Category: Networks and Firewalls

Maintenance pages status codes and Lighttpd

I’ve noticed a few very broken maintenance page Lighttpd config examples around, including the one on the mod_magnet documentation page. They all manage to display the maintenance page ok, but they return a HTTP 200 status code to the client, rather than the more appropriate HTTP 503 code.

As with all 500 status codes, the 503 code is an error code but it signifies a temporary error. The client should try again later (in fact you can specify how much later using the Retry-After header).

A 200 code tells the client everything is normal and OK. So the user gets your nice maintenance page telling them of a temporary outage, whereas their browser gets told that everything is fine. Now this might not be a problem for a user, but if the client is a search engine or a caching proxy then it will assume the maintenance page is the new valid content for the request.

If the Google crawler hits your site when you have the maintenance page up, it will update its search index with your “we’re down for now” message, rather than your cash prizes blog content. Your page rank will drop, your fat Adsense cheque will diminish and you’ll have to go back to your regular nine to five job in the city with people you don’t like in clothes you hate wearing.

So, as you can see, it’s important to return the correct status code. Here’s how to do it with Lighty and mod_magnet:


IPSEC VPN problems upgrading to Ubuntu Edgy

I upgraded my home gateway firewall to Edgy today in the hope of fixing some SATA problems I’ve been experiencing. The new Edgy kernel might help – we’ll see.

Anyway, it went pretty well. Two runs (?) of apt-get dist-upgrade -u, a reboot and there I was.

Unfortunately I had two problems with my Openswan IPSEC VPNs. I’m not so sure if these count as bugs. I’ll be investigating further and reporting if so. Anyway, techie details follow…

TCP, NAT and 2MSL mismatch

We have a client that connects over the NHS internal network to a server hosted at our site. We have lots of clients like this, but these are slightly different because they NAT all their machines to one IP before it gets to us.

Recently they complained about connection problems and after lots of investigation we managed to get a packet capture of the problem (IPs changed of course):

 1  0.00 -> TCP 2268 > 80 [SYN]
 2  0.00 -> TCP 80 > 2268 [SYN, ACK]
 3  0.01 -> TCP 2268 > 80 [ACK]
 4  0.08 -> HTTP POST
 5  0.24 -> TCP 80 > 2268 [ACK]
 6  0.23 -> HTTP Continuation
 7  0.24 -> HTTP HTTP/1.1 200 OK 1365
 8  0.24 -> HTTP Continuation
 9  0.24 -> TCP 80 > 2268 [FIN, ACK]
10  0.29 -> TCP 2268 > 80 [ACK]
11  0.31 -> TCP 2268 > 80 [FIN, ACK]
12  0.31 -> TCP 80 > 2268 [ACK]
13  0.34 -> TCP 2268 > 80 [ACK]
14 68.26 -> TCP 2268 > 80 [SYN]
15 71.18 -> TCP 2268 > 80 [SYN]
16 77.13 -> TCP 2268 > 80 [SYN]
17 98.25 -> TCP 2268 > 80 [RST, CWR]


netfilter ip_conntrack_ftp and tls

Here I am attempting to connect to a server using lftp wondering why the firewall is blocking the incoming data connections, even though ip_conntrack_ftp has been working for years.

lftp supports tls, and so does the server I’m connecting to. This means the control connection is encrypted, so the netfilter ftp connection tracker can’t peek inside the packets to find out which ports to open up to allow the data connections. DUH. Ftp sucks.

Anyway, the only way I found to disable tls support in lftp is to add the following line to ~/.lftp/rc:

set ftp:ssl-allow false

Windows popup spam

Whilst closely watching the traffic to a server here at work (I had a good reason, I don’t just find it fun) (yes I do) I noticed a firewall batting away a bunch of incoming Microsoft Messenger Service NetrSendMessage. These are UDP packets destined for port 1026. The contents of the messages seem to be spyware and spam tricks. “Your system needs updating, click here to purchase the patch” etc.etc.

I’ve not come across this before, but it seems to be wide spread. In 2 hours I collected over a dozen to one particular host, all from different source IPs and nearly all with different messages and urls in them. Here are some excerpts, notice that as URLs aren’t clickable in message boxes they have to leave instructions to type the url in.

UPDATE: For all the non-techies, these messages are NOT the result of a virus or worm or anything like that. They are just network messages sent over the internet by scammers, a bit like spam. You can safely ignore them. If you want them to go away, install some firewall software or follow the instructions by Manimo to turn off the messaging service.


Black Hat, Amsterdam

I leave for Amsterdam on Wednesday where I’m attending the Black Hat Briefings. I was at DefCon in Las Vegas a few years ago so I’m interested to see what the BHB are like in comparison. I hope it’s not just a big ugly advertis-a-thon. I’m there for a few days courtesy of work and will have photies to post when I get back I expect.

My new Laptop arrived today too (not got it in my hands though). The ickle IBM Thinkpad X40 is very portable, but I’ve been using it for more of a desktop replacement than a portable troubleshooter, hence the new Viao one. Big 17inch widescreen LCD, crazy CPUness (for Doom3 and Half Life 2 fun), and 1G RAM. I expect it’ll weigh more than two Terri Schiavos* but I’m a big guy.

* – Please note: topical reference.

FreeS/WAN Sonicwall example

Here’s a (possibly) handy little set of configs and such to help you get
the FreeS/WAN IPSEC implementation working with a Sonicwall firewall in tunnel mode. It should work in transport mode with minimal changes but I have not tested that myself.

This is a working config with the sensitive information obsucated (mostly the external IPs of the firewalls and the secret key).

“” = freeswan gateway ip and
“son.icw.all.ip” = sonicwall gateway ip.

I’ve found other examples which state you need the “SonicWall Unique Identifier” but I found this to be unnecessary (in fact I couldn’t get it working correctly using any leftid= combinations)


    Left Network
|   FreeSwan GW    |
|   |
  The InterNET(tm)
|   SonicWall GW   |
|  son.icw.all.ip  |
    Right Network


config setup

conn fswn-swll
	# PFS doesn't work so turn it off
	# Freeswan Side
	# Sonicwall Side
	# you'll need to do "ipsec auto --up fswn-swll" to start this up
	# unless you use auto=start, but thats just basic freeswan stuff

ipsec.secrets son.icw.all.ip : PSK "allthefish"

RHCE, dsbackup, qemu, nfs, firestorm, m4

I passed my RHCE exam last month.

I’ve released v0.1 of dsbackup, an rsync based backup system.

I’m totally impressed with qemu the Intel and PPC cpu emulator. It’s far faster than bochs and I’ve not had any of the problems that I used to with Bochs (Fedora wouldn’t even get to the installer screen). Apparently the code is far cleaner and better thought out, which is allowing Gianni to do some rather clever things regarding hardward reverse engineering.

I’ve been implementing some NFS services at work over the last few months. I have to say it’s not as bad as I thought it would be. Don’t get me wrong, it’s quite horrifically messy from a security point of view (firewalling rpc, eesh) but not as insanely lame as I had first imagined.

I also begun work on a port scan detector for Firestorm but thats on hold at the moment whilst we discuss some implementation details of the tcp connection tracker. I’m now adding support for disk saving in between restarts for macwatch.

I’ve also learnt the M4 macro language. Cute. And handy.

Qmail, RedHat and Firestorm

I’ve built some packages of djbs software (qmail, daemontools, djbdns…) for RedHat ES.

I’ve also been working on Firestorm again, primarily on my mac/arp watcher preprocessor. It now saves state between restarts, and reports on more nefarious ethernet/arp. It’ll be included in the next release of Firestorm.

Firestorm ethereal and RedHat Advanced Server

I’ve ported my Ethereal ELOG patch to the latest version (0.9.14) and fixed a bug handling pcap captured alerts. Created Debian debs for powerpc and i386. Matt is working on some RPMS for RedHat 9

RedHat’s latest change of support plans for RedHat Linux seems to be doing what was intended, getting more people to purchase Advanced Server (and the new Enterprise Server and Workstation) rather than leeching off them. Good for RedHat. There have been too many idiots selling RedHat Linux-based solutions expecting the coloured headgear company to do the hard work of beta testing, bug fixing etc.etc. for free.