drop in libnids like api?

[Alfred Perlstein]

On 12/16/13 10:36 PM, Patrick Kelsey wrote:
>
>
> On Dec 16, 2013, at 9:33 PM, Juli Mallett <juli at clockworksquid.com 
> <mailto:juli at clockworksquid.com>> wrote:
>
>> On Mon, Dec 16, 2024 at 6:29 PM, Alfred Perlstein <alfred at freebsd.org 
>> <mailto: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...

I think this is what is needed, basically a "tap/tee" socket so that our 
application can watch an established flow.
Imagine:
client  <->  [switch] <-> server
                         |
application <-span port->
Our application would then be able to monitor the existing streams.
Basically the functionality that seems best would be getting a 
libnids-like callback with a tcp structure that maintains a copy buffer 
of the data transferred until we tell it to discard.
>
> 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.
I think we need to deal with lossy/out of order at least at a basic level.
>
> 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.
I think so.  I'm going to send a follow up off-list so we can exchange 
contact information and see how we can make this happen.
thank you,
-Alfred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20131217/4d3b0d32/attachment-0003.htm>