From owner-freebsd-pf@FreeBSD.ORG Mon Jul 23 11:26:53 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C8BF106566C for ; Mon, 23 Jul 2012 11:26:53 +0000 (UTC) (envelope-from tonix@interazioni.it) Received: from mx02.interazioni.net (mx02.interazioni.net [80.94.114.204]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA8F8FC19 for ; Mon, 23 Jul 2012 11:26:52 +0000 (UTC) Received: (qmail 24859 invoked by uid 88); 23 Jul 2012 11:26:51 -0000 Received: from unknown (HELO ?82.143.55.20?) (tonix@interazioni.it@82.143.55.20) by relay.interazioni.net with ESMTPA; 23 Jul 2012 11:26:51 -0000 Message-ID: <500D34F9.5000502@interazioni.it> Date: Mon, 23 Jul 2012 13:26:49 +0200 From: "Tonix (Antonio Nati)" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Daniel Hartmeier References: <500826BD.3070602@interazioni.it> <9EB23F6C23A8B6488E8BCC92A48E83264BB4D26F80@PEMEXMBXVS04.jellyfishnet.co.uk.local> <500AB340.2040405@interazioni.it> <9EB23F6C23A8B6488E8BCC92A48E83264BB4D27241@PEMEXMBXVS04.jellyfishnet.co.uk.local> <500AC91F.9090907@interazioni.it> <20120721182316.GA32530@insomnia.benzedrine.cx> <500D1B57.8080405@interazioni.it> <20120723095509.GB32530@insomnia.benzedrine.cx> <500D2D35.4070608@interazioni.it> <20120723111348.GD32530@insomnia.benzedrine.cx> In-Reply-To: <20120723111348.GD32530@insomnia.benzedrine.cx> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-pf@freebsd.org" Subject: Re: Question on packet filter using in and out interfaces 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: Mon, 23 Jul 2012 11:26:53 -0000 Il 23/07/2012 13:13, Daniel Hartmeier ha scritto: > On Mon, Jul 23, 2012 at 12:53:41PM +0200, Tonix (Antonio Nati) wrote: > >> So, does that mean the OUT phase evaluation always occurs when IN phase >> has been positive (packet should pass)? > > Yes. You have to both allow a packet in on the first interface and out > on the second interface. If you forget/omit the second part, the packet > will get dropped (assuming a default block policy). > >> I'm thinking to management of a lot of interfaces, where one is the WAN, >> and others are DMZ and/or customers dedicated subnets. >> >> I'd love to put basic protections on WAN input, and then permit all >> other interfaces to define its own rules for packets coming/going >> from/to the specific subnet. >> >> According to what I understand of your explanation, each interface could >> have its own IN rules, and if the IN rules of a specific INPUT interface >> are successfull, the OUT rules of the 'outgoing' interface are then >> evaluated. > > Yes. Example: you want to prevent customers from talking to arbitrary > SMTP hosts (prevent spam by forcing the use of a spam filtering proxy). > > You can block this with OUT rules on the WAN interface, i.e. by only > allowing the proxy's source address to connect to external hosts' > port 25. > > Even if customers can add pass rules for their respective interfaces, > they cannot circumvent your OUT on WAN rules. > >> This would be wonderful, as each interface could have both IN and OUT >> rules which do not interphere with or break other interfaces rules. And >> would permit to write the most of rules just once, according to each >> interface needs. > > Yes, that's the upside of filtering on both directions on all involved > interfaces :) > > The downside is that you might have to add some redundancy in your > rules: even if a customer adds 'pass out on DMZ to port 80' you'll also > have to add 'pass out on WAN to port 80'. When a customer complains that > something isn't working, you'll have to check both his interface's rules > AND the WAN rules. I have customers which should be allowed to go whetever they like. So I'd love to make something like this: - deny on INPUT WAN from hackers/abusers - allow any other INPUT on WAN - custom INPUT rules on remaining interfaces - custom OUT rules on remaining interfaces So, if a customer wants to allow anyone to access his port 80, he/she just add that OUT rule to his/her interface. And that avoids me to add the same rule to WAN and all remaining interfaces. Respect to the dominant model (i.e. which puts any rules on INPUT only), do you see any security hole? Or just some more processing? Regards, Tonino > > Daniel > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------