Studies show that 37,000 websites are hacked every day – that translates to 13.5 million websites per year. From exploiting software vulnerabilities to infecting ad-networks, attackers use a wide range of methods to distribute their malware. The good news is, these attacks can be blocked with a systematic approach to hardening your web server.

Now, many think that getting a top-of-the-line firewall is a good enough for website security. This is not true. An experienced security expert will tell you that the best way to secure a server is to deploy a series of defenses, one behind the other. So, even if an attacker manages to get through one layer, there’s another layer to take its place. This approach is called “Layered security”.

Today, we’ll see how to secure web server using “Layered security”.

1. Implement basic system security

The web service is just one part of a server. There are hundreds of ways in which server security can be breached. Setting up a strong foundation for server security is the first step in securing a web server. Here’s how:

• Disable un-used services – In a default OS installation, many services are set to auto-start. This will open ports to the public, which may not be secure. So, disable all services you do not need.
• Harden the file system – The filesystem controls the access privileges of each user. By hardening the filesystem settings, any malware that’s uploaded to the server can be blocked from being executed.
• Protect system binaries – Core system binaries can be write protected by using special filesystem settings. Preventing modification at filesystem level can be an effective deterrent against core system infection.
• Use only verified, authentic software – Get application repos only from official repositories that are cross verified using PGP signature.
• Setup Mandatory Access Control systems to block unauthorized operations – There are kernel patches in Linux and Mandatory Integrity Control features in Linux that restricts each user to a very limited set of operations. This effectively blocks an attacker from running any damaging exploits.
• Enable intrusion detection  – Quick reaction to an intrusion or an intrusion attempt can help you limit any damage done on the server. Intrusion detection systems (IDS) monitor sensitive directories, logs and processes to notify you of un-usual behavior.
• Ensure physical security – Many businesses now use cloud servers from AWS, Google or Azure. For these users, physical security may not be relevant. But for companies that still use on-premise or co-located servers, physical security is still important.

Read : How to secure your server

2. Enforce strong network security

Almost all attacks originate over the network. By locking down your network services, a vast majority of these attacks can be blocked even before it touches your web application. Here are a few tips:

• Close all ports, and open only the ones you need – This is the most fundamental principle in network security. Block all, and allow only those you really want.
• Segregate private and public network – Remember that any one can listen in on the traffic from your server. Your company’s private data such as backup, internal mail, traffic to development server, etc. could be open to public. Split your network traffic so that only the data that’s supposed to be public is available over the public IP.
• Harden the network against common attacks – Many common attacks such as Slowloris, Syn flood, or Spoofed packets exploit insecure default settings in operating systems. The network settings need to be adjusted to defend against these issues.
• Monitor port scanning behavior and block attacking IPs – Valid users come directly to a standard service port, and request information. Malicious users scan for any open ports. Block any IP that tries to connect to closed ports at random.
• Setup a brute force monitor to automatically block abusive IPs – Legitimate users do not send in hundreds of login requests per minute. Install a brute force monitor and block originating IPs.
• Prevent direct access to back-end servers – In reality, only your web server and mail server should be open to the public. All others such as backup server, database server, POP/IMAP server, etc. should be off limits to direct access. Put these servers on a private network to reduce your attack surface area.

Read : An easy way to enable firewall in Linux servers

3. Secure the user and administrator access

Users are often the weakest link in server security. Valid login details are the equivalent to getting a key to a well secured door. It is the path of least resistance and often over-looked by server administrators. Attackers use phishing, brute forcing, or social engineering to steal login details. Here are a few tips to secure user accounts:

• Enforce a strong password policy – Users tend to set easy to remember passwords, which may not be secure. Enforce a strong password policy that makes your users employ only strong, difficult to crack passwords. Some steps include, blocking use of old passwords, setting password expiry, mandatory password length, etc.
• Authenticate only over SSL/TLS – Use SSL/TLS in all your server services. This will prevent sending username and password pairs as plain text.
• Setup secure authentication systems such as Kerberos – Attackers can sniff our username/password pairs sent across networks. Use of secure authentication systems like Kerberos avoid sending passwords across the network, thereby foiling sniffing attacks.
• Implement IP restriction for administrator access – For sensitive users such as administrators, limit logins to a pre-approved set of IPs.
• Consider using 2 factor authentication – For critical accounts, such as administrative accounts, setup 2 step authentication.
• Lock account after login failures – Hackers use automated tools that push in hundreds of passwords per minute to get a working combination. You can prevent it by setting the account to lock after a few login failures.
• Educate users on good security practices – Publish a page on your website explaining how Phishing, Social Engineering, Trojans or other malware can be used to steal login details.

Good passwords need not be hard to remember

4. Harden the web server configuration

All web servers are optimized for feature richness in its default configuration. This presents an attacker a large area of attack. So, securing the server configuration is the first step in web service security. Here are a few tips:

• Prevent information disclosure – In its default configuration, most web servers display a lot of information about the version of the software, list of files in a directory, list of web server modules, etc.. Unless expressly disabled, this provides a wealth of information for an attacker to run a successful exploit.
• Run the web server as an un-privileged user – Configure web server with a new user and group instead of its default user, to provide isolation for other processes.
• Disable un-necessary modules – Choosing the minimal installation for a web server, with only the required modules and features, is recommended to avoid attackers exploiting the vulnerabilities of the unused modules.
• Limit available HTTP methods – The vast majority of web applications use a “GET” request, a “POST request or a “HEAD” request to display web pages. By default, web servers allow use of other kinds of requests such as “DELETE”, “TRACE”, “TRACK”, etc. which can be used by attackers to gain system information. Disable them if it’s not needed.
• Delete default files – Remove the default web page files, default cgi scripts and web server manual directory as they contain web server information.
• Enable DDoS protection – Web servers are the most targeted service in DoS attacks. Setup and enable special DDoS protection modules to block abusive IPs.
• Protect source code and database dumps – Many developers leave backups of website files (eg. database.php.bak), server configuration files (eg. htaccess.txt) or database dumps in public accessible locations, or folders with “directory listing” enabled. This should be avoided at all costs.
• Setup resource limits for each user – An attack on a website can easily cause resource usage spike, and cause the server to go down. Use resource limits for each user to prevent this possibility.
• For SSL (HSTS) if possible – Attackers can sniff web application login details by listening in on the web traffic. By enforcing HTTPS connection in all web requests, this risk can be minimized.
• Restrict permissions to prevent one user from seeing another user’s data – Some web servers allow web applications to navigate out of user’s home folder using symbolic links, lax permissions, etc. Secure all web server and filesystem settings to prevent data breach.

Read : How to web blocked Zero day exploits using NAXSI web application firewall

5. Secure the web server modules

The real work horse of a web server is its specialist modules such as PHP, ASP, Ruby, etc. These modules determine how securely the user scripts are executed. Here’s how web server modules can be protected.

• Execute user scripts in un-privileged user mode – Configure your web server modules (such as PHP, Python, Ruby, etc.) to execute the scripts as un-privileged modules. This will prevent a vulnerability in one user’s script affecting the security of another user.
• Block or Restrict access to system commands – Some web server features allow running of system commands. These features can be used in hack attempts. Disable such features if it’s not absolutely essential to your service.
• Disable remote file inclusion or execution – Disable web server module features that enable applications to open remote URLs or download remote files. These may contain malicious code, and it is a method used extensively to hack websites.
• Use server hardening patches – Many web server modules are designed for feature richness, and not security. Use independent security patches (such as Suhosin for PHP) that can be used to harden the server.

Read : How to secure your PHP web module

6. Disable weak encryption protocols and ciphers

Everyone knows encryption is good, but not many know that there are weak encryption systems that can be easily cracked. Many servers by default use weak encryption methods, which lead to information disclosure. Here’s how you can secure your encrypted communication.

• Disable weak ciphers – Ciphers are “steps” to encrypt a data. Some ciphers like DES and RC4 have known vulnerabilities. Replace these ciphers with strong ones like AES and GCM.
• Disable SSL v2 and v3 – SSL protocols were found to have serious vulnerabilities like FUBAR, POODLE and DROWN. It is best to disable these in all your services.
• Disable compression over TLS 1.0 – If your server uses TLS 1.0 (it’s recommended to use TLS 1.2), disable compression of HTTP requests, because that’s known to be vulnerable to CRIME exploit.
• Use certificates of at least 2048 bit strength – The average desktop computer now has enough power to be a threat to encryption strengths less than 2048 bit. So, get certificates of only 2048 or higher.
• Use encryption for all services – This seems like a moot point, but many server owners use encryption only on web services. It is best to encrypt all channels of traffic from your server.
• Do not use self-signed certificates – Many think that self-signed certificates are safe, because it provides encryption anyway. This is not true. Self-signed certs always display an error, and end-users then tend to ignore warnings – even if it says there’s active snooping going on. So, it’s best to use certificates from valid certificate authorities. You can get free certs from Lets Encrypt.

Read : How we fixed the DROWN SSL vulnerability

7. Setup web application firewall and malware scanning

There are a wide range of attack methods such as Cross Site Scripting (XSS), SQL injection, or CSRF that’s used to exploit web applications. Web Application Firewalls (WAFs) and malware scanners can be used to block such attacks. Here are a few tips on how best to do it:

• Block all known attack patterns – There are hundreds of known attack patterns. Use reliable signature databases to block all these common attacks.
• Use security rules customized for the applications hosted in the server – Legitimate requests to your applications may be blocked by generic WAF rule sets. Customize them based on which rule triggered a block.
• Setup upload time scanning – Any upload, whether it be via Web, FTP, Web disk, File shares, or SSH, it should be scanned for malware content.
• Configure process scanning – Setup the anti-malware tools to detect malicious behavior in running programs.
• Setup malware scanning based on filesystem change – When a malware is uploaded, it needs to be written on to the disk. Setup the anti-malware to monitor filesystem changes, and trigger a file scan when a new file is detected.
• Use multiple anti-virus database – A single database cannot cover all possible viruses. Use multiple vendors to ensure high probability of virus detection.
• Schedule periodic full server scanning – What if some malware escaped upload time scanning (before your anti-virus signatures were updated)? You can clean them with periodic full server scanning.
• Stay informed about new modes of attack – Hackers invent new ways to exploit web apps all the time. Subscribe to security news to be aware of new trends. This will help you select effective mitigation strategies.

  A lot of attacks rely on executing a malware on the server. In our server management services, using a web application firewall is one of the ways we block malware uploads. We routinely see cross site scripting, sql injections or remote code executions being blocked by the firewalls we implement. If not for this layer of security, many of these attacks would have succeeded.    

Blessen Cherian
Member of Executive Group, Bobcares

8. Harden the database servers

Many attacks are crafted to finally get access to a database. For hackers, it’s like hitting a gold mine. Assuming that an attacker got past all other defenses, the database itself should be able to withstand information disclosure attacks. Here’s how you can improve database security.

• Enforce a password for all database users – Never create a user with no password. Audit regularly to make sure all accounts have passwords.
• Remove all default users and demo/test databases – Almost all database servers come with a few demo databases and users. These details are public information. It’s best to remove these accounts.
• Restrict user privileges to only what’s needed – It is common practice to create database users with access to all tables in a database. This is really not needed in all cases. Give access to only minimum required tables, and limit privileges (SELECT, INSERT, etc.) to only that’s needed by that user. It’ll prevent data loss even if an exploit is attempted (see image below).
• Change the name of admin user – The admin username of most database servers is public information. Change the admin username to prevent automated database attacks.
• Restrict remote connections to only known IPs – Ideally remote access should be disabled. But if it’s absolutely required, restrict the access to only known IPs.
• Do not store database backups on public locations – This is an all-too-common mistake. Application owners take database backups (prior to debugging, upgrades, etc.) and leave them in public accessible locations such as web folders, temporary partition, etc. Use your monitoring system to detect SQL dump files in public folders.
• Keep the database server updated – Database upgrades can be cumbersome, but it’s not avoidable. Apply security patches as soon as it is available.

Limiting user permissions will prevent data loss – unlike how it happened here

Read : How to secure your database server

9. Run each application in an isolated environment

Many companies run all their web applications in a single server. This can include the company website, collaboration suite, billing system, an old CMS that they tested but discarded later, etc. The issue with that is, a single vulnerability in one of these applications can get all these sites infected with malware. So, the best practice dictates that each application be run in a different server environment.

• Consider using virtualization – You do not need to buy many dedicated servers and run your costs through the roof. Just get one server, and virtualize it to get reliable application isolation.
• Put app and database services into different servers – Your database contains all your business critical information. There’s really no need to make your database server publicly accessible. Put it in a private network, and allow only an IP restricted, “low privileged” access from your web application to the database server.
• Segregate system and user files – Put user scripts in a disk partition that’s different from system files, and implement restrictive permissions to prevent navigation from user directories to system directories. This will prevent malware from accessing system critical data.

Read : How account isolation was implemented using OpenShift for WordPress sites

10. Separate the development, testing and production environment

There are far too many developers who deploy un-tested code in production servers under the name “new-site”, “demo-final”, etc. These site versions usually contain insecure code, and can be easily exploited to gain access to production database. Attackers are aware of this human tendency, and use specially crafted attacks to exploit this. Here are a few tips to secure it.

• Use public inaccessible servers for development and testing – Put the development code in a separate server, and limit access to those servers only from your company IP, or over VPN.
• Audit web folders regularly and remove unwanted files – Remove test scripts, website backups, file backups, or any other kind of script or file that’s not absolutely needed for the website to function.

Read : How Bobcares helps with DevOps

11. Follow secure coding practices

Many developers think only about the feature set when they build a website. Security is not just the job of the server administrator. If the application code is built to be secure, it cannot be exploited. Here are a few best practices.

• Enable strong input validation – This is the most fundamental rule of all. Never trust the input of a website user. You know what kind of data is needed. Accept only that data in an acceptable format.
• Use CAPTCHA where applicable – Many exploits happen through automated methods. Using a strong CAPTCHA can block this.
• Sanitize data sent to other systems – When sending data to other apps or servers (such as database servers), use another set of data validation to make sure it conforms to your data format.
• Use least privilege for functions by default – If a web application is only required to display information from a database, there’s no need to give it “UPDATE” privilege. Similarly, audit all the privileges of a web application and grant it only those accesses that are absolutely needed.

Read : How to use Django to improve web application security

12. Keep server and application software updated

Vulnerable software is perhaps the most popular way for hackers to gain access to a server. Software vulnerability results from using outdated or non-authentic software. Here are a few tips to keep your application updated:

• Enable update notifications – Configure the package management software (such as Yum) to send you notification when an update is available.
• Apply security patches ASAP – Auto updates can be configured for security updates. For eg., in Redhat compatible systems yum-security plugin can be used for this purpose.
• Subscribe to vulnerability disclosures – Software vendors often take a few days to release a patch to fix any new vulnerability. Being alerted to a newly released vulnerability helps you block exploit attempts until a patch is available.

Read : How to keep your servers updated and patched

13. Setup a fool-proof backup system

Security is not complete unless you plan for everything. The worst case scenario is that an attack or a hardware failure caused all data to be lost. For you to be able to quickly recover from such an event, backups are mandatory. Here are some backup best practices:

• Backup daily – Take backups as frequently as possible – at least once a day.
• Take incremental backups – Reduce load on the server by taking incremental backups.
• Setup an off-site backup – Copy your backups to a remote server, so that even if your current servers are unreachable, you can restore your site on a different server.
• Restrict access to backup server – Your backups contain all your business data. Enable multi-factor authentication, and minimize the number of people who have access to it.
• Monitor your backup process – Monitor the backup process for successful completion. Investigate if the process returns any errors.
• Test backup integrity periodically – Try restoring data at random at least once a week. This will ensure that the backups will work when needed.

Read : 7 best practices in maintaining server backups

14. Monitor for security issues round the clock

Logging all system events can help you detect service mis-configuration, and attack attempts. This information can be used to further harden your server. Here are the top information you need to log.

• Enable file access monitoring – Log which all users tried to access system files or executable scripts and programs.
• Enable login monitoring – Log the IP, time and username of all login attempts.
• Enable critical events monitoring – Log system reboots, high loads, or any other event that’s out of ordinary.
• Setup alerts for unusual log entries – Setup your monitoring system to alert you if unusual entries are found in the log file.
• Setup command logging – Record all commands issued by users.
• Log the events to a remote server – In the event of a server breach, an attacker will clear all log files. So, setup your system to relay all log entries to a remote server with only “update” permission.
• Monitor DNS blacklists – Setup your monitoring systems to notify you if your mail server IP is listed in any Realtime Block Lists. Such a listing means there’s malicious traffic (via web, mail, DoS, etc.) originating from your server. Timely notification helps you mitigate the damage and quarantine the spam source.

Read : How remote logging was made resilient to failures

15. Audit and re-harden the server

As long as you have data to protect, there will be people trying to steal it. That’s the truth about security. Attackers constantly find new ways to breach security, and new vulnerabilities to exploit. That is why it is important to audit your server defenses periodically, analyze various security events, and re-harden the server. Here are a few things to look for:

• Confirm if the server is updated – See if all patches are applied, and if not, resolve all issues (technical or business).
• Verify if all disclosed vulnerabilities are patched – Go through all security advisories and make sure no patches or mitigation steps were missed out.
• Analyze server events and take action – Go through all critical server events and see if all attacks were blocked as you planned. If not, take corrective actions.
• Confirm if backups are working fine – Analyze backup logs, and results of backup restore tests. Take corrective action if any issues are noted.
• Test responses to security events – See if your 24/7 security monitoring team has reacted as planned to security events. Verify if those actions were adequate. Make changes as needed.
• Verify if the server is secured against new forms of attack – Evaluate the server defenses to see if it can stand up to new forms of attack as disclosed in security channels.
• Analyze if changes in business functions necessitate new defenses – Some business changes require more in-depth security. For eg. if your company has started storing medical records, you may need to encrypt device drives, or perform penetration testing on your applications. So, make changes to your security model as applicable.

  Periodic top-down security audits are an important part of our server management services. Our security experts try to bypass the server defenses by using popular attack tools loaded with latest exploit methods. By playing the role of an attacker, our experts gain valuable insight into how the server can be further secured against new threats.   

Sojish Krishnan
Member of Executive Group, Bobcares

How to secure web server – A quick recap

Much like how a fort is secured by a moat, canons, archers and steep walls, effective web server security can be ensured only with multiple layers of defenses. Today we’ve seen how to secure web server using Layered security. By securing each sub-system of a server, an attacker will have an uphill task to breach server security – which is enough to encourage them to seek other easier targets.

In case you skipped to the end, here’s a quick summary of what needs to be done to keep your server secure.

Bobcares helps online businesses of all sizes achieve world-class security and uptime, using tried and tested solutions. If you’d like to know how to make your server more reliable, we’d be happy to talk to you.