Hi,
I’d already posted few times 1.5 yrs back regarding extremely poor handling of packets when CCRs are used with firewall or queues. Currently I experienced some mysterious reboots of CCR 1072 running 6.35.4. Total traffic was 5gbps download. Two rules in firewall mangle changing tos, 4 simple queues. I saw genuine udp traffic reaching total traffic to sometimes 7gbps as http content is now days also coming on udp. Then I tested with simulated ddos attack using UDP packets. Everytime CCR 1072 failed with meagre attack and it rebooted. It couldnt handle 100k pps attack (5gbps traffic running). Support file had already been sent.
I have before tested flooding the CCR and a few things to take in mind. If an interface is flooded than the router becomes unresponsive on that interface. So avoid bridging and try LACP.
Have rules to handle DDoS and loops. You will want to drop layer 3 broadcast, multicast, loops, Packets that have a source/destination of LAN that isnt your LAN, and so on. Avoid layer 2 from communicating between the ports so perhaps dropping a bunch of layer 2 related stuff as well. That unhandled traffic that just gets stuck at the router that isnt dropped just ends up collecting. Make sure SSL access to the router is restricted and closed on WAN as an SSH brute force will use a lot of CPU. Dont forget to include a catogary for other when catogarising traffic for all the other traffic that you didnt mark or consider when you started identifying and marking stuff.
Also check the temperature in system health and the voltage. If the voltage drops below accepted range the CCR will reboot. If it reaches a high temperature like 100C it will reboot.
i was simulating udp flood. Can you really stop udp flood ?? As the packet had reached to your router so your upstream pipe will very likely be choked.
UDP floods fill up bandwidth so you cant stop the bandwidth usage of UDP floods but you can stop the processing of a UDP flood. A UDP flood towards router only fills up download pipe but upload pipe is still fine unless you are an ISP in which you have
Internet traffic → router → clients
so UDP flood from internet traffic only messes with the clients download but the router itself can upload perfectly fine. You can use the blackhole route method to deal with UDP flood.
One of the ways you can identify a host before it tries to flood or hack you is when it tries to test/probe your router. Simply adding the host that tried on the input on your router to a blacklist and blocking/diverting it in forwarding, input and output does help. If a packet gets processed by your router it may output a reply back so you can also try dropping to blacklist on output chain as well as that would help in reducing the bandwidth as long as the router’s CPU/mesh isnt fully loaded.
You can not stop a UDP flood no matter what kind of firewall rules you try to set up. It’s purely a bandwidth exhaustion attack - if you have lower downstream capacity than the attack, you will lose.
That said, there is zero reason why a UDP flood (or any kind of traffic) should be crashing the router. This sounds like a buggy kernel module or something and should be investigated by Mikrotik. The worst that should happen is denial of service due to bandwidth or CPU exhaustion.