[4378] in linux-net channel archive
(fwd) BoS: Tool for stopping SYN floods
daemon@ATHENA.MIT.EDU (Olaf Titz)
Sat Sep 14 13:12:21 1996
To: submit-linux-dev-net@ratatosk.yggdrasil.com
From: Olaf Titz <olaf@bigred.inka.de>
Date: 14 Sep 1996 12:19:17 +0200
The solution prevented below looks very simple, could this be a
possible way out of the problem?
> Christopher Klaus <cklaus@iss.net> said:
>
> [Below we have a software tool that will recognize SYN floods and correct
> the problem.]
>
> Possible solution to SYN Flooding attacks
>
> The attack is on! Both 2600 and Phrack, 2 of the biggest well-known
> underground hacking magazines, have posted exploit code to do one of the
> nastiest denial of service attacks that the Internet has seen so far.
> Hundreds of people have access to these programs to bring down services on
> the Internet. Many of these people are targeting their attacks at various
> organizations such as ISP. Panix, an ISP, has been under attack for quite
> a few days now and they have not been able to receive email. Many other
> ISPs are suffering from the SYN flood attack. This attack is being
> discussed on many mailing lists, newsgroups, and Thursday's Wall Street
> Journal (9/12/96). Fortunately a solution already exists as we discuss
> below.
>
> Everyone connected to the Internet relies on TCP/IP. When you establish a
> connection with TCP, you do a 3-way handshake. The connecting host sends
> a SYN packet to the receiving host. The receiving host sends a SYN|ACK
> packet back and to fully establish a connection, the connecting host
> finally responds with an ACK packet.
>
> In a SYN flood attack, an attacker host sends many SYN packets and does
> not respond with an ACK to the SYN|ACK's. As the receiving host is
> waiting for more and more ACK's, the buffer queue will fill up and the
> receiving machine can no longer accepts legitimate connections. This means
> that attackers can block your email, web, or any other service you are
> providing on the Internet.
>
> To even make this attack worse, the code exploiting the problem randomizes
> the source address of the attacking host. Thus, the receiving machine
> gets packets that appear to be from all over the Internet, hiding the
> location of the attacker.
>
> Solution
>
> There are several things we can do to stop these attacks from being
> effective.
>
> With the routers for most ISP, they should be blocking any non-internal
> addresses from leaving their network and going to the Internet. This will
> stop an attacker if their ISP implements this. Unfortunately, this does
> not stop an attack from areas on the Internet that do not block that. But
> at least the ISP can feel comfortable to know that an attacker can not
> launch his attack from that ISP.
>
> Here are two methods of helping eliminate the problem. Some of the
> exploit code I have seen does not pick a random source port. It would be
> easy to block the attack with a router denying any packets coming from a
> specific source port. This may not be too effective because of the trivial
> nature of adding code to randomize the source port, sequence number,
> source address, and TTL. But it might help you temporarily if you notice
> the attacks have any pattern that can be blocked by router rules.
>
> Another way to fix this is to set the kernel maximum number of half open
> connections allowed (SO_MAXCONN) to a higher number than the default value.
> We have a tool that will look for SYN packets that do not get followed with
> ACK and clean the half open connections by sending a RST packet. This
> unclogs the port and allows legitimate connections to happen. This tool
> is called RealSecure (tm). To obtain a copy of the RealSecure tool,
> send email to majordomo@Iss.net and within the body of the message, type:
>
> subscribe realsecure
>
> RealSecure (tm) is a comprehensive attack recognition and real time response
> tool that ISS is alpha testing and will expire in 60 days.
>
> --
> Christopher William Klaus Voice: (770)395-0150. Fax: (770)395-1972
> Internet Security Systems, Inc. "Internet Scanner finds Ste. 660,41
> Perimeter Center East,Atlanta,GA 30346 your network security holes Web:
> http://www.iss.net/ Email: cklaus@iss.net before the hackers do."
>
> ========================================================================
> Kenneth L. Hamer <a href=http://www.uiuc.edu/ph/www/k-hamer>WWW Page</a>
> k-hamer@uiuc.edu
> SENILE.COM found . . . Out Of Memory . . .
>
--
___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
__ o <URL:http://www.inka.de/~bigred/> <IRC:praetorius>
__/<_ >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____
