🛡️ Как ограничить пропускную способность сети на веб-сервере NGINX

Автор cryptoparty На чтение 5 мин Опубликовано 16.06.2022

Для того чтобы пропускная способность вашего приложения не расходовалась одним клиентом, необходимо контролировать скорость загрузки и выгрузки для каждого клиента.

Это обычный контроль безопасности NGINX против DoS-атак (Denial of Service) со стороны злоумышленников, которые просто пытаются злоупотреблять производительностью сайта.

Ранее мы уже рассмотрели:

🌐 Ограничение скорости определенных URL-адресов с Nginx

В этой части мы расскажем, как ограничить пропускную способность сети в веб-сервере NGINX.

Ограничение пропускной способности в NGINX

Для ограничения пропускной способности в NGINX используйте директиву limit_rate, которая ограничивает скорость передачи ответа клиенту.

Она действует в операторах HTTP, server, location и if в блоке location, и по умолчанию задает ограничение скорости для данного контекста в байтах в секунду.

Вы также можете использовать m для мегабайтов или g для гигабайтов.

limit_rate 20k;

Другой связанной директивой является limit_rate_after, которая указывает, что соединение не должно ограничиваться по скорости до тех пор, пока не будет передано определенное количество данных.

Эта директива может быть установлена в HTTP, server.

limit_rate_after 500k;

Вот пример конфигурации для ограничения клиента на загрузку контента через одно соединение с максимальной скоростью 20 килобайт в секунду.

upstream api_service {
    server 10.1.1.10:9051;
    server 10.1.1.77:9052;
}

server {
    listen 80;
    server_name testapp.tecmint.com;
    root /var/www/html/testapp.tecmint.com/build;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html =404 =403 =500;
    }
    location /api {
        proxy_pass http://api_service;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

       
   }
   location /documents {
        limit_rate 20k;
        limit_rate_after 500k;  
}
}

После добавления необходимых настроек, описанных выше, сохраните изменения и закройте файл.

После этого проверьте правильность синтаксиса конфигурации NGINX, как показано ниже:

$ sudo nginx -t

Если все в порядке, перезагрузите службу NGINX, чтобы ввести в действие последние изменения:

$ sudo systemctl reload nginx

Ограничение полосы пропускания и количества подключений в NGINX

При описанной выше конфигурации клиент может открыть несколько соединений для увеличения пропускной способности.

Поэтому дополнительно можно ограничить количество соединений для каждого клиента с помощью такого параметра, как IP-адрес, как мы рассматривали ранее.

Например, вы можете ограничить одно соединение на IP-адрес.

upstream api_service {
    server 127.0.0.1:9051;
    server 10.1.1.77:9052;
}

limit_conn_zone $binary_remote_addr zone=limitconnbyaddr:20m;
limit_conn_status 429;

server {
    listen 80;
    server_name testapp.tecmint.com;
    root /var/www/html/testapp.tecmint.com/build;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html =404 =403 =500;
    }
    location /api {
        limit_conn   limitconnbyaddr  5;

        proxy_pass http://api_service;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

       
   }
   location  /documents {
        limit_rate 50k;
        limit_rate_after 500k;  
        limit_conn   limitconnbyaddr  1;
}
}

Динамическое ограничение пропускной способности в NGINX

В качестве значения параметра директивы limit_rate можно указать переменные для динамического ограничения пропускной способности.

Это особенно полезно в ситуациях, когда скорость должна быть ограничена в зависимости от определенного условия.

В данном примере мы используем блок map.

Он позволил создать новую переменную, значение которой зависит от значений одной или нескольких исходных переменных ($slow и $limit_rate), указанных в первом параметре.

upstream api_service {
    server 10.1.1.10:9051;
    server 10.1.1.77:9052;
}

map $slow $limit_rate {
    1     20k;
    2     30k;
}

server {
    listen 80;
    server_name testapp.tecmint.com;
    root /var/www/html/testapp.tecmint.com/build;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html =404 =403 =500;
    }
    location /api {
        proxy_pass http://api_service;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
   }
   location /documents {
        limit_rate $limit_rate;
        limit_rate_after 500k;
}
}

Вот еще один пример конфигурации, иллюстрирующий динамическое ограничение пропускной способности в NGINX.

Эта конфигурация позволяет NGINX ограничивать пропускную способность на основе версии TLS.

Директива limit_rate_after 512 подразумевает ограничение пропускной способности после отправки заголовков.

upstream api_service {
    server 10.1.1.10:9051;
    server 10.1.1.77:9052;
}

map $ssl_protocol $response_rate {
    "TLSv1.1" 50k;
    "TLSv1.2" 100k;
    "TLSv1.3" 500k;
}

server {
    listen 443 ssl;
    ssl_protocols       TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_certificate     /etc/ssl/testapp.crt;
    ssl_certificate_key   /etc/ssl/testapp.key;

    location / {
        limit_rate       $response_rate; # Limit bandwidth based on TLS version
        limit_rate_after 512;
        proxy_pass       http://api_service;
    }
}

Мы продолжим рассматривать другие темы, касающиеся управления трафиком NGINX и контроля безопасности.

Но, как обычно, вы можете задать вопросы или поделиться своими мыслями об этом руководстве через форму обратной связи ниже.

см. также: