[21925] in bugtraq

home help back first fref pref prev next nref lref last post

Re: UDP packet handling weird behaviour of various operating systems

daemon@ATHENA.MIT.EDU (Sean Hunter)
Fri Jul 27 11:38:36 2001

From: "Sean Hunter" <sean@uncarved.com>
Date: Fri, 27 Jul 2001 08:56:15 +0100
To: Stefan Laudat <stefan@mail.allianztiriac.ro>
Cc: Paul Sack <paulsack@mail.utexas.edu>, bugtraq@securityfocus.com
Message-ID: <20010727085615.A5086@uncarved.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
In-Reply-To: <20010726015959.C31276@allianztiriac.ro>; from stefan@mail.allianztiriac.ro on Thu, Jul 26, 2001 at 01:59:59AM +0300

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I was entirely unable to duplicate the problem on my linux-2.4.7 box, and t=
his
is why:

Firstly, I apply some rate throttling on incoming and outgoing packets thus=
sly...

#jump to connection throttling table
$IPTABLES -t filter -A INPUT -j in-throttle

echo -n "    rate throttling: "
#syn flood limit
$IPTABLES -t filter -A in-throttle -j RETURN        -p tcp -m tcp --tcp-fla=
gs SYN,RST,ACK SYN     -m limit --limit 10/sec
$IPTABLES -t filter -A in-throttle -j rate-logdrop  -p tcp -m tcp --tcp-fla=
gs SYN,RST,ACK SYN
#rst flood limit
$IPTABLES -t filter -A in-throttle -j RETURN        -p tcp -m tcp --tcp-fla=
gs FIN,SYN,RST,ACK RST -m limit --limit 10/sec
$IPTABLES -t filter -A in-throttle -j rate-logdrop  -p tcp -m tcp --tcp-fla=
gs FIN,SYN,RST,ACK RST
$IPTABLES -t filter -A in-throttle -j RETURN        -p tcp
#icmp rate limit
$IPTABLES -t filter -A in-throttle -j RETURN        -p icmp                =
                       -m limit --limit 25/sec
$IPTABLES -t filter -A in-throttle -j RETURN        -p udp                 =
                       -m limit --limit 25/sec
#log the flood
$IPTABLES -t filter -A in-throttle -j LOG -m limit --limit 10/min --log-pre=
fix "FW-IN-THROTTLE: "

#enable this to debug inbound flood throttling
#$IPTABLES -t filter -A in-throttle -j RETURN
#normally this is the policy
$IPTABLES -t filter -A in-throttle -j DROP

=2E..I do the same sort of thing outgoing.  YMMV, I am not a qualified doct=
or etc
etc etc.  You may have to tweak the limits to make them suitable for your s=
ite,
but they work for me.

The next reason is that I proc rate limit icmp traffic thussly:

net.ipv4.icmp_destunreach_rate =3D 50
net.ipv4.icmp_echoreply_rate =3D 50
net.ipv4.icmp_paramprob_rate =3D 50
net.ipv4.icmp_timeexceed_rate =3D 50

net.ipv4.icmp_ignore_bogus_error_responses =3D 1
net.ipv4.icmp_echo_ignore_broadcasts =3D 1

On most modern linux systems you can add these lines to /etc/sysctl.conf an=
d go
"sysctl -p" to install them.

on others you have to tweak /proc by hand, doing:

echo 50 > /proc/sys/net/ipv4/icmp_destunreach_rate

etc etc.

Finally, you should really firewall all traffic (including, but not limited=
 to,
biff) that you don't really really have to serve[1] and that goes for udp a=
nd
tcp.  And don't ignore the loopback interface or your local users may bite =
you.

Hope this helps

Sean

[1] Strangely, I need to open the biff port on the loopback interface or I =
get
packet logs.  I haven't had the chance to track that down yet.

On Thu, Jul 26, 2001 at 01:59:59AM +0300, Stefan Laudat wrote:
> > Most UDP packets should be firewalled from the Internet.
>=20
> Agree.
>=20
> > This is only really useful if someone has access to the local network. =
Is
> > Linux/UP actually *locking* or just temporarily unresponsive? Also, it =
is
> > invalid to compare Windows ME running on $3000 hardware with Linux/*BSD
> > running on an old Pentium. Are you running all of this on the same
> > hardware? Obviously faster hardware is going to be affected less by a U=
DP
> > flood. How about the network cards?
>=20
> Identical network cards for Win2k, Linux SMP and OpemBSD processor (Intel
> Pro 100). Linux was run on dual p3/1Ghz(SMP), Pentium2/400Mhz and P3/800M=
hz
> (UP). Windows 2000 was run on p3/1Ghz UP. I've made tests with same resul=
ts
> against Linux UP boxes running on Celeron/600 with 3com Vortex and realtek
> 8139 NICs. I've outlined that the result is the same no matter if you hit
> via 1Gbit or 100Mbit.=20
>=20
> > I am suspicious that you are just comparing hardware, given that differ=
ent
> > versions of W2K perform much differently in your analysis. (You said the
> > load was server: 35%, professional: 60%) I somehow doubt that MS tuned =
the
> > network stack so much on the ``server'' version & wouldn't do the same =
on
> > the ``professional'' version.
>=20
> Some of the Linux servers have just the same configuration with the w2k
> servers. The reaction IS different. That's what amazes me. Also WinME was
> run on a cheap p2/350 box with an old intel NIC. No slowdown at all :(
>=20
> > I bet a Sun E10K with lots of NICs could flood the Sun UE3500 with lots=
 of
> > NICs, but that probably doesn't mean that the Solaris 8 network stack is
> > better than the Solaris 8 network stack; it's because the E10K is faste=
r.
>=20
> well then someone will clear all this stuff for me.
>=20
> --=20
> Stefan Laudat
> CCNA,CCAI
> Senior Network Engineer
> Allianz-Tiriac SA
>=20
> "Let's call it an accidental feature."
>         -- Larry Wall

--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7YR6eAgJf0xrWsZwRAnaTAJwJL/aQL2tW12fibyNDqr3ezXgEYQCeJyWH
dIIO3vhqYCIHx3BxKepe4IQ=
=C3W1
-----END PGP SIGNATURE-----

--tThc/1wpZn/ma/RB--

home help back first fref pref prev next nref lref last post