Date: Mon, 25 Nov 2013 11:42:43 -0800 From: "R. Tyler Croy" <tyler@monkeypox.org> To: Frank Knobbe <frank@knobbe.us> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125194243.GD6275@kiwi.coupleofllamas.com> In-Reply-To: <20131125192633.GB75749@knobbe.us> References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> <20131125190803.GC6275@kiwi.coupleofllamas.com> <20131125192633.GB75749@knobbe.us>
next in thread | previous in thread | raw e-mail | index | archive | help
--uxuisgdDHaNETlh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 retransmissi=
ons of
> > various packets?
>=20
> Ah, gotcha. The answer is Yes. :) pfil works at the packet level. You wi=
ll
> 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=20
> 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=
=20
> packet (well, stream) content for the response.
>=20
> 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,=20
> building an established TCP session table, tracking the in- or outbound
> request, and then wait for a response, an "attacker" could feed the respo=
nse
> 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.=20
>=20
> 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.=20
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 HTT=
P.
> The pfil interface is for a very low level of network traffic, and it sou=
nds
> 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@jabber.org
--uxuisgdDHaNETlh8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlKTqDMACgkQFCbH3D9R4W9JrgCgoiMU5lqWuZMJy/bx8QWfXXlb
/jAAn2j6UHzwOv5HHXCO4GGCFA7LeyJ0
=4jeB
-----END PGP SIGNATURE-----
--uxuisgdDHaNETlh8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131125194243.GD6275>