Сети и серверы · мониторинг и Linux
Как случайное предупреждение на карте сети привело к расследованию сетевого шторма и обнаружению постороннего администратора
Я тогда только начинал делать портал мониторинга сети. Одной из первых проверок была загрузка процессора центрального сетевого оборудования: если она превышала порог, на карте возле устройства появлялся красный восклицательный знак.
Больше ничего не происходило. Мониторинг ещё не записывал такие предупреждения как инциденты и никому не писал. Нагрузка могла подскочить на несколько минут и успокоиться до следующего опроса, и значок пропадал без следа. Однажды, работая над картой, я совершенно случайно его заметил. С этого и началось расследование.
Во время перегрузки
Через пару минут
Журнал событийпусто
Условная схема и вымышленное значение загрузки. В ранней версии мониторинга предупреждение жило только на экране: как только нагрузка возвращалась в норму, от него ничего не оставалось.
Проверка показала, что необычный трафик приходит из одного клиентского сегмента. Шторм накатывал волнами: всплеск, затишье, снова всплеск. Между волнами всё выглядело нормально, поэтому на значок легко было не обратить внимания.
Сетевой шторм похож на общий домовой чат, где одно сообщение начинают пересылать снова и снова, а каждый, кто его получил, тоже пересылает всем. Через минуту чат невозможно читать, а нужные сообщения тонут в потоке. В сети вместо сообщений — пакеты «для всех сразу». Каждое устройство обязано их принять и обработать, и центральное оборудование тратит процессор на мусор вместо полезной работы.
Масштаб хорошо видно по одной проверке в сентябре. Порт в сторону сегмента ненадолго включили с промежуточными ограничениями, и примерно за три секунды через него пришло 3 478 763 пакета. Конкретному получателю из них были адресованы 64, всё остальное — широковещательная и групповая рассылка.
Искал от центра сети к краю. На каждом устройстве по пути смотрел, на какой порт приходит самый большой входящий поток и через какой он уходит дальше, а по данным о соседях выяснял, кто подключён к этому порту. Цепочка закончилась на порту коммутатора агрегации, за которым начиналась сеть клиента — управляющей компании с собственным оборудованием.
порог предупреждения
Форма волн условная и показывает только характер шторма. Настоящие цифры — в карточках ниже.
Как устроена сеть клиента изнутри, с нашей стороны было не видно. Поэтому первым делом этот порт выключили, и шторм перестал доходить до остальной сети. Сегмент оставался отключённым, пока не появилась возможность разобраться на самом клиентском оборудовании.
Пробное включение в сентябре показало, что шторм на месте. Промежуточные ограничения его не удержали: примерно за три секунды начала сбоить даже управляющая сессия коммутатора, и заранее открытое аварийное подключение сразу выключило порт. Просто включить порт ещё раз после этого было нельзя.
Дальше порт включался только в карантине: одна служебная сеть, скорость около 512 кбит/с, не больше примерно ста пакетов в секунду на каждый вид рассылки, фильтр по трём известным устройствам, готовая аварийная сессия и таймер, который сам выключит порт. Сначала окна по 6–40 секунд, потом по 15 и 30 минут. В одном 40-секундном окне на порт пришло 85 975 пакетов, а дальше в сеть ничего не прошло.
Клиентский MikroTik, от которого шёл шторм, обслуживал другой системный администратор — со стороны управляющей компании. Дальше мы разбирались вместе: я держал карантин на нашем порту и открывал окна доступа, он отвечал за само устройство и его сеть.
В карантине маршрутизатор наконец стал отвечать: ping проходил без потерь, SSH спрашивал пароль. Но войти не получилось — известные пароли не подходили. Подбирать дальше я не стал: устройство чужое, и решать, что с ним делать, должен его владелец. Следующее окно с новым паролем я закрыл досрочно: проверка защиты не успела завершиться за отведённое время, а при малейшем сомнении порт должен оставаться выключенным.
В итоге договорились о сбросе. На время работ сеть клиента подключили через временный роутер на другом порту. Перед сбросом в списке пользователей MikroTik обнаружилась учётная запись System с полными правами — никто из тех, кто отвечал за устройство, её не создавал. Последний вход по ней был отмечен 1 мая 2026 года, на следующий день после того, как шторм впервые зафиксировали.
После сброса администратор клиента заново настроил MikroTik, а наш порт перевели в отдельную сеть для подключения, где устройство получает адрес автоматически и не тянет за собой старых настроек. За время наблюдения шторм не вернулся. На следующий день интернет через новый путь заработал, и временный роутер отключили.
Стилизованное окно управления маршрутизатором: список пользователей, среди которых неизвестная учётная запись System в группе full с полными правами.
Стилизованный фрагмент на вымышленных данных. С настоящим устройством совпадают только имя System и группа full; имена, время и комментарии придуманы.
Как именно всё началось, выяснить не удалось. Осталось непонятным, были ли шторм и учётная запись System связаны. Сведений о том, что System появлялась снова после сброса, нет.
Роутер выглядит как коробка с лампочками, но внутри у него операционная система, программы и учётные записи — почти как у компьютера. А где есть программы, там бывают ошибки, через которые чужой человек может войти или получить больше прав, чем ему положено. Поэтому такие устройства тоже нужно обновлять и не открывать управление всему интернету.
Осенью 2026 года MikroTik выпустил исправления сразу для нескольких уязвимостей RouterOS. Среди них — ошибки в SSH, которые вместе позволяли получить полный контроль над устройством. CERT Polska 5 сентября сообщил о реальных атаках не позднее чем со 2 сентября: на взломанных роутерах злоумышленники заводили собственную учётную запись. В конце сентября американское агентство CISA опубликовало предупреждение ещё об одной критической уязвимости — в веб-интерфейсе управления.
Наши события случились весной, за несколько месяцев до этих публикаций, поэтому приписывать их какой-то конкретной уязвимости было бы неправильно. Как System попала на устройство, неизвестно. Но история хорошо показывает, почему посторонняя учётная запись на сетевом оборудовании — повод для сброса, а не для удаления одной строчки: заранее не знаешь, что ещё успели поменять.
Источники: MikroTik — бюллетени безопасности · CERT Polska, 5 сентября 2026 · CISA ICSA-26-272-06, 29 сентября 2026
Первый мониторинг показывал только текущее состояние: что происходит в эту минуту. Для шторма, который приходит волнами, этого мало. Предупреждение исчезало вместе с нагрузкой, и если в этот момент никто не смотрел на карту, проблемы как будто и не было. Я увидел значок случайно — значит, мог и не увидеть.
Из этого стало понятно, что мониторингу нужна память. Событие должно сохраняться, даже когда всё уже успокоилось: когда началось, сколько длилось, повторялось ли. О нём нужно сообщать человеку, а после восстановления — проверять, что всё действительно вернулось в норму.
Портал рос постепенно. Сразу после расследования оборудование начало само сохранять снимки нагрузки процессора и трафика, когда они превышают порог, — чтобы следующую волну не нужно было ловить вручную. Потом появились инциденты с историей: повторившаяся проблема возвращает прежний инцидент, а не плодит новые. Затем уведомления инженеру в MAX, отдельное сообщение о восстановлении, автоматическое закрытие только после устойчивой нормальной работы и внешняя проверка, которая сообщит, если недоступен сам портал. Простая карта со значками стала системой, по которой можно восстановить, что и когда происходило.
Тогда: только сейчас
Сейчас: событие с историей
Высокая загрузка процессора · центр сети
три всплеска за сутки сохранены в истории
Время, длительность и число повторов вымышлены; карточка показывает, какие сведения теперь сохраняются о событии.
Вторая часть работы — серверы на Linux, на которых живут портал, биллинг и фоновые задачи. С ними похожая ловушка: сервер отвечает на ping, по SSH заходишь без проблем, а отдельная служба или задание по расписанию тем временем работает не так, как нужно.
На карточке одного из устройств портала иногда на несколько минут вместо состояния портов появлялись вопросительные знаки. При этом само устройство было на связи, а задание, которое собирает состояние портов, каждый раз завершалось успешно.
Задание стояло в расписании «каждые четыре минуты», начиная с четвёртой минуты часа: 04, 08 и так до 56. После 56-й минуты следующий запуск был только в 04 следующего часа — почти восемь минут, а не четыре. Данные о портах считаются свежими пять минут, поэтому раз в час они успевали устареть, хотя ни один запуск не заканчивался ошибкой.
Нашлось это в истории запусков: между двумя соседними стартами прошло 479,7 секунды. Исправление — одна строка расписания: запуски сдвинулись на 01, 05 … 57, и шаг стал ровно четыре минуты в том числе через границу часа. Срок свежести я не увеличивал. Задачу закрыл только после того, как настоящий переход 11:57 → 12:01 прошёл без устаревших данных.
Шкала в минутах, масштаб условный. Восемь минут и пять минут свежести — реальные значения этого случая.
Обновление серверов виртуализации до новой версии прошло штатно: узлы перезагрузились, виртуальные машины запустились, SSH отвечал. А биллинг не работал. Новая версия запустила его виртуальную машину с другим типом виртуального «железа», лицензия биллинга привязана к оборудованию — и система решила, что машина чужая. Лицензию отвергли, а службы, которые принимают авторизацию и учёт трафика, раз за разом завершались с одной и той же ошибкой о лицензии. Система запуска поднимала их снова, и они снова падали.
Перезапускать их ещё раз смысла не было: причина оставалась на месте, и каждый новый запуск заканчивался так же. Помогло исправить саму причину. Я закрепил для этой машины прежний тип виртуального оборудования, вернул лицензионную запись из локальной копии базы, сделанной до работ, и перезапустил основную службу биллинга один раз. Лицензию приняли, сессии абонентов снова пошли в учёт. Авторизация и учёт трафика в тот день не работали около часа.
Хвост у этой истории тоже был: после восстановления часть абонентов не могла подключиться из-за зависших сессий в биллинге. Об этом — отдельный разбор →
Что я проверяю после обновления
Всё началось с маленького красного значка, который через пару минут исчез бы без следа. Если бы я в тот момент не смотрел на карту, шторм ещё какое-то время приходил бы волнами, а странная учётная запись на клиентском роутере, возможно, осталась бы незамеченной.
С тех пор я по-другому смотрю на мониторинг. Показать текущее состояние — только начало. Важно сохранить событие, сообщить о нём человеку и проверить, что после восстановления всё действительно работает. Тот случайный значок я до сих пор вспоминаю каждый раз, когда добавляю в портал новую проверку.