Best Practices for Web Server Security
As web servers are a central component of web infrastructure, web server security is critical for preventing data losses and security breaches. Following best practices to secure your web server will significantly reduce the risk of your resources and reputation being compromised in the event of a malicious cyberattack.
In this blog, we'll examine the different kinds of web server security and the most common ways bad actors try to exploit web servers. We'll also share examples of security configurations for two popular web servers: NGINX and Apache HTTP Server.
What Is Web Server Security?
Web server security is a significant principle of any network operating online and it is essential to protecting businesses and their data from malicious actors attempting to access secret information, deny service to authorized users, and otherwise compromise the availability and trust of business applications.
A web server is what listens for, and responds to, HTTP requests for business applications and websites, so it is often the place in your network diagram where security measures are implemented. If a web server is secure, it means that only authorized users have access to protected information, and that the integrity of information provided to website users is safeguarded.
Back to topTypes of Web Server Security
Within information security, there are many types of server security, starting with the physical data center that hosts the hardware running a web server that is listening to requests on the network. In this blog, we’ll be addressing the security of the web server application itself, so we won’t be discussing firewalls, intrusion detection, or compliance measures on or in front of a server. Instead, we'll focus on web server security configuration.
A web server can be configured to handle three facets of security:
- Availability, by enabling rate limiting to protect business application server compute resources from DDoS attacks
- Confidentiality through:
- Client Authentication, or AuthN, by prompting a user to provide a username and a password to associate with a principal in a network
- Client Authorization, or AuthZ, by ensuring certain URLs are protected from anonymous access and requiring association with a principal to obtain access
- Integrity and Trust, by using HTTPS, TLS certificates, and Public Key Infrastructure (PKI) to prove to users that we are who we say we are (trust), that the data passed between the web server and the user has not been modified in-flight (integrity), or viewed by another party (confidentiality).
Web Server Vulnerabilities
Web servers are often thought of as the first line of defense for a business application because they frequently serve as proxies that expose business applications to the global internet.
For example, a consumer bank will have a portal that allows customers to view balances and complete transactions, such as wiring money. If an attacker had a way to compromise this business application, they might be able to initiate wire transfers from customers' accounts to accounts the attacker controls, essentially “robbing the bank” remotely. If an asset is worth protecting, it's worth attacking, which is why knowing how attackers may try to breach your web server is essential.
Common Security Threats and Attack Methods
- Organizational attacks, like the successful deployment of Ransomware, might begin as a successful exploitation of a web server vulnerability
- Personal security attacks including:
- Phishing attacks that target users through email, text messages, and social media sites to escalate privileges in a network
- Spyware used to obtain passwords in order to log into sensitive systems, escalate privileges, and launch further attacks in a network
- Software attacks including:
- SQL Injection and Cross-Site Scripting, which are common types of web app vulnerabilities used by attackers to attempt to access protected information
- Arbitrary code execution and Remote code execution, which might happen at the middleware layer of your business application through a third-party library
- Attacks on availability, such as a Distributed Denial-of-service (DDoS) attack, might be used to tie up an organization's resources and awareness while sensitive data is being exfiltrated or a remote administration/access tool/trojan (RAT) is being embedded in a network
How to Secure a Web Server
Securing a web server involves enabling Authentication, Authorization, and Encryption.
Earlier, we talked about different web server security measures designed to ensure Availability, Confidentiality, and Integrity. Web servers do this by enabling Authentication, Authorization, and Encryption.
What Is Authentication?
Authentication (AuthN) is the mechanism by which a web server assigns an identity to a user agent, or web browser, to grant or deny an entity access to a network or system resource.
Authentication can be achieved using a single sign-on (SSO) solution to streamline the process and management of authenticated users based on the credentials provided. IBMi, for example, achieves SSO via a feature called Enterprise Identity Mapping (EIM) to manage user access to resource assets.
Let’s take a look at how to configure two popular open source web servers with AuthN:
NGINX: auth_basic "ZendPHP Application Login"; auth_basic_user_file /qopensys/etc/nginx/.htpasswd ;
Apache HTTP:
<Location /> ProfileToken On AuthType Basic AuthName "IBM i OS User Profile" Require valid-user PasswdFile %%SYSTEM%% order deny,allow Allow from all </Location> PasswdFile %%SYSTEM%% | %%LDAP%% | %%KERBEROS%% | QUSRSYS/PHP_USERS (groups, validation list or .htpasswd)
What Is Authorization?
Once the user is authenticated with a principal, Authorization (AuthZ) is how a web server determines which principals can access a protected resource.
Authorization (AuthZ) checks are done after a user has been authenticated by the web server and requires that the enterprise knows who is trying to gain access.
A website’s login page will either not have AuthZ enabled, or have a fully permissive AuthZ configuration, allowing any user to visit it to authenticate and obtain a principal. A protected page might have an AuthZ configuration that requires a principal with a specific role, such as “account_holder” or “user_admin.” This is accomplished with validation lists in conjunction with other resources, such as group files, to limit access to server resources.
In the above web server configuration examples, AuthZ is “all or nothing.” If the user can authenticate, any principal is accepted as Authorized. Most organizations need more granular authorization controls, and this is where Role Based Access Control (RBAC) comes into play. In some configurations, a web server may provide AuthN, and associate a user agent with a principal, but the application server (Wildfly, ZendPHP, NodeJS) will determine which functions can be run.
These AuthZ checks are typically configured against specific parts of an HTTP request. For example, principals in the “consumer_banking” group might have the ability to access a URL “/checking/send_wire” but not “/business/commercial_loan_rates”. Principals in the “auditing” group might be able to GET (or “read") from “/api/business/stats” to get reporting data on commercial accounts, but not be able to POST (or “create”) to “/api/business/checking” and create a new commercial checking account.
Access Control
A step before AuthZ is access control. This can be based on a client's hostname or IP address to control which hosts can access a given URL. In the following examples, using the directives Allow and Deny allow the implementation of access control. For Apache, the Order directive tells the order to apply the filters, HTTP server by default, and prevents any clients from seeing the entire file system.
Apache HTTP (documentation): <Directory/> Order deny,allow deny from all allow from none </Directory>
NGINX (documentation): http { server { listen 10.151.16.40:10055; root html; location /MyAPP { MyAPP; satisfy all; deny 192.168.2.9; allow 192.168.1.1/24; allow 127.0.0.1; deny all;
What Is Encryption?
In a web server, encryption provides three key assurances to both the web server and the web browser, or user agent: that we are who we say we are (trust), that the data passed between the web server and the user have not been modified in-flight (integrity), and that the data has not been viewed by another party (confidentiality).
Web servers enable encryption through HTTPS. HTTPS is more secure than HTTP because it uses encryption to protect information as it is being sent between clients and servers. When an organization enables HTTPS, any information the user agent or web server transmits, like passwords or credit card numbers, will be protected from attackers.
Here's how to configure encryption in Apache HTTPD and NGINX:
Apache HTTPD: # TLS/SSL encryption Listen *:443 SetEnv HTTPS_PORT 443
<VirtualHost *:443> SSLEngine On SSLAppName QIBM_HTTP_SERVER_ZENDPHP74 SSLProtocolDisable SSLv3 TLSv1 TLSv1.1 ... </VirtualHost>
NGINX: server { listen 10.151.16.40:443 ssl; server_name 10.151.16.40; ssl on; ssl_certificate /qopensys/etc/nginx/ssl/domain_name.pem; ssl_certificate_key /qopensys/etc/nginx/ssl/domain_name.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5;
...
}
Mitigating DoS and DDoS Attacks
A DDoS is a flood of requests being sent to a web server intentionally by one or multiple malicious sources. A common mitigation against a DDoS attack is presented in the following configurations:
Apache HTTPD (documentation): RequestReadTimeout handshake=20-40,MinRate=400 header=20-30,MinRate=500 TimeOut 500 KeepAlive Off HotBackup Off KeepAliveTimeout 180 MaxKeepAliveRequests 10 LimitRequestLine 8180 LimitRequestFieldSize 32762 LimitRequestFields 98
NGINX (documentation): limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;
IBM i Configuration Examples
In this section, we'll share config files for NGINX and Apache HTTPD listening on TCP port 80 or 443 on an IBM i system. We will assume network connections to the web server listening for requests are protected by a firewall to expose the minimum number of ports to the internet to serve web content and reduce the attack surface for a threat actor. We will also assume that the operating system, like Linux, Windows, or IBM i has the latest updates to ensure integrity at the kernel level.
Apache HTTP: # TLS/SSL encryption Listen *:443 SetEnv HTTPS_PORT 443 <VirtualHost *:443> SSLEngine On SSLAppName QIBM_HTTP_SERVER_ZENDPHP74 SSLProtocolDisable SSLv3 TLSv1 TLSv1.1
DocumentRoot /www/zendphp74/htdocs # Allow requests for files in document root <Directory /www/zendphp74/htdocs> Options FollowSymLinks order allow,deny allow from all AllowOverride all </Directory>
# Authentication <Location /> ProfileToken On AuthType Basic AuthName "IBM i OS User Profile" Require valid-user PasswdFile %%SYSTEM%% order deny,allow Allow from all </Location> </VirtualHost>
PasswdFile %%SYSTEM%% | %%LDAP%% | %%KERBEROS%% and a created user PasswdFile QUSRSYS/PHP_USERS
NGINX: http {
server { listen 10.151.16.40:10055; server_name 10.151.16.40; error_page 404 /404.html; error_page 500 502 503 504 /50x.html;
location = /50x.html { root html; }
#php location / {
root /www/zendphp/htdocs; index index.php index.html; try_files $uri index.php index.html; }
# pass the PHP scripts to FastCGI server
location ~* \.php$ { root /www/zendphp/htdocs; index index.php index.html; try_files $uri index.php index.html;
auth_basic "ZendPHP Application Login"; auth_basic_user_file /qopensys/etc/nginx/.SVhtpasswd ;
#UNIX-domain socket path fastcgi_pass unix:/QOpenSys/var/run/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name; include fastcgi_params;
} } }
Final Thoughts
When it comes to web server security, this blog is just the tip of the iceberg. Keeping your web server secure is not a one-and-done exercise; it's an ongoing process as there will always be new threats and attackers finding new ways in. Avoid embarrassing and damaging security incidents by staying on top of security recommendations and following best practices like the ones outlined here.
Get Support for NGINX, Apache, and 400 OSS Technologies
No matter what software is in your stack, chances are OpenLogic covers it with SLA-backed technical support and professional services. We work with enterprise teams to help them keep their open source infrastructure secure and performant.
Additional Resources
- Guide - Overview of Open Source Web Infrastructure
- Blog - NGINX vs. HAProxy
- Blog - Top Open Source Infrastructure Technologies (State of Open Source Report)
- Blog - NGINX Performance Tuning: Top 5 Tips
- Blog - Using ZendPHP, PHP-FPM, and NGINX on IBM i
- Blog - Web Server vs. Application Server: What's the Difference?
- Blog - CVE 2023-44487 and How to Avoid an HTTP/2 Rapid Reset Attack
- Blog - Apache vs. NGINX
- Blog - NGINX Setup and Configuration Tips
- Course - NGINX Training
- Datasheet - Zend Server
- Video - Open Source Security
