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

ive always wondered the same thing, if the attacker accomplished to perform a DoS then he was successful either way. I think you might want to change the rules so that they are done per destination IP, so each server gets its own limits. Then, if the attacker is attacking a single host, at least it's not affecting the other IPs and their syn rates. The goal is to really protect the hosts behind it, and if all of them are affected by a DoS to a single host then its pointless. It might still kill the router, at which time it's time to upgrade to an x86 with intel server nics.

I don't know anything about the SYN cookies feature in RouterOS, I always turn it on, but I've never known if it works or not. The fact is the attacker is only sending a single type of packet and not expecting a response anyhow.

How syn cookie works is described pretty clearly here:
http://en.wikipedia.org/wiki/SYN_cookies

You've been very helpful on this board so far. I'm a firewall newbie, I understand some basics but I'm not real comfortable writing my own rules from scratch and I probably would not know a lean and efficient rule from a sloppy resource-intensive one. Can you suggest modifying the above rules for per-destination IP?

I am actually planning to upgrade my busiest router with a dual x86 model, most likely the Powerouter 732. It seems the performance of the RB1000 is fine as long as everyone is behaving nicely. Once a fight breaks out, it quickly crumbles to the ground.

Can you suggest modifying the above rules for per-destination IP?

simply use 'dst-limit' instead of 'limit' parameter

Can you suggest modifying the above rules for per-destination IP?

simply use 'dst-limit' instead of 'limit' parameter

So this is correct ?
Only change what ?
Can you paste the final version of it ?

I can't see any 'dst-limit' in your rules, so I don't know what you actually changed...