Date: Sun, 13 Jul 2003 00:15:31 -0500 From: Herbert Wolverson <herbert@charizard.tsghelp.com> To: freebsd-questions@freebsd.org Subject: Re: Newbie Firewall Question Message-ID: <20030713051531.GA28872@charizard.tsghelp.com> In-Reply-To: <000e01c347fc$87e701e0$0f00a8c0@cannotresolve> References: <000e01c347fc$87e701e0$0f00a8c0@cannotresolve>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 12, 2003 at 12:33:47AM +0200, mempheria wrote: > Q1: > i just setup my first ipfw/with natd firewall :-) > i run the preconfigured firewalltype called "simple" > can anyone help me make a ruleset that blocks all to inside > (except dhcp from my isp & ssh from inside) and allows everything out? > outside interface ep0 "DHCP" > inside interface fxp0 "192.168.0.1" > > when i try to learn, and look at the "simple" configuration ruleset in rc.firewall i go nuts > i mean, why is there natd rules? isnt natd transparent? if i block all in it should block all in for natd aswell (?) Answering your last questions first, natd isn't transparent because: - it runs in userland (rather than kernelspace), so it doesn't see anything before the firewall. - the flexibility to not run it, or closely control how it runs is appreciated in many situations (multiple divert rules, for example). In other words, it could be transparent but that would annoy those of us with wierd/complex setups! The trick with natd/ipfw is to realise that as soon as your divert rule runs, you can ignore natd in your firewall rules: after the divert rule, all packets show up with correct endpoints. Generally, that means running natd early. A really basic firewall script to allow outbound traffic and deny inbound would look something like this: --------------------------------------------------- (snip) # Clear the firewall ipfw flush # Run natd ipfw add divert natd all from any to any via ep0 # Allow established TCP sessions ipfw add allow tcp from any to any established # Allow TCP setup from local to anywhere ipfw add allow tcp from 192.168.0.0/24 to any setup # Allow SSH administration from inside ipfw add allow tcp from 192.168.0.0/24 to me 22 setup # Block all TCP that didn't match the above rules ipfw add deny tcp from any to 192.168.0.0/24 # Allow DNS ipfw add allow udp from any 53 to any ipfw add allow udp from any to any 53 # Allow DHCP ipfw add allow udp from any to any 546 ipfw add allow udp from any to any 547 ipfw add allow udp from any to any 67 ipfw add allow udp from any to any 68 # Block stupid MS UDP traffic ipfw add deny udp from any to any 137-139 # Block low port UDP (safety measure optional) ipfw deny udp from any to 192.168.0.0/24 1-1024 # Allow all udp (I generally don't do this!) ipfw add allow udp from any to any # Allow all icmp ipfw add allow icmp from any to any --------------------------------------------------- (snip) This is from memory, so there may be something wrong with it. I strongly recommend taking a look at the FreeBSD cheat sheets, http://www.mostgraveconcern.com/freebsd/ , the handbook at freebsd.org, "man ipfw", and "man natd". > Q2: > What means by statefull inspection? i guess ipfw doesnt have suport for that. Stateful inspection means that the firewall "keeps state" - in other words, it remembers which connections are supposed to be allowed, rather than taking the protocol's word for it; that way it can't be tricked into allowing certain scans that work by faking the "established" flag in TCP connections. ipfw has had this for a long time! (see "man ipfw" for details) A non-stateful ruleset to allow only outgoing TCP traffic: ipfw add allow tcp from any to any established ipfw add allow tcp from 192.168.0.0/24 to any setup ipfw add deny tcp from any to any A stateful version of the same thing: ipfw add check-state ipfw add allow tcp from 192.168.0.0/24 to any setup keep-state ipfw add deny tcp from any to any The first set of rules will allow any TCP packet market as being part of an ongoing connection, and can be tricked into allowing certain scans as a result. The second set automagically adds an ipfw rule for each connection that passes the "keep-state" rule - in this case, any TCP connection setup originating in the local subnet. Scans that attempt to get in because they are marked "established" fail, because "check-state" doesn't see a rule created by a matching outbound connection. Note that there is a performance hit for using stateful rules. It isn't huge, but for a busy firewall it is noticable. Also note that natd and check-state/keep-state don't like one another. FreeBSD has two other firewalls (pf and ipf) to try if you really need this functionality (you almost certainly don't!). -- Herbert.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030713051531.GA28872>