Today we will discuss the last goal (but not least) that needs to be completed to ensure the protectability from DDoS - ensuring the availability of the service during an attack.
Let us rehearse the last three goals we discussed in the previous posts:
But the problem is, if the service has availability issues even without an attack, under attack this issue will become more evident.
The idea is simple: if an online service does not “survive” a weak attack, it will be powerless against a serious one.
In some cases, it is technically not possible to provide 100% filtering traffic. For example, if Anti-DDoS protection is connected in asymmetric mode (only the incoming traffic passes through the filters, and not outgoing). This way of connection is often used by datacenters, hosting providers, and most ISPs. In such situations, the attack is sometimes not completely filtered — merely mitigated. Ideally, your service should be able to ensure the performance and availability during such a weakened attack.
One of our clients was under the attack via UDP and the attack was unsuccessful.Then the attacker started HTTP flood against his website. The attack wasn’t very strong. And if the client had a DDoS protection service from an attack of such nature it would easily reflect the attack. But the client refused to connect Layer-7 protection from HTTP attacks and his whole infrastructure not only the website, went down. The reason was that the client used a pretty old router on the edge of his network, and it just “died” from the number of TCP connections generated by this small HTTP botnet. Conclusion is - you should evaluate the sustainability to weak attacks not only of the server on which the service is deployed, but also of the entire network where it is located. Also it is a question that you should answer yourself, whether you really should use outdated or SOHO equipment on the corporate network edge.
It is often useful to optimize the network stack of the operating system to improve system sustainability. For example, NIC interrupts can be distributed across different processor cores. There are many articles on the Internet about how to do this better.
And, of course, you need to take care of the sustainability of applications. You need to make sure that it performs “heavy” functions only after the authorization procedure is completed. In this case, an application will be able to withstand the invasion of bots, because it spends the main reserve of server performance only on legitimate users.
Finally, you need to separate the services by dividing their functions into different IP addresses. For example, the website separately, the authentication service - separately, and the other services - also into separate addresses. This separation will allow you to cut off many DDoS attacks in advance.