BunkerWeb даёт защиту из коробки ценой прозрачности конфига nginx

MAATRIX

Защитить публичный веб-сервер голым nginx честно — это неделя работы: собрать ModSecurity с CRS, написать fail2ban-фильтры под конкретные атаки, настроить rate limiting, руками продумать security-заголовки. BunkerWeb обещает всё это за один docker-compose и набор переключателей. Разберём без маркетинга, что вы реально получаете из коробки и что теряете, когда конфиг nginx перестаёт быть тем файлом, который вы правите руками и понимаете построчно.

Что за инструмент BunkerWeb и чем он отличается от голого nginx

BunkerWeb — не замена nginx, а обёртка вокруг него. Под капотом всё тот же nginx-воркер, который принимает соединения, терминирует TLS и проксирует запросы в бэкенд. Разница — в том, как вы этим конфигом управляете. В голом nginx вы пишете server {} и location {} блоки сами, руками добавляете директивы proxy_pass, ssl_certificate, limit_req_zone. В BunkerWeb вы выставляете переменные окружения или галочки в веб-панели (AUTO_LETS_ENCRYPT=yes, USE_MODSECURITY=yes, USE_ANTIBOT=captcha), а сам nginx.conf генерирует планировщик BunkerWeb — процесс, который следит за настройками и перегенерирует конфигурацию при изменениях.

Второе отличие — набор функций из коробки. Голый nginx — это надёжный, но нейтральный движок: сам по себе он не знает, что такое WAF, не отличает бота от браузера, не продлевает сертификаты. Всё это — отдельные задачи, которые вы решаете сторонними инструментами или собственными правилами. BunkerWeb встраивает такие вещи как модули-переключатели: ModSecurity с набором правил OWASP CRS, автоматический выпуск и продление Let's Encrypt, антибот-челленджи (JS-проверка, капча, cookie-проверка), геоблокировку по странам, DNSBL-проверку IP и лимиты запросов — без того, чтобы вы писали конфиг ModSecurity или собирали список плохих User-Agent самостоятельно.

Производительность и базовое поведение nginx как HTTP-сервера при этом не меняется — вы получаете тот же движок. Меняется слой управления: вместо прямого текста конфига — декларативные настройки, за которыми сам текст скрыт.

Что вы строите руками на голом nginx

Чтобы честно оценить выигрыш BunkerWeb, полезно вспомнить, из чего складывается «защита из коробки», когда вы делаете её сами. Возьмём типовой продакшен-сценарий: сайт за nginx как реверс-прокси, публичный домен, обычный набор угроз (боты, брутфорс форм, SQLi/XSS-попытки).

Автопродление сертификата через certbot — отдельный шаг после установки nginx:

apt install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
systemctl status certbot.timer

Это надёжно, но требует, чтобы certbot умел править именно ваш конфиг (при нестандартной структуре server блоков иногда приходится выпускать сертификат отдельно и подключать вручную). Разницу между certbot и альтернативными ACME-клиентами разбирали в статье про certbot и acme.sh — там же нюансы wildcard-сертификатов, которых у BunkerWeb из коробки тоже нет без DNS-плагина.

WAF на голом nginx — это не одна директива, а отдельная сборка. Штатный nginx не умеет разбирать тело запроса на предмет SQL-инъекций или XSS-паттернов — для этого нужен модуль ModSecurity, собранный как динамический модуль (--add-dynamic-module) или через nginx с уже вкомпилированным ngx_http_modsecurity_module, плюс отдельно скачанный и подключённый набор правил OWASP CRS:

load_module modules/ngx_http_modsecurity_module.so;

server {
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
    ...
}

Дальше — обновление CRS вручную при выходе новых версий правил, тюнинг ложных срабатываний под конкретное приложение, и всё это без встроенного UI — только конфиг-файлы и логи.

Защита от брутфорса и ботов — это fail2ban с собственными фильтрами под access-лог nginx: отдельный regex под брутфорс формы логина, отдельный под сканирование путей, отдельный под злоупотребление конкретным эндпоинтом. Подробный разбор с готовыми регулярками и порогами — в статье про настройку fail2ban для nginx. Антибот-челленджи (JS-проверка перед выдачей контента, капча для подозрительных клиентов) fail2ban не даёт вообще — это либо сторонний сервис (Cloudflare и подобные), либо самописный код на уровне приложения.

Rate limiting в голом nginx есть из коробки, но настраивается вручную под каждый эндпоинт:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
}

Итого на голом nginx защищённый продакшен — это nginx + certbot + модуль ModSecurity + правила CRS + fail2ban с собственными фильтрами + ручные security-заголовки (add_header Strict-Transport-Security, X-Content-Type-Options и так далее) — пять-шесть разных инструментов, которые вы собираете, обновляете и держите в голове по отдельности.

Что даёт BunkerWeb за один docker-compose

BunkerWeb ставит рядом эти же по сути возможности, но как переключатели одного инструмента. Базовая установка через Docker Compose выглядит примерно так (структура и имена сервисов между релизами BunkerWeb меняются, поэтому перед боевым разворачиванием сверяйтесь с актуальным quickstart в официальной документации проекта):

services:
  bunkerweb:
    image: bunkerity/bunkerweb:1.6
    ports:
      - "80:8080/tcp"
      - "443:8443/tcp"
    environment:
      - API_WHITELIST_IP=127.0.0.0/8 10.20.30.0/24
    networks:
      - bw-universe
      - bw-services
    restart: unless-stopped

  bw-scheduler:
    image: bunkerity/bunkerweb-scheduler:1.6
    depends_on:
      - bunkerweb
    environment:
      - BUNKERWEB_INSTANCES=bunkerweb
      - SERVER_NAME=example.com
      - MULTISITE=yes
      - API_WHITELIST_IP=127.0.0.0/8 10.20.30.0/24
      - AUTO_LETS_ENCRYPT=yes
      - EMAIL_LETS_ENCRYPT=admin@example.com
      - USE_MODSECURITY=yes
      - USE_MODSECURITY_CRS=yes
      - USE_ANTIBOT=captcha
      - USE_LIMIT_REQ=yes
      - example.com_USE_REVERSE_PROXY=yes
      - example.com_REVERSE_PROXY_HOST=http://myapp:8080
      - example.com_REVERSE_PROXY_URL=/
    volumes:
      - bw-storage:/data
    networks:
      - bw-universe

  bw-ui:
    image: bunkerity/bunkerweb-ui:1.6
    depends_on:
      - bunkerweb
    networks:
      - bw-universe

networks:
  bw-universe:
    name: bw-universe
  bw-services:
    name: bw-services

volumes:
  bw-storage:

После docker compose up -d планировщик сам генерирует nginx-конфиг под эти настройки, выпускает сертификат Let's Encrypt и продлевает его без вашего участия, включает ModSecurity с CRS без ручной сборки модуля, добавляет антибот-челлендж (капчу или JS-проверку в зависимости от значения USE_ANTIBOT) и лимитирует запросы по IP. Всё это управляется одним набором переменных, а не пятью разными конфиг-файлами и cron-задачами.

Дополнительно доступны геоблокировка по странам (BLACKLIST_COUNTRY / WHITELIST_COUNTRY), проверка IP по DNSBL-спискам, whitelisting доверенных ботов (поисковики) без false positive от антибот-модуля, и веб-панель bw-ui, где часть настроек меняется кликами вместо правки environment-переменных и перезапуска контейнеров. Для команды, где кроме вас за сервер отвечает ещё один человек без глубокого знания nginx, это ощутимый плюс.

Цена абстракции: что теряете в прозрачности

Здесь начинается честная часть. Абстракция BunkerWeb решает задачу «включить защиту быстро», но платите вы за это тем, что раньше умели читать и что теперь скрыто за слоем настроек.

Отладка через два слоя вместо одного. Когда голый nginx отдаёт 502 или не подхватывает сертификат, вы читаете nginx -t, смотрите error.log и правите конкретную директиву. С BunkerWeb ошибка может быть на уровне самого nginx (тот же error.log доступен) или на уровне планировщика, который неверно сгенерировал конфиг из ваших настроек, или в API-обмене между bunkerweb и bw-scheduler контейнерами. Причину приходится искать в двух системах сразу, и логи планировщика читаются не так интуитивно, как привычный nginx access/error лог.

Ваши знания nginx частично обесцениваются. Годами наработанное умение читать и писать nginx.conf при переходе на BunkerWeb превращается в умение читать документацию по конкретным переменным окружения — а это более узкое и менее переносимое знание. Экосистема готовых решений вокруг голого nginx огромна (десятки лет практики сообщества); вокруг настроек конкретного WAF-дистрибутива она заметно меньше.

Зависимость от релизного цикла проекта. С голым nginx вы обновляете один пакет со стабильным API конфигурации, который не менялся принципиально годами. С BunkerWeb вы привязаны к темпу обновлений всего проекта: новые версии могут переименовывать переменные, менять состав Docker-сервисов, требовать миграции хранимых настроек — у активно развивающихся security-инструментов такие изменения между мажорными версиями случаются чаще, чем в самом nginx.

Больше движущихся частей. Docker-инсталляция BunkerWeb — это минимум три контейнера (сам bunkerweb, планировщик, панель), которые общаются между собой по внутреннему API, плюс постоянное хранилище настроек. У голого nginx это один процесс и один конфиг-файл. Каждый дополнительный компонент — ещё одна точка, которую нужно резервировать и мониторить.

ModSecurity добавляет накладные расходы на каждый запрос, потому что разбирает тело и заголовки по правилам CRS перед тем, как пропустить запрос дальше — это справедливо и для голого nginx с руками собранным модулем, и для BunkerWeb, но в BunkerWeb это включено по умолчанию, и не всегда очевидно новичку, что за WAF-проверку платят задержкой на каждый запрос. Насколько она заметна — зависит от нагрузки и агрессивности набора правил, точную цифру без замера на своём трафике не даст никто.

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

Custom configs: как вернуть точечный контроль внутри BunkerWeb

Разработчики BunkerWeb знают про эту цену и оставили лазейку: механизм custom configs позволяет подкладывать произвольные фрагменты nginx-конфига на разных уровнях генерации — до или после стандартных блоков http, server, modsec, stream и других. Технически это либо файлы в примонтированной директории (/data/configs/<уровень>/имя.conf в томе планировщика), либо те же данные, переданные через переменные окружения с префиксом CUSTOM_CONF_, в зависимости от способа установки.

Это не полноценный доступ к nginx.conf целиком — вы не редактируете сгенерированный файл напрямую (планировщик перезапишет его при следующей генерации), а добавляете точечные вставки в определённые точки шаблона. Для тонких директив, которых нет среди штатных настроек BunkerWeb — специфичный proxy_buffer_size, кастомный map-блок, нестандартный location с логикой, которую переключателями не выразить, — это рабочий путь. Но он требует понимания, в какую точку шаблона встраивается фрагмент и в каком порядке применяются вставки от разных источников — отдельная область знаний поверх обычного nginx-синтаксиса.

Практический вывод: полностью прозрачного nginx.conf вы не вернёте, но для точечных потребностей — если 95% защиты устраивает как есть, а 5% нужно донастроить руками — custom configs закрывают разрыв без отказа от BunkerWeb целиком. Это разумный компромисс, а не полный доступ к движку, который у вас был на голом nginx.

Кому что подходит: таблица решения

Если у вас уже есть отработанный конфиг nginx, знание ModSecurity и время поддерживать fail2ban-фильтры — переход на BunkerWeb, скорее, добавит слой без пропорциональной выгоды: вы и так закрыли те же задачи своими руками и с полным пониманием каждой строчки. Если защиту нужно поднять быстро, штата на регулярное обновление CRS-правил нет, а часть настроек хочется отдать коллеге через веб-панель — BunkerWeb экономит реальное время и закрывает базовые классы атак без глубокого погружения в ModSecurity.

Рабочий средний путь — гибрид: часть проектов держать под голым nginx, где нужен максимальный контроль (например, сложная маршрутизация из статьи про настройку nginx как реверс-прокси), а публичные сайты с высоким риском автоматизированных атак — вынести под BunkerWeb на отдельном инстансе. На VPS с полным root-доступом это вопрос не архитектуры, а ресурсов: оба варианта требуют памяти и CPU под собственный процесс анализа трафика, особенно ModSecurity под нагрузкой.

Частые вопросы