Мониторинг сетевой активности сервера: обнаружение аномалий

В половине третьего ночи сетевой интерфейс сервера начинает отдавать данные в десять раз быстрее обычного. Антивирус молчит, система работает, пользователей нет. Майнер? Утечка? Или приложение зациклилось на запросах к базе?

Разобраться в этом можно за пятнадцать минут, если знать, куда смотреть. Порядок такой: сначала iftop покажет, между какими адресами идёт трафик, потом ss назовёт процесс, который держит соединение, и только если этого мало - tcpdump покажет, что именно передаётся. Все три утилиты ставятся из репозитория и работают по SSH.

Ниже - что считать аномалией и как отличить её от нормального всплеска, чем смотреть трафик на разных горизонтах (от «прямо сейчас» до «что было в прошлый вторник»), и таблица симптомов с расшифровкой: какой признак что обычно означает.

Анатомия сетевых аномалий

Аномалия - это отклонение от вашей нормы, а не от абстрактного идеала. Поэтому первый шаг всегда один: снять норму. Без неё любой всплеск выглядит подозрительно, а настоящая проблема теряется в шуме.

Отклонения бывают трёх типов, и ищут их по-разному.

Объёмные: изменился объём трафика

Самый заметный тип. DDoS, вирусная активность, сорвавшийся с расписания бэкап - всё это даёт кратный рост нагрузки на интерфейс.

Ловушка в том, что объёмные аномалии кажутся простыми. Заметный всплеск действительно виден сразу, но самые неприятные сценарии его не создают. Медленная утечка данных выглядит как обычная работа пользователей. Майнер часто ограничивает себя, чтобы не привлекать внимания: 5-10 % канала не поднимут ни один порог.

Время суток важнее абсолютной цифры. Всплеск в 15:00 в понедельник - вероятно, норма. Тот же всплеск в 03:30 в субботу - повод посмотреть.

Поведенческие: изменился характер трафика

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

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

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

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

Временные: изменился ритм

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

Отдельный признак - регулярность там, где её быть не должно. Ровные всплески строго раз в пять минут, одинаковой длительности и объёма, - это почти наверняка не человек. Так выглядит связь с управляющим сервером или работа по расписанию: у живой нагрузки такой метрономной точности не бывает.

Инструменты сетевого мониторинга: чем смотреть трафик

Инструменты удобно делить по горизонту, на который они смотрят. Задача «что происходит прямо сейчас» и задача «что было три недели назад» решаются разными вещами, и одна другую не заменяет.

Первые пятнадцать минут

Если сервер ведёт себя странно прямо сейчас, порядок такой. Всё ниже выполняется от root или через sudo: без прав iftop и tcpdump просто не запустятся, а ss покажет сокеты, но молча скроет имена чужих процессов - и это легко принять за «процесса нет».

Посмотрите, куда идёт трафик. Строка, которая забирает основной объём, в выводе iftop обычно видна сразу. Дальше нужен виновник.

Найдите процесс. Адрес и порт уже есть, ss добавляет к ним имя процесса и PID. Связка «iftop нашёл соединение - ss назвал процесс» закрывает большинство ситуаций.

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

Если непонятно - смотрите пакеты. Команда tcpdump -i eth0 -w dump.pcap сохранит дамп, который потом удобно разобрать в Wireshark на своей машине. Ключ -nn при выводе на экран отключает разрешение имён, чтобы вывод не тормозил и не порождал лишнего трафика.

Что поставить, чтобы не гадать каждый раз

Разовые утилиты хороши, когда вы уже знаете, что что-то не так. Проблема в том, что вопрос «а как было раньше?» они не закрывают - к моменту вашего прихода картина уже изменилась.

Минимум, который стоит поставить заранее, - vnstat: он ведёт историю по интерфейсу и почти ничего не потребляет. Команда vnstat -d покажет разбивку по дням, и станет видно, что «аномальный» объём держится уже неделю.

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

Если нужны счётчики самих интерфейсов - ошибки передачи, отброшенные пакеты, состояние портов, - это уже территория SNMP-мониторинга: протокол отдаёт эти счётчики штатно.

Системы мониторинга состояния сети в действии

Между «поставил vnstat» и «развернул NTA-платформу» лежит большой разрыв, и попадать в него обычно не нужно. Масштаб решения выбирают по размеру инфраструктуры.

Один-два сервера. vnstat для истории, ntopng для картины по хостам, iftop и ss под рукой для разбора. Отдельная система мониторинга сети не нужна: сетевые метрики удобнее добавить в общий мониторинг, который у вас и так есть. Если это Zabbix, сетевые счётчики берутся штатным шаблоном без единой строчки кода.

Десяток серверов и управляемые коммутаторы. Появляется смысл собирать потоки: коммутаторы и маршрутизаторы умеют экспортировать NetFlow, sFlow или IPFIX, а коллектор сводит это в общую картину. Плюс подхода в том, что вы видите трафик всей сети, не ставя ничего на каждый сервер, и содержимое пакетов не разбирается - собираются только метаданные потоков: кто, с кем, сколько, как долго.

Дальше - специализированные платформы. Системы класса NTA и NDR, разбор трафика с machine learning, интеграция с SOC. Это корпоративный сегмент со своим бюджетом и своей командой; в инфраструктуре на десяток машин такая система создаёт больше работы, чем закрывает.

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

Автоматизация обнаружения аномалий

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

Сначала базовая линия, потом пороги

Порог, взятый из головы, бесполезен. Сначала нужно снять норму: неделя-две наблюдений, чтобы увидеть будни, ночи и выходные, а если есть месячная отчётность - то и месяц.

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

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

Ложные срабатывания дороже пропусков

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

Про машинное обучение честно

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

В инфраструктуре из нескольких серверов картина другая. Модели нужны данные и обучение, а на маленькой и предсказуемой нагрузке они дают точность не выше обычных пороговых правил, зато требуют настройки, объяснения каждого срабатывания и человека, который всё это будет вести. Простое правило «ночью исходящего трафика больше 100 МБ - оповестить» ловит майнер не хуже нейросети и настраивается за пять минут.

Интерпретация результатов и принятие решений

Аномалию нашли. Дальше нужно понять, что это, и не бросаться выключать сервер раньше времени.

Два правила, которые экономят нервы.

Проверьте календарь раньше, чем поднимать тревогу. Плановый бэкап, обновление, миграция, выгрузка отчётности в конце квартала, новое приложение у коллег - большинство «аномалий» объясняется этим. Вопрос «что у нас вчера меняли?» закрывает больше инцидентов, чем любой анализатор.

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

Интеграция с общей системой мониторинга

Сетевые метрики отдельно от остальных мало что дают. Рост трафика вместе со скачком нагрузки на процессор - вероятно, приложение под нагрузкой. Тот же рост при спокойном процессоре и ночью - совсем другая история.

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

Что именно и с какой частотой имеет смысл собирать по всей инфраструктуре, разобрано в материале про комплексный мониторинг серверов.

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