From owner-freebsd-net Wed Jul 12 0:21:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 1E10837B736 for ; Wed, 12 Jul 2000 00:21:37 -0700 (PDT) (envelope-from mike@adept.org) Received: by snafu.adept.org (Postfix, from userid 1000) id 09E899EE01; Wed, 12 Jul 2000 00:21:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id EB6CD9B001 for ; Wed, 12 Jul 2000 00:21:35 -0700 (PDT) Date: Wed, 12 Jul 2000 00:21:35 -0700 (PDT) From: Mike Hoskins To: freebsd-net@freebsd.org Subject: BSD Firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I'm relatively new to BSD-based firewalling, and have a couple questions... Hopefully, this is the right forum. I'm running 4.0-STABLE with ipfw... FreeBSD snafu.adept.org 4.0-STABLE FreeBSD 4.0-STABLE #0: Sat Jul 8 01:18:17 PDT 2000 mike@snafu.adept.org:/usr/src/sys/compile/SNAFU i386 I have a privately addressed /24 on fxp1, and a DSL connection on fxp0. The box also runs NATD. My ruleset is as follows: 00100 divert 8668 ip from any to any via fxp0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 01000 check-state 01100 allow ip from 63.201.63.44 to any keep-state 01200 allow ip from 192.168.0.0/24 to any keep-state 01300 allow tcp from any to 63.201.63.44 80 setup 01400 allow tcp from any to 63.201.63.44 443 setup 01500 allow tcp from any to 63.201.63.44 22 setup 01600 allow tcp from any to 63.201.63.44 25 setup 01700 allow tcp from 206.136.108.7 to 63.201.63.44 53 setup 01800 allow udp from 206.136.108.7 to 63.201.63.44 53 01900 allow udp from 63.201.63.44 53 to any 02000 allow tcp from 204.152.184.72 to 63.201.63.44 123 setup 02100 allow udp from 204.152.184.72 to 63.201.63.44 123 02200 allow tcp from any to 63.201.63.44 113 setup 02300 allow udp from any to 63.201.63.44 113 65535 deny ip from any to any 1000-2300 are my rules, the rest are system defaults. The intent is to allow anything out (statefully), since it's a small, 'trusted' LAN, and allow only HTTP, SSL, SSH, SMTP, DNS, NTP and IDENT in. This seems to work... but, having never played with ipfw before AND only finding decent refernece in ipfw(8), does this look ok? I looked for the old ipfw examples site, but it seems to have moved. One problem was the existence of example rules w/o an explanation of why the rule was needed or what it really did... Primarily, I had some confusion over: In order to protect a site from flood attacks involving fake TCP packets, it is safer to use dynamic rules: ipfw add check-state ipfw add deny tcp from any to any established ipfw add allow tcp from my-net to any setup keep-state Ok... I want to be protected from flood attacks (and this, indeed, seems to be the problem noted below), but why is the deny placed before the allow? I'd thought the 'rule chain' was inspected on a first-match basis. I didn't understand this, and, as best I remember, this didn't work for me... so I made modifications (remove rule, test, add rule, test, etc...) until something both worked and looked 'sane'. Furthermore, inspection of /etc/rc.firewall yielded confusion when I noted that the 'simple' firewall explicitly adds 'deny' statements... Is this really needed when the final rule in the chain is to deny all? I noticed the following warnin in ipfw(8) relating to stateful operation: BEWARE: stateful rules can be subject to denial-of-service attacks by a SYN-flood which opens a huge number of dynamic rules. The effects of such attacks can be partially limited by acting on a set of sysctl(8) variables which control the operation of the firewall. Is said 'SYN-flood' externally originated or internally? Like I mentioned above, I don't have to worry about internal hosts... As for external... How do the kernel options TCP_DROP_SYNFIN and TCP_RESTRICT_RST handle SYN floods? A day or so after setting up ipfw, I started notcing that when I would ssh to my gw from work, my connection would freeze up... If I opened a new ssh session, it'c connect immediately... but leaving it idle for any time at all (well, 5-10 seconds) would result in another freeze. I have net.inet.icmp.icmplim set to 200, and noticed 'icmp-response bandwidth limit 223/200 pps' in messages... repeated many times. My first thought was some valid service or a misconfiguration of ipfw since I'm new to this... but inspection of ipfw list|wc yielded almost 1000 dynamic rules... most of which, when verified, I could not account for. These were rules from a single, remote IP (technical contacts for supporting network(s) contacted) which I had never heard of... It seems that, somehow, the remote user was 'tricking' the fw into injecting dynamic rules into my chain. System performance was getting slower, and I figured this was the real reason for my ssh freezes. Now... I turned net.inet.ip.fw.dyn_max down to 256, net.inet.ip.fw.dyn_ack_lifetime to 200, flushed and reloaded my ruleset... Now ipfw list|grep for the source IP yields a high number of port 80 rules... Yet I have not accessed the remote host's webserver. This is different than before, however, as the previously generated rules seemed to my random ports. I've just cvsup'd and rebuilt my system... To ensure the recent security release relating to ip options isn't to blame... but I had built after that release... Which leads me to believe there is still an ipfw misconfiguration I'm overlooking. Pointers please... -mrh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message