Monthly Archives: July 2008

Support for source port randomization in Vuurmuur

Posted on by

One of the workarounds for the current DNS problems is that servers introduce source port randomization.  So it’s time for you to patch your DNS server so it uses random source ports. If for some reason you are unable to do that, iptables can help. Michael Rash has a good write up of how that works here.

In Vuurmuur there is now a per rule option, that can be enabled for the SNAT, MASQ, PORTFW, DNAT and BOUNCE actions, called ‘random’. This passes the ‘–random’ option to the iptables rules Vuurmuur creates. Note that you need a recent distro for this. Debian Etch is too old, Ubuntu Hardy is fine. The new functionality is just released in Vuurmuur 0.5.74 alpha 6. Check it out!

*UPDATE 29/07/08* it turns out iptables/netfilter does not undo existing randomization so removed the text suggesting that.

Fixing noise on Ubuntu Hardy 8.04, aka setting max_cstate

Posted on by

Not security related at all, but it took me so much time to figure this out, I want to share this with the world!

I own a Lenovo Thinkpad T60 that I like very much. There is one annoyance, and that is that when on battery, the laptop produces a high pitched noise when idle. It turns out that this has something to do with the ACPI state. States of C3 and higher made my laptop produce the noise. In Ubuntu Gutsy 7.10 there was a simple solution. I could force the laptop to never use anything higher that C2. That was done like this:

echo “2” > /sys/module/processor/parameters/max_cstate

And everyone was happy! Noise gone, battery life still decent. All was good. Until I upgraded to Hardy. Hardy uses kernel 2.6.24, and for some reason the sysfs interface has been removed. So there is no way to set the max_cstate on the fly. See here for the bug report.

In theory the ‘processor’ module should be able to take an option ‘max_cstate=2’. But setting this option didn’t seem to work. It took some time to figure out why, but the reason is simple. The ‘processor’ module is in the initrd image, and is loaded before /etc/modprobe.d/options is inspected. Luckily, the solution is simple:

Add the following line to your /etc/modprobe.d/options file:

options processor max_cstate=2

Then update the initrd image using the following command:

sudo update-initramfs -u

The initrd image is now updated to include the option. Then reboot. Verify if it works:

$ cat /proc/acpi/processor/CPU0/power |grep max_cstate
max_cstate:              C2

Success! Again, no more noise…

Update 21st of March 2010 for Ubuntu Karmic 9.10. The solution for this for Karmic was posted by Markus in the comments below, I’m replicating it here for convenience. Thanks Markus!

Karmic introduces the new grub2 so there isn’t any menu.lst anymore. In grub2 some things (like default kernel options) are done in /etc/default/grub, so you have to edit this file:

sudo pico /etc/default/grub

search for a line GRUB_CMDLINE_LINUX=”” and change to (or add if it doesn’t exist):

GRUB_CMDLINE_LINUX=”processor.max_cstate=2″

press STRG+x and y to save and exit and execute the grub update:

sudo update-grub

After a reboot the max cstate should then be C2!

WordPress version 2.6 & ModSecurity

Posted on by

Today I updated my WordPress installation to version 2.6. The upgrade went smooth as usual. However afterwards I couldn’t login anymore because one of my ModSecurity rules was triggered at the login. Turns out the WordPress developers changed the use of the ‘redirect_to’ argument in wp-login.php. WordPress uses it to redirect the browser to some part of the weblog software after a successful login. Some time ago there used to be a vulnerability in WordPress as described here: http://www.securityfocus.com/archive/1/463291. To prevent exploitation on my box at the time I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(ht|f)tps?://”

This worked because WordPress only used relative paths as values for the ‘redirect_to’ argument. With 2.6 however, this has changed. WordPress now tries to redirect to a full URI. So the above rule needed an update. What I wanted is to adapt the rule so that it only allows the redirect to my own domain. So I created the following rule:

SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS:/^s*redirect_to$/ “^(?:ht|f)tps?://(.*)$” “chain,capture”
SecRule TX:1 “!@beginsWith %{SERVER_NAME}”

What it does is take the domain name from the ‘redirect_to’ variable and strip the leading http:// or https:// from it. Next, that is compared with Apache2’s SERVER_NAME variable. It is tested using ‘beginsWith’ so the rule can’t be bypassed using something like ‘redirect_to=http://evil.com/www.inliniac.net/’.

This way the logins work again and I still should be notified when someone tries this old (and patched) trick on me!