[739] in Intrusion Detection Systems
No subject found in mail header
daemon@ATHENA.MIT.EDU (-= IDS Moderator =-)
Wed Sep 25 04:31:33 1996
From: ruf@uow.edu.au (-= IDS Moderator =-)
To: ids@uow.edu.au (Intrusion Detection System Mailing List)
Date: Wed, 25 Sep 1996 13:24:23 +1000 (EST)
Reply-To: ids@uow.edu.au
Responses to c4i-pro Denial-of-service at panix
> Re: Denial Service Attacks
> Saturday night someone in the group suggested that working with the local
> LEC or carrier and pinpointing the NPA or NXX of the attack then blocking
> calls from that NXX was an option. I know that would take prior
> arrangements but would it work. yes I know the attacker could shift the
> attack but I was just asking if this was an option from a telecom side.
> If it is a dumb questions please excuse me, I am new to this.
> Bill Church
It seems that by allowing this article some people have confused
the attack to one originating from dialins.. rather TCP/IP packets coming
from the Internet. Please read the technical details from phrack.
http://www.fc.net/phrack/files/p48/p48-14.html
Briefly the attack involves flooding with TCP SYN requests, which can be
used to fill up the backlog queue for connections on a port (further requests
ie. legitimate ones will not be possible). It is achieved by spoofing the
SRC address (of the TCP SYN request) with the IP of a unreachable host.
It is due to TCP considering the ICMP host-unreachable response (in response
to the attacked hosts SYN/ACK) to be a transient error. Also the attack
can use random unreachable hosts and target all ports.
A post on the ISS alert mailing list suggested possible solutions..
From: Christopher Klaus <cklaus@iss.net>
Message-Id: <199609131505.LAA06646@phoenix.iss.net>
Subject: SYN Flooding [info]
Date: Fri, 13 Sep 1996 11:05:06 -0400 (EDT)
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."
-----------------------------------------------------------------------------
Message-Id: <199609230623.BAA18772@telepath.com>
From: "darkpoet" <brianc@telepath.com>
Date: Mon, 23 Sep 1996 01:21:06 -0500
the only dumb thing was assuming it was dumb, for people that have an
answer, they had to ask the question... don't worry, it's alright...
okay, the denial of service attacks are coming in over the internet.
therefore blocking calls would have no effect on it since they are not
demon-dialing. if there were demon-dialing, this would be 200% easier to
fight, but they are using ip-spoofed syn packets.. almost untraceable,
but if you can get a glimpse of the header, you can see from which servers
it's hopping from, and trace the packet back down pretty close to where
it's coming from. but even that's not going to guarantee you a path to the
attacker, more like a general heading.
i've got some people working together to find a way to defeat it.. who
knows, we may get lucky.
brianc@telepath.com
darkened horizons, ltd.
-----------------------------------------------------------------------------
Message-Id: <9609240044.AA10948@raptor.icubed.net>
From: ScottMorris <smorri59@icubed.net>
Date: Mon, 23 Sep 96 20:44:04 EDT
Yes it would take prior arangements with the Telco as a trap & trace
would be necessary, but this can be requested by the dialed party. However
any intelligent person launching the attack will be using an outdial
somewhere which can't be traced to them. You would however weed out the
shallow end of the gene pool. Also if you shutdown an entire NPA-NXX you
just shutdown 10000 (0000-9999) lines, not all or any of whom are guilty.
If the individual can be traced to an outdial the party whose line
is being misused may appreciate knowing this and could be enticed :) to
assist by having a T&T placed on that line.
-----
Scott L. Morris Systems Security Consultant
smorri59@icubed.net Data Forensics
Finger smorri59@ally.ios.com for my pgp public key.
-----------------------------------------------------------------------------
Message-ID: <01BBA9B7.02A99C80@seena.earthlink.net>
From: Masoud Safi <seena@armenia.it.earthlink.net>
Date: Mon, 23 Sep 1996 23:57:30 -0700
There are many many other ways than dialup services to get in to the =
Net. Blocking an NPA-NXX will result in blocking a big range of people =
from dialing those numbers.
The idea is to prevent people from accessing your propriatory data ever.
Masoud.
-----------------------------------------------------------------------------
--
+---------------------+--------------------------------------------------+
| ____ ___ |-= Justin Lister email: ruf@uow.edu.au =-|
| | \\ /\ __\ | Center for Computer Security Research (CCSR) |
| | |) / \_/ / |_ | Dept. Computer Science, University of Wollongong |
| | _ \\ /| _/ | ZenMsg: Computer Security a utopian dream.|
| |_/ \/ \_/ |_| (tm) |-= prefix: +61-42 =- Disclaimer: dream own risk.|
| |-= fax: 214329 mobile: 0412139269 voice: 835114 =-|
+---------------------+--------------------------------------------------+
