Между взломом и моментом, когда его наконец заметили, в 2024 году проходило 11 дней (данные Mandiant). В отчёте M-Trends 2026 за следующий год медиана подросла до 14. Две недели чужой человек спокойно ходит по сети, читает почту, копирует базы, а защита всё ещё считает это рабочим шумом.
Теперь вторая цифра, от которой холодеет спина. Передача доступа от одной группировки к другой в 2022 году занимала больше восьми часов. По данным той же Mandiant, в 2025-м медиана упала до 22 секунд. Пока обороняющийся раскачивается две недели, нападающий перепродаёт вход за время, которого хватает на глоток кофе. (Кофе, кстати, ещё горячий.)
Сеть редко падает молча. Перед сбоем, утечкой или шифровальщиком появляются мелкие странности. Сервер вдруг лезет на внешний адрес, которого раньше не знал. Рабочая станция перебирает соседей по подсети. DNS-запросы вытягиваются в подозрительно длинные строки. А ночью, в пустом офисе, исходящий трафик зачем-то ползёт вверх.
Сама по себе странность ничего не доказывает. Всплеск отправленных данных бывает и от ночного обновления, и от криворукого админа, и от новой задачи, про которую забыли предупредить. Хорошая система наблюдения нужна ровно за этим. Отделить обычный шум от настоящего сигнала, не утонув в ложных тревогах.
Что считать нормой (и почему она у всех разная)
Сетевая аномалия это отклонение поведения устройства, пользователя или сегмента от привычного для конкретной сети. Слово «конкретной» тут ключевое. Рост числа соединений ночью для серверов интернет-магазина в чёрную пятницу абсолютно нормален. Тот же скачок на изолированном бухгалтерском сервере означает, что пора будить дежурного.
Классическая защита ищет известные шаблоны атак, как охранник со списком разыскиваемых лиц. Поиск аномалий устроен иначе. Программа смотрит на поведение и прикидывает, насколько новое событие похоже на обычную жизнь сети. Руководство NIST SP 800-94 относит такой подход к базовым наряду с сигнатурами и разбором протоколов. Документ, правда, родом из 2007 года (черновик обновления 2012-го NIST в итоге похоронил), так что технологии в нём устарели, а идея жива.
Загвоздка в том, что почти всё необычное оказывается безобидным. Аналитику приходится выяснять, чьё это устройство, какая у сервера роль, не было ли плановых работ, куда именно шёл трафик и случалось ли подобное раньше. Скучная детективная работа без погонь.
Как это вообще считают
Защитная программа собирает выбранные показатели, превращает их в признаки, сравнивает с моделью нормы и подсвечивает то, что выбивается. Расследование она не заменяет. Даёт ранний сигнал, дальше думает человек.
Удобно разложить процесс на три шага. Сырые данные превращаются в признаки, и сюда идёт всё подряд, от адресов источника и назначения до портов, протоколов, объёма, времени соединения, частоты повторов, доменов и кодов ответа. Потом алгоритм строит модель нормы, сам или с помощью человека. И наконец новые события постоянно сверяются с моделью, а сильные отклонения уходят в отчёт.
Один раз настроить и забыть не выйдет. Переехали сервисы в облако, сменили VPN, подключили нового подрядчика, и поведение сети меняется до неузнаваемости. Без регулярного обновления модель начнёт сыпать ложными тревогами, на которые однажды перестанут реагировать. Что и требовалось нападающему.
Смотреть молча или дёргать сеть
Подходов два. Пассивный просто наблюдает за тем трафиком, что уже есть. Инструменты снимают копию рабочего потока, события коммутаторов, журналы DNS, DHCP, прокси, межсетевых экранов и удалённого доступа. На пропускную способность это не влияет, поэтому для расследований и тихой охоты за угрозами подход идеален. Открытый анализатор Zeek так и работает, складывая подробные журналы сетевых событий.
Активный метод сам генерирует запросы, чтобы проверить доступность сервисов, задержки, потери пакетов и время отклика. Полезно для контроля работоспособности, но есть нюанс. Слишком частые проверки сами перегружают слабые сервисы и искажают картину нагрузки. Диагностика, которая ломает то, что измеряет, в перегруженной сети не анекдот, а будни.
Для безопасности главный это пассивный сбор. Он показывает, что на самом деле делают люди и программы. Активные проверки честнее отвечают на другой вопрос, про технический статус сервиса.
Четыре способа выбиться из нормы
Чтобы расследование не превращалось в бесконечную прокрутку логов, события группируют. Аномалии объёма это резкий рост входящего или исходящего трафика, лавина соединений, активность в три часа ночи. Причины разные, от сбоя синхронизации и кривого бэкапа до распределённой атаки или работы шифровальщика.
Аномалии направления возникают, когда локальная машина вдруг тянется к нетипичному внешнему адресу или в закрытый сегмент. Внутренний сервер, который годами не выходил наружу и вдруг полез в интернет, подозрителен сам по себе.
Аномалии протокола это отдельное удовольствие. Тут DNS внезапно начинает передавать длинные нечитаемые строки. Знакомьтесь, туннелирование. Данные кодируют в поддоменах и шлют наружу через запросы, которые межсетевой экран пропускает не глядя (порт 53 же, святое). Простая арифметика. Сто запросов в секунду по сорок байт это около 14 мегабайт в час, чего хватит, чтобы вынести дамп базы или хранилище паролей за один рабочий день. Так уводили данные группировки уровня APT41 и OceanLotus. Сигналы при этом не прячутся. Всплеск запросов к одному редкому домену, аномально длинные имена, гора ответов NXDOMAIN, высокая энтропия в поддоменах. База Network Traffic Flow из MITRE ATT&CK как раз описывает поток как сводку по соединениям с адресами, портами, протоколами, временем, объёмом и направлением.
Четвёртая категория самая коварная, аномалии ритма. Машина обращается к одному узлу через равные промежутки, как метроном. Это поведение маяка (beacon), которым управляется заражённая система. По умолчанию маяк Cobalt Strike стучится на свой сервер примерно раз в минуту, разбавляя интервал случайным разбросом (jitter), чтобы не палиться на ровном тиканье. Хитрость в том, что разброс прячет точные секунды, но не статистический ритм. Инструмент RITA вычитывает периодичность прямо из логов Zeek и подсвечивает маяк, даже если тот спит то 38, то 51 секунду. А ещё ранние сборки оставляли в HTTP-запросах путь /jquery-3.3.1.min.js и сертификат со строкой «Major Cobalt Strike», что роднит такую маскировку с фальшивыми усами из комедии.
Конкретный признак становится тревожным, когда поведение спорит с ролью устройства. Принтеру незачем ходить на домены, зарегистрированные позавчера. Файловому серверу незачем отправлять гигабайты на неизвестный узел в другой стране. Рабочая станция бухгалтера не должна сканировать полсети. А вот ночной трафик иногда оказывается легальным резервным копированием, а вход из новой страны командировкой сотрудника. Поэтому каждую странность проверяют, а не рубят с перепугу. Но если разом совпали ночная активность, незнакомый процесс и вход из чужой страны, это уже не похоже на случайность.
Без чего ничего не работает
Хороший поиск начинается с телеметрии. При плохой видимости сети алгоритм либо проспит атаку, либо завалит ложными тревогами. Минимум это сетевые потоки NetFlow или IPFIX, журналы DNS, DHCP, прокси, экранов и VPN. Потоки показывают, кто с кем говорил, по какому протоколу, сколько передал и как долго. DHCP подсказывает, за каким узлом в нужный момент числился внутренний адрес.
В облаке зеркалирования трафика уже мало. Инженеры собирают облачные журналы, например VPC Flow Logs в AWS, аналогичные потоки в Azure и телеметрию сервисных сеток в Kubernetes. Платформа Istio выдаёт детали взаимодействия сервисов через встроенную наблюдаемость.
Шифрование прячет содержимое, но метаданные остаются. Адреса, порты, частота, направление, объёмы никуда не деваются. Не расшифровывая ни байта, реально засечь сканирование, скрытый туннель, кражу данных и связь с чужим сервером. А связка сетевой статистики с тем, что творится в процессах на самой машине, превращает догадку в доказательство.
Базовая линия описывает привычный режим. Одни узлы каждый день гонят терабайты, другие молчат неделями. Норму разумнее строить по классам устройств отдельно для рабочих станций, серверов, маршрутизаторов, облачных сервисов и удалённых сотрудников. У каждого класса свои показатели, свои рабочие часы, свои ночные окна и сезонные пики.
Порядок разбора и чем его делать
Разбор начинается с простого вопроса. Что вообще изменилось. Аналитик ищет инициатора события, уточняет роль устройства и проверяет, нет ли законной причины для странного поведения. Сравнивает с историей за последние недели, смотрит плановые работы и накаты обновлений, изучает направление, домены, порты, объёмы и частоту. Сетевые признаки сверяет с журналами операционной системы и экрана. И только потом решает, наблюдать дальше, ограничить доступ, изолировать машину или поднимать полноценное расследование. Весь разбор фиксируют, иначе через месяц никто не вспомнит, почему сработало правило.
Серебряной пули среди инструментов нет. Системы обнаружения вторжений ловят известные атаки. Платформы SIEM собирают логи отовсюду и связывают события между собой. Решения класса EDR показывают процессы, файлы и действия на конкретных машинах. Системы NDR сосредоточены именно на поведении трафика, а XDR пытается сшить всё это в одну картину. Каждый видит свой кусок и без остальных слепнет.
Связки Zabbix, Prometheus и Grafana отлично ловят чисто технические сбои, падение доступности, рост задержек, перегрузку интерфейсов. Машинное обучение помогает, когда данных слишком много для живого человека. Но контекста алгоритм не понимает и понимать не обязан. Его дело подсветить, дело аналитика объяснить.
Где обычно спотыкаются
Спотыкаются предсказуемо. Чаще всего ищут аномалии без актуальной карты сети, а потом удивляются, что гоняются за призраками. Не зная, какие сервисы критичны и какие соединения легальны, отличить атаку от плановой задачи нельзя в принципе.
Второй классический промах это один порог на всех. Гигабайты исходящего от сервера копирования абсолютная норма. Тот же объём от ноутбука бухгалтера повод бросать обед. А ещё регулярно забывают про DNS, облачные метрики и логи удалённого доступа, и расследование упирается в стену ровно там, где спрятался нападающий.
С чего начать
Браться за всё сразу не нужно. Разумнее запустить десяток сценариев на критичных участках, закрыть внешние подключения, VPN, DNS, облачные среды и административные порты. Поэтапно команда быстрее увидит результат и не утонет в тревогах с первого дня.
Сначала список критичных активов и владельцы систем. Потом детальный сбор потоков, в облаке плюс метрики виртуальных роутеров. Дальше описывают нормальные соединения для приоритетных серверов, выбирают пару десятков сценариев и каждому уровню риска прописывают регламент. Раз в месяц правила пересматривают и добавляют исключения. Ориентир простой. Каждая тревога обязана отвечать, что изменилось и чем это опасно. Не можешь объяснить срабатывание, значит, правило сырое.
Самое сложное в этой работе не заметить аномалию. Замечать как раз умеют и алгоритмы. Сложно ответить на детский по форме вопрос, который встаёт сразу после сигнала. Это вообще что было. Те самые 14 дней медианного простоя и набегают, пока на него никто не может ответить. А нападающий, напомню, перепродаёт доступ за 22 секунды.