DDoS and how to prevent them

The fight against DDoS attacks is not only difficult, but also exciting. It is not surprising that each system administrator first of all tries to organize defense on his own since it is still possible.

We decided to help you in this difficult matter and publish some short, trivial, and not universal tips for protecting your site from attacks. These recipes will not help you cope with any attack, but they will protect you from most dangers. All our further in-house DDoS protection tips are based on the following important conditions.

Give up on Windows Server

Practice suggests that a site that runs on Windows (2003 or 2008 – it doesn’t matter) is doomed in the case of DDoS. The reason for the failure lies in the Windows network stack: when there are a lot of connections, the server will certainly start to respond poorly. We do not know why Windows Server works in such disgusting situations, but we have come across this more than once or twice. For this reason, this article will focus on protection against DDoS attacks when the server is running on Linux. If you are a happy owner of a relatively modern kernel (starting from 2.6), then the iptables and ipset utilities (for quickly adding IP addresses) will be used as the primary tools, with which you can quickly ban bots. Another key to success is a properly prepared network stack, which we will also talk about later.

Break up with Apache

The second important condition is the abandonment of Apache. If you, it is not an hour, costs Apache, then at least put in front of it a caching proxy – nginx or lighttpd. It is extremely difficult for Apache to give files, and, even worse, it is fundamentally (that is, incorrigibly) vulnerable to the most dangerous Slowloris attack, which allows you to flood the server almost from a mobile phone. To combat the various types of Slowloris, Apache users first came up with the Anti-slowloris.diff patch, then mod_noloris, then mod_antiloris, mod_limitipconn, mod_reqtimeout … But if you want to sleep peacefully at night, it’s easier to take an HTTP server that is invulnerable to Slowloris at the architecture level code. Therefore, all our further recipes are based on the assumption that nginx is used on the frontend.

Use the testcookie module

Perhaps the most important, effective and operational recipe for this article. If DDoS comes to your site, then the testcookie-nginx module, developed by the @kyprizel user hub, can become the most effective way to fight back. The idea is simple. Most often, bots that implement HTTP flood are pretty dumb and don’t have HTTP cookie and redirect mechanisms. Sometimes more advanced ones come across – these can use cookies and process redirects, but rarely a DoS bot does not carry a full-fledged JavaScript engine (although this is more and more common). Testcookie-nginx works as a quick filter between bots and a backend during an L7 DDoS attack, allowing you to filter out junk requests. What is included in these checks? Does the client know how to perform HTTP Redirect, does it support JavaScript, is it the browser that it claims to be (because JavaScript is different everywhere and if the client says that it is, say, Firefox, then we can check it). Validation is implemented using cookies using different methods:

To avoid automatic parsing, the validation cookie can be encrypted using AES-128 and later decrypted on the client side of JavaScript. The new version of the module can set cookies via Flash, which also allows you to effectively filter out bots (which Flash, as a rule, do not support), but, however, it blocks access for many legitimate users (practically all mobile devices). It is noteworthy that it is extremely simple to start using testcookie-nginx. The developer, in particular, provides several understandable examples of use (for different cases of attack) with samples of configs for nginx.

Ban on geo-tag

The non-standard response code 444 can also be useful for an operational ban of clients on a geo-tag. You can severely restrict individual countries that you feel uncomfortable with. Say, it is unlikely that the online camera store from Rostov-on-Don has many users in Egypt. This is not a very good way (frankly – disgusting), since the GeoIP data is inaccurate, and Rostovites sometimes fly to Egypt on vacation. But if you have nothing to lose, then follow the instructions:

Connect the nginx GeoIP module.

Print the geolocation information in the access log.

Further, modifying the shell script above, log in the accesslog nginx’a and add the clients that are kicked out by geography to the ban.

Neural network (PoC)

If you know the insides of your site, then you have a chance that in the most tragic situations such tools based on neural networks, training, and information gathered in advance will help you. In this case, it is very useful to have access.log before the start of DDoS, as it describes almost 100% of legitimate clients, and therefore, an excellent dataset for training a neural network. Moreover, the bots are not always visible with the eyes in the log.