Unfinished and untested.

These rules can be modified for many botnet situations.

Logging can be added if needed.

The order of rules in your firewall is important. Move these rules to an appropriate place in your firewall order.

Consider disabling or deleting these rules after the attacks have subsided to keep from polluting your firewall rule set.

Here we see a botnet using UDP port 30837, so we create a permanent blacklist and drop all packets.

• We can disable the rules later
• We can modify these rules for the next attack
• Or we can keep or delete the blacklist and rules later

/ip firewall filter

add chain=input comment="Drop Blacklisted Botnet Attackers for 10 Days" src-address-list=botnet_blacklist \
action=drop disabled=no

add chain=input protocol=udp dst-port=30837 connection-state=new src-address-list=botnet_stage3 \
action=add-src-to-address-list address-list=botnet_blacklist address-list-timeout=10d  disabled=no

add chain=input protocol=udp dst-port=30837 connection-state=new src-address-list=botnet_stage2 \
action=add-src-to-address-list address-list=botnet_stage3 address-list-timeout=1m disabled=no

add chain=input protocol=udp dst-port=30837 connection-state=new src-address-list=botnet_stage1 \
action=add-src-to-address-list address-list=botnet_stage2 address-list-timeout=1m disabled=no

add chain=input protocol=udp dst-port=30837 connection-state=new action=add-src-to-address-list \
address-list=botnet_stage1 address-list-timeout=1m  disabled=no

• Since botnet traffic generally comes slowly from many different hosts, you might have to adjust the address-list-timeout to a longer period in the “stage” rules to catch more attackers
• You might omit the address-list-timeout from the “stage3” rule to make the blacklist entry permanent.

If you feel the need, you can then allow connections not previously blocked. If all you are doing is building a blacklist, omit this rule:

add chain=input comment="Accept botnet traffic not previously blocked" protocol=udp dst-port=30837 \
connection-state=new action=accept

http://forum.mikrotik.com/viewtopic.php?f=2&t=54607&p=278189

http://wiki.mikrotik.com/wiki/DDoS_Detection_and_Blocking

This sample rule set is on the forward chain. For traffic destined for router, you would have to use the input chain.

This rule set uses ether1 as WAN (Internet) connection.

You can also easily exclude (whitelist) certain hosts. See DDoS_Detection_and_Blocking.

This example dynamically creates two address lists: attackers (ddos-source) and attacked hosts (ddos-target), and blocks packets from the former to the latter.

/ip firewall filter

  add chain=forward action=jump connection-state=new in-interface=ether1 jump-target=detect-ddos \
  comment="Detect DDoS Attack"
    
  add chain=detect-ddos action=return dst-limit=50,100,src-and-dst-addresses/10s \
  comment="Detect DDoS Attack - 1"
      
  add chain=detect-ddos action=add-dst-to-address-list address-list=ddos-target address-list-timeout=1w \
  comment="Detect DDoS Attack - 2"
    
  add chain=detect-ddos action=add-src-to-address-list address-list=ddos-source address-list-timeout=1w \
  comment="Detect DDoS Attack - 3"
    
  add chain=forward action=drop connection-state=new dst-address-list=ddos-target \
  src-address-list=ddos-source comment="Drop DDoS Attackers"

Q: Is there way to make the rule less sensitive? When I browse to my web server, Firefox hangs and retries too many times and I'm flagged as a ddos-source.

A: dst-limit=32,32 is what you're looking for. try to change it to dst-limit=32,256 for higher burst.