From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:14:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E9C2E0F for ; Mon, 25 Nov 2013 19:14:49 +0000 (UTC) Received: from starfish.geekisp.com (starfish.geekisp.com [216.168.135.166]) by mx1.freebsd.org (Postfix) with SMTP id D2E1021F0 for ; Mon, 25 Nov 2013 19:14:48 +0000 (UTC) Received: (qmail 12954 invoked by uid 1003); 25 Nov 2013 19:08:07 -0000 Received: from unknown (HELO kiwi.coupleofllamas.com) (tyler@monkeypox.org@64.125.69.200) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Nov 2013 19:08:06 -0000 Date: Mon, 25 Nov 2013 11:08:03 -0800 From: "R. Tyler Croy" To: Frank Knobbe Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125190803.GC6275@kiwi.coupleofllamas.com> Mail-Followup-To: Frank Knobbe , freebsd-hackers References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: <20131125183829.GA75749@knobbe.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:14:49 -0000 --vOmOzSkFvhd7u8Ms 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 10:12:32AM -0800, R. Tyler Croy wrote: > > I'm looking at the pfil(9) interface to accomplish some packet inspecti= on > > tasks, but the man page leaves some ambiguity in this case. > >=20 > > If the hooks are not invoked multiple times for retransmissions then I = can > > imagine it being relatively "simple" to implement a basic firewall with= these > > hooks without implementing loads of state tracking for packets. >=20 > I'm not sure if I follow. Typically you only have one function that gets > "hooked" into the pfil chain. That function will receive ALL packets leav= ing > or entering the system. It's up to your code to check for the interface, > apply state tracking, or whatever other checks need to be performed. For a > very basic firewall (just dropping traffic from/to a certain IP address or > a certain port or protocol) you probably don't need to track state. >=20 > If the packet passes your filter criteria and is to be passed on (down the > chain of other firewalls), your function is to return 0. If you need to > filter the packet, your function needs to a) m_freem the mbuf, and=20 > b) return -1. That'll drop the packet and it won't be passed on to other > firewalls in the chain or the system. 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? My goal is not necessarily to write a simple firewall at an IP level, but prototype a slightly more complex firewall filtering of application layer traffic. I'm not 100% certain pfil(9) is the right way to do this, but it's= the first useful API I've stumbled across. > Hope that helps. Most certainly :) - R. Tyler Croy -------------------------------------- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rtyler@jabber.org --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKToBMACgkQFCbH3D9R4W9PfgCfZxHgCBqcyO1reH/a4UQSWM4Q a1wAoIvt9CY0cQ3ytydbxd64JuBxCVVA =11XG -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms--