The attacks are well explained. I personally knew about Slowloris but didn’t about RUDY and post attacks.

Now the latest version of Apache mod_ssl (2.2) embeds an option to reactivate old way client renegociation :

SSLInsecureRenegotiation on

Check the official doc for more details. With this option activated, you can now safely upgrade openSSL and mod_ssl without breaking your clients. They should have done it from the begining, shouldn’t they ?

The next step will be to move on to the new protocol definitely, to solve for good the CVE-2009-3555 vulnerability. For that we have to wait for the browsers to support it.

Firefox has started to work seriously on it and we can expect some support in the next releases (some settings will be possible through about:config).

They even created a test site. This screenshot was taken from Google Chrome (5.0.366.2, openSUSE repo) which already has support for the SSL protocol :

At least, the IETF agreed on a fix as Marsh Ray informs us, though it will still take some weeks for the whole validation process to complete.

Moreover, as it requires both the servers and the clients to be patched, it will take months before the patches can be applied and one can have a working client authentification architecture. The longest will be the client side, of course, so I feel sorry for those who have a large park to manage.

As far as I am concerned, fortunately, I will just have a few browsers that I manage directly to update. Anyway, still more patience is needed !

I found a lot of interest reading it as I was already using ModSecurity – and I think anyone exposing an Apache web server should.
I was actually using it partially. It is not trivial to secure a web application, and the rule engine of ModSecurity is very powerful but it is also quite complex.

So this book was a good opportunity for me to dig into it further.

The book covers all topics : from the set-up to a real use-case.
The author explains how to write rules, how to deal with the performance impact, logging and gives us a range of various core rules to implement to get a good security basis.

The difficulty goes up progressively and the author doesn’t forget the beginners.
The set-up of the module is precisely described. All requirements are also explained and there are some good recalls about regular expressions, common attacks on systems, server and client sides, and other stuff like that.

After reading the book, I could harden my rules, reorganize and optimize them for better performance – something I hadn’t cared about before.

So I have nothing else to say but to recommend this book.
It is definitely a great handbook about ModSecurity that’s worth having next to you. The variety of configuration patterns makes it a reference.

Check it there. I also appreciated the availability of PDF version, so that I can carry it everywhere with my laptop and index it with Beagle.

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

• low security by deactivating client authentication on your server
• low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general ;)

PS 2 : bug reported on openSUSE bugzilla

ModSecurity is essential when it comes to secure any web site.

It will make the work of the attacker much harder and  it may save you even if your favorite dynamic pages have a security hole.
However, it must be configured wisely to be efficient. It is just a firewall that works at the application layer : you need to know the attacker point of view and the basics before writing any mod-security rules, otherwise at best it will useless (and at worst, it will kick legitimate traffic off).

So, stay tuned :  I will talk more about the ModSecurity stuff and publish a review about this book soon.

By default, Firefox 3 has a very annoying setting : it will prompt you with a box to select your certificate, every time the browser access to a file.

I quickly realized that there is not setting in the preference tab to change this behavior. That sucks, really !

Fortunately, it is possible to tweak it within the about:config page. Set the security.default_personal_cert entry with Select Automatically instead of Ask Every Time.

But what a dumb behavior !

It is like the alert page that Firefox displays every time a self-signed certificate is used. I am now wondering if the developers really understood well what a certificate is !

Setting Firefox properly for Client certificate

It is especially usefull if your website is dynamic, involving php, sql, javascript, etc. With such a complex environment, as you can never be sure that your website is not vulnerable or up-to-date enough, something like mod-security provides an interesting extra-security layer.

Due to license issues, mod-security is no more shipped with Debian – it was until Debian Sarge.

Fortunately, the Debian maintainer continue to provide some packages on his website.

So, the easy way to set up mod-security on your Debian system is to add this line in your /etc/apt/source.list file :

$ echo "deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/ etch/" >> /etc/apt/source.list

Then type in the usual sequence :

$ aptitude update && aptitude install libapache-mod-security2

You could also download the source from the official website.

Once it is done, comes the configuration part. The configuration is critical because any mistake on it will make it at best useless, or at worst blocking your website.
You have the choice between creating your rules from scratch or getting some ready made.
Creating your rules will require a lot of time and expertise in the http protocol, php, sql, and any other service that you offer with Apache.
That was not really my case, so I started to look for some ready made rules on google. I could not get good ones. Most of tutorial gives only some very basic and incomplete rules : useless. I found a good paper, notably containing some specific rules for WordPress, but the rules were written for mod-security v1 whereas it is now in its second version.
Oh, did I forget to tell you ? Most of the syntax was changed between the two versions !!! Not very nice, even if it was worth doing it.

Finally, I came to find a way with the rules provided by this website, Got Root ?. They provide quite up-to-date rules, with a delay of 30 days subscription-free, which is quite acceptable for what I want to do. After all, Php exploits and Sql injection technics don’t change every day.

The rules are also complete and spread over several files, one for each category in : generic rules, blacklist, usergents, proxies, rootkits…

We can fetch them with a little script. They suggest to add it as a cron job, but you should not, except if you don’t mind that your website becomes unavailable ! These rules always require testing, some of them may be broken or require customizing… be careful and always check what’s inside the rule files !

Here is the small script, modsec.sh, that I made to retrieve the rules and put them in the right directory :

#!/bin/sh

wget http://www.gotroot.com/downloads/ftp/mod_security/2.0/apache2/apache2-gotrootrules-modsec2.0-latest.tar.gz
if [ -e apache2-gotrootrules-modsec2.0-latest.tar.gz ]
then
tar -xzvf apache2-gotrootrules-modsec2.0-latest.tar.gz -C /etc/apache2/modsecurity/
fi
rm apache2-gotrootrules-modsec2.0-latest.tar.gz
/etc/init.d/apache2 restart

Make it executable and run it :

# chmod +x modsec.sh
$ ./modsec.sh

Now, let’s edit the /etc/apache2/apache2.conf file.

Just before these lines (probably at the bottom of the file) :

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

Add these :

#Turn the filtering engine On or Off
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Handling of file uploads
# TODO Choose a folder private to Apache.
# SecUploadDir /opt/apache-frontend/tmp/
SecUploadKeepFiles Off

# Maximum request body size we will
# accept for buffering
SecRequestBodyLimit 131072
# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072
# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288

SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0
# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

#should mod_security inspect POST payloads
#SecRuleScanPOST On

# by default log and deny suspicious requests with HTTP status 500
SecDefaultAction log,auditlog,deny,status:403,phase:2,t:none

#First, add in your exclusion rules:
#These MUST come first!
Include /etc/apache2/modsecurity/exclude.conf

#Application protection rules
Include /etc/apache2/modsecurity/rules.conf

#Comment spam rules
Include /etc/apache2/modsecurity/blacklist.conf

#Bad hosts, bad proxies and other bad players
Include /etc/apache2/modsecurity/blacklist2.conf

#Bad clients, known bogus useragents and other signs of malware
Include /etc/apache2/modsecurity/useragents.conf

#Known bad software, rootkits and other malware
Include /etc/apache2/modsecurity/rootkits.conf

#Signatures to prevent proxying through your server
#only rule these rules if your server is NOT a proxy
#Include /etc/apache2/modsecurity/proxy.conf

#Additional rules for Apache 2.x ONLY!  Do not add this line if you use Apache 1.x
Include /etc/apache2/modsecurity/apache2-rules.conf

As you can see, we just include the rule files we just downloaded. You can easily activate or deactivate some to fit your needs.

You will probably notice that there is a performance impact after activating mod-security – not so big to me, but it also depends on your traffic. It is up to you to optimize the number of activated rules to make it faster.

If some page appear to be blocked, check the /var/log/apache2/error.log for something like :

[Fri Jul 11 19:33:08 2008] [error] [client 192.168.222.21] ModSecurity: Access
denied with code 500 (phase 2). Match of "rx ^HTTP/(0\\\\.9|1\\\\.0|1\\\\.1|1\\
\\.2)$" against "REQUEST_PROTOCOL" required. [id "340000"] [msg "Bad HTTP Proto
col"] [severity "ALERT"] [hostname "www.phocean.net"] [uri "/"] [unique_id "72F
col"] [severity "ALERT"] [hostname "www.phocean.net"] [uri "/"] [unique_id "72F
mG38AAAEAACa@AVUAAAAA"]

The ID number of the blocking rule is given. Just grep to find the faulty rule and correct / deactivate it :

$ grep 340000 /etc/apache2/modsecurity

Regxp knowledge required ! :D