[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Forwarded message from Christopher Klaus (SYN Flooding [info])
------- start of forwarded message (RFC 934 encapsulation) -------
Content-Length: 3804
Return-Path: [email protected]
Received: from brimstone.netspace.org ([128.148.157.143]) by chrome.DataSphere.NeT (8.7.5/8.7.3) with ESMTP id NAA05258 for <[email protected]>; Fri, 13 Sep 1996 13:20:11 -0700 (PDT)
Received: from netspace.org ([128.148.157.6]) by brimstone.netspace.org with ESMTP id <24730-24839>; Fri, 13 Sep 1996 14:27:52 -0500
Received: from netspace.org (netspace [128.148.157.6]) by netspace.org (8.7/8.6.12) with SMTP id OAA28644; Fri, 13 Sep 1996 14:27:19 -0400
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8b) with
spool id 397572 for [email protected]; Fri, 13 Sep 1996 14:23:31
-0400
Received: from netspace.org (netspace [128.148.157.6]) by netspace.org
(8.7/8.6.12) with SMTP id OAA27584 for <[email protected]>; Fri,
13 Sep 1996 14:19:44 -0400
Approved-By: [email protected]
Received: from phoenix.iss.net (phoenix.iss.net [204.241.60.5]) by netspace.org
(8.7/8.6.12) with SMTP id LAA05934 for <[email protected]>; Fri,
13 Sep 1996 11:02:26 -0400
Received: (from cklaus@localhost) by phoenix.iss.net (8.6.13/8.6.12) id
KAA06507 for [email protected]; Fri, 13 Sep 1996 10:58:24 -0400
X-Mailer: ELM [version 2.4 PL24 PGP2]
Content-Type: text
Approved-By: Christopher Klaus <[email protected]>
Message-ID: <[email protected]>
Reply-To: Christopher Klaus <[email protected]>
From: Christopher Klaus <[email protected]>
Sender: Bugtraq List <[email protected]>
To: Multiple recipients of list BUGTRAQ <[email protected]>
Subject: SYN Flooding [info]
Date: Fri, 13 Sep 1996 10:58:24 -0400
[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 [email protected] 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: [email protected] before the hackers do."
------- end -------
--
[:]====================================================================[:]
[\] Mycroft <[email protected]> >>>>>[DataSphere]<<<<< [=]
[=] Key fingerprint = DD B1 A7 D9 2D DF A0 F7 23 C2 6B EC 5A AD 01 A9 [\]
[:]====================================================================[:]