Limit req zone nginx

Установка

Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.

Измени строку приветствия Web-сервера

Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:

Замени их на что-то вроде этого:

Удали все неиспользуемые тобой nginx-модули

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

Выполни сборку с помощью следующих команд:

Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘—help’.

Нужны ли ограничение скорости обработки запросов и шейпинг трафика?

Поговорим о параметре . Представьте, что флаг, о котором мы говорили выше, может принимать значения больше единицы. В этом случае он будет отражать максимальное количество запросов, которые NGINX должен пропустить в рамках одной пачки (burst).

Теперь это уже не «дырявое ведро», «маркерная корзина» (token bucket). Параметр определяет временной интервал между запросами, но мы имеем дело не с токеном типа true/false, а со счетчиком от до . Счетчик увеличивается каждый раз, когда проходит рассчитанный интервал времени (срабатывает таймер), достигая максимального значения в . Напомню еще раз: — это количество запросов, а не скорость их пропускания.

Когда приходит новый запрос, NGINX проверяет доступность токена (счетчик > 0). Если токен недоступен, запрос отклоняется. В противном случае запрос принимается и будет обработан, а токен считается израсходованным (счетчик уменьшается на один).

Хорошо, если есть неизрасходованные burst-токены, NGINX примет запрос. Но когда он его обработает?

Мы установили лимит в 5r/s, при этом NGINX примет запросы сверх нормы, если есть доступные burst-токены, но отложит их обработку таким образом, чтобы выдержать установленную скорость. То есть эти burst-запросы будут обработаны с некоторой задержкой или завершатся по таймауту.

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

Приведем простой пример: скажем, у нас установлен лимит и равен . Что будет, если NGINX получит сразу 5 запросов?

• Первый будет принят и обработан.
• Поскольку разрешено не больше 1+3, один запрос будет сразу отклонен с кодом состояния 503.
• Три оставшихся будут обработаны один за другим, но не мгновенно. NGINX пропустит их со скоростью , оставаясь в рамках установленного лимита, а также при условии, что не будут поступать новые запросы, которые также используют квоту. Когда очередь опустеет, счетчик пачки (burst counter) снова начнет увеличиваться (маркерная корзина начнет наполняться).

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

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

nodelay

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

В результате всплески трафика все же будут достигать сервисов, расположенных за NGINX, но эти всплески будут ограничены значением .

Сценарии настройки

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

1. Backend на https

Предположим, что наши внутренние серверы отвечают по SSL-каналу. Таким образом, нам нужно отправлять запрос по порту 443. Также схема проксирования должна быть https.

Настройка сайта:

server {
    …
    location / {
        proxy_pass https://dmosk_backend;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
    …
}

* обратите внимание на 2 момента:

1. Мы в схеме подключения proxy_pass указали https. В противном случае при подключении NGINX будет возвращать ошибку 400.
2. Мы задали дополнительные опции proxy_set_header, которых не было в примерах выше. 

Настройка upstream:

upstream dmosk_backend {
    server 192.168.10.10:443;
    server 192.168.10.11:443;
    server 192.168.10.12:443;
}

* в данном примере мы указали конкретный порт, по которому должно выполняться соединение с бэкендом. Для упрощения конфига дополнительные опции упущены.

2. Разные бэкенды для разных страниц

Нам может понадобиться разные страницы сайта переводить на разные группы внутренних серверов.

Настройка сайта:

server {
    …
    location /page1 {
      proxy_pass http://backend1;
    }
    location /page2 {
      proxy_pass http://backend2;
    }
    …
}

* при такой настройке мы будем передавать запросы к странице page1 на группу backend1, а к page2 — backend2.

Настройка upstream:

upstream backend1 {
    server 192.168.10.10;
    server 192.168.10.11;
}
upstream backend2 {
    server 192.168.10.12;
    server 192.168.10.13;
}

* в данном примере у нас есть 2 апстрима, каждый со своим набором серверов.

3. На другой хост

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

Настройка сайта:

server {
    …
    location / {
        proxy_pass https://dmosk_backend;
        proxy_set_header   Host             internal.domain.com;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
    …
}

* в данном примере мы будем проксировать запросы на бэкенды, передавая им имя хоста internal.domain.com.

4. TCP-запрос

Рассмотрим, в качестве исключения, TCP-запрос на порт 5432 — подключение к базе PostgreSQL.

Настройка сайта:

server {
    listen 5432;
    proxy_pass tcp_postgresql;
}

* в данном примере мы слушаем TCP-порт 5432 и проксируем все запросы на апстрим tcp_postgresql.

Настройка upstream:

upstream tcp_postgresql {
    server 192.168.10.14:5432;
    server 192.168.10.15:5432;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.14 и 192.168.10.15.

5. UDP-запрос

Рассмотрим также и возможность балансировки UDP-запросов — подключение к DNS по порту 53.

Настройка сайта:

server {
    listen 53 udp;
    proxy_pass udp_dns;
    proxy_responses 1;
}

* в данном примере мы слушаем UDP-порт 53 и проксируем все запросы на апстрим udp_dns. Опция proxy_responses говорит о том, что на один запрос нужно давать один ответ.

Настройка upstream:

upstream udp_dns {
    server 192.168.10.16:53;
    server 192.168.10.17:53;
}

* запросы будут случайным образом передаваться на серверы 192.168.10.16 и 192.168.10.17.

Интеграция 1С с ГИИС ДМДК

ГИИС ДМДК — единая информационная платформа для взаимодействия участников рынка драгоценных металлов и драгоценных камней. с 01.09.21 стартовал обязательный обмен данными с Федеральной пробирной палатой (ФПП) исключительно через ГИИС. А постепенно — с 01.01.2022 и с 01.03.2022 — все данные о продаже драгоценных металлов и камней должны быть интегрированы с ГИИС.
У многих пользователей возникает вопрос как автоматизировать обмен между программой 1С и ГИИС ДМДК.
В настоящей статье ВЦ Раздолье поделится своим опытом о реализации такого обмена.
Автор статьи — Мордовин Антон — архитектор систем на базе 1С Внедренческого центра «Раздолье».

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

Доступная конфигурацияПривлекайте ровный трафик, но это не очень практично, потому что это сделает ваш сайт медленным. В нашем примере 20-й пакет в очереди ожидает пересылки в течение 2 секунд, и ответ на него больше не может быть полезен для клиента. Чтобы разрешить эту ситуацию, пожалуйста,Добавлено в параметрыпараметр:

Использовать этоПараметры NGINX все равно будутПараметр выделяет слоты в очереди и накладывает настроенное ограничение скорости, но оно не реализуется путем пересылки запросов через определенные промежутки времени. И наоборот, когда запрос поступает «преждевременно», если в очереди есть свободные слоты, NGINX немедленно перенаправит запрос. Он помечает слот как «используемый» и не освобождает слот для других запросов до тех пор, пока не пройдет соответствующее время (в нашем примере 100 миллисекунд).

Как и раньше, предположим, что очередь из 20 слотов пуста, и с данного IP-адреса одновременно поступает 21 запрос. NGINX немедленно пересылает все 21 запрос и отмечает 20 временных интервалов в очереди как занятые, а затем освобождает 1 временной интервал каждые 100 миллисекунд. (Если вместо этого существует 25 запросов, NGINX немедленно перенаправит 21 из них, отметит 20 слотов как занятые и отклонит 4 запроса со статусом.。）

Теперь предположим, что через 101 мс после пересылки первого набора запросов одновременно поступает 20 запросов. Только 1 слот в очереди был освобожден, поэтому NGINX перенаправляет 1 запрос и отклоняет 19 других запросов со статусом статуса, И наоборот, если до прихода 20 новых запросов прошло 501 миллисекунда, то 5 временных интервалов свободны, поэтому NGINX немедленно перенаправляет 5 запросов и отклоняет 15.

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

нота:Для большинства развертываний мы рекомендуем включить в инструкциюс участиемпараметр。

Доступ с определенных IP-адресов

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

В настройке виртуального домена:

location / {
    deny  192.168.0.15;
    allow 192.168.0.0/24;
    allow 2001:0ab3::/32;
    deny  all;
}

* в данном примере мы разрешаем доступ для всех компьютеров сети 192.168.0.0/24 (за исключением 192.168.0.15) и компьютеру с адресом ipv6 2001:0ab3::. Остальным доступ запрещен. 

Если мы хотим сделать ограничение не для конкретного сайта, а для всего nginx (всех сайтов), то прописываем настройки в общем конфигурационном файле секции http:

vi /etc/nginx/nginx.conf

http {
    …
    deny  192.168.0.15;
    allow 192.168.0.0/24;
    allow 2001:0ab3::/32;
    deny  all;
    …
}

После перезапускаем NGINX одной из команд:

systemctl reload nginx

service nginx reload

Ограничение доступа к определенной папке

Стоит отметить, что блокировать доступ по IP-адресу можно не только ко всему сайту, но и к определенным директориям, например:

location /install {
    allow 192.168.0.15;
    deny  all;
}

* в данном примере мы запрещаем доступ к папке install, но разрешаем устройству 192.168.0.15.

Разрешить только локальные запросы

Самый правильный способ, настроить, чтобы NGINX слушал только на локальном адреса, например, listen 127.0.0.1:80;

Но если такой метод, по каким-либо причинам нам не подходит, делаем так:

location / {
    allow 127.0.0.1;
    deny  all;
}

Действие с IP по условию

В зависимости от определенного IP-адреса NGINX может выполнять различные действия, а не только запрет доступа. Например, перенаправление:

location / {
    …
    if ($remote_addr != 127.0.0.1) {
        return 301 https://$host$request_uri;
    }
    …
}

* в данном примере мы перенаправляем всех посетителей по пути https://$host$request_uri, кроме запросов с IP-адреса 127.0.0.1.

Использование Web интерфейса для настройки

Если лезть и разбираться в конфигах и командах не очень хочется то можно поставить «Nginx Proxy Manager» https://github.com/jc21/nginx-proxy-manager.

Особенности

• Красивый и безопасный интерфейс администратора на основе Tabler
• Легко создавать домены пересылки, перенаправления, потоки и 404 хосты, ничего не зная о Nginx
• Бесплатный SSL с использованием Let’s Encrypt или используя ваши собственные пользовательские SSL-сертификаты
• Списки доступа и базовая HTTP-аутентификация для ваших хостов
• Расширенная конфигурация Nginx, доступная для суперпользователей
• Управление пользователями, разрешения и журнал аудита

Запускается как докер контейнер

В базе на сколько понимаю работает в SQLite, можно подключить к Mysql.

После установки доступен по http://127.0.0.1:81.

Благодарю Алексея Лустина за информацию.

Интеграция 1С 8 и HostCMS

Интеграции 1С с сайтами очень сложно оценивать, ибо на сайте разработчика CMS, а может, и на странице конкретного модуля, зачастую можно найти инструкцию подключения обмена, но в ходе работы постоянно появляются подводные камни: то одно не выгружается, то другое, порой, кажется, все данные передаются, но документы или элементы справочников не заполняются. А перерабатывать типовой механизм зачастую бывает себе дороже. Причем бывают и ситуации, когда нужно вносить изменения и в 1С, и на сайте. Стоимость таких работ возрастает и встает вопрос о том, нужно ли это вообще. Сейчас я расскажу о том, как мы подключали HostCMS, а в конце статьи приведу результаты обмена.

Настроить ограничение основной скорости

Ограничение скорости использует две основные инструкцииИ настроитьКак показано в этом примере:

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

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

• ключОпределите характеристики запроса, чтобы применить ограничение. В примере это переменная NGINX, Эта переменная содержит двоичное представление IP-адреса клиента. Это означает, что мы ограничиваем каждый уникальный IP-адрес частотой запросов, определенной третьим параметром. (Мы используем эту переменную, потому что она занимает меньше места, чем строковое представление IP-адреса клиента）。

• площадь-Определить область разделяемой памяти, используемой для хранения статуса каждого IP-адреса и частоты ограниченных URL-адресов запросов доступа. Хранение информации в общей памяти означает, что информация может быть передана рабочим процессам NGINX. Определение делится на две части:Имя области, определяемое ключевым словом, и размер после двоеточия. Информация о состоянии около 16 000 IP-адресов требует 1 мегабайта, поэтому в нашей области может храниться около 160 000 адресов.

  Если NGINX необходимо добавить новые записи, когда место на диске исчерпано, он удалит самые старые записи. Если свободного места все еще недостаточно для размещения новой записи, NGINX возвращает код состояния. Кроме того, чтобы предотвратить исчерпание памяти, каждый раз, когда NGINX создает новую запись, он удаляет две неиспользуемые записи на срок до 60 секунд.   

• Rate-Установите максимальную частоту запросов. В этом примере скорость не может превышать 10 запросов в секунду. NGINX фактически отслеживает запросы в миллисекундах, поэтому этот предел соответствует 1 запросу каждые 100 миллисекунд. Потому что мы не допускаем очередей (см.), это означает, что если запрос прибудет менее чем через 100 миллисекунд после предыдущего разрешенного запроса, запрос будет отклонен.

Инструкция устанавливает ограничение скорости и параметры области общей памяти, но фактически не ограничивает частоту запросов. Для этого нужно применить ограничения к конкретнымилиКусок, В примере мы будем/авторизоваться/Запрос на ограничение скорости.

Поэтому каждый уникальный IP-адрес может быть только/ login /Запросить 10 запросов, или, точнее, запрос не может быть сделан на URL в течение 100 миллисекунд от предыдущего URL.

Другие способы

Открой файл /etc/sysctl.conf и помести в него следующие строки:

Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Установи правила SELinux для защиты nginx

Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

Ограничь количество соединений с помощью брандмауэра

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.

Настрой PHP

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:

Три, принцип ограничения скорости

Принцип протекающего ведра Идея алгоритма:

Сверху в ведро наливается вода (запрос), а снизу вытекает (обрабатывается); Вода, которая слишком поздно вытечь, сохраняется в ведре (буфере) и вытекает с фиксированной скоростью; Вода переполняется, когда ведро заполнено (выбросить).

Ядро этого алгоритма: кэширование запросов, обработка с постоянной скоростью и прямой отказ от избыточных запросов. По сравнению с алгоритмом дырявого ведра, алгоритм ведра токенов отличается тем, что в нем есть не только «ведро», но и очередь. Этот сегмент используется для хранения маркеров и очереди Используется для хранения запросов.

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

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

Белый список

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

Этот пример также используетс участиеминструкция.Блок назначает IP-адрес в белый список и все другие IP-адресаценить, оценивать. Затем мы используем карту для преобразования этих значений в ключи, например:

• в случаедля，Затем установите пустую строку
• в случаедля，Затем установите IP-адрес клиента в двоичном формате

Положите два вместе,Установите для белого списка IP-адрес пустую строку, в противном случае установите для него IP-адрес клиента. когдаКогда первый параметр (ключ) каталога является пустой строкой, ограничение не применяется, поэтому IP-адреса белого списка (в подсетях 10.0.0.0.0 / 8 и 192.168.0.0/24) не ограничены. Все остальные IP-адреса ограничены 5 запросами в секунду.

Директива применяет ограничения кОпределите местоположение и разрешите пакеты до 10 пакетов, которые превышают настроенный предел, без задержки в пересылке

Содержать несколько инструкций в одном месте

ты можешьСодержит несколько инструкций в одном месте. Будут применены все ограничения, которые соответствуют данному запросу, что означает, что будут использоваться самые ограничительные ограничения. Например, если инструкция накладывает задержку, используется самая длинная задержка. Точно так же, даже если это результат какой-либо инструкции, запрос будет отклонен, даже если другие инструкции позволят им пройти.

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

IP-адрес в белом списке не соответствует первому ограничению скорости (req_zone), но соответствует второму ограничению скорости (req_zone_wl), поэтому ограничение составляет 15 запросов в секунду. IP-адреса, которых нет в белом списке, соответствуют обоим ограничениям скорости, поэтому применимый предел является более строгим: 5 запросов в секунду.

Queueing with No Delay

A configuration with results in a smooth flow of traffic, but is not very practical because it can make your site appear slow. In our example, the 20th packet in the queue waits 2 seconds to be forwarded, at which point a response to it might no longer be useful to the client. To address this situation, add the parameter along with the parameter:

With the parameter, NGINX still allocates slots in the queue according to the parameter and imposes the configured rate limit, but not by spacing out the forwarding of queued requests. Instead, when a request arrives “too soon”, NGINX forwards it immediately as long as there is a slot available for it in the queue. It marks that slot as “taken” and does not free it for use by another request until the appropriate time has passed (in our example, after 100ms).

Suppose, as before, that the 20‑slot queue is empty and 21 requests arrive simultaneously from a given IP address. NGINX forwards all 21 requests immediately and marks the 20 slots in the queue as taken, then frees 1 slot every 100ms. (If there were 25 requests instead, NGINX would immediately forward 21 of them, mark 20 slots as taken, and reject 4 requests with status .)

Now suppose that 101ms after the first set of requests was forwarded another 20 requests arrive simultaneously. Only 1 slot in the queue has been freed, so NGINX forwards 1 request and rejects the other 19 with status . If instead 501ms have passed before the 20 new requests arrive, 5 slots are free so NGINX forwards 5 requests immediately and rejects 15.

The effect is equivalent to a rate limit of 10 requests per second. The option is useful if you want to impose a rate limit without constraining the allowed spacing between requests.

Note: For most deployments, we recommend including the and parameters to the directive.

Описание проблемы

Для каждого из видов подключения нужна своя аутентификация и отдельный набор ролей доступа. При одной публикации доступ пересекается, стандартные «грабли»: при подключении телефонии тонкий клиент на автомате подключается под сервисным пользователем телефонии.

Разнесение на отдельные публикации 

Решает проблему пересечения, но не решает вопрос контроля доступа. При публикации HTTP сервисов расширений публикуются все, потенциально под одним пользователем могут подключится к другому сервису.

Так же остается проблема если нужна Basic аутентификация на уровне кода сервиса.

В заключение

Мы представили множество функций ограничения скорости, предоставляемых NGINX и NGINX Plus, включая настройку частоты запросов для разных мест HTTP-запросов и настройку других функций для ограничения скорости, таких какс участиемпараметр. Мы также представили расширенную настройку, которая подходит для установки различных ограничений на IP-адреса клиентов из белого и черного списков, и объяснили, как регистрировать отклоненные и отложенные запросы.

Попробуйте лимит скорости в NGINX Plus для себя — начните прямо сейчас30-дневная бесплатная пробная версия,илиСвязаться с намиОбсудить ваш вариант использования.