[1125] in linux-security and linux-alert archive
Re: [linux-security] SYN flooding (was inetd and
daemon@ATHENA.MIT.EDU (route@onyx.infonexus.com)
Sun Sep 1 07:52:33 1996
From: route@onyx.infonexus.com
To: hagopiar@vuser.vu.union.edu (Rob Hagopian)
Date: Fri, 30 Aug 1996 17:48:23 -0700 (PDT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <v03007808ae4c83b33899@[199.232.252.122]> from "Rob Hagopian" at Aug 30, 96 07:52:32 am
Rob Hagopian's thoughts were:
| What about simply dropping the oldest SYN connections after the port(s)
| have been flooded, always leaving a connection available?
The oldest SYN connection request may in fact be legitmate.
| This won't help too much in a continuous flood mode as any legit
| connections might be wiped out along with the dummy SYN packets, but this
| could be aleivated somewhat with larger buffers...
A larger backlog queue is not the answer. The amount of memory each
pending connection request requires is much greater when compared to
the complexity of simply sending 10,20 or 50 more spoofed SYNs to
flood the port.
| Also, when this threshold is reached, it would be a good time to
| start alerting the sysadmin.
Of course.
| Thus, a proactive solution is acheived, while a permenant solution
| can be investigated. Also, I don't believe that this would require too much
| effort on the part of the kernel to track (as opposed to tracking the IP
Simple mods.
| addr of SYN packets, which would fail anyways under a random SYN flood
| attack).
Any SYN flood *attack* will have the source IP address spoofed.
--
[ route@infonexus.com ] Editor, Phrack Magazine / Guild Corporation Chair
the greatest trick the devil ever pulled was
convincing the world he didn't exist
