[Bro-Dev] Decapsulating "payload" tunnels

Seth Hall seth at icir.org
Wed Apr 25 06:54:03 PDT 2012

Jon and I have been working on the 2.1 tunnel decapsulation recently and we encountered some major architectural questions.  We seem to have the groundwork laid for doing IP encapsulation tunnels (AYIYA, Teredo, 6to4), but I want to support tunnels like SOCKS and HTTP CONNECT which are essentially session payload tunnels since they are tunneling reassembled TCP streams.

This brings up a problem if we want to create logs that are useful forensically because right now any connection to a SOCKS proxy looks like the client is sending all the traffic to the proxy.  The HTTP logs will show the client doing HTTP requests to the proxy even though the proxy is really sending them onward to other hosts.  In environments with pervasive proxying, this makes the logs much less useful.

Robin, Jon, and I discussed this for a while yesterday and we came up with a proposal where we would extract the payload from the proxy connection and mock up IP headers for the Sessions::DoNextPacket method which looks like the client connecting to the host it's requesting to actually talk to.  We would need to extend the DoNextPacket method to provide a short circuit for skipping the TCP reassembly and analysis since it would be reassembled payload bytes immediately after the fake IP header.  This would result in two connections showing up in conn.log when there was *really* 

There is one other niggle in this.  It seems that most proxy protocols (SOCKS and HTTP at least) support requesting a proxy connection by name instead of IP address.  I fully expect to be beat up over this, but I think it would be great to be able to support doing a lookup to create the fake ip header.  

I'm sure we'll end up sticking configuration options all over the place to turn things off and we'll definitely figure out a good set of things to turn on by default.

Does anyone have reservations with this design?  It definitely seems nasty on some levels and Robin pointed out yesterday that it would probably be much better to pass data around with abstracted metadata instead of packets, but packets are what we deal with internally for now so that's what we would have to fake without doing a major redesign.

Robin, Jon: please follow up if there are any points that I didn't make clear enough. :)


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list