[1107] in linux-security and linux-alert archive
Re: [linux-security] inetd and denial-of-service
daemon@ATHENA.MIT.EDU (route@onyx.infonexus.com)
Wed Aug 28 20:11:48 1996
From: route@onyx.infonexus.com
To: shagboy@bluesky.net
Date: Tue, 27 Aug 1996 09:41:55 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu, brian@saturn.net
In-Reply-To: <Pine.LNX.3.91.960826233608.2057C-100000@cirrus.bluesky.net> from "Racer X" at Aug 26, 96 11:46:17 pm
Racer X's thoughts were:
| > victim up. You will get into a syn/syn|ack/rst flood, which when
| > completed will leave the victim perfectly normal.
|
| Not when I tried. All that happened was that I took up all the open
| connections on my machine as well as the attacked machine.
When the attacked TCP receives the SYN (which is *not* forged in
this example) it sends out it's SYN/ACK as expected. Since the
source IP address is valid and reachable, the SYN/ACK will make
it's way to a host, on the source port that was in the TCP header
of the original SYN packet. Since, either A) no process will be
listen()ing on that port, or B) the SYN/ACK is *not* expected for
whatever process is listen()ing, a RST packet will be elicted from
this SYN/ACK and sent to the target host. The connection is torn
down. No SYN flood.
| > They would not use www.whitehouse.gov, because those syn packets would be
| > reset.
|
| I don't think you're right on this one, but if you are, it still doesn't
This is EXACTLY what will happen in the above scenario.
| explain why a randomly chosen source IP is a bad idea, which was what I
| was trying to clarify.
Because you have NO way of verifying if a host is unreachable or
not when you pick an IP address out of thin air. Just like when
generate a large odd number. You cannot guarantee it's prime without
testing it for primality...
| > If they forge the ip of a host with reverse dns, but not up - what have
| > you done? Absolutely nothing.
|
| Sure you have. If they use that same IP over and over again, you can
| spot a potential SYN flood from that particular host and refuse to accept
| any more SYN's from that host. Contrary to what you may think, this can
| be done in user space with an ipfwadm-like tool; we just need the hooks
| in the kernel to allow policies to be changed on the fly.
This is why you will see many SYN floods with different source
addresses in each wave of packets, or even better, in each
packet.
[REW: And using "random" IP addresses will "work". There are nowhere
near 4G hosts on the internet, so choosing a random IP address is quite
likely to give you one that isn't reachable. The occasional one that
IS availble will trigger the first scenario.]
--
[ route@infonexus.com ] Editor, Phrack Magazine / Guild Corporation Chair
the greatest trick the devil ever pulled was
convincing the world he didn't exist
