Сообщение FortiWeb об атаке часто воспринимают как готовый вердикт: злоумышленник найден, запрос заблокирован, приложение защищено. Но одна строка отвечает только на часть вопросов. Она показывает, какой трафик нарушил политику WAF, какое действие выполнило устройство. Чтобы понять ход атаки и последствия, аналитик должен собрать временную линию из нескольких записей.
Для лучшего понимания особенностей этого процесса нужно рассмотреть условный инцидент с Интернет-магазином. Адреса и идентификаторы обезличены, а состав полей может отличаться в зависимости от версии и настроек FortiWeb.
Три вида журналов – три части картины
FortiWeb разделяет сообщения на event, attack и traffic:
- Attack log фиксирует трафик, нарушивший примененную политику.
- Traffic log показывает обработанные запросы, включая разрешенные и заблокированные.
- Event log содержит системные и административные события, например, вход администратора или изменение конфигурации.
Attack log объясняет решение WAF, traffic log помогает проверить результат и HTTP-код, event log – изменения защиты. Такое разделение приведено в FortiWeb Log Reference 8.0.1.
Расследование нельзя ограничивать FortiWeb. Если WAF работал в режиме наблюдения или пропустил запрос, то понадобятся журналы приложения, веб-сервера, базы данных и системы аутентификации. Только они покажут, выполнило приложение нежелательную операцию или нет.
Первый этап: признаки разведки
Сначала источник обычно проверяет URL, методы и ответы приложения. В журналах видны обращения к несуществующим страницам, административным путям и API. Дополнительные признаки — много ошибок 404, короткие интервалы и последовательный перебор адресов.
FortiWeb фиксирует нарушения URL Access, Protected Hostnames, HTTP Protocol Constraints, Custom Access и bot-политик. В рассматриваемом сценарии один src обращается к десяткам путей одного http_host: часть запросов формирует traffic-записи, часть – attack-события.
Сканирование не доказывает взлом, но в сочетании со срабатыванием сигнатуры указывает на возможную цепочку атаки. Тут http_agent ненадежен: User-Agent легко подделать.
Как выглядит ключевая запись
Следующее событие – учебный пример, составленный по структуре FortiWeb. Опасное содержимое параметра удалено:
date=2026-08-13 time=14:32:18 type=attack pri=alert
main_type="Signature Detection" sub_type="SQL Injection"
severity_level=High action=Alert_Deny policy="web-prod"
src=203.0.113.42 src_port=51874 dst=10.20.0.15 dst_port=443
http_method=post http_url="/api/orders/search"
http_host="shop.example.ru" http_session_id="<session-id>"
msg="Parameter (query) triggered signature"
signature_id="<signature-id>" threat_level=<level>
Согласно справочнику Fortinet, attack-запись означает, что трафик нарушил подходящую политику. Но она не доказывает успешный взлом.
date, time и часовой пояс задают точку на временной линии, поэтому часы связанных систем синхронизируют. log_id классифицирует причину сообщения, а уникальный msg_id обозначает конкретную запись.
src и src_port показывают источник, dst и dst_port – назначение. Но перед FortiWeb могут находиться CDN или прокси. При неправильной обработке клиентского IP журнал приведет к промежуточному узлу.
Поля http_method, http_url и http_host показывают, куда направлен запрос. В документации уточняется, что http_url содержит исходный URL клиента без схемы и имени хоста. При переписывании URL это вариант до преобразования. policy связывает событие с серверной политикой.
main_type="Signature Detection" указывает на сигнатурный механизм, sub_type – на класс нарушения, а signature_id – на сработавшее правило. Среди категорий есть SQL Injection, Cross Site Scripting и Known Exploits.
Запрос заблокирован или только записан
Первым проверяется action. Alert_Deny означает, что FortiWeb зарегистрировал нарушение и отклонил трафик. При Alert запрос мог пройти дальше. Результат зависит также от режима развертывания, Monitor Mode, исключений и настроек правила.
Нельзя считать событие критическим из-за pri=alert. В FortiWeb у всех attack-логов этот приоритет. Опасность оценивается по severity_level, типу атаки, ресурсу, действию и контексту. Причем severity_level задается администратором в правиле или политике, а не доказывает успешность атаки.
Затем ищут связанный traffic-лог по времени, адресам, URL и сессии. При блокирующем действии проверяют HTTP-ответ и отсутствие обращения к backend. Если запрос прошел, то нужно определить по журналам приложения, как он был обработан.
Как отдельные строки становятся инцидентом
Затем источник повторяет запрос с измененным параметром, обращается к соседнему API и вызывает срабатывание Cross Site Scripting. Позже FortiWeb фиксирует блокировку клиента или нарушение IP Reputation. Это уже последовательность действий, а не случайная ошибка.
Для корреляции используется src, http_session_id, dev_id, http_host, URL и близкое время. Ни один признак не универсален, поэтому вывод делается по их совокупности.
В логах новых версий могут присутствовать threat_weight, накопленный history_threat_weight, threat_level, оценка клиента и категория OWASP Top 10. Они помогают расставлять приоритеты, но зависят от версии и настроек, поэтому не заменяют расследование.
FortiWeb также агрегирует некоторые повторяющиеся события, чтобы не переполнять журнал. В версии 8.0.1 периодически объединяются, в частности, сообщения о DoS и нарушениях ограничений HTTP/HTTPS. Поэтому одна строка не всегда соответствует одному запросу. Масштаб оценивается по счетчикам и traffic-логам.
Реальная атака или ложное срабатывание
Сначала выясняется, какой параметр вызвал сигнатуру и встречается он у обычных пользователей или нет. Затем проверяется backend и история источника. Ложное срабатывание вероятнее, если запрос создается штатной функцией без аномалий на сервере.
Вероятность атаки возрастает, если событию предшествовал перебор URL, клиент менял подозрительный параметр, обращался к несвязанным служебным путям и продолжил делать попытки после блокировки. Но даже в таком случае нужно разделять попытку эксплуатации и успешную компрометацию.
Нельзя создавать широкое исключение для сигнатуры только из-за жалобы на недоступность страницы. Сначала исключение ограничивается определенным хостом, URL и параметром, оценивается риск и повторяется проверка. Иначе тот же класс атак незаметно откроется на других страницах.
Инцидент в FortiWeb выглядит не как одна красная строка, а как последовательность. Сначала появляются признаки разведки, затем attack-лог с типом нарушения и действием WAF, после него – повторные попытки или блокировка клиента. Анализ связывает эти события с traffic-логами и журналами приложения.
Начинать нужно с времени, main_type, sub_type, action, policy, src, метода, URL, сессии и сигнатуры. Затем следует проверить, дошел запрос до backend, спровоцировал изменения или нет. Такой подход позволяет отличить попытку атаки от успешного взлома. Он дает возможность отделять ложное срабатывание, не пропустить инцидент, который действительно требует реагирования.