Re: syn DDoS attack solution

[Bgs <bgs@bgs.hu>]

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
>> TCP/IP
>> stack?
> 
> 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
> you. 

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 :)

Regards
Bgs