Getting Started with Web Server Security
The role that the internet plays in people’s lives and business operations has only continued to increase as advancements in web services, web-based applications and other services have evolved. Many businesses have even gone so far as to shift most of their services online or see their web presence as a major way to advertise their brand and share information with their customers.
In response, protocols like HTML5 and HTTPS are spreading further. They meet customer demands to have access to any data at any time anywhere, especially when it comes to online shopping or banking. All of these web-based advancements, however, have also attracted cyberthieves and hackers, encouraging them to find new vulnerabilities and attack vectors to target businesses and unsuspecting website visitors.
For those looking to explain the basics and myths around web server security and how they can improve the security of their websites, this article is the first of the Infosec Skills series in web server protection. We’ll be providing an overview of web server security and introducing many of the key terms and topics that will be explored in more detail in later pieces.
Network versus web server security
While there are a lot of tools, techniques and active defense mechanisms like firewalls and intrusion detection systems that can be employed to enhance web server security, the first step organizations must take is to develop a holistic approach to security. It may be easy to think that just having a network firewall in place to secure a network will also protect the web servers and web applications sitting within them, but this isn’t true.
However, network security is different from web server security. Perimeter defenses such as firewalls use rules to filter and block traffic that is predetermined to be “bad.” But when it comes to establishing, managing and securing websites, such network perimeter defenses are not designed to or appropriate to protect web servers from malicious attacks.
Business and organizational websites have to be accessible to allow incoming traffic on coming into ports 80 (HTTP) and 443 (HTTPS) to access such web services, and nothing more. Because of this, network firewalls cannot analyze if this incoming web traffic is simply trying to learn more about a company or, alternatively, performing initial vulnerability scanning for a future cyberattack.
Web server hardening
When a new web server is being spun up, the first thing any security professional is going to do is perform a number of steps and set a number of configurations to secure — or harden — the device. Web server hardening refers to identifying and remediating and mitigating all known security issues and vulnerabilities that the web server and its applications before a malicious hacker exploits them.
Hardening a server includes not only ensuring that the software is running the latest operating system and patches, but also shutting down services, ports and other identifying information according to unique requirements of the organization and the device’s intended use.
Web server hardening should occur in a development or testing environment before the web server and its applications are running “live” in production. Within these development environments, organizations can use several different tools and best practices to harden the web server, ranging from scanning the web application with a vulnerability scanner, conducting manual source code audit and quality review, completing penetration testing and ensuring that the device’s management console has the proper filters, rules and services in place.
Common web server hardening techniques
As with any other security best practice, none of these hardening methods alone is the best or comprehensive enough to identify all vulnerabilities or prevent unwanted traffic from probing the device; each has their pros and cons that should be well understood.
For example, while automated web server vulnerability scanners are fast, quick and reoccurring methods to discover a wide range of technical vulnerabilities faster than a manual review or penetration test, it cannot reasonability identify all logical vulnerabilities due to the sheer pace of exploit development. On the other hand, a manual audit or penetration test can help to ensure more current vulnerabilities are accounted for, but these tests and reviews are slower and often more costly to perform. In either case, organizations must also decide whether the tests will be “white” or “black” box reviews, where source code or internal knowledge of the device’s configuration is known or unknown, respectively.
Securing web server components
There are many components that make up and interact with the web server that makes hosting and running a web application successful. These components include web server software, the web server operating system — such as Linux or Windows — as well as database servers and network devices. Each of these parts and pieces that make up the web server need to be tested, patched and secured, as each can provide the way a cyberattacker can gain access to or bypass a web application in order to retrieve or modify sensitive data.
Removing unused services
The more services and functions that a web server is enabling, the more opportunities a potential hacker will have to exploit the device. A simple but easily overlooked best practice is to disable and turn off any services, ports or functions that will not be used in the web server environment. This can reduce the potential attack surface.
Limiting remote access
Depending on the size, scale and purpose of the web server environment, remote access to the web server should at least be limited, encrypted and securely tunneled through SSH and RDP or turned off entirely. If possible, administrative access to the web server should be limited to a specific range of IP addresses, such as those assigned to an administrative team.
User account and privilege management
The two types of accounts that can integrate with web servers: user and system. In both cases, the right balance between functionality and security is needed, allowing admins to complete the necessary maintenance tasks without being unduly cumbersome to slow productivity or encourage workarounds.
One method for user accounts is to establish different administrator accounts on the web server to perform different security and maintenance tasks. This could mean one account to perform log reviews, another for performing system backups and another account to make changes to system configurations. This way, work can be performed to achieve a designated purpose, but no one account has global privileges in case the username and credentials are exploited.
System privileges, such as those owned by the database connected to the webserver to read/write traffic logs or display information, also need to be structured with only the permissions that they need to enable the web application. Without doing so, these associated system accounts can be manipulated by attackers to bypass security controls or cause damage to an organization. Continuing with the database example, improper system account controls could lead to unauthorized system communication, database tables to be created or dropped or other services utilized to provide a malicious user with more of an attack surface.
As with any other software, one of the most important security practices is regular software patching. As manufacturers identify security vulnerabilities or bugs, patches are deployed to fix these holes. These should always be applied to ensure that commonly known weaknesses in your web server are fixed before they are found and exploited by hackers.
Web application firewalls
As discussed previously, while traditional network firewalls monitor traffic, requests and IP addresses against certain criteria or rules, they are not designed to evaluate traffic flowing into HTTP and HTTPS ports. However, web application firewalls (WAFs) can be employed on web and application services to attempt to identify malicious activities at the application or host level. For example, if an attacker is attempting to exploit a web server through HTTP and HTTPS traffic using a known vulnerability, the WAF can block this connection and stop the attacker from pulling off the attack against the website.
However, like other security products, WAFs do have their shortcomings and should be used as a part of a larger, layered defense strategy. In particular, WAFs only detect known web server security vulnerabilities, using signatures or patterns of known malicious traffic against existing connections. While this will protect your web server against known attacks or even denial of service attacks, zero-day vulnerabilities or attack vectors can exploit your server successfully.
Additionally, WAFs are composed of configurable software that relies on administrators and security professionals to set which rules or services should be protected. If attackers identify ways to avoid these protocols or identify security holes to bypass the WAF entirely, a web server can be exploited.
Logs and security
In addition to web server hardening and firewalls, organizations often employ traffic logs on their web services, keeping a record of everything that is occurring on the web server. With this information, administrators and security professionals can set flags to highlight anomalous activities or, in the event of a cyberattack, attempt to recreate the attack and learn more about the attacker. In either case, administrators can then use this information to make changes to better protect the web server in the future.
Another aspect of web server security involves the scripts and commands executed by the server or are enabled by it. Just as with evaluating other services and ports to be opened or closed on the web server, security professionals need to understand the types of commands allowed to be performed by the web server.
For example: Requests for the server to provide PHP files, which often contain sensitive configuration information as well as database passwords and other data, can be disabled to prevent attackers from requesting and utilizing this information.
Other examples of key scripts and commands to be disabled include:
- Preventing public execution of phpinfo.php files, which sometimes are used by web developers to document key information about the web environment to aid in debugging
- Disabling TRACK and TRACE commands, which can be used by web developers to debug problems on a web server
- Changing default SSL ciphers, such as those that come with Apache’s SSL, which are often weaker than the necessary level of encryption recommended
Web server active defense
A final method employed to improve web server security is the use of web vulnerability scanners. These devices, also known as web application security scanners, include preconfigured software that automatically scans websites and web servers, probing them for common vulnerabilities and security issues that can be exploited.
Web vulnerability scanners are a popular choice for active defense. This is because the tools automate the vulnerability detection and reporting process, allowing for multiple and consistent evaluation of web server security. These scanners can either be “black box,” where no internal data or knowledge about the web server is provided before the test, or “white box,” where source code is also scanned for potential vulnerabilities.
By no means is this a full introduction to the wide range of web server security tools and methods. Furthermore, no single best practice or technique can defend against the full range of determined attackers. However, exploring the full Infosec Skill series in web server security can provide organizations with a solid foundation, set of rules and best practices to get the most out of their cybersecurity program.
- Securing Web Servers, TechWeb