While trying to secure my ATL, I am reading the well-known article about DDoS protection and I am wondering:
From what I know, the principle against DDoS attacks is to minimize resource usage, so how does adding addresses to lists match that?
My concern is that adding addresses to a list during an attack can quickly exhaust the whole memory and block the system, thus actually assisting the attacker. While that probably depends on the balance between address-list-timeout, the size/speed of the attack and the available bandwidth, that balance seems difficult (if at all possible) to measure/calculate.
So, it seems to me that by protecting from DDoS using this method, one can actually DDoS oneself even more.
What do you think?
What is the right approach to all this?
*Yes, I know the advice from other threads - relying on ISP doing that part, using some service provider for protection and so on. I am just wondering if one can actually do something to protect oneself or is it better not to even try (in which case, what is the purpose of that documentation?)
The idea about creating address lists is to avoid sending any feedback to attacking nodes … which helps to save at least uplink bandwidth. Using the lists in raw firewall also helps to reduce amount of packet processing (even if normal firewall filter rules would eventually drop those packets) … as per packet flow, dropping packets in prerouting phase saves lots of CPU cycles, otherwise spent by connection tracking machinery.
But, as you wrote, saving CPU cycles is offset by RAM usage (to hold the potentially huge address list). So one has to decide which resources are more precious (RAM or CPU) and save those when trying to survive DDoS attack.
I don’t know how ROS’s packet flow matches that of nftables. I am mentioning that because in nftables there is also ingress hook, which comes before prerouting, and experts have told me that if a packet reaches ingress, it is already too late for any DDoS protection, i.e. DDoS must be handled even before ingress. I still haven’t learned how exactly but, from what I have read, one of the approaches is using XDP and eBPF (which doesn’t seem simple at all). None of the terms “xdp” or “bpf” are found in ROS documentation though.
If we assume that prerouting in ROS is equivalent to prerouting in nftables (as it seems), then ROS documentation contradicts the above advice, as prerouting happens even later than ingress.
Another confusing element of this article is that it does not even mention if the DDoS handling rules should be put on top of the rule list, so they take priority (which would be logical). So, this part is quite unclear too.
I would be really interested to read what experts like you think about all this.
xdp, bpf & co want to replace the whole kernel packet handling (i.e. everything drawn in nftables diagram) with a different (simplified) implementation of packet handling. And you’re right, ROS doesn’t do any of it, so just forget about it.
Next the DDoS handling in the pre-ingress: that would be almost impossible in ROS (IMO it roughly translates to fastpath), even ingress hook is IMO not available in ROS.
As you quite well know, surviving DDoS is hard. If one actually requires using all those early low level hooks to make router/firewall survive, then upstream link wouldn’t survive because DDoS packets would use up the whole bandwidth. So then we’re back to the thesis that cooperation of ISP is required in case of massive DDoS.
Would you say the firewall-based approach described in the docs is futile? Especially if everything on the input is dropped by default, i.e. there are no WAN-facing open ports.
I would say that any kind of DDoS protection is mostly futile and the only realistic goal in such case is to keep router/firewall alive … in a sense that it doesn’t start passing forbidden traffic in wrong direction and in a sense that it recovers soon after DDoS attack stops. Pulling WAN cable out of firewall would 100% guarantee the first part but would highly likely introduce very long delay in the second part (it’s hard to notice end of DDoS attack if you can’t see ingress traffic).
Of course it all depends on scale of DDoS attack and the grade of equipment involved … so probably a powerfull router could survive a weak DDoS attack and still allow to pass some legitimate traffic (e.g. when using a CCR2216 on an ADSL line) while a weak router on a fast line (e.g. hAP ac2 on a symmetrical 1Gbps line) wouldn’t stand a chance.
When it comes to DDoS, often dropping unwanted packets is not the problem, the problem is selecting legitimate traffic from unwanted … with wide-scale DDoS there are so many different attackers that only a portion of new packets can be easily correlated with already identified malicious packets. The rest of selection is costly operation.
I guess that confirms the mentioned article in the docs is nothing but a source of false sense of security. Even the proposed TCP SYN cookies technique seems to have significant drawbacks.