June 22, 2023

Best Practices for Web Server Security

Web Infrastructure
Security

By and

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.

Types 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). 
Diagram of web server security layers
Source: Michel Bakni - CIAJMK1209.png, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=114986828 

 

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 Your Web Server

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. 

Explore Solutions 

Talk to an Open Source Expert 

Additional Resources

Connor Headshot

Connor Penhale

Enterprise Architect, OpenLogic by Perforce

With over a decade of experience in enterprise software architecture, engineering, and operations for the Fortune 500, Connor is working to build and support cloud native solutions for OpenLogic customers around the world.

Headshot for Shlomo Vanunu

Shlomo Vanunu

Senior Technical Support Engineer, Zend by Perforce

Shlomo joined the Zend development team 16 years ago and is a part of the IBM i Global Services Team, involved in the development of the Zend for IBMi product installation base. He provides technical services, support, and education for Zend Products for IBMi and related technologies on IBMi.

Shlomo has worked in the IT industry for 35 years and has experience with IBMi OS system, programming, and several other OS variants.