Перейти к содержанию

Работа с логами WAF‑ноды

Расположение лог‑файлов WAF‑ноды

WAF‑нода хранит следующие лог‑файлы в директории /var/log/wallarm:

  • brute-detect.log: логи получения данных по счетчикам bruteforce-атак в кластере WAF‑нод.

  • export-attacks.log: лог экспорта информации об атаках из модуля постаналитики в облако Вебмониторэкс.

  • export-counters.log: лог выгрузки данных счетчиков (см. «Мониторинг WAF‑ноды»).

  • export-environment.log: лог сбора и выгрузки в Вычислительный кластер Вебмониторэкс информации о версиях установленных пакетов ноды. Версии пакетов, выгруженные в Вычислительный кластер, отображаются в информации о ноде в Консоли управления Вебмониторэкс. Скрипт для сбора и выгрузки версий запускается один раз в час.

  • syncnode.log: лог синхронизации WAF‑ноды с облаком Вебмониторэкс (включая получение файлов индивидуального набора правил и proton.db из облака).

  • tarantool.log: лог работы модуля постаналитики.

  • sync-ip-lists.log (в предыдущих версиях ноды — sync-blacklist.log): лог синхронизации WAF‑ноды и IP‑адресов, которые были добавлены в списки IP‑адресов как одиночные объекты или подсети.

  • sync-ip-lists-source.log (в предыдущих версиях ноды — sync-mmdb.log): лог синхронизации WAF‑ноды и IP‑адресов, которые зарегистрированы в странах, регионах или дата-центрах, добавленных в списки IP‑адресов.

  • appstructure.log (только в Docker‑контейнере): лог модуля Структура API.

  • registernode_loop.log (только в Docker‑контейнере): лог wrapper‑скрипта, который перезапускает скрипт register-node до успешного выполнения.

    В образа Вебмониторэкс 4.0 и ниже, файл называется addnode_loop.log.

  • weak-jwt-detect.log: лог обнаружения уязвимостей JWT.

Настройка расширенного логирования для WAF‑ноды на основе NGINX

NGINX записывает логи обработанных запросов (англ. «access logs») в отдельный лог‑файл.

По умолчанию NGINX использует предопределенный формат логирования combined:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $request_id $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" ';

Вы можете определить и использовать собственный формат логирования, включив в него одну или несколько переменных WAF‑ноды (а также другие переменные NGINX, если это необходимо). Это позволит проводить более быструю диагностику состояния WAF‑ноды, основываясь на содержимом лог‑файла NGINX.

Переменные WAF‑ноды

При определении формата логирования NGINX могут быть использованы следующие переменные WAF‑ноды:

Имя Тип Значение
request_id Строка Идентификатор запроса
Имеет значение вида a79199bcea606040cc79f913325401fb
wallarm_request_cpu_time
(в версии 3.6 и ниже — wallarm_request_time)
Число с плавающей точкой Время, потраченное CPU машины с фильтрующей нодой на выполнение запроса. Единица измерения – секунды.
wallarm_request_mono_time Число с плавающей точкой Время, равное сумме показателей:
  • Время ожидания в очереди на выполнение
  • Время, потраченное CPU машины с фильтрующей нодой на выполнение запроса
Единица измерения – секунды.

Например, если запрос находился в очереди 3 секунды, затем CPU выполнял его 1 секунду, то:
  • "wallarm_request_cpu_time":1
  • "wallarm_request_mono_time":4
wallarm_serialized_size Целое число Размер сериализованного запроса в байтах
wallarm_is_input_valid Целое число Валидность запроса
0: запрос валиден. Запрос проверен WAF‑нодой и соответствует индивидуальным наборам правил.
1: запрос невалиден. Запрос проверен WAF‑нодой и не соответствует индивидуальным наборам правил.
wallarm_attack_type_list Строка Типы атак, обнаруженных в запросе с помощью библиотеки libproton. Типы представлены в текстовом формате:
  • xss
  • sqli
  • rce
  • xxe
  • ptrav
  • crlf
  • redir
  • nosqli
  • infoleak
  • overlimit_res
  • data_bomb
  • vpatch
  • ldapi
  • scanner
  • ssi
  • mail_injection
  • ssti
  • invalid_xml
Если в запросе обнаружено несколько типов атак, они будут перечислены через символ |. Например: если в запросе обнаружены атаки типа XSS и SQLi, значение переменной равно xss|sqli.
wallarm_attack_type Целое число Типы атак, обнаруженных в запросе с помощью библиотеки libproton. Типы представлены в виде битовой строки:
  • 0x00000000: отсутствие атаки: "0"
  • 0x00000002: xss: "2"
  • 0x00000004: sqli: "4"
  • 0x00000008: rce: "8"
  • 0x00000010: xxe: "16"
  • 0x00000020: ptrav: "32"
  • 0x00000040: crlf: "64"
  • 0x00000080: redir: "128"
  • 0x00000100: nosqli: "256"
  • 0x00000200: infoleak: "512"
  • 0x20000000: overlimit_res: "536870912"
  • 0x40000000: data_bomb: "1073741824"
  • 0x80000000: vpatch: "2147483648"
  • 0x00002000: ldapi: "8192"
  • 0x4000: scanner: "16384"
  • 0x02000000: ssi: "33554432"
  • 0x04000000: mail_injection: "67108864"
  • 0x08000000: ssti: "134217728"
  • 0x10000000: invalid_xml: "268435456"
Если в запросе обнаружено несколько типов атак, значения суммируются. Например: если в запросе обнаружены атаки типа XSS и SQLi, значение переменной равно 6.
wallarm_application Положительное целое число или пустая строка Уникальный идентификатор для обозначения защищенного приложения в Вычислительном кластере Вебмониторэкс.
wallarm_partner_client_uuid Строка Uuid или пустая строка Уникальный идентификатор тенанта для ноды Вебмониторэкс с мультиарендной опцией.

Пример настройки

Пусть необходимо задать расширенный формат логирования с именем wallarm_combined, включающий в себя:

  • все переменные, используемые в формате combined;

  • все переменные WAF‑ноды.

Чтобы это сделать, выполните следующие действия:

  1. Добавьте в блок http файла конфигурации NGINX следующие строки, описывающие формат логирования:

    log_format wallarm_combined '$remote_addr - $remote_user [$time_local] '
                                '"$request" $request_id $status $body_bytes_sent '
                                '"$http_referer" "$http_user_agent" '
                                '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list';
    
  2. Включите логирование в расширенном формате, добавив в тот же блок директиву:

    access_log /var/log/nginx/access.log wallarm_combined;

    Логи обработанных запросов будут записываться в формате wallarm_combined в файл /var/log/nginx/access.log.

    Логирование по условию

    При использовании директивы, приведенной выше, в лог‑файл попадут данные по всем обработанным запросам. В том числе данные, которые не относятся к какой-либо атаке.

    Вы можете настроить логирование по условию, чтобы в лог‑файл попадала информация только по тем запросам, которые относятся к атаке (т.е. по запросам, для которых значение wallarm_attack_type не равно нулю). Для этого добавьте к директиве следующее условие:

    `access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;`
    

    Это может быть полезно для сокращения объема лог‑файла и для интеграции WAF‑ноды с SIEM‑системами.

  3. Перезапустите NGINX, выполнив одну из следующих команд в зависимости от используемой операционной системы:

    sudo systemctl restart nginx
    
    sudo service nginx restart
    
    sudo systemctl restart nginx
    
    sudo systemctl restart nginx
    

Дополнительная информация

Подробная информация о настройке логирования в NGINX доступна здесь.