SYN-flood
Martin Mačok
martin.macok at underground.cz
Mon Aug 28 23:52:49 CEST 2000
On Mon, Aug 28, 2000 at 12:55:21PM +0200, David Rohleder wrote:
> > Mohl by mi nekdo vysvetlit pojem "SYN-flood attack"? Dojde k
> > zahlceni systemu zaplnenim swapu, nebo jak?
>
> SYN-flood je prilis mnoho pokusu o otevreni TCP spojeni.
Navic se typicky posilaji SYN pakety se zfalsovanou zpetnou neexistujici
IP adresou, cimz se vyuzije plne ten casovy interval (loophole, timeout)
pro handshake pri vytvareni TCP spojeni. Bez zfalsovane zpetne adresy to
neni ucinne ;-]
> Protoze system si pri kazdem pokusu o spojeni alokuje jistou pamet, a
> ma vetsinou limity na pocty otevrenych spojeni. Takze kdyz nekdo
> vyzere pamet nebo ten limit, tak uz se nikdo jiny nepripoji. Pak jsou
> jiste limity na delku polootevreneho TCP spojeni, pak se spojeni
> uzavre a pamet se uvolni. (detaily: RFC pro TCP)
A ja bych jen doplnil pro zvidave :) nejake odkazy:
http://www.securityserver.com/cgi-local/ssis.pl/docs/tcpip2.htm
http://www.clark.net/pub/mjr/pubs/attck/
(pokud ty odkazy nefunguji, tak omluvte zub casu mych starych bookmarks)
Prikladam jeste nejake zajimave emaily ze zahranicnich konferenci
(v anglickem jazyce) na tema SYN flooding.
enjoy
--
< Martin Mačok martin.macok at underground.cz <iso-8859-2>
\\. http://kocour.ms.mff.cuni.cz/~macok/ http://underground.cz/ .//
\\\.. .-= t.r.u.s.t n.0 o.n.e =-. ..///
NELAMTE SI HLAVU Z KONCE SVETA
ALLAH JE DOST CHYTRY, ABY MEL SCHOVANY ZALOZNI DISK
-------------- next part --------------
>From owner-linux-security at tarsier.cv.nrao.edu Sat Aug 24 16:23:57 1996
From: infinity <route at infonexus.com>
Message-Id: <199608221549.IAA15611-RESENT at onyx.infonexus.com>
Subject: Re: [linux-security] inetd and denial-of-service
To: shagboy at bluesky.net
Date: Thu, 22 Aug 1996 08:49:02 -0700 (PDT)
Cc: linux-security at tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.960821225700.133A-100000 at cirrus.bluesky.net> from "Racer X" at Aug 21, 96 11:19:14 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 5780
Sender: owner-linux-security at tarsier.cv.nrao.edu
Precedence: list
-----BEGIN PGP SIGNED MESSAGE-----
Racer X's thoughts were:
| I started thinking about this a couple of days ago (right after I read
| the source for the SYN-flooder in the latest 2600). I thought of a way
| to at least try to avoid total denial-of-service.
|
| >From the sources I have seen for SYN-flooders, they generally forge the
| source address. One style is to generate random source addresses, the
By very defintion of a SYN flood, the source address has to be
forged.
| other is to take a user-specified address. A way around the first style
| is this:
A randomly generated source address would be a horrible idea. You
have a better than even chance of generating one that is reachable.
| If the max number of connects per unit time is passed, stop the server
| for (say) 1 or 2 minutes. Then try to reverse DNS all those connects on
| that port. Any that can't be reversed should be immediately dropped.
A host may have DNS entries and still be unreachable (and vice
versa).
| Once you're back under the limit, restart the server.
SYN flooding doesn't attack TCP-based servers so much as it
attacks the TCP kernel. The monitoring and actions taken
should reflect this...
| You could get around the second style by specifying a max number of
| connects to accept from any one site at a time. However, passing this
| limit would not shut down the server, it would just deny that site until
| it was back under limit.
Bad idea. You cannot control any aspects of the Internet past yur
box (or boxes). Therefore, you cannot control which hosts will go
down. (Aside: I've thought about coding a SYN flooder that plays
two reachable hosts off each-other. It floods both, exactly at
the same time, each SYN-ladden packet purporting to come from the
other host on it's flooded port.)
| The more I think about this though, the more it seems this would be
| better implemented in TCP wrappers (tcpd). It doesn't seem TOO difficult
| to do, although I'm not sure if you would have to do anything in kernel
The best way to do this is in the kernel. Briefly: A list of
concurrent pending connection requests needs to be kept for
each TCP port that is listen()ing. When this number of
connection requests reachs n (n==backlog, or n==backlog-1)
it does a few other checks, like perhaps the time in which all
of these arrived (connections that arrive very close together
would be indicative of a SYN flood) and it waits a few seconds.
if the state does not proceed into SYN_SENT or CLOSED it frees
the associated memory and tears down all the connection requests.
The n value should be different for different ports. TCP/80 for
example, would see it being higher...
| space too. For instance, if you have a connect that is in state
| SYN_RECV, can you just arbitrarily drop it, or do you have to wait for
| something to timeout in the TCP code?
The TCP Connection-Establishment timer of 75 seconds causes
connections to time out. In Linux however, this is not the
case. Below is an excerpt from my whitepaper I did on TCP
SYN flooding (from Project Neptune available in the next
issue of Phrack).
- ------------------------------------Excerpt-------------------------------
--[ Linux Anomaly ]--
In doing my research for this project, I noticed a very strange
implementation error in the TCP module of Linux. When a particular TCP
server is flooded on a Linux host, strange things are afoot... First, it
appears that the connection-establishment timer is broken. The 10 spoofed
connection-requests keep the sockets in the SYN_RCVD state for just
over 20 minutes (23 minutesto be exact. Wonder what the signifigance of
this is... Hmmm...). Much longer than the 75-seconds it *should* be. The
next oddity is even more odd... After that seemingly arbitrary time period
(I have to determine what the hell is going on there), TCP moves the flooded
sockets into the CLOSE state, where they *stay* until a connection-request
arrives on a *different* port. If a connection-request arrives on the
flooded port (now in the CLOSE state), it will not answer, acting as if it
is still flooded. After the connection-request arrives on a different port,
the CLOSEd sockets will be destroyed, and the original flooded port will be
free to answer requests again. It seems as though the connection-request
will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask
me...
The implications of this are severe. I have been able to completely
disable all TCP based servers from answering requests indefinitely. If all
the TCP servers are flooded, there are none to recieve the valid connection
request to alleviate the CLOSE state from the flooded connections. Bad
news indeed.
- ------------------------------------Excerpt-------------------------------
I have since learned a few things from Erik Schenk...
1) The Linux TCP kernel does not directly setup timers for connection
establishment or keepalive timeouts.
2) The Linux TCP kernel counts retransmissions.
3) It takes 15 retransmission before a pending connection request is
torn down. This is 1389 seconds, or 23 minutes...
This is to say that a Linux box is painfully vulnerable to
SYN floods. There is a patch in the works...
- --
[ route at infonexus.com ] Editor, Phrack Magazine / Guild Corporation Chair
the greatest trick the devil ever pulled was
convincing the world he didn't exist
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMhyBbQtXkSokWGapAQFZwgQAl6oljDTIflypKJRSXvCfkzwOIK7rU4Uq
t+lkIfnqsLMxH1hgSGxOIUaV2lA7gn6wdesKoDxqv9xpKAU7PpyfpQxZkTdVyGTS
nffv0wz8tRy3YxW2Od1mDf+a3RxfHSF61jPQB0GgvJYovZDg1Abp+0ovSosuQ01k
yldDUV3ofvo=
=j+7P
-----END PGP SIGNATURE-----
-------------- next part --------------
From: daemon9 at netcom.com (Route)
Message-Id: <199609180848.BAA20688 at netcom.netcom.com>
Subject: no subject (file transmission)
To: root at infonexus.com
Date: Wed, 18 Sep 1996 01:48:05 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 5435
Status: RO
Subject: Re: Panix
Newsgroups: comp.security.unix
References: <51d1mi$1th at News.IDT.NET> <51d6ie$bvp at nntp.ucs.ubc.ca> <51decl$2ur at netnews.upenn.edu>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Distribution:
X-Newsreader: TIN [version 1.2 PL2]
I guess it's about time I added my input here...
Vikram Bajaj (vbajaj at sas.upenn.edu):
: |They can't be blocked. Read 'TCP/IP Illustrated, Volume I' for more
Correct. SYN floods cannot be 'blocked', but they can bestopped,
with a reasonal amount of confidence...
: |o We spoof a valid address of a working machine - this is less than ideal,
: | because the SYN|ACK packet will be sent (2nd handshake packet) from
: | machine B to the spoofed address, and then the spoofed address will
: | respond with an ICMP error message. Machine B will then clear it's
No, this will elicit a RST from the machine whose IP address you
choose as the source. No ICMP traffic is generated here. BTW,
the only ICMP error message TCP will pay attention is source quench.
: |o We spoof an invalid address - no good for the same reason, because a
: | router along the way will return an ICMP Destination Unreachable message
TCP ordains ICMP unreachable messages to be the responsibility of IP.
These are network errors, are considered transient, and therefore up
to IP to resolve (re-route packets, or whatnot). TCP will ignore such
such messages. What is an invalid address? Something like
333.1213.443.1? The call to convert it to network-byte order, would
fail...
: |So, the choice of addresses to spoof should be made so that we can send
: |the minimum number of packets and avoid detection. We'll send 1000s of
: |packets per second to fill up the host queue and then only have to send at
: |1/10th - 1/20th the rate to maintain an overloaded state. Quite elegant.
The host backlog queue is probably not this large (depending on the
service and OS). If the backlog is, say 256, for example, and we
send 256 spoofed SYNs in, say, 5 seconds, ALL of these connection
requests will have expired 70-75 seconds after the last packet
arrives. We have to send 256 more after the timer expires. Any
others before that will, of course be dropped with legitimate
requests. We have send <backlog> amount of spoofed SYNs per <expiry>
period.
: |In addition to randomly spoofing the source address within these
: |constraints, we'll certainly want to spoof the destination port to avoid
You mean source port. Randomly spoofing the TCP destination port
will not aid us in our attack. To minimize homogeniality (ok, prolly
not a real word, but the conotation is there) in packets (read:
maximize difficulty in filtering) you should randomize the IP address,
IP TTL, TCP source port, TCP window advertisement and TCP sequence
number...
: |Since I am purely evil, I would also randomly scramble the content of the
: |SYN packets, such that there would be no detection scheme that I could
: |employ to determine that two SYN packets were actually from the same
: |source. There is now no way for me to differentiate legitimate SYN
: |connections from bogus ones, and I am completely open to a denial of
: |service attack.
Contents? What contents? The packets should be empty. Header
information only. Anything else is inefficient and surplus.
: |You'd think that spoofing IPs would be more difficult. If I'm trying to
: |spoof an IP from machine A, and I'm spoofing an external IP, my router
: |should say, "wait, that external IP can't be coming from my internal side,
: |so it's spoofed" and drop the packet. Routers can be configured to do
This is solution that needs to be employed to stop major attacks.
Internal attacks would still be possible, however.
: |network-wide solution would require the assistance of every ISP and
: |provider. Clearly, this will not occur.
IPv6 and T/TCP will render SYN floods impossible.
: |There are two more local options that I could try, though. I could
: |insert a user-level kernel daemon which had control over timeouts and
: |expiry based on average age of processes in the network buffer. At least
: |this would give the system administrator some warning that he was under
: |attack. Of course, it wouldn't do much to stop the attack, and it would
: |interfere with legitimate, slower connections.
One possible solution implementing a heuristics based filter:
x=backlog
y=user specified timeout < connection establishment timer
A kernel-level process sits and keeps a list of pending connection
requests on every TCP port. If x (or x-1,x-2) pending
connection-requests are present, several other contigencies are
checked:
-have x connection-requests been present for y?
-are there similarites in the packets (header information)?
-look at the arrival time of packets relative to each other
: |vulnerable (albeit much less vulnerable) to SYN attacks, but the internal
: |hosts will be protected; if the machine fails, no connections will go
: |through. The disadvantage of this approach, of course, is that there
: |will be a great increase in connection latency.
With this solution, all I have to do is disable one machine to remove
network service from your whole internal network.
: |Long-term solutions rest, really, with the IPv6 standard. IPv6 source
T/TCP's TAO will stop SYN flooding cold.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.felk.cvut.cz/pipermail/net/attachments/20000828/a5186000/attachment.bin
More information about the net
mailing list