Процедуры, диагностики и безопасность в Интернет

Сетевая диагностика с помощью SNMP и ICMP

Разбить на страницы
Показывать лекцию целиком

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

Так как сеть может быть построена с применением различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол SNMP, который служит для целей управления в Ethernet, ISDN, X.25, FDDI, ATM, SDH, TCP/IP и других сетях. Протокол SNMP ( std15, RFC- 1448, -1592, -1901, 1902-1907, 1908-1910, -3411-18, std0062 ) использует управляющую базу данных MIB (RFC- 1213, - 1158, -1792, -1042; std16, std17 ), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Чтобы база данных была доступна, необходимо наличие snmp -демона. Рассмотрим сеть, изображенную на рис 10.1.

(рис 10.1) Пример диагностируемой сети

Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол TCP/IP, возможно применение для целей диагностики протокола ICMP (RFC- 1256, -1788, -1885, -792). Этот протокол, так же, как и SNMP, пригоден для диагностики не только локальной сети, но и каналов Интернет. Если использовать ICMP не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, например, о DoS-атаке или ухудшении ситуации в отдельных сетевых сегментах. Но применение ICMP ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма не обширны.

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

Сеть ИТЭФ, которая была зарегистрирована в качестве узла Интернет в 1991 году, в настоящее время содержит более 1000 ЭВМ при суммарной длине кабельных сегментов около 15 км. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig, hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch, snmpman, netguard, ws_watch. Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное применение IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.

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

При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика, и для целей диагностики не все ее записи представляют интерес. Для написания нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):

interface.iftable.ifentry.ifinucastpktsЧисло полученных обычных пакетов;
interface.iftable.ifentry.ifinnucastpktsЧисло полученных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinerrorsЧисло ошибок при приеме пакетов;
interface.iftable.ifentry.ifoutucastpktsЧисло посланных обычных пакетов;
interface.iftable.ifentry.ifinnucastpktsЧисло посланных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinunknownprotosЧисло полученных пакетов с неизвестным кодом протокола;
ip.ipinreceivesПолное число IP-дейтограмм, включая полученные с ошибкой;
ip.ipinhdrerrorsЧисло входных IP-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, TTL и т.д.
ip.ipinaddrerrorsЧисло полученных пакетов с ошибкой в адресе;
ip.ipinunknownprotosЧисло входных IP-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой;
ip.ipreasmreqdsЧисло полученных фрагментов, которые требуют сборки;
ip.ipindeliversЧисло IP-дейтограмм, принятых без ошибок (включая ICMP );
icmp.icmpinmsgsЧисло полученных icmp -пакетов; (другие 10 контролируемых переменных ICMP -группы по соображениям экономии места из списка исключены);
udp.udpindatagramsЧисло принятых UDP-дейтограмм;
udp.udpoutdatagramsЧисло отправленных UDP-дейтограмм;
udp.udpnoportsПолное число UDP-дейтограмм, где не существует приложения для указанного номера порта;
udp.udpinerrorsЧисло UDP-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту;
tcp.tcpinsegsЧисло принятых TCP-сегментов;
tcp.tcpoutsegsЧисло отправленных TCP-сегментов;
tcp.tcpretranssegsЧисло tcp-сегментов с повторной пересылкой;
tcp.tcpoutrstsЧисло сегментов с флагом RST=1;
tcp.tcpinerrorЧисло TCP-сегментов, полученных с ошибкой.

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

Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так, переменная snmpinbadcommunityuses { snmp 5} может сообщить о попытках несанкционированного доступа к базе MIB. Переменные snmpintoobigs { snmp 8}, snmpingenerrs { snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы, и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д., полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, — последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать о неверном выборе MTU.

Рассмотрим средние значения некоторых переменных за сутки. Так, переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормальное. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети; если соотнести эти цифры с входным и выходным потоками пакетов, можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока или в результате грозы). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результатом работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки было мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках TCP-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети: чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок и не упомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP -активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.

(рис 10.2) Вариации tcpinsegs и udpindatagrams в течение недели

Для защищенных систем доступ к snmp -резиденту в пакетах должно использоваться поле community, равное паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp -пакетов пароль может быть открыт. По этой причине лучше ориентироваться на версию SNMPv3, если она поддерживается вашим оборудованием и программами. При написании программ нужно учитывать версии MIB, используемые анализируемыми узлами. Рассмотрим, как варьируются некоторые из перечисленных переменных в течение суток и недели. На рис 10.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый — понедельнику, но уже следующей недели. На рис 10.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность охватывает период с 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Небольшой фрагмент распечатки, выданной программой last на ЭВМ, snmp -резидентом которой пользовалась наша программа, приведен ниже.

ms977     pts/0   vitep5.itep.ru    tue sep 10 23:49 - 00:16 (00:27)
ms977     pts/2   vitep5.itep.ru    tue sep 10 22:20 - 23:46 (01:26)
ostrouh   pts/0   athene.itep.ru    tue sep 10 18:30 - 18:43 (00:13)
titovich  pts/0   athene.itep.ru    tue sep 10 18:30 - 18:30 (00:00)
vita      pts/3   athene.itep.ru    tue sep 10 14:55 - 15:56 (01:00)
checho    pts/12  itep05.itep.ru    tue sep 10 13:35 - 13:37 (00:01)
fomin     pts/10  hydra.ifh.de      tue sep 10 13:16 - 13:22 (00:06)
checho    pts/7   itep05.itep.ru    tue sep 10 13:09 13:16 (00:07)
illarion  pts/7   xt07.itep.ru      tue sep 10 12:45 12:45 (00:00)
vita      pts/9   athene.itep.ru    tue sep 10 11:55 13:03 (01:07)
bely      pts/12  pcx01.itep.ru     tue sep 10 11:49 12:02 (00:13)
vita      pts/13  athene.itep.ru    tue sep 10 11:49 11:52 (00:03)
ozero     pts/5   itep05.itep.ru    mon sep 09 18:05 18:32 (00:27)
olyalin   pts/6   itep05.itep.ru    mon sep 09 16:19 16:27 (00:08)
efre      ftp     pcx10.itep.ru     mon sep 09 16:14 16:15 (00:00)
mara      pts/1   hpl3pur2.cern.ch  mon sep 09 16:02 16:27 (00:24)
mara      pts/1   hpl3pur2.cern.ch  mon sep 09 15:50 15:54 (00:04)
itep977   pts/2   1mars.itep.ru     mon sep 09 15:22 15:23 (00:00)
ozero     pts/20  aix0.itep.ru      mon sep 09 15:06 15:36 (00:29)
ozero     pts/12  itep05.itep.ru    mon sep 09 14:56 14:56 (00:00)
galy      pts/16  athene.itep.ru    mon sep 09 14:27 14:31 (00:03)
bely      pts/15  vitep5.itep.ru    mon sep 09 14:09 10:36 (20:27)
sed       pts/5   pcx11.itep.ru     mon sep 09 14:01 14:01 (00:00)
kisel     pts/1   vxitep.itep.ru    mon sep 09 13:59 15:22 (01:22)
ozero     pts/12  itep05.itep.ru    mon sep 09 13:53 14:55 (01:02)
ozero     pts/2   193.148.166.214   mon sep 09 13:40 13:41 (00:00)
ozero     pts/8   193.148.166.214   mon sep 09 13:32 13:37 (00:04)
vita      pts/9   aix0.itep.ru      mon sep 09 13:32 13:32 (00:00)
galy      pts/1   athene.itep.ru    mon sep 09 10:57 10:58 (00:00)
titovich  pts/4   athene.itep.ru    mon sep 09 10:20 10:21 (00:01)
korol     pts/0   193.124.225.174   mon sep 09 05:20 05:57 (00:37)

Первая колонка содержит имена пользователей, вторая — тип задачи (PTS/n — удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet/ssh. Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Изучив, например, результаты работы программы last, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствие сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.

(рис 10.3) Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts

На рис 10.3 приведена вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 10.4а (19:00 — 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но, так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора MTU для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos).

(рис 10.5(а,б)) Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)(рис 10.4) Суточные вариации потоков UDP-дейтограмм

На рис 10.5(а,б) показаны суточные вариации потоков UDP-дейтограмм, а на рис 10.6(а,б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).

(рис 10.6(а,б)) Суточные вариации потоков UDP-дейтограмм

Диагностика на базе протокола ICMP

Безусловно, SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не позволит решить все проблемы. Не все объекты в Интернет имеют активные SNMP -агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах и из-за перегрузки канала.

Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика возможно из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты MAC-уровня).

Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP -протокола.

При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов.

Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента дает возможность оперативно локализовать неисправный сетевой элемент (см. рис 10.7). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это разрешает даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.

Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена). Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, но известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, которые обслуживают многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы.

(рис 10.7) Схема, поясняющая диагностические возможности протокола ICMP

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

Следует иметь в виду, что ICMP может найти применение при тестовых измерениях в современных методах анализа приложений в MPLS-TE с гарантированным качеством обслуживания. Протокол ICMP позволяет легко сформировать несколько потоков пакетов с одним и тем же адресом места назначения. Доставка пакетов контролируется по приходу откликов. Это проще, чем в случае использования протокола UDP, где нужно самому позаботиться о подтверждениях, или ТСР, когда нужно осуществить соединение и следовать правилам этого протокола. Такого рода техника была применена при исследовании свойств VPN ПРАН-ИАЭ, результат измерений доложен на III международной конференции "Интернет нового поколения — IPv6" в ИОХ в ноябре 2004 г ("Гарантированное качество обслуживания в рамках протокола MPLS").

Ниже на рисунке 10.8 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа не только позволяет отображать такого рода диаграммы, но и измеряет относительные потери для различных сегментов сети. По горизонтали отложено время суток 0-24 часа, а по вертикали — число ЭВМ, присылающих отклики на ICMP -запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)

(рис 10.8) Суточные вариации числа активных ЭВМ в сети ИТЭФ

Применение 6-го режима сетевого адаптера для целей диагностики

Освоение 6-го режима (promiscuous mode) работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты, адресованные ей, а также широковещательные и мультикастинг-пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и пароли привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля. Этот режим используется, например, известной программой sniffer.

6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей и определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности.

К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис 10.9).

(рис 10.9)

Выделенная ЭВМ может полностью отслеживать трафик из зоны сети "B" и лишь транзитный поток пакетов для зон A и C (например, из зоны А в зону C). Пакеты внутреннего трафика для зон А и C не доступны.

Страницы:

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

Так как сеть может быть построена с применением различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол SNMP, который служит для целей управления в Ethernet, ISDN, X.25, FDDI, ATM, SDH, TCP/IP и других сетях. Протокол SNMP ( std15, RFC- 1448, -1592, -1901, 1902-1907, 1908-1910, -3411-18, std0062 ) использует управляющую базу данных MIB (RFC- 1213, - 1158, -1792, -1042; std16, std17 ), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Чтобы база данных была доступна, необходимо наличие snmp -демона. Рассмотрим сеть, изображенную на рис 10.1.

(рис 10.1) Пример диагностируемой сети

Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол TCP/IP, возможно применение для целей диагностики протокола ICMP (RFC- 1256, -1788, -1885, -792). Этот протокол, так же, как и SNMP, пригоден для диагностики не только локальной сети, но и каналов Интернет. Если использовать ICMP не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, например, о DoS-атаке или ухудшении ситуации в отдельных сетевых сегментах. Но применение ICMP ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма не обширны.

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

Сеть ИТЭФ, которая была зарегистрирована в качестве узла Интернет в 1991 году, в настоящее время содержит более 1000 ЭВМ при суммарной длине кабельных сегментов около 15 км. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig, hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch, snmpman, netguard, ws_watch. Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное применение IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.

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

При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика, и для целей диагностики не все ее записи представляют интерес. Для написания нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):

interface.iftable.ifentry.ifinucastpktsЧисло полученных обычных пакетов;
interface.iftable.ifentry.ifinnucastpktsЧисло полученных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinerrorsЧисло ошибок при приеме пакетов;
interface.iftable.ifentry.ifoutucastpktsЧисло посланных обычных пакетов;
interface.iftable.ifentry.ifinnucastpktsЧисло посланных широковещательных и мультикаст-пакетов;
interface.iftable.ifentry.ifinunknownprotosЧисло полученных пакетов с неизвестным кодом протокола;
ip.ipinreceivesПолное число IP-дейтограмм, включая полученные с ошибкой;
ip.ipinhdrerrorsЧисло входных IP-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, TTL и т.д.
ip.ipinaddrerrorsЧисло полученных пакетов с ошибкой в адресе;
ip.ipinunknownprotosЧисло входных IP-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой;
ip.ipreasmreqdsЧисло полученных фрагментов, которые требуют сборки;
ip.ipindeliversЧисло IP-дейтограмм, принятых без ошибок (включая ICMP );
icmp.icmpinmsgsЧисло полученных icmp -пакетов; (другие 10 контролируемых переменных ICMP -группы по соображениям экономии места из списка исключены);
udp.udpindatagramsЧисло принятых UDP-дейтограмм;
udp.udpoutdatagramsЧисло отправленных UDP-дейтограмм;
udp.udpnoportsПолное число UDP-дейтограмм, где не существует приложения для указанного номера порта;
udp.udpinerrorsЧисло UDP-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту;
tcp.tcpinsegsЧисло принятых TCP-сегментов;
tcp.tcpoutsegsЧисло отправленных TCP-сегментов;
tcp.tcpretranssegsЧисло tcp-сегментов с повторной пересылкой;
tcp.tcpoutrstsЧисло сегментов с флагом RST=1;
tcp.tcpinerrorЧисло TCP-сегментов, полученных с ошибкой.

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

Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так, переменная snmpinbadcommunityuses { snmp 5} может сообщить о попытках несанкционированного доступа к базе MIB. Переменные snmpintoobigs { snmp 8}, snmpingenerrs { snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы, и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д., полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, — последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать о неверном выборе MTU.

Рассмотрим средние значения некоторых переменных за сутки. Так, переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормальное. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети; если соотнести эти цифры с входным и выходным потоками пакетов, можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока или в результате грозы). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результатом работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки было мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках TCP-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети: чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок и не упомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP -активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.

(рис 10.2) Вариации tcpinsegs и udpindatagrams в течение недели

Для защищенных систем доступ к snmp -резиденту в пакетах должно использоваться поле community, равное паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp -пакетов пароль может быть открыт. По этой причине лучше ориентироваться на версию SNMPv3, если она поддерживается вашим оборудованием и программами. При написании программ нужно учитывать версии MIB, используемые анализируемыми узлами. Рассмотрим, как варьируются некоторые из перечисленных переменных в течение суток и недели. На рис 10.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый — понедельнику, но уже следующей недели. На рис 10.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность охватывает период с 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Небольшой фрагмент распечатки, выданной программой last на ЭВМ, snmp -резидентом которой пользовалась наша программа, приведен ниже.

ms977     pts/0   vitep5.itep.ru    tue sep 10 23:49 - 00:16 (00:27)
ms977     pts/2   vitep5.itep.ru    tue sep 10 22:20 - 23:46 (01:26)
ostrouh   pts/0   athene.itep.ru    tue sep 10 18:30 - 18:43 (00:13)
titovich  pts/0   athene.itep.ru    tue sep 10 18:30 - 18:30 (00:00)
vita      pts/3   athene.itep.ru    tue sep 10 14:55 - 15:56 (01:00)
checho    pts/12  itep05.itep.ru    tue sep 10 13:35 - 13:37 (00:01)
fomin     pts/10  hydra.ifh.de      tue sep 10 13:16 - 13:22 (00:06)
checho    pts/7   itep05.itep.ru    tue sep 10 13:09 13:16 (00:07)
illarion  pts/7   xt07.itep.ru      tue sep 10 12:45 12:45 (00:00)
vita      pts/9   athene.itep.ru    tue sep 10 11:55 13:03 (01:07)
bely      pts/12  pcx01.itep.ru     tue sep 10 11:49 12:02 (00:13)
vita      pts/13  athene.itep.ru    tue sep 10 11:49 11:52 (00:03)
ozero     pts/5   itep05.itep.ru    mon sep 09 18:05 18:32 (00:27)
olyalin   pts/6   itep05.itep.ru    mon sep 09 16:19 16:27 (00:08)
efre      ftp     pcx10.itep.ru     mon sep 09 16:14 16:15 (00:00)
mara      pts/1   hpl3pur2.cern.ch  mon sep 09 16:02 16:27 (00:24)
mara      pts/1   hpl3pur2.cern.ch  mon sep 09 15:50 15:54 (00:04)
itep977   pts/2   1mars.itep.ru     mon sep 09 15:22 15:23 (00:00)
ozero     pts/20  aix0.itep.ru      mon sep 09 15:06 15:36 (00:29)
ozero     pts/12  itep05.itep.ru    mon sep 09 14:56 14:56 (00:00)
galy      pts/16  athene.itep.ru    mon sep 09 14:27 14:31 (00:03)
bely      pts/15  vitep5.itep.ru    mon sep 09 14:09 10:36 (20:27)
sed       pts/5   pcx11.itep.ru     mon sep 09 14:01 14:01 (00:00)
kisel     pts/1   vxitep.itep.ru    mon sep 09 13:59 15:22 (01:22)
ozero     pts/12  itep05.itep.ru    mon sep 09 13:53 14:55 (01:02)
ozero     pts/2   193.148.166.214   mon sep 09 13:40 13:41 (00:00)
ozero     pts/8   193.148.166.214   mon sep 09 13:32 13:37 (00:04)
vita      pts/9   aix0.itep.ru      mon sep 09 13:32 13:32 (00:00)
galy      pts/1   athene.itep.ru    mon sep 09 10:57 10:58 (00:00)
titovich  pts/4   athene.itep.ru    mon sep 09 10:20 10:21 (00:01)
korol     pts/0   193.124.225.174   mon sep 09 05:20 05:57 (00:37)

Первая колонка содержит имена пользователей, вторая — тип задачи (PTS/n — удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet/ssh. Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Изучив, например, результаты работы программы last, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствие сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.

(рис 10.3) Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts

На рис 10.3 приведена вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 10.4а (19:00 — 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но, так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора MTU для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos).

(рис 10.5(а,б)) Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)(рис 10.4) Суточные вариации потоков UDP-дейтограмм

На рис 10.5(а,б) показаны суточные вариации потоков UDP-дейтограмм, а на рис 10.6(а,б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).

(рис 10.6(а,б)) Суточные вариации потоков UDP-дейтограмм

Диагностика на базе протокола ICMP

Безусловно, SNMP предоставляет наиболее мощные и универсальные возможности диагностики. Но этот протокол не позволит решить все проблемы. Не все объекты в Интернет имеют активные SNMP -агенты. Как было описано в разделе Ping, протокол ICMP позволяет проверить доступность пути от машины оператора до любой ЭВМ, включенной в Интернет. При этом может быть измерено время пакета в пути и вероятность потери пакета. Проводя такое зондирование периодически и сравнивая результаты для разных моментов времени и разных путей, можно получить важную диагностическую информацию. Время пакета в пути может стать важным параметром для тестирования внешних каналов, ведь задержка может расти из-за потерь пакетов на некоторых этапах и из-за перегрузки канала.

Потеря пакета может произойти как по пути туда, так и по пути обратно. Кроме того, отсутствие отклика возможно из-за перегрузки буфера или процессора ЭВМ-адресата. В локальных сетях при нормальных условиях потеря может случиться только из-за переполнения буферов в переключателях или ЭВМ (объекты MAC-уровня).

Более информативным может стать сочетание зондирования с помощью пакетов ICMP и контроль втекающих и вытекающих потоков сегмента посредством SNMP -протокола.

При использовании процедуры ping (с необходимыми опциями) для зондирования внешних каналов можно выявить как циклы пакетов, так и осцилляции маршрутов.

Протокол ICMP при круглосуточном мониторинге позволяет контролировать активность всех узлов локальной сети. Кроме того, такая программа в случае выхода из строя какого-то сегмента дает возможность оперативно локализовать неисправный сетевой элемент (см. рис 10.7). Сканирующая программа должна использовать в качестве исходной информации базу данных всех узлов локальной сети, куда должны быть помещены IP- и MAC-адреса всех сетевых узлов, их имена, географическое положение, фамилия хозяина и другая необходимая информация, например, суммарная задержка от какой-то точки в сети до данной рабочей станции. Результаты работы этой диагностической программы заносится в файлы, доступные для диагностического WWW-сервера. Такие данные упрощают поиск причины в случае аварии, так как позволяют проконтролировать активность в сети накануне появления отказа. Если такая программа одновременно измеряет все основные информационные потоки, она поможет выявить самые слабые участки в сети, выявить источники слишком частых широковещательных запросов. Теоретически это разрешает даже динамически реконфигурировать потоки в локальной сети, устраняя узкие места.

Пусть диагностическая ЭВМ занимает положение в сети, помеченное буквой D. Сканирующая программа, позволяя проверить доступность любой из ЭВМ, может выявить неисправный вход/выход любого из повторителей, хотя сами эти приборы пассивны и на пакеты ICMP откликов не присылают. Это определяется по наличию или отсутствию отклика от хотя бы одной ЭВМ, подключенной к исследуемому входу/выходу. Так, если ни одна ЭВМ сегмента Б не откликается, то можно сделать вывод, что выход 3 повторителя 2 не исправен (предполагается, что хотя бы одна машина сегмента Б включена). Аналогичным образом можно проверить выходы повторителя 1. Если же не откликаются ЭВМ сегментов А и Б, то весьма вероятен отказ моста. Если же ни одна из ЭВМ, показанных на рисунке, не присылает отклика, но известно, что они включены, то не исправен повторитель 1. Конечно, эту задачу можно решить и с помощью стандартной программы PING, но это займет много больше времени. Администраторы, которые обслуживают многомашинные сети, размещенные во многих зданиям, безусловно оценят преимущества сканирующей программы.

(рис 10.7) Схема, поясняющая диагностические возможности протокола ICMP

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

Следует иметь в виду, что ICMP может найти применение при тестовых измерениях в современных методах анализа приложений в MPLS-TE с гарантированным качеством обслуживания. Протокол ICMP позволяет легко сформировать несколько потоков пакетов с одним и тем же адресом места назначения. Доставка пакетов контролируется по приходу откликов. Это проще, чем в случае использования протокола UDP, где нужно самому позаботиться о подтверждениях, или ТСР, когда нужно осуществить соединение и следовать правилам этого протокола. Такого рода техника была применена при исследовании свойств VPN ПРАН-ИАЭ, результат измерений доложен на III международной конференции "Интернет нового поколения — IPv6" в ИОХ в ноябре 2004 г ("Гарантированное качество обслуживания в рамках протокола MPLS").

Ниже на рисунке 10.8 показан результат круглосуточного мониторинга в сети ГНЦ ИТЭФ. Программа не только позволяет отображать такого рода диаграммы, но и измеряет относительные потери для различных сегментов сети. По горизонтали отложено время суток 0-24 часа, а по вертикали — число ЭВМ, присылающих отклики на ICMP -запросы. Нетрудно видеть, что днем активных ЭВМ больше, чем ночью. :-)

(рис 10.8) Суточные вариации числа активных ЭВМ в сети ИТЭФ

Применение 6-го режима сетевого адаптера для целей диагностики

Освоение 6-го режима (promiscuous mode) работы сетевого интерфейса предоставляет необычные возможности администратору и таит в себе немалые угрозы в случае использования его хакером. Как известно практически любая сетевая карта имеет 6 режимов работы. Обычно она работает в 3-ем режиме, воспринимая все пакеты, адресованные ей, а также широковещательные и мультикастинг-пакеты. В 6-ом же режиме карта пытается принять все пакеты, следующие по сегменту, вне зависимости от адреса места назначения. Если позволяет загрузка и быстродействие сетевого интерфейса, будут восприняты и обработаны все пакеты, следующие по сегменту, к которому подключена ЭВМ, работающая в 6-ом режиме. Именно по этой причине желательно при осуществлении авторизации использовать шифрованный обмен. В противном случае хакер, чья ЭВМ подключена к сетевому сегменту, может получить все пароли, в том числе и пароли привилегированных пользователей. Если шифрование обмена при авторизации недоступно, привилегированные (root) пользователи должны ограничиться работой через консоль. Выполнение привилегированных операций с удаленной ЭВМ не желательно, так как может привести к раскрытию системного пароля. Этот режим используется, например, известной программой sniffer.

6-ой режим позволяет проанализировать распределение пакетов по коду протокола, по адресам отправителей или получателей и определить парциальные значения трафиков отдельного пользователя для различных видов услуг. Некоторые виды перечисленных данных можно получить из MIB маршрутизатора (например, Accounting database в случае маршрутизаторов CISCO), но 6-й режим предоставляет большую гибкость и возможности.

К сожалению, данная методика применима лишь к пакетам, проходящим через сегмент, к которому подключена ЭВМ, работающая в 6-ом режиме (см. рис 10.9).

(рис 10.9)

Выделенная ЭВМ может полностью отслеживать трафик из зоны сети "B" и лишь транзитный поток пакетов для зон A и C (например, из зоны А в зону C). Пакеты внутреннего трафика для зон А и C не доступны.

Предыдущее занятие Следующее занятие
Вернуться к учебному плану
^