Волгоградский государственный университет
студент
Научный руководитель: Умницын Михаил Юрьевич, ассистент кафедры Информационной безопасности Волгоградского государственного университета
УДК 004.273
ВВЕДЕНИЕ
Фильтрации и маршрутизация пакетов на основе политик, имеет ряд недостатков, причем они становятся более ощутимыми при ужесточении требований к безопасности защищаемой сети. Отметим основные из них:
На самом деле причин возникновения ошибок маршрутизации и фильтрации гораздо шире и подлежит отдельному рассмотрению, однако способ их выявления зачастую одинаков: администратор сравнивает фактическое состояние сети с ожидаемым, ищет различия и выясняет, при каких обстоятельствах они могли возникнуть. В большинстве случаев это осуществляется вручную. Специалист по маршрутизации самостоятельно регистрируется на отдельных устройствах маршрутизации и проверяет информацию о маршрутах и конфигурацию самих устройств, пытаясь выявить причины ошибок и несоответствия.
Тем временем гораздо эффективнее для поиска причины использовать средства мониторинга и аудита, которые регулярно и параллельно на всех обследуемых устройствах могут делать моментальные снимки с помощью инструмента для анализа маршрутов, а также собирать всю необходимую информацию, на всех устройствах маршрутизации. Помимо этого инструменты проверяют данные о маршрутизации на предмет возможных ошибок, автоматически выполняя те же самые шаги, которые предпринял бы специалист. После анализа, занимающего всего несколько секунд, программное обеспечение отображает возможные источники ошибок при маршрутизации, администратору в свою очередь достаточно лишь изучить их, чтобы быстро локализовать проблему. Кроме того, используя сравнению двух снимков, можно определить, какие пути были измены, кем и почему в результате возникла ошибка.
ИССЛЕДОВАНИЕ
Описанная система мониторинга и аудита должна распознавать даже промежуточные изменения в настройке отдельных устройств и сразу же сообщать об этом администратору. Например, возможно, что применение асимметричных маршрутных путей необходимо в данный момент времени при конкретных условиях, но если их число постоянно меняется, значит в сети имеется аномалия, и это необходимо проверить.
Приведенные требования можно формализовать следующим образом. При реализации функций мониторинга и аудита параметров работы систем фильтрации и маршрутизации трафика средство, отвечающее за выполнение этих функций, должно обеспечивать:
1) формирование, просмотр, редактирование, активацию (деактивацию) и удаление заданий на сбор значений параметров работы (выполнения\невыполнения правил) систем фильтрации и маршрутизации пакетов информации;
2) система должна идентифицировать любые изменения (удаление, изменение или добавление новых правил) ключевых элементов в конфигурации политик сетевых устройств, а так же выявлять следующие типы аномалий систем фильтрации и маршрутизации пакетов информации: пересечение, обобщение, затенение и избыточность. Конфигурация каждой системы должна проверяться по утвержденной базе данных эталонных образов для проверки любых изменений в настройках безопасности, которые могли бы повлиять на безопасность;
3) создание отчетов (в виде журналов) по параметрам работы систем фильтрации и маршрутизации пакетов информации. Отчет должен содержать время и дату выявления аномалии, наименование объекта мониторинга, тип выявленной аномалии, источник выявленной аномалии, краткое описание ее местоположения;
4) выдачу аварийных сообщений по параметрам работы и конфигураций систем фильтрации и маршрутизации пакетов информации, если полученные значения отличаются от установленных.
Т.о. для полноценного контроля за процессами фильтрации и маршрутизации, средство обеспечивающее данные функции должно предоставлять следующие возможности:
Применение метода функциональной декомпозиции позволило выделить в таблицу составные части, характерные для описанной системы мониторинга и аудита.
Таблица 1. Составные части алгоритма мониторинга и аудита
Подсистема сбора данных |
Осуществляет с заданной регулярностью опрос объектов, подлежащих мониторингу, для получения исследуемых значений. Может также включать в себя первичный анализ полученных данных с целью, квалификации полученных значений как нормальных, требующих вмешательства оператора либо критических.
|
Подсистема хранения |
Отвечает за накопление, хранение, архивацию данных о результатах проверок. Включает компоненты для работы с базами данных (БД) или иными репозиториями, программные средства уменьшения объема хранимой информации и т.п. |
Подсистема анализа данных |
Включает компоненты, производящие исследования данных, накопленных системой, сбор статистики, выработку эталонных значений и сравнение с ними различных состояний наблюдаемой системы, верификацию правил маршрутизации и фильтрации и т.д. |
Подсистема оповещения |
Отвечает за уведомление лиц, ответственных за функционирование проверяемых объектов о нештатных ситуациях и иных значимых событиях, возникающих в системе. |
Подсистема вывода |
Отвечает за представление информации о работе системы и результатов проверок в виде, удобном для восприятия пользователем. Для взаимодействия с конечным пользователем, безусловно, необходим развитый интерфейс, предоставляющий удобную навигацию между различными типами отчетов и сводок о состоянии объектов мониторинга. |
Эти подсистемы ориентированы на оперативный мониторинг, направленный на оценку текущей работоспособности и немедленную реакцию на разнообразные внештатные ситуации работы систем маршрутизации и фильтрации.
На рисунке 1 приведена возможная архитектура системы, удовлетворяющей этим требованиям.
Рисунок 1 ‒ Архитектура системы мониторинга и аудита
Фактически можно говорить о том, что типовые особенности, наложенные на конкретную архитектуру, выражают требования к функциональной модели разрабатываемой системы. По методологии IDEF0 для программного комплекса мониторинга и аудита правил фильтрации и маршрутизации сетевого трафика разработана функциональная модель, определяющая структуру и связи подсистем системы мониторинга и аудита. Модель разрабатываемой системы, построенная согласно данному стандарту приведена на рисунке ниже.
Рисунок 2 ‒ Контекстная диаграмма верхнего уровня
Рисунок 3 ‒ Дочерняя диаграмма
Представленная функциональная модель состоит из двух диаграмм: родительской диаграммы (А0) и диаграммы, представляющей ее декомпозицию.
Основной функциональный блок, который определяет систему в качестве единого модуля, детализируется на другой диаграмме с помощью шести блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами.
В процессе декомпозиции, функциональный блок, представленный на родительской диаграмме, был подвергнут детализации на второй диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока родительской диаграммы и является дочерней. Декомпозиция была произведена в соответствии с шестью основными модулями, которые должны быть включены в ПС мониторинга и аудита (таблица 1). Таким образом, блок, представленный на родительской диаграмме, был разбит на следующие функциональные блоки:
– обработка события ИБ (А1);
– сбор информации об этом событии (А2);
– сохранение собранной информации (А3);
– анализ сохраненной информации (А4);
– распространение проанализированной информации (А5);
– отобразить распространенную информацию (А6).
Управление будет воздействовать на все шесть функциональных блоков, представленных на диаграмме, декомпозирующей родительскую диаграмму.
Можно утверждать, что математического моделирования, для приведенного набора модулей, требует только та часть, функции которой сводятся к анализу и проверке формальных спецификаций. Известны различные общие подходы, но их применимость к верификации правил фильтрации и маршрутизации ограничена, в следствие чего существующих средств сетевого мониторинга и управления маршрутизацией\фильтрацией, удовлетворяющих всем поставленным в данном исследовании требованиям не выявлено.
Следует отметить, что аномалии возникающие в правилах фильтрации и маршрутизации легко поддаются математической формализации, что стало одним из решающих факторов, повлиявших на результат тщательного анализа, в ходе которого был сделан следующий вывод: для данной работы наиболее подходящим представляется сигнатурный метод верификации правил. Этот подход предполагает структурирование и последующий анализ собранной о конфигурациях политик информации. Т.о. основным преимуществом данного подхода является сочетание простоты программной реализации с максимальной точностью выявления аномалий.
Для реализации выбранного метода было принято решение положить в основу аудита правил фильтрации и маршрутизации способ выявления аномалий основанный на составлении и последующем сравнении текущих значений объектов мониторинга с контрольными. Формализуем данный прием следующим образом.
Пускай существует такое множество, элементы которого описывают состояние объекта мониторинга. Назовем его профилем объекта и обозначим как П. При этом выделяют два вида профиля:
1) контрольный профиля (Пк): данный профиль формируется при тестовом проведении мониторинга системой мониторинга и аудита или задается вручную, уполномоченным на то специалистом, и характеризует состояние контролируемого объекта.
2) текущий профиль (Пт): данный профиль создается каждый раз при проведении мониторинга состояния КС.
Программный комплекс мониторинга и аудита правил фильтрации и маршрутизации согласно выдвигаемым к нему требованиям должен предусматривает два типа аудита: целостности конфигураций и противоречий правил конфигураций, которые легко формализовать в виде блок-схем:
В первом случае в качестве контрольного профиля выступает эталонный профиль, параметры которого изначально считаются безопасными, а во втором – профиль аномалий, определяющий набор сигнатур противоречивого поведения.
Для формирования текущего и эталонного профиля разработана модель профиля защищаемой сети. Данная модель описывает статические характеристики сети, такие как топология, множество узлов сети, их расположение, характеристики и связность друг с другом, правила маршрутизации и фильтрации в сети. Данная модель выступает в качестве текущего и эталонного профиля в программном комплексе мониторинга и аудита правил фильтрации и маршрутизации.
Математически модель сети можно определить как набор множеств статических параметров, характерных для реальной сети. M=<N, L, R, IP, PORTS, PROTOCOLS>, где M – модель сети, N – множество узлов в сети, L – множество связей в сети, R – множество правил в сети, IP – множество адресов в сети, PORTS – множество портов в сети {0..65535}, PROTOCOLS – множество протоколов, используемых в сети {IP, ICMP, TCP, UDP}.
Ниже приведена таблица с подробным описанием всех элементов модели.
Описание составляющих |
Составляющие |
Описание элементов |
Узел в сети характеризуется адресом, типом и узлом сети, которому он принадлежит. |
n є N, n = Tє{Подсеть, Диапазон, Хост, Коммутатор, Маршрутизатор, МЭ} |
ip – множество адресов узла, T – тип узла, n' – узел сети, для которого узел n является вложенным. |
Множество связей представляет собой множество пар узлов, которые связаны напрямую в сети |
L=<(n1,n2)> |
n1 – первый узел пары узлов, n2 – второй узел пары узлов. |
Множество правил представлено множеством правил фильтрации и маршрутизации |
R=<PR,PF> |
PR – множество правил маршрутизации в сети, PF – множество правил фильтрации в сети. |
Правило фильтрации определяется как набор из оконечной точки источника, оконечной точки цели и действия, задаваемого для правила |
pf є PF, pf = <nr, Vs,Vd, a є {Разрешить, Запретить}>, где V = |
nr – объект, которому принадлежит правило, Vs – оконечная точка источника, Vd – оконечная точка цели, a – действие правила, port – порт узла, protocol – протокол передачи. |
Правила маршрутизации в модели определяют направления в сети для достижимости между объектами |
pr є PR, pr = <nr, nd, nfd> |
nr – объект, которому принадлежит правило, nd – объект-цель, nfd – объект-шлюз. |
Теоретиком-множественная модель, описывающая профиль защищаемой сети, позволяет формализовать профиль аномалий правил фильтрации и маршрутизации, используемый в случае аудита противоречий правил в качестве контрольного профиля.
Формализованные сигнатуры аномалий, которые соответствует небезопасным параметрам правил конфигурации имеют следующий вид:
Название |
Математическое представление |
«Затенение» |
Пусть правило A предшествует правилу B в списке правил. Тогда правило B будет затенено правилом A, если выполняется условие:
|
«Обобщение» |
Пусть правило A предшествует правилу B в списке правил. Тогда правило B будет обобщать правило A, если выполняется условие:
|
«Пересечение» |
Для правил A и B в списке правил будет определено пересечение, если выполняется условие:
|
«Неиспользуемые правила» |
Для правил A и B в списке правил правило A будет избыточно, если выполняется условие:
|
В данной работе разработана архитектура и функциональная и теоретико-множественная модель системы мониторинга и аудита, , описаны алгоритмы функционирования ее модулей и подсистем, выявлено взаимодействие между этими модулями.
Предлагаемое решение для системы мониторинга и аудита:
Рецензии:
18.10.2014, 21:29 Клинков Георгий Тодоров
Рецензия: Рекомндуется к публикации.Основания:
1.Актуальность приложной проблематики...
2.Динамика проявлений в режиме постоянного контролья...
3.Алгоритмизация отдельных процессов информационной безопасности приложения дают возможности применить разных(типовых)трафиках маршрутизации и фильтрации.
Комментарии пользователей:
Оставить комментарий