From owner-freebsd-pf@FreeBSD.ORG Wed Jan 21 17:47:51 2009 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 1B2E4106566B for ; Wed, 21 Jan 2009 17:47:51 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id C576F8FC23 for ; Wed, 21 Jan 2009 17:47:50 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 8308081; Wed, 21 Jan 2009 11:47:50 -0500 Received: from [216.143.146.251] (account laura@radel.com HELO 84.sub-70-223-142.myvzw.com) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 8308079; Wed, 21 Jan 2009 11:47:25 -0500 Message-ID: <49775195.80809@radel.com> Date: Wed, 21 Jan 2009 11:47:17 -0500 From: Jon Radel User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: fbsdmail@dnswatch.com References: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> <497382D3.8040408@quip.cz> <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> In-Reply-To: <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: basic rule request - allow_all/block_bad 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: Wed, 21 Jan 2009 17:47:51 -0000 fbsdmail@dnswatch.com wrote: >> block in quick from 10.20.30.40 to any pass all >> >> If you need to block more than one address, or you need easy >> manipulation with list of addresses, you can use tables in ruleset: >> >> table persist file "/etc/pf.badguys.table" block in quick from >> to any >> pass all >> >> >> You can put IPs in to persistent file /etc/pf.badguys.table, these IPs >> will be loaded in the boot time. You can add / remove address on the fly by >> pfctl command: pfctl -t badguys -T add 10.11.12.13 pfctl -t badguys -T >> delete 10.11.12.13 > > Thank you. That's perfect! > > I seem to be stumped on one last issue; > All the information, and pf.conf files all provide for 2 interfaces - > INT_IF, and EXT_IF. > Assuming a single NIC (ethernet adapter), and only Internet routable > IP addresses, and a l0 (loopback). How would I define/use the 2 IF's? > Dummynet, maybe? > Ick (if you don't mind my saying so). No, don't make your life hell by coming up with dummy interfaces. The example line you were given by Miroslav at very top of my reply is standalone if you wish. A rule set like: set skip on l0 block in quick from 10.20.30.40 to any pass all should be completely stand-alone. It means: 1) Completely ignore the loopback interface for filtering purposes (supposedly more efficient than setting up a pass all or something to make sure other rules don't give you weird side effects on the loopback). 2) On any interface (since you didn't mention one in the rule) (other than on lo0, since you're ignoring it) block any incoming packets that come from 10.20.30.40. The fact that there's only one interface is of no particular consequence. 3) Pass everything else in and out on all interfaces (other than lo0, which is passing everything since it's being ignored). Again, that there is only one interface is of no concern. All those INT_IF, etc., macros you see in examples are there because it's considered best practice to use macros and document your rule set. For a 3 line rule set where you're the only maintainer, feel free to rip that all out.... ;-) After you get that running, I'd suggest you start making things fancier with Miroslav's recommendation about using a table, putting in scrub with some of the less agressive options, protecting yourself from packets with spoofed addresses, etc., etc. --Jon Radel