Re: SYN floods
PANIX, a large public access provider in New York, was badly hit with
SYN flood attacks from random source addresses over the last few
days. It nearly wrecked them.
I think its time for the larger providers to start filtering packets
coming from customers so that they only accept packets with the
customer's network number on it.
Yes, its a load on routers. Yes, its nasty for the mobile IP weenies.
Unfortunately, the only known way to stop this. Many TCPs go belly up
as soon as they get SYN flooded -- its a defect in the protocol
design, and other than Karn style anti-clogging tokens ("cookies")
being put into a TCP++ and mass implemented worldwide soon, the only
reasonable way to stop this sort of terrorism is provider filtering.
Perry
I disagree. A better way to do this would be for providers to cooperate to
track down the people who are doing it and make sure to flood the media
with press releases when the culprits are arrested. If the cracker
wannabe's realize that source-spoofed SYN attacks can still be quickly
traced, they will stop doing it.
And the cooperation would do the net some good; maybe lead to more
cooperation down the line.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
On my private network I can send 600 or more SYN packets to my telnet port
(w/faked, unreachable source addresses + random seq numbers), yet the
port doesn't seem to be flooded.
It's a linux box.
The telnet daemon seems to be able to tell the difference between a faked
packet and a real one. Even when spoofing from localhost, it reports a
connection from unknown.
Obviously, there seems to be a solution to this problem. ??
On my private network I can send 600 or more SYN packets to my telnet port
(w/faked, unreachable source addresses + random seq numbers), yet the
port doesn't seem to be flooded.
It's a linux box.
The telnet daemon seems to be able to tell the difference between a faked
packet and a real one. Even when spoofing from localhost, it reports a
connection from unknown.
Obviously, there seems to be a solution to this problem. ??
I'd like to see this. First of all, the telnet daemon never sees the SYN.
The SYN is responded to by the kernel (with a SYN/ACK).
taner@BOOM:ttyp6 (Linux) ~/code >./syn
./syn srchost dsthost port num
taner@BOOM:ttyp6 (Linux) ~/code >./syn 1.2.3.4 boom.net 23 10
synflooding boom.net from 1.2.3.4 port 23 10 times
Now to try to connect to it...
taner@nic:~ >telnet boom.net
Trying 134.24.7.153 ...
telnet: connect: Connection timed out
And why?
taner@BOOM:ttyp6 (Linux) ~ >netstat -tn | grep 1.2.3.4
tcp 0 1 134.24.7.153:23 1.2.3.4:59914 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:60170 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:60426 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:60682 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:60938 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:61194 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:61706 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:61962 SYN_RECV root
tcp 0 1 134.24.7.153:23 1.2.3.4:62218 SYN_RECV root
taner@BOOM:ttyp6 (Linux) ~ >uname -a
Linux BOOM.NET 2.0.0 #5 Sun Sep 1 21:34:31 PDT 1996 i486
Looks like Linux can only queue 9 SYN's...
-Taner
-=-=-=-=-=-=-=-=-=-=-=-=[ D. Taner Halicioglu ]=-=-=-=-=-=-=-=-=-=-=-=-
taner@CERF.NET -=- taner@ucsd.edu -=- taner@sdsc.edu
IRC Admin: irc.cerf.net -=- U. of California, San Diego, Computer Sci.
taner@cisco.com -=- Cisco Systems -=- Enterprise Network Management
-=-=-=-=-=-=[ Linux 2.0.* OS -- http://www.sdsc.edu/~taner/ ]=-=-=-=-=-