Большинство разговоров о сетевой безопасности крутятся вокруг систем, которые стоят на пути трафика и должны принять решение здесь и сейчас: NGFW, WAF, IDS. Но есть и другой класс систем — те, что работают не с самим трафиком, а с его зеркальной копией, и потому могут анализировать происходящее сколько угодно долго. Эта статья — про то, что удаётся увидеть NTA/NDR-системам именно благодаря этому запасу времени: от восстановления цепочки атаки шифровальщика по сохранённым метаданным до обнаружения ботнета, для которого ещё не существовало сигнатуры.

Привет, Хабр! Меня зовут Кирилл Шипулин, я руководитель экспертизы PT NAD в Positive Technologies. Эта статья сделана из моего доклада на K2 Cloud Conf. Этот текст — «мост» между дисциплинами (безопасность и сеть), не чистое ИБ-чтение, а информация в основном про то, зачем сетевику или архитектору облака вообще думать про анализ трафика.

В центре рассказа две системы. NGFW, которые должны решить за миллисекунды, пропустить пакет или нет — у них нет времени на раздумья. И NTA/NDR-системы, что работают с копией трафика и могут анализировать его сколько угодно долго. Это не конкурирующие подходы, а системы с принципиально разными возможностями — и вторые обнаруживают то, что первые физически не успевают увидеть.

Фактически это разбор целого класса решений через кейсы, но начнём мы с того, причём здесь вообще облака.

Почему облака — ещё одна поверхность для анализа трафика

По составу облачная инфраструктура почти не отличается от привычного серверного сегмента компании. В облаке точно так же разворачивают почтовые серверы, базы данных, GitLab, а иногда и рабочие станции — просто в меньшем количестве, чем в офисной сети. Разница не в устройстве инфраструктуры, а в зрелости средств защиты вокруг неё.

Технологии информационной безопасности приходят в облака с задержкой относительно физических сетей. Просто потому, что и сама потребность в них там возникла позже. NGFW и WAF, которые давно стали нормой на периметре классической инфраструктуры, в облаках тоже уже прижились. А вот зеркалирование трафика — технология, без которой невозможна работа систем классов IDS, IPS и NTA/NDR, — появилась в K2 Cloud относительно недавно. Пока этой технологии не было, у облачных клиентов физически не было возможности развернуть у себя такие системы, даже если бы они этого захотели.

Есть и вторая причина, по которой облака заслуживают отдельного внимания с точки зрения анализа трафика: в них исключительно легко плодить инфраструктуру. Один инженер за час может создать полсотни виртуальных машин под конкретную задачу и так же легко забыть о части из них после того, как задача закрыта. Забытые машины продолжают существовать, их сервисы устаревают, начинается деградация — накапливаются уязвимости, о которых никто уже не думает, потому что формально о существовании этих машин никто и не помнит.

Оба фактора вместе — задержка защитных технологий и лёгкость бесконтрольного разрастания инфраструктуры — делают облако не менее, а местами более интересной средой для анализа трафика, чем классическая корпоративная сеть.

Попробовать облако на практике

Если вы как раз оцениваете перенос инфраструктуры в облако или хотите протестировать новые инструменты безопасности, сейчас это можно сделать с грантом в 30 000₽ от K2 Cloud на тестирование инфраструктуры: ссылка

Жертва в угоду скорости

Чтобы понять, зачем вообще нужен ещё один класс систем безопасности вдобавок к уже привычным NGFW, WAF и IDS, важно сначала разобраться в ограничении, которое есть у всех перечисленных систем и которое редко проговаривают вслух: у них физически нет времени думать.

Не то чтобы у NGFW и WAF вообще нет способностей к накоплению статистики, но у детектов очень мало времени на анализ, а на скоростях 100-200 Гбит любой сложный детект для NGFW оборачивается огромными объемами памяти. Кроме того, скользящее окно для поиска вредоносного контента у систем NGFW уже, поэтому даже привычные сигнатуры для обнаружения требуют адаптации под более быстрые и узкие проверки.

К тому же у NGFW почти нет опции для алертов. Сердце их движка безопасности — это модуль IPS, который либо блокирует трафик, либо пропускает его. Поэтому несмотря на то, что NGFW способен генерировать какие-то алерты операторам, в них почти никто не смотрит. Большинство относится к NGFW системам, как к "поставил и забыл". А сложившиеся мифы о том, что сигнатурные детекты генерируют много ложных алертов лишь вынуждает пользователей выключить их или никогда не обращать на них внимания. 

Системы, которые работают с отзеркалированной копией трафика — к этому классу относится и NTA/NDR (Network Traffic Analysis и Network Detection and Response), — устроены принципиально иначе.

Возможностей для анализа в них гораздо больше. Они работают на гораздо меньших объемах трафика (10-20 Гбит на инсталляцию), поэтому в них хорошо функционируют модули на основе ML, анализа поведения хостов и другие статистические, поведенческие и аномальные модули обнаружения. Эти модули не стоят на пути реального трафика, исследуют его дубликат, у них нет требования решать мгновенно. Они могут накапливать метаданные сессий за месяцы, хранить полные копии пакетов (pcap) для последующего разбора, сопоставлять события, разнесённые во времени на недели, и при необходимости даже эскалировать находку человеку — аналитику, который откроет сырые данные и разберётся, что произошло, без давления времени, которое есть у поточной системы.

Разница на практике выглядит так:

Это разграничение — не техническая деталь для энтузиастов, а ключ к пониманию всего, что будет дальше в этой статье. Каждый следующий кейс — конкретный пример того, что удалось увидеть именно благодаря запасу времени на анализ, которого нет ни у одной поточной системы защиты.

Кейс №1: расследование атаки шифровальщика

Один из самых показательных случаев в практике команды — это расследование атаки шифровальщика, которая уже произошла. Атака завершилась шифрованием, и всё это время система анализа трафика (в данном случае — NTA/NDR-решение PT NAD) фиксировала происходящее.

Парадокс успешной атаки легко объяснить: порой атаки бывают успешными, даже если средства защиты все вовремя обнаружили. С системой защиты работают операторы SOC, которые попросту могут о ней забыть или не знать как правильно с ней работать.

Подобные истории - все-таки редкость, но именно они подталкивают системы NTA/NDR к автоматическому или автоматизированному реагированию, к упрощению работы с ними и тем самым подобные истории - это редкое "реальное" испытание, которое невозможно смоделировать пентестами или редтим-проектами. 

Ценность этой истории не в том, что атаку удалось остановить, а в том, что её удалось полностью восстановить постфактум — шаг за шагом, опираясь исключительно на сохранённые метаданные и записи трафика. Ниже — шесть этапов атаки в том порядке, в котором они произошли, и отдельно для каждого — обнаруживается ли этот этап поточными системами защиты (NGFW, IDS, антивирус) или требует ретроспективного анализа.

Проникновение через SSH

Точный метод получения первого доступа установить сложно — это мог быть подбор пароля методом перебора, а мог быть и логин, полученный из утечки данных на стороне. Установленный факт один: цепочка началась со входа по SSH.

Обнаружение поточными системами: частично. Подбор пароля через brute force — не новая техника, и большинство современных средств защиты умеют находить и блокировать такие попытки по сигнатурам.

Разведка и сканирование сети

Получив доступ, злоумышленники начали осматриваться: сканировали внутреннюю сеть, перебирали типичные порты (445, 3389 — RDP), собирали дополнительные учётные данные и постепенно перемещались на соседние хосты. Этот этап растянулся на две недели — именно столько потребовалось, чтобы найти привилегированный доступ.

Обнаружение поточными системами: ненадёжно. Сканирование портов звучит как очевидная вещь для детектирования, но на практике алертинг на каждое соединение с несколькими портами приведет к массе ложных срабатываний — обычный фоновый шум внутренней сети (мониторинг, системное администрирование, служебные обращения) выглядит похоже. Чтобы надёжно отличить сканирование от штатной активности, нужна аналитика поверх накопленных метаданных, а не сигнатура.

Сбор дополнительных учётных записей

Здесь злоумышленники пробовали эксплуатировать уязвимости на доступных хостах — техники вроде NTLM-relay или использование известных уязвимостей. К тому же, системы NGFW редко анализируют трафик внутри сети.

Обнаружение поточными системами: ненадёжно. По той же причине, что и сканирование, — обнаружение ряда атак требует накопления аналитики, а не разовой сигнатуры IPS.

Перемещение в серверный сегмент

Получив достаточно высокие привилегии, злоумышленники быстро переместились туда, где хранились ценные данные — через стандартные механизмы удалённого выполнения команд: RDP, SSH, удалённое создание задач через SMB.

Обнаружение поточными системами: да, но с оговорками. Способов удалённого выполнения команд — ограниченное количество, и NGFW способен их отследить, но злоумышленники маскируются под легитимные средства и протоколы, что затрудняет их безошибочное обнаружение.

Эксфильтрация данных

На одном из серверов злоумышленники собрали архив объёмом порядка 50 гигабайт и постепенно, по 10 гигабайт за ночь, выгружали его на внешний FTP-сервер. Это стандартная тактика для атак типа double extortion, когда данные сначала похищают, а затем шифруют — чтобы у жертвы был дополнительный стимул заплатить, даже если резервные копии позволяют восстановить систему без расшифровки.

Обнаружение поточными системами: нет. Отличить архив с фотографиями с корпоратива от эксфильтрации корпоративных данных по одному пакету невозможно — нужен анализ аномального объёма трафика в нехарактерное время, а это снова требует ретроспективной аналитики, а не мгновенного решения.

Шифрование

Финальная стадия атаки произошла в 3 часа ночи в субботу — время, выбранное явно не случайно: в этот момент меньше всего шансов, что кто-то заметит происходящее и успеет вмешаться.

Обнаружение поточными системами: частично, но к этому моменту атака уже завершена.

Общий итог по всем этапам взлома и кейсу

Из шести этапов надёжно детектируются поточными системами защиты в лучшем случае два — а остальные требуют именно ретроспективного анализа накопленных

данных для точной аналитики без ложных срабатываний. 

И весь смысл этой истории в том, что цепочку с шестого шага (шифрование, о котором стало известно) до первого (вход по SSH две недели назад) удалось восстановить исключительно благодаря тому, что метаданные трафика и полные записи сессий (pcap) всё это время сохранялись. Без этого расследование постфактум было бы попросту невозможно — компания так и не узнала бы, как именно её взломали.

Кейс №2: обнаружение ботнета через аномалию в трафике

Если история с шифровальщиком показывает, как система анализа трафика помогает восстановить уже случившуюся атаку, то следующий кейс — про другую грань той же технологии: возможность найти то, для чего ещё не существует готовой сигнатуры.

Дело было в 2018–2019 году. Аналитик просто наблюдал за тем, какие запросы проходят во входящем трафике на один из серверов в DMZ-сегменте. Без конкретной задачи, без тревоги, без повода для расследования. В потоке HTTP-запросов обнаружился характерный паттерн: перебор множества различных URL, а в теле одного из запросов нашлась строка вида "hello" = "die(md5(Ch3ck1ng));". Формулировка не имела отношения ни к одной из известных на тот момент уязвимостей веб-приложений или роутеров — она выглядела так, будто её сгенерировал какой-то нестандартный инструмент.

Дальнейшее расследование заняло около полугода и привело к обнаружению крупного китайского ботнета, специализирующегося на заражении определённой конфигурации LAMP-серверов (Apache, MySQL, PHP, phpMyAdmin). Оказалось, что внутри самого ботнета шла конкурентная борьба, две группировки заражали одни и те же серверы, вытесняя друг друга.

Ключевой момент этой истории — методологический, а не сюжетный. Ботнет не был найден по сигнатуре, потому что сигнатуры для него попросту не существовало: ни один вендор ещё не описал эту угрозу, ни одна система защиты не знала, что искать. Находка стала возможна только потому, что у аналитика был доступ к сырым, необработанным данным трафика — и время, чтобы заметить в них что-то странное и довести наблюдение до полноценного расследования.

Это иллюстрирует разницу, о которой шла речь в предыдущем разделе, с неожиданной стороны. Системы анализа трафика полезны не только там, где готовая сигнатура уже существует, а система лишь ищет её совпадение с потоком данных. Они полезны и там, где сигнатуры ещё нет вообще — потому что аналитик работает не с готовым вердиктом «атака/не атака», а с исходными данными, в которых можно увидеть что-то, чего пока не увидел никто другой. По этому поводу есть целое исследование.

Инвентаризация сети через анализ трафика

Ещё одно применение систем анализа трафика редко приходит в голову первым — потому что традиционно инвентаризацией сетевых устройств занимаются совсем другие инструменты: сканеры активов, анализ логов, отдельные agent-based системы учёта. Но устройства в сети постоянно и неизбежно рассказывают о себе через сам трафик, который они генерируют, — и эти данные можно использовать напрямую.

Механика простая. Когда устройство получает IP-адрес по DHCP, оно передаёт своё имя хоста. При аутентификации в домене (NTLM) хост точно так же раскрывает своё сетевое имя, DNS-имя и имя учётной записи, от имени которой происходит вход. Протокол LDAP работает аналогично — тоже передаёт хостнейм устройства, обращающегося к каталогу. Вся эта информация, разбросанная по разным протоколам, вместе складывается в довольно точную карту сети.

Ценность этой возможности особенно заметна в крупной инфраструктуре. В сети из сотни и более компьютеров рано или поздно неизбежно теряется учёт части устройств — какая-нибудь машина остаётся в дальнем углу сегмента, о ней забывают, и она годами продолжает работать без контроля. Это не гипотетическая ситуация: в реальной практике встречаются серверы под управлением Windows 98, о существовании которых уже никто в компании не помнит. Анализ трафика позволяет найти такие устройства именно потому, что они продолжают «отстукиваться» — генерировать трафик, который выдаёт их присутствие, даже если формально они выпали из инвентарных списков.

Похожим образом можно обнаружить и постороннее устройство в сети: если к инфраструктуре подключается ноутбук из другой компании, при передаче собственного имени домена в трафике это становится заметно практически сразу.

Отдельный источник данных — DNS-запросы устройства. По списку доменов, к которым обращается конкретный хост, довольно точно восстанавливается его профиль: какое программное обеспечение на нём установлено и даже какого типа это устройство. Например, набор запросов доменных имен сервисов Google Play, Яндекс.Браузер и соцсетей сразу указывают, что это, вероятнее всего, устройство с Android, на котором установлен определённый набор приложений — большинство программ регулярно обращаются к собственным серверам обновлений, и по этим обращениям несложно восстановить, что вообще стоит на устройстве.

Самый нетривиальный источник данных для инвентаризации — протокол DCERPC, используемый для удалённого вызова процедур в инфраструктуре Windows. На первый взгляд это просто набор технических полей — десятки интерфейсов UUID, множество опкодов команд, разнообразные параметры вызовов, — за которыми сложно увидеть что-то практически полезное. Но у этого протокола есть неочевидное прикладное применение: он позволяет не просто зафиксировать факт попытки определенной атаки, но и определить, каким именно инструментом эта атака была проведена.

DCSync — классическая атака, при которой злоумышленник, получивший достаточно привилегированные учётные данные, притворяется контроллером домена и запрашивает синхронизацию доменной базы, чтобы получить пароли и хэши учётных записей — либо все сразу, либо выборочно. Три разных инструмента, реализующих эту атаку, генерируют технически разные последовательности вызовов DCERPC — то есть разные цепочки опкодов, даже если конечный результат атаки одинаков.

Анализируя эту последовательность, можно не только установить сам факт того, что происходящее не является легитимным поведением контроллера домена, а является атакой, но и определить, какой конкретно инструмент использовал злоумышленник, — деталь, которая обычно остаётся недоступной при поверхностном анализе трафика.

Анализ зашифрованного трафика: что можно узнать, не расшифровывая

Один из самых частых аргументов, который приходится слышать от заказчиков и коллег по цеху: «У нас всё шифруется, вы в этом трафике всё равно ничего не найдёте». Здесь есть доля правды — шифрование действительно скрывает содержимое соединения. Но скрытое содержимое не означает полное отсутствие полезной информации: даже не расшифровывая трафик, можно узнать значительную часть того, что происходит внутри сессии.

Работает это через технику, которая называется анализом побочного канала (side-channel analysis). Суть в том, что шифрование скрывает содержимое пакетов, но не их размер и не тайминг — а эти два параметра сами по себе оказываются достаточно информативными, чтобы восстановить характер происходящего внутри соединения.

Показательный пример — SSH-соединения. В начале установления сессии клиент и сервер обмениваются баннерами и параметрами в открытом виде — это можно увидеть в любом сетевом анализаторе вроде Wireshark ещё до начала шифрования. Дальнейшее содержимое сессии уже зашифровано, но за счёт исследования поведения разных SSH-клиентов и серверов удалось установить закономерность: успешная аутентификация по паролю и логину всегда оставляет пакеты фиксированного размера — 148 байт от клиента и 28 байт от сервера в случае успеха. Это справедливо независимо от длины самого пароля и имени пользователя — протокол специально спроектирован так, чтобы нельзя было по размеру пакета подобрать длину учётных данных.

Но это же свойство работает и в обратную сторону как инструмент анализа: зная эти фиксированные размеры, можно с уверенностью определить, что в конкретной сессии произошла именно аутентификация по паролю, и была ли она успешной. Практическая ценность очевидна: если SSH на периметре обычно используется по ключу, а в 3 часа ночи в субботу вдруг фиксируется успешный вход по паролю, — это весомый повод для тревоги, даже если содержимое сессии остаётся полностью зашифрованным. Аналогичным образом по паттернам пакетов можно определить число неудачных попыток входа, использование SCP для передачи файлов или факт проброса портов внутри SSH-туннеля.

Та же логика применима и к TLS-соединениям. Показательный пример — инструмент DogTunnel, применяемый для построения сетевых туннелей (в том числе для эксфильтрации данных). Установление соединения оставляет характерный след в 173 байта, а затем — heartbeat-пакеты по 60 байт каждые 10 секунд, которыми туннель подтверждает, что соединение ещё активно. Этот регулярный ритм легко отличим от обычного TLS-трафика веб-приложений.

Развивая эту идею дальше, тем же методом можно детектировать куда более широкий круг явлений — вплоть до выявления скрытых VPN-протоколов, даже если они специально спроектированы так, чтобы имитировать обычный HTTPS-трафик и не поддаваться анализу DPI (Deep Packet Inspection). Конкретный пример: используя анализ побочного канала, удалось находить серверы, работающие по современному протоколу VLESS/XRay, который в описаниях позиционируется как устойчивый к обнаружению системами глубокого анализа пакетов.

Здесь важен более общий вывод, который выходит за рамки конкретного протокола. Дело не в том, что у конкретного VPN-решения есть критическая уязвимость в реализации. Дело в том, что многие разработчики сетевых протоколов и инструментов недооценивают возможности анализа трафика в целом. Показательный пример из практики: разработчики Telegram однажды допустили ошибку в реализации протокола — перепутали служебный символ (поставили просто «20» вместо «%20»), — и эта деталь, оставшаяся незамеченной при разработке, впоследствии позволила системам.

DPI умеет надёжно отличать трафик Telegram от прочего HTTPS-трафика и блокировать его. Похожая логика применима и к авторам VPN-протоколов: заявления об «обходе DPI» часто основаны на теоретических предположениях о возможностях анализа, а не на практических возможностях систем анализа трафика.

Не только безопасность: прикладные IT-задачи

Обсуждение систем анализа трафика легко замыкается на теме атак и расследований, но их прикладная ценность заметно шире и касается не только команды безопасности, а любой IT-команды, которая эксплуатирует инфраструктуру.

В основе лежит простой факт: система, которая непрерывно обрабатывает десятки гигабит трафика и хранит накопленную аналитику, — это готовая база данных, по которой можно строить произвольные запросы, а не только искать признаки атак. Например, запрос вида «найти все HTTP-сессии длительностью больше секунды с кодом ответа 500» за секунды возвращает список проблемных обращений — код 500 почти всегда означает внутреннюю ошибку сервера. Такой запрос полезен не столько как разовая диагностика, сколько как основа для мониторинга: если обычно таких ошибок фиксируется около пятидесяти в час, а внезапно их число подскакивает до двух тысяч, — это чёткий сигнал аномалии, который можно отследить автоматически, без участия человека в каждом отдельном случае.

По тому же принципу — постоянный мониторинг метаданных, которые и так проходят через сеть, — можно закрывать сразу несколько практических задач:

1. Истекающие TLS-сертификаты. Практика показывает, что хотя бы раз в год в любой компании находится сертификат, срок действия которого истекает незаметно для команды, и его приходится экстренно чинить. TLS-трафик проходит через сеть постоянно, и заранее выявить приближающееся истечение сертификата — задача, которую можно решить чисто по данным трафика, не дожидаясь инцидента.

2. Несоответствие протокола заявленному порту. Например, ситуация, когда SSH фактически работает на порту 443, формально закреплённом за HTTPS. Такие расхождения часто нарушают внутренние политики компании — особенно это актуально для организаций с жёсткими требованиями к сетевой безопасности, включая государственный сектор.

3. Пароли, передаваемые в открытом виде. Анализ трафика позволяет не только зафиксировать сам факт передачи пароля без шифрования, но и пойти дальше — например, попытаться подобрать пароль по перехваченному хэшу NTLM прямо в процессе анализа. В сети передается куда больше паролей, чем вы привыкли считать.

4. Обнаружение приложений теневого IT. Один из самых наглядных примеров из практики: компания официально заявляет, что у неё разрешён только один инструмент удалённого доступа — скажем, AnyDesk. Анализ реального трафика сети при этом показывает целый «зоопарк» из разных приложений: Radmin, TeamViewer и прочие инструменты, о которых официальная политика ничего не говорит. Формулировка, которая точно описывает эту ситуацию: администраторы говорят одно, а сеть говорит другое — и именно сеть в этом случае оказывается источником более достоверной картины происходящего.

Все перечисленные находки можно настроить как автоматические уведомления и завести в любой удобный канал коммуникации — корпоративный мессенджер, чат-бота, систему тикетов — без необходимости вручную просматривать данные каждый день.

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

Чего NTA не может

У любой технологии, которая производит впечатление почти всемогущей, стоит проговорить границы возможностей — иначе доверие к ней строится на завышенных ожиданиях, а не на реальном понимании инструмента.

Есть категории атак, которые NTA не может надежно обнаруживать 

Показательный пример — атака Golden Ticket: получив полный контроль над контроллером домена и захватив учётную запись KRBTGT (специальную учётную запись, от имени которой подписываются все билеты Kerberos в домене), злоумышленник получает возможность действовать от имени кого угодно в этом домене. Надёжное обнаружение такой атаки требует видимости буквально всех Kerberos-билетов, циркулирующих в сети, — а обеспечить полную видимость такого объёма данных из-за возможных потерь трафика  на практике крайне сложно.

NTA не видит, что происходит непосредственно на хосте

Если злоумышленник закрепился на машине и построил, например, зашифрованный туннель через SSH, содержимое его дальнейших действий внутри этого хоста остаётся вне зоны видимости системы анализа трафика — в отличие от систем класса EDR, которые устанавливаются непосредственно на конечные точки. Есть отдельные ситуации, когда что-то всё же становится заметно опосредованно: например, если скомпрометированный хост запускает какой-то процесс, который обращается к внешнему репозиторию за обновлением или устанавливает дополнительный инструмент — это обращение пройдёт по сети и будет зафиксировано. Но полагаться на такую опосредованную видимость как на систематический источник данных о происходящем на хосте нельзя.

Отдельно стоит развести системы анализа трафика с ещё одним классом решений, с которым их часто сравнивают, — SIEM (Security Information and Event Management). SIEM собирает и анализирует логи из самых разных систем компании и часто выступает единой точкой, куда стекаются алерты от других средств защиты. Принципиальная разница в том, с чем работает каждая из систем: SIEM оперирует записями событий, которые системы сами решили зафиксировать в своих логах, а NTA работает непосредственно с сетевым трафиком, независимо от того, ведёт ли какая-либо система логирование происходящего или нет.

Из этого следует практический вывод: NTA и SIEM не заменяют друг друга, а дополняют. Как анализ логов не способен найти абсолютно все атаки, так и анализ сетевого трафика не покрывает всё возможное пространство угроз — у каждого инструмента есть своя специфика. Например, такие атаки, как NTLM-relay или сканирование портов, по своей природе являются сугубо сетевыми — у них попросту нет соответствующей записи в логах отдельных систем, которую мог бы проанализировать SIEM. Здесь NTA оказывается единственным источником видимости, потому что само событие никогда не попадает ни в один системный журнал.

Кейс №3: наблюдение за атакой в реальном времени

Все предыдущие истории объединяет одна черта — они разбирались постфактум, уже после того, как что-то произошло. Но у систем анализа трафика есть и другая грань: возможность наблюдать за разворачивающейся атакой практически в моменте, пока злоумышленник ещё активен внутри инфраструктуры.

Один из заказчиков обратился за экстренной помощью с простым сообщением: что-то происходит, помогите разобраться. С момента обращения до начала анализа прошло около двух часов.

Подключившись, команда быстро установила: злоумышленники взломали сервер в DMZ-сегменте — позже выяснилось, что это была система видеоконференцсвязи (ВКС) российской разработки. И здесь начинается самая необычная часть этой истории: атака ещё продолжалась, и её можно было наблюдать вживую. Хакер установил обратное соединение с хостом — незашифрованное — и начал разворачивать типичный инструментарий: загружал утилиты для сканирования сети (в духе nmap), архиваторы, программы для построения дополнительных туннелей. Всё это отражалось в трафике буквально в реальном времени: было видно не абстрактную «подозрительную активность», а конкретные команды, которые злоумышленник вводил в reverse shell-сессии — wget, распаковку архивов, установку дополнительных инструментов.

Первоочередным вопросом было не «что происходит сейчас», а «как злоумышленник вообще проник внутрь». Здесь помог тот же принцип, что и в истории с шифровальщиком: команда просто прошла по хронологии сессий назад от момента компрометации и нашла тот самый первый входящий запрос, который предшествовал появлению reverse-шелла. Скачав полную запись этой сессии (pcap) и открыв её в Wireshark, аналитики увидели то, чего в нормальном HTTP-запросе быть не должно: посторонние символы вроде кавычек и точек с запятой, характерные для попытки инъекции. Это оказалась ранее неизвестная уязвимость нулевого дня в конкретной системе ВКС-связи — эксплойт, для которого на тот момент не существовало ни патча, ни сигнатуры ни в одной системе защиты.

О находке немедленно сообщили производителю, уязвимость оперативно закрыли, и, по всей вероятности, это спасло от аналогичной компрометации ещё не один десяток российских компаний, использующих то же решение.

Эта история хорошо дополняет расследование шифровальщика с другой стороны. Там NTA/NDR-система восстанавливала цепочку атаки, которая уже завершилась, — работа велась с историей событий. Здесь та же технология оказалась полезной в противоположном сценарии: не восстановление прошлого, а наблюдение за настоящим, причём именно возможность мгновенно поднять полную запись конкретной сессии и открыть её в анализаторе пакетов позволила не просто остановить конкретную атаку, а обнаружить неизвестную уязвимость, о которой без этого расследования никто бы не узнал вовсе.

Заключение

Вернёмся к тезису, с которого начали. Большинство разговоров о сетевой безопасности крутится вокруг систем, которые обязаны решать мгновенно — пропустить пакет или заблокировать его, здесь и сейчас, без права на паузу. Но есть и другой класс систем, у которых этого ограничения нет, потому что они работают не с самим трафиком, а с его копией. И вся ценность, которую удалось показать через конкретные кейсы в этой статье, вырастает именно из одного простого факта — у таких систем есть время подумать.

Возможность сохранить данные сырого трафика лишь не насколько дней оборачивается возможностью восстановить постфактум всю цепочку атаки шифровальщика — от входа по SSH две недели назад до шифрования в 3 часа ночи субботы. Возможностью заметить аномальный паттерн в трафике и довести случайное наблюдение до обнаружения крупного ботнета, для которого ещё не существовало ни одной сигнатуры. Возможностью превратить обычные метаданные сети — DHCP, DNS-запросы, служебные поля DCERPC — в инструмент инвентаризации, который находит забытые серверы и посторонние устройства просто потому, что они продолжают о себе сообщать. Возможностью увидеть за размером и таймингом зашифрованных пакетов то, что происходит внутри соединения, даже не расшифровывая его содержимое. И возможностью наблюдать за атакой не только в архиве, но и в моменте, пока злоумышленник ещё активен внутри инфраструктуры.

При этом системы анализа трафика — не универсальный ответ на все вопросы безопасности. Отдельные категории атак остаются для них слепой зоной, а происходящее непосредственно на скомпрометированном хосте — вне их прямой видимости. Это не конкурент SIEM, NGFW или EDR, а системы, которые закрывают именно то пространство, куда остальные инструменты физически не дотягиваются — по своей архитектуре, а не по недоработке.

Прикладная ценность этого класса систем при этом заметно шире одной только безопасности. Истекающие сертификаты, аномальные всплески ошибок, не согласованные протоколы на нестандартных портах, теневой IT из незадекларированных инструментов удалённого доступа — всё это находится в тех же самых данных, которые изначально собирались ради поиска атак, и одинаково полезно и команде безопасности, и команде эксплуатации.

Если и есть один вывод, который стоит вынести из всех этих историй, — это то, что возможности анализа сетевого трафика систематически недооценивают. Не потому, что технология сложна или недоступна, а потому, что для большинства команд она остаётся за рамками привычного набора инструментов — до тех пор, пока не появляется задача, которую больше нечем решить.