From owner-freebsd-questions@FreeBSD.ORG Mon Jan 31 14:40:56 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433F8106564A for ; Mon, 31 Jan 2011 14:40:56 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0026D8FC14 for ; Mon, 31 Jan 2011 14:40:55 +0000 (UTC) Received: by gyf3 with SMTP id 3so2129495gyf.13 for ; Mon, 31 Jan 2011 06:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mVzBocvq4JjCJ0/Oi7B1LmhcoSbj+NXFuRiQvHEhrSs=; b=sgb97Rrcb+JCd/BdoUBZos4ax5VjR0/RD3Ko9mEMy7UmxMvh/ak6C5SLHJj5wpC34b 4BlFTvno+36POzSgyO1PP7OvkubOh1kZnwMB0Kt8r+6Yg6XsAz3ooyZ6xB++IRUCd9N6 QjDeV3fmQvhNDHgtJ3fdynt41mWWfNdu7DaCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xUHkpqgKlS1rW84XahIflwvn11Ifp3Zc7e97khEyIdN399CgiQNMIjlxbe/v7Dhcjs SMGJbz2tjl0vf/S6sFYJgU2UugDmxHTC/YCQR9l0TXQAWyP6qWiPnMtQldSCVnqD0mMg q1rSE1yk8qG858tUJOADl4MaUSYscGD1iTLZc= MIME-Version: 1.0 Received: by 10.90.248.28 with SMTP id v28mr8891162agh.168.1296484855102; Mon, 31 Jan 2011 06:40:55 -0800 (PST) Received: by 10.90.79.10 with HTTP; Mon, 31 Jan 2011 06:40:54 -0800 (PST) In-Reply-To: <4D4695D0.1040604@herveybayaustralia.com.au> References: <4D437DD6.4030202@herveybayaustralia.com.au> <20110131113058.71d4e4e8@mr129041.univ-rennes1.fr> <4D4695D0.1040604@herveybayaustralia.com.au> Date: Mon, 31 Jan 2011 09:40:54 -0500 Message-ID: From: Kevin Wilcox To: Da Rock Content-Type: text/plain; charset=UTF-8 Cc: freebsd-questions@freebsd.org Subject: Re: PF firewall rules and documentation X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:40:56 -0000 On Mon, Jan 31, 2011 at 05:58, Da Rock wrote: > Yes. Me unfortunately, but I did manage to pick it up quite quickly though. > I had a little thief attack one of my ports and attempt login on the > firewall. I had to change it to 'block in $log on $ext_if all > block out $log on $ext_if all' to actually block the traffic. Bit of a doozy > really, I'm still monitoring the traffic very closely with tcpdump on the > interface and not the log. Unless you have an explicit need to block in/out, it's easier to maintain a ruleset that uses block log on $ext_if For example, I use the following as a "starting point" for some of my routing firewalls: ============================= int_if=bge1 ext_if=bge0 set skip on lo # block everything block # NAT rule pass out log(all) on $ext_if from ($int_if:network) to any nat-to ($ext_if) # allow traffic in on the internal interface pass in on $int_if from ($int_if:network) to any keep state ============================= There are at least three things in that basic config that some people would jump on me for. 1) why block all if I'm then allowing every in on the internal interface? 2) why block all if I'm allowing everything out on the external interface? 3) why not pass everything on the internal interface and then filter on the external? The shortest answer is because I happen to like that starting point and it serves as a syntactical reminder if I deploy without a pf reference handy. Regarding 1) and 2), the longer answer is that I like to control traffic flow. I don't want to allow inbound connections on the external interface and I don't have a need for the firewall to connect to machines inside the NAT. On my bridges I'll set skip on the internal interface and filter on the other but I don't like doing that for a router. >> There are some plans to update PF to a more recent version. So may >> be it will be better. >> > > Actually, that sounds like a better idea than mine ;) Kills 2 birds with one > stone then... I am truly excited about this as the NAT and RDR stuff was significantly cleaned up (and the OpenBSD pf FAQ is a great resource). I'm even more excited about the patch to tcpdump that Daniel just sent to freebsd-pf@ that allows you to tcpdump a pfsync device and pull the state creation/updates - in my opinion, that's the weakest area for a BSD firewall (we'll ignore span ports on routers since you can bridge two addressed interfaces and create a span of that bridge) and being able to easily pull those NAT translations fulfills some serious accountability issues. If you need a reliable printed reference, you should really consider picking up Hansteen's _The Book of PF_, available from No Starch Press: http://nostarch.com/pf2.htm I have the first edition and it's incredible but somewhat dated. The author suggests the second edition for FreeBSD 8.x+. kmw