Nice demo there.
Author Archives: phocean
waf00f
waf00f is another nice fingerprinting tool.
It is a good complement to a tool like httprint. It is able to detect Web Application Firewalls.
Its output can help you to determine the trust you can have in what httprint or any other web server fingerprinting tool found out.
Check it there.
ModSecurity 2.5 review
I finished reading the ModSecurity 2.5 book, written by Magnus Mischell and published by Packt Publishing.
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.
Dovecot LDA vs Procmail
I have a mail server configuration based on Postfix for the smtp, Dovecot for the imap and virtual users receiving e-mails in maildir boxes.
I am also using Amavis and Spamassassin for content filtering.
I am not going now to describe this configuration, I think there are already a lot of very good tutorials about it all over the web. Moreover, the openSUSE maintainers made such a configuration quite easy : a sensible part of the work just consists in commenting out some line in the configuration files.
However, with the basic setup, I had an issue with permissions : all e-mails delivered by Postfix were created with permissions set to 600.
A typical use case with which I got into trouble was spam learning, done with a cron script with a dedicated account (“vscan”, you don’t want to execute such a script with root, right ?).
In that case, what I need is files to be created with permissions 660.
It seems easy and rather obvious at first, but actually there is not such a setting in Postfix.
Actually, it is not really the job of the MTA to do it, so in the case of Postfix it doesn’t bother with the transmission of such a parameter.
Then, I tried to use Procmail and set UMASK in /etc/procmailrc, but this just didn’t have any effect.
After searching and trying in vain a couple of hours, I found out that Dovecot can also deliver e-mails from the MTA to the maildir with Dovecot LDA.
So I tested it out. The configuration is pretty straightforward.
Add the line in bold to the virtual user configuration in /etc/postfix/main.cf :
[...] virtual_mailbox_domains = domain.com virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /home/vmail virtual_minimum_uid = 100 virtual_gid_maps = static:1002 virtual_uid_maps = static:1001 virtual_transport = dovecot [...]
Now, add these lines in /etc/postfix/master.cf :
[...] # Dovecot LDA dovecot unix - n n - - pipe flags=DRhu user=vmail argv=/usr/lib/dovecot/deliver -d ${recipient} [...]
Finally, configure /etc/dovecot/dovecot.conf with these sections :
[...] protocol lda { # If you wish to use plugins you need to specify plugin directory # For example quota enforcing is implemented by plugin module_dir = /usr/lib/dovecot/modules/lda # Address from LDA should send MDNs like out of quota postmaster_address = postmaster@domain.com # UNIX socket path to master authentication server to find users. auth_socket_path = /var/run/dovecot/auth-master } [...] auth default { [...] socket listen { master { # Master socket provides access to userdb information. It's typically # used to give Dovecot's local delivery agent access to userdb so it # can find mailbox locations. path = /var/run/dovecot/auth-master mode = 0660 user = vmail group = vmail } client { # The client socket is generally safe to export to everyone. Typical use # is to export it to your SMTP server so it can do SMTP AUTH lookups # using it. path = /var/run/dovecot/auth-client mode = 0660 } } } [...]
And that’s all !
Restart Postfix and Dovecot, check the log to ensure that everything works fine.
Now all new mails should come out in the maildir folder with permissions set to 660.
Definitely, in my opinion, Dovecot LDA is the way to go : simple and extensible. Good bye Procmail and your cluttered configuration file.
Nessus 4.2
Nessus 4.2 is out.
I tried it out and I must say that the new UI is great. I am not a big fan of Flash and I regret this choice. However, the design is excellent, all options are accessible in a logical way. Instead of spreading over the options like it used to be, they come to you in the right order.
I also appreciate that the server and the client set-up are now unified thanks to the web interface (you can access it from localhost or from the network indifferently).
The report section has also been greatly improved.
So, if you were already an Nessus user, it is worth upgrading.
Talking about the set-up, there is an up-to-date package for openSUSE (of course, there are a lot less dependencies than before).
OpenSSL : CVE-2009-3555 security fix and mod_ssl client authentication breakage
A security advisory on OpenSSL has recently been published. Details are there and there.
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