Основы безопасности Nginx: лучшие практики и часто задаваемые вопросы по устранению неполадок
Практические часто задаваемые вопросы по безопасности Nginx, охватывающие HTTPS, раскрытие файлов, заголовки прокси, ограничения скорости и анализ журналов.
Основы безопасности Nginx: лучшие практики и часто задаваемые вопросы по устранению неполадок
Основы безопасности Nginx — это не одна настройка или один магический заголовок. Это набор продуманных значений по умолчанию: HTTPS, строгий контроль доступа к файлам, безопасное поведение прокси, ограничение видимости и журналы, которые помогают выявить проблемы до того, как они разрастутся.
Этот FAQ охватывает вопросы, которые команды обычно задают после запуска Nginx и осознания того, что конфигурация по умолчанию — это лишь отправная точка.
Какие настройки безопасности Nginx следует проверить в первую очередь?
Начните с основ, которые уменьшают случайное раскрытие. Эти настройки защищают от распространенных ошибок, а не от продвинутых атак.
Во-первых, отключите отображение версии:
server_tokens off;
Это запрещает Nginx сообщать свою версию в страницах ошибок и заголовках. Это не делает сервер невидимым, но удаляет лишние детали.
Во-вторых, убедитесь, что корневой каталог документов указан правильно. Распространенная ошибка — указывать root на каталог проекта вместо каталога публичной сборки. Это может раскрыть исходные файлы, примеры окружения или приватные ресурсы.
Для статического сайта предпочтительнее:
root /var/www/example.com/public;
а не:
root /var/www/example.com;
В-третьих, заблокируйте скрытые файлы, если только ваше приложение действительно не нуждается в них:
location ~ /\.(?!well-known) {
deny all;
}
Это разрешает пути .well-known, используемые для проверки сертификатов, но запрещает доступ к файлам .env, .git и .htpasswd.
Наконец, проверьте лимиты загрузки. Если ваш сайт не принимает большие файлы, держите client_max_body_size скромным. Это уменьшает радиус поражения при случайных больших запросах.
Как Nginx должен обрабатывать HTTPS?
HTTPS должен быть стандартным путем для публичных сайтов и API. Перенаправляйте обычный HTTP на HTTPS, используйте валидные сертификаты и избегайте устаревших настроек протокола.
Простой блок сервера для перенаправления выглядит так:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
Блок сервера HTTPS должен ссылаться на ваши файлы сертификатов и включать современные настройки TLS. Многие команды используют Certbot или управляемый балансировщик нагрузки для работы с сертификатами. Важно автоматизировать и контролировать продление.
Заголовки безопасности также могут помочь браузерам принимать более безопасные решения:
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
Будьте осторожны с Content Security Policy. Он мощный, но строгая политика может сломать скрипты, шрифты, аналитику или встроенный контент, если применить ее без тестирования. По возможности начинайте в режиме только отчетов.
Для практического руководства по HTTPS см. обеспечение безопасности Nginx с помощью HTTPS.
Как защитить Nginx в качестве обратного прокси?
Когда Nginx проксирует трафик к приложению, необходимо сохранять правильную информацию о запросе, не доверяя слепо вводу клиента.
Типичные заголовки прокси выглядят так:
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;
Эти заголовки помогают вышестоящему приложению понять исходный запрос. Они полезны для журналирования, перенаправлений, ограничения скорости и проверок безопасности.
Если Nginx находится за другим доверенным прокси или балансировщиком нагрузки, настройте обработку реального IP-адреса осторожно. Доверяйте только известным адресам прокси:
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Не доверяйте X-Forwarded-For из открытого интернета. Клиент может подделать этот заголовок. Доверяйте ему только тогда, когда запрос приходит от вашего балансировщика нагрузки, CDN или внутреннего прокси.
Также следует скрывать детали реализации вышестоящего сервера. Если ваше приложение возвращает ненужные заголовки, специфичные для фреймворка, удалите их на уровне прокси или приложения.
Стоит ли использовать ограничение скорости?
Ограничение скорости полезно для страниц входа, конечных точек поиска, дорогих API и любых маршрутов, которые злоумышленники могут легко использовать. Это не замена безопасности приложения, но может замедлить попытки подбора и шумный трафик.
Пример:
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
server {
location /login {
limit_req zone=login burst=10 nodelay;
proxy_pass http://app_backend;
}
}
Это создает зону разделяемой памяти, привязанную к IP-адресу клиента, и ограничивает запросы к пути входа. Точные значения зависят от ваших пользователей. Корпоративная панель управления обычно может выдержать более строгие ограничения, чем публичное потребительское приложение в мобильных сетях.
Тщательно тестируйте ограничения скорости. Если ваш сайт находится за прокси и вы не настроили обработку реального IP-адреса клиента, каждый пользователь может казаться приходящим с одного и того же адреса. Это может заблокировать легитимный трафик.
Почему я все еще вижу подозрительные запросы?
Публичные серверы Nginx постоянно получают фоновый шум: сканирование старых панелей администратора, PHP-файлов, путей WordPress и раскрытых файлов окружения. Наличие этих запросов в журналах не всегда означает, что вы скомпрометированы.
Важно то, как ваш сервер отвечает. Запрос к /wp-admin на сайте, не использующем WordPress, должен возвращать 404 или 403. Запрос к /.env никогда не должен возвращать секреты. Запрос со странным путем не должен проксироваться к внутреннему сервису администратора.
Проверяйте журналы доступа на наличие:
- Повторяющихся ответов 401 или 403
- Множества запросов с одного IP
- Больших тел запросов
- Попыток доступа к скрытым файлам
- Необычных user-agent
- Всплесков ответов 499, 502 или 504
Для более широкого устранения неполадок см. распространенные ошибки Nginx.
Когда обращаться за помощью по безопасности
Привлекайте инженера по безопасности или опытного консультанта DevOps, когда Nginx защищает данные клиентов, аутентификацию, платежные потоки, частные API или внутренние инструменты администратора. Также следует обращаться за помощью после любого предполагаемого взлома, неожиданного раскрытия файлов или повторяющихся атак, влияющих на доступность.
Профессиональный обзор стоит того, когда конфигурация охватывает несколько уровней, таких как CDN, балансировщик нагрузки, Nginx, сервисная сетка и фреймворк приложения. Безопасный файл Nginx может быть ослаблен плохой границей доверия где-то еще.
Обеспечьте безопасность Nginx, удалив ненужное раскрытие, принудительно включив HTTPS, осторожно обрабатывая заголовки прокси и отслеживая журналы. Вам не нужна огромная конфигурация, чтобы быть в большей безопасности. Вам нужны четкие настройки по умолчанию, протестированные изменения и привычка проверять, что ваш сервер на самом деле отдает.