CC BY
38
Ю.И.Шокин, А.М.Федотов, С.Д.Белов, А.С.Зайцев, В.С.Никульцев, Л.Б.Чубаров
Проблемы мониторинга и сбора статистики в больших корпоративных научно-образовательных сетях на примере СПД СО РАН
Введение. Современные крупные информационно-телекоммуникационные комплексы, такие как Сеть передачи данных (СПД) Сибирского отделения РАН, наравне с энергетическими, транспортными и другими системами жизнеобеспечения составляют основу современной инфраструктуры, обеспечивающей не только научную и образовательную деятельность в рамках своей исторически сформировавшейся сферы влияния, но и поддержку многих других принципиально важных аспектов функционирования социума в локальном, региональном и глобальном масштабах.
Для управления такими комплексами представляется чрезвычайно важной возможность получения достоверной информации о структуре потоков данных, о природе этих потоков, о приложениях, генерирующих эти потоки и потребляющих дефицитные сетевые ресурсы. Предотвращение утечек этих ресурсов, обусловленных наличием в сети компьютеров с аномальным поведением, в том числе зараженных или взломанных, использованием в сети изощренных файлооб-менных (Реег-То-Реег, далее просто Р2Р) приложений, подобных е-ти!е, Кагаа и др., также является актуальной задачей.
Инфраструктура СПД разворачивалась с февраля 1995 г. За последние три года подключения институтов СО РАН были переведены на современный технологический уровень. Направления развития сети ориентированы в сторону г. Новосибирска, находящегося на удалении более 30 км от основных технологических площадок, и региональных научных центров (НЦ) СО РАН. За этот период к СПД были подключены НЦ СО РАН в Иркутске, Красноярске, Омске, Томске и др. Сеть стала одним из важнейших корпоративных ресурсов всего Сибирского отделения. Региональные НЦ подключались по среднескоростным каналам, арендуемым у национальных операторов Ростелеком и Транстелеком. Суммарная емкость этих подключений к лету 2006 г. превысила 45 Мбит/сек.
К 2006 году в СПД СО РАН работало более 160 организаций и 35 000 компьютеров, обслуживались десятки тысяч пользователей, а суммарный объем информации, переданной по внешним каналам, составил более 263 Тбайт/год.
Сама по себе задача исследования характери-стик интенсивных потоков данных в современных кор-
поративных сетях при загрузке в сотни и более Мбит/сек является нетривиальной и требует тщательного изучения,
Упрощенные подходы к анализу трафика и попытки получения информации о сетевых приложениях на основании легкодоступных атрибутов и характеристик потоков данных чаще всего оказываются непродуктивными, Так, в большинстве упомянутых выше файлооб-менных приложений активно используются приемы, затрудняющие достоверную идентификацию таких приложений (динамическое назначение портов, децентрализованные хранилища, использование широко распространенных прикладных протоколов в качестве транспортных, а также криптографические методы сокрытия и маскировки трафика), Поэтому для обнаружения сетевых аномалий необходим тщательный анализ. Зти обстоятельства требуют использования дополнительных технических, программных и алгоритмических средств и, возможно, изощренных математических моделей исследуемых процессов.
I. Технологические аспекты организации мониторинга. Научно-образовательные сети, особенно достаточно большого масштаба, несомненно, имеют определенную специфику. На наш взгляд, эта специфика связана с несколькими особенностями тс.ких сетей.
Во-первых, следует указать на существенную социальную интегрированность и открытость научно-образовательного сообщества. В отличие от сетей большинства других корпоративных сообществ (например, силовых ведомств, промышленных предприятий), где во главу угла ставятся задачи узко-корпоративного характера и не предполагается выделение сколько-нибудь заметных ресурсов для обеспечения иных задач (разве что во время чрезвычайных ситуаций), в научно-образовательных сообществах всегда отмечалась тенденция не замыкаться в ведомственных рамках, а искать все новые и новые приложения для разработанных идей, подходов, не ограничивая чрезмерно совместного использования ресурсов.
Именно поэтому научно-образовательные сети России, создававшиеся в существенно ограниченных условиях (например, Ргее№1 в ИОХ им. Зелинского, 1?ас1ю-М$и в Институте ядерной физики им. Скобельци-на), неизбежно эволюционировали в сторону мульти-
дисциплинарного развития, размывая тем самым изначальную узкопрофессиональную ориентацию, Более того, в сферу такого развития неизбежно оказывались вовлеченными не только научно-ориентированные сообщества, но и структуры образования, культуры и здравоохранения различной ведомственной принадлежности,
Во-вторых, упомянутая мудьтидисциплинарность, в совокупности с исследовательским характером решаемых задач, с неизбежностью приводит к расширению спектра проблемной ориентации пользователей, В таких сетях могут спонтанно возникать новые потребности, которые должны по возможности удовлетворяться наряду с потребностями традиционными и заявленными заранее. При этом специалисты, ответственные за сектор, например, вирусологических исследований, проводимых с использованием сети, не могут даже и предполагать о содержании задач, которые будут предложены уже завтра для решения в этой же сети археологами или геофизиками. Новые задачи и направления исследований возникают непрерывно, постоянно меняются их относительные приоритеты, состав приложений, участников и используемых ресурсов. Такая ситуация нехарактерна для типичной корпоративной сети неакадемического происхождения, где развитие идет существенно более плавными темпами, без резких скачков и поворотов.
Наконец, имеет место особое отношение исследовательских, в первую очередь, академических сообществ, к проблемам подготовки кадров - как для «собственного потребления», так и для нужд общества в самом широком смысле - на уровне города, региона, государства и даже цивилизации в целом.
Для эффективного управления информационно-телекоммуникационной системой такого масштаба, как Сеть передачи данных СО РАН в ее современном виде, требуется непрерывное поступление достоверных технологических данных о состоянии различных ее узлов и подсистем. Однако, наличия лишь низкоуровневых технологических данных для понимания и прогнозирования работы современной сети безусловно недостаточно. Так, мы располагаем, например, информацией о том, что с 14:10 сего дня резко подскочила загрузка сетевого подключения, обслуживающего организацию N. Является ли эта аномалия проявлением нового научного подхода в сообществе N. что потребовало организовать массовую перекачку данных из точки А в точку Б? Или это - результат вирусной инфекции в локальной сети организации? Или это - проявление внешней атаки на информационные ресурсы наших абонентов? От ответа на эти и подобные вопросы, от классификации наблюдаемых аномалий зависит реакция администраторов сети, основанная на оперативном анализе ситуации, выполненном на более высоком семантическом уровне.
Если в отношении технологического мониторинга ситуация более или менее ясна, и для реализации этого мониторинга доступны вполне адекватные технические и программные средства, обеспечивающие сбор и визуализацию данных о сиюминутном состоянии различных компонент сети, то в отношении средств сбора данных по динамике и высокоуровневому анализу состояния сети ситуация далеко не так проста.
Формулировки требований к службам мониторинга и сбора статистики в СПД СО РАН предпринимались ранее в ряде работ (см. например, работу С. Бредихина с соавторами [1], в которой описывается существующая система мониторинга и сбора статистики). Предваряя изложение подходов к решению решаемых этими службами задач, рассмотрим возможную их классификацию. На наш взгляд, могут быть выделены следующие категории:
A) Оперативный контроль технического состояния активного оборудования сети (загрузка процессора коммутатора и/или маршрутизатора, текущее использование их оперативной памяти, температура внутри корпуса и пр.).
Б) Оперативный контроль состояния внешних и внутренних каналов (пропускная способность в различных метриках, уровень ошибок, разнообразные особые случаи (например, увеличение количества коллизий, пропадание несущей)),
B) Сбор статистических данных для учета потребления ресурсов, для оперативного и ретроспективного анализа этого потребления, для планирования перспективного развития сети и ее отдельных сегментов.
Г) Задачи обеспечения безопасности, включающие обнаружение аномалий в потреблении ресурсов сети, оперативное обнаружение атак, вторжений и других инцидентов, ретроспективный анализ статистических данных при расследовании таких инцидентов.
Мы сознательно ограничиваем предметную область и не рассматриваем оперативный контроль за состоянием множества сетевых приложений и сервисов, таких, как DNS, работоспособность почтовых служб и заполненность пулов почтовых очередей, согласованность и непротиворечивость маршрутизации. Важность этих вопросов для управления реальной сетью не вызывает сомнений, и большинство задач этих категорий решаются с помощью широко известных сетевому сообществу приложений высокоуровневого сетевого мониторинга. В настоящее время хорошо известны программные продукты с открытым кодом, например, Nagios [2], с помощью которых могут эффективно решаться как упомянутые выше, так и подобные им задачи.
Перечислим широко использующиеся подходы.
SNMP-мониторинг. Информационная ценность его результатов в известной степени ограничена, поскольку практически вся доступная информация силь-
но интегрирована и/или анонимизирована, Несмотря на то, что многие естественные вопросы в рамках стандарта SNMP остаются без ответов (например, определить текущую загрузку в битах в секунду на определенном интерфейсе можно только при использовании реализованных на конкрентной платформе расширений стандарта, или путем самостоятельного вычисления инкрементов счетчиков на интерфейсе и деления полученных значений на длительность интервала наблюдения), SNMP-мониторинг активно используется для решения задач категорий А и Б. Его функциональность реализована достаточно единообразно на большинстве используемых платформ, хотя и существует определенная специфика. Практически нет альтернатив, позволяющих работать с различными платформами (не учитывая разве что терминальный доступ), Для задач категории Б технологии SNMP-мониторинга вполне адекватны, но проблемы могут возникать при использовании небрежно реализованных front-end систем или применения плохо масштабируемых решений (например, при регулярном опросе значительного количества переменных загрузка монито-рирующего процессора может стать значительной),
Для решения задач категории В применяется уже множество подходов:
Непосредственное наблюдение за состоянием передающей среды на 2-ом уровне ВОС, В принципе это - самый мощный метод, поскольку позволяет фиксировать всю необходимую информацию о трафике, однако применимость его с переходом сетей на современные технологии передачи данных существенно ограничилась,
Использование для этой цели современных коммутаторов и маршрутизаторов с применением технологий мониторирующих портов (monitoring port, spanning port) все же возможны, но ограничиваются в основном сетями с относительно невысокой загрузкой, не превышающей половины пропускной способности передающей среды: в случае мониторирования порта с текущей загрузкой 40 Мбит/сек в обе стороны на мо-ниторирующий порт будет приходить поток 40+40=80 Мбит/сек; для текущей загрузки 80 Мбит в обе стороны мощность потока на мониторирующий порт составит уже 160 Мбит/сек, что может превысить возможности мониторирующего порта (мы исходим из предположения, что мониторируемая инфраструктура построена на широко распространенной технологии Fast Ethernet), В этом случае будет необходимо использование или гигабитного порта (а их количество на коммутаторе и, тем более, на маршрутизаторе, как правило, ограничено, и они используются в основном для организации так называемых восходящих линков (up-links)), или применением механизма агрегирования группы Ethernet-портов. Однако, в последнем случае также существуют проблемы на популярных платформах, связанные, например, с невозможностью назначения
порта и/или интерфейса (в частности, агрегированного порта) в качестве мониторирующего порта.
При таком подходе анализируется непосредственно передающая среда, и здесь возможна определенная независимость от аппаратной платформы. Для полноценного использования возможностей такого метода могут потребоваться специальные технические средства сетевого мониторинга (Network Taps, technological access points),
Технологии типа IP-accounting. По сути это наблюдение за трафиком интерфейса или группы интерфейсов средствами, интегрированными в состав активного сетевого устройства. В настоящее время эти технологии также имеют ограниченное применение, хотя по своей эффективности могли бы быть сопоставлены с перечисленными в предыдущем пункте, Технологии этого типа реализованы на немногих аппаратных платформах. Конечно они могут быть реализованы в автономных модулях-сенсорах, способных непосредственно наблюдать за средой (см. выше), либо в качестве встроенных компонент сетевой инфраструктуры, пропускающих через себя весь трафик определенных фрагментов сети [3],
В подобных реализациях сенсоры могут предоставлять дополнительную функциональность межсетевых экранов (firewalls), либо систем обнаружения атак (традиционно такие системы обнаружения называются IDS, Intrusion Detection System, что не вполне соответствует их функциональности): например, сетевые экрчны PIX, FVV-1, экраны, построенные на распространенных пользовательских платформах (Linux, BSD, Solaris)/ Как правило, предоставляемая в части сбора статистики функциональность у распространенных сетевых платформ существенно ограничена из-за чрезмерного агрегирования и интегрирования статистических характеристик трафика. В то же время, при реализации на автономных модулях-сенсорах она может быть столь существенно расширена, что возникают основания говорить о новой категории сетевых устройств.
Методы, базирующиеся на технологиях, следующих моделям RFC1272, RFC3917 (Netflow и им подобные) [4], [5]. Эти методы наиболее широко применяются в современных сетях, наряду с мониторингом SNMP, Технологии Netflow разрабатывались для оптимизации процедур маршрутизации и коммутации, так что задачи сбора статистики трафика не являлись приоритетными. В результате ценность данных Net-iiow для задач категорий В и Г заметно ограничивается. Критика технологии Netflow и направления ее развития достаточно широко известны [6].
Для задач сбора статистики и оперативной диагностики, когда требуется информация неинтегриро-ванная (fine-grained), преимущественно используются методы, базирующиеся на технологиях Netflow, что объясняется не преимуществами этих технологий, а отсутствием альтернативных решений. Например, оп-
ределенные характеристики ТСР-трафика (например, кем из двух участвовавших в диалоге хостов было инициировано данное ТСР-соединение или данная 1ЮР-транзакция) практически несущественны для задач сбора статистики, но для задач расследования инцидентов они чрезвычайно важны.
На наш взгляд, определенные перспективы имеют два взаимодополняющих метода мониторинга: непосредственное мониторирование потока данных передающей среды на нижнем уровне посредством автономного модуля-сенсора, и сбор оперативной статистики трафика на базе этого мониторинга типа МеЙ1оуу, но с иной, более продуктивной для сформулированных задач семантикой.
Сложности применения этих подходов состоят, прежде всего, в том, что непосредственный мониторинг канала в условиях корпоративной СПД СО РАН возможен только в точках подключения на периферии сети, на уровне отдельной организации либо некоторой группы организаций, типа сети регионального НЦ (где загрузка канала не превосходит 50% от потенциальной емкости канала), но не подходит для опорной сети или для внешних каналов. Для организации такого мониторинга на загруженных каналах емкостью 100 Мбит/с и более требуется специальное оборудование, обеспечивающее невозмущающее мониторирование канала.
Следует указать также и на то, что включение в состав сети сложных компонент с активно эволюционирующим программным обеспечением может отрицательно сказаться на надежности системы в целом. Это делает предпочтительным выделение модулей-сенсоров в такие автономные блоки, которые не будут блокировать целый сегмент сети в случае неизбежных ошибок/сбоев.
И, наконец, дополнительную сложность создает необходимость обеспечения масштабируемости системы с тем, чтобы обеспечить ее работоспособность как на современных уровнях загрузки каналов, так и в случае ее увеличения в несколько раз (как минимум до емкости 1 Гбит/сек),
2, Анализ статистических данных. До сих пор нами рассматривались лишь технологические аспекты получения статистических данных по трафику в различных точках корпоративной сети. В то же время статистика, относящаяся к передаваемым данным, интересна во всех телекоммуникационных системах, и особенно важна в сетях крупных операторов, в частности, в корпоративных сетях. Статистические данные используются не только для обоснования чисто инженерных решений - оптимизация топологии и подключений, планирование расширений и развития, анализа использования ресурсов - они также важны для обеспечения определенных мер безопасности, равно как и в расследовании разнообразных инцидентов.
К сожалению, достаточно широко распространен прецедентный подход к построению систем сбора и анализа статистики сетевого трафика, когда тиражируется некоторое демонстрационное, модельное решение, вполне адекватное для небольших сетей, но не масштабируемое для реальных потребностей. Как правило, такие реализации имеют целью продемонстрировать состоятельность определенного технологического подхода, а не обеспечить решение практических вопросов, постоянно возникающих в процессе эксплуатации сети у ее администраторов и технического персонала, Модель-прототип оснащается развесистым графическим интерфейсом, и в результате возникает сложная и тяжеловесная система, декларативно предназначенная для чего угодно - для анализа трафика, для подсчета календарных итогов и для представления результатов такого анализа случайному пользователю, обладающая «богатой» функциональностью (суммы за неделю; суммы за декаду; суммы за две; за месяц и пр.), однако имеющая чрезвычайно узкий круг пользователей в силу априорной заданности исходных принятых посылок,
Обычно такого рода «априорно» построенные системы возникают в отсутствие предварительного анализа потребностей, набора задач и круга пользователей, Ретроспективный анализ причин такого ограничения применений системы, как правило, сводится к утверждению об объективной невозможности обеспечения требуемой функциональности при использовании априорно выбранного инструментария, Отсюда делается неправильный вывод либо о невозможности реализации требуемой функциональности, либо о необоснованности неудовлетворенной потребности. Значительность ресурсов, затраченных в совокупности на реализацию такой системы, далее зачастую используется в качестве аргумента о нецелесообразности каких-либо переделок, по сути дела замораживая дальнейшее развитие всего направления.
На наш взгляд, соответствующий список приоритетов для сети СО РАН должен базироваться на понимании предназначения самой сети и функций обслуживающих эту сеть подразделений и служб. Так, одной из важных и, без сомнения, необходимых для оперативного управления сетью и для перспективного планирования, являются задачи учета потребления ресурсов сети различными группами пользователей - как определенными статически (некоторая организация; региональный НЦ как единое целое), так и динамически возникающими субъектами (участники видеоконференции из разных организаций, участники традиционных конференций и/или собраний, использующие лишь традиционный доступ к ресурсам сети как в пределах конкретной организации, так и для группы организаций).
Принимая во внимание высокую ценность используемых в сети ресурсов (в первую очередь ресурсов пропускной способности внешних каналов), необходи-
мо обеспечить возможность кок оперативного, так и ретроспективного анализа нерегулярностей в использовании этих ресурсов с достаточной детализацией для выявления злоупотреблений в использовании ресурсов пользователями, группами пользователей, организациями.
Непредсказуемость вопросов, которые могут возникать при анализе аномалий, диктует необходимость наличия многофункционального пользовательского интерфейса для формулировки и выполнения конкретных запросов к системе, а также обеспечения доступа к исходным сырым данным, накопленным за некоторый период времени, для их обработки с помощью выбранных критериев и алгоритмов. Такие алгоритмы было бы нерационально включать в общую систему, разве что за исключением современных средств автоматической классификации аномалий и нерегулярностей потребления сетевых ресурсов [7].
В предлагаемой к реализации системе предусматривается наличие эффективных автономных средств для анализа и визуализации значительных объемов данных, генерируемых системой мониторинга. Например, при суммарной емкости внешних каналов -150 Мбит/сек объем «сырой» статистики Netflow составляет около 1 Гбайт/час. В качестве такого универсального средства выбран широко использующийся в физике высоких энергий пакет ROOT [8]. Этот пакет прекрасно подходит для задач анализа больших объемов многомерных данных (до терабайта в интерактивном режиме, до 100 Тбайт в оффлайне), имеет развитые графические средства,
Если оперативный анализ экстренных ситуаций в сети квалифицированными сетевыми операторами в рамках современной системы возможен, хотя и непрост (например, эпизод с локализацией червя Slammer в сети ИМ СО РАН в 2004 г.), то их ретроспективный анализ существенно затруднен, То же самое следует отметить в отношении малозаметной, размазанной утечки ресурсов в современных сетях файлового обмена (упоминавшиеся выше Р2Р-приложения, см., например, [9]).
Упрощенные подходы к построению систем учета использования ресурсов в сети существенно увеличивают чувствительность реализуемых систем к помехам от сетевых атак и, тем самым, понижают их устойчивость. Так, достаточно распространенное сканирование внешними хостами портов внутренней сети, не говоря уже об атаке типа DDoS (разновидность атаки, приводящей к отказу в обслуживании легитимных пользователей за счет посылки большого числа сфабрикованных, бессмысленных запросов на использование определенного информационного ресурса) может приводить к существенному искажению и к потере статистических данных. Для обеспечения упомянутой выше устойчивости, системы сбора статистики должны разрабатываться с учетом возможности помех от за-
шумления исходных данных и непосредственных атак на систему. Эта проблема может быть снята путем обеспечения координация действий с системами обеспечения информационной безопасности (в частности, с IDS).
В современных условиях, когда в силу указанных выше обстоятельств, использование сетевых ресурсов не поддается тривиальной классификации по протоколам/номерам портов, зачастую необходимо привлекать дополнительную информацию более высоких уровней модели ВОС, которая может быть доступна либо при взаимодействии с IDS, либо при непосредственном анализе трафика. Наибольшие неприятности в данном случае могут представлять, как уже отмечалось, современные Р2Р-системы, эффективно использующие различные схемы динамического назначения портов (включая 80, 22, 25 и 53 порты).
Подводя итог краткому обзору распространенных подходов к сбору статистических данных в реальных сетях можно, на наш взгляд, выделить подходы, базирующиеся на поточной архитектуре (netflow и подобные), и подходы, аккумулирующие данные на фиксированных временных интервалах (IP-Accounting, SNMP-монито-ринг).
При этом подходы, тяготеющие к поточной архитектуре, принципиально не могут отражать сиюминутную временную динамику трафика, тем самым искажая реальную картину: данные по определенному потоку во-первых, станут доступны только после завершения (естественного или принудительного) этого потока, а, во-вторых, эти данные представляют лишь интегрированные, усредненные по времени «жизни» потока результаты.
Подходы другого типа, собирающие данные на фиксированных временных интервалах, могут характеризовать трафик в реальном масштабе времени (с разрешением, определяемым продолжительностью интервала сбора статистики), Однако, в современных сетевых устройствах (коммутаторах, маршрутизаторах) таким образом может быть зафиксирован лишь очень ограниченный набор атрибутов трафика. Полноценный его анализ может быть обеспечен лишь при использовании специализированных сенсоров, что влечет дополнительные материальные затраты и приводит к общему усложнению системы. С другой стороны, такие дополнительные компоненты могут обеспечивать и ценную дополнительную функциональность, например, выступать в качестве IDS,
3. Визуализация данных статистики, Основным критерием качества системы сетевого мониторинга и сбора статистики является адекватность управленческих решений, принимаемых персоналом на основе информации, предоставляемой этой системой. Обеспечение такой адекватности возможно только на основе правильной интерпретации представляемых системой результатов, что, как правило, невозможно без их
наглядного графического представления. Таким образом, чрезвычайно важной функцией эффективной системы мониторинга и статистики становится функция визуализации текущего состояния сети,
Недостатками распространенных систем визуализации является их неэффективность в тех случаях, когда масштабы мониторируемой сети превышают определенный порог, так что результаты визуализации уже не воспринимаются потребителем, либо требуют от него значительных дополнительных усилий для восприятия представленной информации,
Поскольку контролируемые сети, как правило, достаточно сложны - включают множество компонент и, зачастую, мониторируемые метрики этих компонент взаимосвязаны (например, загрузка внешнего канала определяется совокупной загрузкой региональных подключений и трафиком организаций ННЦ), в развернутых по умолчанию системах мониторинга для ответа на вопрос «кто съел?» требуется последовательный просмотр значительного объема информации (для региональных НЦ это около 8 страниц, а для отдельных организаций ННЦ - 2-3 десятка страниц),
В качестве примера можно привести ситуацию с оценкой «на взгляд» состояния достаточно развитой кампусной сети регионального центра, Такая сеть составлена из большого числа коммутаторов и/или маршрутизаторов (потребителей), каждый из которых имеет множество мониторируемых портов, вносящих определенный вклад в некоторую, может быть и не определенную формально метрику общей загрузки кампусной сети (например, текущая загрузка магистрали в битах в секунду). Типичной задачей при возникновении сетевой аномалии в подобной сети - резкого роста загрузки магистралей - является задача определения организации-абонента, внесшей наиболее существенный вклад в такую экстремальную загрузку.
Конечно, может оказаться, что вклад внесли все -например, все одновременно начали процедуру обновления антивирусных баз данных после публикации сообщения об обнаружении очередного вируса, что, впрочем, на практике встречается нечасто. Чаще оказывается, что такая загрузка обусловлена существенным увеличением загрузки отдельного подключения (отдельного компьютера в случае локальной сети организации, организации в случае кампусной сети), Для того, чтобы определить субъекта, породившего аномалию, в большинстве систем мониторинга следует перебрать и проанализировать страницы визуализации активности всех субъектов, запоминая при этом их текущие состояния, что может оказаться затруднительным для оператора,
Более разумный подход состоит в графическом представлении результатов с учетом их реальной многомерности и многоаспектности, что даст возможность оперативно, одним взглядом сопоставить загрузки, соответствующие группе абонентов и/или подключений.
В этой ситуации на основе графического представления потребления ресурсов конкретными абонентами можно легко определить, что всплеск загрузки был обусловлен активностью конкретного субъекта. Несмотря на кажущуюся очевидность и тривиальность такого подхода, реальные его применения наблюдаются достаточно редко,
Уже упоминавшийся программный пакет ROOT, использующийся в качестве инструмента анализа статистических данных, также может быть использован в качестве средства как для оперативной визуализации, так и для подготовки итогового отчетного материала.
В Приложении приводятся два примера анализа статистических данных - анализ трафика типичного рабочего дня средней по масштабам сети ННЦ (ИЯФ СО РАН) на основании статистических данных, собранных системой статистики ИЯФ, и анализ трафика двух машин ННЦ до и после момента обнаружения факта их взлома, проведенный с использованием системы ROOT на основе данных Netflow. Эти примеры активно обсуждались на семинаре ИВТ СО РАН «Информационные технологии» весной этого года.
Заключение. Ряд средств, упомянутых здесь, продолжает интенсивно развиваться и расширяться. Поэтому, даже построив действующую систему сбора статистики и учета либо использующую эти средства, либо лишь базирующуюся на постоянно отслеживать направления эволюции аналогичных босистем в мировом сетевом сообществе заложенных в них принципах и подходах, следует постоянно отслеживать направлений эволюции аналогичных систем в мировом сетевом сообществе.
Приложение
Минимальный оперативный анализ внешнего трафика локальной сети ИЯФ, и анализ трафика с помощью системы ROOT.
В локальной сети ИЯФ СО РАН применен метод IP-accounting на фиксированных временных интервалах. Демон сбора статистики анализирует весь трафик, направленный в локальную сеть или наружу, и регулярно сохраняет файл со статистикой. Данные, записываемые в файл, выглядят следующим образом (Пример 1).
В данном случае показаны несколько первых строк статистического файла за период, завершившийся в 15:00 17 марта 2006 г. - середина рабочего дня, Последние три поля строки соответствуют номерам портов (source и destination для протоколов TCP и UDP), и протоколу (ТСР=6, UDP= 17 и т.д.). Размер файла составляет около 6 Мбайт, и в нем содержится более 130 тысяч записей, Для минимального анализа этих данных разработаны несколько скриптов-сценариев, Чаще других используются скрипты inp_dist и ,inp_geog.
Следующий фрагмент иллюстрирует распределение трафика по машинам локальной сети (Пример 2).
Пример 1
$ head 2006.03.17-15:00
Source Destination Packets Bytes
217.117.80.29 193 . , 124 . . 164 . ,251 26583 34744297 8008 3251 6
213.200.100.30 193, , 124 , .167 . . 14 23055 32678670 80 11226 6
217.107.219.124 193. . 124 . . 167. , 102 18379 25993149 59163 22 6
38.118.213.151 193. , 124 , . 167 . , 14 17229 24465180 80 4373 6
62.67.57.17 193. , 124 , . 167 . , 14 13092 17998612 80 46415 6
83.222.6.57 193. , 124 , . 167 . , 14 11956 16698803 80 1484 6
83.149.249.236 193. , 124 , . 167 . , 14 11291 .15968068 4620 28964 .6
217.16.25.56 193, . 124 , . 167 . , 14 10902 15340605 80 1359 6
217.147.30.100 193, . 1.24 . . 167 , . 14 10756 15266198 80 12798 6
$ wc 2006.03.17-15:00
132909 930360 6204327 2006.03.17-15:00
$ cat 2006.03.17*1inp_dist|head Hosts 712 Traffic 35,170,480,744 81 17,908,326,292 50.92 50.92 91.27< 56.43 5.51 54.12< 59.50 3.07 97.34< 62.52 3.02 4 5.9 0 < 65.37 2.85 2.66< 66.92 1.55 8.67< 68.23 1.31 5.2 6<
Пример 2
1,936,339,425 1,078,844,206 1,062,169,305 1,003,079,477 545,325,074 460,138,787
08< records 3,802,556 51 sees 1644789 29472893 193.124.167.14 squid
17019 30433 515187 20 28059 26397
3015570
1273792
6578269
1136290
780241
689058
193 193 193 193 193 193
124 124 124 124 124 124
167 167 1 67 167 167 167
29 18 102 4 7
17
rainbow
dist
wizard
csd-bs
sllcmd
www
$
Здесь необходимый сценарий применяется для всех статистических файлов, записанный в указанный день, после чего распечатываются несколько первых строк отчета. Из них видно, что за сутки внешний трафик генерировался 712 компьютерами локальной сети, общий объем трафика составил около 35 Гбайт, 81% трафика был направлен в сеть (т.е. 19% - наружу), всего проанализировано чуть меньше 4 миллионов записей, на что было потрачено менее минуты астрономического времени.
В последующих строках отчета, отсортированных по убыванию объема трафика, приведены данные по каждому компьютеру локальной сети. Вторая и третья колонки отчета - накопленный процент трафика от общеинститутского объема и процент конкретного компьютера. Четвертая колонка - направленность трафика, как и в заголовке отчета, только по отношению к данному хосту,
Две следующих колонки - это «мера широты интересов» данного хоста и общее количество пакетов для него, «Широта интересов» есть количество различных сеансов/взаимодействий, которые провел за отчетный период этот компьютер, Так, 5-й по счету компьютер списка, несмотря на достаточно заметный трафик (около гигабайта, в основном переданного наружу), имел всего 20 сеансов связи. Другими словами, география его интересов была достаточно компактна. В то же время предшествующий ему в отчете компьютер, несмотря на примерно такой же объем трафика, характеризуется значительно большей «широтой интересов» (более полумиллиона сеансов). Кроме того, соот-
ношение in/out для его трафика приблизительно равномерное. Такая повышенная «широта интересов» дает основания для дополнительного анализа деятельности компьютера и его пользователей.
Следующие два фрагмента иллюстрируют анализ распределения трафика по внешним хостам (Пример 3).
Во втором фрагменте из всех статистических данных мы выделяем только те, которые относятся к конкретной внешней машине с адресом 64.225.154.135, и смотрим, с какими машинами института она контактировала. Оказывается, что таких машин было всего две.
В следующем примере анализируются данные во временном интервале, перекрывающем 72 часа, относящиеся к инциденту, произошедшему в начале зимы 2006 г., когда были взломаны два компьютера ННЦ. Статистические данные Netflow загружаются в систему ROOT с помощью небольшой вспомогательной программы, переводящей достаточно рыхлые исходные данные в компактное и эффективное внутреннее представление. При исходном объеме данных порядка 200 Мбайт внутреннее представление занимает около 50 Мбайт, преобразование занимает около 3 минут. Последующий анализ данных происходит в интерактивном режиме, длительность отработки одиночного запроса не превышает 10-15 секунд. Используются мнемонические названия атрибутов, собираемых Netflow: s_p (Source Port), dtl и dt2 (время начала и окончания потока).
На рис, 1 видны характерные линии, соответствующие группам потоков с монотонно увеличиваю-
щимся номером порта (в частности, возможные эпизо- ная суточная периодичность,
ды сканирования), Также видна ожидаемая естествен-
Пример 3
$ cat 2006.03.17*|inp_geogI head
Ext Hosts 93046 Traffic 35,170,480,744 81.08< records 3,802,556
1,004,727, 180 2. 86 2 . 86 2. . 69< 523 1141518 84 . 237.123 . 25
654,750, 588 4 . ,72 1. 86 54 . , 84< 2180 680528 192 . 91.245 .29
616,669, 38 9 6. , 47 1. 75 97 , , 56< 13007 710014 137 . 138.25 1.23
586,135, 903 8 . . 14 i 67 97. , 28< 22 698432 158 . 36.191 .136
558,643,059 9. .73 1. 59 97 . . 52< 62 64 9412 194 . 59.170 .44
523,987, .815 11. . 22 1. 49 97 . . 8 9< 25 573994 38 . 118.213 . 12
513,634, , 045 12 , . 68 1. 46 53 . 54< 399 567873 130 . 199.80 . 100
$ cat 2006, . 03.1 7 *!grep 64 .22 5.154.135|inp dist|head
Hosts 2 Traffic 102,090,418 34.14< records 156,611 7 sees
102,090,282 100.00 100.00 34.14< 156609 978912 193.124.162.199 ts-zolotarev
136 100.00 0.00 35.29< 2 3 193.12.4.165.24 4 15-12-4-415
$
70000
«
60000
50000
40000
30000
20000
10000
dt1/3600,h
^а££1с->Огам (^ 4 э_р: dtl/3600' ' ) Рис. 1. Распрелеленив атрибута по времени
Рис. 2. Верхний участок рис. 1, соответствующий портам с большими номерами
s_p:dt1/36GQ {{abs{s_p-6455ö)<500)&&{abs{dt1/3600-4б}<1}}
64400
64200
46.5 47
dt1/36ÖO
Рис, 3. Упомянутая область в более крупном масштабе
Для отрисовки этого распределения было достаточно выделить мышкой область на предыдущем рисунке. Видна (рис. 2) подозрительная сетевая активность во временной области около 46 часов от начала наблюдения (почти вертикальная плотная линия). Ее детальная структура изображена на рис. 3.
Библиографический список
1. Бредихин C.B., Ляпунов В.М., Щербакова Н.Г, Анализатор «сетевой погоды». Тезисы X Российской конференции с участием иностранных ученых «Распределенные информационно-вычислительные ресурсы», 6-8.10.2005, - Новосибирск, 2005.
2. http://www.nagios.org/
Middleboxes: Taxonomy and Issues, February 2002,
http://www.rfc-editor.org/rfc/rfc3234.txi
Internet Accounting: Background, http://www.rfc-
editor.org/rfc/rfcl272.txt
Requirements for IP Flow Information Export (IPFIX), http://www.rfc-editor.org/ rfc/rfc3917.txt C. Estan, K. Keys, D, Moore and G, Varghese, "Building a Better NetFlow", Proc. ACM SIGCOMM 2004. C. Estan, S, Savage, and G. Varghese "Automatically Inferring Patterns of Resource Consumption in Network Traific", Proc. ACM SIGCOMM 2003
ROOT - An Object-Oriented Data Analysis Framework, see
http://root.cern.ch/
Meiyuan Zhao,
http://www.es,dartmouth.edu/~2haom/research/marianas/reso urce.htmi
Н.И.Юсупова, Д.В.Попов, Д.А.Ризванов, М.А.Тихов, Д.Р.Богданова, А.Р.Габдулхакова
Модели и методы поддержки выполнения проектов в распределенном информационном пространстве
Введение, Эффективность деятельности мультипроектной организации определяется соотнесением достигнутых результатов и задействованных ресурсов, в первую очередь, - интеллектуального потенциала, который выражается в компетенции исполнителей и проявляется в процессе их коммуникации. Моделирование коллективной деятельности является наиболее сложно формализуемой проблемой. Здесь в неразрывном единстве должны учитываться не только формальная, но и содержательная стороны деятельности, поскольку применение ставших уже традиционными формальных подходов, основанных на ИСО 9000, SW СММ, РМВоК, Six Sigma и др., позволяют решить сформулированную проблему лишь до определенных пределов. В свою очередь, содержательная сторона творческой деятельности может условно быть поделена на креативную и коммуникативную составляющие.
