Apache Web Server Hardening
| Status: | Published |
|---|---|
| Version: | 1.4 |
| 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.
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:
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 OnMaxKeepAliveRequests 100KeepAliveTImeout 15
See the following Web page for more details:
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:
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:
Hiding Important Information
The following two subsections show how you can suppress the disclosure of information that could be useful to an attacker.
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 OffServerTokens Prod
See the following Web pages for more details:
- http://httpd.apache.org/docs/2.0/mod/core.html#serversignature
- http://httpd.apache.org/docs/2.0/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:
Enabling/Forcing SSL Version 3
SSL Version 3.0 was released in 1996 to resolve the known vulnerabilities associated with SSL Version 2.0. In order to ensure that any HTTPS request is forced to use SSL Version 3, you will need to edit the ssl.conf file and replace the existing SSLProtocol and SSLCipherSuite directives with the following (or add one or the other if absent):
SSLProtocol -all +SSLv3 +TLSv1SSLCipherSuite SSLv3:+HIGH:+MEDIUM
- Note that the above should only be used if your customers\analysts accessing the Web Client or Web Self Service Module are suing IE6. This is open to the CVE-2014-3566\Poodle and not recommended.
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 OnSSLCipherSuite 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 onRewriteCond %{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,allowDeny from allAllow 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.0/misc/security_tips.html - List of other security tips and considerations