drop in libnids like api?

[Patrick Kelsey]

On Dec 16, 2013, at 9:33 PM, Juli Mallett <juli at clockworksquid.com> wrote:

> On Mon, Dec 16, 2013 at 6:29 PM, Alfred Perlstein <alfred at freebsd.org> wrote:
>> 
>> On 12/16/13, 4:28 PM, Juli Mallett wrote:
>>> Alfred,
>>> 
>>> It's probably the "libuinet" component you're looking for,           but that's an active userland TCP stack, not a passive one.  That is, you can do full TCP/IP with libuinet pretty easily, but you can't just hand it packets and look at a stream you're intercepting.  It might be possible to make it provide two half-connections for each connection from the wire at some point, with data going into a socket and being readable, but that functionality isn't there now.  I know there's some interest in funding Pat Kelsey (who did the "libuinet" work) to do that, but I don't think there's any roadmap for it.  I may also be misunderstanding what you're using libnids to do.
>> 
>> I think you're right on point.
>> 
>> Basically what I need is the ability to write something like     https://github.com/alfredperlstein/dsniff/blob/master/urlsnarf.c using wanproxy as a backend.
>> 
>> Specifically have a look at line 164 of the file at  sniff_http_client(), this calls line 88 of that file (process_http_request()) each time a new packet comes in for a stream we are interested in.  It's relatively basic stuff to monitor streams.  Is it at all possible to do this using wanproxy libuinet?
> 
> Nope, not at this time, unless you're willing to actually be an inline proxy instead, which is probably not worth it since libnids exists.
>  
>> If not is Pat available to chat about what needs to be done?
> 
> I've added him to the CC list explicitly, I'm sure he has some thoughts on how possible it would be to adapt the FreeBSD stack to support passive reception / read-only connections.

Thanks, Juli.  It's a wonder I hadn't subscribed to the list until ten minutes ago.

libuinet currently has the ability to flexibly listen for TCP connections, letting you independently specify any/single for IP address, port, and VLAN tag stack.  Inbound connection attempts that make it past that selector can be additionally qualified by a user-supplied filter routine that has access to all the L2 and L3 address information on the SYN.  Whatever passes those criteria becomes a connection accessible via the sockets API, and whatever doesn't pass is blackholed.

The 'sockets API' above is currently the FreeBSD in-kernel API.  If you aren't familiar, suffice it to say it's event-driven, so it lends itself to urlsnarf-style applications.  You'd also have the option of using the WANproxy event system and sockets API, as that is now integrated with the libuinet API.

So the only thing truly lacking is receive-only socket functionality.  Off the top of my head, this would require plumbing  through a new socket option for listen sockets, that when enabled, would modify the TCP state machine for inbound connections (3-way handshake becomes 1-way handshake), modify/disable some timer behavior, silence all outbound ACK, FIN and RST paths, deal with anything dependent on RTT and the ability to limit the client's behavior based on options negotiation...

Some consideration would have to be given to whether and how to handle dropped frames that would leave a hole in the reassembled stream, unless it's reasonable to assume that the data path that would be feeding this suffers no more losses (lossy driver input queues, oversubscribed span ports, etc) than the path to the responding party at the true other end of the connection.

Not trivial, but I think entirely doable.  I'd be happy to talk more about it, if this at all seems on the track to what you are after.

-Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20131217/6c53a4ef/attachment-0002.htm>