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:
- Give the attacker as little information as possible.
- Provide as much information as possible to the DDoS protection company.
- Ensure clear opportunities for filtering the attacks.
WHAT IS THE PROBLEM
The key goal of any DDoS protection is to ensure the availability of an online service under attack as well as without it.
But the problem is, if the service has availability issues even without an attack, under attack this issue will become more evident.
Which parameters can impact the availability of an online service?
- Number of points of failure – the fewer of them, the more reliable the service is and vice versa. That is why, for example, thoughtless use of Round-Robin DNS, instead of increasing availability, can lead to unexpected issues for some clients when one of the IP addresses becomes unavailable.
- Redundancy on the application layer. We discussed the taxi automation service in one of the previous posts. It uses several IP addresses which are not consecutive and from different subnets. So if one IP goes down, the service automatically reconnects taxi drivers to another one. I think you will agree that it will be difficult to arrange an efficient attack on such a service.
- Dependence of system components on each other and their ability to work independently. Let’s recall the game service that we described earlier, which uses the same game database as the website. The website could work without this connection (merely not showing the number of players online), but because of bad system design, the unavailability of the game database will lead to the unavailability of the website and players will not be even able to read an announcement regarding the outage.
RESISTANCE TO WEAK ATTACKS IS THE BASIS OF SERVICE RELIABILITY
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 data centers, 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.
Typical example
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.
OUR RECOMMENDATIONS
- Make sure that the service is highly available without an attack: check the points of failure, the dependency of components on each other, and their redundancy.
- Ensure that your system is sustainable to weak attacks, both at the network, OS and application levels.
- Distribute different functions to different IP addresses — and inform your DDoS protection company about it.
Credit Card
Bank Transfer (invoice)
