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 Vulnerabilities

Apache server

The Apache Web Server

The Apache HTTP Server is a web server application based on NCSA HTTPd. Development of Apache began in early 1995 after work on the NCSA code stalled, and it quickly overtook HTTPd as the dominant web server, and has been the most popular web server in use since April 1996. As of June 2013, Apache was estimated to server 54.2 percent of all active websites, so if you come across a website, there’s a better than even chance that it’s hosted by an Apache server (this site is).

The Apache server supports a variety of features. Many of these features are implemented as compiled modules which extend the core functionality. Some common language interfaces support Perl, Python, Tcl, and PHP. Other features include Secure Sockets Layer and Transport Layer Security support. Because the source code is freely available, anyone can adapt the server for specific needs, and there is a large public library of Apache server add-ons.

Although the main design goal of the Apache server is not to be the fastest web server, Apache does have performance similar to other high-performance web servers. Instead of implementing a single architecture, Apache provides a variety of MultiProcessing Modules (MPMs) which allow Apache to run in a process-based, hybrid (press and thread) or event-hybrid mode, to better match the demands of each particular infrastructure. The multi-threaded architecture implemented in Apache 2.4 should provide for performance equivalent or slightly better than event-based webservers.


Apache Server Vulnerabilities

All software systems have the same general types of vulnerability and Apache is no different. It can be adversely affected by any one of the following problems: [1] poor application configuration; [2] unsecured web-based code; [3] inherent Apache security flaws, and [4] fundamental OS vulnerabilities.

Apache has many default settings that require modification for secure operation. Nearly all configuration information for Apache Web server exists within the httpd.conf file and associated Include files. Because many configuration options exist within these files, it can be easy to make configuration errors that expose the application to attack.

The second manner in which vulnerabilities are exposed is via poorly implemented code on the Apache server. Often, Web developers are far more concerned with business functionality than the security of their code. For instance, poorly written dynamic web pages can be easy denial of service (DoS) targets for attackers, should coded limitations be absent from back-end database queries. Simply publishing confidential or potentially harmful information without authentication can provide enemies with ammunition for attack. For these reasons, you must review and understand not only the Apache application but the information and functionality being delivered via the system.

As with Microsoft’s IIS server, vulnerabilities can exist within the Apache server’s application code itself. There are many means by which hackers can breach or disable an Apache system, such as:

  • Denial of Service (DoS)
  • Buffer overflow attacks
  • Attacks on vulnerable scripts
  • URL manipulation

Occasionally, Apache security flaws are discovered and announced by Apache or by various security groups. The Apache development team is typically quick to respond and distribute patches in response to such events. For this reason, it is critical that you be vigilant in your attention to security newsgroups and to Apache’s security advisory site.

Another source of vulnerability within an Apache web server could occur as a result of foundational security flaws in the OS on which Apache is installed. Apache can be run on just about any OS. You should be very familiar with the specific security vulnerabilities for any OS on which you run Apache.

In the next article, we will discuss the merits of patching and securing the OS as a means of securing your Apache server.

External Links:

The official Apache web site

Apache HTTP Server at Wikipedia

The official Apache Software Foundation web site

Apache web server resource site

© 2013 David Zientara. All rights reserved. Privacy Policy