drop in libnids like api?
alfred at freebsd.org
Tue Dec 17 08:15:54 PST 2013
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, 2013 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:
>>> 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
>> 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
>> Nope, not at this time, unless you're willing to actually be an
>> inline proxy instead, which is probably not worth it since libnids
>> 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
I think this is what is needed, basically a "tap/tee" socket so that our
application can watch an established flow.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wanproxy