We are getting lots of IP Fragmentation style DDoS, Packets are marked with MF (more fragment flag) and Mikrotik is super busy in assemble packets. CPU is 100% that time.
Is there a way i can block or stop IP Fragmented packet with MF bit on Prerouting chain? But prerouting chain doesn’t support “DROP” action. Why prerouting doesn’t have “DROP”?
Or any other solution to stop this kind of attack??
You could make action=mark-packet new-packet-mark=dropme
and then in filter table:
chain=input packet-mark=dropme action=drop
chain=forward packet-mark=dropme action=drop
Do be aware that this could break other things that are legitimately having packet fragmentation along the path.
Is there a way i can mark only “MF” flag in prerouting? How do i filter fragmented packet in Prerouting chain?
Anybody who can help?
Any solution?
new mangle rule/extra/ ip fragment
as mentioned before - fragmented traffic is perfectly legal. By dropping subsequent fragments you will probably make more problems than you solve
is important to establish if offending traffic is toward the router itself or is in transit traffic
are application is voice base RTP packet which data size is less than 512 bytes. We did all kind of study and finally decided we don’t need fragmented packet. We run sniffer for 1 month to detect fragmented packet and we didn’t find single fragmented packet. We have dual home network so i want to restrict fragment on public facing interface.
I was reading doc and its saying following for “IP Fragment” option in firewall
Matches fragmented packets. First (starting) fragment does not count. If connection tracking is enabled there will be no fragments as system automatically assembles every packet.
We have connection tracking enabled, do you think your option will help?
Its transit traffic toward my servers.
maybe limiting specific application destination port to a max size of packet?? looks like ip firewall has the option of match ip fragments
Here is the problem, even if i identify my packet is IP Fragmented but i want to drop then in PREROUTING chain itself. because if i block them in INPUT or FORWARD chain my CPU get 100%.
I want to stop them in PREROUTING so it won’t touch routing table and get drop on door before getting in.
What do you suggest?
This won’t improve your performance.
Only the forward or input chain can actually block packets. Mangle is like a paint sprayer - it can mark packets and change some interesting values on them, but it doesn’t do any discarding.
Even if it did, this would not improve the performance, because the same basic actions must be taken: receive packet, identify it as a fragment, discard it. Routing table lookups are a very very very fast operation and don’t take much CPU, especially when a destination is cached.
Okay! Enable IP Fragment option in “Prerouting” chain to mark fragmented packet but its not matching any single packet. If i disable check mark “IP fragment” it start matching packet..
I am sending “IP Fragmented” packet using following command to test,
-x option will set “MF” bit in packet. I have tired other option ot like -f and -g but its not matching anyone. I think its different purpose for IP fragment.
hping3 -V --icmp --data 100 -x 192.168.200.2
maybe you need a powerfull routerboard than actual??
I have CCR1036-8G-2S+ 16GB memory 32 CPUs, Does it enough?
ccr1036 has 36 cpu tile cores not 32
bandwidth an pps of legitimate traffic??
bandwidth and pps of offending traffic when attacked??
As you already mentioned the problem is probably that ROS does the fragment reassembly automatically when connection tracking is enabled (i.e. when filter rules used). So you will see no packet fragment - the packet will enter the rules after it was reassembled.
So I see no solution for you here.
Note: in the past we had another type of problems with fragmented packets. On CPE stations we configure a firewall (allowing only configured SRC IPs from client, etc) and disabled connection tracking (there is no NAT and no statefull firewall). Sometimes it happened that the customer was not able to run VPNs/tunnels through the CPE. It showed that fragmented traffic was not forwarded. Explanation from MT support was that when there is any filter rule fragmented packets are dropped (it is expected that connection tracking is enabled and thus thare are no real fragments goints though rules). The problem was a little bit fuzzy because without changing the config all was working most time. After CPE restart the problem could appear or disappear. Enabling the connection tracking solved it. Later ROS versions enable the tracking automatically if filter rules are present and default settings is used.
You are right, its 36 core. 100kpps and total bandwidth is 1G internet link
You are right, if connection tracking is enabled then you will never be able to find fragmented packet because it get assembly at door.
How other company handling this kind of attack?
I hope the fragments you want to eliminate are part of some DDoS attack. For example if the attack is made by DNS protocol you could try to filter all packes which have SRC port UDP/53. If you are lucky enough you can made exceptions for legal DNS traffic (i.e. if your customers use known set of DNS servers).
Maybe when the first packet id dropped the fragments will be dropped silently too. But maybe the logic of packet reassembly will be behaving badly inthis case too. I would ask MT support if they have solution for you.
We are not using MT for nothing else than CPE, AP. You are a proof that even 36 CPUs is not enough (if they are not effectivelly used and are not too powerful alone). You could replace the box with x86 and run ROS or Linux on it. Than you can use some accelerated NIC (which allows to distribute packets to more cores) and be able much more traffic