📝 Логи веб-серверов: где искать следы хакеров?
Когда речь заходит о расследовании атак, многие сразу вспоминают EDR, SIEM или сетевые дампы. Но один из самых ценных источников информации зачастую лежит буквально на поверхности — логи веб-сервера. Коллеги, признавайтесь, как часто вы реально разбираете access.log? 🤔
Каждый 🌐 HTTP-запрос оставляет след. И если научиться читать эти следы, можно обнаружить атаку еще до того, как она приведет к компрометации. Коллеги из BI.ZONE выпустили очередную техническую статью, где на практических примерах разбирают анализ логов nginx и IIS, показывают, как выглядят распространенные техники злоумышленников 👹 и на какие поля логов стоит обращать внимание в первую очередь. Материал подойдет всем, кто хочет увереннее работать с журналами веб-серверов.
Что стоит искать в первую очередь?
⏺Path Traversal — попытки получить доступ к файлам за пределами веб-каталога (../, URL-кодированные варианты и т. п.). Обращения к /.git, /.env, /admin — автоматические сканеры ищут, что бы слить или куда зайти.
⏺Фаззинг — большое количество запросов к различным URL с целью поиска скрытых страниц, API или уязвимостей.
⏺Подозрительные User-Agent — автоматизированные сканеры, утилиты или вовсе пустые значения.
⏺Всплески ошибок 404/403/500 — часто сопровождают разведку и подбор путей.
⏺Необычные HTTP-методы (PUT, DELETE, TRACE и др.), если они не используются вашим приложением.
⏺Повторяющиеся запросы с одного IP, аномальные параметры URL, длинные строки запроса и признаки инъекций.
Инструменты первичной аналитики (без тяжелого софта).
Когда под рукой только консоль и нет SIEM 👨💻 или времени ждать, пока отрисуются дашборды в SIEM, на помощь приходят классические bash-утилиты:
— трассируем конкретного нарушителя.
— находим самые "шумные" IP-адреса (привет, ботнеты и сканеры).
— смотрим, какие точки атакуют чаще всего.
— Позволяет быстро выбрать из лога все события с кодами ошибок: серверными (500, 502, 503, 504) и клиентскими (404).
Важно понимать, что каждый отдельный запрос может выглядеть безобидно. Но если смотреть на картину целиком 🔎 - последовательность действий, частоту запросов, коды ответов и поведение клиента — становится заметен сценарий атаки.
Именно поэтому анализ веб-логов остается одной из базовых ✍️ компетенций аналитика SOC. Это не только помогает расследовать уже произошедшие инциденты, но и позволяет своевременно обнаружить разведку, сканирование и первые этапы атаки.
💬 Веб-логи — это идеальный инструмент для ретроспективного анализа и расследования. Но не стоит пытаться использовать их как основной механизм блокировки атак в реальном времени. Для фильтрации SQLi, XSS и др. на лету нужен WAF. Логи помогают понять, что произошло, а WAF — не дать этому произойти.
📖 InfoSec Context
Когда речь заходит о расследовании атак, многие сразу вспоминают EDR, SIEM или сетевые дампы. Но один из самых ценных источников информации зачастую лежит буквально на поверхности — логи веб-сервера. Коллеги, признавайтесь, как часто вы реально разбираете access.log? 🤔
Каждый 🌐 HTTP-запрос оставляет след. И если научиться читать эти следы, можно обнаружить атаку еще до того, как она приведет к компрометации. Коллеги из BI.ZONE выпустили очередную техническую статью, где на практических примерах разбирают анализ логов nginx и IIS, показывают, как выглядят распространенные техники злоумышленников 👹 и на какие поля логов стоит обращать внимание в первую очередь. Материал подойдет всем, кто хочет увереннее работать с журналами веб-серверов.
Что стоит искать в первую очередь?
⏺Path Traversal — попытки получить доступ к файлам за пределами веб-каталога (../, URL-кодированные варианты и т. п.). Обращения к /.git, /.env, /admin — автоматические сканеры ищут, что бы слить или куда зайти.
⏺Фаззинг — большое количество запросов к различным URL с целью поиска скрытых страниц, API или уязвимостей.
⏺Подозрительные User-Agent — автоматизированные сканеры, утилиты или вовсе пустые значения.
⏺Всплески ошибок 404/403/500 — часто сопровождают разведку и подбор путей.
⏺Необычные HTTP-методы (PUT, DELETE, TRACE и др.), если они не используются вашим приложением.
⏺Повторяющиеся запросы с одного IP, аномальные параметры URL, длинные строки запроса и признаки инъекций.
Инструменты первичной аналитики (без тяжелого софта).
Когда под рукой только консоль и нет SIEM 👨💻 или времени ждать, пока отрисуются дашборды в SIEM, на помощь приходят классические bash-утилиты:
grep "IP_злодея" access.log
— трассируем конкретного нарушителя.
awk '{print $1}' access.log | sort | uniq -c | sort -nr
— находим самые "шумные" IP-адреса (привет, ботнеты и сканеры).
cut -d '"' -f 2 access.log | sort | uniq -c | sort -nr
— смотрим, какие точки атакуют чаще всего.
grep -E "500|502|503|504|404" access.log
— Позволяет быстро выбрать из лога все события с кодами ошибок: серверными (500, 502, 503, 504) и клиентскими (404).
Важно понимать, что каждый отдельный запрос может выглядеть безобидно. Но если смотреть на картину целиком 🔎 - последовательность действий, частоту запросов, коды ответов и поведение клиента — становится заметен сценарий атаки.
Именно поэтому анализ веб-логов остается одной из базовых ✍️ компетенций аналитика SOC. Это не только помогает расследовать уже произошедшие инциденты, но и позволяет своевременно обнаружить разведку, сканирование и первые этапы атаки.
💬 Веб-логи — это идеальный инструмент для ретроспективного анализа и расследования. Но не стоит пытаться использовать их как основной механизм блокировки атак в реальном времени. Для фильтрации SQLi, XSS и др. на лету нужен WAF. Логи помогают понять, что произошло, а WAF — не дать этому произойти.
📖 InfoSec Context