Файл: Современные методы построения сетей для решения сходных задач.pdf

Рисунок 12. Структурная схема системы обнаружения вторжений

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

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

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

Каждый сенсор представляет собой набор блоков сбора данных (S₁ ... S_n), блоков первичной реакции (R₁ ... R_n), а также содержит блок первичного анализа данных, осуществляющий первичный анализ потока данных активности объектов и формирующий на его основе совокупность первичных сигнатур. Как правило, совокупность первичных сигнатур включает в себя описание активности, вызванное подозрением сенсора и полный перечень операций, выполненных субъектом активности (последовательность вызова системных функций, протокол RIP и т. д.).

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

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

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

Описание архитектуры сенсора

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

В качестве исходных данных для анализа активности вредоносного ПО сенсор использует следующую информацию:

1. статистику вызовов системных сервисов ОС;
2. наличие попыток внедрения в адресное пространство пользовательских или системных процессов;
3. попытки получения привилегий отладки или подключения к наладочным портам процессов;
4. попытки модификации системных структур ядра ОС;
5. статистические профили пользователей и процессов.

Рисунок 13. Структурная схема сенсора СОВ.

Информация по статистике вызовов системных сервисов собирается отдельно для каждого процесса в системе. Графически ее можно представить в виде лепестковой диаграммы, которая содержит 237 осей (число системных сервисов). Каждая ось соответствует определенному системному вызову ядра ОС.

На оси откладывается отношение количества вызовов данного системного сервиса до общего процессорного времени, потребленного процессом

Топология связи протокола РТР.

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

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

Иерархическая топология

Различные приложения используют различные топологии. Для многих систем предпочтительна иерархическая топология, показанная на рисунке 13.

Рисунок 14. Иерархическая топология.

За исключением циклического пути, показанного пунктирной линией, остальные устройства, показанные на Рисунке 15 образуют иерархическую древовидную структуру с ВС в начале дерева. Поскольку ВС может иметь несколько портов, показанная топология позволяет большому количеству устройств синхронизироваться только через несколько ВС между любым ведомым устройством и GM. В данном примере предполагается, что путь, указанный пунктирной линией, отсутствует. Если ВС-1 выбран в качестве задающего генератора (GM), как показано на Рисунке 15, максимальное количество промежуточных ВС равно 1. Худший вариант реализации данной схемы возникает, если один из ОС, например, ОС-3 будет выбран в качестве GM. При таком выборе максимальное количество ВС до самого удалённого ведомого устройства, например, ОС-6 будет равно 3.
Протокол РТР строится на предположении, что протоколы маршрутизации и коммутации нижнего уровня будут исключать циклическую пересылку сообщений. В случае, если путь, указанный пунктирной линией на Рисунке 12, присутствует, из трех ВС образуется петля. Работа ВМСА и алгоритма принятия решения о состоянии разорвут эту петлю для сообщений РТР.

Определенные приложения требуют длинных линейных топологий, как показано на Рисунке 13, а не топологий «звезда» или иерархических топологий, как показано на Рисунке 12. На Рисунке 14 показаны две длинные линейные цепочки с Е2Е ТС с ВС-1 в качестве GM.

Рисунок 15. Линейная топология

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

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

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

Для использования протокола в подобных топологиях разработаны устройства Р2Р ТС.

Рисунок 16. Многосвязная топология.

Показанные на Рисунке 14 несколько Р2Р ТС соединены в mesh-структуру. Работа Р2Р ТС зависит от транспортных протоколов нижнего уровня, устраняющих циклические маршруты в сети. Как и в случае Е2Е ТС, Р2Р ТС обычно связаны с ОС, используемыми в датчиках или иных конечных устройствах. Разница между двумя типами ТС в том, как реализуется корректировка времени прохождения сообщений через ТС.
Предположим, что изначально путь между ОС-1-1 (GM) и ОС-1-2 (ведомое устройство) был A, B, G, E, D, как определено транспортным протоколом нижнего уровня относительно протокола РТР. Сообщения синхронизации от ОС-1-1 будут скорректированы в Р2Р-1-1 на время прохождения пакета синхронизации в устройстве Р2Р и на время задержки распространения в линии А. Аналогично, устройство Р2Р-2-1 будет дополнительно корректировать время задержки передачи пакета в самом себе и задержку в линии В, и так далее, так, что ОС-1-2 принимает сообщение Sync, откорректированное на время задержки в устройствах Р2Р 1-1, 2-1, 2-2 и 1-2 и задержки в линиях A, В, G, E. ОС-1-2, который также поддерживает механизм измерения задержки в линии, определяет и корректирует задержку на последнем участке D.

Предположим, что сеть реконфигурируется так, что новый путь между двумя узлами теперь проходит через A, C, D. Устройство Р2Р-1-1 делает ту же корректировку сообщений синхронизации, что и раньше. Однако, в данном примере, устройство Р2Р-1-2 теперь принимает сообщение Sync напрямую от Р2Р-1-1 и, таком образом, корректирует время прохождения сообщения в устройстве и задержку в линии С, которая была измерена ранее. Именно это предварительное измерение задержек в линии по всем соединениям, как активным, так и не активным, позволяет реализовать быструю реконфигурацию.

В протоколе отсутствует требование, чтобы все соединительные линии РТР использовали одинаковые транспортные протоколы или технологии. Для связи между различными сетевыми транспортными технологиями используется ВС, как показано на Рисунке 15.

На Рисунке 16, предполагается, что ВС-1, ОС-1, ОС-3 и ОС-5 обмениваются данными через сетевые стыки, обозначенные литерой «А», использующие один протокол, например, UDP/IP. ВС-2, ОС-2, ОС-4 и ОС-6 обмениваются данными через сетевые стыки, обозначенные литерой «В», использующие другой протокол, например, DeviceNet. Одно из устройств, на Рисунке 16 это ВС-2, является мостом, который поддерживает технологию А на Порту-2 и технологию В на остальных портах.

Рисунок 16. Интерконнект между различными технологиями

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

Чтобы обеспечить более упорядоченное поведение, когда узел включается в линию, все ОС и ВС слушают сообщения Announce от задающего генератора в течение настраиваемого временного интервала. Если в течение данного интервала сообщение Announce принято не было, узел предполагает, что он является задающим генератором до тех пор, пока не появится «лучший» генератор.

Дополнительный механизм для поддержки более упорядоченной реконфигурации систем, при добавлении или удалении узлов, изменении характеристик генераторов или изменения топологии соединений реализуется через состояние PRE_MASTER. В данном состоянии порт устройства ведет себя, как если бы он находился в состоянии MASTER, за исключением того, что он не указывает некоторые классы сообщений на портах использования протокола РТР. Порт остается в состоянии PRE_MASTER достаточно долго, чтобы позволить изменениям распространиться из узлов в системе между внутренним генератором и возможными ведущими генераторами, находящимися за портом.