Apache Web Server Hardening

Status:	Published
Version:	1.3
Authors:	HTL QA
Applies to:	Core Services Version 3.1.3 with OpenSSL v1.0.1 or above

Apache Web Server Hardening

Introduction

The purpose of this FAQ is to indicate the Apache and PHP configuration changes that you can make within Core Services (mainly Version 3.1.3) to make your Supportworks installation more secure. Please note that all but one of these changes have been made by default in the Version 3.1.2 and 3.1.3 releases of Core Services, and all of them have been made in Version 3.1.4.

Please be assured that these changes will not adversely affect any default Core Services installation. Nevertheless, good practice dictates that you should apply all the changes on a test server before applying them to your live server, which will confirm to you that there is no unexpected behaviour.

Apache Configuration Changes

This section details the changes that you can make within the Apache configuration files httpd.conf and ssl.conf, whose default location is:

C:\Program Files\Hornbill\Core Services\SwHttpServer\conf\

Please note that all such changes will require a restart of the SwHttpServer service.

Enabling HTTPS

If HTTPS is not enabled on your Apache server, you should follow the instructions in this subsection to create an SSL certificate and apply that to your server. (Although both a client and server certificate/key will be created, only the server certificate/key is typically required. You will need the client certificate/key too only if you choose to create applications that require two way authentication.)

Note that the certificate created will be a self-certified one. Limited to data encryption only, it will not be a sign of a trusted server. For that, you should contact one of the certification authorities such as VeriSign, Thawte or Go Daddy, who will provide their own instructions for applying their trusted certificates.

To enable SSL, perform the following steps:

1. From the Windows Start menu, run a "cmd" prompt.
2. In the prompt window, change to the Apache server's \bin\ folder by entering the following:

   cd C:\Program Files\Hornbill\Core Services\SwHttpServer\bin

3. Enter the following commands:

   openssl genrsa 2048 > ca-key.pem

   openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem -config openssl.cnf

4. Enter the required information for your site (country code, state/province, locality/city, organisation, unit/department, Webmaster contact name and e-mail address).
5. Enter the following command:

   openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem –config openssl.cnf

6. Again, enter the required information for your site (country code, state/province, locality/city, organisation, unit/department, Webmaster contact name and e-mail address).
7. Enter the following commands:

   openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

   openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem –config openssl.cnf

8. For a third time, enter the required information for your site (country code, state/province, locality/city, organisation, unit/department, Webmaster contact name and e-mail address).
9. Enter the following command:

   openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

10. Once the keys have been created, open the httpd.conf file in a text editor.
11. Add a line containing the directive Listen 443 to Section 1 of the file (for example, under Listen 80).
12. Enable the loading of two relevant modules by removing the comment (# character) from each of the following lines in the "LoadModule" part of Section 1:

    LoadModule ssl_module modules/mod_ssl.so

    LoadModule deflate_module modules/mod_deflate.so

13. Save your changes to the httpd.conf file.
14. Copy the created certificates and keys to the appropriate folders under the \conf\ folder (normally ssl.crt and ssl.key).
15. If any Virtual Hosts exist that are to use SSL, you should add the necessary directives in a separate .conf file in the sub-folder \conf\sw\ rather than in httpd.conf itself to avoid overwriting during an upgrade. By default, any such file will be regarded as an extension to httpd.conf. Suitable directives for setting up Virtual Hosts for SSL might be as follows:

    <VirtualHost *:443>

    DocumentRoot "C:\Program Files\Hornbill\Core Services\SwHttpServer\htdocs"

    SSLEngine on

    SSLCertificateFile conf/ssl.crt/server-cert.crt

    SSLCertificateKeyFile conf/ssl.key/server-key.key

    </VirtualHost>

16. Similarly, any aliases you may wish to add should preferably be included in a .conf file under \conf\sw\.
17. Open the ssl.conf file in a text editor and add lines such as the following to indicate the paths to the created certificate(s) and key(s):

    SSLCertificateFile conf/ssl.crt/server-cert.crt

    SSLCertificateKeyFile conf/ssl.key/server-key.key

18. Save your changes in the ssl.conf file.
19. Restart the SwHttpServer service.

Disabling HTTP

In order to ensure that all data is encrypted between clients/browsers and server, you can disable HTTP once you have enabled SSL. To do this, open httpd.conf, comment out the Listen 80 directive and change all instances of :80 in uncommented lines to :443.

Avoiding Denial-of-Service (DOS) Attacks

The following subsections describe a number of techniques you can employ to reduce or eliminate the potential for DOS attacks on your system.

Modifying Timeout Settings

This value specifies the length of time the Apache server will hold a given connection open before force-closing it. The default is 300 seconds and should not be confused with the KeepAliveTimeout directive, which only applies to the time taken between two given requests from the same connection.

The default value of 300 seconds does provide the opportunity for DOS attacks that consist of simply opening a connection and not sending data. However, as the timeout would be reset after this time, the effect would only be temporary.

The timeout value should be reduced, based on your site's typical usage and performance. You do so by editing the existing directive in your httpd.conf file:

Timeout 300

See the following Web page for more details:

http://httpd.apache.org/docs/2.0/mod/core.html#timeout

Modifying Keep-Alive Settings

These values specify whether the server will hold open any subsequent connections and, if so, for how long. The effect of enabling keep-alives will be that the server holds connections open, for the time specified, after the request has finished serving data. Holding connections open takes resources and decrements the pool of threads available for processing requests, and keeping them open for too long (or at all) would provide a good entry point for DOS attacks. Whether or not you enable keep-alives and/or what you set as the actual keep-alive timeout value should depend on your site's typical usage and performance.

Note that you can also set a value for the MaxKeepAliveRequests directive, which dictates the maximum number of keep-alive requests that can be submitted per connection. By default, Internet Explorer is configured to make two active connections, whereas Firefox and Chrome both default to 30. However, these are configurable and other applications may make more. The more keep-alive requests the server can handle per connection, the faster requests to that connection will be served (there is no overhead for reconnection).

In order to configure these values, edit the existing directives in your httpd.conf file:

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTImeout 15

See the following Web page for more details:

http://httpd.apache.org/docs/2.2/mod/core.html#keepalive

Modifying the Limit to an HTTP Request Body

This setting specifies the total of number of bytes a client can send within an HTTP request before a forced disconnection occurs. The higher this limit is set to, the more disruption a DOS attack could cause. The value should be based on your site's typical usage and depends on whether you permit file uploads, for example.

In order to configure this limit, add the following directive in your httpd.conf file

LimitRequestBody size

where size should be the maximum expected size (in Kb) for requests.

See the following Web page for more details:

http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody

Modifying the Limit to an XML-based Request Body

This setting specifies the total of number of bytes a client can send within an XML request before a forced disconnection occurs. The higher this limit is set to, the more disruption a DOS attack could cause. The value should be based on your site's typical usage and depends on whether you permit file uploads, for example.

In order to configure this, add the following directive in your httpd.conf file

LimitXMLRequestBody size

where size should be the maximum expected size (in Kb) for requests.

A formal definition is to be found here:

http://httpd.apache.org/docs/2.2/mod/core.html#limitxmlrequestbody

Hiding Important Information

The following two subsections show how you can suppress the disclosure of information that could be useful to an attacker.

Limiting Disclosure of Header/Footer Information

These values control whether the Apache server will show a header/footer containing its name, version and other related information.

In order to hide the footer and limit the header to show the product only, you should edit the existing directives in your httpd.conf file:

ServerSignature Off

ServerTokens Prod

See the following Web pages for more details:

http://httpd.apache.org/docs/2.2/mod/core.html#serversignature

http://httpd.apache.org/docs/2.2/mod/core.html#servertokens

Avoiding Disclosure of Internal IP Addresses

This directive specifies whether the Apache server will auto-create/correct any entered URL using values created from the SERVER_NAME and SERVER_PORT values. If the directive's value is Off, the URL returned will be based on what the client has requested rather than on the internal server settings (which you may not wish to disclose).

In order to configure this, add the following directive in your httpd.conf file:

UseCanonicalName Off

See the following Web page for more details:

http://httpd.apache.org/docs/2.2/mod/core.html#usecanonicalname

Disabling SSL\Weak Ciphers and Mitigating BEAST Attacks and POODLE attacks

One way of ensuring that HTTPS requests are forced to use anything but TLSV1.2 is to include the following directive in the httpd.conf file:

SSLProtocol all -SSLv2 -SSLv3

In addition, to guard against BEAST attacks, you should include the following two lines in the same file:

SSLHonorCipherOrder On

SSLCipherSuite RC4-SHA:HIGH:!ADH

Disabling HTTP Track/Trace

HTTP Track and HTTP Trace were originally provided as a means for Web developers to debug applications/pages. However, they are very rarely (if ever) used and have instead become a friend of the attacker. The easiest way to disable both methods is to add a rewrite rule. This requires that the Mod_rewrite module be loaded, so, if it has not already been done, you should first uncomment (i.e. remove the # from) the following line in the httpd.conf file:

LoadModule rewrite_module modules/mod_rewrite.so

You should then add the following rewrite directives to each Virtual Host definition, as well as to the Server Root definitions:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

Allowing/Blocking Access from a Given IP Address or Domain

If you know where your users are supposed to be coming from (typically from an internal network only), then you can force Apache to only allow connections from either a given IP address or a given Domain. You can also reverse this to prevent a known annoyance (such as a spammer or a frequent abuser) from accessing the site. The necessary setting can be applied at either a Directory or Virtual Host level. For example, to configure Apache to only allow requests from example.com, we would add the following to our httpd.conf file:

Order deny,allow

Deny from all

Allow from example.com

The settings required are specific to each site and depend on where your users exist.

See the following Web page for more details:

http://httpd.apache.org/docs/2.2/howto/access.html

Running SwHttpServer in a Local Context

By default, SwServerService and all other Supportworks-specific services run in the context of the local system account. The most secure way of running the SwHttpServer service would be to create a local Windows account named (say) SwHTTPUser and then run SwHttpServer in the context of that SwHTTPUser account. This will ensure that the SwHTTPUser account can access the SwHTTPServer folders (using cacls) only with minimal rights.

Note that, once done, this will make the administration and maintenance of the server more difficult due to the restrictions.

PHP Configuration Changes

This section details the changes that can be made within the PHP configuration file php.ini, whose default location is:

C:\Program Files\Hornbill\Core Services\SwHttpServer\Bin\

Please note that all such changes will require a restart of the SwHttpServer service.

Hiding the PHP Version

The expose_php option line allows you to control whether PHP will show its version. To hide the version, turn exposure off as follows:

expose_php = Off

Disabling Error Reporting

If PHP generates an error, then the message shown can be used to identify what version is in place and may show details of paths/files that exist on the server. In order to prevent this, you should turn error reporting off as follows:

error_reporting = Off

display_errors = Off

Modifying Maximum Limits

In order to prevent users from stalling scripts with large file loads or starting a POST and then not sending any data, you can change any of the following limits:

max_execution_time = 30  ; Max script execution time
max_input_time = 60      ; Max time spent parsing input
memory_limit = 16M       ; Max memory used by one script
upload_max_filesize = 2M ; Max upload file size
post_max_size = 8M       ; Max post size

Note that the values you set will depend on your site's typical usage.

Disabling "Magic Quotes"

PHP provides an option to automatically quote strings containing apostrophes so that they are valid when parsed. However, this does not encourage developers to write secure scripts. Therefore, the option should be off by default and if it is not, then you should turn it off in each context as follows:

; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off

; Use Sybase-style magic quotes (escape ' with '' instead of \').
magic_quotes_sybase = Off

Useful Links

http://httpd.apache.org/docs/2.2/howto/access.html - How to control access to the server
http://httpd.apache.org/docs/2.2/misc/security_tips.html - List of other security tips and considerations