Безопасная настройка Nginx и Apache: защита от DDoS и ботов

Веб-сервер это первая линия обороны любой инфраструктуры. Однако настройки «по умолчанию» часто играют на руку злоумышленникам, выдавая версии ПО и оставляя открытыми двери для автоматизированных атак. Кибер Медиа вместе с экспертами разбирает, как правильно скрыть лишнее, настроить Rate Limiting и не сломать продакшн.

Содержание

Режим тишины: скрываем версии и заголовки

Первый этап настройки любого веб-сервера перед выходом в продакшн — минимизация информации, которую он отдает внешнему миру. Базовые баннеры сервера часто содержат не только название (Nginx/Apache), но и точные версии операционной системы и подключенных модулей.

Максим Федосенко

Инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

«Все это — подарок для атакующего: он сразу понимает, какие у сервера есть уязвимости (CVE) и какие эксплойты способны его положить. Что касается базовых директив, то server_tokens off и ServerSignature Off убирают только версию, а сам заголовок сервера при этом остается. Отсюда важно убирать любые упоминания об используемом софте в HTTP-заголовках, чтобы сканеры злоумышленников не могли идентифицировать цель».

Для полного скрытия информации эксперты рекомендуют выходить за рамки стандартных директив.

• PHP: Отключить вывод версий интерпретаторов (например, expose_php = off).
• Прикладные заголовки: Убрать X-Powered-By, X-AspNet-Version через директивы proxy_hide_header (Nginx) или Header unset (Apache).
• Заголовок Server: В Apache использовать ServerTokens Prod и Header unset Server. В Nginx для полного удаления строки Server потребуется сторонний модуль headers-more.

Однако у такой «стерильности» есть обратная сторона — усложнение отладки.

Владислав Шелепов

Аналитик угроз GSOC компании «Газинформсервис»

«Инженерам будет сложнее быстро определить версии компонентов при анализе сбоев на продакшн-среде. Чтобы этого избежать, можно передавать служебную информацию (версию, имя сервера) только во внутренних заголовках, которые сбрасываются перед отправкой клиенту, либо фиксировать её в логах и системах трейсинга».

Rate Limiting: алгоритм дырявого ведра и защита от флуда

Ограничение скорости запросов (Rate Limiting) — ключевой механизм защиты от Brute-force и DDoS-атак уровня приложений (L7). При выборе между Nginx и Apache эксперты отдают явное предпочтение первому из-за архитектурных различий.

Максим Федосенко

Инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

«Реализация limit_req_zone в Nginx является на голову выше аналога за счет алгоритма leaky bucket ("дырявое ведро"). Суть заключается в поддержании постоянной скорости передачи данных за счет их хранения в буфере. Это позволяет как минимизировать успешные реализации DDoS-атак, так и избежать ложных блокировок активных пользователей. Параметр burst (буфер для легитимных всплесков) как раз и определяет размер «очереди» для всплесков. Установка burst=10 и включение поддержку nodelay является наиболее оптимальным решением защиты сервера от его перегруза запросами».

Фильтрация по Referer: как не заблокировать легитимных пользователей

Блокировка запросов с пустым или подозрительным заголовком Referer кажется простым решением, но на практике это минное поле. Прямой переход по закладке, ввод адреса вручную или настройки приватности в браузере часто приводят к тому, что легитимный пользователь приходит с пустым Referer.

Владислав Шелепов

Аналитик угроз GSOC компании «Газинформсервис»

«Блокировать запросы только по пустым Referer – это точно плохая практика. Хорошим подходом будет блокировать такие запросы только в связке с другими аномалиями, например, при наличии пустого User-Agent’а, несоответствия PTR-записи или отсутствия Accept-заголовков. Также злоумышленники часто не оставляют Referer пустым, а заполняют его случайными символами, обрезанными URL или явно спамерскими доменами. Такие значения даже не пытаются имитировать реальный переход - их можно отсекать по регулярным выражениям».

Эксперты советуют применять точечную фильтрацию. Например, жесткая проверка Referer оправдана для статических ресурсов (изображений), чтобы защититься от хотлинкинга. При этом важно помнить про белые списки: Яндекс и Google могут приходить с нестандартным Referer, но их IP-диапазоны известны и публичны.

CSP и защита от XSS: от мягкого контроля к жесткой блокировке

Настройка Content Security Policy (CSP) часто пугает администраторов риском «сломать» работу сайта, особенно если используются inline-скрипты и сторонние виджеты. Основная проблема CSP — излишняя жесткость. Лучший способ избежать сбоев — внедрять политику поэтапно, начиная с режима Report-Only.

Максим Федосенко

Инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

«Говоря подробнее, при включении Content-Security-Policy-Report-Only браузер будет слать отчеты об ошибках, но не будет ничего блокировать. Также немаловажным подходом в настройке серверов является внедрение одноразовых токенов nonce для доверенных inline-скриптов. Nonce представляет собой уникальный код, который меняется при каждой загрузке страницы, что позволит защититься от XSS-атак, сохранив при этом работоспособность аналитики и сторонних виджетов».

Мониторинг и интеграция с внешними защитниками

Даже идеально настроенный сервер нуждается в мониторинге и часто — в защите внешними сервисами (Cloudflare, AWS Shield). При интеграции с ними важно не допустить ситуации, когда сервер банит IP-адреса самого защитника. Для Nginx необходимо использовать модуль ngx_http_realip_module и настроить доверие к IP-адресам провайдера защиты.

Оценка эффективности защиты требует анализа конкретных метрик.

1. Коэффициент блокировки (отношение числа отклоненных запросов к общему объему трафика);
2. Интенсивность срабатываний каждого правил СЗИ;
3. Доля ложных срабатываний среди легитимных пользователей;
4. Время отклика сервера под нагрузкой (при эффективной DDoS-защите latency бэкенда не коррелирует с ростом числа запросов)».

Максим Федосенко

Инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

«Эффективный мониторинг строится на основе анализа аномалий. Например, резкий всплеск параметра request_time или отклонения от привычного соотношения 4xx/5xx HTTP-статусов сервера могут говорить о начале DDoS-атаки на уровне Приложения. В этом администратору может помочь использование связки Prometheus + Grafana, которая не только позволит обнаружить факт атаки, но и увидеть ее паттерн для дальнейшей подстройки фильтров защиты».

Заключение

Настройка веб-сервера — это всегда поиск баланса между безопасностью и доступностью. Как отмечают эксперты, чрезмерно жесткие фильтры (например, блокировка всех пустых Referer или агрессивный CSP) могут отсечь легитимный трафик и нарушить работу бизнес-функций.

Эффективная защита строится не на «коробочных» решениях, а на комбинации методов: скрытии технической информации, умном ограничении скорости запросов (Rate Limiting) и постоянном мониторинге аномалий. Использование инструментов аналитики, таких как Prometheus и Grafana, позволяет превратить реакцию на инциденты из хаотичной в управляемую, давая администраторам возможность адаптировать защиту под меняющиеся векторы атак.