«Сбор логов HTTP-запросов — это не просто техническая рутина, а создание системы доказательств. Она должна быть готова ответить на три вопроса: что произошло, когда и кто виноват. Без детализированных URL-журналов расследование инцидента превращается в гадание, а соответствие регуляторным требованиям — в формальность.»
Зачем собирать URL логи
Каждый HTTP-запрос к веб-ресурсу оставляет цифровой след. Журналы URL-запросов фиксируют этот след: метод, путь, параметры, заголовки, статус ответа и время обработки. Эта информация — не просто данные для отчётов, а основа для поведенческого анализа, обнаружения аномалий и реконструкции событий при расследовании.
Первым делом определяют цели сбора. Для мониторинга доступности достаточно минимального набора: статус ответа и время. Расследование инцидентов требует полной детализации: исходный URI со всеми параметрами, заголовки User-Agent и Referer, IP-адрес источника и точная метка времени. Если речь идёт о соответствии требованиям, например, 152-ФЗ или приказам ФСТЭК, добавляются обязательства по срокам хранения и обеспечению неизменности журналов.
Отдельный и часто упускаемый из виду аспект — обработка персональных данных. Параметры запроса могут содержать идентификаторы, токены сессий, email-адреса или даже фрагменты поисковых запросов. Сбор таких данных без должного обоснования и защиты создаёт риски. Поэтому применяется фильтрация или маскирование чувствительной информации ещё на этапе генерации логов или их первичной обработки.
Источники URL логов в веб-инфраструктуре
HTTP-запросы фиксируются на разных уровнях инфраструктуры, и каждый источник даёт свой взгляд на событие.
| Источник | Формат логов | Особенности сбора |
|---|---|---|
| Nginx access.log | Combined или кастомный формат, доступ к переменным вроде $request_uri, $args, $http_* | Ротация через logrotate, настройка буферизации (buffer, flush) для снижения нагрузки на диск. |
| Apache access_log | Common/Combined Log Format, директивы CustomLog с %U, %q, %a | Модуль mod_log_config для кастомизации, возможность отправки логов через pipe в внешнюю программу. |
| Логи приложения | Структурированный формат (JSON), логи из middleware фреймворков | Дают контекст бизнес-логики (ID пользователя, действие), но увеличивают нагрузку на само приложение. |
| Прокси и WAF | CEF, LEEF или вендорские форматы с полями rule_id, action, verdict | Содержат не только факт запроса, но и результат его проверки правилами безопасности. |
| CDN и edge-сети | JSON через Real-time Logging, CSV-экспорт, API для выгрузки | Логи генерируются на периферии сети, что требует их агрегации из множества географически распределённых точек. |
Настройка логирования на веб-серверах
Правильная конфигурация источника — залог того, что в логах окажутся нужные данные, а не шум. Используются кастомные форматы, включающие необходимые для анализа поля.
Конфигурация Nginx для детального логирования
log_format url_detailed '$remote_addr - $remote_user [$time_local] '
'"$request_method $request_uri $server_protocol" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" rt=$request_time '
'upstream=$upstream_addr args=$args';
access_log /var/log/nginx/access_url.log url_detailed buffer=32k flush=5s;
# Исключение статических ресурсов для снижения объёма
location ~* .(jpg|jpeg|png|css|js|ico)$ {
access_log off;
expires 30d;
}Параметры buffer и flush снижают нагрузку на ввод-вывод за счёт группировки записей. Отключение логирования для статики (картинки, стили, скрипты) может сократить общий объём логов на две трети, не влияя на безопасность.
Фильтрация чувствительных данных на уровне сервера
Параметры запросов — частая цель для злоумышленников, но и в них же могут передаваться токены, пароли или иные персональные данные. Маскировать их лучше сразу, в момент логирования.
# Nginx: использование map для маскирования параметров
map $args $masked_args {
default $args;
"~*password=[^&]*" "password=***";
"~*token=[^&]*" "token=***";
"~*session_id=[^&]*" "session_id=***";
}
log_format secure '$remote_addr "$request_method $request_uri?$masked_args" $status';Альтернативный подход — нормализация и очистка на стороне агрегатора логов (например, с помощью grok-паттернов в Logstash или скриптов на Lua). Это даёт больше гибкости, но оставляет чувствительные данные в исходном лог-файле на сервере.
Транспортировка логов в централизованное хранилище
Локальные файлы логов уязвимы: при компрометации сервера их можно удалить или подменить. Доставка в удалённое хранилище в реальном времени с гарантиями — обязательный этап.
| Метод доставки | Преимущества | Ограничения | Сценарий применения |
|---|---|---|---|
| Syslog (TCP/TLS) | Стандартный протокол, поддержка в rsyslog/syslog-ng, относительно прост | Без дополнительных настроек может не гарантировать доставку, требует инфраструктуры сервера | Стабильные внутренние сети для инфраструктурных сервисов |
| Агенты (Filebeat, Fluentd) | Буферизация на диске при потере связи, автоматические повторы, шифрование TLS | Дополнительный софт на каждом хосте, потребляет CPU и память | Распределённые среды с высокими требованиями к надёжности доставки |
| Отправка по HTTP API | Гибкость формата, встроенные механизмы аутентификации (OAuth, ключи) | Зависит от доступности конечной точки, накладные расходы протокола HTTP | Интеграция с облачными платформами или SaaS-решениями для анализа |
| Очереди сообщений (Kafka) | Высокая пропускная способность, возможность повторной обработки потока | Высокая сложность развёртывания и поддержки собственного кластера | Высоконагруженные платформы, где лог — это поток событий для многих систем |
Для защиты целостности данных в пути используется TLS с взаимной проверкой сертификатов. В критичных сценариях можно добавить криптографическую подпись каждого пакета логов на стороне отправителя, чтобы исключить возможность подмены в процессе транспортировки.
Нормализация и обогащение событий
Сырые логи из разных источников имеют разный формат и структуру. Нормализация превращает их в единообразные события, пригодные для автоматического анализа.
Структура нормализованного события
{
"timestamp": "2026-02-27T14:23:01.234Z",
"source": {
"ip": "192.168.1.100",
"geo": {"country":"RU","city":"Moscow"},
"asn": "AS12345"
},
"http": {
"method": "GET",
"path": "/api/users",
"query_params": {"id":"123"},
"headers": {
"user_agent": "Mozilla/5.0...",
"referer": "https://example.com"
},
"status": 200,
"response_size": 1024,
"duration_ms": 45
},
"security": {
"waf_action": "allow",
"rule_ids": [],
"risk_score": 0.1
},
"context": {
"user_id": "usr_abc123",
"session_id": "sess_xyz789",
"app_version": "2.4.1"
}
}Обогащение контекстом
Обогащение превращает голый факт запроса в осмысленное событие.
- GeoIP по IP-адресу: помогает сразу отсечь запросы из географически невозможных или нехарактерных локаций.
- ASN и провайдер: трафик с IP-адресов, принадлежащих хостинг-провайдерам или VPN-сервисам, часто требует повышенного внимания.
- Корреляция с IAM: привязка HTTP-запроса к конкретной учётной записи — основа для построения поведенческих профилей (UEBA).
- Классификация URL: маркировка путей (например, «админ-панель», «API оплаты», «скачивание отчёта») позволяет анализировать активность по смысловым группам.
Обогащение выполняется в потоке обработки с использованием локальных баз данных (например, MaxMind) или запросов к внешним API. Критически важно кэшировать результаты таких запросов, чтобы не создавать задержек и не перегружать внешние системы.
Анализ для обнаружения угроз
Подготовленные данные позволяют перейти от реактивного просмотра логов к проактивному обнаружению аномалий.
| Сценарий угрозы | Индикаторы в URL логах | Пример логики детектирования |
|---|---|---|
| Разведка (Web scanning) | Множественные ответы 404/403 на разные, часто несуществующие пути, короткие интервалы между запросами. | Более 50 запросов со статусом 404 за минуту с одного IP из определённых ASN (хостинг). |
| Инъекции (SQL/NoSQL) | Параметры запроса, содержащие ключевые слова UNION, SELECT, кавычки, точки с запятой, закодированные полезные нагрузки. | Наличие в параметрах паттернов, характерных для инъекций, особенно к критичным endpoint (логин, поиск). |
| Обход путей (Path traversal) | Последовательности «../» или их URL-кодированные варианты (%2e%2e%2f) в пути запроса. | Попытка доступа к путям, содержащим шаблоны системных директорий (/etc/, /proc/). |
| Перебор учётных записей | Последовательные запросы к endpoint логина или профиля с изменяющимся параметром (user_id, email). | Более 10 уникальных значений параметра user_id/email за короткий период с одного IP или сессии. |
| Утечка данных | Запросы к API экспорта или выгрузки, сопровождающиеся аномально большим объёмом отдаваемых данных. | Загрузка файлов размером >10 МБ через endpoint, который обычно используется для небольших операций. |
Чтобы снизить количество ложных срабатываний, правила дополняют контекстом: исключают IP-адреса легитимных сканеров безопасности, учитывают рабочие часы для внутренних пользователей, добавляют whitelist для известных легитимных паттернов.
Хранение и ротация журналов
Объём логов веб-трафика может расти экспоненциально. Многоуровневая стратегия хранения балансирует между стоимостью, скоростью доступа и требованиями регуляторов.
| Уровень | Срок хранения | Характеристики | Назначение |
|---|---|---|---|
| Горячий (Hot) | 1–7 дней | Быстрые SSD-диски, полная индексация, репликация для отказоустойчивости. | Активный мониторинг, расследование свежих инцидентов, работа SIEM в реальном времени. |
| Тёплый (Warm) | 8–30 дней | Более ёмкие HDD, сжатие данных, индексация только по ключевым полям (timestamp, IP, статус). | Анализ трендов, еженедельные/ежемесячные отчёты, ретроспективные расследования. |
| Холодный (Cold) | 31–180+ дней | Объектное хранилище (S3-совместимое), архивные форматы (tar.gz, .zstd), высокая задержка доступа. | Долгосрочное хранение для выполнения регуляторных требований (например, 152-ФЗ), извлечение по запросу для аудита. |
Перемещение данных между уровнями автоматизируют с помощью политик управления жизненным циклом (ILM), доступных в современных системах хранения, или скриптов на основе времени и размера. Для архивного уровня эффективно используют алгоритмы сжатия вроде zstd, которые обеспечивают хорошее соотношение степени сжатия и скорости работы.
В итоге сбор журналов URL-запросов — это создание единой, достоверной хроники взаимодействия с веб-ресурсами. Успех зависит от баланса: между детализацией и объёмом, между скоростью и надёжностью доставки, между глубиной хранения и стоимостью инфраструктуры. Правильно выстроенная система работает незаметно, но в момент инцидента становится главным инструментом для ответа на вопрос «что случилось?».