January 14, 2016 at 14:17Case NGINX: How to Resist DDoS Attacks
- Transfer
The main goal of our work is to make IaaS simple and understandable even for those who have not encountered the IT field. Therefore, we carry out continuous optimization of all systems and talk about what we managed to do in our blog on Habré.
A couple of examples:
Today we decided to take a look at Western experience and briefly analyze the topic of load balancing. We were attracted by a note on the topic of working with DDoS attacks. / Photo by Dennis van Zuijlekom / CC If you start with the terminology, then DDoS can be defined as an attack on an IT system in order to bring it to a state in which it will be impossible to service requests with the proper level of quality. The quantitative impact that is produced by special bots that use this or that vulnerability for a DDoS attack works here.
Weak readiness of the system to handle a large number of requests or parallelize connections and load balancing can become such a vulnerability. In the case of the beginning of a simple DDoS attack, traffic to your system will go from certain addresses that will generate an anomalous number of requests and connections. In addition to the traffic intensity, the attack can be calculated on the basis of non-standard User-Agent headers.
NGINX allows you to manage traffic by routing it and limiting the frequency of incoming requests by average indicators specific to people (rather than bots). In addition, you can set the plug for the number of connections that can come from one IP.
An additional possibility is the rupture of compounds that are practically not used, but remain open for a significant period of time. Thus, you can protect the system from a Slowloris attack.
A tougher measure would be to blacklist IP using the deny directive. After that, NGINX will no longer process requests from this address. An alternative is to set the range of allowed IPs. / Photo by Joe The Goat Farmer / CC To prevent traffic jumps, you can use the caching option. NGINX will be able to update obsolete objects as necessary and thereby smooth out peak loads on your system.
Additionally, you can configure filters by URL (for the case when a certain part of your resource is being attacked) and User-Agent headers (if you would like to cut off abnormal traffic that is not like normal user behavior). There is still the possibility of limiting the number of connections at the level of internal routing between servers.
The NGINX internal toolkit allows you to analyze various metrics of incoming traffic. Monitoring is also available through the API.
A couple of examples:
Today we decided to take a look at Western experience and briefly analyze the topic of load balancing. We were attracted by a note on the topic of working with DDoS attacks. / Photo by Dennis van Zuijlekom / CC If you start with the terminology, then DDoS can be defined as an attack on an IT system in order to bring it to a state in which it will be impossible to service requests with the proper level of quality. The quantitative impact that is produced by special bots that use this or that vulnerability for a DDoS attack works here.
Weak readiness of the system to handle a large number of requests or parallelize connections and load balancing can become such a vulnerability. In the case of the beginning of a simple DDoS attack, traffic to your system will go from certain addresses that will generate an anomalous number of requests and connections. In addition to the traffic intensity, the attack can be calculated on the basis of non-standard User-Agent headers.
NGINX allows you to manage traffic by routing it and limiting the frequency of incoming requests by average indicators specific to people (rather than bots). In addition, you can set the plug for the number of connections that can come from one IP.
An additional possibility is the rupture of compounds that are practically not used, but remain open for a significant period of time. Thus, you can protect the system from a Slowloris attack.
A tougher measure would be to blacklist IP using the deny directive. After that, NGINX will no longer process requests from this address. An alternative is to set the range of allowed IPs. / Photo by Joe The Goat Farmer / CC To prevent traffic jumps, you can use the caching option. NGINX will be able to update obsolete objects as necessary and thereby smooth out peak loads on your system.
Additionally, you can configure filters by URL (for the case when a certain part of your resource is being attacked) and User-Agent headers (if you would like to cut off abnormal traffic that is not like normal user behavior). There is still the possibility of limiting the number of connections at the level of internal routing between servers.
The NGINX internal toolkit allows you to analyze various metrics of incoming traffic. Monitoring is also available through the API.