Apache Web Server Hardening and Security Guide

本贴最后更新于 635 天前,其中的信息可能已经渤澥桑田

A practical guide to secure and harden Apache Web Server.


1. Introduction

The Web Server is a crucial part of web-based applications. Apache Web Server is often placed at the edge of the network hence it becomes one of the most vulnerable services to attack.

Having default configuration supply much sensitive information which may help hacker to prepare for an attack the Web server.

The majority of Web application attacks are through XSS, Info Leakage, Session Management and PHP Injection attacks which are due to weak programming code and failure to sanitize Web application infrastructure.

According to the security vendor Acunetix, 84% of tested applications have one or more vulnerabilities.

This practical guide provides you the necessary skill set to secure Apache Web Server.

In this course, we will talk about how to Harden & Secure Apache Web Server on Unix platform.

Following are tested on Apache 2.4.x version.

  1. This assumes you have installed Apache on UNIX platform. If not, you can go through Installation guide.
  2. We will call Apache installation directory /opt/apache as $Web_Server throughout this guide.
  3. You are advised to take a backup of existing configuration file before any modification.


1.1 Audience

This is designed for Middleware Administrator, Application Support, System Analyst, or anyone working or eager to learn Hardening & Security guidelines.

Fair knowledge of Apache Web Server & UNIX command is mandatory.

****Bonus: ****Click here to download this guide in PDF format.

1.2 Notes

We require some tool to examine HTTP Headers for some of the implementation verification. There are two ways to do this.

  1. Use browser inbuilt developer tools to inspect the HTTP headers. Usually, it’s under Network tab
  2. Use online HTTP response header checker tool

2. Information Leakage

In default Apache configuration you would have much sensitive information disclosures, which can be used to prepare for an attack.

It’s one of the most critical tasks for an administrator to understand and secure them.

2.1 Remove Server Version Banner

I would say this is one of the first things to consider, as you don’t want to expose what Web server version you are using. Exposing version means you are helping hacker to speedy the reconnaissance process.

The default configuration will expose Apache Version and OS type as shown below.


ServerTokens Prod
ServerSignature Off

ServerSignature will remove the version information from the page generated by apache Web server.

ServerTokens will change Header to production only, i.e. Apache


As you can see below, version & OS information is gone.

2.2 Disable directory browser listing

Disable directory listing in a browser, so the visitor doesn’t see what all file and folders you have under root or subdirectory.

Let’s test how does it look like in default settings.

mkdir test

touch hi

touch hello

Now, let’s try to access Apache by http://localhost/test

As you could see it reveals what all file/folders you have and I am sure you don’t want to expose that.


Options -Indexes


Options None

Note: if you have multiple Directory directives in your environment, you should consider doing the same for all.


Now, let’s try to access Apache by http://localhost/test

As you could see, it displays a forbidden error instead of showing test folder listing.

2.3 Etag

It allows remote attackers to obtain sensitive information like inode number, multipart MIME boundary, and child process through Etag header.

To prevent this vulnerability, let’s implement it as below. This is required to fix for PCI compliance.


FileETag None

3. Authorization

3.1 Run Apache from non-privileged account

Default apache configuration is to run as nobody or daemon. It’s good to use a separate non-privileged user for Apache.

The idea here is to protect other services running in case of any security hole.


groupadd apache

useradd –G apache apache

chown –R apache:apache /opt/apache

User apache
Group apache


grep for running http process and ensure it’s running with apache user

ps –ef |grep http

You should see one process is running with root. That’s because Apache is listening on port 80 and it has to be started with root.

3.2 Protect binary and configuration directory permission

By default, permission for binary and configuration is 755 that mean any user on a server can view the configuration. You can disallow another user to get into conf and bin folder.


chmod –R 750 bin conf

3.3 System Settings Protection

In a default installation, users can override apache configuration using .htaccess. if you want to stop users changing your apache server settings, you can add AllowOverride to None as shown below.

This must be done at the root level.


Options -Indexes
AllowOverride None

3.4 HTTP Request Methods

HTTP 1.1 protocol support many request methods which may not be required and some of them are having potential risk.

Typically you may just need GET, HEAD, POST request methods in a Web application, which can be configured in the respective Directory directive.

Default apache configuration support OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT method in HTTP 1.1 protocol.


deny from all

4. Web Application Security

Apache Web server misconfiguration or not hardened properly can exploit Web application. It’s critical to harden your Web server configuration.

4.1 Cookies

4.1.1 Disable Trace HTTP Request

By default Trace method is enabled in Apache Web server.

Having this enabled can allow Cross Site Tracing attack and potentially giving an option to a hacker to steal cookie information. Let’s see how it looks like in default configuration.

#telnet localhost 80
Connected to localhost.
Escape character is '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 200 OK
Date: Sat, 31 Aug 2013 02:13:24 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http 20
Host: test
Connection closed by foreign host.#

As you could see in above TRACE request, it has responded my query. Let’s disable it and test it.


TraceEnable off


#telnet localhost 80
Connected to localhost.
Escape character is '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 405 Method Not Allowed
Date: Sat, 31 Aug 2013 02:18:27 GMT
Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1
405 Method Not Allowed
Method Not Allowed
The requested method TRACE is not allowed for the URL /.
Connection closed by foreign host.#

As you could see in above TRACE request, it has blocked my request with HTTP 405 Method Not Allowed.

Now, this Web server doesn’t allow TRACE request and help in blocking Cross Site Tracing attack.

You can mitigate most of the common Cross Site Scripting attack using HttpOnly and Secure flag in a cookie. Without having HttpOnly and Secure, it is possible to steal or manipulate Web application session and cookies and it’s dangerous.


Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

4.2 Clickjacking Attack

Clickjacking is well-known Web application vulnerabilities.


Header always append X-Frame-Options SAMEORIGIN


X-Frame-Options also support two more options which I explained here.

4.3 Server Side Include

Server Side Include (SSI) has a risk of increasing the load on the server. If you have shared the environment and heavy traffic Web applications you should consider disabling SSI by adding Includes in Options directive.

SSI attack allows the exploitation of a Web application by injecting scripts in HTML pages or executing codes remotely.


Options –Indexes -Includes
Order allow,denyAllow from all

Note: if you have multiple Directory directives in your environment, you should consider doing the same for all.

4.4 X-XSS Protection

Cross Site Scripting (XSS) protection can be bypassed in many browsers. You can apply this protection for a Web application if it was disabled by the user. This is used by a majority of giant Web companies like Facebook, Twitter, Google, etc.


Header set X-XSS-Protection "1; mode=block"


As you can see, XSS-Protection is the injected in the response header.

4.5 Disable HTTP 1.0 Protocol

When we talk about security, we should protect as much we can. So why do we use older HTTP version of the protocol, let’s disable them as well?

HTTP 1.0 has security weakness related to session hijacking. We can disable this by using the mod_rewrite module.


RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

4.6 Timeout value configuration

By default Apache time-out value is 300 seconds, which can be a victim of Slow Loris attack and DoS. To mitigate this you can lower the timeout value to maybe 60 seconds.


Timeout 60

5. SSL

Having SSL is an additional layer of security you are adding into Web Application. However, default SSL configuration leads to certain vulnerabilities and you should consider tweaking those configurations.

5.1 SSL Key

Breaching SSL key is hard, but not impossible. It’s just matter of computational power and time.

As you might know, using a 2009-era PC cracking away for around 73 days you can reverse engineer a 512-bit key.

So the higher key length you have, the more complicated it becomes to break SSL key. The majority of giant Web Companies use 2048 bit key, as below so why don’t we?


openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

It will generate a CSR which you will need to send to a certificate authority to sign it. Once you receive the signed certificate file, you can add them in httpd-ssl.conf file

SSLCertificateFile #Certificate signed by authority
SSLCertificateChainFile #Certificate signer given by authority
SSLCertificateKeyFile #Key file which you generated above

5.2 SSL Cipher

SSL Cipher is an encryption algorithm, which is used as a key between two computers over the Internet. Data encryption is the process of converting plain text into secret ciphered codes.

It’s based on your Web server SSL Cipher configuration the data encryption will take place.

So it’s important to configure SSL Cipher, which is stronger and not vulnerable.



Note: if you have many weak ciphers in your SSL auditing report, you can quickly reject them adding ! at beginning.

5.3 Disable SSL v2 & v3

SSL v2 & v3 has many security flaws, and if you are working towards penetration test or PCI compliance, then you are expected to close security finding to disable SSL v2/v3.

Any SSL v2/v3 communication may be vulnerable to a Man-in-The-Middle attack that could allow data tampering or disclosure.

Let’s implement apache Web server to accept only latest TLS and reject SSL v2/v3 connection request.


SSLProtocol –ALL +TLSv1.2

Once you are done with SSL configuration, it’s a good idea to test your Web application with online SSL/TLS Certificate tool to find any configuration error.

6. Mod Security

Mod Security is an open-source Web Application Firewall, which you can use with Apache.

It comes as a module which you have to compile and install. If you can’t afford a commercial Web application firewall, this would be a good choice to go for it.

In order to provide generic Web applications protection, the Core Rules use the following techniques:

6.1 Download & Installation

Following prerequisites must be installed on the server where you wish to use Mod Security with Apache. If any one of these doesn’t exist then Mod Security compilation will fail. You may use yum install on Linux or CentOS to install these packages.

Now, let’s download the latest stable version of Mod Security 2.7.5 from here

gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

cd modsecurity-apache_2.7.5

./configure –with-apxs=/opt/apache/bin/apxs


make install

Now this concludes, you have installed Mod Security module in existing Apache Web server.

6.2 Configuration

In order to use Mod security feature with Apache, we have to load mod security module in httpd.conf. The mod_unique_id module is pre-requisite for Mod Security.

This module provides an environment variable with a unique identifier for each request, which is tracked and used by Mod Security.

LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so

Mod Security is now installed!

Next thing you have to do is to install Mod Security core rule to take full advantage of its feature.

Latest Core Rule can be downloaded from following a link, which is free.https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

Now, let’s enable these rules to get it working with Apache Web server.

Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf

In above configuration, we are loading Mod Security main configuration file modsecurity_crs_10_setup.conf and base rules **base_rules/*.conf **provided by Mod Security Core Rules to protect Web applications.

You have successfully configured Mod Security with Apache!

Well done. Now, Apache Web server is protected by Mod Security Web application firewall.

6.3 Getting Started

Let’s get it started with some of the critical configurations in Mod Security to harden & secure Web applications.

In this section, we will do all configuration modification in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

We will refer **/opt/apache/conf/crs/modsecurity_crs_10_setup.conf **as setup.conf in this section for example purpose.

It’s important to understand what are the OWASP rules are provided for free. There are two types of rules provided by OWASP.

Base Rules – these rules are heavily tested, and probably false alarm ratio is less.

Experimental Rules – these rules are for an experimental purpose, and you may have the high false alarm. It’s important to configure, test and implement in UAT before using these in a production environment.

Optional Rules – these optional rules may not be suitable for the entire environment. Based on your requirement you may use them.

If you are looking for CSRF, User tracking, Session hijacking, etc. protection then you may consider using optional rules. We have the base, optional and experimental rules after extracting the downloaded crs zip file from OWASP download page.

These rules configuration file is available in crs/base_rules, crs/optional_rules and crs/experimental_rules folder. Let’s get familiar with some of the base rules.

6.3.1 Logging

Logging is one of the first things to configure so you can have logs created for what Mod Security is doing. There are two types of logging available; Debug & Audit log.

Debug Log: this is to duplicate the Apache error, warning and notice messages from the error log.

Audit Log: this is to write the transaction logs that are marked by Mod Security rule Mod Security gives you the flexibility to configure Audit, Debug or both logging. By default configuration will write both logs. However, you can change based on your requirement. The log is controlled in SecDefaultAction directive. Let’s look at default logging configuration in setup.conf

SecDefaultAction “phase:1,deny,log”

To log Debug, Audit log – use “log” To log only audit log – use “nolog,auditlog”To log only debug log – use “log,noauditlog” You can specify the Audit Log location to be stored which is controlled by SecAuditLog directive.

Let’s write audit log into /opt/apache/logs/modsec_audit.log by adding as shown below.


SecAuditLog /opt/apache/logs/modsec_audit.log

6.3.2 Enable Rule Engine

By default Engine Rule is Off that means if you don’t enable Rule Engine you are not utilizing all the advantages of Mod Security.

Rule Engine enabling or disabling is controlled by SecRuleEngine directive.


SecRuleEngine On

There are three values for SecRuleEngine:

Once Rule Engine is on – Mod Security is ready to protect with some of the common attack types.

6.3.3 Common Attack Type Protection

Now Web server is ready to protect with common attack types like XSS, SQL Injection, Protocol Violation, etc. as we have installed Core Rule and turned on Rule Engine. Let’s test few of them.

XSS Attack:-

You will notice Mod Security blocks request as it contains

  • Apache
    26 引用 • 31 回帖
  • 部署
    17 引用 • 267 回帖
  • 安全


    153 引用 • 803 回帖 • 561 关注

赞助商 我要投放

请输入回帖内容 ...