Hi,
I have recently setup a TeamSpeak 3 Server to provide Voice Services to my Clients on Network.
However shortly after putting on Public IP I started receiving UDP Flooding. The behavior is very odd, as the IP from which flooding is being done is caught in a dynamic Address-List and all packets are dropped from that source, but the Interface gets jammed up showing 98Mbps or 95Mbps. This create a huge timeout on all other Network Services, and sometimes even my backend provider blacklists my IP saying a DDoS attack was noticed on this IP. This sort of flooding usually comes over UDP.
Is there any possible way to protect my system / network from this using Mikrotik Firewall.
To give a better idea what happens during the attack to my router, I am attaching a sample snapshot generated for Firewall Testing purpose. Any other details can be provided for the same.
Have you tried a firewall chain that’s packet rate limited?
Hi,
Not working, attached snapshot.
See if you can use torch for your local address and udp as protocol to see where they are coming from?
Since UDP is connectionless, the destination IP/port is probably what you have to use to see the traffic.
Hi,
Snapshot in my initial post shows the torch screen also, there I tested it from my local IP address “10.6.24.2”. I have a perl script which I use to perform this this, I define port, packet size and few other parameters in there and then start the test.
So I’m assuming you have a similar setup to this guy:
http://forum.mikrotik.com/t/udp-flood-spoof-ip-request-hurricane-to-mikrotik/8511/1
and sadly his solution was to install an additional mikrotik to just filter udp traffic to prevent exactly what you’re experiencing.
You’re pretty much the victim of a DOS attack unless you can figure out the true source as a virus or somesuch.
And just to be sure, firewall rule on rate limit should be on ‘forward’ chain if passing through router, ‘input’ if directed at the router. Might want to try both and see which is more effective.
Does traffic stop when you stop forwarding port and drop all UDP packets directed at that port?
Hi,
It is somewhat similar, however I can not add another Mikrotik instance, as still my core router will be receiving this attack which at some time will get saturated link.
Core router is also a Mikrotik Router.
I thought of implementing PCQ on Interface Queue to restrict complete traffic, but again not sure will this work or not. As it is a bit dangerous also, as I also do not have physical access to this router, and if it goes out of reach then it will cost me 2 days.
Will always welcome more suggestions and ideas.
You can’t stop traffic directed to you that has already reached your external interface.
The best option is to request your upstream provider restrict and/or block it themselves as once it reaches you the only thing you can do is drop it. If you’re doing BGP some providers have a specific BGP community you can use to blackhole certain IP addresses which might help in your case.
Hi,
Yes that is exactly what I initially figured out. My upstream provider does blackhole my IP address and it blocks everything. Up till now I have not been able to get any updates from my provider as to how we can control this.
Lets see, if I come up with any solution, I will share it here.
Hi.
How did you do the setup for Teamspeak on the Mikrotik unit?
Please help
Try this and it will work, just remember to change interface name and port if required
add action=drop chain=forward in-interface=ether1 src-address-list=“SIP Hacker”
add action=add-src-to-address-list address-list=“SIP Hacker” address-list-timeout=2w chain=forward connection-state=new dst-port=5060 in-interface=ether1 protocol=udp src-address-list=“SIP Trial”
add action=add-src-to-address-list address-list=“SIP Trial” address-list-timeout=15s chain=forward connection-state=new dst-port=5060 in-interface=ether1 protocol=udp src-address=0.0.0.0/0
add action=drop chain=forward disabled=yes in-interface=ether1 src-address-list=“SIP Hacker”
add action=add-src-to-address-list address-list=“SIP Hacker” address-list-timeout=1d chain=forward connection-state=new disabled=yes dst-port=9070 in-interface=ether1 protocol=udp src-address-list=
“SIP Trial”
Basically when you block input your system still replies so just block the reply to unsuccessful attempt..