[4465] in North American Network Operators' Group
Re: New Denial of Service Attack on Panix
daemon@ATHENA.MIT.EDU (Rashid Karimov)
Tue Sep 17 09:51:59 1996
From: Rashid Karimov <rashid@rk.ios.com>
To: michael@memra.com (Michael Dillon)
Date: Tue, 17 Sep 1996 09:46:55 -0400 (EDT)
Cc: nanog@merit.edu, iepg@iepg.org
In-Reply-To: <Pine.BSI.3.93.960916191246.3265P-100000@sidhe.memra.com> from "Michael Dillon" at Sep 16, 96 07:32:48 pm
How exactly proxy is supposed to behave
when it "hangs onto" say 10.000 + unfinished
TCP connections ? Will it deny new ones (because
resources are always limited) ?
Looks like it's the only thing it will be able
to do and as soon as first packet is denied,
hacker's won.
As hard as it is to be implemented the only way
to fight this is have every single ISP to filter
outgoing packets.
Assuming big players have enough desire they can do it
quickly by making an offer smaller ISPs can't refuse,
the same kind Sprint made when it started filtering
small CIDRs.
It's certainly harder to catch those who don't comply
though ...
Interestingly enough, the source IP's could be valid,
then it becomes even harder to see if the TCP connection
request is valid or bogus. And once again, source filtering
by ea and every AS looks like the only solution.
>
> On Mon, 16 Sep 1996, Craig A. Huegen wrote:
>
> > The SYN flood coming towards my host X looks like this, at approximately
> > 2,000 PPS:
> >
> > 182.58.239.2.1526 -> 172.30.15.5.80 TCP SYN
> > 19.23.212.4.10294 -> 172.30.15.5.80 TCP SYN
> > 93.29.233.68.4355 -> 172.30.15.5.80 TCP SYN
> > [... on and on ...]
> >
> > Tell me how to filter this.
>
> The only thing that comes close to the concept of "filtering" is to build
> a SYN proxy that replies with SYN-ACK and hangs onto SYN packets until the
> ACK is received from the net before actually letting the packets through
> to your server. This may require sequence number munging on every packet
> but that's generally the kind of thing proxies do.
