Re: syn DDoS attack solution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux