SYN Flooding Protection
-
Hello! I've recently setup a GRE endpoint just for a couple servers and I got a SYN flood on that IP and it killed all my state tables, I made a firewall rule specifically on the port that was attacked and all TCP traffic incoming to have a max connections be 10 every 1 second, I even went down to 3 every 1 second and it still seemed to not be phased.
I've also tried Synproxy which also didn't do much, here's my TCP rule for all my TCP traffic. (I only run 1-2 servers so I don't think it'll be an issue)
Is there something I'm missing here? While the flood happens (I ran a flood on myself with some online booter) I check my SSH and run: pfctl -t virusprot -Ts but it shows nothing. Thanks for any help in advance
-
Is your rule even getting hit, correct interface, correct order? How large is your state table? Have you tried configuring Firewall Adaptive Timeouts under "System/Advanced/Firewall & NAT"? You may also want to turn down some of the timeouts at the bottom. I set "TCP First" and "TCP Opening" to 16 seconds. The default is some ludicrous number like 90 seconds where every modern TCP stack gives up after 24 seconds.
FreeBSD uses SYN cookies and does quite well against basic SYN floods, but gets hosed by DDOS SYN floods from many source IPs. The network stack has an O(nm) cost for removing states, where N is the size of the number of source IPs and M is the number of active states. Even though FreeBSD has an O(1) cost for processing packets for an existing state, adding and removing states locks the state table. This causes new and expired states to have higher priority than existing live states.
There's a company that uses FreeBSD as a DDOS protection service and they've been working on this problem. I think they're hoping to get it closer to O(y) scaling and possibly allow existing states to have priority or at least a fairer share.
Another issue is the FreeBSD state table is a shared resource that requires locks to protect it. There are plans in the works to have state tables per core and to pin a state to a core for all of its processing. This would allow the locks to be removed giving perfect linear scaling in this part of the code. Not only would it be lockless, but it wouldn't even have to be shared, no cache-line bouncing.
It is quite ridiculous that a DSL connection with 1Mb upload can take down a 10Gb router by forcing the router to literally spend trillions of clock cycles to process one packet. It is getting attention, but few people are competent in the area of SMP and general scaling issues to work on the problem. These types of problems aren't so much an issue of effort or experience, but of thinking differently.
You may be interested in this: https://forum.pfsense.org/index.php?topic=113496.msg631076#msg631076
-
Thank you for the response, love the in depth information. I've just set my TCP First and TCP Opening to 16 seconds, and I was doing relatively basic (to my knowledge) floods with a free booter online. Only sent 4Mbps but it tanks my 400k state tables.
I'm not sure how many IP's are hitting me, but it isn't much I'd assume since it's just QuezStresser. Is there something I did wrong with the TCP filter rule? It is receiving traffic, it's at the top of the rules list and it is creating states & passing traffic.
I followed http://pfsensesetup.com/syn-flood-prevention-in-pfsense/ and it seemed pretty basic, is this no longer valid or just doesn't apply to my situation? Thanks!
-
Did you set adaptive timeouts? They'll further lower the timeouts as your state table fills. I don't know if 400k is a normal amount of states for you, but you may want to start dropping states as your table starts getting full.
-
Yeah I just set them up, I tested it out and it did help a bunch and I managed to stay up, thanks Harvey! Although I still do wonder, why do my TCP rules not send those connections to the Virusprot? Or is the Virusprot and the way I'm setting up my TCP rules designed for another type of attack?
-
I am not familiar with much more than the basic network settings. Virusprot is outside of what I can attempt to help with.
-
Thanks for the help Harvey, you did solve my main concern of defending against a SYN but I am curious as to why it doesn't work, maybe one day it'll be found out. At any rate, it's appreciate you took the time! :D
