Date: Tue, 30 Apr 2002 08:16:29 -0700 From: "Drew Tomlinson" <drew@mykitchentable.net> To: <cjclark@alum.mit.edu> Cc: <security@FreeBSD.ORG> Subject: Re: Stateful IPFW Firewall Assistance Message-ID: <013001c1f05a$00eba290$6e2a6ba5@lc.ca.gov> References: <020501c1ecb4$4e21a220$6e2a6ba5@lc.ca.gov> <20020427163041.A37618@blossom.cjclark.org> <010901c1efc9$2f1dc670$6e2a6ba5@lc.ca.gov> <20020429202337.A53784@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Crist J. Clark" <crist.clark@attbi.com> Sent: Monday, April 29, 2002 8:23 PM > On Mon, Apr 29, 2002 at 02:59:49PM -0700, Drew Tomlinson wrote: > > ----- Original Message ----- > > From: "Crist J. Clark" <cjc@FreeBSD.ORG> > > Sent: Saturday, April 27, 2002 4:30 PM > > > > > On Thu, Apr 25, 2002 at 04:52:47PM -0700, Drew Tomlinson wrote: > > > > I'm trying to fine-tune my firewall and am hoping for a little > > advice > > > > regarding stateful behavior. I built this rule set based upon an > > > > example by Peter Brezny I found on the web so it may look familar. > > > > > > > > Here's my current network setup: > > > > > > > > ISP > > > > | > > > > | Public DHCP address > > > > | > > > > 3Com ADSL Modem/Router > > > > (Router performs NAT and passes packets to 10.2 by default) > > > > | (192.168.10.1) > > > > | > > > > | > > > > | (ed1 192.168.10.2) > > > > FBSD Gateway > > > > | (ed0 192.168.1.2) > > > > | > > > > | > > > > Internal LAN > > > > > > > > And here are my current firewall rules: > > > > > > > > 00100 allow ip from any to any via lo0 > > > > 00200 deny log ip from any to 127.0.0.0/8 > > > > 00300 deny log ip from 192.168.1.0/24 to any in recv ed1 > > > > 00400 deny log ip from not 192.168.1.0/24 to any in recv ed0 > > > > 00500 allow tcp from any to any established > > > > 00600 allow tcp from any to 192.168.1.0/24 > > 21,22,25,80,143,389,443,993 setup > > > > > > This seems odd. How can anyone ever get packets to your various nets > > > in the 192.168.0.0/16 range from the outside? Maybe these are masked > > > examples? Anyway, you probably want the above to read as, > > > > These are actual examples. If I understand the reasons for these rules > > correctly, I'm not allowing packets arrive on the outside interface > > (192.168.10.2) from the inside (192.168.1.0/24) network and visa-versa > > to prevent spoofing. > > That's what 200, 300, and 400 do, anti-spoofing. > > > > 00500 allow tcp from 192.168.1.0/24 21,22,25,80,143,389,443,993 to > > any established > > > 00600 allow tcp from any to 192.168.1.0/24 > > 21,22,25,80,143,389,443,993 > > > > > > > 00700 allow tcp from any to 192.168.10.2 21,22 setup > > > > > > And this as, > > > > > > 00700 allow tcp from 192.168.10.2 21,22 to any established > > > 00750 allow tcp from any to 192.168.10.2 21,22 > > > > > > This way, you get rid of that 'pass tcp from any to any established' > > > rule that will mess up, > > > > I think I understand. These rules allow traffic in and out for ports > > where services are running. However, are rules 500 and 700 necessary? > > If you want to allow external access to ftp (21/tcp), ssh (22/tcp), > smtp (25/tcp), http (80/tcp), imap (143/tcp), ldap (389/tcp), https > (443/tcp), and imaps (993/tcp), you want these rules. It will actually > work with just the keep-state rules for the outgoing stuff, but > allowing external machines to create dynamic rules is not a really > good idea. There is no security benefit, and it is actually less > secure since it's an easier DoS. > > If you don't need to allow the outside world access to any of these > servers running on your network, close 'em up. My previous question > was how the external world could possibly reach these services from > the Internet if you are using RFC1918 addresses. Ah... because my 3Com ADSL Modem/Router performs NAT as indicated in the diagram of my network. I would really like to set up the 3Com as a bridge so it would be "transparent" to my FBSD gateway but I can't seem to make that happen. I think my ISP's config won't allow it to be a bridge but their help desk doesn't have a clue and thus, can't confirm my suspicion. They just want to know what version of Windows I'm runnin g... :) > > I've tested this and rules 2000 and 2100 appear to allow the outgoing > > traffic? Is this OK or is it poor firewall design? What are the > > ad/disadvantages? > > Those does allow _outgoing_ the previous rules allow incoming. > > > > > 01900 check-state > > > > 02000 allow ip from 192.168.10.2 to any keep-state out xmit ed1 > > > > 02100 allow ip from 192.168.1.0/24 to any keep-state via ed0 > > > > > > The keep-state rules by passing packets that they have state on. Also > > > note that the 'check-state' rule here is completely redudant and can > > > be removed. > > > > I've moved the check-state and made the modifications you suggested. My > > current ruleset looks like this: (Please note these rule numbers will > > not correspond exactly to the rule numbers in the previous thread.) > > > > blacksheep# ipfw show > > 00100 0 0 allow ip from any to any via lo0 > > 00200 0 0 deny log ip from any to 127.0.0.0/8 > > 00300 0 0 deny log ip from 192.168.1.0/24 to any in recv ed1 > > 00400 0 0 deny log ip from not 192.168.1.0/24 to any in recv ed0 > > 00500 0 0 check-state > > 00600 14 696 allow tcp from any to 192.168.1.0/24 > > 21,22,25,80,143,389,443,993,5405,10001 > > 00700 77 3464 allow tcp from any to 192.168.10.2 21,22 > > 00800 0 0 allow icmp from any to any icmptype 3,4,11,12 > > 00900 0 0 allow icmp from any to any out icmptype 8 > > 01000 0 0 allow icmp from any to any in icmptype 0 > > 01100 0 0 reset log tcp from any to any 113 > > 01200 0 0 allow udp from 206.13.19.133 123 to 192.168.10.2 123 > > 01300 0 0 allow udp from 165.227.1.1 123 to 192.168.10.2 123 > > 01400 0 0 allow udp from 63.192.96.2 123 to 192.168.10.2 123 > > 01500 0 0 allow udp from 63.192.96.3 123 to 192.168.10.2 123 > > 01600 0 0 allow udp from 132.239.254.49 123 to 192.168.10.2 123 > > 01700 42 4614 allow udp from 192.168.10.1 to any > > 01800 42 2928 allow udp from any to 192.168.10.1 > > 01900 144 12816 allow ip from 192.168.10.2 to any keep-state out xmit > > ed1 > > 02000 195 62903 allow ip from 192.168.1.0/24 to any keep-state via ed0 > > 65400 0 0 allow log ip from any to any > > 65500 0 0 deny log ip from any to any > > 65535 203 17016 allow ip from any to any > > > > I am curious as to why the check-state (500) rule is not incrementing. > > 'Cause that's not how it works. The "parent rule" gets incremented. OK, thanks for clearing that up. > > As I understand it, a box on my internal network (192.168.1.0/24) > > requests a page from Yahoo! for example. The outgoing request is > > allowed by rule 2000 which then sets up the dynamic rule. Why wouldn't > > the packets coming back from Yahoo! match the check-state rule > > (500)? > > It does, and rule 2000 gets incremented each time a packet maches the > dynamic rule created from it. > > > Instead they are being allowed back in via rule 600. > > No, other stuff is coming in that way. OK, I've got it. Thank you for your help. I appreciate it very much and am happy to understand what's going on here instead of just copying a file from the Net and assuming it works. Thanks again, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?013001c1f05a$00eba290$6e2a6ba5>