I have single PUBLIC ip on WAN interface of Mikrotik.
From yesterday I am continuously being hit by various public ip with UDP attack. this results in WAN link usage to 100% and chocking.
the src and dst ports (udp) are different. I tried to block ports, i tried to block source ip’s in INPUT/FORWARD chains but still no use.
If I will ask my ISP to change the IP, they will but still its no solution, attack can come to new ip as well sooner or later.
in my LAB, i used ‘UDP Unicorn’ tool to FLOOd my mikrotik & it simply flooded mikrotik. no rules are blocking the UDP traffic. even i tried bandwidth limiting those pkts.
What is the real solution to this problem ? How can I block such UDP attack?
You could be the target of a DDoS, but more likely you’re contributing to a DDoS targeting someone else. You should configure your router to drop the UDP traffic in question, rather than reject or forward.
Right now I donot have any FIREWALL in place.
In TORCH i can see on IP address with UDP traffic , traffic reaching upto 80-100 mbps which chocks the whole bandwidth.
Even if block this ip in INPUT/FORWARD chain , still the traffic is reaching upto 80-100mbps.
Some one told me about UNICORN UDP flooder, when I downloaded it and run the test, my mikrotik reached traffic full.
I can understand TCP flooding, but how can I prevent UDP flooding which doesnt stops even with the rules?
I am static public IP, it is required for some services. Getting public ip is very difficult here, after many months of requests I am now able to get public ip.
In very old days I faced similar issue, & I have one Linux base Transparent Bridge which was placed between the ISA Server & the Clients for MAC - IP filtering.
With some tuning, I placed it between ISA & Internet & it filtered all unnecessary ports / flooding & block it from reaching ISA which saved at least ISA, but still bandwidth hogging will happen.
ISP need to block them via ther BGP blackhole routes.
They should be informed by you that you are flooded from particular IP or to particular port.
The problem is that UDP traffic does not care about confirmation what happens to packets. Flooder just sends packets and ignores the result … your link is saturated so you are DDOS’s victim.
Rejecting or Dropping packets plays role for TCP traffic. but should be done with your router/firewall.
Rejecting packets lets you inform flooder that your network/host is not accessible but intelligent flooder could check that the packet comes from the attacked device so it is alive. You should mangle TTL to fool flooder that your device is really not accessible.
Dropping packets does not give any information to flooder and you can just wait till it is “tootired” to flood nonresponsing host.
How might TTL mangle help in this case, with UDP with possibly blind transmission?
Also keep in mind, that the resulting ICMP will carry source ip, which would be targeted ip when transmitted by router, so how would it fool the attacker?