------- start of forwarded message (RFC 934 encapsulation) ------- Content-Length: 3804 Return-Path: owner-bugtraq@NETSPACE.ORG Received: from brimstone.netspace.org ([128.148.157.143]) by chrome.DataSphere.NeT (8.7.5/8.7.3) with ESMTP id NAA05258 for <mycroft@DATASPHERE.NET>; 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 BUGTRAQ@NETSPACE.ORG; 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 <BUGTRAQ@NETSPACE.ORG>; Fri, 13 Sep 1996 14:19:44 -0400 Approved-By: ALEPH1@UNDERGROUND.ORG 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 <bugtraq@netspace.org>; 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 bugtraq@netspace.org; Fri, 13 Sep 1996 10:58:24 -0400 X-Mailer: ELM [version 2.4 PL24 PGP2] Content-Type: text Approved-By: Christopher Klaus <cklaus@ISS.NET> Message-ID: <199609131458.KAA06507@phoenix.iss.net> Reply-To: Christopher Klaus <cklaus@iss.net> From: Christopher Klaus <cklaus@iss.net> Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG> To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG> 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 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." ------- end ------- -- [:]====================================================================[:] [\] Mycroft <mycroft@datasphere.net> >>>>>[DataSphere]<<<<< [=] [=] Key fingerprint = DD B1 A7 D9 2D DF A0 F7 23 C2 6B EC 5A AD 01 A9 [\] [:]====================================================================[:]