Defending W5500-based systems against SYN Flood Attacks

Question

I experienced my first DDoS attack on my W5500-based system yesterday and failed the test miserably. But I captured the attack with WireShark and came up with a strategy of recording the system time when each socket first enters the SYNRECV state and forcibly closing them if they remain in that state longer than some timeout period. In the long term I’ll make this timeout a configurable parameter, but in the short term I’m experimenting to identify a potential default value. I tested with 5ms and 10ms today, but saw remote visitors’ connections timing out at both, so I’ve increased it to 20ms. I understand that making it too low will prevent legitimate traffic from high-latency connections from using my system, so I’m trying to find a balance between making my system semi-usable during attacks and rejecting legitimate traffic. I added a “Delta Time” column to my WireShark capture display and sorted the attack data by time between incoming SYN packets. Scrolling down suggests that a 20ms timeout would have allowed me to reject ~80% of packets received during the attack without expending significant resources other than the socket itself. One other thought… I could set the initial timeout quite high, and add code to detect a SYN Flood DDoS attack. When an attack is detected I could reduce the timeout, then increase it once the attack ends. Has anyone else tackled this problem, and if so, what approach did you use and how well did it work?

Eugeny · Answer

I did no thave these issues (so far). Your approach sounds very logical, and must improve the situation. It will prevent W5500 sockets from hanging for longer time thus total unavailability to the legitimate users. Depending on the architecture of your solution you may consider putting more intelligent firewall device in front of W5500. I suspect that your proposed way to deal with DDoS, in terms of servicing requests, may prove to be unsatisfactory - simply because legitimate users will anyway have huge difficulties accessing W5500 during the attack. You may need more clever device to deal with the stuation, which would search for patterns in attack (e.g. source, location, port numbers, timing), or even having configurable rules to ensure legitimate users will go through it without issues. Defence against DDoS is a quiate a big business, if that would be so simple (in terms of algorithm and code ROM/RAM space) this business would not exist… However if you have special conditions (e.g. source address your cliens come from) you can easily program them disallowing bad guys at the entrance.

Mxyxixptlick · Answer

I’ve implemented anti-DOS code that successfully fends off attacks that appear to originate from both random IP addresses and a group of subnets (the latter sort of attack on my test system is what led me to do this work). It takes 1-2 seconds to recognize an attack, depending on attack intensity and automatically lowers defenses a random period of time after the attack ends. The code is parameterized to make it easy for others to tweak the settings. I used hping3 to test it on a dedicated LAN, a worst-case attack scenario. My system wasn’t able to function when hping3 was set to send packets as quickly as possible (–flood option), but served web pages and even steamed an audio file when SYN packets were generated every 2.5 ms. Today I added a dynamic socket connection timeout calculation that updates the timeout periodically based on the average number of SYN attack packets received in the recent past. This allowed my server to operate when I sent it a SYN packet every 500 to 1,000 microseconds. Anyone who’s interested in more information can send me a private message.