syn DDoS attack solution
dufresne at sysinfo.com
Sat Jun 2 21:07:44 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 1 Jun 2007, Bgs wrote:
> Sorry if my first mail was misleading, I only slept about 5-6 hours this week
> in all :/
>>> How is the handling of ESTABLISHED connections implemented in the
>> There is likely a timer somewhere to time out connections that are just
>> hanging around doing nothing. You'd have to dig around to find it and turn
>> it down. You could also use something like tcpkill to get rid of them for
> What I'd like to achieve is different from the normal tcp timeouts. I only
> want a different (quite short in terms of everyday tcp traffic) timeout for
> connections that have not sent any data after the tcp handshake. The
> connections that did any traffic would become normal or 'legitimate' and the
> usual tcp timeouts would apply.
> About the netlink approach, here is what I was thinking about. I have never
> coded in the netlink/netfilter space so I'm completely in the dark if this
> can be done at all or not:
> Client sends SYN to server. It arrives to the firewall. An info is sent to
> the userspace portion and the SYN packet is DROPed. The user space program
> logs the SYN packet and sends out an appropriately constructed SYN/ACK to the
> client. Client sends the ACK. The info is sent to util which logs the packet
> and puts the connection in allowed state as it knows from it's own db that
> the tcp handshake was ok. At this point it either starts the next phase or
> waits for the first data packet and starts the next phase then (allowing the
> data packet after it). The next phase is: userland replays the SYN handshake
> with the server thus making it receptive to the tcp stream to come. Through
> netlinks firewall part it would allow all subsequent traffic.
> The main point is almost identical to the syn proxy thingie in bsd and ios,
> the main difference would be the ability to add some policy about when and
> how to let the traffic through to the server. For example with delayed
> replay, connections in ESTABLISHED state but without data would be dropped
> from the replay db stopping the culprit at the firewall.
> Just a thought... can it be done (technically) or should I simply go to bed
DDOS attacks work against resources, the tcp/ip stack <half opens (syn's)
left hanging>, memory <cache of data in your syn-flood db>, drive space
<system logs with overzealous logging of packet flow in limited space, or
how much disk is devoted to a syn-flood db>, the size of your pipe...
In any but the most simplistic low bandwith attacks there is little one
can do in such cases but either ride out the storm or go upstream for help in
resolution <mist often a block of the damaging traffic>. Even an
semi-decent firewall defense against a simple low bandwith syn flood will
need to be totally rework for defense in the case of a simple lowbandwidth
ping flood, etc. And once the attack level is amplified above the flow
capabilities of your pipe, all bets are off. In a serious flooding attack
the firewall simply become a stopgate from preventing work on the local
net from being affected. There have been and will continue to be some
rather decently funded companies with some fairly decent pipes wiped out
of business or their internet presence closed up due to some of these
kinds of attacks over extended periods of time. Goverments across the
globe have had internet services disrupted for extended periods.
Microsoft has had to relocate servers to new net/ip addresses to divert
the flow from such attacks and stay somewhat online...
Best way to avoid such problems is to not get into a whose prick is bigger
contest with some kid in IRC that controls a 10,000-100,000 or larger
series of zombies in their botnet.
It's the nature of the game, all in the design...
admin & senior security consultant: sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the netfilter