Коротко — nginx сам по себе относительно «маленький» и надёжный сервер, но в реальности уязвимости и проблемы чаще возникают из‑за устаревших версий/библиотек, плохой конфигурации, сторонних модулей и уязвимостей прикладного уровня (WordPress, PHP‑приложения и т. п.). Ниже — обзор типичных угроз и конкретные меры защиты, которые реально снижают риск при развёртывании сайта на VPS.
1) Типичные уязвимости/проблемы для nginx и окружения
- Устаревший nginx / библиотеки (OpenSSL, libpcre и т. п.) — открытые CVE.
- Утечка метаданных (server_tokens показывает версию).
- Неправильная конфигурация proxy_pass → утечка заголовков, открытый прокси, SSRF‑векторы.
- Директории с открытой индексацией и доступ к скрытым файлам (.git, .env, .htpasswd).
- Неправильные права файлов/пулов PHP (php-fpm) → выполнение чужого кода.
- Большие тела запроса / медленные соединения (Slowloris, DDoS через HTTPS).
- HTTP request smuggling / desync (при наличии нескольких прокси с разной логикой парсинга).
- Наличие уязвимых сторонних модулей (lua‑модули, старые плагины для nginx Plus).
- TLS/SSL ошибки: слабые протоколы/шаги (SSLv3/weak ciphers), отсутствие OCSP stapling, уязвимости OpenSSL.
- Web‑приложение (WordPress, CMS) уязвимости: brute force, xmlrpc abuse, path‑traversal, RCE/XSS/SQLi.
2) Общие и обязательные меры защиты (очень кратко)
- Обновляйте nginx и OpenSSL/OS регулярно.
- Уберите/минимизируйте ненужные модули.
- Запускайте nginx под непривилегированным пользователем, настройте права на файлы.
- Отключите server_tokens: server_tokens off;
- Закройте доступ к скрытым/системным файлам:
location ~ /\.(?!well-known) { deny all; }
- Отключите autoindex (autoindex off).
- Ограничьте размер тела запроса: client_max_body_size 10M (под ваши нужды).
- Ограничьте величину заголовков/буферов: large_client_header_buffers 4 16k;
- Защититесь от «медленных» соединений: client_body_timeout, client_header_timeout, keepalive_timeout меньше по разуму.
- Логи + мониторинг + alerting; централизованная аналитика (ELK/Graylog) и регулярные проверки логов.
3) Защита от автоматических сканирований/брутфорса и DDoS‑попыток
- Rate‑limit (limit_req / limit_conn):
- limit_req_zone $binary_remote_addr zone=rl:10m rate=5r/s;
- limit_req zone=rl burst=20 nodelay;
- limit_conn_zone $binary_remote_addr zone=addr:10m;
- limit_conn addr 10;
- Блокировка по сигнатурам/агентам/URI (fail2ban + парсинг access.log) — для защиты от Brute/WordPress сканирования.
- Блокировать xmlrpc.php или закрыть его для всех, кроме нужных IP.
- Защитите /wp-admin/ базовой аутентификацией (nginx auth_basic) или переместите админку за VPN.
- CDN/WAF/Anti‑DDoS (Cloudflare, Fastly, Sucuri и т. п.) — отбрасывают массовый трафик и снижают нагрузку TLS.
- Использовать SYN/connection‑rate настройки ядра + tcp_backlog для устойчивости при DDoS.
4) WAF и защита прикладного уровня
- Разверните ModSecurity (в связке с nginx via connector) + OWASP CRS, либо NAXSI. Это критично, если вы не доверяете коду приложения.
- Правила для типичных атак на WordPress (сканирование уязвимостей, попытки загрузки shell, access to wp‑includes etc.).
- Защитные заголовки: Strict‑Transport‑Security, X-Frame-Options, X-Content-Type-Options, Content‑Security‑Policy (по возможности).
- Принудительная фильтрация/валидация на бэкенде (не полагаться только на nginx).
5) Конфигурация TLS / HTTPS (важно: атаки по HTTPS)
Атаки по HTTPS бывают двух типов: сетевые/криптографические (downgrade, слабые шифры, уязвимости OpenSSL) и прикладные (через зашифрованный трафик от клиента — XSS, SQLi и т. д.). Меры:
- Используйте современные настройки TLS (предпочтительно TLS 1.3 + TLS 1.2):
ssl_protocols TLSv1.2 TLSv1.3;
- Используйте рекомендованные шифры (Mozilla «Modern/Intermediate»). Пример: ssl_prefer_server_ciphers off; ssl_ciphers 'ECDHE+AESGCM:...';
- Включите HSTS (внимание: preload и includeSubDomains только если уверены):
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
- Включите OCSP stapling:
ssl_stapling on;
ssl_stapling_verify on;
- Отключите SSL‑session tickets при необходимости, создайте сильные dhparam:
ssl_session_tickets off;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
- Регулярно патчьте OpenSSL (Heartbleed, FREAK и т. п. — все это исторические примеры).
- Сохраняйте приватные ключи в безопасном месте (ограничения прав, HSM при возможности).
- Если на VPS много нагрузок / маленькие ресурсы: используйте CDN или TLS‑терминирование на стороннем сервисе (снижает риск TLS‑DDoS).
6) Противодействие специфическим HTTPS‑атакам
- TLS DDoS (много дорогих рукопожатий): использовать CDN/TLS offload, limit_conn, rate limits и tcp syn cookies на уровне ОС.
- Man‑in‑the‑middle и поддельные сертификаты: следить за CT (Certificate Transparency), использовать мониторинг сертификатов, короткий срок жизни сертификатов.
- Request smuggling / desync при мульти‑прокси: убедитесь, что все промежуточные прокси используют одинаковые HTTP версии и согласованные заголовки. В nginx избегайте передачи конфликтующих заголовков Transfer‑Encoding/Content‑Length; примеры:
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering on;
- Защита от SSL renegotiation/подделки: обновляйте OpenSSL, используйте современные настройки.
7) Практические nginx‑сниппеты (важнейшее)
- Скрыть версию:
server_tokens off;
- Ограничение тела:
client_max_body_size 10M;
- Блокировка скрытых файлов:
location ~ /\.(?!well-known) { deny all; }
- Запретить опасные методы:
if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; }
- Rate‑limit:
limit_req_zone $binary_remote_addr zone=rl:10m rate=5r/s;
limit_req zone=rl burst=20 nodelay;
- Безопасный SSL:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:...'; (использовать готовые рекомендованные списки)
8) Окружающая безопасность VPS и бэкенда
- Локально: firewall (ufw/iptables/nftables) — разрешать только порты 80/443/22 (и SSH только с ваших IP или через jump host).
- SSH: запрет root, использовать ключи, поменять порт, fail2ban для SSH.
- php‑fpm: закрыть от прямого доступа, использовать unix socket, настроить open_basedir, disable_functions, выставить процесс‑пул c ограничением max_execution_time/memory_limit.
- Файловая система: права 644/755, www-data владелец, запрет записи в каталоги, где не требуется.
- SELinux/AppArmor — включить если возможно.
9) Ответ на вашу вторую часть (много GET/POST — как через HTTPS атакуют и что делать)
- Что делают сканеры: ищут известные CMS/плагины (WordPress), пытаются найти админки, xmlrpc.php, wp-login.php, пытаются загрузить веб‑шеллы через уязвимые плагины, пытаются SQLi/XSS.
- Как защититься:
- Блокируйте/ограничивайте частые запросы: limit_req, fail2ban.
- Закройте/защитите административные интерфейсы (basic auth, IP whitelist).
- WAF (ModSecurity + OWASP CRS) для фильтрации exploit‑payloads.
- Ограничьте публичный доступ к upload/exec каталогам, запрещайте исполнение кода в upload.
- Применяйте CAPTCHA для форм входа/регистрации.
- Используйте CDN и IP‑репутационные списки (или сервисы типа Cloudflare) для автоматической фильтрации ботов.
- Мониторинг: настраивайте алерты при резком росте 404/500/POST запросов.
10) Рекомендации по приоритету (что сделать первым)
1. Обновить nginx/OS/openssl.
2. Закрыть лишние порты, включить firewall, запретить root SSH, настроить fail2ban.
3. Настроить TLS по современным рекомендациям и HSTS.
4. Ограничить body/timeout/заголовки, включить limit_req/limit_conn.
5. Скрыть server_tokens, запретить доступ к .git/.env и автоиндексацию.
6. Внедрить WAF (ModSecurity/NAXSI) и rules для WordPress (если используете WP).
7. Логи -> автоматические правила блокировки (fail2ban) + мониторинг.
Если хотите, могу:
- Прислать готовую «безопасную» конфигурацию nginx (сервер‑блок) под ваш конкретный проект (скажите: статический сайт / PHP‑FPM / проксирование на backend).
- Помочь составить fail2ban‑правила или ModSecurity‑правила под WordPress.
- Проанализировать конкретные строки access.log и подсказать какие запросы блокировать.
Хочешь, начнём с проверки нескольких ключевых параметров твоего nginx.conf и примеров логов, которые ты видишь?