[1904] in linux-security and linux-alert archive
[linux-security] Re: Linux and IPFWADM
daemon@ATHENA.MIT.EDU (Bernhard Weisshuhn)
Fri Jun 19 03:38:31 1998
Date: Wed, 17 Jun 1998 09:45:42 +0200
From: Bernhard Weisshuhn <bkw@weisshuhn.de>
To: linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.96.980616003614.3348D-100000@seifried-gateway.seifried.org>; from seifried@seifried.org on Tue, Jun 16, 1998 at 12:41:53AM -0600
Resent-From: linux-security@redhat.com
Resent-Reply-To: linux-security@redhat.com
seifried@seifried.org (seifried@seifried.org) wrote:
> # Deny ALL ICMP from external.
> #
> ipfwadm -I -a deny -P icmp -S 0.0.0.0/0 -W eth0 -D 0.0.0.0/0
> ipfwadm -O -a deny -P icmp -S 0.0.0.0/0 -W eth0 -D 0.0.0.0/0
You don't want to disable all icmp. It disables MTU discovery. Quoting
the ipchains-howto
( http://www.adelaide.net.au/~rustcorp/ipfwchains/HOWTO.html )
A worse problem is the role of ICMP packets in MTU discovery. All
good TCP implementations (Linux included) use MTU discovery to try to
figure out what the largest packet that can get to a destination
without being fragmented (fragmentation slows performance, especially
when occasional fragments are lost). MTU discovery works by sending
packets with the "Don't Fragment" bit set, and then sending smaller
packets if it gets an ICMP packet indicating "Fragmentation needed but
DF set" (`fragmentation-needed'). This is a type of `destination-
unreachable' packet, and if it is never received, the local host will
not reduce MTU, and performance will be abysmal or non-existant.
> # Allow ftp-data (20) connections incoming to internal clients (1024:65535)
> #
> ipfwadm -I -a accept -P tcp -S 0.0.0.0/0 20 -D 0.0.0.0/0 1025:65535
You should only allow these connections, if you are absolutely positve
there are no other services running in the 1025:65535 range, that you
have not taken care of seperately. It is way too easy to make a
connection come from port 20, security measures should not rely on the
client behaving pc.
A better way IMHO is to force the clients to use PASV-ftp (every client
out there supports it) and let an internal squid forward ftp-requests
from www-browsers to an external parent, or use some other ftp-proxy.
> # Allow named (udp 53) connections incoming to clients (1024:65535)
> #
> ipfwadm -I -a accept -P udp -S 0.0.0.0/0 53 -D 0.0.0.0/0 1025:65535
AFAIK big chinks of dns data are transported via tcp (and not only zone
transfers). So you should also allow tcp. Then again, there is this
tunneling issue (published in phrack I think), but this can bite you
on any other other ports as well.
[mod: I thought only zone transfers were done using tcp. Anybody know
for sure? (Yes, nslookup also uses tcp if you use the "ls" command,
but it just pretends being another named doing a zone transfer) -- REW]
Rather than gathering material on ipfwadm, I think we should all turn
our heads towards ipchains, the excellent new firewalling implementation
by Paul Russel, that is already in the new 2.1 kernels. This is the way
to go, IMHO.
Check out http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html
and let's work on some basic setup we all can agree on. The Howto has
some examples already.
just my 2 Pfennig,
Bernhard
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
