From owner-freebsd-hackers Thu Jan 16 13:56:14 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B96637B401 for ; Thu, 16 Jan 2003 13:56:11 -0800 (PST) Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D0143F13 for ; Thu, 16 Jan 2003 13:56:09 -0800 (PST) (envelope-from nate@yogotech.com) Received: from emerger.yogotech.com (emerger.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA00288; Thu, 16 Jan 2003 14:56:08 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by emerger.yogotech.com (8.12.6/8.12.6) id h0GLu7Fg068281; Thu, 16 Jan 2003 14:56:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15911.10871.858477.333335@emerger.yogotech.com> Date: Thu, 16 Jan 2003 14:56:07 -0700 To: Josh Brooks Cc: Nate Williams , freebsd-hackers@freebsd.org Subject: Re: FreeBSD firewall for high profile hosts - waste of time ? In-Reply-To: <20030116132958.H38599-100000@mail.econolodgetulsa.com> References: <15911.7774.98861.58086@emerger.yogotech.com> <20030116132958.H38599-100000@mail.econolodgetulsa.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > So you are saying that if I put in: > > ipfw add 00001 deny tcp from any to 10.10.10.10 6667 > > That an incoming packet for 10.10.10.10 on port 6667 will go through the > rule set _twice_ (once for each interface) ? No, that much is true. However, you want to optimize your firewall for packets that *do* go through, so your 'typical' packets (which are passed) go through two sets of rules before they are dropped. You don't want to stick the 'block abnormal packets' rules at the top of the list, IMO. You want those at the end, since abnormal packets are *usually* the exception. Optimize for the standard case. > Or are you saying that rules I have in place that _allow_ traffic should > have their _allowance_ apply to the external, because then they pass > through the firewall without ever checking the ruleset for the internal > interface they have to pass through ? Exactly. > Also, if you don't mind, could you post your paranoia rules: Sure. This set of rules probably won't work, as I've massaged it and added/removed some rules so that it makes more sense. -----------------------------cut here----------------------------- # Netif is my external interface's address. If this box has no external # services on it, the rules related to it can be removed. netif="fxp0" myeip="10.0.9.2" mynet="10.0.10.0/24" mybcast="10.0.10.255" ############ # Only in rare cases do you want to change this rule /sbin/ipfw add 10 pass all from any to any via lo0 /sbin/ipfw add 15 deny log all from any to 127.0.0.0/8 /sbin/ipfw add 20 deny log all from 127.0.0.0/8 to any ############ # Don't allow packets with source addresses from my boxes 'in'. /sbin/ipfw add 100 deny log all from ${mynet} to any via ${netif} in /sbin/ipfw add 110 deny log all from ${myeip} to any via ${netif} in ############ # RFC 1918 unroutable hosts shouldn't be generating incoming/outgoing packets. /sbin/ipfw add 200 deny log all from 192.168.0.0/16 to any via ${netif} /sbin/ipfw add 205 deny log all from any to 192.168.0.0/16 via ${netif} /sbin/ipfw add 210 deny log all from 172.16.0.0/12 to any via ${netif} /sbin/ipfw add 215 deny log all from any to 172.16.0.0/12 via ${netif} /sbin/ipfw add 220 deny log all from 10.0.0.0/8 to any via ${netif} /sbin/ipfw add 225 deny log all from any to 10.0.0.0/8 via ${netif} ############ # Multicast source stuff addresses. Don't send out multicast packets, and # ignore incoming TCP multicast packets (which are bogus). /sbin/ipfw add 230 deny log all from 224.0.0.0/8 to any via ${netif} /sbin/ipfw add 235 deny log tcp from any to 224.0.0.0/8 via ${netif} ############ # Other misc. netblocks that shouldn't see traffic # 0.0.0.0/8 should never be seen on the net # 169.254.0.0/16 is used by M$ if a box can't find a DHCP server # 204.162.64.0/23 is an old Sun block for private cluster networks # 192.0.2.0/24 is reserved for documentation examples /sbin/ipfw add 240 deny log all from 0.0.0.0/8 to any via ${netif} /sbin/ipfw add 245 deny log all from any to 0.0.0.0/8 via ${netif} /sbin/ipfw add 250 deny log all from 169.254.0.0/16 to any via ${netif} /sbin/ipfw add 260 deny log all from 204.152.64.0/23 to any via ${netif} /sbin/ipfw add 270 deny log all from 192.0.2.0/24 to any via ${netif} ########### # Ignore/block (don't log) broadcast packets. /sbin/ipfw add 400 deny all from ${mynet} to ${mybcast} via ${netif} out ########### # Ensure that outgoing packets have a source address from my machine now. /sbin/ipfw add 500 pass all from ${mynet} to any via ${netif} out /sbin/ipfw add 510 pass all from ${myeip} to any via ${netif} out ########### # Packets should be sanitized from invalid addresses at this point. /sbin/ipfw add 600 pass all from any to ${mynet} via ${netif} in /sbin/ipfw add 610 pass all from any to ${myeip} via ${netif} in ########### # Hmm, time to go kill something on my network that is using an invalid # address. However, we 'actively' reject packets from internal boxes. /sbin/ipfw add 700 log reject all from ${myeip} to any via ${netif} out ########### # Catch-all to see what I've missed. /sbin/ipfw add 700 log deny all from any to any via ${netif} in -----------------------------cut here----------------------------- Note the use of 'deny' vs. reject. I don't want externally generated packets to generate anything from my end. Stupid packet don't even deserve a response to use up *MY* bandwidth. The above are just the start, and are my 'first line of defense', since it doesn't require any stateful inspection in the firewall. There much more there, but these along with some local customizations are what seemd to have worked for me and my previous employers. I use logging to verify that I've caught things, and I monitor the box regularly with tcpdump and such to ensure that I'm catching these. This and email spam protection is something that I have to keep vigilant on... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message