TCP SYN flood test and confusion

Hi all,

Today I just wanted to test how TCP SYN flooding protection works on my setup. So I ran this command from my PC to router:

hping3 -c 15000 -d 120 -S -w 64 -p 80 --flood --rand-source 192.168.1.1

As you can see load is very heavy on to the router, but on a small fraction of SYN packets are captured in input chain. Like one packet every 5 seconds or so. On the other hand if I create just simple passthrough rule in prerouting chain, then all packets are captured. How come only super small fraction of those packets reach input chain? Where they get lost lost? I have same behavior with or without TCP SYN cookies enabled.

EDIT:

When I change hping3 command to this:

hping3 -c 15000 -d 120 -S -w 64 -p 80 --flood 192.168.1.1

then I can capture all packets correctly. The only difference between rules is that first rule generates random source IP address. When IP is static, then there are no problems capturing the traffic.

Any ideas?

Regards,

Sorry, that was not very smart question from my side.

I figured it out what I did wrong. Packets did not get lost :slight_smile: I was SYNC flooding on LAN interface, not WAN, so all IPs from outside network were just rejected when it came to routing decision. All clear, case closed :slight_smile:

Regards,

Which rules for TCP SYN flooding protection did you add? From here maybe?
If you are not behind CGNAT try to perform

hping3 -c 15000 -d 120 -S -w 64 -p <TCP_PORT> --flood --rand-source <ROUTER_WAN_IP>

from device using other WAN connection and see how it goes…

Yes, I was using exactly same rules, but this one

/ip firewall filter
add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s

I was using with connection-state=new. Maybe that was not the best idea of doing so, but I didn’t want all packets to bypass return rule. Now I’m thinking that for security reasons maybe netter is to remove connection-state=new option.

I’m unfortunately behind CGNAT, but I could arrange setup at other place where I could get direclt public WAN to router.

Either way, my last test was loading router quite a lot, but it could still handle. CPU was at 30%, WiFi download speed dropped from approx 600 Mbit to 350-400 Mbit.

If you are behind CGNAT then you are protected from this attack since attacker cannot reach your WAN IP, your public IP is on another subnet.
If you want to test this properly setup WAN connection without CGNAT and attack over WAN. See also how long you can perform attack until address lists are filled many bogus IPs which can consume a lot of RAM and maybe make ROS unsable (depends on device model).
Unless you are expecting that someone from LAN can attack router?

Ah yes, that is a very good point. With random source addresses list will overfill super fast as that pace and router should crash pretty fast. But it is something for sure to be tested!

That is home router, so I do not really expect anybody to do DDoS on LAN.

I was just thinking if my ISP will be happy if I will be performing those tests :slight_smile:

I think it will not be noticed in some shorter period, mine ISPs did not complain when I did this (device connected to ISP from which I was attacking and ISP on which is router connected). See this post and topic conversation, maybe address lists are not issue but you can test it.