Good afternoon, habrovchane! Today we will share with you our thoughts on self-preparation for protection in case of a DDoS attack.
The topic is painful , and not only among users of LiveJournal and other sites under
attack , but also our experts from the
Kaspersky DDoS Prevention project.
Feature of DDoS-attacks in Russia DDoS is the element. It is impossible to predict the element, but it is necessary to prepare for it.
')
A vivid example is a life preserver and lifeboats on ships. It is unlikely that they will save Cthulhu from the almighty, but they can cope with the average storm and other ordinary incidents.
Of course, I would like to advise in advance to assess the risks and to have in mind the supplier of solutions for protection against DDoS attacks, to have an action scenario in case of an attack, etc., but often the events still unfold like this: “until the thunder breaks out - man cross over. "
The operational acceptance of an Internet resource under the protection of all providers of solutions to protect against DDoS looks the same: you will be asked to change the IP address in the DNS records of your resource.
Even if you are offered to move to any secure hosting - it still entails a change of address. Therefore, the very first "rescue equipment" is:
1. Availability of credentials to change the DNS-records in the availability;
2. A preliminary reduction in the lifetime of the DNS record of the resource name to 10-15 minutes.
The experience of Kaspersky Lab shows that the overwhelming majority of attacks can be repulsed without problems, and the main time when a resource is unavailable after a call is just waiting for the users to “switch”.
Secondly - specify in advance what protocols are used in the process of your resource. For some resource owners, it becomes a revelation that, after being placed under protection, personal user accounts and other similar functionality working under the HTTPS protocol stop working.
Our experts bypass the sites and try to reveal the “hidden” functionality, but if the resource owner knew about it initially, it would be easier.
Check in advance the interaction of the components of the resource. Links containing an IP address or local paths can cut off some of the functionality when migrating the attacked component for protection.
And, of course, it is advisable not to bring the resource to a state where, in peacetime, it works “on its last legs”. It is often difficult to verify this, but it is often not necessary to wait for the ability to withstand the load from a site hosted on a shared hosting. Depending on the attack, some parasitic requests may pass through any protection system. Again, no security system can mentally identify and distinguish a bot from a regular user. The analysis takes time, during which parasitic requests will pass from the attacker. The resource must be able to withstand at least a 10-15% increase in load. In the practice of Kaspersky Lab, there have been cases when it was necessary to fight for every extra missed request: in peacetime, the portal processed 3 requests per second, and under attack it turned out that 5 requests per second were disastrous for it.
In general, if a resource is expensive and valuable to your business or business, it should be accompanied accordingly. We often have to see companies that talk about the critical importance of a resource and at the same time not only do not have monitoring systems for its performance, but also administer the resource by outsourcers, who cannot be reached at a critical moment.
Obviously, a change of administrators in 24x7 mode is not available and is needed by everyone, but the same DNS passwords should be available to the person who can be reached at any time.