Hi all -

I want to set up the syn flood protect firewall script that's shown in the Mikrotik wiki. That code uses 400 new syn packets over a 5-second period as the threshold to kick in - but I have no idea of this is the right value for my network, nor do I know how to find out, I must confess. What's the easiest way to take a sample of the current rate of syn packets in my network, so I can pad the value up by about 20% and set the firewall rule to trigger if it exceeds that? For that matter, if I want to protect against a ping flood or a udp flood, or anything else that might be wise, how would I also find the current values for those types of connections?

Another thing I'm not clear on, perhaps someone can help: the syn flood protect filter entries shown here:
http://wiki.mikrotik.com/wiki/DoS_attack_protection

... when I set limit=nnn, does that apply to the cumulative number of connections through the router, or is 'nnn' for the number of new connections to each individual destination host?

TIA!

Ed

Set up the traffic sniffer to stream to a machine with storage, then capture for a day and analyze it on number of packets total vs total number of packets with a SYN (but not a SYN/ACK) flags set. Same theory for other packet types.

To protect against DoS I'd probably not act unless you're exceeding 200% of normal values, otherwise you're going to see false positives and users complaining. Or even higher margins unless your hardware is already running close to its limits.

Thanks, I've done that once before, so it's easy to repeat. My network has a pretty consistent usage profile so I can probably get by with a shorter sample.

So do you if those syn flood protect firewall rules are applied globally, or on a per-destination basis? That makes a *big* difference in the value for limit. I'd rather that they be per-destination, otherwise there will be lots of collateral damage if the rules kick in.

use the mangle chain and just enter a passthru rule for SYN packets. Then open that rule and watch the statistics tab, you will see pps that triggered from that rule.

Hi - thanks for the suggestion, sounds like a good one. I'm pretty new to firewall rules and I'd be much obliged if you were to post a sample. Would it be something like:
Also, I am wondering about the SYN protect rules - if all new SYN packets for all of my clients will be dropped once the rule kicks in, isn't that just giving the attacker a bonus? It will disrupt connectivity to the client they are targeting, and all my other clients too. Right?

So I went ahead and added the mangle rule that I wrote above, and the statistics pane for the rule in winbox showed anywhere between 350 - 600 pps for new SYN packets passing through the router.

So then I added the SYN protect lines shown here, increasing the limit value appropriately:
...and then enabled it. I found that I had to change the burst parameter in limit from 5 to 100, or the filter started to drop SYN packets, even if I increased the value of limit up to 1500. So currently I have limit=1000,100. I'm not sure I understand how burst is evaluated, can someone explain?

I did also turn connecting tracking back on and enabled tcp-syncookie as I do want the benefits that it provides in an attack situation.

Unfortunately all of this has had the effect of nearly doubling the RB1000's average CPU loading from it's previous level. I have this sneaking fear that it's going to be a case of "the operation was a success, but the patient died" if I get another SYN attack - the load that these security measures put on the router may add to the trouble! I certainly hope not.

Anyway, I appreciate any comments or suggestions.
Ed

UPDATE: I've now had to push the limit up to 1200/s and the burst up to 300 due to the occasional dropped packet, so I guess the new SYN rates on my network are a lot more burst-y than the values that were being reported in the statistics pane for the mangle filter. Either that, or it's all FUBAR.

dont use connection-state=new... only use tcp-flags=SYN. I also think you need to ! the rest of the flag types if I remember correctly. See if that improves your cpu use.

somewhere i saw an example that mikrotik said you have to negate the other flags, like this:

add action=passthrough chain=prerouting comment="" disabled=no in-interface=WAN protocol=tcp tcp-flags=\
syn,!fin,!rst,!psh,!ack,!urg,!ece,!cwr

Try that type of rule and see what happens ... thep roblem with tcp-flags=SYN only is that other types of packets have SYN, as well as other flags like PSH or something.

also, these rules will limit TOTAL syns coming thru the network, not per IP. You might want to add a dst-limit and give each invidual IP their own limits instead of lumping them all into the same bucket.

dont use connection-state=new... only use tcp-flags=SYN. I also think you need to ! the rest of the flag types if I remember correctly. See if that improves your cpu use.

The SYN DDoS attacks work by the attacker sending SYN requests for new connections and then not answering the acknowlegement, so only type 'new' connections are involved in the attack and those are the ones I want to look at. Having said that, I certainly want to do it as efficiently as possible, but do you have more complete example code? I'm treading slowly with this and I'd like to give it a read first.

correct, they just SYN flood you... so dont bother checking if its a new connection or not, just look at the flags, its more efficient. If you see a zillion SYN packets come in, its much more efficient to check its flags rather than check a table that has all your valid traffic in it. The rule you have looks good, just remove connection-state=new.

I took your good suggestion from last night and wrote a mangle rule so I could see what kind of packet rate for new SYNs that I was getting on my network. So I re-enabled that, then removed the 'new' state for a bit. The packets getting tagged by the rule doubles - take a look at the big bump below - that's 'all' vs 'new':
So if I do it this way, I'll have to set up a much larger limit and burst value in order to avoid dropping valid SYN packets, which means a bigger hole for pure attack traffic to pass through, right?

try using tcp-flags=syn,!fin,!rst,!psh,!ack,!urg,!ece,!cwr

Like this - note that I removed connection-state=new?:

looks okay. i would probably only use protocol=tcp on the matcher on the jump rule, just send all tcp packets thru it - but that works the way you have it. if you use that tcp-flags setup with your mangle test rule does it show the same pps as the connection-state=new?

Yes, using the extended string of flags in the mangle rule does show an average packet rate that comes pretty close to what I saw with connection-state=new. It also seems to show peaks in more definition, and proves that I occasionally do get bursts of new SYNs that are as much as three times the more typical rate. Given that, it seems like it would make more sense for me to use a limit parameter of something like x,2x instead of what I was doing before, which was more like 10x,x. I'm trying the new ratio now and it seems to be working.

Last night there was a brief blast of SYN traffic coming in from the WAN side - the SYN protect rule dropped 17 million excess SYN packets in a 5-10 minute period! It taxed the router pretty hard, the CPU hit 98%, legit traffic got a big latency increase and was choked off badly for a few minutes. I'm sure there was latency and timeouts all around. So while these rules did what they were supposed to do, my network still took a hit from it. Is there anything else I can do to minimize the effects of these floods on legit traffic? I'm already using tcp-syncookie, which is supposed to help.

Finally, I'd love to log some of this SYN flood traffic - is there a way I could do that without sending router performance into a downward spiral?

Thanks for all your suggestions, they've been exceedingly helpful.

- Ed

i wonder if those SYNs that you are dropped are still setting up connections in the conntrack tables... did youy say earlier that you worked with conntrack turned off? Can you now go back to that since your not using connection-state=new?

you can run the packet sniffer and push the stream to a remote box for low overhead. or just setup a switch in front that has a mirror capability on it.

According to my admittedly feeble understanding, the syncookie may help valid connections get through if the router is being bombarded with false connections:
http://en.wikipedia.org/wiki/SYN_cookies. If that's true, then I want to use it. But I'll definitely give a listen to why I should not.

The last time I streamed the packet sniffer to one of my servers, it worked, but put a real load on the RB's cpu. Port mirroring above the router is something I could actually do right now, but I have no ready way to collect the data on the mirrored port. All this stuff is in DC that's 120 miles away from me, so I can't really run down there and mess around with hardware and cables - any other ideas?