ModSecurity: Part Two

ModSecurity

Configuring site proxies in ModSecurity under pfSense 2.1.5.

In the previous article, we covered installation of ModSecurity and began configuration. In this article, we continue our look at configuration.

We had covered the first five settings on the “Proxy Server Settings” tab. The next setting, the “Use mod_mem_cache” checkbox, enables mod_mem_cache, which stores cached documents in memory. In the next edit box, “mod_mem_cache memory usage”, you can set the memory usage in megabytes. The next setting, the “Use mod_disk_cache” checkbox, implements a disk-based storage manager if checked. The memory usage (in KB) can be specified in the next edit box.

The next setting is to limit the number of POSTS accepted from the same IP address. The purpose of this setting is to help prevent the effects of a Slowloris type of attack. The Slowloris tool provides a means of executing a DoS attack on a web server by not sending a complete set of HTTP request headers. The request will omit the final carriage return/line feed (CRLF) that tells the destination web server that the request has completed so the web server dutifully waits for more request data until it reaches its timeout setting. Now Slowloris can keep it in perpetual waiting mode by sending new requests just before the web server’s timeout setting is reached. Obviously, one of the ways of mitigating the effects of such an attack is to limit the number of POSTS allowed from a single IP address, and this is the objective here.


The next edit box configures the maximum request body size ModSecurity will store in memory. Anything over this limit will be rejected with status code 413 Request Entity Too Large. The next edit box sets the maximum request body size ModSecurity will accept for buffering. The default value is 128 KB.

The next check box, “Enable mod_security protection”, enables mod_security protection for all sites being proxied. The dropbox below that configures the audit logging engine. Possible values are: “On” – log all transactions by default; “Off” – do not log transactions by default; “RelevantOnly” – by default, only log transactions that have triggered a warning or error, or have a status code that is considered to be relevant. The last two edit boxes allow you to specify a custom ErrorDocument and to enter custom ModSecurity rules.

ModSecurity: Configuring Site Proxies

The next tab is “Site Proxies”. By clicking on the “plus” sign on the right side of the page, you can add to the list of sites that will use the ModSecurity Apache proxy. Once you do, you can enter the site name, site webmaster e-mail address, and protocol (HTTP or HTTPS). If you specify HTTPS, then you must specify the “Certificate File”, “Certificate Key File”, and “Certificate Chain File” next. If the “Preserve Proxy hostname” check box is checked, it will pass the “Host:” line from the incoming request to the proxied host instead of the backend IP address. At “Primary site hostname”, you can enter the fully qualified domain name (FQDN) for the website. Finally, you can also specify backend web servers for this site, as well as additional site hostnames.

The third tab, “Logs”, allows you to view the Apache ModSecurity proxy server logs. Pressing the “Clear log” button deletes the log.


External Links:

Mitigating Slow HTTP DoS Attacks at blog.spiderlabs.com – This blog contains a lot of useful information about computer security, especially ModSecurity

Slowloris HTTP DoS – official site for the Slowloris tool

ModSecurity Reference Manual

ModSecurity: Part One

ModSecurity

Configuring settings in ModSecurity under pfSense 2.1.5.

ModSecurity is a open source toolkit for real-time web application monitoring, logging, and access control. It supplies an array of request filtering and other security features to the Apache HTTP Server, IIS, and NGINX. Its capabilities, among other things, include the following:

  • ModSecurity gives you access to the HTTP traffic stream, in real-time, along with the ability to inspect it. This allows you to do real-time security monitoring. ModSecurity also enables you to track system elements over time and perform event correlation.
  • ModSecurity allows you to do virtual patching, a concept of vulnerability migration in a separate layer, where you get to fix problems in applications without having to touch the applications themselves. Virtual patching is available to applications that use any communications protocol, but it is particularly useful with HTTP, because the traffic can generally be well understood by an intermediate device.
  • ModSecurity also allows you to do full HTTP traffic logging. Web servers traditionally do very little when it comes to logging for security purposes; they typically log very little by default, and even with some tweaking, in many cases they do not give you everything you need. ModSecurity gives you the ability to log anything you need, including raw transaction data.
  • ModSecurity allows continuous passive security assessment, a variation of real-time monitoring which can detect traces of many abnormalities and security weaknesses before they are exploited.
  • ModSecurity allows for attack surface reduction, in which you selectively narrow down the HTTP features you are willing to accept, and can do so directly, or through collaboration with other Apache modules.

ModSecurity was designed to be flexible, with a powerful rule language which allows you to do exactly what you need it to do. It also does not interact with a transaction unless you tell it, which leaves the decision-making to you.


There are two deployment options for ModSecurity: embedded and reverse proxy. Embedded involves adding ModSecurity to Apache, which is often a good choice for those who already have their architecture laid out and do not want to change it. Reverse proxy involves installing a dedicated Apache reverse proxy with the ModSecurity module enabled. This is a good option for security practitioners who prefer having a separate security layer. In addition, the standalone reverse proxy will have resources dedicated to it, and you will be able to have more complex rules. One of the disadvantages of this approach is that you will have a new point of failure on your network. In this article, we will cover installation and configuration of ModSecurity under pfSense, which is a reverse proxy deployment.

ModSecurity Installation and Configuration

To install ModSecurity, navigate to System -> Packages, and on the “Available Packages” tab, scroll down to “Proxy Server with mod_security“. Press the “plus” button on the right side of the item to install ModSecurity, and on the next page, press “Confirm” to confirm installation. ModSecurity should be installed within a few minutes. To enable ModSecurity, navigate to Status -> Services, find “apache_mod_security” on the list of services, and press the “Start Service” button (it should look like a Play button). Now there should be a new item on the “Services” menu called “Mod_Security+Apache“.

There are three tabs for ModSecurity settings in pfSense: “Proxy Server Settings“, “Site Proxies“, and “Logs“. Under “Proxy Server Settings“, there are several settings relevant to configuring the web server proxy. You can enter the site administrator’s e-mail address at “Global site E-mail administrator“. You can enter the server’s hostname at “Server hostname” (or leave it blank to bind to all IP addresses on the local network). You can specify the port the proxy server will listen on at “Default Bind to port” (leave it blank to bind to 80).

The next setting is “Additional Addresses“. Here, you can specify additional IP addresses/ports to which the proxy can bind. If you need to specify more than one address, press the “plus” button on the right side to add more.

In the next article, we will continue our look at ModSecurity configuration.


External Links:

The official ModSecurity site

 

Apache Server Hardening: Part Four (httpd.conf)

httpd.confIn the previous article, we looked at compiling and installing Apache and discussed the benefits of mod_security. In this article, we will cover httpd.conf configuration.

httpd.conf File Configuration

The Apache web server stores all its configuration data in the httpd.conf file located in the $[ApacheServerRoot] directory, which is, in our example, /usr/local/apache. The httpd.conf file includes many directives that can be categorized into the following sections:

  • Server Directives
  • User Directives
  • Performance/Denial of Service directives
  • Server Software Obfuscation Directives
  • Access Control Directives
  • Authentication Mechanisms
  • Directory Functionality Directives
  • Logging Directives

Not all directives play a significant role with regard to security. In this article, we will discuss the directives that impact the security of your Apache server. Furthermore, because we disabled a lot of functionality at compile time, some directives that would normally be dangerous do not need to be removed, since they were not added into the compiled Apache binaries. There may also be other configuration files, called Include files, associated with the httpd.conf file. Since we have enabled mod_security, there is a long list of potential configurations to make in an Include filled called modsecurity.conf, which is usually located in the $[ApacheServerRoot]/conf directory.


In this section, I included the modsecurity.com recommended mod_security configuration. For more information about configuring this file, refer to the mod_security documentation.

Recommended modsecurity.conf file:

# Turn ModSecurity On
SecFilterEngine On

# Reject requests with status 403
SecfilterDefaultAction “deny.log.status.403”

# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecfilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255

# Server masking is optional
# SecServerSignature “OurServer”

SecUploadDir /tmp
SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# You normally won’t seed debug logging
SecFilterDebugLevel 0
SecFilterDebug logs/modsec_debug_log

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply “text/html” as Content-Type
SecFilterSelective REQUEST_METHOD “|^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Type \
“|(^application/x-222-form-urlencoded$|^multipart/form-data;)”

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD *^(GET|HEAD)$” chain
SecFilterselective HTTP_content-Length “!^$”

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD “^POST$” chain
SecFilterSelective HTTP_Content-Length ‘^$”

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding “!^$”

There are a couple directives you must configure in the httpd.conf file to ensure that the Apache web server runs using the unprivileged user account we established earlier, among other things. Inspect your httpd.conf file to verify that the following statements appear as show in the following. Recall that we decided to run Apache as wwwusr:wwwgrp.

User wwwusr
Group wwwgrp

Also, configure the serverAdmin directive with a valid alias e-mail address such as the following:

ServerAdmin hostmasteryoursecuredomain.com

This will provide a point of contact for your customers, should they experience problems with your site.

Performance-Tuning Directives in httpd.conf

there are a number of performance-tuning directives in the Apache httpd.conf file. As a security professional, you should interpret those directives as DoS prevention statements, since they control resource allocation for users of the Apache server. The following directives control the performance of an Apache server:

  • Timeout: Configures the time Apache waits to receive GET requests, the time between TCP packets for POST or PUT requests, or the time between TCP ACK statements in responses. The Apache default is 300 seconds (3 mintues), but you might want to consider reducing this timer to 60 seconds to mitigate DoS attacks.
  • KeepAlive: Configures HTTP1.1-compliant persistency for all web requests. By default, this is set to On and should remain as such to streamline web communication.
  • KeepAliveTimeout: Determines the maximum time to wait before closing an inactive, persistent connection. Here we will keep this value att the default of 15 seconds, since raising it can cause performance problems on busy servers and expose you to DoS attacks.
  • StartServers: Designates the number of child processes to start when Apache starts. Setting this value higher than the default of 5 can increase server performance, but use care not to set the value too high, because doing so could saturate system resources.
  • MinSpareServers: This setting, like the MaxSpareServers setting, allows for dynamic adjustment of Apache child processes. MinSpareServers instructs Apache to maintain the specified number of idle processes for new connections. This number should be relatively low except on very busy servers.
  • MaxSpareServers: Maintains Apache idle processes at the specified number. Like MinSpareServers, the value should be low, except for busy sites.
  • MaxClients: As its name implies, this setting determines the maximum number of concurrent requests to the Apache server. We will leave this as the default value of 256.

Once you’ve finished editing this section of your httpd.conf, you should see something similar to the following:
Timeout 60
KeepAlive On
KeepAliveTimeout 15
StartServers 5
MinSpareServers 10
MaxSpareServers 20
MaxClients 256

By default, Apache informs web users of its version number when delivering a 404 (page not found) error. Since it is good practice to limit the information you provide to would-be hackers, we will disable this feature. Recall that we already altered the Apache server signature and that we installed mod_security. Both of these actions should be enough to obfuscate our server because they both alter the default behavior. If you would like to turn off server signatures completely, you can always set the ServerSignature directive to Off and the Server tokens to Prod. this will disable Apache signatures entirely.

The Apache web server includes mechanisms to control access to server pages and functionality. The statement syntax is part of the directive and is fairly straightforward: you specify a directory structure, whether default access is permitted or denied, and the parameters that enable access to the directory if access is denied by default. There are many options for fine-grained control that you should learn by reading the Directory Directive section of the Apache Core Features document in the current version of the Apache documentation.

Regardless of the access you provide to your customers, you should secure the root file system using access control before placing your server into a production environment. In you httpd.conf file, you should create a statement in the access control directives area as follows:

<Directory />

Order, Deny, Allow
deny from all

</Directory>

This statement will deny access to the root file system should someone intentionally or accidentally create a symlink to /.

In the next article, we will discuss further hardening our Apache server using authentication mechanisms.

External Links:

The official Apache website

Apache Server Hardening: Part Three

Apache server hardeningIn the previous article, we discussed configuring the underlying OS and download and verifying Apache. After downloading and verifying the Apache source code, you’ll need to do some research to understand what options you want to compile into your web server. There are many modules, such as mod_access and mod_ssl, that can be added into your server to provide additional functionality and security. A full list of Apache Foundation-provided modules can be found at the Apache web site. When choosing modules, be sure you select only what you need. Compiling extra, unnecessary modules will only result in a less secure, slower web server.

You should use caution in enabling and disabling services at compile time. Before you do so, determine the dependencies of your web server code. Failure to understand what services you require to operate could result in loss of critical functionality. It might be prudent to test your configuration in a lab environment before disabling services on a production server.


Once you’ve decided which modules and configurations to use, you should accomplish one final task before building your software. Obscure the Apache version information located in the ap_release.h file located in the $[ApacheSrcDir]/include directory. To do so, use vi, gedit, or the editor of your choice and alter the following lines to change the Software Vendor (Apache Software Foundation) information:

#define AP_SERVER_BASEVENDOR “Apache Software Foundation”
#define AP_SERVER_BASEPRODUCT “Apache”

In general, you’ll need to perform three steps to compile and install your Apache Web server, as follows:

  1. From the $[ApacheSrcDir] directory, run ./configure.
  2. after configuring source, run ./make to compile the software.
  3. After compiling the software, run ./make install to install the Apache web server.

During the first step, you’ll decide what is added to the Apache server at compile time.

Add/Remove Module name Purpose
Remove Status Provides potentially dangerous information via server statistics web page
Remove Info Provides potentially dangerous configuration information
Remove Include Provudes server-side include (SSI) functionality
Remove userdir Permits users to create personal homepages in ~user home directories
Add mod_ssl Provide cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
Add mod_log_forensic Increases granularity of logging to forensic levels
Add mod_unique_id Required for mod_log_forensic module

mod_security, a third-party Apache module available from www.modsecurity.org, provides application firewall intrusion protection and prevention. To enable mod_security, you must download and compile the software into the Apache web server. Adding mod_security increases the secure operation of your Apache web server and adds functionality including, but not limited to, the following:

  • HTTP protocol awareness
  • Anti-evasion technique prevention such as URL encoding validation and URL decoding
  • Enhanced audit logging
  • Bult-in chroot functionality
  • Buffer overflow protection
  • HTTPS filtering

We will enable mod_security in our example because it adds so many security features to our system. Once you have downloaded mod_security source from the download page of the mod_security website, perform the following steps as root:

cd $[modsecuritySrcDir]/apache2

mkdir -r $[ApacheSrcDir]/modules/security

cp mod_security.c Makefile.in config.m4 \ $[ApacheSrcDir]/modules/security

cd $[ApacheSrcDir]

./buildconf

Now mod_security appears like other Apache modules. When we compile Apache, we will enable it using the command -enable-security. There are many options to consider in configuring the Apache source code for compilation. To view a list of options, issue the command ./configure –help from the $[ApacheSrcDir] directory.

After successfully configuring the source code, proceed with running make and make install. You will see a message indicating successful completion of building and installing Apache. Now that we have successfully installed the Apache web server software, we will proceed to the next step: configuring the httpd.conf file for secure operation. We will cover that in the next article.

External Links:

The official Apache website

The official ModSecurity website

© 2013 David Zientara. All rights reserved. Privacy Policy