Date: Mon, 8 Apr 2002 21:00:36 +0200 (SAST) From: Willie Viljoen <will@laserfence.net> To: Bill Fumerola <billf@mu.org> Cc: Steve Shorter <steve@nomad.lets.net>, FreeBSD <freebsd@icablenet.com.br>, <freebsd-security@FreeBSD.ORG> Subject: Re: IpFilter / IpFireWall Message-ID: <20020408205232.W3388-100000@phoenix.vh.laserfence.net> In-Reply-To: <20020404233824.GN1135@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
To get back to the origional post... as he writes he is using "FreeBSD 4.5-RELEASE _#0" I'm almost certain he hasn't rebuilt, or rebooted with a new kernel. Also, I wouldn't really recommend the IPFIREWALL_DEFAULT_TO_ACCEPT option, unless you are working with a testbed machine. Default to accept means that you have to explicitly block anything you don't want allowed in. The security section of the handbook covers this and very convincingly states that the above method is almost always a bad idea. The better option is to have it deny by default, and only allow in what is really needed in. For a client machine running no services, the following should suffice: add check-state add allow ip from any to any out keep-state That's all you need to set up a stateful firewall for a workstation, which denies ALL incoming new connections, and infact ALL incoming packets, except for ones which are related in connections that were established as outgoing from this machine. A few small caveats, some badly configured servers test for ident (port 113, also called auth) service to "authenticate" users (just as the RFCs on this say you SHOULDN'T use it) These servers will either have long delays when being connected to, or just not allow you to connect at all. Because your machine is not allowing any incoming connections, and thus they can not talk to port 113. A quick (but ugly) way arround this, is to reset TCP connections to port 113, thus telling remote servers you are not willing to provide an ident response. All but the very badly configured of the badly configured servers out there should then allow you immediate access. A good way to do this is to have this at the end of your ruleset (so it gets processed after your outgoing and incoming packets, and generally doesn't get in the way of legit traffic, or eat up any processing time): add reset tcp from any to any 113 setup in Note that outgoing ident from your machine will still work fine. Another annoyance with the stateful behaviour of ipfw is that although ping replies are covered in the 'check-state' state checking machine, replies from routers to traceroutes do not seem to make it through, adding a rule like this (again at the end of your ruleset) fixes the problem: add allow icmp from any to any in icmptypes 11 See the security section in the FreeBSD handbook, and other sections on compiling your kernel, and the ipfw manpage, for more details. Happy script-kiddy hunting. Will On Thu, 4 Apr 2002, Bill Fumerola wrote: > On Thu, Apr 04, 2002 at 06:27:54PM -0500, Steve Shorter wrote: > > On Thu, Apr 04, 2002 at 03:19:01PM -0800, Bill Fumerola wrote: > > > > options IPSTEALTH > > > > > > this has nothing to do with ipfw or ipfilter. > > > > Hmm.. this adds a syctl parameter that when enabled > > causes the firewall to not decrease the ttl for packets that > > pass through it making it "invisible" to traceroute et al. > > ipfw and ipfilter don't decrement the ttl. > > > Or am I missing something? > > yes, the difference between a firewall and a router. > > -- Willie Viljoen Private IT Consultant 214 Paul Kruger Avenue Universitas Bloemfontein 9321 South Africa +27 51 522 15 60, a/h +27 51 522 44 36 +27 82 404 03 27 will@laserfence.net 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?20020408205232.W3388-100000>