Has anyone seen how to prevent this overload known as Wintraff?
My rules against denial-of-service attack can not stop.?
Anyone know how to solve this problem?
https://www.youtube.com/watch?v=KH3NOFQmQa0
This attack seems a kind of UDP flooding, how to prevent this from happening?
1.) UDP traffic does not care if the traffic gets where it is supposed to or not, it will happily keep sending traffic at full speed no matter what. It has no throttling mechanism built in like TCP.
2.) You cannot control what traffic a MikroTik receives on an interface from the router itself, you can only control what the MikroTik sends out of an interface.
So that means if someone that is connected to your router/network over a Gig link and they decide to send the MikroTik 1 Gig of UDP traffic, the router is going to get it and needs to deal with it. There is nothing that can be done from the MikroTik itself to cut down on that traffic, it needs to be throttled closer to the source of the traffic. Even deciding to drop all of that traffic in the router doesn’t affect the client as once again, UDP doesn’t care if the traffic ever gets where it is supposed to, it will just keep sending it.
Thanks for the reply friend,
But how can I treat it?
Through the layer two with switch?
It depends on where it is coming from, and your network design. If it’s within your network, then ideally you can do something about it on layer2 close to where the client is connected. If it’s a managed switch you can see if they have any queue settings, or something that would cut down on the traffic they are allowed to send, same thing for if they are connected to an access point. If it’s coming from outside of your network, you need to talk to your provider to help identify and stop the traffic on their side of things.
ok, for internal network I even accept that the device level two can handle the traffic, but for external traffic coming from the provider, there’s nothing I can do?
There’s not much you can do yourself for external traffic because it’s being delivered to you by your provider, a network you have no control over. They are just forwarding the packets on like they are supposed to. You can work with them to block, or cut down on specific traffic.
Well, I agree with you that I have no responsibility to control the external traffic, but I can not allow a traffic injection (deliberate abusive overload) over UDP protocol, interfere with the performance of my network right?
See another example below?
https://www.youtube.com/watch?v=sTB2bTkIiyM
It is unacceptable there is no solution to this.
There is something you can do, I mentioned it several times. Call your provider, let them know about the DOS and have them investigate and cut down/block on the traffic on their network. Yes it’s a manual process, but there is no other mechanism that is available for any vendor. If you wanted to script something, I supposed to could pull in a Netflows collector and have it send out an automated email with the necessary information when something like that is spotted, but the provider would still need to respond and take action after being notified.
If I can blast 100Mbps of traffic across your provider (lets say it’s Comcast) towards you and they deliver it, it is no different to your router than if the person doing it is directly connected to your router. The traffic is delivered, and now the router needs to do something about it, be it drop it or process it for delivery. The bandwidth has been consumed already by the fact it was delivered by Comcast, the router CPU cycles have been used because it needs to process the traffic now.
Any provider will most likely not let you peer with them via BGP and send them blackhole routes for IP addresses you don’t own. That is extremely dangerous for them to do and could very easily be abused. Let’s say I spoof my source address to the DNS servers your network uses, and that causes you to send them the blackhole route, all of the sudden you and anyone else that uses those servers have no internet service because the DNS servers are unreachable.
So mate,
Since there is an automatic solution to this overhead, I thought about using a script to detect the traffic above normal and by that, cut all traffic when an overload is detected. I know this is a kludge (palliative), but it can at least help correct? Someone has another tip or script that could be created if your link was attacked by an overload of UDP packets?
No manifestation?
From Winbox screens:
This screen is not mine. Is an example 
The discussion is about the external and internal traffic too. Both tools like hping3 and Wintraff detonate internal and external traffic, and I’m trying a viable solution to this. I researched on the internet a lot about this and a workaround to solve part of the problem is to control the ICMP by time and size of the package, because the two programs start the test with ICMP packets.
Any solution you come up with will be a kludge really. The issue is, you need to cut off the undesired traffic as close to the source as possible, be that on your own layer2 network, or on an outside providers network. Since you cannot control an outside providers network, you need to work within their framework for them to not deliver specific kinds of traffic to you, or deal with their process for stopping a DoS attack. They may or may not accept an automated email for example, or may take hours or days to respond and take action once informed of an issue. Remember, once the traffic is delivered the router needs to deal with it one way or the other, so the idea is for the traffic to not be delivered. The router itself cannot control what it receives, only what it sends.
The closest you can get to something that would be automated is using a 3rd party server with something like NFSen or some other netflows collector. You could probably get it to watch for specific kinds of outlying traffic and send an alert on something being off, and take action that way. Tailoring your solution to a specific program isn’t the best either. Just because those programs signal first with ICMP and can be cut down a bit that way doesn’t mean that it can or will prevent someone just blasting UDP traffic at you. Programing a Netflows collector is outside the scope of this forum, it is easy to get the MikroTik to forward netflwos data to a collector however.
Thank you for the information.