I met on the Internet a description of an interesting DDoS attack. Is it possible to protect against this only by the router itself?
There is RB4011. DDoS protection is configured according to the usual principle - collecting addresses into lists and dropping them in the raw chain (dropping in the filter chain is not good, because even with a not very serious attack, the processor goes to 100%). Works great in most cases. Even my home hAP ac2 handles most attacks up to 900 Mbps this way, leaving another 100 for Internet access (I have gigabit at home). The processor is loaded with only 25-35%. But…
Faced an attack that replaces src-address for EVERY package. As a result, a simple attack of only 50,000 packets per second fills the address list with three million addresses per minute. On RB4011, a gigabyte of RAM ends, kernel crash, reboot. Of course, the issue with the RAM is solved by limiting the lifetime of the sheet to 10 seconds, but in general this does not solve the problem, because. only packets starting from the second from the address-list get into raw. And in the case of the substitution of the src-address for each packet, all packets are the first. As a result, the entire attack falls into the filter chain, the CPU goes to 100%, the router is down, the attack target was achieved with an attack width of only 200 Mbps.
it depends on the router resources itself. ie. cpu, ram. but the way you make some firewall rules for that dos - will give you insight whether it is effective or not.
ie. on part 1 of your reading, i could say yes - maybe it is effective enough to protect the target.
on part 2, the attacker change the method - which is using fake srcaddr hence wasting cpu time. this should be resolved by how will you drive your firewall mode : will it be passive nor reactive/aggressive.
There is no protection against DDoS other than having more bandwidth available than the attacker. You absolutely do NOT want complex “anti DDoS” filters with address lists and all that other garbage, you want the junk packets to be discarded as fast as possible with minimal CPU overhead, otherwise the volumetric DDoS becomes a computational DDoS. As the case in the OP shows, a smart attacker uses spoofed IPs which will destroy any attempt at stateful mitigation.
Short answer: No MT routers are not capable of stopping an attack! It is the responsibility of your provider ISP to do so and further up the food chain.
RICH is correct. Focus on setting up the router to allow the traffic you need and simply drop the rest.
Short answer: No MT routers are not capable of stopping an attack! It is the responsibility of your provider ISP to do so and further up the food chain.
I don’t think MT or any brand has any relationship with stopping the ddos.
i would think of the man behind the car. ie. even though you gave me f1 Ferrari to sweep the circuit - it won’t make me Schumacher
the isp and the subscribers - they both have their own specific point of view to run the network. yes, isp help to reduce the possibility of dos - but it doesn’t make the subscribers feel they don’t need to secure their part of the network. the common example for this was smtp smarthost. subscribers machines infected with viruses but the bad things happened on the providers server and ip. - that is why nowadays - ISPs aren’t giving any mail addresses and relay for their subscribers (closed)
in a ddos you already have received the packets saturating your download bandwidth so the damage is done, with raw rules the only achievement is to reduce CPU and Memory usage, but your bandwidth is gone an you are still affected
if the attack only goes towards a few of you public ip addresses its simpler to detect that and filter all traffic going to that few public ip’s, migrate services to other public ip’s, so no need to detect all the faked source ip addresses, this are fake, remember that
then contact your upstream provider for some mitigation at their backbone, this normally is dropping all traffic going towards public ip’s under attack, this when they help you, sometimes they leave you screwed, or they try to sell you some expensive security solution
As mentioned by others, there are two key fundementals of DDoS.
Bandwith (Available vs Attack).
Filtering.
When you understand these two concepts you can see clearly what the solutions are, which are not brand specific. First lets understand the types of attacks and what the goal of the attacker is in each case.
Types of Attacks:
Volumetric
This one is simple, it is a flood style attack where the goal of the attacker is to send as many packets to the target from as many sources as possible to consume all available bandwidth. This attack has nothing to do with services you are hosting or firewall rules you employ (as the target). These need to be resolved at the edges of the network.
Protocol
Here the attacker is using features of the protocol to either cause hangs, consume connection resources or amplify attacks against the target. This is more about packet processing than bandwidth but the two aren’t mutually exclusive in this situation. You can have a high pps and high bandwidth attack, you can also have a high pps and low bandwidth attack. In this case when it is not combined with a bandwidth or volumetric style attack, carefully ordered firewall rules and other protocol attack preventions like syn-cookies can prevent or help mitigate the effect of these attacks.
Application Layer
In this case the attacker is exploiting some service you are hosting (file server, web server, etc) or they are abusing your poorly coded website and consuming all your resources just to deliver the index page of your website by calling a large number of GET requests etc. These are the easiest attacks to mitigate and that can be accomplished either by firewall rules or by recoding your website or patching your hosted service etc.
Solutions:
To successfully and completely mitigate a volumetric attack you need bandwidth (lots of it, think Tbps capacity) and you need multiple routes to redirect flows through. You as a typical end-consumer, have only one route to your router and therefore if every truck from India goes on that road there is no chance that even a dirtbike is getting through. So how does it get solved? Well network providers can re-route traffic flows based on their many routes and peering connections, this allows them to distribute the load not to overwhelm any single edge router. Doing this in combination with likely AI enabled traffic pattern recognition algorithms they can intelligently update all edge routers across their entire network to drop packets from “bad actors” before they even enter the network and therefore protecting whatever the target (maybe you) is on their network. More specifically imagine if you are able to prevent the truck from even leaving each individual warehouse in India, then you have already solved the volume problem before it becomes a problem, the trucks never reach the road and never gain power in volume. In short, the issue is not Mikrotik or any other brand, your bandwidth and peering routes will dictate if you have any options to mitigate volumetric attacks.
For volumetric attacks that are under your bandwidth availability then yes you as the end-consumer can mitigate those (it will consume CPU and will depend on the CPU power of your router). But by using methods listed on this forum like address blocking, dropping entire CIDR ranges that you know are bad or the reverse approach of white listing only certain IPs are all viable solutions.
Protocol attacks depend on the protocol, for ICMP just block ICMP (obviously this may have unintended consequences), for NTP don’t be a potential victim or bot by opening those servers to the public, for TCP-SYN use SYN cookies. In general typical protocol attacks can be blocked by properly using the firewall and most importantly not exposing services to the public or doing so in a way that limits the attack surface (like VPN). Keep in mind that combining a protocol attack with volume can still be an issue if you have low bandwidth.
Application attacks are the easiest to prevent. Don’t open services to the public without proper patching, whitelisting or blacklisting of ip ranges based on geo-location or other clear cases that should never occur and most importantly proper application design don’t code crappy things that consume 10% of your server compute to respond to 1 request.
detecting all the fake source addresses of ddos traffic to block that traffic
afaik,
well if the graph triggers sms - all i could say was don’t overlook sa-da. just do rate limit to throttle the bandwidth. neutralize it to a state safe enough to do the next step.
+++ edit
after all, the only problematic traffic was already limited by bandwidth cap. (this only applies to isps, not subscribers. the subscribers maybe use different methods)
+++ end edit.
blocking was really not a very nice approach since we should have classifiers first. how? the router even can’t be remotely managed😂
