Nginx и Apache: Полная защита веб-серверов. HTTPS, заголовки, WAF и противодействие атакам (2026) | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Nginx и Apache: Полная защита веб-серверов. HTTPS, заголовки, WAF и противодействие атакам (2026)

30 апреля 2026 9 мин. чтения
Содержание статьи

Защита веб-сервера - это не единовременное действие, а многослойный процесс, охватывающий шифрование трафика, контроль доступа и фильтрацию вредоносных запросов. Это руководство предоставляет готовые, проверенные на практике конфигурации для Nginx и Apache, которые вы можете внедрить поэтапно. Мы разберем настройку современного стека SSL/TLS, внедрение критически важных security-заголовков, установку WAF и конфигурационные меры против DDoS и инъекций. Каждый шаг сопровождается параллельными примерами для двух серверов и инструкциями по безопасному тестированию.

Безопасный фундамент: настройка HTTPS с актуальными протоколами и шифрами

HTTPS перестал быть опцией и стал обязательным стандартом. Устаревшие протоколы и слабые шифры создают уязвимости, которыми активно пользуются злоумышленники. В 2026 году базой является отказ от SSLv3, TLS 1.0 и TLS 1.1, использование только TLS 1.2 и 1.3 с актуальными наборами шифров. Автоматизация работы с сертификатами через Let's Encrypt исключает человеческий фактор и риск простоя.

Готовые конфигурации SSL/TLS для Nginx и Apache (актуально на 2026 год)

Ниже приведены оптимизированные шаблоны конфигураций. Замените example.com на ваше доменное имя и пути к сертификатам на актуальные.

Конфигурация для Nginx (фрагмент server {…} в nginx.conf или sites-available/):

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri; # Принудительный редирект HTTP -> HTTPS
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # Пути к сертификатам
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Актуальные протоколы безопасности
    ssl_protocols TLSv1.2 TLSv1.3; # Отключаем старые, небезопасные версии
    # Современный, безопасный набор шифров для TLS 1.2/1.3
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off; # Для TLS 1.3 клиент выбирает шифр

    # OCSP Stapling - ускоряет проверку отзыва сертификата
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # Кэширование параметров SSL-сессии для производительности
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ... # Дальнейшая конфигурация location / {}
}

Конфигурация для Apache (фрагмент VirtualHost в apache2/sites-available/ или httpd.conf):


    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/ # Редирект на HTTPS



    ServerName example.com
    ServerAlias www.example.com

    # Пути к сертификатам
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    # Настройка протоколов и шифров
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 # Включаем только TLS 1.2+
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder off

    # Включение OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
    ... # Дальнейшая конфигурация DocumentRoot и Directory

Автоматизация с Certbot: получение и беспроблемное продление сертификатов

Ручное обновление сертификатов - источник сбоев. Certbot решает эту задачу. Сначала установите клиент:

# Ubuntu/Debian
sudo apt update
sudo apt install certbot python3-certbot-nginx # Для Nginx
sudo apt install certbot python3-certbot-apache # Для Apache

# CentOS/RHEL 8+
sudo dnf install certbot python3-certbot-nginx
sudo dnf install certbot python3-certbot-apache

Получите сертификат в тестовом режиме (не добавляет в preload-лист HSTS):

sudo certbot --nginx --staging -d example.com -d www.example.com # Для Nginx
sudo certbot --apache --staging -d example.com -d www.example.com # Для Apache

Убедившись, что все работает, выполните команду для боевого режима (уберите флаг --staging). Certbot автоматически обновит конфигурацию вашего сервера. Для автоматического продления добавьте задание в cron. Проверьте, что оно уже существует:

sudo systemctl list-timers | grep certbot
# Или создайте cron-задачу
sudo crontab -e
# Добавьте строку (запуск дважды в день)
0 */12 * * * /usr/bin/certbot renew --quiet && systemctl reload nginx

Частая ошибка - сбой верификации из-за неправильно настроенного firewall или DNS. Убедитесь, что порт 80 (HTTP) открыт для входящих подключений с любых IP на время верификации Let's Encrypt. Подробнее о ручной установке и тонкостях процесса читайте в пошаговом руководстве по установке SSL-сертификатов.

Security-заголовки: точечная защита от XSS, кликджекинга и принуждение к HTTPS

Security-заголовки - это инструкции для браузера, которые усиливают защиту на стороне клиента. HSTS предотвращает атаки downgrade, принуждая браузер всегда использовать HTTPS. CSP - самый мощный инструмент против XSS, контролирующий источники загружаемого контента. X-Frame-Options защищает от кликджекинга, запрещая встраивание страницы в frame.

HSTS и X-Frame-Options: базовая и обязательная защита

Эти заголовки должны быть на любом сайте.

Настройка в Nginx (внутри блока server на порту 443):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# max-age=31536000 - срок действия политики 1 год.
# includeSubDomains - политика применяется ко всем поддоменам.
# preload - не добавляйте эту директиву вручную. Добавление в preload-лист требует отдельной процедуры через hstspreload.org.

add_header X-Frame-Options "SAMEORIGIN" always;
# DENY - полный запрет встраивания. SAMEORIGIN - разрешено встраивание только с того же домена.

Настройка в Apache (внутри VirtualHost *:443):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "SAMEORIGIN"

После настройки HSTS обязательно протестируйте работу сайта. Отменить его действие до истечения max-age сложно.

Content-Security-Policy (CSP): построение эффективной защиты от XSS

Неправильно настроенный CSP ломает функционал сайта. Внедряйте его поэтапно.

1. Режим report-only. Сначала директива только отправляет отчеты о нарушениях, не блокируя контент.
Для Nginx:
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; report-uri /csp-report-endpoint;" always;
Создайте простой endpoint (например, на PHP или Node.js) для приема отчетов или используйте сторонние сервисы.

2. Анализ и создание политики. Проанализируйте отчеты, определите, какие внешние источники (CDN, сторонние API, виджеты) использует ваш сайт.

3. Включение полноценной CSP. Пример политики для сайта со статикой на своем домене и Google Fonts:
Для Apache:
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' fonts.googleapis.com; font-src fonts.gstatic.com; img-src 'self' data:;"

Пояснение директив:
- default-src 'self': по умолчанию все загружается только с текущего домена.
- script-src: источники скриптов. 'unsafe-inline' - временная мера для инлайн-скриптов, от которой нужно избавиться.
- style-src: источники стилей. Разрешены свои и fonts.googleapis.com.
- font-src: источники шрифтов (fonts.gstatic.com).
- img-src: источники изображений. data: разрешает data:URI.

Постоянный мониторинг логов на предмет аномалий - ключ к безопасности. Освойте практический анализ логов Nginx и Apache с помощью готовых команд grep и awk.

Web Application Firewall (WAF): установка и настройка mod_security

WAF анализирует HTTP-трафик на уровне приложения, блокируя запросы, соответствующие известным шаблонам атак (инъекции, XSS, сканеры уязвимостей). Для Apache стандартным решением является mod_security с OWASP Core Rule Set (CRS).

Установка OWASP Core Rule Set (CRS) и базовая конфигурация

Установка на Ubuntu/Debian:

sudo apt install libapache2-mod-security2
sudo apt install modsecurity-crs
# Активируем модуль и базовые правила
sudo a2enmod security2
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo systemctl reload apache2

Настройка modsecurity.conf:
Найдите и измените директиву:
SecRuleEngine DetectionOnly на SecRuleEngine On
В режиме DetectionOnly запросы только логируются, но не блокируются. Включайте блокировку (On) только после тестирования.

Подключение OWASP CRS:
Обычно правила находятся в /usr/share/modsecurity-crs/. Включите их в конфигурации Apache, добавив в секцию основного конфига или virtualhost:
IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/rules/*.conf

Проверьте работоспособность, отправив тестовый запрос с попыткой SQL-инъекции: curl -k "https://ваш-сайт/?id=1' OR '1'='1" и проверьте логи Apache (/var/log/apache2/modsec_audit.log или /var/log/httpd/modsec_audit.log).

Адаптация правил WAF и работа с ложными срабатываниями

Стандартные правила CRS могут блокировать легитимный трафик вашего приложения. Ложные срабатывания выявляются в логе modsec_audit.log.

Пример. Правило с ID 942100 блокирует легитимный параметр вашего API. Вы можете отключить его для конкретного location в Apache:


    SecRuleRemoveById 942100

Более тонкая настройка - изменение действия правила только для определенного параметра. Это требует глубокого понимания формата правил ModSecurity. Всегда обновляйте CRS для получения актуальных правил защиты. Мониторинг и реакция на атаки в реальном времени - критически важная задача. Для автоматизации блокировок на уровне сети изучите полное руководство по блокировке IP-адресов в 2026 году.

Защита на уровне конфигурации сервера: DDoS, инъекции и ограничение доступа

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

Ограничение запросов и защита от DDoS-атак

Nginx: модуль ngx_http_limit_req_module.
В блоке http {} глобально определите зону и лимит:

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    # zone=api_limit:10m - зона памяти 10 МБ для хранения состояний IP.
    # rate=10r/s - лимит 10 запросов в секунду с одного IP.
    ...
    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
            # burst=20 - разрешает временное превышение лимита на 20 запросов.
            # nodelay - запросы сверх лимита и burst обрабатываются без задержки, но с кодом 503.
        }
    }
}

Apache: модуль mod_ratelimit (требует установки).
Внутри или :


    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 5 # 5 запросов в секунду

Защита от Slowloris (медленных HTTP-атак):
Nginx:
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 5s 5s;
Apache (в основном конфиге):
Timeout 60 # Общий таймаут. Снижение до 30-40 может помочь.
KeepAliveTimeout 5

Блокировка распространенных векторов атак: SQL, код и путь-траверс

Простые правила регулярных выражений могут отсечь заведомо вредоносные запросы до их попадания в приложение.

Пример для Nginx (внутри блока server или location):

# Блокировка типичных паттернов SQL-инъекций и LFI
if ($query_string ~* "(union\s+select|concat\s*\(|\/etc\/passwd|\/bin\/bash|\/sh\s*$)") {
    return 403;
}
# Блокировка попыток directory traversal
if ($request_uri ~* "\.\./|\x00") {
    return 403;
}

Пример для Apache (используя mod_rewrite в .htaccess или конфиге virtualhost):

RewriteEngine On
# Блокировка запросов с подозрительными параметрами
RewriteCond %{QUERY_STRING} (union\s+select|concat\s*\(|\/etc\/passwd) [NC]
RewriteRule ^ - [F,L] # Возвращает 403 Forbidden

Важно: Такие фильтры - дополнение, а не замена WAF и безопасного кода приложения. Всегда тестируйте их, чтобы не заблокировать легитимные запросы (например, поиск по слову "select").

Чек-лист и порядок внедрения: от тестирования до production

Внедрение изменений в security требует методичного подхода. Следуйте этому плану, чтобы избежать простоев.

Поэтапный план внедрения и тестирования в staging-среде

  1. Подготовка. Создайте полную резервную копию конфигурационных файлов Nginx/Apache и данных сайта.
  2. Staging. Все изменения сначала применяйте на идентичном тестовом стенде (staging).
  3. Последовательность внедрения на staging:
    • Шаг 1: Настройка HTTPS и SSL/TLS. Проверьте работу сайта, редирект с HTTP.
    • Шаг 2: Добавление базовых security-заголовков (HSTS, X-Frame-Options). Проверьте сайт в браузере, убедитесь, что ничего не сломано.
    • Шаг 3: Внедрение CSP в режиме report-only. Соберите и проанализируйте отчеты за несколько дней.
    • Шаг 4: Настройка защитных мер на уровне сервера (rate limiting, фильтрация). Протестируйте легитимные сценарии работы.
    • Шаг 5 (опционально): Установка и настройка WAF в режиме DetectionOnly. Проанализируйте логи на ложные срабатывания и адаптируйте правила.
  4. Проверка конфигурации. Перед перезагрузкой сервиса всегда выполняйте:
    sudo nginx -t (для Nginx)
    sudo apachectl configtest (для Apache)
  5. Выкатка на production. Выполняйте выкатку в период наименьшей нагрузки. Внедряйте изменения поэтапно, как и на staging, с интервалом для мониторинга.

Финальная проверка и инструменты для аудита безопасности

После внедрения всех мер проверьте результат с помощью сторонних сервисов и утилит.

  • SSL Labs (Qualys SSL Test): Проверка корректности настройки SSL/TLS, поддержки протоколов, шифров. Цель - оценка A+.
  • SecurityHeaders.com: Проверка наличия и корректности security-заголовков (HSTS, CSP, X-Frame-Options и др.).
  • Mozilla Observatory: Комплексный аудит безопасности веб-сайта.
  • Локальные утилиты:
    • curl -I https://ваш-сайт - просмотр заголовков ответа.
    • testssl.sh ваш-сайт - глубокий анализ SSL/TLS.
    • nmap --script ssl-enum-ciphers -p 443 ваш-сайт - перебор поддерживаемых шифров.

Что должно быть в логах после успешного внедрения:
- В access-логах: основной трафик на порту 443, минимальный - на порту 80 (редиректы).
- В error-логах: отсутствие ошибок, связанных с SSL-рукопожатием.
- В логах WAF (если установлен): записи о заблокированных атаках и отсутствие ложных срабатываний после настройки.

Установите периодичность повторного аудита (например, раз в квартал) и следите за обновлениями используемого ПО и правил CRS. Для автоматизации мониторинга и быстрого реагирования на инциденты интегрируйте логи в централизованную систему, как описано в руководстве по анализу логов.

Работа с современными ИИ-моделями для анализа кода или генерации правил также может ускорить процессы. Для удобного доступа к широкому спектру AI-API через единый интерфейс и без необходимости VPN рассмотрите сервис AiTunnel, который агрегирует более 200 моделей, включая GPT, Gemini и Claude, с оплатой в рублях и управлением бюджетами.

Поделиться:
Сохранить гайд? В закладки браузера