Does the SYN protect chain really protect anything?
Posted: Thu Apr 15, 2010 10:46 pm
Hi All -
I'm currently working on hardening my RoS RB1000's from malicous traffic, and with the help of the wiki, this forum and it's many gracious users I've got several rules in place. One is the SYN protection chain that can be found in the wiki under protecting from DDoS, slightly modified here per the suggestions of others:
Of course I've set X and Y to values that make sense for rate and burst to allow room for my clients to get busy. My simple question is this - does this really protect anything worth protecting? In my case, I've had SYN floods from hundreds to sometimes thousands of spoofed origin hosts targeting one of my client's IPs, hitting my WAN side at rates of 100k - 140k packets/second at peak, according to stats from the firewall rules (and assuming a 60-byte SYN connect packet). Of course the above rules kick and an drop millions of SYN packets in a few minutes' time. Aside from the fact that the router CPU hits 100% and latency and packet loss goes through the ceiling, I must also be dropping most if not all of the *legitimate* new connection requests along with the attack traffic, right? So what have I really accomplished with this rule, other than making the attack more effective in it's goal, and sooner?
I also have connection tracking on and tcp-syncookie enabled - my understanding is that SYN cookies are useful way to dump false connect packets while servicing valid ones. If the above rules are throwing out valid connect attempts right away because the threshold has been exceeded, it seems like they are sabotaging SYN cookie too.
Perhaps I'm just confused, but can someone explain to me why I would not want to disable these rules and just let SYN cookie handle the DDoS attacks instead?
Thanks!
Ed
I'm currently working on hardening my RoS RB1000's from malicous traffic, and with the help of the wiki, this forum and it's many gracious users I've got several rules in place. One is the SYN protection chain that can be found in the wiki under protecting from DDoS, slightly modified here per the suggestions of others:
Code: Select all
add action=jump chain=forward comment="SYN Flood protect" disabled=no \
jump-target=SYN-Protect protocol=tcp tcp-flags=\
syn,!fin,!rst,!psh,!ack,!urg,!ece,!cwr
add action=accept chain=SYN-Protect comment="" disabled=no limit=X,Y \
protocol=tcp tcp-flags=syn,!fin,!rst,!psh,!ack,!urg,!ece,!cwr
add action=drop chain=SYN-Protect comment="" disabled=no protocol=tcp \
tcp-flags=syn,!fin,!rst,!psh,!ack,!urg,!ece,!cwr
I also have connection tracking on and tcp-syncookie enabled - my understanding is that SYN cookies are useful way to dump false connect packets while servicing valid ones. If the above rules are throwing out valid connect attempts right away because the threshold has been exceeded, it seems like they are sabotaging SYN cookie too.
Perhaps I'm just confused, but can someone explain to me why I would not want to disable these rules and just let SYN cookie handle the DDoS attacks instead?
Thanks!
Ed