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.

No comments:

Post a Comment