Shulou(Shulou.com)06/02 Report--

This article mainly introduces the method of using nginx to deal with DDOS for system optimization, which is very detailed and has a certain reference value. Interested friends must read it!

Preface

It is well known that DDoS is so common that it is even called the access skill of the hacker community, while DDoS is so fierce that it almost overwhelms one side of the network.

DDOS is characterized by distributed, against bandwidth and service attacks, that is, layer 4 traffic attacks and layer 7 application attacks. The corresponding defense bottlenecks are layer 4 in bandwidth and layer 7 in architecture throughput. For layer 7 application attacks, we can still do some configuration to defend, for example, the front end is Nginx, mainly using nginx's http_limit_conn and http_limit_req modules to defend.

What is distributed denial of service DDoS (Distributed Denial of Service) means distributed denial of service attack? attackers use a large number of "broilers" to launch a large number of normal or abnormal requests to the attack target, exhausting the target host resources or network resources, so that the attacker can not provide services for legitimate users. Typically, attackers try to saturate a system with so many connections and require it to no longer accept new traffic or become so slow that it cannot be used.

In other words, Lao Zhang's restaurant (attacked target) can accommodate 100 customers to eat at the same time, Lao Wang (attacker) next door employs 200 people (broiler), occupies a place in the restaurant but does not eat or drink (abnormal request), the restaurant is full (resources are exhausted), but the customers who really want to eat can not get in, and the restaurant cannot operate normally (DDoS attack is achieved). So the question is, what should Lao Zhang do?

Of course it is. Get out!

Typically, attackers try to saturate a system with so many connections and require it to no longer accept new traffic or become so slow that it cannot be used.

Application layer DDoS attack characteristics

Application layer (layer 7 / HTTP) DDoS attacks are performed by software programs (robots) that can be customized to make the best use of vulnerabilities in a particular system. For example, for a system that does not handle a large number of concurrent connections well, opening a large number of connections and keeping them active by sending a small amount of traffic periodically may deplete the system's new connection capacity. Other attacks can take the form of sending a large number of requests or very large requests. Because these attacks are performed by zombies rather than actual users, attackers can easily open a large number of connections and send a large number of requests very quickly.

The characteristics of DDoS attacks can be used to help mitigate these attacks, including the following (this does not mean an exhaustive list):

-the traffic usually comes from a fixed set of IP addresses, belonging to the machine used to perform the attack. As a result, each IP address is responsible for far more connections and requests than you expect from real users.

Note: do not assume that this traffic pattern always represents a DDoS attack. The use of the forwarding agent can also create this pattern because the IP address of the forwarding proxy server is used as the client address for requests from all real clients it serves. However, the number of connections and requests from forwarding agents is usually much lower than that of DDoS attacks.

-because traffic is generated by robots and means overwhelming the server, the traffic rate is much higher than that that can be generated by human users.

The User-Agent header is sometimes set to a non-standard value.

-the Referer header is sometimes set to a value that you can associate with the attack.

Use NGINX and NGINX Plus to defend against DDoS attacks

NGINX and NGINX Plus have many functions, and when combined with the above DDoS attack features, they can become an important part of DDoS attack mitigation solutions. These features address DDoS attacks by regulating incoming traffic and by proxying back-end servers to control traffic.

Inherent Protection of NGINX event-driven Architecture

NGINX is designed to be a "shock absorber" for your website or application. It has a non-blocking event-driven architecture that can handle a large number of requests without significantly increasing resource utilization.

New requests from the network do not interrupt NGINX's processing of ongoing requests, which means that NGINX can use the techniques described below to protect your site or application from attacks.

For more information about the underlying architecture, see Inside NGINX: how we design for performance and scale.

Limit request rate

You can limit the rate at which NGINX and NGINX Plus receive incoming requests to the typical value of the actual user. For example, you might decide that a real user accessing the login page can only make one request every 2 seconds. You can configure NGINX and NGINX Plus to allow a single client IP address to attempt to log in every 2 seconds (equivalent to 30 requests per minute):

Limit_req_zone $binary_remote_addr zone=one: 10m rate= 30r / m; server {#... Location / login.html {limit_req zone=one; #...}}

The limit_req_zone directive configures a shared memory area called "one" to store the request status of the specified key, in this case the client IP address ($binary_remote_addr). The limit_req instruction in the / login.html block refers to the shared memory area. Location

For a detailed discussion of rate limits, see NGINX and NGINX Plus rate limits on the blog.

Limit the number of connections

You can limit the number of connections that can be opened by a single client IP address, or you can limit it to a value that is appropriate for real users. For example, you can allow each client IP address to open no more than 10 connections to the / store area of your website:

Limit_conn_zone $binary_remote_addr zone=addr: 10m; server {#... Location / store/ {limit_conn addr 10; #...}}

The limit_conn_zone directive is configured with a shared memory area called addr to store requests for the specified key, in which case (as shown in the previous example) the client IP address $binary_remote_addr. In limit_conn the instruction location references the shared memory area for block / storage and sets a maximum of 10 connections from each client IP address.

Close slow connection

You can close a connection that is writing data, which may mean trying to keep the connection open as much as possible (thus reducing the server's ability to accept new connections). Slowloris is an example of such an attack. The client_body_timeout instruction controls the time that the NGINX waits between client body writes, and the client_header_timeout instruction controls the time that the NGINX waits between writing client headers. The default value for these two instructions is 60 seconds. This example configures NGINX to wait no more than 5 seconds between writes or header files from the client:

Server {client_body_timeout 5s; client_header_timeout 5s; #...}

Blacklisted IP address

If you can identify the client IP address used for the attack, you can use this deny directive to blacklist it so that NGINX and NGINX Plus do not accept their connections or requests. For example, if you determine that the attack comes from the address range 123.123.123.1 to 123.123.16:

Location / {deny 123.123. 123.0 / 28; #.}

Or, if you determine that the attack comes from the client IP address 123.123.3123.123.123.5 and 123.123.123.7:

Location / {deny 123.123.123.3; deny 123.123.123.5; deny 123.123.123.7; #...}

Whitelist IP address

If you only allow access to your website or application from one or more specific group or range client IP addresses, you can use the allow and deny directives together to allow access to that site or application only from those addresses. For example, you can restrict access to only addresses in a specific local network:

Location / {allow 192.168.1.0 take 24; deny all; #...}

Here, the deny all directive blocks all client IP addresses that are not within the scope specified by the allow directive.

Use caching to smooth traffic spikes

You can configure NGINX and NGINX Plus to absorb a large number of traffic spikes caused by attacks by enabling caching and setting some cache parameters to unload requests from the backend. Some useful settings are:

The updating parameter proxy_cache_use_stale of this directive tells NGINX that when it needs to get an update of a stale cache object, it should only send an update request and continue to provide the stale object to the client requesting it during reception time from the back-end server. When repeated requests for a file are part of an attack this significantly reduces the number of requests to the back-end server.

The keys defined by the proxy_cache_key directive usually consist of embedded variables (the default key $scheme$proxy_host$request_uri, which has three variables). If the value contains a $query_string variable, an attack that sends a random query string may result in excessive caching. Query_string We recommend that you do not include variables in variables unless you have a special reason.

Block request

You can configure NGINX or NGINX Plus to block several requests:

Request a specific URL that seems to be targeted

Requests with User-Agent headers set to values that do not correspond to normal client traffic

Request to set the Referer header to a value that can be associated with the attack

Requests for other header files with values that can be associated with the attack

For example, if you determine that the target of a DDoS attack is URL / foo.php, you can block all requests for that page:

Location / foo.php {deny all;}

Alternatively, if you find that the User-Agent header value of DDoS attack requests is foo or bar, you can block these requests.

Location / {if ($http_user_agent ~ * foo | bar) {return 403;} #...}

This variable refers to a request header, which is the header in the above example. A similar method can be used for other headers that have values that can be used to identify attacks. Http_*name* ``user-Agent

Restrict connections to back-end servers

NGINX or NGINX Plus instances can usually handle more concurrent connections than load-balanced back-end servers. With NGINX Plus, you can limit the number of connections to each back-end server. For example, if you want to limit the number of connections NGINX Plus can make to two back-end servers in the upstream group of the site:

Upstream website {server 192.168.100.1:80 max_conns=200; server 192.168.100.2:80 max_conns=200; queue 10 timeout=30s;}

The parameters that max_conns applies to each server specify the maximum number of connections opened by NGINX Plus. This queue directive limits the number of requests queued when all servers in the upstream group reach their connection limit, and the timeout parameter specifies the time to keep requests in the queue.

Dealing with scope-based attacks

One way to attack is to send a header with a very large value of Range, which can lead to a buffer overflow. For a discussion of how to use NGINX and NGINX Plus to mitigate such attacks, see using NGINX and NGINX Plus to protect CVE-2015-1635.

Deal with high load

DDoS attacks usually result in high traffic loads. For tips on tuning NGINX or NGINX Plus and operating systems that allow the system to handle higher loads, see tuning the performance of NGINX.

Identify DDoS attacks

So far, we have focused on how you can use NGINX and NGINX Plus to help mitigate the impact of DDoS attacks. But how can NGINX or NGINX Plus help you detect DDoS attacks? The NGINX plus status module provides detailed indicators of balanced traffic on loaded back-end servers that you can use to find abnormal traffic patterns. NGINX Plus comes with a status dashboard web page that graphically describes the current state of the NGINX Plus system (see examples on demo.nginx.com). The same metrics can also be used with API, which you can use to provide metrics to custom or third-party monitoring systems, where you can perform historical trend analysis to discover abnormal patterns and enable alerts.

These are all the contents of this article entitled "using nginx to deal with DDOS for system optimization". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.