Как защитить Nginx и CMS от скриптов и DDoS: ограничение запросов и соединений по IP

Введение

При работе с динамическими приложениями (например, XenForo, другие PHP-фреймворки или WebSocket-сервисы) защита от агрессивных клиентов и ботов крайне важна.

В этой статье мы рассмотрим, как в nginx реализовать:

Ограничение количества запросов (rate limiting) на уровне одного IP для динамических HTTP-запросов.
Защиту WebSocket-коннектов (чтобы лимиты применялись к handshake-запросам и потенциально к «тяжёлому» обмену данными).
Интеграцию с iptables и fail2ban для жёсткого блокирования IP-адресов, которые постоянно превышают пороги.

Мы будем исходить из того, что nginx настроен как обратный прокси (front-end), а за динамику отвечает отдельный upstream (Apache+PHP-FPM или любой другой backend).

Также предположим, что перед nginx стоит DDoS-Guard (или другой прокси-провайдер), и нам важно видеть реальные IP клиентов.

1. Обзор ключевых механизмов

limit_req_zone / limit_req
- Позволяют ограничить число запросов в секунду (или минуту) с одного IP, используя алгоритм «token bucket».
- Подходят для HTTP-запросов (GET/POST/AJAX).
limit_conn_zone / limit_conn
- Ограничивают количество одновременных соединений с одного IP.
- Полезны там, где важно не допустить «потоку открытых TCP-коннектов» (например, WebSocket, долгоживущие чаты).
real_ip_header / set_real_ip_from / real_ip_recursive
- Обеспечивают nginx «видеть» реальный IP клиента, а не адрес прокси-провайдера.
- Обязательно нужно настроить, если перед nginx стоят CloudFlare, DDoS-Guard или другие reverse-proxy.
iptables (hashlimit / connlimit)
- Жёсткая фильтрация на уровне ядра — не позволяет превысить заданный порог открытий новых TCP-соединений или пакетов UDP/TCP.
- Срабатывает раньше, чем nginx получит запрос, поэтому «экономит» ресурсы web-стека.
fail2ban
- Мониторит логи nginx (или iptables), и при слишком частых 429/503/других ошибках бана ставит «длительный» бан на IP.
- Закрывает «хвостовые» агрессивные IP-адреса.

2. Подготовка nginx к учёту реальных IP

Если вы используете DDoS-Guard или другую CDN/прокси, то без явной настройки real_ip nginx будет видеть адрес прокси вместо клиента.

Как настроить:

Код:

# В самом начале nginx.conf (http { ... }) или в include-файле:
# Задаём диапазоны IP-адресов вашего провайдера (например, DDoS-Guard):
# Эти адреса могут отличаться — уточните актуальный диапазон у DDoS-Guard.
set_real_ip_from  185.178.209.0/24;   # пример IPv4-диапазона DDoS-Guard
set_real_ip_from  2a06:1100::/32;     # пример IPv6-диапазона DDoS-Guard

# Говорим nginx: «логируй реальный IP из заголовка X-Forwarded-For»
real_ip_header    X-Forwarded-For;
real_ip_recursive on;

set_real_ip_from — CDN/прокси заносим в «белый список»: оттуда будем брать реальный IP.
real_ip_header X-Forwarded-For — в этом заголовке прокси передаёт исходный IP.
real_ip_recursive on — если цепочка из нескольких прокси, берём самый левый (первый) IP, а не последний.

После этого в $remote_addr nginx будет видеть именно IP конечного клиента. И все лимиты, которые мы настроим ниже, автоматически относятся к реальным IP.

3. Ограничение скорости запросов (rate limiting)

3.1. Определяем зоны (limit_req_zone)

В блоке http { ... } заводим две зоны:

Для динамических HTTP-запросов (XenForo, API, AJAX).
Для WebSocket-хендшейка (ограничение на количество initial-запросов /ws).

Код:

http {
    ##
    # … прочие директивы (include mime.types, gzip, sendfile и т.д.) …
    ##

    # 1) Зона для динамики: 10 запросов в секунду с одного IP, burst 20
    #    (rate 10r/s означает: регулярное пополнение 10 токенов/сек. burst = 20 позволяет пик до 30 req за краткий момент)
    limit_req_zone $binary_remote_addr zone=dynamic_zone:10m rate=10r/s;

    # 2) Зона для WebSocket-handshake (например, все запросы на /ws)
    #    Тут можно задать чуть больше или меньше — зависит от характера WS-потока
    limit_req_zone $binary_remote_addr zone=ws_zone:10m rate=5r/s;

    ##
    # … далее ваши другие настройки …
    ##
}

Почему две зоны?
- Динамические страницы (XenForo-PHP) и handshake WebSocket по факту — разные «категории» трафика.
- Можно задать разные пороги: динамика (пик AJAX-запросов) ≈ 10 r/s, а WS-хендшейк (он возникает редко, только при установлении соединения) ≈ 5 r/s.
10m и 10m — объём памяти, выделяемый на "таблицу состояния" для каждой зоны (примерно 160 000 уникальных IP).

3.2. Применяем лимиты в server / location

В конфигурации вашего виртуального хоста (обычно /etc/nginx/sites-enabled/your-site.conf) добавляем:

Код:

server {
    listen 80;
    server_name example.com www.example.com;

    # 1. Для хостинга статических и кешированных страниц (не лимитируем):
    location ~* \.(jpg|jpeg|png|gif|css|js|ico|svg)$ {
        expires 30d;
        access_log off;
        add_header Cache-Control "public";
        try_files $uri @dynamic;
    }

    # 2. Обработчик WebSocket (например, URL /ws)
    location /ws {
        # Сразу же накладываем лимит на handshake:
        limit_req zone=ws_zone burst=10 nodelay; 
        # -- burst=10: можно допустить всплеск до 10 запросов сверх 5r/s
        # -- nodelay: лишние сразу обрежем, не станем ставить в очередь

        # Дальнейшая стандартная прокси-конфигурация для WS:
        proxy_pass http://backend_ws;     # ваш upstream для WS
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 3. Основной location, где живёт XenForo (или другое PHP-приложение)
    location / {
        # Лимитируем все обычные (HTTP) запросы
        limit_req zone=dynamic_zone burst=20 nodelay;
        # -- burst=20: допускаем «всплеск» до 30 req, при этом rate=10r/s постоянно пополняет токены

        # Проксируем всё к Apache (или PHP-FPM) на бэкенд
        proxy_pass http://backend_php;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 4. Ошибка, когда лимит превышен (код 429) — можно настроить кастомную страницу
    error_page 429 = /custom_429.html;
    location = /custom_429.html {
        internal;
        default_type text/html;
        return 200 '<h1>429 Too Many Requests</h1><p>Пожалуйста, подождите немного прежде чем отправлять новый запрос.</p>';
    }

    ##
    # … остальная конфигурация (static, SSL, редиректы) …
    ##
}

limit_req zone=dynamic_zone burst=20 nodelay;
- burst=20 — позволяет «накидать» дополнительный буфер в 20 токенов. При rate=10r/s за одну секунду добавляется 10 токенов, плюс из burst можно взять ещё 20. Итого за 1 секунду максимум 30 запросов, после чего дальнейшие запросы моментально блокируются.
- nodelay означает: не ждём, а сразу отклоняем лишние. Если убрать nodelay, nginx будет «ставить в очередь» до тех пор, пока корзина не пополнится.
limit_req zone=ws_zone burst=10 nodelay;
- Handshake WebSocket — единичный/редкий HTTP-запрос (GET /ws с хэдером Upgrade). Поэтому даже 5r/s может быть вполне достаточно. Если вы ожидаете, что пользователи часто релоадят страницу и переподключаются, можно чуть увеличить burst (до 10).

4. Ограничение одновременных соединений (limit_conn)

Кроме скорости (requests/sec), часто нужно ограничивать количество одновременных TCP-коннектов с одного IP. Это полезно, чтобы один и тот же IP не держал открытыми сотни WS-сессий или HTTP keep-alive-потоков.

4.1. Настраиваем зоны для limit_conn

В блоке http { ... } рядом с limit_req_zone добавьте:

Код:

http {
    ##
    # … ранее созданные limit_req_zone …
    ##

    # Зона для одновременных HTTP-соединений (keep-alive + новые запросы)
    limit_conn_zone $binary_remote_addr zone=conn_zone:10m;

    # Зона для одновременных WebSocket-коннектов (каждое upgrade-соединение считаем отдельно)
    # Будем отличать WS по ключу (к примеру, по $binary_remote_addr:$server_port)
    limit_conn_zone $binary_remote_addr zone=conn_ws_zone:10m;

    ##
    # … остальная конфигурация …
    ##
}

zone=conn_zone:10m — зона для счётчика одновременных HTTP/TCP коннектов (сложим все TCP-сессии, в которых клиент «просто ждёт» keep-alive или шлёт новые запросы).
zone=conn_ws_zone:10m — отдельная зона, чтобы понимать, сколько именно открытых WS-коннектов у данного IP.

4.2. Применяем limit_conn в нужных местах

Код:

server {
    listen 80;
    server_name example.com;

    # 1. Ограничиваем одновременные HTTP-соединения (keep-alive + запросы)
    #    Например, не более 20 одновременных коннектов от одного IP
    #    (здесь и далее $binary_remote_addr — это IP клиента из real_ip)
    location / {
        limit_conn conn_zone 20;
        limit_req zone=dynamic_zone burst=20 nodelay;

        proxy_pass http://backend_php;
        proxy_set_header X-Real-IP $remote_addr;
        # … другие заголовки …
    }

    # 2. Ограничиваем WebSocket-коннекты (upgrade-сессии)
    location /ws {
        limit_conn conn_ws_zone 5;
        limit_req zone=ws_zone burst=10 nodelay;

        proxy_pass http://backend_ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 3. Статика (не ограничиваем или минимально ограничиваем)
    location ~* \.(css|js|jpg|png|gif|ico|svg)$ {
        # Если хотите жестко, можно limit_conn conn_zone 50;
        expires 30d;
        access_log off;
    }

    # 4. Стандартные error_page, логирование и прочие настройки
    …
}

limit_conn conn_zone 20; — означает: не более 20 одновременных TCP-сессий (HTTP-соединений) с одного IP.
- Keep-alive-сессия считается «занятой», даже если клиент просто ждёт.
- Плюс каждый новый запрос (если Connection: keep-alive) тоже увеличит счётчик, но после ответа соединение либо закроется, либо ждёт idle-таймаут (keepalive).
limit_conn conn_ws_zone 5; — не более 5 одновременно открытых WebSocket-коннектов (т. е. подключённых /ws-сессий) с одного IP.

Важно: limit_conn считает количество одномоментно открытых соединений:

HTTP с keep-alive.

WebSocket (после успешного upgrade).

5. Автоматическая блокировка чрезмерных нарушителей (fail2ban)

Даже при наличии rate- и conn-лимитов иногда полезно выбрасывать «долгоиграющие» агрессивные IP из списка навсегда (или на длительное время). Для этого настраиваем fail2ban, чтобы он читал логи nginx и реагировал на избыток 429/503.

5.1. Настройка логирования в nginx

В файле nginx.conf (или в virtual host) убедитесь, что у вас есть отдельный лог ошибок для лимитов:

Код:

http {
    # …
    server {
        # …
        # Логируем лимитированные запросы в отдельный файл
        limit_req_status 429;
        error_log /var/log/nginx/limit_errors.log notice;

        # Можно также выводить в access_log подробности (если нужно):
        # лог-формат, где при 429 выводится «LIMIT»
    }
}

limit_req_status 429 — заставляем nginx возвращать код 429 (по умолчанию 503) при лимите;
error_log /var/log/nginx/limit_errors.log notice — логируем notice-сообщения (включая «limiter»).

5.2. Конфиг fail2ban (пример для Ubuntu/Debian)

Создаём фильтр /etc/fail2ban/filter.d/nginx-limit.conf:

Код:

[Definition]
# Ищем в логе nginx: «limiter» или «limiting»
failregex = limiting requests, excess:.* by zone "dynamic_zone"
            limiting requests, excess:.* by zone "ws_zone"
            \[notice\] .*limiter: *limiting
ignoreregex =

Создаём джейл /etc/fail2ban/jail.d/nginx-limit.conf:

Код:

[nginx-limit]
enabled  = true
filter   = nginx-limit
action   = iptables[name=nginx-limit, port=http, protocol=tcp]
logpath  = /var/log/nginx/limit_errors.log
bantime  = 3600         ; блокировать на 1 час
findtime = 600          ; смотрим за последние 10 минут
maxretry = 20           ; если 20 раз в течение 10 минут попал в limit → бан

Перезапускаем fail2ban:
Код:
```
sudo systemctl restart fail2ban
```

Теперь, если один IP будет часто выпадать в лимит (429), fail2ban отловит его по регулярке и добавит правило iptables с «жестким» баном на 1 час (или любое другое время, согласно bantime). Это позволит гарантированно исключить самых настойчивых штурмовиков, которые упорно «пробивают» лимит.

6. Конфигурация nginx + upstream для XenForo (пример «из коробки»)

Предположим, у нас есть два upstream-блока:

Код:

upstream backend_php {
    server 127.0.0.1:8080;   # Apache (mpm_event + php-fpm)
}

upstream backend_ws {
    server 127.0.0.1:8090;   # Отдельный сокет-сервер (Node.js / Ratchet / любой WS-бекенд)
}

Полная конфигурация server {} может выглядеть так:

Код:

server {
    listen 80;
    server_name forum.example.com;

    # 1. Настройка real_ip для прокси (уже описана ранее)
    set_real_ip_from  185.178.209.0/24;
    real_ip_header    X-Forwarded-For;
    real_ip_recursive on;

    # 2. Общие limit-зоны (http {} уже прописал их утром)

    # 3. Сервис статики: CSS/JS/картинки/файлы XenForo
    location ~* \.(?:css|js|gif|jpe?g|png|svg|woff2?|ttf)$ {
        # Поскольку это статика, не накладываем limit_req (лишь минимальный limit_conn, если нужно)
        limit_conn conn_zone 50;    # макс. 50 одновременных keep-alive-коннектов с одного IP
        access_log off;
        expires 7d;

        # Читаем из папки XenForo: /var/www/forum/
        root /var/www/forum/;
        try_files $uri $uri/ =404;
    }

    # 4. WebSocket (например, чат или real-time уведомления)
    location /socket {
        # Ограничиваем handshake
        limit_conn conn_ws_zone 5;
        limit_req zone=ws_zone burst=10 nodelay;

        proxy_pass http://backend_ws;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 5. Основные запросы к XenForo (динамические страницы / AJAX / формы)
    location / {
        # Ограничиваем скорость: 10 запросов в секунду, всплеск до 20
        limit_req zone=dynamic_zone burst=20 nodelay;
        # Ограничиваем максимально 20 одновременных HTTP-сессий
        limit_conn conn_zone 20;

        # Проксируем на Apache
        proxy_pass http://backend_php;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Если backend возвращает 502/504 или ему долго отвечать, можно вернуть кастомный 503
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }

    # 6. Обработка ошибок 429 (угроза превышения лимита)
    error_page 429 = /429.html;
    location = /429.html {
        internal;
        default_type text/html;
        return 200 '<h1>Слишком много запросов</h1><p>Пожалуйста, делайте перерыв между действиями.</p>';
    }

    # 7. Логи
    access_log /var/log/nginx/forum.access.log main;
    error_log  /var/log/nginx/forum.error.log warn;
    # Лог лимитов
    limit_req_status 429;
    error_log /var/log/nginx/forum_limit.log notice;
}

Статика отдаётся прямо nginx без PHP, только с limit_conn conn_zone 50. Это не мешает CDN-кешированию и даёт форуму «надышаться», когда боты ломанулись за картинками.
WebSocket обрабатывается отдельно, ведь у него свои особенности proxy_http_version 1.1 и хедеры Upgrade/Connection.
Динамика (все остальные URL) йдут на Apache, но перед этим проходят через limit_req zone=dynamic_zone и limit_conn conn_zone.
Также не забудьте настроить fail2ban, для блокировки IP.

9. Рекомендации по настройке и отладке

Точная настройка порогов
- Для XenForo-форумов часто достаточно 5–10r/s и burst=10–20, а не «потолок в 50r/s».
- Чем больше у сайта «тяжёлых» плагины или сложные SQL-запросы, тем выше нужно ставить пороги.
Мониторинг и тестирование
- Используйте утилиты нагрузочного тестирования (ab, wrk, siege) с разными профилями, чтобы увидеть, при каких значениях порогов ваш сервер ещё комфортно справляется с динамикой.
- Проверяйте, как ведёт себя форум при «полусимуляции» реального трафика: исполняйте ряд AJAX-вызовов, регистраций, постов и тд.
Логирование
- Обязательно ведите отдельный лог лимитов (forum_limit.log), чтобы потом проанализировать, какие IP наиболее агрессивны.
- В access_log добавьте формат, где показываются хедеры X-Forwarded-For и $status, чтобы видеть, кто и сколько раз получил 429.
Keep-Alive-таймауты
- В nginx:
- Код:
```
keepalive_timeout 20s;
keepalive_requests 100;
```
В Apache (если он «самостоятельно» обслуживает статику или есть прямой доступ):
Код:
```
KeepAliveTimeout 5
MaxKeepAliveRequests 100
```
- Короткий таймаут (10–20 секунд) позволит «ускорить» освобождение HTTP-коннектов и уменьшить нагрузку «спящих» TCP-сессий.

Кэширование динамических страниц
- Для XenForo обязательно включите Full Page Cache (FPC) или сторонний nginx FastCGI cache, чтобы тяжёлые динамические запросы (например, просмотр тем) отдавались как статические HTML, минуя PHP. Тогда реальная «нагрузка PHP» снизится в 5–10 раз, и вы сможете увеличить пороги rate без страха.
Регулярно проверяйте
- Пересматривайте limit_req_zone и connlimit каждые несколько недель, особенно после апгрейда форума, изменения поведения аудитории или роста посетителей.

10. Заключение

Защита динамических соединений на nginx строится на комбинации:

Видимости реального IP (через real_ip), чтобы лимиты применялись именно к конечному клиенту, а не к адресу прокси.
Гибкого rate limiting (limit_req) для HTTP-запросов (XenForo, AJAX) и handshake WebSocket.
Ограничения одновременных соединений (limit_conn) для предотвращения держания «тысячи» TCP-коннектов от одного IP.
fail2ban-автоматизации, чтобы навсегда «выбрасывать» особо настойчивые IP, которые неоднократно попадали в 429.

Следуя этой схеме, вы получите надёжную защиту как от одиночных скриптов-штурмовиков, так и от полураспределённых атак. Правильно настроенные ограничения позволят не препятствовать реальным пользователям вашего XenForo при обычной работе, но моментально отсекать тех, кто пытается «засыпать» сервер сотнями запросов или держать открытыми тысячи WebSocket-коннектов.

Если у вас IspManager 6, то можно вместо этого всего просто включить "Защита от DDOS" в настройках домена, вот описание:

Чтобы увидеть нужно авторизоваться или зарегистрироваться.

Удачи в настройках.

Если вы используете DDoS-Guard в качестве CDN/прокси, то iptables видит лишь IP-адреса DDoS-Guard, а не IP-адреса реальных клиентов.

Для надёжной блокировки «проблемных» адресов, которые получили ошибку "too many connection" можно сочетать nginx-конфигурацию с Fail2Ban.

В этом подходе:

nginx принимает реальные IP из заголовка X-Forwarded-For, а выдача 429 фиксируется специальным логом;
Fail2Ban читает этот лог, извлекает реальные IP и дописывает их в include-файл nginx (deny <IP>);
nginx при перезагрузке сразу начинает блокировать эти IP до истечения срока бана.

По шагам:

1) Настройка nginx для реальных IP и логирования лимитов:

Код:

http {
    # 1. Разрешаем nginx брать оригинальный IP из X-Forwarded-For
    set_real_ip_from  185.178.209.0/24;   # диапазон DDoS-Guard
    real_ip_header    X-Forwarded-For;
    real_ip_recursive on;

    # 2. Зона rate-limit (пример)
    limit_req_zone $binary_remote_addr zone=dynamic:10m rate=15r/s;
    limit_req_status 429;
    error_log /var/log/nginx/forum_limit.log notice;  # логлим 429 в отдельный файл

    server {
        # … ваши остальные настройки …

        # 3. Include-файл для ручных «deny»
        include /etc/nginx/blocked_ips.conf;

        location / {
            limit_req zone=dynamic burst=20 nodelay;
            # … proxy_pass или FastCGI …
        }

        error_page 429 = /429.html;
        location = /429.html {
            internal;
            return 200 "<h1>429 Too Many Requests</h1>";
        }
    }
}

set_real_ip_from + real_ip_header позволяют nginx видеть IP реального клиента, а не DDoS-Guard.
limit_req_status 429 и error_log … notice фиксируют все превышения в /var/log/nginx/forum_limit.log.
include /etc/nginx/blocked_ips.conf вставляет в начало каждого server {} все deny-правила, добавленные Fail2Ban.

Создайте файл /etc/nginx/blocked_ips.conf и установить туда права на запись, сюда будут добавляться и удаляться IP-адреса для блокировки.

2. Конфиг фильтра Fail2Ban

Создаём файл /etc/fail2ban/filter.d/nginx-ddosguard.conf:

Код:

[Definition]
# ловим любые повторяющиеся 429 в логе лимитов
failregex = ^\s*\S+\s+\S+\s+\[notice\].*limiter: limiting requests.*client: <HOST>
ignoreregex =

3. Action для блокировки в nginx

Создаём /etc/fail2ban/action.d/nginx-echo-block.conf:

Код:

[Definition]
actionstart =
actionstop  =
actioncheck =

# при бане — добавляем в файл и reload nginx
actionban   = echo "deny <ip>;" >> /etc/nginx/blocked_ips.conf && nginx -s reload
# при разбане — удаляем строку и reload nginx
actionunban = sed -i "/^deny <ip>;/d" /etc/nginx/blocked_ips.conf && nginx -s reload

У всех конфигов должны-быть права на запись.

4. Jail-конфигурация

В /etc/fail2ban/jail.local добавляем:

Код:

[nginx-ddosguard]
enabled  = true
filter   = nginx-ddosguard
action   = nginx-echo-block
logpath  = /var/log/nginx/forum_limit.log
findtime =  600
maxretry =   5
bantime  = 3600

maxretry = 5 — при 5 превышениях 429 в 10 минут IP попадёт в бан на час.
Бан реализуется через добавление deny <IP>; в /etc/nginx/blocked_ips.conf и мгновенный nginx -s reload.

5. Итоговая схема работы

Клиент (реальный IP) превышает rate-limit → nginx отдаёт 429 и пишет запись в forum_limit.log.
Fail2Ban «подхватывает» эти записи, извлекает IP и через action добавляет (deny <IP>); в blocked_ips.conf, перезагружая nginx.
Всё дальнейшее соединение от этого IP сразу блокируется на уровне nginx (до PHP).
Через bantime Fail2Ban удаляет строчку из blocked_ips.conf и снова reload nginx, снимая бан.

Такой подход позволяет корректно блокировать реальных «плохих» клиентов за DDoS-Guard, не полагаясь на iptables и гарантированно работая на уровне HTTP/7-го слоя.

Как проверить защиту:

1. Перезапустите сервисы fail2ban, nginx, apache2.

2. Смотрим статус джейла:

Код:

sudo fail2ban-client status ddos-guard

Вы должны увидеть примерно так:

Код:

Status for the jail: ddos-guard
|- Filter
|  |- Currently failed: 0
|  `- Total failed:    0
`- Actions
   |- Currently banned: 0
   `- Banned IP list:

Тестируем

1.С помощью curl можно вручную создать превышение лимита:

Код:

seq 200 | xargs -n1 -P500 -I{} curl -s -o /dev/null -w "%{http_code}\n" https://ваш-домен.ru/

Если вы видите несколько 429, значит limit_req уже срабатывает.

Проверьте, что в логе forum_limit.log появились записи:

Код:

tail -n 20 /var/log/nginx/forum_limit.log

Проверка, что Fail2Ban видит срабатывания

Выполните команду:

Код:

sudo fail2ban-client status nginx-ddosguard

Должно показать:

Currently failed: > 0 — есть срабатывания
Total banned: > 0 — кого-то уже забанили
Banned IP list: — список IP, попавших под блок

Проверка, что IP добавлен в Nginx-бан (blocked_ips.conf)

Проверьте, появился ли IP в /etc/nginx/blocked_ips.conf:

Код:

cat /etc/nginx/blocked_ips.conf

Должно быть что-то вроде:

deny 1.2.3.4;
deny 5.6.7.8;

Если IP в списке — значит бан отработал.

Проверка, что nginx реально блокирует IP

С сервера или другого хоста выполните:

Код:

curl -H "X-Forwarded-For: 1.2.3.4" https://ваш-домен.ru/ -I

Где 1.2.3.4 — IP из deny.

Ожидаемый ответ:

HTTP/1.1 403 Forbidden

Если вы видите 403 — nginx отработал deny.

Проверка лога Fail2Ban

Убедитесь, что fail2ban сработал и добавил IP:

Код:

sudo journalctl -u fail2ban -n 50

Вы увидите строки типа:
Ban <ip> on nginx-ddosguard

Если что-то не работает

Убедитесь, что nginx reload происходит без ошибок:

Код:

sudo nginx -t && sudo nginx -s reload

Убедитесь, что в blocked_ips.conf нет синтаксических ошибок (deny <ip>; строго с точкой с запятой!).

Запустите ручную проверку фильтра:

Код:

sudo fail2ban-regex /var/log/nginx/forum_limit.log /etc/fail2ban/filter.d/nginx-ddosguard.conf

Подсказка: автоматическое удаление старых IP

Fail2Ban автоматически удалит IP через bantime.
Если нужно проверить, снялся ли бан, снова выполните:

Код:

sudo fail2ban-client status nginx-ddosguard

Или убедитесь, что IP удалился из blocked_ips.conf:

Код:

grep <ip> /etc/nginx/blocked_ips.conf

Эти шаги помогут вам убедиться, что ваша защита работает корректно, и nginx действительно блокирует IP-адреса.
Удачи.)

Последнее редактирование: Сегодня в 10:38

📡 Наши контакты

Как защитить Nginx и CMS от скриптов и DDoS: ограничение запросов и соединений по IP

1. Обзор ключевых механизмов

2. Подготовка nginx к учёту реальных IP

3. Ограничение скорости запросов (rate limiting)

3.1. Определяем зоны (limit_req_zone)

3.2. Применяем лимиты в server / location

4. Ограничение одновременных соединений (limit_conn)

4.1. Настраиваем зоны для limit_conn

5. Автоматическая блокировка чрезмерных нарушителей (fail2ban)

5.1. Настройка логирования в nginx

5.2. Конфиг fail2ban (пример для Ubuntu/Debian)

6. Конфигурация nginx + upstream для XenForo (пример «из коробки»)

9. Рекомендации по настройке и отладке

10. Заключение

Комментарии

bbbcode

2. Конфиг фильтра Fail2Ban

3. Action для блокировки в nginx

4. Jail-конфигурация

5. Итоговая схема работы

Тестируем

Проверка, что Fail2Ban видит срабатывания

Проверка, что IP добавлен в Nginx-бан (blocked_ips.conf)

Проверка, что nginx реально блокирует IP

Проверка лога Fail2Ban

Если что-то не работает

Подсказка: автоматическое удаление старых IP

Информация о статье

Больше в Изучение сети

Больше от 0x42

Поделиться этой статьей

📡 Наши контакты

Как защитить Nginx и CMS от скриптов и DDoS: ограничение запросов и соединений по IP

1. Обзор ключевых механизмов​

2. Подготовка nginx к учёту реальных IP​

3. Ограничение скорости запросов (rate limiting)​

3.1. Определяем зоны (limit_req_zone)​

3.2. Применяем лимиты в server / location​

4. Ограничение одновременных соединений (limit_conn)​

4.1. Настраиваем зоны для limit_conn​

​

5. Автоматическая блокировка чрезмерных нарушителей (fail2ban)​

5.1. Настройка логирования в nginx​

5.2. Конфиг fail2ban (пример для Ubuntu/Debian)​

6. Конфигурация nginx + upstream для XenForo (пример «из коробки»)​

9. Рекомендации по настройке и отладке​

10. Заключение​

Комментарии

2. Конфиг фильтра Fail2Ban​

3. Action для блокировки в nginx​

4. Jail-конфигурация​

5. Итоговая схема работы​

Тестируем​

Проверка, что Fail2Ban видит срабатывания​

Проверка, что IP добавлен в Nginx-бан (blocked_ips.conf)​

Проверка, что nginx реально блокирует IP​

Проверка лога Fail2Ban​

Если что-то не работает​

Подсказка: автоматическое удаление старых IP​

Информация о статье

Больше в Изучение сети

Больше от 0x42

Поделиться этой статьей

1. Обзор ключевых механизмов

2. Подготовка nginx к учёту реальных IP

3. Ограничение скорости запросов (rate limiting)

3.1. Определяем зоны (limit_req_zone)

3.2. Применяем лимиты в server / location

4. Ограничение одновременных соединений (limit_conn)

4.1. Настраиваем зоны для limit_conn

5. Автоматическая блокировка чрезмерных нарушителей (fail2ban)

5.1. Настройка логирования в nginx

5.2. Конфиг fail2ban (пример для Ubuntu/Debian)

6. Конфигурация nginx + upstream для XenForo (пример «из коробки»)

9. Рекомендации по настройке и отладке

10. Заключение

2. Конфиг фильтра Fail2Ban

3. Action для блокировки в nginx

4. Jail-конфигурация

5. Итоговая схема работы

Тестируем

Проверка, что Fail2Ban видит срабатывания

Проверка, что IP добавлен в Nginx-бан (blocked_ips.conf)

Проверка, что nginx реально блокирует IP

Проверка лога Fail2Ban

Если что-то не работает

Подсказка: автоматическое удаление старых IP