Что такое мониторинг сети

Что такое мониторинг сети?

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

Связаться с Cisco

Что такое системы мониторинга сети?

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

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

Что такое протоколы мониторинга сети?

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

Ключевые преимущества мониторинга сети

Полная прозрачность сети

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

Более эффективное использование ИТ-ресурсов

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

Понимание потребностей будущей инфраструктуры на ранних этапах

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

Возможность ускоренного выявления угроз безопасности

Мониторинг сети помогает организациям понять, какова «нормальная» производительность их сетей. Таким образом, при возникновении необычной активности, такой как необъяснимое увеличение уровней сетевого трафика, администраторам проще быстро выявить проблему и определить, представляет ли она угрозу безопасности.

Источник

Сетевой мониторинг: как мы следим за тем, чтобы у крупных компаний работали все узлы

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

Я из команды обеспечения физической работоспособности сети, проще говоря – техподдержки, отвечающей за то, чтобы лампочки на роутерах мигали, как надо. У нас «под крылом» разные крупные компании с инфраструктурой по всей стране. Внутрь их бизнеса не лезем, наша задача – чтобы работала сеть на физическом уровне и трафик проходил как надо.

Общий смысл работы – постоянный опрос узлов, снятие телеметрии, прогоны тестов (например, проверка настроек для поиска уязвимостей), обеспечение работоспособности, мониторинг приложений, трафика. Иногда инвентаризации и прочие извращения.

Расскажу про то, как это организовано и пару историй с выездов.

Как это обычно бывает

Диалоги иногда такие:
— Так, связь пропадает между зданиями №4 и 5. Проверь роутер в пятом.
— Порядок, включён. Коннекта нет.
— Ок, иди по кабелю до четвёртого корпуса, там ещё узел.
—… Оппа!
— Что случилось?
— Тут 4-й дом снесли.
— Что??
— Прикладываю фото в отчёт. Дом в SLA восстановить не смогу.

Но чаще всё же получается найти обрыв и восстановить канал.

Примерно 60% выездов – «в молоко», потому что либо перебито питание (лопатой, прорабом, злоумышленниками), либо провайдер не знает про свой сбой, либо же кратковременная проблема устраняется до прибытия монтажника. Однако бывают ситуации, когда мы узнаём о проблеме раньше пользователей и раньше ИТ-служб заказчика, и сообщаем о решении до того, как они вообще поймут, что что-то случилось. Чаще всего такие ситуации случаются ночью, когда активность в компаниях заказчиков низкая.

Кому это надо и зачем

Как правило, у любой крупной компании есть свой IT-отдел, который чётко понимает специфику и задачи. В среднем и большом бизнесе работу «эникеев» и инженеров-сетевиков часто аутсорсят. Это просто выгодно и удобно. Например, один ритейлер имеет своих очень крутых айтишников, но занимаются они далеко не заменой роутеров и выслеживанием кабеля.

Что мы делаем

Первый способ — simple cheсks — это просто машина, которая пингует все узлы сети и следит за тем, чтобы они правильно отвечали. Такая реализация не требует вообще никаких изменений или минимальных косметических изменений в сети заказчика. Как правило, в очень простом случае мы ставим Заббикс прямо к себе в один из дата-центров (благо у нас их целых два в офисе КРОК на Волочаевской). В более сложном, например, если используется своя защищённая сеть – на одну из машин в ЦОДе заказчика:

Заббикс можно применять и сложнее, например, у него есть агенты, которые ставятся на *nix и win-узлы и показывают системный мониторинг, а также режим external check (с поддержкой протокола SNMP). Тем не менее, если бизнесу нужно что-то подобное, то либо у них уже есть свой мониторинг, либо выбирается более функционально-богатый вариант решения. Конечно, это уже не открытое ПО, и это стоит денег, но даже банальная точная инвентаризация уже примерно на треть отбивает затраты.

Это мы тоже делаем, но это история коллег. Вот они прислали пару скринов Инфосима:

Я же оператор «аватара», поэтому расскажу дальше о своей работе.

Как выглядит типовой инцидент

Перед нами экраны с вот таким общим статусом:

На этом объекте Zabbix собирает для нас довольно много информации: партийный номер, серийный номер, загрузка ЦПУ, описание устройства, доступность интерфейсов и т.п. Вся необходимая информация доступна из этого интерфейса.

Рядовой инцидент обычно начинается с того, что отваливается один из каналов, ведущих к, например, магазину заказчика (которых у него штук 200-300 по стране). Розница сейчас прошаренная, не то что лет семь назад, поэтому касса продолжит работу — каналов два.

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

Как правило, без мониторинга до эскалации прошли бы часы или дни — те же резервные каналы проверяют далеко не всегда. Мы знаем сразу и выезжаем сразу же. Если есть дополнительная информация кроме пингов (например, модель глючащей железки) – сразу комплектуем выездного инженера необходимыми частями. Дальше уже по месту.

Второй по частоте штатный вызов – выход из строя одного из терминалов у пользователей, например, DECT-телефона или Wi-Fi-роутера, раздававшего сеть на офис. Здесь мы узнаём о проблеме из мониторинга и почти сразу получаем звонок с деталями. Иногда звонок ничего нового не добавляет («Трубку беру, не звонит чего-то»), иногда очень полезен («Мы его со стола уронили»). Понятно, что во втором случае это явно не обрыв магистрали.

Оборудование в Москве берётся с наших складов горячего резерва, у нас их несколько типа таких:

У заказчиков обычно есть свои запасы часто выходящих из строя комплектующих – трубок для офиса, блоков питания, вентиляторов и так далее. Если же нужно доставить что-то, чего нет на месте, не в Москву, обычно мы едем сами (потому что монтаж). Например, у меня был ночной выезд в Нижний Тагил.

Если у заказчика есть свой мониторинг, они могут выгружать данные нам. Иногда мы разворачиваем Заббикс в режиме опроса, просто чтобы обеспечить прозрачность и контроль SLA (это тоже бесплатно для заказчика). Дополнительные датчики мы не ставим (это делают коллеги, которые обеспечивают непрерывность производственных процессов), но можем подключиться и к ним, если протоколы не экзотические.

В целом – инфраструктуру заказчика не трогаем, просто поддерживаем в том виде, как она есть.

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

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

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

Ещё практика

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

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

Иногда получаются настоящие героические спасения. Такие ситуации – большая редкость, но из того, что помню за этот год – увидели около 3 ночи повышение температуры до 55 градусов на цискокоммутаторе. В далёкой серверной стояли «глупые» кондиционеры без мониторинга, и они вышли из строя. Мы сразу вызвали инженера по охлаждению (не нашего) и позвонили дежурному админу заказчика. Он потушил часть некритичных сервисов и удержал серверную от thermal shotdown до приезда парня с мобильным кондиционером, а потом и починки штатных.

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

Один раз было достаточно нетипичное обращение. Заказчику нужно было отдать роутер какому-то своему обособленному подразделению, причём точно по описи. В роутере был модуль с указанным серийником. Когда роутер начали готовить в дорогу, выяснилось, что этого модуля что-то нет. И найти его никто не может. Проблему слегка усугубляет тот факт, что инженер, который в прошлом году работал с этим филиалом, уже на пенсии, и уехал ко внукам в другой город. Связались с нами, попросили поискать. К счастью, железо давало отчёты по серийникам, а Инфосим делал инвентаризацию, поэтому мы за пару минут нашли этот модуль в инфраструктуре, описали топологию. Беглеца выследили по кабелю – он был в другой серверной в шкафу. История перемещения показала, что попал он туда после выхода из строя аналогичного модуля.

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

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

Один раз настраивали камеру, которая должна фокусироваться на «зайцах», лазящих через забор. Пока ехали, думали, как будем обозначать точку, где должен появляться нарушитель. Не пригодилось – за те 15 минут, что мы там были, на объект проникло человек 30 только в нужной нам точке. Прямо настроечная таблица.

Как я уже приводил пример выше, история про снесённое здание – не анекдот. Один раз пропал линк до оборудования. На месте – нет павильона, где проходила медь. Павильон снесли, кабель пропал. Мы увидели, что маршрутизатор сдох. Монтажник приехал, начинает смотреть – а расстояние там между узлами пара километров. У него в наборе випнетовский тестер, стандарт — прозвонил от одного коннектора, прозвонил от другого – пошёл искать. Обычно проблему сразу видно.

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

На одном объекте в одно и то же время ночью выключалось оборудование. Выяснилось, что местные умельцы подключились к нашему питанию, вывели удлинитель и втыкают туда чайник и электроплитку. Когда эти устройства работают одновременно – выбивает весь павильон.

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

Был случай, что дворник лопатой перебил кабель.

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

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

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

В данном случае с питанием явно есть проблемы.

Что умеет «большой» мониторинг

Отдельно про инвентаризацию. Модуль не просто показывает список, но ещё и сам строит топологию (по крайней мере, в 95% случаев пытается и попадает правильно). Он же позволяет иметь под рукой актуальную базу используемого и простаивающего ИТ оборудования (сетевое, серверное оборудование и т.д.), проводить вовремя замены устаревшего оборудования (EOS/EOL). В общем, удобно для большого бизнеса, но в малом многое из этого делается руками.

Stablenet – Embedded Agent (SNEA) — компьютер размером чуть больше пачки сигарет.

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

Облачный мониторинг

Ещё одна модель установки – SaaS в облаке. Делали для одного глобального заказчика (компания непрерывного цикла производства с географией распределения от Европы по Сибири).

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

Мы настроили мониторинг конкретно под них, потом допилили на ряде участков по особенностям именно их маршрутизации и железа. Это всё делалось в облаке КРОК. Сделали и сдали проект очень быстро.

Преимущество облака в том, что в своем решении мы стоим как бы над их сетью и можем смотреть на все происходящее более объективно. В то время, если бы мы находились внури сети, мы видели бы картину только до узла отказа, и что за ним происходит, нам уже не было бы известно.

Пара картинок напоследок

Это — «утренний паззл»:

А это мы нашли клад:

В сундуке было вот что:

Ну и напоследок про самый весёлый выезд. Я как-то раз выезжал на объект розницы.

Там случилось следующее: сначала начало капать с крыши на фальшпотолок. Потом в фальшпотолке образовалось озеро, которое размыло и продавило одну из плиток. В результате всё это хлынуло на электрику. Дальше точно не знаю, что именно случилось, но где-то в соседнем помещении коротнуло, и начался пожар. Сначала сработали порошковые огнетушители, а потом приехали пожарные и залили всё пеной. Я приехал уже после них к разборку. Надо сказать, что циска 2960 врубилась после всего этого – я смог забрать конфиг и отправить устройство в ремонт.

Ещё один раз при сработке порошковой системы цисковский 3745 в одном банке был заполнен порошком почти полностью. Все интерфейсы были забиты – 2 по 48 портов. Надо было включать на месте. Вспомнили прошлый случай, решили попробовать снять конфиги «на горячую», вытрясли, почистили, как умели. Врубили – сначала устройство сказало «пфф» и чихнуло в нас большой струёй порошка. А потом заурчало и поднялось.

Источник

Зачем мониторить трафик локальной сети?

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

Угрозы ИБ

Компания Positive Technologies провела исследование угроз ИБ в корпоративных сетях, в ходе которого был составлен рейтинг угроз:

Нарушение регламентов ИБ найден у 100% компаний

Подозрительная сетевая активность найдена у 90% компаний

Активность вредоносного ПО найдена у 68% компаний

Попытки эксплуатации уязвимости в ПО найдены у 31% компаний

Попытки подбора пароля найдены у 26% компаний

Попытки эксплуатации веб-уязвимостей найдены у 3% компаний

Зачем мониторить трафик локальной сети?

Рисунок 1

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

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

Решения по защите от угроз ИБ, работающие с трафиком локальной сети

Для предотвращения нарушения регламентов ИБ, подозрительной сетевой активности, использования вредоносного ПО и эксплуатации уязвимости в ПО используются административные и технические меры. К административным относятся разграничение прав пользователей оконечного оборудования и введение списков разрешенного ПО. К техническим мерам – отключение уязвимых протоколов, правильная настройка сети (ограничение доступа к внешним ресурсам, блокировка портов и сервисов, отказ от использования незащищенных протоколов передачи данных). Рассмотрим системы организации мониторинга и защиты от угроз ИБ, изображенные на рисунке 2.

Рисунок 2

Для анализа трафика, взятого на периметре и в самой сети, на наличие используемых запрещенных протоколов и сервисов, используется Network Traffic Analysis (NTA) и Network Behavior Analysis (NBA). С помощью сравнения сигнатур и поведенческого анализа система NTA/NBA сможет распознать работу вредоносного ПО. Благодаря функциональным возможностям по работе с шифрованным трафиком и анализом протоколов возможно выявить аномалии в трафике. Поведенческий анализ и машинное обучение системы NTA/NBA позволит выявить странную активность в работе сети и попытки подбора учетных данных, которые порождают большое количество неуспешных аутентификаций. Данный факт будет виден в трафике.

Выявить угрозы безопасности сети и провести анализ поведения пользователей можно с помощью системы Data Leak Prevention (DLP), которая использует сбор данных с точек мониторинга локальной сети и с DLP-агентов, установленных на сетевом и абонентском оборудовании. Однако использование DLP-агентов может вызывать затруднения, ведь существуют устройства, на которые их невозможно установить. Причины могут быть разные – отсутствие доступа к ОС, нет поддержки ОС, конфликты с установленным ПО и прочие. Существует риск несанкционированного подключения к сети, когда пользователи могут подключать к сети свои личные устройства. В сети могут присутствовать контроллеры, различные датчики, которые генерируют большое количество трафика, но установить на такие устройства DLP-агенты невозможно. Стоит отметить, что вредоносное ПО может обходить мониторинг DLP-агента. В таких случаях анализ трафика локальной сети позволит системе DLP исключить описанные ограничения, наложенные DLP-агентами. Получая трафик с точек мониторинга локальной сети, система DLP сможет проводить анализ поведения всех устройств в сети в независимости, установлен ли на них DLP-агент или нет.

Система Security Information and Event Management (SIEM) собирает, анализирует логи различных приложений и на их основании может делать выводы о наличии угроз ИБ: подозрительный трафик и атаки, случаи заражения вредоносным ПО, нарушение регламентов ИБ пользователями. Работа системы SIEM со встроенным модулем NetFlow/sFlow заключается в следующем: трафик с точек мониторинга сети поступает на модуль NetFlow/sFlow, модуль NetFlow/sFlow анализирует трафик, формирует события и отправляет на SIEM, где проводится анализ и делается вывод о наличии угрозы ИБ. Таким образом, модуль NetFlow/sFlow собирает сетевую статистику по полученному трафику, а применение его совместно с SIEM позволяет осуществлять независимый от других приложений мониторинг сети на предмет угроз ИБ.

Система Intrusion Detection System (IDS) предназначена для обнаружения вторжений. Среди самых распространённых видов IDS можно выделить Perimeter Intrusion Detection Systems (PIDS) и Network Intrusion Detection System (NIDS). Система PIDS анализирует трафик, взятый с периметра сети (данный трафик может быть получен как с активного сетевого оборудования, так и с точки мониторинга на сети). Но не все угрозы ИБ можно выявить на периметре сети, они могут возникнуть внутри сети и не выходить наружу. Такие угрозы чаще всего возникают при подключении к сети несанкционированных устройств пользователей, подключении модемов, Wi-Fi адаптеров, заражение локальных устройств вирусами. Система NIDS получает и анализирует трафик с точек мониторинга, расположенных по всей локальной сети. Использование системы NIDS позволяет выявить все описанные угрозы ИБ.

Вместо заключения

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

Источник