[1104] in linux-security and linux-alert archive
[linux-security] SYN flooding (was inetd and denial-of-service)
daemon@ATHENA.MIT.EDU (thought)
Wed Aug 28 17:33:46 1996
From: thought <route@infonexus.com>
To: sirsyko@dot.ishiboo.com (Ralph the Wonder Llama)
Date: Sun, 25 Aug 1996 11:07:45 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.BSF.3.91.960825022554.25550A-100000@dot.ishiboo.com> from "Ralph the Wonder Llama" at Aug 25, 96 02:42:03 am
Ralph the Wonder Llama's thoughts were:
| > By very defintion of a SYN flood, the source address has to be
| > forged.
|
| No offense, but dont you think that the definition of a syn flood is a
| flood of syn packets? whocares if the source address is real. Although,
| the only practical use of a syn flooder is one where the address is
| forged :)
True. I should have clarified that the only useful way to SYN
flood a host's TCP is with forged source IP addresses. (Assuming
you can find a purpose in which SYN flooding is usefull...;))
| why do I like the idea of a random address? It would be cool go get
| flooded by 123.234.345.456 :)
Yes but if it just drawn from a hat the host *could* be reachable.
Besides, `123.234.345.456` will fail when you try to convert it into
network-byte order...;)
[REW: Most implementations will silently drop the higher bits in
the 4 bytes of an IP address. 123.234.89.200 might just be valid.]
| How does this meet his point. He is saying to hack up an inetd that if it
| receives many tries from an given host or network, to turn on a filter
| that disallows any incoming syn requests from being accepted, thus
| denying this host/network but allowing other hosts/networks to function.
| However, all this would do is cause the evil haxorer to need to change
| the source address of his flood routine, but hey, its a start...
Remember that the inetd (and TCPd) filters work after the completion
of the 3-way handshake. SYN flooding only satisfies the first part
of the 3-way handshake. I can deny TCP/23 with TCPd from all but
trusted IP addresses. It can still be SYN flooded however.
| >
| > The best way to do this is in the kernel. Briefly: A list of
|
| Faster in the kernel perhaps. Better? I dont know. I'd rather have my
| kernel pass the packets to the application and have the application
| decide how to work (the application in question would be something like
| xinetd or tcp wrappers). Doing all this trickery in the kernel sounds
See above.
| dangerous, ie, memory problems (buffer exhaustion, and/or possible buffer
| attacks) since the packets have to spend more time and be stored in the
| memory, and perhaps even be stored in parts of memory that would be
| trusted (like I said, possible buffer attack).
This is a moot point. If it is coded well, this is not a problem.
--
[ route@infonexus.com ] Editor, Phrack Magazine / Guild Corporation Chair
the greatest trick the devil ever pulled was
convincing the world he didn't exist
