Do pfil(9) hooks receive TCP retransmissions?

R. Tyler Croy tyler at monkeypox.org
Mon Nov 25 19:42:50 UTC 2013


On Mon, 25 Nov 2013, Frank Knobbe wrote:

> On Mon, Nov 25, 2013 at 11:08:03AM -0800, R. Tyler Croy wrote:
> > Let's say for example I wanted to filter out a specific HTTP response, just as
> > a more complex kind of traffic on top of the TCP stream. Would my hook be
> > invoked for packets 1-100 of the HTTP response 100 times, or could it be
> > invoked any number of times depending on whether there are retransmissions of
> > various packets?
> 
> Ah, gotcha. The answer is Yes. :)  pfil works at the packet level. You will
> receive ALL packets going through the system. That means your function has
> to look for HTTP traffic (and ignore/pass the rest). You will also 
> have to keep track of the session state. In essence, you get all packets
> involved in the TCP 3-way handshake. You probably want to track that and
> mark a session as established. Then on established sessions, you probably
> want to keep track of HTTP content and "HTTP level session state", for
> example limiting your actions on responses to GET requests (or POSTs or
> whatever you need), and not the request itself. Then finally evaluate the 
> packet (well, stream) content for the response.
> 
> Since the pfil hooks work on each packet, you will also have to reassemble
> the TCP/HTTP stream properly so that your checks can not be bypassed by
> fragmentation attacks. Say your tracking the packets, tracking 3-way, 
> building an established TCP session table, tracking the in- or outbound
> request, and then wait for a response, an "attacker" could feed the response
> with, say, 2 byte packets, so your function will have to catch all these,
> in the proper order, and reassemble a complete response before you can
> perform any sort of content matching. 
> 
> This will be quite an effort. It might be easier to see if there are HTTP
> proxies (for example, Apache) where you could hook into in order to avoid
> having to do all the grunt work from the packet level up. 


I don't disagree with you that this might be a large amount of effort.
Unfortunately I've not found any existing tools that give me the ability to
create application layer filtering, while still acting as a full transparent
TCP proxy.

Performing such filtering in an HTTP proxy is fine, but I'm more interested
(academically) in filtering traffic transparently across more than just HTTP.


> The pfil interface is for a very low level of network traffic, and it sounds
> like you're wanting to build something for a much higher level in the OSI
> stack. Can it be done with pfil? Sure, but I wonder if the effort required
> would make pfil a good choice.


Agreed, pfil(9) is a very big and basic hammer.

- R. Tyler Croy
--------------------------------------
    Code: https://github.com/rtyler
 Chatter: https://twitter.com/agentdero
          rtyler at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20131125/b02ebca1/attachment.sig>


More information about the freebsd-hackers mailing list