You want to keep your server safe. From a security point of view running a Web servers with applications gives hackers many ways to attack your server.  How can you protect your server from the hackers out there, and lazy coders who don’t write secure code and then let your server be attacked at the web application level?

When you start to look hard at Web servers, you can find that a lot of application on the web are very insecure. Whilst you can and should keep working to make things more secure, it is good to look at some backup options.

The first answer might be to look for a network firewall – but that’s just not going to work as most firewalls just open up the port 80, which is where web traffic goes. It is very hard to protect web traffic using your network firewall as it’s not really built to spot the type of attacks that attack websites, and particularly the ones that go for applications.

Enter ModSecurity

ModSecurity is a Web application firewall (WAF). Over 2/3s of attacks are now at the Web application level and you’re going to need all the help you can get making your website secure. ModSecurity gets you a high degree of protection quickly without having to change your existing server.

When I was testing the code in here I used a nice up to-date version of Unbutu. In this case I’ve got a fresh version of 10.4. If you are not using Ubuntu, I would suggest going to download it from http://www.ubuntu.com, it makes it much easier to install dependencies for this tutorial. That said, most of these will work with other forms of Linux. The install process for ModSecurity will obviously vary for non Debian-based Linux versions.

With a modern Web server it is common for most requests for marketing analyses to be logged very well. However, web traffic for application is a lot harder to log and web servers don’t handle it very well. ModSecurity gives you the chance to log everything, with the ability to mask sensitive data if required. It allows much deeper logging information.

In addition, ModSecurity can look at the live web traffic to stop attacks quickly and to act as a web intrusion detection tool. It can even start blocking requests that seem to be ‘unusual’ or ‘not-normal’. In the first suspicious and malicious requests are rejected, in the second requests that not from a set of known correct calls are rejected. It also have a rule engine which can quickly change the way it operates.

Pre-requisites

Under Ubuntu the ModSecurity install process is very easy, as it’s all within the apt-get system. To install it we just need to run the apt-get process.

sudo apt-get install libapache2-mod-security

Now, we need to make sure that the Apache server has enabled the mod-security system. This sometimes doesn’t work by default, but should normally be fine. You can’t cause any problem by running this anyway.

sudo a2enmod mod-security

Finally, restart the Apache server:

sudo /etc/init.d/apache2 force-reload

ModSecurity As A Reverse Proxy

This is a before and after graphic of how we want ModSecurity to operate:

As you can see from the diagram above, we are aiming to use ModSecurity as a reverse proxy. This means it sits between all inbound traffic and your Apache server, although it can also be used for other servers like IIS as well in a similar way. I have recently put an Apache reverse proxy like this together on IIS – you need to change the IIS port to be set to 8888, for example, and install Apache on port 80 and use ModSecurity and the Apache reverse proxy to map the requests across.

Why bother with a reverse proxy?

1.    All traffic goes through the web proxy – so you only have point to monitor
2.    Web Application Firewall – with little else done, a web proxy will create a new request from your existing request. This means you can do a large set of checks on the traffic.
3.    Higher speed – you can have the new server to use to cache content, deal with SSL traffic & compress outbound traffic
4.    Hiding your network – people from outside have little idea what is going with your network. Hackers have less information about the network. You can also change the network round quickly without anyone noticing.

There are a couple of caveats

1.    Additional complexity – your network is more complex and harder to maintain
2.    Single point of failure – if your reverse proxy crashes, your Web server goes down.

Configuring ModSecurity As A Reverse Proxy

Let’s complete the process of setup. The key to this is that we need to setup the mod_proxy & proxy systems on Apache. These are a very useful bit of kit which allow you put the actual Web server somewhere else altogether. This separation gives us a lot of power in terms of hiding and protecting the server which is doing the work.

First, make sure that we have the proxy installed for Apache:

sudo apt-get install libapache2-mod-proxy-html
installed

And that we have the modules enabled:

sudo  a2enmod mod-proxy
sudo  a2enmod proxy

Now – let’s make sure that we can use the reverse proxy: we have to edit /etc/apache2/mods-enabled/proxy.conf and change the ‘deny all’ to ‘allow all’ – so that we can use it for external requests. My proxy.conf now looks like this:

<IfModule mod_proxy.c>
#turning ProxyRequests on and allowing proxying from all may allow
#spammers to use your proxy to send email.

ProxyRequests Off

<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from all
#Allow from .example.com
</Proxy>

# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block

ProxyVia On
</IfModule>

Configuring ModSecurity

To get your mod_security installation fully working, you will need to create a base configuration file.
The recommended practice for this is to create a config file that is separate from your main httpd.conf file and add an Include directive pointing to your mod_security configuration file: /etc/apache2/sites-available/modsec.

This file has been based on the file here – /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal  - your version is likely to be different & you should check the difference between the files. Please note that my Web server in this case is at 192.168.1.2  :

<VirtualHost www.modsecurity.org>
# First, let's set up the reverse proxy
ProxyRequests Off
ProxyPass / http://192.168.1.2/
ProxyPassReverse / http://192.168.1.2/
<IfModule mod_security.c>
# Yes, we want to use mod_security
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Let's use this as the mod_security dir
SecUploadDir /tmp/
SecUploadKeepFiles Off

# Debug log
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0

# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

SecRequestBodyLimit 131072

SecRequestBodyInMemoryLimit 131072

SecResponseBodyLimit 524288

SecRule REQBODY_PROCESSOR_ERROR "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Failed to parse request body.',severity:2"

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}'"

# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched \
boundary.'"
</IfModule>
</VirtualHost>

Create a symlink to the config file
sudo ln -s /etc/apache2/sites-available/modsec /etc/apache2/sites-enabled/modsec

Please do not use this for a live version of ModSecurity – you need to be a little bit more careful that I’ve been in this short intro. For example, you should look at re-compiling apache so that you reduce the amount of un-needed code in the server.

Commonly Used Configuration Rules

At this stage, we have a basic ModSecurity system in place, so it is a good chance to look at some of the options in the configuration system. This is where the power of ModSecurity really comes into its own.

Firstly, some common settings you might want to look at:

#This is the security level from 0 -> 10. 2 is high enough for most systems.
SecDebugLogLevel 2

#Inspect the payloads of POSTs
SecRequestBodyAccess On

#This is a key line, which defines the default action to take. In this case,
#deny the request, log it and return status 406.
# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "phase:1,t:none,deny,status:500"

Block IP Range

You are having problems with someone from a specific IP causing trouble:
SecRule “REMOTE_ADDR” “^12.42.51.$”

This actually blocks everyone from the subnet 12.42.51.xxx – which might be the area that is causing you problems. Note that as for usual regex, ^ matches the start of the line, so this doesn’t match 112.42.51.12

Block Spammers

If you have a blog site, I’m sure you get very annoyed by people putting content on your site that you really don’t want. ModSecurity is perfect to block this, just get the list of keywords you are trying to block with the POST payload.
SecRule REQUEST_METHOD “POST” chain
SecRule REQUEST_BODY “viagra|mortgages|spam”

XSS Protection

This is a weaker form of XSS protection, just stopping javascript script being past to the server. It does let all other tags go through

SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "<( |\n)*script"

Block all XSS attack sites and stop all tags being sent to the server. Note that this is really going stop all tags and this might have an impact on your site. Be careful when using these commands, and make sure to test them, as they could end up blocking valid user traffic.

SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "<(.|\n)+>"

SQL Injection Protection Patterns

These rules detect malicious SQL commands embedded in an HTTP request, and blocks exploitation of your SQL database through your Web application. This is a simple solution which should block most attacks, but you should look at more complex solutions if you are really being targeted.

SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "delete[[:space:]]+from"
SecRule REQUEST_BODY "insert[[:space:]]+into"
SecRule REQUEST_BODY "select.+from"

Stop Path Traversal Attacks

A  common attack is to use directory traversal commands embedded within a HTTP request to look at files outside of your Web server’s allowed directories on the Web server’s file system. This rule stops all directory traversal attacks.

SecRule "\.\./"

Stop Spammers Sending Emails

Sometimes you can find that spammers are injecting emails addresses and sending emails from your server. This bit of code is one way to stop them getting through and exploiting email functionality that a Web application may provide.

SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4} \
\,\x20[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4} \
\,[A-Za-z0-9._%-]+@[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4} \
\,\x20[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z{2,4}"
SecRule REQUEST_BODY "bcc:|cc:|bcc%3A|cc%3A" t:lowercase,chain
SecRule REQUEST_BODY "[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4} \
\,[A-Za-z0-9._%-]+%10[A-Za-z0-9._%-]+\.[A-Za-z]{2,4}"

ModSecurity is a great system for controlling access to your server. That said, it is a constant battle to close the holes that are left open by poorly written code and servers. Keep all of your systems up to date. Make sure you test all your servers with and without ModSecurity – it is common to find that it can break servers, especially when you are developing code.