Система обнаружения атак (СОА) Snort является инструментом, предназначенным для обнаружения сетевых атак в сетях, построенных на базе протоколов TCP/IP. Основным методом обнаружения атак этой СОА является анализ трафика на предмет соответствия сетевых пакетов набору сигнатур. Данный набор сигнатур описывает критерии, по которым конкретный сетевой пакет может классифицироваться как пакет, несущий некоторое атакующее воздействие. Помимо метода сигнатурного анализа в настоящее время в СОА Snort применяется и метод статистического анализа, позволяющий выявлять подозрительные аномалии в контролируемом сетевом трафике.

СОА Snort распространяется на условиях лицензии GNU GPL. Данная система может функционировать как на многочисленных UNIX-подобных платформах, так и на платформе Windows9x/2000/XP. Размер дистрибутива СОА в архиве незначительно превышает 100 кбайт, что позволяет отметить в качестве положительной характерной черты ее компактность. Сборка и установка системы занимает несколько десятков минут. В то же время адаптация настроек под конкретные условия применения может занять длительное время. Настроенная система не требует постоянного администрирования.

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

Гибкость и эффективность СОА Snort основываются на следующих особенностях системы:

-       наличие языка описания правил, используемого для создания сигнатур опасных и подозрительных воздействий;

-       наличие настраиваемого механизма реагирования на обнаруженные атаки (подозрительные воздействия);

-       модульной  архитектуре  построения  с  возможностью
создания и подключения   новых   модулей.

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

3.2. Язык описания правил

Синтаксис правила СОА Snort следующий:

ACTION PROTO IP_ADDR1 P0RT1 DIRECTION IPADDR2 P0RT2 [(OPTIONS)]

Параметр ACTION определяет дальнейшие действия при обнаружении сетевого пакета, соответствующего указанному правилу. Имеются пять директив, задающих эти действия.

Директива pass обязывает просто игнорировать пакет.

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

Директива alert генерирует уведомление об обнаружении пакета, определенным пользователем способом, и затем передает пакет процедуре журналирования.

Директива activate генерирует уведомление, а затем вызывает обработку другого правила, определенного директивой dynamic.

Директива dynamic предписывает ожидать активации правила, определенного директивой activate, а затем выполняет действие log.

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

Кроме выше описанного набора директив существует возможность определения собственных директив. Для них можно назначить правило, в соответствии с которым могут выполняться некоторые действия. Например, следующее определение:

 ruletype redalert

{

type alert output alert_syslog: LOG_AUTH LOGALERT

output database: log, mysql, user=snort dbname= snort host= localhost

}

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

Параметры PROTO, IP_ADDR1, PORT1, DIRECTION, IPADDR2, PORT2 являются обязательными и указывают основные условия, при соблюдении которых выполняется указанное в правиле действие.

PROTO – тип сетевого протокола. В настоящее время для анализа доступны три протокола, и, соответственно, допустимы три значения этого параметра - tcp, udp, icmp.

IPADDR1, IPADDR2 – IP-адреса, указанные в заголовке IP-пакета. Стоит отметить, что Snort в настоящее время не предоставляет возможности использовать вместо IP-адресов сетевые имена. Ключевое слово any позволяет задать все возможные адреса. Для подсетей указываются CIDR-блоки. Символ "!" инвертирует условие, т.е. выражение "!192.168.3.0/24" означает любой не принадлежащий подсети 192.168.3.0/24 IP-адрес. Кроме того, можно задавать списки адресов, перечисляя их через запятую и заключая в квадратные скобки: [192.168.2.0/24,192.169.3.54/32].

PORT1, PORT2 – номера сетевых портов. Возможно задать диапазон портов через двоеточие, например, 6000:6010 – порты с 6000 по 6010 включительно, :1024 - порты с 1 по 1024, 1024: - порты с 1024 по 65535. Символ "!" инвертирует условие, а ключевое слово any обозначает все порты.

DIRECTION – параметр, определяющий направление движения пакета. Допускается использование следующих значений: -> (одностороннее) – правило будет применяться только к пакетам, идущим с IPADDR1 на IPADDR2; <> (двустороннее) – направление движения пакета роли не играет.

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

Параметры отделяются друг от друга точкой с запятой, а ключевое слово параметра отделяется от его аргумента двоеточием. Есть четыре категории параметров OPTIONS:

-       meta-data – эти параметры устанавливают порядок реакции, но не затрагивают порядок обработки условий в правиле;

-       payload – эти параметры позволяют искать дополнительные данные в области данных сетевого пакета;

-       non-payload – эти параметры позволяют обрабатывать пакет, не затрагивая его область данных;

-       post-detection – эти параметры устанавливают дополнительные условия срабатывания правила после того, как выполнены основные условия правила.

Существуют следующие параметры типа meta-data:

msg   – устанавливает текст сообщения, выдаваемого в случае срабатывания правила;

reference – содержит ссылку на базу атак и обнаруженную атаку;

sid – предписывает выдавать уникальный идентификатор правила из базы правил Snort в случае срабатывания правила;

classtype – позволяет классифицировать степень опасности обнаруженного правилом события;

priority – позволяет установить приоритет обнаруженного правилом события.

Существуют следующие параметры типа payload:

content – задает шаблон поиска в содержимом пакета, а не в заголовке (шаблон можно задавать как в текстовом виде, так и в шестнадцатеричном);

nocase        – отключает чувствительность к регистру при анализе содержимого пакета;

rawbytes – ключевое слово, позволяющее правилам обрабатывать "сырые" данные пакета, игнорируя любую расшифровку, которая была сделана препроцессорами; этот параметр действует как модификатор к параметру content;

depth – определяет положение в пакете, до которого будет производиться анализ содержимого;

offset  – работает совместно с опцией content для определения смещения в пакете, с которого будет производиться анализ содержимого;

distance – позволяет автору правила определять, на каком расстоянии в пакете искать указанный образец относительно конца предыдущего образца;

within – позволяет указать пределы разнесения в N байт между двумя образцами, используя параметр content;

uricontent – позволяет осуществлять поиск с использованием URI-выражений;

isdataat – проверяет, что указанный образец находится в указанном местоположении, дополнительно осуществляя поиск данных относительно конца предыдущего образца;

pcre и regex – позволяют использовать для поиска регулярные выражения, используя синтаксис языка perl;

byte_test и byte_jump – позволяют оперировать бинарными (числовыми) значениями, используя различные формы их представления для поиска и позиционирования в сетевом пакете;

content-list  – этот параметр аналогичен параметру content за исключением того, что список искомых шаблонов берется из заданного файла.

Существуют следующие параметры типа non-payload:

fragoffset – ключевое слово, позволяющее сравнивать поля смещений во фрагментированных IP-пакетах в десятичном формате;

ttl – задает значение поля TTL в заголовке IP-пакета;

tos – задает значение поля TOS в заголовке IP-пакета;

id – задает значение поля номера фрагмента в заголовке IP-пакета;

ipopts – задает значение поля параметров IP-пакета;

fragbits – задает биты фрагментации IP-пакета;

dsize – задает условия на размер IP-пакета;

flags – задает условия на наличие или отсутствие определенных ТСР-флагов;

flow и flowbits – используются при разборе TCP-соединений;

seq – задает номер сегмента TCP-пакета в последовательности;

аск – задает значение поля подтверждения в ТСР-пакете;

window – используется для проверки размера TCP окна;

itype – задает значение поля типа ICMP-пакета;

icode – задает значение поля кода ICMP-пакета;

icmp_id – задает значение поля ICMP ECHO ID в ICMP-пакете;

icmp_seq – задает номер ICMP ECHO пакета в последовательности;

rрс – этот параметр позволяет более точно задать характеристики программных или процедурных вызовов RPC-сервисов;

ip_proto – позволяет осуществлять выбор типов протоколов из списка, которые могут быть определены по имени, см./etc/protocols;

sameip – позволяет проверить, является ли исходный адрес ip тем же самым, что и адрес назначения.

Существуют следующие параметры типа post-detection:

session – этот параметр позволяет включить извлечение пользовательских данных из ТСР-сессии, например, для последующего анализа того, какие команды вводил пользователь во время telnet-сессии;

resp   – если пакет соответствует правилу, то этот параметр предписывает Snort выполнить одно из указанных действий, например, закрыть соединение, отправив TCP-RST пакет;

react  – блокирует заданные в правиле web-сайты, закрывая соединение с ними и/или отправляя заданное сообщение браузеру, с которого была предпринята попытка соединения;

tag – позволяет сохранять в лог более одного пакета.

Перечисленные параметры позволяют создавать правила для перехвата практически любых пакетов, которые как-то могут угрожать безопасности.

На сайте http://www.snort.org всегда можно получить для своих целей набор уже готовых правил. Они разбиты на несколько групп: BackDoor Activity, BackDoor Attempts, Backdoor Sig. Based, Exploits, Finger, FTP, ICMP, MISC, NetBios, RPC, RServices, Scans, SMTP, Sysadmin, TELNET, Virus - SMTP Worms, Web-CGI, Web-ColdFusion, Web-FrontPage, Web-IIS, Web-Misc. Как видно из названий, сфера применения Snort очень широка. Чтобы не ждать обновления набора правил на сайте после публикации нового очень опасного эксплойта, можно очень быстро составить правило самостоятельно. Для этого достаточно найти в Internet новый эксплойт, применить его против подопытного хоста-жертвы, записывая в лог при этом весь трафик между атакующим хостом и хостом-жертвой. Анализируя затем лог, необходимо найти уникальную сигнатуру эксплойта.

3.3. Конфигурирование

Основная настройка СОА Snort осуществляется в файле конфигурации snort.conf. Данный файл является текстовым и должен содержать последовательность директив (команд).

Фактически файл конфигурации состоит из нескольких секций настроек.

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

Важными параметрами являются внутренние переменные Snort. Для удобства настройки правил из базы сигнатур под конкретную конфигурацию защищаемой сети непосредственно в сигнатурах общепринято использовать переменные вместо реальных IP-адресов. В конфигурационном файле Snort данным переменным необходимо присвоить конкретные сетевые адреса.

В следующей секции настраиваются препроцессоры. Препроцессоры предназначены для выполнения определенных действий над каждым пакетом до анализа пакета на соответствие ему сигнатуры. В настоящее время в стандартной поставке Snort имеются следующие препроцессоры:

portscan detector и portscan ignorehosts – предназначены для определения сканирования портов;

frag2 – предназначен для обработки фрагментированных пакетов;

stream4 – предназначен для обработки tcp-потоков;

flow – модуль, с которого предпринята попытка реализовать статистические механизмы анализа;

flow-portscan – это модуль, созданный как дополнение к модулю flow и предназначенный для обнаружения сканирования портов;

telnet decode – предназначен для декодирования telnet сессии, что в дальнейшем может быть использовано для поиска в ней заданных сигнатур;

rpc decode – предназначен для декодирования rpc сессии, что в дальнейшем может быть использовано для поиска в ней заданных сигнатур;

performance monitor – предназначен для обработки статистики, полезной для определения параметров производительности СОА;

http inspect – предназначен для декодирования http сессии, что в дальнейшем может быть использовано для поиска в ней заданных сигнатур.

В следующей секции можно определить относительно специфические параметры поведения СОА в процессе работы. Первый из них это event thresholding. Настройка данного параметра позволяет избежать излишнего "замусоривания" логов в ситуации, когда Snort обнаружил некоторое опасное воздействие и выдал сообщение о нем, но данное воздействие продолжает осуществляться и вынуждает Snort генерировать все новые и новые сообщения. Второй параметр – это event suppression. Данный параметр позволяет определить специфические для защищаемой сети адреса, для которых анализ пакетов осуществляться не будет.

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

alert_syslog – модуль, позволяющий направлять сообщения в системный журнал ОС;

alert_fast – модуль, позволяющий направлять короткие текстовые сообщения в указанный файл;

alert_full – модуль, позволяющий направлять в указанный файл текстовые сообщения, в которых, помимо прочего, печатается заголовок сетевого пакета;

alert_unixsock – модуль, позволяющий направлять сообщения, используя механизм сокетов;

log_tcpdump – модуль, позволяющий сохранять целиком сетевой пакет в формате tcpdump;

database – модуль, позволяющий сохранять сообщения базах данных;

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

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

3.4. Архитектура системы

3.4.1. Основные программные компоненты

Прежде чем начать описание архитектуры СОА Snort необходимо обратить внимание на следующие особенности:

1. СОА Snort построена на основе модульной архитектуры. Это дает возможность подключать программные дополнения, созданные сторонними разработчиками. Далее данная возможность будет описана подробнее.

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

Таким образом, будет удобнее рассматривать архитектуру СОА в двух плоскостях:

архитектуру всей системы, включающую собственно ядро обнаружения и все остальные составляющие, образующие необходимую инфраструктуру;

архитектуру собственно ядра, анализирующего сетевой трафик.

Общая архитектура с привязкой к основным модулям (в данном случае имеются в виду программные модули текстов на языке Cи) представлена следующими блоками.

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

Блок разбора правил предназначен для выполнения двух основных задач. Первая задача состоит в собственно лексическом анализе правил. Основные функции, выполняющие данную задачу, реализованы в модуле parser.c. В нем осуществляется разбор правил, которые рассматриваются либо как строки из файлов с расширением rules, либо как строка с описанием правила из файла конфигурации. В процессе анализа производится разбивка строк на лексемы (это осуществляется при помощи строковых функций из mstring.c), и далее по этим лексемам осуществляется заполнение специальных управляющих структур.

В модуле rules.c реализованы процедуры, которые на основе результатов, полученных при разборе правил,  осуществляют создание и заполнение специальных структур, используемых при последующем анализе пакетов.

Наиболее важными среди этих структур являются:

1. _RuleFpList – при помощи этой структуры организуется список указателей на функции проверки правил.

2. _OptFpList – организуется список указателей на функции обработки опций правил.

3. _RspFpList – организуется список указателей на функции, которые выполняются в случае соответствия или несоответствия пакетов правилам.

4. _TagData – справочная информация по пакетам (время, когда пакет был принят, число пакетов).

5. _OptTreeNode – организует список опций правил с функциями обработки.

6. _RuleTreeNode – правило уже в разобранном виде, также заполняет структуры (_ActivateList, IPAddSet ).

Процесс разбора правил достаточно тесно связан с подключением дополнений. Основные процедуры, необходимые для подключения дополнений, реализованы в модуле plugbase.c. Данный модуль инициализирует детектирующие модули, препроцессоры и модули вывода информации.

Блок детектирующих модулей содержит модули, которые предназначены для обнаружения какого-либо одного аспекта при анализе пакетов.

В настоящее время реализованы следующие детектирующие модули.

Модуль sp_ip_fragbit.c реализует опцию fragbit, которая управляет анализом бита фрагментации в IP пакетах.

Модуль sp_ip_id_check.c реализует опцию id, которая управляет анализом уникального идентификатора IP пакета (фрагмента), необходимого для сборки пакета.

Модуль sp_ip_proto.c реализует опцию proto, при помощи которой определяется протокол, инкапсулированный в IP пакет.

Модуль sp_ip_tos_check.c реализует опцию tos, которая служит для обозначения требуемого для данной IP датаграммы типа обслуживания. Например, FTP, HTTP, Telnet. В этой опции определяется приоритет, задержка и другие характеристики IP пакета.

Модуль sp_ipoptions_check.c реализует опцию, анализирующую часть заголовка IP-датаграмм, где хранятся дополнительные опции, которые устанавливают более подробную инструкцию по обработке данного IP пакета.

Модуль sp_pattern_match.c реализует механизм задания и проверки данных пакетов в соответствии с некоторым образцом.

Модуль sp_priority.c реализует механизм задания и проверки пакетов по их приоритетам, которые определяются в sp_ipoption_check.c.

Модуль sp_react.c реализует опцию react, которая позволяет блокировать заданные в правиле Web-сайты, закрывая соединение с ними и/или отправляя заданное сообщение браузеру, с которого была организованна попытка зайти на некоторые сайты.

Модуль sp_respond.c реализует опцию resp, которая позволяет в случае соответствия пакета заданным правилам выполнять некоторые заданные операции.

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

В настоящее время реализованы следующие модули препроцессоров.

Модуль spp_anomsensor.c реализует SPADE препроцессор, который выявляет систематически аномальные пакеты и выдает сообщение об этом.

Модуль spp_arps_proof.c реализует препроцессор, который выполняет просмотр аномальных явлений при передаче ARP-запросов и по возможности корректирует таблицу соответствия IP адресов физическим MAC- адресам.

Модуль spp_defrag.c реализует препроцессор, который осуществляет дефрагментацию IP-датаграмм.

Модуль spp_http_decode.c реализует препроцессор, нормализующий вид http-запроса путем замены символов %ХХ на их ASCII эквивалент, так как часто за группой %ХХ скрывается запрос атаки, также модуль проверяет эти запросы.

Модуль spp_portscan.c реализует препроцессор, выявляющий попытки сканирования портов.

Модуль spp_tcp_stream2.c реализует препроцессор, который рассматривает поток tcp-пакетов, анализирует его и строит из них сеанс: <argset1>, <argset2>,…где arg может быть:

timeout – наибольшее время, в течение которого не получено ни одного пакета по данному потоку, затем соединение разрывается;

port X – порт соединения;

maxbytes – максимальное число байтов, которые могут приниматься.

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

Модуль spp_stream4.h.c реализует препроцессор, позволяющий полностью информировать пользователя о происходящем в потоке tcp-пакетов путем анализа в spp_tcp_stream2.c.

Модуль spp_telnet_acyotiation.c реализует препроцессор, который выделяет трафик Telnet и FTP сессий и анализирует введенные пользователем команды.

Блок модулей вывода информации содержит модули вывода информации, которые предназначены для протоколирования информации в указанный файл, а также для активной реакции на атаку.

В настоящее время реализованы следующие модули вывода информации.

Модуль spo_alert_syslog.c выводит информацию в журнал через системный демон syslogd.

Модуль spo_alert_fast.c выводит в указанный файл информацию о возможной атаке в однострочном укороченном формате.

Модуль spo_alert_full.c выполняет то же самое, что и spo_alert_fast.c, но в указанный файл записывается и сам перехваченный пакет.

Модуль spo_alert_unixsock.c выполняет то же самое, что и spo_alert_full.c, но вся информация передаётся в другой процесс через Unix-сокет.

Модуль spo_alert_smb.c посылает сообщение об атаке по протоколу WinPopup на указанные NETBIOS-хосты.

Модуль spo_log_tcpdump.c записывает в файл перехваченные пакеты в формате утилиты tcpdump.

Модуль spo_database.c позволяет сохранять всю информацию о перехваченных пакетах в базу данных. В настоящее время поддерживаются СУБД PostgreSQL, MySQL, Oracle, а также ODBC-совместимые базы данных.

Модуль spo_XML.c был разработан в координационном центре CERT. Основная его цель – создание целой инфраструктуры по обнаружению вторжений внутри локальной сети, где запущенные на нескольких компьютерах экземпляры СОА Snort выполняют роль сенсоров.

3.4.2. Ядро Snort

Архитектурно ядро СОА Snort состоит из трёх подсистем: декодера пакетов, подсистемы обнаружения и подсистемы регистрации и реагирования.

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

Перехват и частично декодирование пакетов осуществляется с помощью библиотеки libpcap. Основные функции по декодированию пакетов реализованы в программных модулях checksum.c и  decode.c.

В модуле checksum.c вычисляется контрольная сумма для проверки правильности принятого пакета.

В модуле decode.c (decode.h) описываются пакеты канального уровня для сетевого оборудования, заголовки пакетов протоколов: IP, TCP, UDP, ICMP, ARP, PPP, SLIP. В нем также описывается структура Packet, которая используется для реализации анализа пакетов на разных уровнях взаимодействия: канальном, сетевом, транспортном.

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

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

Основной программный модуль, в котором реализованы процедуры журналирования – log.c.

3.4.3. Механизмы анализа/разбора сетевого трафика

Анализ сетевого трафика фактически заключается в поиске сетевых пакетов, соответствующих условиям, заданным в правилах (сигнатурах). Таким образом, механизм обнаружения должен сравнить каждый перехваченный пакет с целым набором шаблонов. Поскольку набор таких шаблонов может быть достаточно большого объема (чем больше сигнатур в базе, тем в общем случае больше шаблонов), то неотвратимо встает вопрос оптимизации числа операций сравнений. С этой целью в СОА Snort был реализован механизм так называемых цепочек правил.

Как было описано ранее, любое правило состоит из заголовка, т.е. условий применения правила, и набора дополнительных параметров (опций) применения правила. В процессе разбора правила сохраняются в Деревьях Правил (RuleTreeNodes – RTN) и Деревьях Опций (OptTreeNodes – OTN). RTN и OTN являются структурами. Экземпляры этих структур хранятся в двух связанных списках. В узлах RTN хранятся заголовки правил, т.е. условия применения правил. В узлах OTN хранятся параметры (опции) правил. Для более наглядного представления можно считать, что RTN формируют горизонтальную цепочку (или верхнюю строку "массива"), а OTN формируют вертикальные цепочки, исходящие из узлов RTN (или столбцы под RTN).

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

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

3.4.4. Механизмы работы с дополнениями

В настоящее время СОА Snort поддерживает три вида подключаемых модулей: детектирующие, препроцессоры и модули вывода информации.

Детектирующие модули предназначены для обнаружения какого-либо единственного аспекта пакета и, таким образом, расширяют набор возможных параметров, определяющих условия на соответствие правилу. Так, например, параметр flags, задающий условия на наличие или отсутствие в пакете установленных TCP-флагов, реализован при помощи детектирующего модуля.

Код препроцессоров вызывается на исполнение после декодирования пакета и перед исполнением детектирующего кода. Через механизм препроцессоров возможна модификация пакетов, например, для повторной сборки TCP-сеанса, для дефрагментации пакетов, нормализации HTTP-запросов, возможен дополнительный анализ вне основного детектирующего кода, возможно также выполнение задач по сбору статистики.

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

Модули могут быть написаны на любом языке, который является способным к созданию пригодного для редактирования объектного кода.

Детектирующие модули

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

Детектирующий модуль должен состоять из двух файлов: sp_something.c и sp_something.h, где префикс "sp_" указывает на то, что это именно детектирующий модуль, а "something" – название модуля, которое, дает разработчик модуля, как правило, отражая его назначение.

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

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

В составе любого детектирующего модуля должны быть как минимум следующие функции:

1. Функция регистрации модуля и связи его с ключевым словом, используемом в правиле для обозначения модуля.

2. Функция конфигурации правила, используемая для выделения памяти под структуры данных и обработки правила.

3. Функция обработки аргументов модуля в правиле.

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

Модули препроцессоров.

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

Препроцессор как и детектирующий модуль состоит из двух файлов: spp_something.c и spp_something.h, где префикс spp_ – указывает на то, что это именно препроцессор, а something – название модуля, которое как правило отражает, что делает данный модуль.

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

В составе любого модуля-препоцессора должны быть как минимум следующие функции:

1. Функция регистрации модуля и связи его с ключевым словом, используемом в директиве подключения модуля.

2. Функция инициализации, используемая для синтаксического анализа аргументов и установки ссылки на основную функцию препроцессора в список.

3. Функция обработки аргументов препроцессора в конфигурационном файле.

4. Функция собственно препроцессора, т.е. функция, выполняющая задачу, для решения которой предназначен препроцессор.

5. Функция завершения работы препроцессора.

6. Функция перезапуска препроцессора.

Модули вывода информации.

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

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

Синица И.Н. `