Лучшие практики безопасности Nginx: Защитите ваш веб-сервер

Ваш сервер Nginx часто является первой публичной службой, с которой сталкиваются пользователи и злоумышленники. Эти лучшие практики безопасности Nginx сосредоточены на контроле, который Nginx может реально обеспечить: TLS, ограничения запросов, заголовки, правила доступа, более безопасные настройки по умолчанию и регулярные обновления.

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

Безопасные соединения с помощью TLS

TLS шифрует трафик между браузером и вашим сервером. Используйте доверенный сертификат, перенаправляйте HTTP на HTTPS и отключайте устаревшие версии протоколов.

Получите сертификат

Let's Encrypt распространен для публичных веб-сайтов, но может работать любой доверенный центр сертификации. На многих серверах Linux Certbot хранит файлы в /etc/letsencrypt/live/your_domain.com/.

Настройте HTTPS

Отредактируйте блок сервера для вашего домена. Путь часто находится в /etc/nginx/sites-available/ на Debian/Ubuntu или /etc/nginx/conf.d/ на системах RHEL-стиля.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name your_domain.com www.your_domain.com;

    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;

    # Включите ваши общие настройки TLS
    include /etc/nginx/snippets/ssl-params.conf;

    # ... другие конфигурации (root, блоки location и т.д.)
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com;

    # Перенаправление HTTP на HTTPS
    return 301 https://$host$request_uri;
}

Используйте консервативные параметры TLS

Вы можете хранить общие настройки TLS в сниппете, например, /etc/nginx/snippets/ssl-params.conf.

# /etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# Включите HSTS (HTTP Strict Transport Security)
# Добавьте includeSubDomains, если применимо
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Включите OCSP Stapling для более быстрой проверки сертификатов
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Параметры Диффи-Хеллмана (сгенерируйте надежные, если необходимо)
# ssl_dhparam /etc/nginx/ssl/dhparams.pem;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Добавляйте includeSubDomains или preload в HSTS только после того, как убедитесь, что каждый поддомен поддерживает HTTPS. Неправильное развертывание HSTS может заблокировать пользователям доступ к старым поддоменам.

Внедрение ограничения скорости

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

Пример базового ограничения скорости

limit_req_zone определяет общее состояние, а limit_req применяет ограничение к location.

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        # ...

        location /login {
            limit_req zone=mylimit burst=10 nodelay;
            # ... конфигурация обработчика входа
        }

        location / {
            limit_req zone=mylimit burst=20 nodelay;
            # ... конфигурация основного сайта
        }
    }
}

В этом примере: $binary_remote_addr привязывает ограничение к IP-адресу клиента. burst=10 разрешает короткую вспышку выше средней скорости, а nodelay отклоняет избыточные запросы вместо их задержки.

Будьте осторожны за балансировщиком нагрузки или CDN. Если Nginx видит только IP-адрес прокси, ограничение скорости по $binary_remote_addr может наказать всех пользователей как одного клиента. Настройте обработку доверенных реальных IP-адресов, прежде чем полагаться на ограничения для каждого клиента.

Уменьшение поверхности распространенных атак

Nginx может уменьшить подверженность риску, но ваше приложение все равно нуждается в проверке ввода, кодировании вывода, параметризованных SQL-запросах, проверках аутентификации и исправлении зависимостей.

Добавьте заголовки безопасности

Заголовки безопасности могут снизить риск на стороне браузера:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Политика безопасности контента (CSP) может помочь с XSS, но она должна соответствовать скриптам, стилям, изображениям и сторонним сервисам вашего приложения. Начните в режиме только для отчетов, прежде чем применять ее на рабочем сайте.

Осторожно блокируйте очевидные сканеры

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

http {
    # Определите карту для блокировки плохих ботов/сканеров
    map $http_user_agent $bad_bot {
        default 0;
        "~*malicious_bot_pattern" 1;
        "~*another_suspicious_agent" 1;
    }

    server {
        # ...
        if ($bad_bot) {
            return 403;
        }
        # ...
    }
}

Ограничьте доступ к чувствительным путям

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

location / {
    root /var/www/html;
    index index.html index.htm;
    try_files $uri $uri/ =404;
    autoindex off; # Отключить список каталогов
}

# Пример ограничения доступа к чувствительным файлам
location ~ /\.ht {
    deny all;
}

Скрывайте версию Nginx

server_tokens off удаляет версию Nginx из генерируемых страниц ошибок и уменьшает детализацию в заголовке ответа Server.

http {
    server_tokens off;
    # ...
}

Ограничьте HTTP-методы, где это уместно

Если конечная точка принимает только GET и POST, отклоняйте другие методы там. Делайте это для каждого location, чтобы не нарушать CORS preflight запросы или конечные точки API, которые легитимно используют PUT, PATCH или DELETE.

location /api/ {
    # Разрешить только GET и POST
    if ($request_method !~ ^(GET|POST)$) {
        return 405;
    }
    # ...
}

Обновляйте Nginx

Исправления безопасности часто приходят через репозиторий пакетов вашего дистрибутива Linux. Держите Nginx и пакеты, связанные с OpenSSL, исправленными, и тестируйте перезагрузки после обновлений.

Для Debian/Ubuntu:

sudo apt update
sudo apt upgrade nginx

Для CentOS/RHEL:

sudo dnf update nginx

Используйте yum update nginx на старых версиях RHEL/CentOS, которые все еще используют yum.

Добавьте защиту на уровне хоста

Безопасность Nginx также зависит от окружающего хоста:

• Разрешайте только необходимые порты в ufw, firewalld, облачных группах безопасности или сетевых ACL.
• Мониторьте /var/log/nginx/access.log и /var/log/nginx/error.log на предмет всплесков, повторяющихся ответов 401/403 и подозрительных путей.
• Используйте Fail2ban или аналогичный инструмент, когда шаблоны логов могут идентифицировать злоупотребляющих клиентов.
• Запускайте sudo nginx -t перед каждой перезагрузкой, чтобы изменение безопасности не привело к отключению сайта.

Вывод

Начните с HTTPS, обновлений, ограниченных портов, безопасных заголовков и ограничений скорости на чувствительных путях, таких как /login. Затем регулярно просматривайте свои логи. Большинство преимуществ безопасности Nginx достигаются за счет постоянного обслуживания и четкой конфигурации, а не одного большого файла ужесточения, скопированного с другого сайта.