From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 10:22:33 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 972A816A4E1 for ; Tue, 11 Jul 2006 10:22:33 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ws2.infoweapons.com (ws2.infoweapons.com [58.71.34.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0310343D5A for ; Tue, 11 Jul 2006 10:22:31 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from [10.3.1.41] ([10.3.1.41] RDNS failed) by ws2.infoweapons.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 18:22:20 +0800 Message-ID: <44B37BA0.7030405@infoweapons.com> Date: Tue, 11 Jul 2006 18:21:20 +0800 From: "Ronnel P. Maglasang" User-Agent: Thunderbird 1.5 (X11/20060613) MIME-Version: 1.0 To: Greg Hennessy References: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> In-Reply-To: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 10:22:20.0882 (UTC) FILETIME=[E4B5EB20:01C6A4D3] 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:22:33 -0000 Greg Hennessy wrote: > 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. > > is it safe to say to just remove the "keep state" behavior for udp and other connectionless packets? i really think this is a vulnerability. please note the pf always creates states for outgoing packets, even its udp. >> 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 > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >