Date: Mon, 25 Nov 2013 13:26:33 -0600 From: Frank Knobbe <frank@knobbe.us> To: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125192633.GB75749@knobbe.us> In-Reply-To: <20131125190803.GC6275@kiwi.coupleofllamas.com> References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> <20131125190803.GC6275@kiwi.coupleofllamas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. Cheers, Frank
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131125192633.GB75749>