Date: Wed, 12 Jul 2000 00:21:35 -0700 (PDT) From: Mike Hoskins <mike@adept.org> To: freebsd-net@freebsd.org Subject: BSD Firewall Message-ID: <Pine.BSF.4.21.0007112353320.21280-100000@snafu.adept.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007112353320.21280-100000>