Одна из самых полезных функций в Nginx, которую часто не понимают и потому не настраивают — rate limit . Она позволяет ограничить количество HTTP запросов от пользователей в определённый промежуток времени. Лимиты можно применять к простым GET запросам домашней страницы сайта или же к POST запросам формы логина.

Rate limit можно использовать для усиления безопасности. Например, замедлив перебор паролей для злоумышленника, или для предотвращения DDoS-атаки, снизив количество входящих запросов до типичных для пользователей значений. И тем временем определять по логам атакуемые URL. Также можно предотвратить перегрузку вышестоящих серверов (upstream) во время внезапного наплыва пользователей на сайт.

Как лимиты вообще работают?

Схематичное изображение Windows специально для CoolAdmin

Ограничения запросов в Nginx используют алгоритм «дырявого ведра», широко используемый, чтобы справится со всплесками трафика, когда ширина канала ограничена. Дырявое ведро — хорошая аналогия, ведь, из него вода медленно вытекает сквозь дырки, и оно может переполнится, если добавлять воду слишком быстро. В терминах обработки запросов, вода — это входящий трафик, а ведро — очередь запросов на обработку FIFO-алгоритмом. Протекающая сквозь ведро вода — это запросы, переданные на обработку, а всё, что проливается через край — отклонённые запросы пользователей.

#1 Minecraft » ̶Б̶а̶г̶и̶, Приколы, Фейлы»

Простая настройка Rate Limit

Ограничения настраиваются при помощи двух директив, limit_req_zone и limit_req .

Рассмотрим простой пример:

limit_req_zone $binary_remote_addr zone=cooladmin:10m rate=10r/s;
server location /cooladmin/ limit_req zone=cooladmin;
proxy_pass https://t.me/cooladmin;
>
>

В этом примере директива limit_req_zone описывает лимиты, которые далее используются для ограничения числа пользовательских запросов в локации /cooladmin/ при помощи limit_req .

Директива limit_req_zone описывается в http секции конфигурации и может использоваться во множестве контекстов. Параметры этой директивы:

  • Key – характеристика запросов для их группировки. В примере выше используется системная переменная $binary_remote_addr, которая содержит бинарные представления IP-адресов пользователей. Это означает, что лимиты из третьего параметра будут применяться к каждому уникальному IP-адресу клиента из запроса. В примере мы используем переменную $binary_remote_addr , поскольку она занимает меньше места в памяти, чем её строковая альтернатива $remote_addr.
  • Zone – зона разделяемой памяти, которая используется для хранения состояний IP-адресов и количества их обращений к URL-адресам. Эта память является общей для всех процессов Nginx. Следует отнестись к настройке этого параметра с особым вниманием (см. ниже). Параметр состоит из двух частей: названия зоны zone и объема памяти, после двоеточия. Сведения о состоянии около 16 000 IP-адресов занимают 1 мегабайт, так что в нашей зоне можно хранить около 160 000 записей.

Если места для добавления новой записи недостаточно, Nginx удаляет самую старую запись, чтобы предотвратить исчерпание памяти. Если процесс Nginx’а не может создать новую запись, из зоны может быть удалено до двух записей, которые не использовались в предыдущие 60 секунд. Если свободного пространства все равно не хватает, возвращается ошибка 503 (Service Temporarily Unavailable)

Как обойти защиту » Ты превысил максимальное число регистраций » — Minecraft ( Minecraft Server ) #1

  • Rate задаёт максимальное количество запросов. В примере выше будет принято 10 запросов в секунду. На самом деле, Nginx измеряет количество запросов каждую миллисекунду, поэтому такой лимит означает 1 запрос каждые 100 миллисекунд. Поскольку мы не настраивали всплески (bursts) , каждый следующий запрос, пришедший быстрее, чем через 100 мс после предыдущего, будет отброшен.

Закрепим. Директива limit_req_zone задаёт параметры лимитов и общей памяти, но не управляет применением самих лимитов к запросам. Для окончательной настройки необходимо добавить в блоки location или server директиву limit_req. Выше мы применили лимиты для локации /cooladmin/ в блоке server нашей конфигурации. Тем самым мы ограничили число запросов с уникального IP-адреса клиента одним, сделанным не ранее чем 100 миллисекунд после предыдущего.

Обработка очередей и всплесков

Что же будет, если в нашей конфигурации пользователь отправит 2 запроса к нашему серверу за 100 мс? Сервер вернёт код 503 для второго запроса. Это может оказаться не очень удачным решением, ведь в реальности наши приложения способны обрабатывать такие всплески. Необходимо настроить буфер для входящих запросов. За эту настройку отвечает параметр burst в директиве limit_req. Посмотрим на примере:

location /cooladmin/ limit_req zone=cooladmin burst=20;
proxy_pass https://t.me/cooladmin;
>

В этом примере, для локации cooladmin , каждый запрос, который приходит чаще, чем установленное ограничение, будет помещён в очередь, размер которой 20 запросов.

Параметр burst настраивает количество запросов, которые пользователь может сделать прежде, чем лимиты будут применены и Nginx начнёт отбрасывать запросы.

Это означает, что если от одного IP адреса приходит одновременно 21 запрос, то Nginx отправить в обработку первый, а остальные 20 будут помещены в очередь. Затем каждые 100 миллисекунд запросы из очереди будут отправлены в обработку и пользователь увидит ошибку 503 только если количество запросов от него не уместится в этой очереди или они будут прибывать слишком быстро (быстрее чем 1 запрос в 100 миллисекунд если вы этого ещё не запомнили ).

Читайте также:  Как сделать в Майнкрафте крейсер

Очереди без задержек

В конфигурациях с простым использованием burst есть недостаток. Они обеспечивают сервер плавным потоком трафика, но слишком медлительны для пользователя. Так в примере выше, обработка 20 пакетов от пользователя занимает 2 секунды (Карл!) . Если вам не подходит такое поведение, добавьте параметр nodelay вместе с burst:

location /cooladmin/ limit_req zone=cooladmin burst=20 nodelay;
proxy_pass https://t.me/cooladmin;
>

С параметром nodelay Nginx по-прежнему выделяет очередь для каждого потока запросов, но не делает паузы в отправках запросов из очереди. Вместо этого запросы пересылаются на обработку как только возможно, а очистка слотов в очереди происходит как и выше (да-да, те самые 1 раз в 100 миллисекунд) .

Теперь предположим, что к нам поступает 21 запрос с одного IP-адреса одновременно. Nginx незамедлительно отправляет все эти запросы в обработку, и начинает освобождать очередь, очищая 1 слот каждые 100 миллисекунд. Если мы получили 25 запросов от одного IP адреса, то четыре из них отклоняются со статусом 503, а остальные отправляются в обработку.

Теперь предположим, что через 101 миллисекунду после первой порции запросов отправляется еще 20 запросов одновременно. Свободен только 1 слот в очереди, поэтому Nginx передаёт в обработку только один запрос, а остальные 19 отклоняет с кодом 503. Если спустя 501 миллисекунду пришло ещё 20 новых запросов, то в очереди появилось 5 свободных слотов, потому 5 запросов будут обработаны, а остальные 15 отклонены.

Хозяйке на заметку: Для большинства инсталляций разработчики Nginx рекомендуют использовать burst и nodelay совместно. Cooladmin присоединяется к рекомендации.

Примеры расширенных конфигураций

Комбинируя базовые ограничения скорости с другими функциями Nginx можно реализовать более тонкие ограничения трафика.

Белые списки

Например, мы можем наложить ограничения на количество обращений к серверу со всех IP-адресов, кроме внесённых в белый список.

geo $cooladmin default 1;
10.0.0.0/8 0;
192.168.0.0/24 0;
>
map $cooladmin $cooladmin_key 0 «»;
1 $binary_remote_addr;
>

limit_req_zone $cooladmin_key zone=cool_admin_zone:10m rate=5r/s;

server location / limit_req zone=cool_admin_zone burst=10 nodelay;

В этом примере мы используем директивы geo и map . Блок geo устанавливает значение 0 адресам из белого списка и 1 — всем остальным (по умолчанию) . Затем мы используем map для назначения лимитов:

  • Если $cooladmin равен 0, то в $сooladmin_key будет записана пустая строка.
  • Если в $cooladmin записано 1, $cooladmin_key заполнится как адрес клиента в бинарном формате (используйте именно бинарный формат, экономьте память).

Таким образом, мы обрабатываем одновременно адреса из белого списка и адреса клиентов. Для адресов из белого списка переменная $cooladmin_key будет содержать пустую строку, и директива limit_req_zone для них применена не будет. Как следствие, на адреса из сетей 10.0.0.0/8 и 192.168.0.0/24 не будет наложено ограничений. Для адресов, не входящих в белый список, будет применён лимит в 5 запросов в секунду (или 1 запрос в 200 миллисекунд).

Такой лимит мы применили к корневой «/» локации сервера. Ещё мы настроили возможность всплеска до 10 дополнительных запросов, которые будут обработаны так быстро, как это позволит наш сервер, без дополнительных задержек, так как используется nodelay.

Использование нескольких ограничений в одной локации

Вы можете использовать несколько директив limit_req в одной локации вашего сервера. В таком случае применяться будет только наиболее строгий лимит. Например, если несколько ограничений вводят задержку на входящие запросы, будет использована самая долгая. Если несколько директив разрешают запрос, а одна директива его отклоняет — запрос будет отклонён .

Расширим предыдущий пример, введём дополнительные лимиты для адресов из белого списка:

http # .
limit_req_zone $cooladmin_key zone=cooladmin_zone:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=cooladmin_zone_wl:10m rate=15r/s;

server # .
location / limit_req zone=cooladmin_zone burst=10 nodelay;
limit_req zone=cooladmin_zone_wl burst=20 nodelay;
# .
>
>
>

Адреса из белого списка не попадают под первый лимит cooladmin_zone, но попадают под второй cooladmin_zone_wl и к ним будет применяться ограничение в 15 запросов в секунду (или 1 запрос в 66 миллисекунд). Для всех остальных адресов, по прежнему, применяется лимит в пять запросов в секунду.

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

Настройка связанных функций

Логирование

По умолчанию лог Nginx будет содержать отложенные или отброшенные лимитами записи в формате:

1998/04/04 04:04:04 [error] 228#0: *228 limiting requests, excess: 1.000 by zone «cooladmin», client: 192.251.68.254, server: cooladmin, request: «GET / HTTP/1.0», host: «mr.rob0t»

Поля этого лога:

  • limiting requests – Индикатор того, что лог сформирован обработчиком лимитов.
  • excess – Количество запросов в миллисекунду сверх установленного в конфигурации лимита.
  • zone – Зона общей памяти, используемая в конфигурации. Это поле поможет понять, какой лимит сработал в этом случае.
  • client – IP-адрес клиента.
  • server – IP-адрес сервера или имя хоста.
  • request – HTTP-запрос, отправленный клиентом.
  • host – Значения из заголовка Host протокола HTTP.
Читайте также:  Как сделать бота в майнкрафт

По умолчанию лог отклонённых запросов будет располагаться на уровне error, и будет показан в топике [error]. Лог задержанных запросов будет находится на другом уровне, в info по умолчанию. Чтобы поменять такое поведение, используйте директиву limit_req_log_level . В примере ниже мы помещаем лог отклонённых запросов на уровень warn:

location /cooladmin/ limit_req zone=coollimit burst=20 nodelay;
limit_req_log_level warn;
proxy_pass https://t.me/cooladmin;
>

Коды ошибок, возвращаемые клиенту

По умолчанию Nginx возвращает код 503 (Service Temporarily Unavailable ), если клиент превысил допустимые лимиты. Используйте директиву limit_req_status , чтобы изменить код на другой. Например, на 444 — «Закрытие соединения без передачи заголовка ответа», нестандартный код:

location /cooladmin/ limit_req zone=coollimit burst=20 nodelay;
limit_req_status 444;
>

Блокирование доступа к локации

Если вам необходимо запретить доступ к определённой локации, используйте директиву deny совместно с параметром all:

location /mr.rob0t deny all;
>

Заключение

Этот перевод подготовлен специально для канала ( угадайте какого ) . Надеюсь, статья и её перевод окажутся вам полезны, и помогут настроить веб-сервер правильно.

Если понравилось — жмите лайк, подписывайтесь. =)

Источник: dzen.ru

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

Мануал

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

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

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

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

В этой части мы расскажем, как ограничить пропускную способность сети в веб-сервере 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 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 и контроля безопасности.

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

  • Как контролировать доступ на основе IP-адреса клиента в NGINX
  • Ограничение скорости определенных URL-адресов с Nginx
  • Как защитить паролем каталог с аутентификацией .htpasswd на Nginx
  • Как защитить конкретную страницу паролем в Apache, Nginx, WordPress, на хостинге?
  • Nginx: советы по настройке безопасности
  • Настройка производительности и безопасности Nginx
  • ✍ Как использовать Nginx в качестве обратного прокси
  • Советы и рекомендации по обеспечению безопасности вашего веб-сервера Nginx
  • ️ Полное руководство по безопасности веб-серверов

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!

Добавить комментарий Отменить ответ

Поддержать нас

  • Аудит ИБ (49)
  • Вакансии (12)
  • Закрытие уязвимостей (105)
  • Книги (27)
  • Мануал (2 264)
  • Медиа (66)
  • Мероприятия (39)
  • Мошенники (23)
  • Обзоры (809)
  • Обход запретов (34)
  • Опросы (3)
  • Скрипты (111)
  • Статьи (345)
  • Философия (105)
  • Юмор (18)

Наш Telegram

Социальные сети
Поделиться

Anything in here will be replaced on browsers that support the canvas element

  • Как безопасно использовать команду read на Linux 06.04.2023

Не стоит вводить пароли непосредственно в шелл скрипт. Всякий раз, когда мы указываем пароль на Linux, он должен быть либо невидимым, либо звездочки (*) должны маскировать наш пароль так, чтобы он стал нечитаемым. В этой теме мы рассмотрим различные техники чтения паролей с помощью Bash. Как читать пароли на Bash? Bash имеет встроенную утилиту для […]

Если встал вопрос «как отследить машину», потребуется воспользоваться ГЛОНАСС. Для этого необходимо будет поставить специальное ПО. Оно позволит справиться с задачей без проблем. Анализ можно осуществлять разными способами: на компьютере, смартфоне. Ключевые черты основных способов мониторинга Как отследить машину, где находится, через компьютер?

В этом случае заранее на нее следует поставить трекер. Датчик будет связываться […]

Локальное SEO фокусируется на оптимизации вашего сайта и онлайн-присутствия для поиска по местоположению. Это особенно важно для малых предприятий, которые работают в определенных географических регионах. Локальное SEO позволяет малому бизнесу улучшить свою видимость в Интернете, привлечь больше местных клиентов и конкурировать с крупными брендами. В этой статье мы обсудим важность местного продвижения для малого бизнеса и способы […]

APKHunt – это мощный инструмент, используемый в пентесте приложений Android. Android app pentest, сокращенно от Android application penetration testing, – это процесс анализа Android-приложения на предмет потенциальных уязвимостей безопасности. APKHunt – это инструмент, который помогает обнаружить уязвимости и слабые места в приложениях Android. APKHunt – это инструмент с открытым исходным кодом, разработанный специально для пентеста […]

Источник: itsecforu.ru

SpeedLimit — плагин на ограничение скорости игрока на сервере [1.15 — 1.8]

SpeedLimit - плагин на ограничение скорости игрока на сервере [1.15 - 1.8]

SpeedLimit — плагин для Minecraft, позволяющий владельцам серверов органичить максимальную допустимую скорость передвижения игрока. Будет полезно для Hardcore-режимов, особенностью которых является усложнение оригинальных механик игры.

Как это работает? Очень просто. Если игрок превышает лимит, плагин автоматически телепортирует его в начальную точку движения. Можно настроить в каких мирах будет действовать этот лимит, установить максимальную скорость, а также сообщение, которое будет выводится в чат в случае превышения скорости. При этом можно позволить игрокам обходить лимит, если они падают с высоты.

Не чудеса ли?

Команды

/speedlimit — показать информацию о плагине
/speedlimit reload — перезагрузить работу плагина

Конфигурация


Настройка плагина выглядит следующим образом:

# maximum speed
Максимальная скорость, 1 метр = 1 блок
max-meters-per-second: 20

# allow players to fall down faster than the speed limit (true = allow, false = don’t allow)
Разрешить ли игрокам падать со скоростью свыше лимита
allow-falling-bypass: true

# set speed limit mode, if both are true nothing will happen
Установить ли лимит скорости исключительно в режиме полёта или находясь на земле
only-flying: false
only-on-ground: false

# the message a player will receive if he is above the speed limit
Сообщение, которое выводится в чат при превышении лимита
too-fast-message: «

# worlds that have a speed limit
Миры, в которых действует лимит
worlds:
— world

Источник: ru-minecraft.ru