From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 10:02:29 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC5016A4DF for ; Tue, 11 Jul 2006 10:02:29 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 450C043D45 for ; Tue, 11 Jul 2006 10:02:29 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id F188A2375F1 for ; Tue, 11 Jul 2006 11:02:24 +0100 (BST) From: "Greg Hennessy" To: "'Michael Vince'" , "'Daniel Hartmeier'" Date: Tue, 11 Jul 2006 11:02:25 +0100 Message-ID: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44B35E7D.5010107@thebeastie.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcakxFTO5xUkxWATRQq2hkW/XcSnXQAArArg X-OriginalArrivalTime: 11 Jul 2006 10:02:25.0517 (UTC) FILETIME=[1C37B1D0:01C6A4D1] Cc: freebsd-pf@freebsd.org Subject: RE: PF firewall rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 10:02:29 -0000 > > So ultimately what your saying is PF is too clever now and > can never be simplified like UDP state modes for single line The notion of UDP keeping state is overstated. Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer tracking how long it was since the last packet for the reverse flow arrived. > firewall rules using rough careless flags options on a > firewall rules where everything is just going out keep state One cannot 'keep state' for TCP in any meaningful fashion without tracking the flags + sequencing. If you want a primitive packet filtered ACL from point a to b for TCP. pass out on int inet proto tcp from a to b pass in on int inet proto tcp from b to a will match all packets and allow that flow. > and otherwise blocking all in. > > This is fair enough, I just had to ask. To me it just seemed > a bit unreasonable to bit so stricted about TCP while being > so lean and easy going and in one sense clever with UDP and ICMP. At layer 3 there is nothing to track in UDP to keep state except the quad in the header. UDP by its very nature is connectionless. > While the inherited TCP flags give you the ability to be more > strict about it all I just would of thought if I want to have > a easy/non strict going firewall I would be able to configure > it like that with no problems. > While I don't understand the TCP protocol as well as you > guys, I do tent to see as protocol racism, making it all easy > for the white UDP people and being tough on the TCP black > people (if it was a firewall/country of largely white > population in the 50s) Oh puhleeze. Get some of idea of the fundamental difference between TCP and UDP before making such a ridiculous statement. In particular I recommend reading TCP Illustrated by W Richard Stevens. > >But if you'd just prefer to not have "translation occur before > >filtering", I guess you're way too late to suggest that. It was a > >deliberate design choice, and people grew to appreciate and rely on > >this order. > > > > > Darn, I had wondered about this for a bit now, so all > IPFilter users have to readapt their mind frame for PF, We all had to do it, you will find once you get used to it, that the equivalent PF policy is about half the size of the IPF one as a consequence. > One way to kind of add onto the syntax but still keep the > "out" word in there would be to place the keyword "kernel" to > help let the user know which direction the packet is going in > and out of the internal interface. Err, that's what matching against direction in the rule base does. > I don't know if it is the > best solution but I do get to keep my "out" word even if its > a bit selfish. That's what tags are for. > > block out quick on $int_if kernel proto { tcp, udp, icmp } from > 192.168.1.17 to any > > Yes, one of the issues I had against blocking so early on the > internal interface is it ruins the ability to run services on > internal NAT ip servers using RDR for internal IPs but > providing a single IP to all users behind the firewall and > for those over the Internet. Are you saying that you cannot do a transparent redirect on the inside interface of the form ? rdr pass on inside $TCP from -> $PublicVIP port something -> $DMZ-RFC-ADDRESS port something > If I want to block some IPs from reaching the Internet but > still be able to use the web server behind NAT firewall I > have to allow extra firewall rules for those IPs before they > hit the firewall rule above that blocks everything going out > on the internal interface. If the service sits on the LAN rather than on a DMZ interface, this is most likely going to pear shaped unless you start disabling ICMP redirects everywhere. >From a design perspective hosting any external facing service directly on the most trusted part of the network is *not* a good idea. Greg