Современные методы и средства контроля и диагностики в корпоративных сетях передачи данных

Статья доложена Ю.А.Семеновым на конференции ICSNET'2001, Москва, 19 декабря 2001 года


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

Подавляющее число локальных сетей построены на основе протокола Ethernet, а межсетевые соединения реализованы с привлечением стека протоколов TCP/IP, работающего поверх какого-то протокола физического уровня. Возможности мониторинга предоставляют два протокола из этого стека – ICMP и SNMP, последний позволяет осуществлять и управление. Здесь не рассматриваются проблемы, возникающие при передаче мультимедийных данных. Протокол SNMP для рассматриваемых целей наиболее удобен, так как поддерживается практически всеми сетями, в том числе и неработающими со стеком протоколов TCP/IP.

Перед сетевым администратором обычно встают следующие задачи:

  1. Своевременное выявление отказов в сети (отключение сервера или рабочей станции, отказ маршрутизатора или сетевого повторителя)
  2. Оперативное детектирование отказов во внешних каналах.
  3. Своевременное выявление узких мест в сети и источников ненадежности (перегруженных сегментов или неустойчиво работающего оборудования)
  4. Мониторинг внешних и внутренних сетевых атак (сканирований, DoS-атак и т.д.)

Характер этих задач существенно зависит от размера и топологии сети, а также от требований безопасности. Существует достаточно большое число коммерческих продуктов, например OpenView (Hewlett Packard). Эти продукты предоставляют неплохие возможности, но весьма дороги (от 2000 до 40000$). А в тех случаях, когда вы сталкиваетесь с нестандартными проблемами, они вам просто не помогут. К счастью современные программные технологии (XML, CGI, JavaScript и т.д.) позволяют решить такие задачи достаточно легко и с небольшими трудозатратами. В качестве иллюстраций решения перечисленных проблем будет использоваться опыт работы сети Института Теоретической и Экспериментальной физики (ИТЭФ, подключен к Интернет в 1991г), в которой работает более 600 ЭВМ различного типа на основе разнородных ОС (см. http://saturn.itep.ru).

Задачи мониторинга обрывов связи наиболее естественным образом решаются с помощью протокола ICMP (знакомая многим утилита ping). Программа, осуществляющая мониторирование, может быть написана на Си, Java, Perl или каком-то ином языке. Современные программные технологии (HTML, XML в сочетании с JavaScript) позволяют создать простую наглядную и при необходимости интерактивную схему контроля, показанную на рисунках 1, 2, 3 и 4 (смотри, например, http://saturn.itep.ru/trace/extern/start_trace.htm; ~/intern/start.htm; ~/computer_n/ping-all-hosts.html; и ~/blocks/start.htm)..

В первом примере контролируется связность внешних каналов. При этом доступные узлы после успешного зондирования окрашиваются в зеленый цвет, а недоступные - в красный (как это показано на рисунках 1 и 2). При желании можно отображать и процент потерь пакетов на интересующем участке сети или канала. Данная опция позволяет оценить надежность и загруженность канала. С помощью этой технологии можно мониторировать подключение рабочих станций к локальной сети (Рис. 3). Результаты мониторинга могут заноситься в базу данных. Эта технология позволяет руководителю контролировать активность своих сотрудников. На рисунке видно, что по субботам и воскресеньям наблюдается ощутимый спад активности. Эффективность такой программы существенно возрастает, если попутно мониторируются процессы, запущенные на рабочих станциях.

На рис. 4. показан результат мониторинга активных IP-адресов в некотором С-блоке. Такой мониторинг при сопоставлении полученных результатов с данными из конфигурационной базы данных позволяет выявить нелегальное использование IP-адресов. В принципе данная программа во многом эквивалентна предыдущей.

Техника ICMP-зондирования может позволить выявить потенциально ненадежные участки сети или каналов. Если при зондировании регистрировать число потерянных пакетов (запросов или откликов), можно определить с определенной точностью объект, создающий помехи нормальной работе сети. Это может быть перегруженный переключатель или кабельный сегмент, работающий в условиях повышенных наводок или имеющий плохой контакт. Мною была написана программа, посылающая ICMP-запросы нарастающей длины (от 64 до 1500 байт). Если при зондировании какой-то ЭВМ при длинных кадрах вероятность потери кадра больше, это говорит о плохом контакте или сильных наводках по дороге. Сопоставляя результаты зондирования ЭВМ, подключенных к разным сегментам, можно локализовать дефектный участок. Аналогично можно выявить перегруженные элементы сети и своевременно модифицировать топологию или заменить сетевой прибор на более быстродействующий.



16 октября 2002 г. 13:22:18
Рис. 1. Мониторирование внешних каналов сети ИТЭФ


Одной из проблем, с которой довольно часто сталкиваются администраторы, – дублирование IP-адресов в сети. Мне приходилось столкнуться и с дублированием МАС-адресов, чего в принципе не должно быть никогда. Начинать надо с создания и поддержания конфигурационной базы данных сети, куда заносятся IP- и МАС-адреса ЭВМ, их имена, имя, e-mail и телефон владельца, место размещения и пр. Дублирование IP обычно приводит к нарушению соответствия адресов IP-MAC.


Рис. 2. Контроль обрывов в локальной сети ИТЭФ


Количество работающих машин в сети ИТЭФ
Зависимость числа активных машин от времени (текущие сутки)
на 16 октября 2002 г. 13:19:51


Зависимость числа активных машин от времени (текущая неделя)

Рис. 3. Активность рабочих станций в локальной сети ИТЭФ.


C-блок 193.124.127.0
  0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1 2 3 4 5 6 7 8 9 40 1 2 3 4 5 6 7 8 9
0

50

100

150

200

250

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Число активных ЭВМ в этом блоке = 27
16 октября 2002 г. 13:08:26
Рис. 4. Мониторирование активных адресов в заданном С-блоке IP-адресов


Локализовать нарушителя достаточно сложно, для этого нужно считывать ARP-кэши внутренних маршрутизаторов, а в некоторых случаях с помощью специальной SNMP-программы последовательно закрывать каналы переключателей (для этого они должны быть управляемыми!) или хабов. Но даже в этом случае локализация возможна с точностью до канала или сегмента. Эта же техника применима для локализации DoS-атак (Denial of Service), когда атакер находится внутри локальной сети.

Широко используется сетевыми администраторами утилита traceroute, которая позволяет отследить маршрут от вашей ЭВМ до определенного объекта в Интернет, а в некоторых случаях и обратно. Последнее свойство полезно для выявления ошибок маршрутизации. Эта утилита использует специальную опцию протокола IP. В последнее время появилось несколько реализаций traceroute, где возможно использование протоколов TCP, UDP или ICMP. Техника базируется на посылке адресату последовательности пакетов со значениями TTL = 1, 2, 3,… и т.д. Отправителю будут присылаться ICMP уведомления об истечении TTL от промежуточных узлов маршрута, до тех пор, пока значение TTL не станет достаточным. Эта техника не позволяет отследить обратный маршрут.

Важной характеристикой как внешних, так и внутренних каналов является их загрузка. Для мониторирования загрузки канала в байтах или в пакетах в секунду незаменимым является протокол SNMP. В случае маршрутизаторов фирмы CISCO можно использовать утилиту NetFlow. Ощутимую помощь сетевикам оказал Тобиас Оетикер, разработавший и предоставивший в свободном доступе программу MRTG (http://mrtg.hdl.com/mrtg.html). Эта легко конфигурируемая программа осуществляет доступ с помощью SNMP к базе MIB (Management Information Base) нужного объекта (маршрутизатора или сетевого переключателя) и формирует временные диаграммы потоков через указанный вами интерфейс. Пример результата работы этой программы с внешним маршрутизатором ИТЭФ показан на рис. 5.


Диаграмма входного и выходного потоков за сутки.

То же за неделю.

То же за месяц

Packet flow for C-4000.

Вертикальными красными линиями обозначены концы суток, недели, месяца
Рис. 5. Временные зависимости входных и выходных потоков внешнего канала ИТЭФ


Следует заметить, что только SNMPv3 предоставляет достаточные гарантии безопасности. В более ранних версиях поле community (пароль) передается открытым текстом, что предоставляет неплохие шансы для хакеров.

База MIB допускает мониторирование не только потоков, но и получение самых разных данные, например, соотношение потоков Unicast/NonUnicast кадров. Эти данные позволяют регистрировать сбои в сети, когда какое-то устройство формирует большой поток широковещательных запросов, или какие-то любители запустили просмотр видео-фильма через сеть. Из MIB можно считать число попыток повторной передачи, что наряду с вероятностью потери пакета, характеризует соответствующий канал. Мониторирование запросов фрагментации может помочь выбрать оптимальное значение MTU, список разнообразных возможностей можно продолжать достаточно долго.


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


Неисчерпаемым и крайне важным источником данных являются различные журнальные файлы (LOG-файлы), имеющие обычно текстовый формат. Их просмотр является служебной обязанностью любого администратора. Журнальные файлы просматриваются на предмет необычной активности или активности в необычное время. Работа эта может быть существенно облегчена, если написать специальный скрипт (наиболее удобно это сделать на языке PERL), осуществляющий анализ того или иного журнального файла, например, создаваемого почтовым сервером. Пример такого анализа за сутки можно увидеть на рис. 6.



Рис. 6. Результат анализа журнального файла почтового сервера за сутки


Опытный сетевик может получить нужные ему данные из самых разных источников, в частности с привлечением протоколов Finger и WINS (см. http://book.itep.ru/4/42/nbio_423.htm). Последний среди прочего позволяет удаленно считать МАС-адрес сетевого интерфейса ЭВМ, работающей под операционной системой Windows. Эта технология помогает также автоматически выявлять любые изменения IP- или MAC-адресов в локальной сети даже за маршрутизаторами. Любая сеть, предоставленная самой себе, рано или поздно перестает работать, но все чаще в этот процесс вмешивается человеческий фактор.

Число официально зарегистрированных в мире сетевых инцидентов различного рода возрастает экспоненциально (см. http://www.cert.org/stats/). Этот рост совпадает с ростом числа узлов в Интернет. Полное число сигнатур (типов) атак в настоящее время уже превосходит 650. Атаки можно отнести к нескольким классам (вирусы, сетевые черви, кролики, молдавская связь и пр. здесь не рассматриваются):

  • Базирующиеся на дефектах протоколов, например, TCP или их реализаций, например, SSH.
  • Использующие дефекты и ошибки операционной системы (UNIX, Apache)
  • Пытающиеся найти и воспользоваться дефектами программ-приложений, включая, например, CGI
  • Эксплуатирующие человеческие слабости (любопытство, алчность и пр., например, попытки заслать троянского коня путем приглашения участия в бесплатной лотерее или игры в сетевом казино)

К первому типу относятся и атаки типа SMURF, ICMP flood и TCP SYN flood. ICMP flood не использует эффектов усиления на локальных широковещательных адресах, а работает с адресами типа 255.255.255.255. Здесь следует заметить, что для аналогичных целей хакеры могут использовать как протоколы TCP, так и UDP. В последнее время число атак сети ИТЭФ растет экспоненциально и достигает 150-300 в сутки. Число успешных атак оценивается как 1-3 в месяц.

В сети ИТЭФ зарегистрирован новый вид атак - имитация SMURF. При этой атаке с машины атакера посылается последовательность ICMP-пакетов, с адресами места назначения, например, 193.124.225.1, 193.124.225.2 и т.д. до 193.124.225.255, при этом в качестве адреса отправителя проставляется IP-адрес атакуемой машины. Такую атаку трудно выявить и еще труднее найти виновника, даже если он находится в локальной сети. Определить его можно только по MAC-адресу в реальном масштабе времени, если машина-ловушка находится в той же субсети, что и ЭВМ атакера.

Оказалось возможным и эту задачу переложить на ЭВМ с привлечением протоколов SNMP и ICMP. Дело в том, что данный вид атаки порождает большое число относительно коротких пакетов, что в некоторых случаях может заблокировать работу маршрутизатора (когда поток пакетов превышает (5000-10000)/сек). Именно это обстоятельство и используется для локализации машины атакера. Программа регистрирует и отображает уровень потоков пакетов на всех интерфейсах внутренних маршрутизаторов и переключателях (протокол SNMP). При достижении уровня больше 2000/сек на экран оператора выводятся временные диаграммы потоков 8 наиболее загруженных интерфейсов. После этого производится запрос в базу данных и получается список IP-адресов машин в сегменте-источнике потока пакетов. Эти адреса зондируются с помощью пакетов ICMP и выявляется ЭВМ с наибольшей вероятностью потери пакета и с наибольшим значением RTT. Далее следует запрос в базу данных и выявляется ее владелец. Остальное дело техники…

Защищаться от внешних атак можно с помощью FireWall для всей сети или посредством BlackICE Defender для конкретной ЭВМ. Но любой FireWall бессилен из-за того что в любой большой сети найдется пользователь, который, уходя домой, переключит свой служебный телефон на модем. Атаковать такого пользователя легко, а в сети после успешной атаки это будет выглядеть как атака с одной из машин локальной сети. Я уже не говорю, что любой коммерческий продукт не может гарантировать отсутствия люков или “черных ходов”, допускающих разработчика программы куда угодно. Программа же, написанная по вашему заданию, имеет доступные исходные тексты, и при желании вы всегда можете проверить ее на наличие каких-либо “закладок”.

Сегодняшняя ситуация не позволяет оставлять проблему безопасности без внимания. Большинство систем FireWall предоставляют достаточные средства мониторинга атак (например, CISCO ). Но ситуация в этой сфере меняется слишком быстро и многие системы не поспевают за прогрессом у хакеров (их слишком много и они сотрудничают друг с другом). Чтобы успешно противостоять напору атакеров, потенциальные жертвы должны начать сотрудничать. Первым таким шагом могло бы быть создание всемирной базы данных потенциальных атакеров (лиц, которые осуществляют сканирование сети Интернет, или замечены за использованием чужих ЭВМ для атак других машин). Для пополнения такой базы можно использовать систему, показанную на рис. 7. Машина монитора атак имеет два сетевых интерфейса. Один из них воспринимает все пакеты, поступающие на вход сети, и не имеет IP-адреса, что исключает непосредственную атаку такой ЭВМ. Второй интерфейс подключен к порту внутреннего маршрутизатора в защищенной части локальной сети. Функцией монитора атак является выявление всех известных видов атак и ведение журнала атак. Некоторая программа, которая может работать и на другой машине в защищенной части локальной сети может считывать содержимое журнального файла и производить его анализ.



Рис. 7. Схема мониторинга внешних атак локальной сети


Такая схема была реализована нами. Это позволило уже на первом этапе выявить распределение атак по номеру порта, по типам доменов и по времени суток. Смотри http://book.itep.ru/6/intrusions.htm. Написана программа для обработки текстовых журнальных файлов. Анализ некоторых видов таких файлов показал, что для более половины атакеров IP-адресу не соответствует никакого имени. Но оперативное исследование с помощью утилиты traceroute позволяет определить их сервис провайдера. Далее программа с помощью утилиты whois выявляется e-mail администратора сервис-провайдера. С помощью протокола WINS часто можно узнать МАС-адрес их ЭВМ (а это почти то же, что и серия и номер паспорта). Таким образом, у администратора атакованной сети появляется возможность в полуавтоматическом режиме уведомить по почте сервис провайдера о работе в их сети машины хакера.

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