CC BY
68
operations and allows to describe as the value tags corresponding to the group AnyLogicalOrCompareOperation; 2) MultipleLogicalOperation is intended to describe the multiple logical operations and allows to describe as the value two or more tags corresponding to the group AnyLogicalOrCompareOperation. Many logical operations, such as “or”, “and”, “xor” are binary. When writing complex queries, there is a need to union more than two operands with one operation. To get rid of repeating the same operation several times XML-type MultipleLogicalOperation has been described. The types of concrete operations (tags <And>, <Or>, <Xor>) were inherited from this XML-type. Thus, in general, binary operations are n-ary ones. The values of these operations are evaluated from left to right. It corresponds to the serial extraction of tags by such programming interfaces (API) as DOM or SAX [4].
Similar approach is used for tags developing, that allows to describe the comparison operation: for the unary operations the type UnaryCompareOperation was defined, and for the binary ones the type MultipleCompareOperation was used. Both types are inherited from the base one CompareOperation. The binary operations are n-ary as well as logical ones. The operation IsNull is the only unary operation declared in the schema. It checks empty value for the attribute the type of which is a class. Fig.1 shows that for the other comparisons we can use a set of tags as child elements corresponding to the group ExpressionContent, which represents a sequence of arithmetic operations (the group AnyArithmeticOperation), attribute values (the tag <Attribute>) and constant values recorded in the tag <ConstValue>. Since the value of the last XML-node is a string, then using the “Type” attribute we can specify the desired type, corresponding to the types of DBMS into the query language of which the XOQL-query will be transformed.
In any comparison operation the tag <Attribute> can be used. It suggests the potential for describing a path expression. This approach demonstrates the commonality of the implemented treatment of the dot notation (for a path expression).
This article describes in detail the basic syntax constructions of the object query language XOQL, based on XML-applications. The key areas of the presented research progress consider the problem of the expansion of the proposed syntax with additional constructs (“order by”, “group by”, “having”, etc.) and the description of the directives which allow to add new data, to edit and delete the existing ones. It is also necessary to develop and implement an algorithm for transformation of XOQL-queries into a certain dialect of queries (e.g., SQL), supported by a specific DBMS.
References
1. Graves M. Designing XML Databases, Prentice Hall PTR, 2001, 688p.
2. Cattell R.G., Barry D.K. The Object Data Standard:ODMG 3.0, Morgan Kaufmann Publishers, 2000,
288p.
3. Russell Butek, Web services tip: Use polymorphism as an alternative to xsd:choice, http://www.ibm.com/developerworks/webservices/library/ws-tip-xsdchoice.html
4. Holzner S. Real World XML, Second Edition, Peachpit Press, 2003, 1200p.
УДК 004.457
ПРИМЕНЕНИЕ ОБЪЕКТНОГО ПОДХОДА ПРИ СОЗДАНИИ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ ВЫЯВЛЕНИЯ И ПРЕДОТВРАЩЕНИЯ АТАКИ ТИПА ARP-SPOOFING
Крылов Александр Юрьевич, студент, Ивановский государственный химикотехнологический университет, Россия, Иваново, Krylov Al@mail.ru Шитов Николай Андреевич, студент, Ивановский государственный химикотехнологический университет, Россия, Иваново, niko 1989@inbox.ru Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химико-технологический университет, Россия, Иваново, galiaskarov@isuct.ru
18
В современном мире одном из важнейших требования к инфраструктуре предприятия является ее безопасность. К сожалению, в наши дни не существует идеальной системы защиты от компьютерных атак, проводимых с различными целями - кража, повреждение, или удаление информации. Нашей задачей являлась разработка принципиально нового метода выявления сетевых атак и последующего предотвращения их, после чего требовалось продемонстрировать разработанный метод на примере одной из наиболее распространенных атак, качественной защиты от которой пока еще нет. Выработанная методология базируется на объектном подходе и демонстрируется на примере атаки типа ARP-spoofing, а также прототипе системы, разработанном для демонстрации выявления и предотвращения описанной ниже атаки нашим методом.
Address Resolution Protocol - протокол определения адреса, использующийся в компьютерных сетях для определения адреса канального уровня по известному адресу сетевого уровня. В сетях, основанных на технологии TCP/IP, протокол получил широкое распространение для определения MAC-адреса целевого узла по его IP-адресу для последующей передачи данных. При необходимости передачи данных к какому-либо узлу по его IP-адресу производится проверка ARP-таблицы на предмет наличия в ней сопоставленного указанному IP-адресу своего MAC-адреса. Если таковой находится -данные отправляется на сопоставленный MAC-адрес. Если же такой записи нет в таблице -отправляется широковещательный ARP-запрос, предназначенный узлу с указанным IP-адресом, который игнорируется всеми узлами, кроме имеющего заданный IP адрес. Данный узел формирует ARP-ответ, содержащий свой IP и MAC-адрес и отправляет его узлу, отославшему ARP-запрос. Получив ARP-ответ, узел записывает полученную информацию в ARP-таблицу, где каждому IP-адресу сопоставлен свой MAC-адрес, что позволяет при необходимости передачи данных указанному IP-адресу узнавать его MAC-адрес без ARP-запроса. По прошествии 10 минут, если передача данных определенному IP-адресу не производится, запись автоматически удаляется из таблицы [1].
Суть атаки типа ARP-spoofing основана на такой уязвимости вышеописанного протокола, что при приеме ARP-ответа не производится никакой проверки подлинности относительно отправителя этого пакета. Это позволяет любому узлу в данной сети сформировать ложный ARP-ответ, указав в качестве MAC-адреса свой, получив таким образов возможность перенаправить на себя все пакеты, которые жертва отсылает на указанный IP-адрес. Таким образом, злоумышленник имеет возможность «вклиниться» в канал передачи данных между двумя узлами и безо всяких проблем прослушивать их трафик [2-3].
Допустим, имеются два компьютера, намеревающиеся произвести обмен данными, А и В. До выполнения ARP-spoofing^ в ARP-таблице узлов A и B существуют записи с IP- и MAC-адресами друг друга. Обмен информацией производится непосредственно между узлами A и B (1,2,3,4). В ходе выполнения ARP-spoofing^ компьютер C, выполняющий атаку, отправляет ARP-ответы (без получения запросов): узлу A: с IP-адресом узла B и MAC-адресом узла C; узлу B: с IP-адресом узла A и MAC-адресом узла C.
В силу того, что компьютеры поддерживают самопроизвольный ARP (оповещение об изменении ARP-таблицы), они модифицируют собственные ARP-таблицы и помещают туда записи, где вместо настоящих MAC-адресов компьютеров A и B стоит MAC-адрес компьютера C (7,8). После того как атака выполнена, когда компьютер A хочет передать пакет компьютеру B, он находит в ARP-таблице запись (она соответствует компьютеру C) и определяет из неё MAC-адрес получателя.
Отправленный по этому MAC-адресу пакет приходит компьютеру C вместо получателя. Компьютер C затем ретранслирует пакет тому, кому он действительно адресован — т.е. компьютеру B (9,10,11,12). Таким образом, узел С становится своего рода посредником при передаче данных между узлами А и В, что дает злоумышленнику возможность видеть все данные, передаваемые узлами А и В друг другу.
19
Таким образом, процесс атаки типа ARP-spoofing можно представить в виде объекта, состояние которого меняется при совершении каждого из шагов в реализации этой атаки (в данном случае - отправка ложных ARP-ответов атакуемым узлам) и построить автомат для выявления подобной атаки.
Рис. 1 Схема проведения ARP-spoofing
Предложенный метод решения этой проблемы заключается в отслеживании в сети событий, из которых состоит атака, и построении из них цепочек, позволяющих выявить во множестве этих событий производимую атаку.
Рассмотрим приход ложных ARP-ответов атакуемым узлами как два события, которые при условии, что они оба произошли в промежутке времени до 10 минут, представляют собой атаку типа ARP-spoofing. Т.о. мы получаем возможность, отслеживая в сети подобные события, выявить данную атаку, используя математическую теорию конечных автоматов. Учтем, что уведомления о получении ARP-ответов (любых) будут приходить с узлов, потенциально являющихся атакуемыми.
Рис. 2 Диаграмма состояний объекта, приписываемого проводимой потенциальной атаке для её
выявления (конечный автомат)
Находясь в состоянии 1, автомат выполняет формирование условий, по которым впоследствии будет решаться, принимает ли автомат пакет данных (с последующей интерпретацией его как события) или нет. После перехода во второе состояние автомат сигнализирует о выявленной атаке и запускает процедуру восстановления искаженных ARP-таблиц на атакуемых компьютерах, после чего управление передается менеджеру автоматов, удаляющему его.
Следует учесть, что событие «В», представляющее собой получение вторым, потенциально атакуемым узлом ложного ARP-ответа, описывается на основе данных о событии «А» - отправке ложного ARP-ответа первому, потенциально атакуемому узлу. Получив уведомление о событии, «А» система (разработанная и описанная нами ниже) генерирует соответствующие условия, на основе которых решается, является ли получение каким-либо другим узлом ложного ARP-ответа событием «В», предназначенным этому автомату. Зависимость ложного ARP-ответа второму атакуемому узлу от ложного ARP-ответа первому узлу изображена ни рис. 3.
20
+ Bits 0-7 8-15 16-31
0 Hardware type Protocol type
32 Hardware length Protocol length Operation
64 SHA
96 SHA SPA
12В SPA THA
160 THA
196 TPA
SHA = SHA SPA = TPA TPA = SPA
+ Bits 0-7 8-15 16-31
0 Hardware type Protocol type
32 Hardware length Protocol length Operation
64 SHA
96 SHA SPA
128 SPA THA
160 THA
196 TPA
Рис. 3 Зависимость отправляемого второму атакуемому узлу ARP-ответа от отправленного
первому атакуемому узлу, где
SHA - MAC-адрес отправителя; SPA - IP-адрес отправителя; THA - MAC-адрес получателя; TPA - IP-адрес получателя. Одинаковыми стилями обозначены поля, которые в этих пакетах, для успешной атаки должны быть равны.
Рассмотрим архитектуру системы. Программная структура системы включает серверную часть и сетевых агентов:
1. Сетевые агенты - неавтономные модули, функционирующие в режиме прослушивания выбранного сетевого адаптера на предмет приема\отправки пакетов протокола ARP и отслеживающие ARP-запросы и ARP -ответы, запускаемые в виде системных сервисов на компьютерах наблюдаемой сети.
2. Серверная часть - автономный модуль системы, обеспечивающий интерпретацию полученных уведомлений об ARP-ответах, сопоставление их событиям и функционирование автоматов, изменяющих свое состояние в зависимости от поступивших к ним на вход событий. При обнаружении атаки отправляет сетевым агентам, расположенным на атакуемых узлах, специальные команды для предотвращения атаки.
Функционально серверная часть системы подразделяется на четыре объекта (рис. 4):
• приемник входящих пакетов;
• менеджер автоматов;
• автомат (автоматы);
• обработчик системных сообщений.
-next atm
Auto mat в Ma n age г
-atm_quant: int
+A uto m ats M a n ag e r()
+C re ate N ewA uto m at()
+D e I ete Autom atByl ntN a me () +D e I eteTh i s Auto m at()
+S end I n Autom ats ()
+P n ntAuto matState ()
+G etAuto mats Q u antity () +GenNameForAutomat()
+~A uto m ats M a n age r()
ARPAutomat
-first -------------------------
--------c_name : u_char
-----5>-name : int
-last . . . .
--------state_atm : int
-rec : bool
-adhandle : pcap_t*
- Re cove ryARPTa Ы e s ()
+ARPAutomat()
+lnitializing()
+P us h Pa ckag eTo Auto mat() +C h a nge Atm State () ♦ActionlnStateQ +ldentifyEvent()
♦ SetRecValueQ +G etAuto matN a me ()
+Pri ntAuto matlnfoQ +~ARPAutomat()
previous_atn
-attack_comp
«struct»
computer
+ip : u_char[4] ♦mac: u_char[6]
Рис. 4 Диаграмма классов серверной части системы
21
Рис. 5 Диаграмма действий серверной части системы при получении пакета данных
Структура серверной части системы следующая:
• Приемник входящих пакетов. Первая ступень серверного модуля системы, реализованная при помощи библиотеки Pcap [4], позволяющий получать доступ напрямую к сетевому адаптеру для перехвата поступающих на него пакетов до их попадания в ядро операционной системы. Также поддерживает функцию перехвата исходящих сообщений с прослушиваемого сетевого адаптера. В нашем случае, получив из сети пакет, соответствующий протоколу системы, в зависимости от типа пакета отправляет его либо менеджеру автоматов, либо обработчику системных сообщений.
• Менеджер автоматов предназначен для обработки пакетов, несущих информацию о получении или отправке какими-либо узлами сети ARP-ответа. Реализует такие функции, как создание новых, контроль и удаление автоматов, функционирующих в ядре системы. Алгоритм работы серверной части системы представлен на рис. 5.
• Автомат - объект, приписанный отдельной, потенциально производимой в сети атаке, изменяющий свое состояние в зависимости от событий, поступающих на его вход. Является своего рода индикатором, своевременно информирующим об атаке,
22
если такая будет замечена - автомат переходит в конечное состояние. Поскольку в системе может одновременно функционировать большое количество автоматов, ограничиваемое лишь ресурсами компьютера, автоматы реализованы в виде связного списка, позволяющего при необходимости удалять ненужные и создавать новые автоматы, практически не затрагивая при этом остальные.
• Обработчик системных сообщений отвечает за обработку сообщений, передаваемых системе с кодом протокола 0x00:0xFF, которые интерпретируются и передаются ему для обработки. В качестве примера можно привести широковещательный запрос MAC-адреса сервера системы сетевым агентом, только что запущенным на защищаемом от атаки узле.
Диаграмма классов, описывающая методы менеджера автоматов и самого объекта автомата, реализованные в прототипе системы представлена на рис. 4.
Сетевые агенты запускаются на компьютерах, которые необходимо защитить от вышеописанной атаки, и функционируют в фоновом режиме как системные службы.
После запуска клиент отсылает широковещательный запрос MAC-адреса сервера системы и, получив ответ, переходит в режим прослушивания выбранного сетевого адаптера на предмет получения\отправки ARP-запросов\ответов и системных сообщений от сервера. При получении ARP-ответа агент отправляет уведомление об этом серверу, после чего продолжает свое функционирование. Если на сервере была выявлена атака против этого компьютера, агент получает от сервера системное сообщение с командами, которые необходимо выполнить на данном компьютере для предотвращения производимой атаки, которые выполняет и снова возвращается к своим штатным обязанностям - прослушиванию сетевого адаптера.
Таким образом, программная реализация представляет собой распределенную систему, развертываемую в локальном сегменте сети, компьютеры которого необходимо защитить от подобной атаки.
В данной статье предложена программная система, имеющая следующие важные достоинства:
• возможность отслеживать одновременно множество атак. Число автоматов, сопоставленных каждой из них, ограничено лишь ресурсами компьютера, на котором запущена серверная часть системы;
• система полностью автономна, не требует настройки при установке как серверной, так и клиентской (сетевые агенты) частей;
• сервер и агенты функционируют в фоне и независимо от пользователей, которые, в свою очередь, даже не догадываются о том, что, например, была предотвращена атака против их компьютера;
• особенности реализации программной системы исключают возможность проведения атаки типа ARP-spoofing против самой системы с целью вывода ее из строя;
• оптимизация пакетов данных позволяет функционированию системы практически не загружать работу сети;
• разработанный объектный метод применим также для выявления и предотвращения других атак, т.о. является универсальным.
Литература
1. RFC 826: an Ethernet Address Resolution Protocol. [Электронный ресурс]:[стандарт]. - Режим доступа: http://tools.ietf.org/html/rfc826.
2. ARP-spoofing/ Игорь Чубин. [Электронный ресурс]:[статья]. - Режим доступа: http://xgu.ru/wiki/ARP-spoofing
3. ARP-spoofing/Wikipedia. [Электронный ресурс]:[статья]. - Режим доступа: http://ru.wikipedia.org/wiki/ARP-spoofing
4. Документация по применению библиотеки winpcap. [Электронный ресурс]:[электрон. документация]. - Режим доступа: http://www.winpcap.org/docs/docs 412/html/main.html
23
УДК 004.652.5
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ МОДЕЛИРОВАНИЕ БАЗ ДАННЫХ СИСТЕМ
ФИЗИЧЕСКОЙ ЗАЩИТЫ
Саенко Игорь Борисович, д. т.н., проф., ведущий научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук (СПИИРАН), Россия, Санкт-
Петербург, ibsaen@mail.ru
Невров Алексей Александрович, к.т.н., научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук (СПИИРАН), Россия, Санкт-Петербург,
newrow@mail.ru
Салами Мохамад Юнес, аспирант, Санкт-Петербургский институт информатики и автоматизации Российской академии наук (СПИИРАН), Россия, Санкт-Петербург
Современные реалии окружающего мира диктуют государственным структурам необходимость построения систем физической защиты (СФЗ) находящихся в их ведении объектов. СФЗ является сложной системой и состоит из ряда организационных и технических подсистем. Основными структурными компонентами построения СФЗ являются следующие технические системы [1]: охранной сигнализации; оптико-электронного
наблюдения; тревожно-вызывной сигнализации; контроля и управления доступом; оперативной связи и оповещения; обеспечения электропитания.
В настоящее время наблюдается тенденция к интеграции указанных систем на базе единой вычислительной платформы. Однако существующие практические решения, как правило, представляют собой совместное выполнение на одной ЭВМ нескольких модулей, реализующих функции одной из технических подсистем. Такой способ объединения нельзя назвать интеграцией.
Для полноценной интеграции различных подсистем СФЗ, состоящих из множества неоднородных технических средств, необходимо создать единую информационную модель, позволяющую объединить в ее рамках все множество конкретных видов оборудования, типовые классы оборудования, а также логические объекты (видеопотоки, трассы проходов субъектов, критические пути проникновения и т.п.). Данная информационная модель должна включать правила взаимодействия технических средств и логических объектов. Примером такого правила является следующее утверждение: «срабатывание датчика активизирует запись видеопотока со связанной камеры».
Технологической основой для баз данных (БД) каждой из существующих в настоящее время технических подсистем СФЗ, как правило, являются реляционные базы данных. К их достоинствам можно отнести развитые методологию и инструментарий построения информационной модели предметной области [2]. Плюсом является широкий спектр решений, распространяющийся от настольных систем управления базами данных (СУБД) до сверхмощных кластерных систем. Однако реляционная модель представления данных не лишена ряда недостатков, которые проявляются при попытке реализации на ее основе единой информационной модели СФЗ [3]. Эти недостатки связаны, прежде всего, со статичностью структуры БД, ограниченными возможностями по реализации поведенческого аспекта элементов системы, отсутствием учета особенностей временных (темпоральных) данных.
Наличие указанных недостатков, а также другие сложности, возникающие при попытке объединения реляционных БД различных подсистем СФЗ, приводят к выводу, что интегрированная информационная подсистема, объединяющая БД всех подсистем СФЗ, должна строиться на основе постреляционной СУБД, позволяющей обойти указанные недостатки реляционных СУБД.
Моделируемой предметной области СФЗ в наибольшей степени соответствует концепция объектно-ориентированного проектирования (ООП). Это связано с широким спектром технических средств, параметры и характеристики которых зачастую не могут быть сведены в единую таблицу. Также следует отметить возрастающую
24
