Sunday, May 15, 2011

Tuntap - going down the rabbit hole

Firstly I'd like to begin by apologising if the title makes this sound at all interesting - it drove me completely fucking crazy for most of last week. The issue I had was a packet capture probe which would stream the data elsewhere, but I didn't have the luxury of being able to cache the gigabytes of data it was putting out every minute. I tried using netflow with ntop (since I'd had absolutely no experience with flow analysers) and this gave me a good start, but there was pretty much nothing I could do to manipulate the data apart from a few hall of fame style charts.

The next step was to try snort and set up some rules based on ip ranges (a step ahead of ntop in netflow mode) and then run it through snortalog to make it a bit easier to view, but snort doesn't take data directly from a single port. I tried to dump it from netcat into a named pipe, but snort doesn't read "special" files... The next option was to start playing around with tap interfaces.

The tap and tun interfaces are virtual NICs which you can apparently send data directly to. I had no luck getting this to work - my tap0 didn't give me a /dev/tap0 file to pipe to, so I ended up back at square one... almost. The final key was using tcpreplay to replay from the named pipe to tap0, and then attaching snort to it. It ended up working, but being asynchronous, snort ended up missing half the packets since the system was busy trying to pipe data to this virtual interface that nobody else could read from...

And in the end? We all lived happily ever after. I found the tcpdump filter I wanted, set up tshark to read from the named pipe, and it's all working, all thanks to the almost unusable tuntap interfaces.

Monday, May 9, 2011

Two part network authentication

We've just changed to using two part authentication for google at work, and it seems to do the job well - unintrusive, unless you lose your phone. The idea is simple - retain your current password, but use a second one-time password which is generated by an app on your phone. When you first set it up, you paste a massive password into your phone if you're unlucky enough to not have an iPhone 3GS or higher (with a camera capable of reading the barcode on the screen). This acts as the seed for a random number generator, which is combined with the current time to the nearest minute to generate one-time passwords that can only be predicted if both sides have their time synchronised and share the same password.

This is cool in itself, but after a conversation with one of my colleagues I thought it would be cool to extend it, and combine it with the concept of port knocking.

Port knocking, for those who don't know, is at worst another layer of security through obscurity, but at best is another channel for confirming knowledge of shared secrets. Normal firewalls try to make it difficult for potential hackers by detecting when they scan for open ports (which correspond to network services) and then not confirming or denying whether or not any of the ports are open. Port knocking goes further, by making all ports appear closed, unless the IP attempting to connect to a service has recently queried a list of ports in the correct order (a sort of secret knock if you like).

A traditional port knock is a predictable sequence, which can be easily inspected by routers along the way. To add a further layer of security, setting the TCP sequence number to the value of a hash of the packet combined with a shared secret - thus ensuring a port knock from one IP can't be replayed later from another.

But what if we want to make the sequence itself unpredictable? If we restrict ourself to just 256 ports, and make our port knock sequence 16 ports long, then we can convert the output from a cryptographic hash into a sequence of ports to query. Sharing a secret in advance, and salting this with the current time to the nearest minute allows us to create per-session portknocks. And the icing on the cake? Add the IP to the time as a second salt, allowing the client to perform the portknock in plain sight, and then be allowed access to a totally hidden port.

OR..... we could just use IPSEC AH