Мониторинг и аудит безопасности Nginx: настройка журналов и интеграция с auditd | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Мониторинг и аудит безопасности Nginx: настройка журналов и интеграция с auditd

17 мая 2026 6 мин. чтения
Содержание статьи

Зачем Nginx отдельный аудит, если есть логи?

Стандартные access.log и error.log в Nginx фиксируют все запросы и ошибки. Эти файлы нужны для анализа трафика и отладки. Однако они не создают защищенный, централизованный след критических событий безопасности. Злоумышленник, получивший доступ к серверу, может удалить или модифицировать эти логи.

Системный аудит через auditd решает эту проблему. Он создает независимый, защищенный от модификации трейл событий. auditd регистрирует действия на уровне системы и приложений в специальный журнал, доступ к которому контролируется жесткими правами. Интеграция логов Nginx с auditd превращает разрозненную информацию в единый поток данных для мониторинга безопасности. Это позволяет отслеживать попытки атак в одном месте вместе с другими системными событиями, например, изменениями файлов или запуском процессов.

Журналирование и аудит - разные процессы. Журналирование в Nginx фиксирует все запросы для анализа трафика. Аудит в auditd фиксирует только события, критичные для безопасности, в защищенном хранилище. Пример: запись 404 ошибки в access.log - это журналирование. Регистрация серии 404 запросов на админ-панель (/wp-admin/, /admin.php) в audit.log - это аудит потенциальной атаки. Аналогия с переходом от sudo к run0 в systemd: ключевое преимущество run0 - создание полного аудит-трейла через polkit. Для веб-сервера нужно достичь того же: создать неудаляемый след.

Настройка детального журналирования в Nginx для захвата атак

Первым шагом нужно настроить детальное журналирование в Nginx. Стандартный log_format захватывает базовые данные. Для мониторинга безопасности требуется расширенный формат.

Готовый log_format для мониторинга безопасности

Добавьте этот блок конфигурации в файл nginx.conf в разделе http. Он создает новый формат лога с именем security.

log_format security '$time_local | $remote_addr | $request_method | $status | $request_uri | $http_user_agent | $request_time | $http_referer';

Затем в конфигурации сервера или location используйте этот формат, записывая логи в отдельный файл.

access_log /var/log/nginx/security.log security;

Разберем переменные формата:

  • $time_local: локальное время запроса.
  • $remote_addr: IP-адрес клиента.
  • $request_method: метод HTTP (GET, POST).
  • $status: код ответа (200, 404, 403).
  • $request_uri: полный URI запроса, включая параметры.
  • $http_user_agent: заголовок User-Agent клиента.
  • $request_time: время обработки запроса в секундах.
  • $http_referer: источник запроса.

Запись в отдельный файл /var/log/nginx/security.log упрощает дальнейший анализ и интеграцию с auditd или Fail2ban. Для глубокого анализа логов используйте готовые команды grep и awk из статьи Практический анализ логов Nginx и Apache.

Какие паттерны в логах сигнализируют об атаке

После настройки детального лога вы увидите паттерны атак. Вот примеры строк из security.log и их интерпретация.

Сканирование уязвимостей выглядит как множество запросов от одного IP-адреса к различным потенциально опасным ресурсам с кодом 404.

17/May/2026:10:15:01 | 192.168.1.100 | GET | 404 | /phpmyadmin/ | Mozilla/5.0 | 0.002 | -
17/May/2026:10:15:02 | 192.168.1.100 | GET | 404 | /wp-login.php | Mozilla/5.0 | 0.001 | -
17/May/2026:10:15:03 | 192.168.1.100 | GET | 404 | /.env | Mozilla/5.0 | 0.001 | -
17/May/2026:10:15:04 | 192.168.1.100 | GET | 404 | /.git/HEAD | Mozilla/5.0 | 0.001 | -

Brute force на форму входа - это много POST запросов на один endpoint (/login) с чередованием кодов 200 (успешный вход) или 403 (неудачный).

17/May/2026:10:20:01 | 10.0.0.5 | POST | 403 | /login | python-requests/2.28.0 | 0.05 | -
17/May/2026:10:20:02 | 10.0.0.5 | POST | 403 | /login | python-requests/2.28.0 | 0.04 | -
17/May/2026:10:20:03 | 10.0.0.5 | POST | 200 | /login | python-requests/2.28.0 | 0.06 | -

Попытки выполнения команд через параметры URI также легко обнаружить.

17/May/2026:10:25:01 | 172.16.0.10 | GET | 200 | /index.php?cmd=whoami | curl/7.68.0 | 0.03 | -

Принцип Response Rate Limiting (RRL), используемый в Bind9 для защиты от DoS, аналогичен подходу для веб-серверов. Множество запросов в секунду от одного IP - индикатор атаки.

Интеграция логов Nginx в систему auditd

Централизованный сбор событий повышает эффективность мониторинга. Интеграция логов Nginx с auditd создает единый аудит-трейл.

Практическая настройка: от лога Nginx до записи в audit.log

Существует два основных способа отправки событий из логов Nginx в auditd.

Первый способ: использование утилиты logger через pipe в конфигурации Nginx. Добавьте в конфиг следующую директиву.

access_log /var/log/nginx/security.log security;
access_log pipe:logger -t nginx_audit security;

Это дублирует записи в файл и сразу отправляет их в системный лог через logger с тегом nginx_audit. Затем auditd или rsyslog могут отслеживать эти сообщения.

Второй способ: прямое правило auditd для отслеживания файла лога. Добавьте правило в файл /etc/audit/rules.d/audit.rules.

-w /var/log/nginx/security.log -p wa -k nginx_security

Это правило (-w) следит за файлом /var/log/nginx/security.log. Флаг -p wa означает отслеживание событий записи (w) и изменения атрибутов (a). Ключ -k nginx_security помечает события для удобного поиска.

После добавления правила активируйте его.

auditctl -w /var/log/nginx/security.log -p wa -k nginx_security
service auditd restart

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

ausearch -k nginx_security

Команда покажет все события, помеченные ключом nginx_security.

Централизация: отправка аудит-событий в SIEM

Для продвинутого мониторинга события auditd можно отправлять в SIEM системы, такие как ELK или Splunk. Используйте плагины audisp.

Настройте плагин audisp-syslog для отправки событий в локальный syslog. Затем конфигурируйте rsyslog или syslog-ng для пересылки сообщений с ключом nginx_security на удаленный сервер SIEM. Это превращает события Nginx в часть общего корпоративного аудит-трейла.

Для комплексной защиты веб-приложений с динамическим контентом дополнительно используйте рекомендации из статьи Защита приложений с динамическим контентом.

Автоматическое реагирование на угрозы

Мониторинг должен приводить к действию. Интеграция с Fail2ban автоматизирует блокировку атакующих IP на основе анализа логов.

Настраиваем Fail2ban для блокировки атакующих IP

Создайте фильтр для Fail2ban, который анализирует security.log. Файл разместите в /etc/fail2ban/filter.d/nginx-auth.conf.

[Definition]
failregex = ^\S+ \|  \| POST \| (403|200) \| /login \| .*$
ignoreregex =

Это регулярное выражение (failregex) найдет POST запросы к /login от определенного IP (), которые завершились кодом 403 (неудачный вход) или 200 (успешный вход после множества попыток).

Теперь создайте jail в /etc/fail2ban/jail.local или добавьте в jail.d.

[nginx-auth]
enabled = true
port = http,https
filter = nginx-auth
logpath = /var/log/nginx/security.log
maxretry = 5
findtime = 600
bantime = 3600

Параметры означают:

  • maxretry = 5: 5 нарушений за период findtime приводят к блокировке.
  • findtime = 600: период анализа - 600 секунд (10 минут).
  • bantime = 3600: время блокировки IP - 3600 секунд (1 час).

Проверьте фильтр перед применением.

fail2ban-regex /var/log/nginx/security.log /etc/fail2ban/filter.d/nginx-auth.conf

Перезапустите Fail2ban.

systemctl restart fail2ban

Для защиты от DDoS на уровне приложения также настройте rate limiting в Nginx, аналогично RRL в Bind9. Добавьте в http секцию nginx.conf.

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

И применяйте лимит в location.

limit_req zone=one burst=20 nodelay;

Это ограничивает количество запросов от одного IP до 10 в секунду. Для детальной настройки защиты от DDoS используйте готовые конфигурации из статьи Пошаговая защита веб-сервера от DDoS.

Проверка работоспособности и поддержка конфигурации

После внедрения проверьте работоспособность системы. Используйте этот чек-лист.

  1. Проверьте синтаксис конфигурации Nginx.
    nginx -t
  2. Проверьте активные правила auditd.
    auditctl -l
  3. Сделайте тестовый запрос, который должен попасть в лог и аудит. Например, запрос к несуществующему админ-пути.
    curl http://your-server/wp-admin/
  4. Убедитесь, что событие появилось в логе Nginx.
    tail -f /var/log/nginx/security.log
  5. Найдите это событие в audit.log.
    ausearch -k nginx_security | tail -5

Инструкции актуальны для следующих версий ПО:

  • Nginx 1.18+
  • auditd 2.8+
  • ОС: RHEL/CentOS 7+, Ubuntu 18.04+ и аналогичные дистрибутивы.

Пути к файлам конфигурации могут отличаться в зависимости от дистрибутива. Например, в Debian правила auditd часто находятся в /etc/audit/audit.rules. Адаптируйте команды под свою систему.

Для комплексного аудита безопасности всей системы Linux используйте рекомендации из руководства Безопасность Linux-сервера. Для полноценного мониторинга метрик Nginx подключите Prometheus и Grafana по инструкции из статьи Nginx: практический мониторинг.

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

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