In the last post, we talked about the protectability from DDoS attacks, understood the main parameters it depends on and gave the example of two systems which had dramatic differences in their protectability potential due to the architecture that the systems had. Today we will start discussing the first goal that needs to be achieved in order to ensure security.
So, the goal #1 – perhaps the simplest – is to give the attacker as little information as possible.
Example from our practice
About five years ago, we faced a very expensive, several-week-long, intense DDoS attack on a popular gaming service. The capacity we had at that time was not enough to mitigate it completely. A trick helped: since the service was divided into an authentication server and game servers, we agreed with the developers that after authentication, the player was given an IP address that strictly corresponds to one of the 32 pre-allocated segments of the Internet depending on the IP from which this user connects. In addition, we asked our service providers to restrict these segments on the upper level so that each individual address can only accept requests from a specific segment of the Internet. As a result, the intensity of the attack decreased by 32 times – and we successfully coped with it. Our advantage was that the attacker didn’t know exactly which IP addresses to attack. I.e., it is very important to minimize the opportunities available to the attacker to check the health of the service.
Put yourself in the attacker’s shoes
Imagine yourself, for example, as an attacker trying to bring down some Internet Service Provider (ISP). After scanning its network, you will find out what its IP addresses respond to, and to which requests (let’s say, ping or TCP probe). But what if you lose all verification methods? First of all, you won’t be able to tell if the attack was successful. And if your goal is merely to stop the Internet for the ISP’s clients, then without an insider, you will be able to tell if you are successful or not. As a result you will just switch to other victims with which you can easily tell whether your attack is successful.
Finally, you need to take care of “general” security. It is not uncommon for hackers to try to hack a server after several failed DDoS attacks to learn more about its architecture and find out some important details for subsequent attacks.
Recommendations that will help to achieve “Goal #1”
- When designing a system, imagine yourself as an attacker and evaluate how you could test the performance of your service. By minimizing the possibility of such verification, you will significantly reduce the probability of a successful attack.
- Don’t forget to think about “general” security measures (protection from hacking), because if a DDoS attack fails, a hacker will most likely start actively searching for vulnerabilities.