From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 12:17:30 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 50EDC16A4DA for ; Tue, 11 Jul 2006 12:17:30 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8110A43D6E for ; Tue, 11 Jul 2006 12:17:18 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 633074CDFD for ; Tue, 11 Jul 2006 12:17:14 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 3B9014CDD8 for ; Tue, 11 Jul 2006 12:17:13 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 5E9D48A065; Tue, 11 Jul 2006 22:17:06 +1000 (EST) Received: from [192.168.0.4] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 117768A01F; Tue, 11 Jul 2006 22:17:06 +1000 (EST) Message-ID: <44B396C3.90205@thebeastie.org> Date: Tue, 11 Jul 2006 22:17:07 +1000 From: Michael VInce User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) 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-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP 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 12:17:30 -0000 Greg Hennessy wrote: > > > >> 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. > While a lot of people are telling me things I already know, its nice to be refreshed, on the other side I have seen a few ideas for PF now to make maybe slightly cleaner firewall rule set, thanks for this. I did mention it a few times but I suppose I wasn't clear about it, but I really do want to use "single line firewall rules", and the only way to do this is to keep state, if there are other ways/rules to have really flexible firewall but still with stateful inspection with a small amount of rules I would like to see them. Using double line firewall rules (stateless) is going way past even my goal of testing out a less strict (easy going) firewall setup. My goal has been to have a really simple firewall rule set, strictly single line rules per access rule (for the basic stuff), I aimed to have all out going connections have only firewall rules that had the keyword "out" for any out going connections or blocks with no "in" rules for what I would normally see the other way around, and every thing else blocked. Also to have the TCP keep state rules lean to the point their behavior was similar to UDP as in to really pay no attention to flags so I could continue with my "testing" and reset the state table as much as I like even if I can use the /etc/rc.d/pf resync or the other methods to reload rules but still keep the state table. If you follow these rules very strictly enough they can not be done with PF but are a fair bit easier to do with IPFilter. I thought PF being a new firewall technology that it could do everything IPFilter could do in the exact same fashion and more, but it can't and I am glad I asked. Realistically everyone is right to point out that there are plenty of compromises such as block "in" on the internal interface etc, I just wasn't sure these were the only options and I just once again had to ask. Some other people might be wondering the same things as me, you never know. I really was hoping that I could create the rules exactly as how I would imagine them to be, but I am ready to make some compromises and I am actually have a good feeling I will be more happy with my new rules setup then before simply because I know more about my options and limitations. Just like most people I don't see it any other way then the fact that single line firewall rules are great, and I never have and never will be making any compromises on this. I just don't know if I agree on what appears to be overly strict behavior on TCP in regards to its state activity and how it could be done for some firewall scenarios like a home firewall, but again people can just point out I can just keep my state table and reload my rules while using stick keep state methods, I just want to test the alternative limits for situations I don't want to have to go into, isn't what flexible firewalling technology is about? As for UDP being stateless I still do see the big benefit of using the stateful rules for what they are worth as a more sure way of tracking those packets of "who" is initiating those connections, if I go back to the true old school ways and have 2 firewall rules for every rule over what could be done with a single stateful rule I would still taking a step back as I can't be sure some ones loading up some of the old classic back door UDP trojans into my network by 'initiating' connections into my network. Mike