Анализ существующих к моменту начала исследований средств наблюдения в локальных (ЛВС) и корпоративных (КВС) вычислительных сетях показал [1], что наряду с дорогостоящими в те времена общецелевыми пакетами и наличием обширной группы разноцелевых хакерских средств, имеется явный недостаток дешевых средств постоянного наблюдения. Было показано [2], что остается актуальной как задача круглосуточного аудита сети, так и полноценный мониторинг действий конкретных пользователей. Предложенный автором метод мониторинга корпоративной сети на основе сплошного неинтерактивного низкоуровневого круглосуточного наблюдения датаграмм с помощью выделенной наблюдающей станции (НС) был реализован в ЦЭМИ РАН с 2000 г. Практически сразу же после внедрения оказалось возможным решить целый ряд актуальных задач: получить полные данные о трафике в сети по ряду первичных показателей (общий объем трафика в пакетах и байтах, средняя и максимальная скорость в сети, процент бродкастинга и др.), выделить Интернет-компоненту трафика, получить данные об относительном распределении TCP/IP-пакетов и пакетов Novell Netware. Оказалось возможным также решать ряд задач по конкретным пользователям: установить время их сетевой активности, определять некорректно настроенные ПК, идентифицировать незаконное появление новых пользователей в сети, по косвенным данным определять возможную зараженность ПК и серверов сетевыми вирусами.
Пятилетний опыт эксплуатации этой системы позволил сделать ряд важных выводов. Во-первых, после внедрения этой системы с течением времени появилось желание существенно расширить круг решаемых задач. Помимо сопровождения сети и анализа общего трафика, появилась необходимость в углубленном анализе сетевых сервисов [3], в постоянном отслеживании одного или сразу нескольких выделенных ПК [4], в уточненном анализе даже простых с виду сетевых протоколов [5]. Существенно важным для развития сети оказалось более полное исследование внутрисетевого трафика [6]. Возникла потребность и в чисто коммерческих приложениях [7]. Особую актуальность в связи с современной вирусной обстановкой представляет интеграция НС со средствами автоматического отсечения зараженных ПК [8], превращая сетевой мониторинг в интегрированную систему полноценного аудита. Полный спектр задач современной актуальности подробно обсужден в [9]. Таким образом, сфера потребных приложений созданной системы мониторинга постоянно расширяется.
Во-вторых, корпоративная сеть института, на которой в течение этих лет опробывалась работа системы, также не стояла на месте. Однофрагментная структура локальной сети, в которой в каждый момент времени возможна работа только одного сетевого адаптера [1], оказалась слишком сильно связанной, не отвечающей реальным потребностям пользователей и потому тормозящей развитие сети. Два самостоятельных направления решения проблемы развязывания трафика ЛВС представлены двумя работами данного сборника – о вводе в действие центрального коммутатора [10] и о формировании выделенных сегментов в сети [6]. Таким образом, в многофрагментной сети меняется смысл мониторинга: тотальное слежение за трафиком всех сетевых устройств заменяется отслеживанием основных и интерсегментных связей (хотя, как, собственно, и показано в [10], ничто не мешает увеличить число наблюдающих станций для дополнительного отслеживания нужных сегментов).
С другой же стороны, выбранный метод программной реализации средств мониторинга не позволяет бесконечно добавлять все новые функции в существующий комплекс программ. Следует отметить, что уже показанное в [10] решение о вводе центрального коммутатора с выделением на нем мониторного порта резко увеличило поток наблюдаемых пакетов. В дальнейшем эта тенденция усилилась. Для иллюстрации достаточно рассмотреть развитие сети института в срезах ее трафика за последние годы (рис. 1, 2, 3). Даже на приведенных рисунках заметно существенное увеличение пиковых значений: графики построены с интервалом в 1 час по оси времени, так что если ранее пределом пересылок было 10Гб/час, то к данному моменту предельные значения превысили 13 Гб/час.
Хорошей иллюстрацией в этом смысле стал сентябрь 2003 г.: на рис. 2 ясно видно, что с 1 по 8 сентября ЛВС ЦЭМИ РАН была заражена сетевыми вирусами и постоянно выбрасывала в Интернет весьма высокие для однофрагментной сети объемы информации. Из того же графика ясно, что основная НС вышла из строя и бездействовала с 20 по 25 сентября.
Программное обеспечение НС, созданное в 2000 г., с тех пор постоянно совершенствовалось в целях добавления все новых и новых функций. В результате первоначально успешный вариант, представлявший, собственно, экспериментальную пилот-систему, стал сильно перегружен по ресурсным характеристикам и неоптимальным по программной реализации. Даже поэтапное увеличение мощности процессора НС с AMD-DX4-120 на Celeron-266, а затем на PentiumIII-666, заметно снизив нагрузку на НС в подавляющем отрезке времени суточного наблюдения, тем не менее в пиковые периоды приводила к заметным отказам в обработке пакетов.
Рис. 1. Сводный трафик за сентябрь 2002 г.
При эксплуатации пилот-версии обнаружились и другие проблемы. В частности, отсутствовала специфическая реакция на переполнение оперативной таблицы ip-адресов, не всегда корректно срабатывал общий блок обработки ошибок, и др.
В связи со сказанным, в последнее время был полностью переработан весь комплекс программ сетевого мониторинга для получения полноценной эксплуатационной версии. Предварительно был проведен ряд дополнительных исследований. Ниже в данной работе перечислены выполненные исследования и описаны принятые решения.
В настоящее время основная НС реализована на Pentium-4 (Celeron)-1500МГц, однако даже такие мощности без кардинальной реорганизации программных средств оказались неэффективными.
Рис. 2. Сводный трафик за сентябрь 2003 г.
Рис. 3. Сводный трафик за сентябрь 2004 г.
Стандартный сетевой адаптер рабочей станции (РС) сети на основе Ethernet-II можно перевести в специальный режим Promiscuous Mode, который позволяет передавать в обрабатывающую программу все пакеты, циркулирующие в сети. Автором предложено [1] использовать эту возможность для организации системы круглосуточного наблюдения (мониторинга) за трафиком всех пакетов в сети, с регистрацией исходного и результирующего технологических сетевых адресов (MAC-адресов). Такую систему, представлялось, целесообразно строить на следующих принципах.
Первоначальная пилот-система мониторинга с соблюдением указанных принципов была успешно реализована [2] в MS-DOS 6.22, позволяя решать ряд разнообразных задач аудита и мониторинга. Естественно, накопив многолетний опыт применения этой системы и представляя возможность ее применения в полном спектре задач аудита [17], при разработке комплекса программ автоматического управления сетью был сделан выбор уже апробированной системы мониторинга как базового наблюдающего средства.
Дополняющим программным средством, использующимся для просмотра и коррекции оперативной БД, просмотра отчетов, переписи файлов и т.д., служит файловая оболочка Волков-Коммандер. Все программное обеспечение размещено на 1 загрузочной дискете MS-DOS.
После развертки системы исполняется создание первоначальной БД из одной строки, указывающей на гейт Интернета, и НС запускается в нужном режиме. По мере выявления работоспособных сетевых устройств, БД пополняется их MAC-адресами и легко может быть дополнена необходимыми текстовыми идентификаторами пользователей.
При работе НС вывод информации исполняется в расширенном текстовом режиме (50 строк по 80 символов) одновременно в 4 области видеопамяти. Оператор может переключиться на отображение на экране монитора любой из 4-х областей.
Верхние 6 строк, содержащие наиболее важные общие сведения о наблюдаемых процессах в сети, дублированы на каждом экране. В их числе сумма принятой и «пропущенной» (отказанной к обработке) информации, использование буферов, дата и время, наименование системы, средняя и мгновенная скорости информации в сети, текущее и среднее (за время работы НС) число рабочих циклов в секунду, время работы НС в последнем запуске.
Нижняя строка каждого экрана содержит короткую подсказку о том, какую клавишу следует нажать для переключения на тот или иной блок информации.
Экран 0 (рис. 4 на следующей странице) содержит в верхней половине свыше 80 общих наблюдаемых параметров. В их числе количество принятой к обработке корректной информации (пораздельно в пакетах и байтах), некорректной и отказанной к обработке информации (т.е. той, которая принята из сети драйвером сетевого адаптера, но из-за недостаточной вычислительной мощности не была обработана). В нижней части со скролингом снизу вверх показывается своим заголовком и характеристиками каждый принятый пакет. Несколько строк средней части экрана дают отладочную информацию о текущем распределении оперативной памяти под различные сегменты программы.
Рис. 4. Вид экрана 0 программы мониторинга
Нижний правый угол верхней половины экрана 0 содержит несколько последних сообщений, выведенных в протокол работы. По мере поступления новых сообщений текущие продвигаются вверх.
Можно видеть, что обработанные пакеты информации подразделены на 8 типов по формату пакета, причем отдельно выделена статистика бродкастинга. Пакеты формата IP, в свою очередь, подразделены на 5 видов: TCP, UDP, ICMP, прочие пакеты и пакеты версий IP, отличных от 4. Такое подразделение позволяет специалисту сразу же определить, с сетью какого типа он имеет дело, какова загрузка сети и достаточно ли вычислительной мощности НС для полной обработки принимаемой информации.
Во время работы НС оператором могут быть поданы различные команды. В частности, он может ввести интересуемый MAC- или IP-адрес, указать интересуемые типы пакетов, дать интересуемое направление по указанному адресу (от него, к нему или оба), ограничить отображаемые пакеты этими характеристиками, в любой момент начать/закончить дампирование отбираемых по указанному принципу пакетов в специальный файл.
Рис. 5. Вид экрана 1 программы мониторинга
В случае необходимости получения оперативной помощи можно переключиться на показ экрана 1 (рис. 5), на котором дана краткая сводка управляющих клавиш и отражен ряд особенностей демонстрируемой в разных режимах информации.
Экраны 0 и 1 являются вспомогательными при постоянной работе наблюдающей программы. В большинстве случаев оказывается удобным настроить НС на постоянный показ рассматриваемых далее экранов 2 или 3 или их черезминутное чередование.
Экран 2 (рис. 6) содержит список текущих активных ПК или, что то же самое, пользователей. По каждому пользователю показывается:
— ряд текстовых характеристик (подразделение, фамилия или иная идентификация ПК, местонахождение) известного сетевого объекта, либо MAC-адрес для неизвестного;
— 4 последние цифры полного IP-адреса сетевого объекта (например, для адреса 193.232.194.178 будет показано 4.178);
— ряд индикаторов, таких, как осуществившийся посыл почты (пораздельно на внутренние и внешние сервера).
Цвет строки дает указание о корректности работы данного сетевого объекта с точки зрения использования более чем одного IP-адреса. Максимально показывается 132 объекта.
Рис. 6. Вид экрана 2 программы мониторинга
Впоследствии на этот экран будет добавлен ряд дополнительных характеристик сетевых объектов, характеризующих их «поведение» в сети – в частности, ненормально высокое число обращений к различным ПК сети, прочие поводы заподозрить сетевые атаки, попытки сканирования или атак объектов в других сетях (в Интернете) и ряд других характеристик.
Последний блок информации, экран 3 (рис. 7), содержит в текущей версии, помимо общей для всех экранов заголовочной части, две области. В первой из них дан список специально выделенных серверов и иных сетевых объектов, относительно которых необходимо постоянно иметь точную информацию об их активности. Во второй, нижней части дана статистика работы по протоколу POP3 и несколько строк отведено для показа последних обращений по этому протоколу с указанием времени, источника, адресата и имени пользователя, обращающегося за почтой.
Рис. 7. Вид экрана 3 программы мониторинга
В дальнейшем предполагается дополнить эту информацию блоком характеристик состояния связи с мониторной программой и/или связи с коммутатором для отсечения сетевых объектов, нарушающих регламент поведения в сети.
Выше (стр.7) уже отмечено, что построенная пилот-система, функционально вполне отвечая поставленным задачам, оказалась в реальных условиях эксплуатации малоэффективной. Задача резкого повышения эффективности с выходом на полноценную эксплуатационную версию являлась центральной задачей, решенной в текущем году. В данном разделе статьи описывается постановка этой задачи и реализованные решения.
После выполнения инициализирующих процедур (настройка интерфейса с драйвером, загрузка текущего состояния оперативной БД, прием параметров, определение номера последнего из сгенерированных отчетов и др.) программа наблюдения входит в бесконечный цикл (см. рис. 8), исполняя следующие основные этапы:
Рис. 8. Схема основного цикла работы программы мониторинга
— проверка текущего состояния буфера, при наличии в нем пакета извлечение его и необходимая обработка (все варианты циклов);
— при достаточном свободном пространстве в буферах – вывод на экран текущих значений параметров и переменных («длинный» цикл);
— определение нажатой клавиши и исполнение соответствующей команды.
Одновременно, асинхронно с основным процессом (т.е. прерывая его при получении пакета из сети), исполняется вызываемая из пакетного драйвера методом UpCall ветвь алгоритма, показанная на рис. 8 вверху справа, пополняющая буфера принятыми пакетами. При отсутствии места в буферах пакет считается не принятым к обработке и пополняет графу «Мимо» на экране 0 (рис. 4). Таким образом, регулярная отчетность по отказанным к обработке пакетам вместе с мгновенной скоростью в сети, занятостью буферов и числом циклов представляют количественные выражения эффективности работы программы. UpCall-процедура написана на Ассемблере еще для пилот-версии, содержит не более пары десятков команд и не вносит погрешность в автоматическое измерение эффективности.
Искажения, вносимые техническим несовершенством НС как в смысле «железа», так и в смысле программы, обсуждались [2, стр. 60] давно. Было показано, что для общего мониторинга с достоверностью 95% (т.е. число отказанных к обработке пакетов не превышало 5% ни по количеству пакетов, ни по их объему) в одно рагментной сети при Vmax в пределах 100¸300 Кб/с вполне достаточно пилот-системы, эксплуатирующейся на AMD-K6-2-300. При 1000 рабочих циклах в секунду максимальная пропускная способность такой НС соответствовала 1000*1540/1024=1468 Кб/с, что в тех условиях было вполне достаточно. Однако, реорганизация ЛВС с вводом 100Мбитных концентраторов и особенно развязывающего коммутатора [10] дала, как мы видели выше (рис. 3), возможность передачи по сети до 15000Мб/ч, или свыше 4000Кб/c. Таких скоростей пилот-система уже не выдерживала, значение 1000 циклов/с следовало резко увеличить.
Второй, связанной с этим проблемой был вопрос обработки пакетов в ситуациях резкого короткого повышения скорости до 2000Кб/с и выше. Двух буферов по 4096 Кб, отведенных в пилот-системе под область приема пакетов, явно не хватало. Исследования показали, что емкость буферов следовало увеличить в 6-8 раз. Это было невозможно выполнить в пилот-системе, т.к. буфера были зарезервированы в жестком формате на уровне PowerBASIC как часть разделяемой области памяти, а в модуле на Ассемблере использовались ссылки на абсолютные места в общем буфере. Требовалось полное перепрограммирование всех блоков.
Третьей проблемой стала нехватка оперативной памяти. Большое количество предопределенных массивов, flex-переменных, готовых форматных строк (обратите внимание на отрисовку экранов на рисунках 4¸7) вывело программу за рубеж 512Кб. В среде MS-DOS для исполняемых программ свободно 602Кб. Как первичная отладка в среде DOS с использованием среды программирования PowerBASIC (476Кб) и драйвера, имитирующего работу в сети (35Кб), так и тонкая отладка с отладчиком ассемблера (98Кб) и все тем же драйвером имитации сети, стали невозможны. Следовало изменить технологию создания программы.
Указанные проблемы решались следующим образом. С самого начала разработки было ясно, что основное время цикла тратится на исполнение форматирования. Тем не менее, до последнего времени особого внимания этому не уделялось; единственное, что присутствовало в алгоритме – это направление расчетов по «короткому» циклу в случаях, когда заполненность буферов более установленного числа процентов. В противовес этому, теперь проведены полноценные исследования реализации ряда конструкций языка PowerBASIC и создана оригинальная библиотека процедур форматирования на Ассемблере (подробнее об этом см. в самостоятельной статье данного сборника [11]). По результатам этих исследований также в ряде мест основной программы изменены конструкции языка PowerBASIC.
Полностью переписана подпрограмма на Ассемблере, организующая связь с FTP-драйвером. В новой ее редакции в нее включена также первичная обработка пакетов (определение типа, развертка форматного представления в виде, отображаемом на экране 0, и др.).
Далее, была реорганизована структура области связи с подпрограмами Ассемблера. В частности, выделена самостоятельная область под буферы приема пакетов, объем которой теперь легко модифицируется на этапе компиляции. Такое решение обеспечило как выделение максимально возможного в языке PowerBASIC объема под буфера (2 по 64Кб), так и быстрое их усечение до 2Кб для возможности отладки.
Переписан драйвер, имитирующий работу сети, без которого невозможна отладка программы (в реальной сети поступление пакетов спонтанно; при отладке это регулируется программистом). Новый объем драйвера составил всего 5 Кб.
Наконец, из программы убрано значительное количество блоков отрисовки сложных структур экрана, занимавшее около 25% объема программы. Подготовка форматов экранов выделена в самостоятельный модуль, результат работы которого записывается в файл на этапе генерации программной версии. В основной программе присутствует блок чтения заранее подготовленной экранной информации и засылки этих данных в видеопамять. При отработке такого решения оказалось, что различные видеокарты по-разному организуют видеопамять (различно дополнительное число байт в конце страниц). В силу этого разработан алгоритм автоматического определения начала очередной страницы видеопамяти, и в основную программу вставлен соответствующий реализующий блок.
Особняком стоит важная выполненная работа по сохранению управления в аварийных ситуациях. Дело в том, что формирование аварийных собщений о сбоях программы исполнялось в предыдущих версиях с использованием общего аппарата обработки текстовых строк. Поэтому в случаях, когда аварийная ситуация возникла по вине строковых переменных (а такие случаи, к сожалению, после устранения прочих ошибок составляли подавляющее большинство), попытка вывода аварийного сообщения, вновь пытающаяся использовать строковые функции, вела к потере контроля над работоспособностью программы. В новом варианте программы разработана специальная схема построения структур аварийных сообщений, не задействующая строковый сегмент и строковые функции. Вместо них используются соответственно flex-строки [12] и процедуры новой библиотеки форматных преобразований.
Выше уже было сказано, что основная программа наблюдения имеет ряд характеристик, объективно фиксирующих состояние процесса переработки информации. Часть этой информации доступна на экране 0 в момент работы НС. Все параметры фиксируются в каждом 15-минутном отчете. Не вдаваясь в подробные объяснения, отметим, что основными интересуемыми параметрами являются следующие.
Ybytes, Ebytes и Nbytes – числа байтов, соответственно, обработанных программой, коллизионных и отказанных к обработке за некоторое интересуемое время T.
CycA – число всех рабочих циклов за исследуемый период.
CycH – число рабочих циклов максимальное за исследуемый период.
CycL – число рабочих циклов минимальное за исследуемый период.
CycU – число «полезных» рабочих циклов, т.е. тех, в которых реально была выполнена обработка пакета.
CycS – число «коротких» циклов за исследуемый период.
Bufmax% – максимальный процент загрузки буферов за исследуемый период.
В ряде случаев бывает удобно оперировать производными показателями.
Vср – средняя скорость в сети, определяемая как (Ybytes+Nbytes+Ebytes)/T.
Vmax – максимальная скорость, достигнутая в интересуемом интервале времени.
Vср% и Vmax% – средняя и максимальная скорости, выраженные в процентах от принятого ранее [2] значения «полной» загрузки сети в 600 Кб/c. При построении графиков они более удобны вследствие нормированности.
Для того, чтобы не иметь дело с большими числами, достигаемыми на полной длительности интервала T, ряд показателей удобнее выражать в приведенных к 1 секунде значениях. CpsH и CpsL вычисляются из CycH и CycL функциями максимума и минимума, CpsA, CpsU и CpsS вычисляются по CycA, CycU и CycS усреднением по числу секунд.
Полные исследования за весь период существования современной программной реализации, разумеется, здесь привести невозможно вследствие колоссального объема информации. Репрезентативную качественную картину достигнутой эффективности проиллюстрируем на одном примере, выбранном по достаточно высоким показателям Vср и Vmax.
На рис. 9 показаны типичные параметры, достигнутые в ЛВС ЦЭМИ РАН к концу 2004 г. Из сравнения с приведенным в данном сборнике рис. 40 на стр. 88 легко видеть, что Vmax увеличилась в несколько раз за 4 года. Повысилась и Vср, что говорит об увеличении пропускной способности сети.
Исследуем наиболее загруженный день показанной недели. На рис. 10 для сравнения даны графики Vmax% и Vср%. Отчетливо видно, что даже в периоды наивысших скоростей в сети общее количество рабочих циклов CpsA, показанное деленным на 10 для сохранения наглядности графиков, практически не изменяется. Более того, минимальное число циклов в секунду CpsL в периоды наивысшей активности сети не было меньше 5000. Сравнение с соответствующими числами для пилот-версии (600-800 циклов/с) наглядно дает представление о достигнутой эффективности программных средств мониторинга.
Рис. 9. Типичные скорости в многофрагментной сети
Рис. 10. Пропускная способность программы аудита на высоких скоростях сети
Не менее интересны данные о загрузке буферов и распределении циклов. На рис. 11 представлены эти сведения за тот же день. Обратим внимание, что даже на критическом участке занятость буферов возрастает до 100% лишь периодически, а число «коротких» циклов, свидетельствующих о нехватке вычислительной мощности, проявляется на весьма ограниченном отрезке.
Рис. 11. Технические характеристики программы аудита на высоких скоростях сети
Детальные данные по этому короткому отрезку о реальных отказах в обработке данных приведены в нижеследующей таблице.
Табл. 1. Точные данные мониторинга на отрезке высокой загрузки сети
Как видим, максимальное значение отказанных к обработке данных в байтах было на скорости 3476 Кб/c и составило 0,000107%. Для пилот-системы [2] было 2¸5%.
Таким образом, достигнутый уровень достоверности даже на высоких скоростях сети принципиально превышает уровень достоверности пилот-системы и свидетельствует о достижении программой класса полноценного мониторинга и аудита.
Сделанные модификации программного обеспечения наблюдающих станций завершают экспериментальную стадию пилот-системы, переводя разработанную программу в ранг эффективного потребительского продукта.
Выполненные модификации, давая некоторый резерв оперативной памяти на этапе исполнения программы, открывают возможность дальнейшей доработки программы для разработки блоков связи по RS232 с мониторной программой на стороннем компьютере. Эта работа является дальнейшим этапом планируемого комплекса программ связи со средствами управления локальной сетью (коммутаторами Cisco Catalyst).
Приведенные изменения также не исчерпывают всех возможностей по оптимизации программного обеспечения наблюдающих станций.
(X)Работа выполнена при финансовой поддержке РФФИ, проект N 04-07-90260в