ipfw query

Matthew Seaman m.seaman at plasm.demon.co.uk
Tue Jun 19 07:52:21 BST 2001


On Mon, Jun 18, 2001 at 10:40:14PM +0100, Richard Smith wrote:
> On Sun, Jun 17, 2001 at 11:17:30PM +0100, Matthew Seaman wrote:
> [snip]
> > add deny log all from any to any ipoptions rr
> > add check-state
> > add deny log tcp from any to any established
> > add allow tcp from me to any out via tun0 keep-state
> > add allow tcp from 194.217.242.0/24 to me 25 in via tun0 keep-state
> > add allow udp from me to any 53 out via tun0 keep-state
> > add allow udp from me 123 to any 123 keep-state
> > add allow icmp from me to any out
> > add allow icmp from any to me in icmptype 0,3,4,8,11,12
> > add unreach filter-prohib log icmp from any to any
> > add 65534 deny log ip from any to any
> [snip]
> > You seem to have the basic idea: the static rules default to denying
> > pretty much everything, except certain packets that can establish
> > particular connections.  Any new connection is recorded, and a time
> > limited dynamic rule is generated allowing tcp or udp or whatever
> > packets in either direction between a specific local ip+port and
> > remote ip+port.
> 
> I notice that only dynamic rules are being banded about in this thread,
> yet the default rc.firewall (with 4.3-R) uses it for one UDP rule only.

Two rules in the current /etc/rc.firewall as far as I can see --- I
have $FreeBSD: src/etc/rc.firewall,v 1.30.2.12 2001/03/06 01:58:02
obrien Exp $
 
> Is there an advantage to using the keep-state/check-state dynamic style
> over the setup/etablished static style of writing ipfw rules?

Absolutely yes. First of all, you can't use setup/established for
anything other than tcp.  Without dynamic rules, udp traffic has to be
enabled incoming and outgoing to all possible destinations: eg, with
static rules, you'ld need something like this for DNS [*]:

add allow udp from me to any 53 out via tun0
add allow udp from any 53 to me in via tun0

So an all an attacker needs to do to attack any service on your
machine, is to emit packets using a source port of 53. 

With dynamic rules, the default state is to not permit anything
incoming. Eg,

add check-state
add allow udp from me to any 53 out via tun0 keep-state

Even when you do make a DNS lookup, you are less exposed: the dynamic
rule that is established only allows connection from the specific IP
number of the server you queried and back to the originating port on
your own machine.

plasm# ipfw -at list
[snip]
00900 1 218 (T 0, # 186) ty 0 udp, xxx.xxx.xxx.xxx 1345 <-> 158.152.1.43 53
[snip]

Secondly, allowing incoming packets (whether udp or tcp without the
setup flag) exposes you to SYN-flood DOS attacks.  It's not a perfect
defense, as a lot of bandwidth would still be sucked up by the
flooding packets, but it will stop your machine wasting too many
cycles dealing with them.

> Particularly from a security standpoint?

The advantages are all in improved security.  Disadvantages are that
it adds complexity and uses up more system resources to achieve it's
end.  On a busy gateway machine you'll have to tune the
net.inet.ip.fw.dyn_buckets sysctl and so forth or you could run out of
space for dynamic rules.

It can also have annoying side effects: eg. with the ruleset above,
you clearly have to use passive mode FTP.  Even so, after a long
download --- empirically, longer than about 300s (the default for the
net.inet.ip.fw.dyn_ack_lifetime sysctl...), downloads would hang on
trying to close the connection.  Which makes installing from ports a
little trying.  Best solution I found was using Demon's proxy servers.
Add this line to /etc/make.conf:

FETCH_ENV=      "FTP_PROXY=http://www-cache.demon.co.uk:8080/ \
  HTTP_PROXY=http://www-cache.demon.co.uk:8080/"

	Cheers,

	Matthew

[*] Actually, this is where the "query-source address * port 53;"
directive in named.conf comes in useful, but you'ld have to run a
caching nameserver in that case.

-- 
Dr Matthew J Seaman MA, D.Phil.                          26 The Paddocks
                                                         Savill Way
                                                         Marlow
Tel: +44 1628 476614                                     Bucks., SL7 1TH UK




More information about the Ukfreebsd mailing list