Date: Mon, 29 Apr 2002 20:23:37 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: Drew Tomlinson <drew@mykitchentable.net> Cc: security@FreeBSD.ORG Subject: Re: Stateful IPFW Firewall Assistance Message-ID: <20020429202337.A53784@blossom.cjclark.org> In-Reply-To: <010901c1efc9$2f1dc670$6e2a6ba5@lc.ca.gov>; from drew@mykitchentable.net on Mon, Apr 29, 2002 at 02:59:49PM -0700 References: <020501c1ecb4$4e21a220$6e2a6ba5@lc.ca.gov> <20020427163041.A37618@blossom.cjclark.org> <010901c1efc9$2f1dc670$6e2a6ba5@lc.ca.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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.
> 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.
> Anyway, thank for your help. I am trying to *understand* how my
> firewall actually works instead of just being satisfied that it seems to
> work.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
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?20020429202337.A53784>