Обзор системы обнаружения вторжений Snort
Воскресенье, 03 мая 2009 13:32

Обзор системы обнаружения вторжений Snort

Оцените материал
(0 голосов)

snort idsКак бы хорошо ни был защищен web-сервер или шлюз в интернет, всегда существует возможность его взлома. И для системного администратора было бы лучше узнавать о попытках взлома еще до того, как взлом произошел. Поэтому особенно важны средства, позволяющие не только обнаружить факт проникновения в систему, но и предупредить о предстоящем вторжении.Существует два вида систем обнаружения вторжения: к первым относятся программы, выявляющие аномалии в функционировании системы, например, необычно большое количество одновременно работающих процессов, повышенный трафик, передаваемый интерфейсами системы, и т. п.; ко вторым относят IDS, работа которых заключается в поиске заранее известных признаков атаки. Что же касается великолепной программы Snort, то её можно смело отнести к обоим видам IDS.

 

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

Эта статья не претендует на всеобъемлющее руководство по Snort, а лишь является моим очень вольным переводом руководства, написанного Martin Roesch (автором программы), вперемешку с моими собственными мыслями.

Исчерпывающую информацию о том, чем является Snort и как его использовать, можно найти по адресу http://www.snort.org.

Что же такое Snort? Snort - это сетевая IDS, способная выполнять в режиме реального времени анализ трафика, передаваемого по контролируемому интерфейсу, с целью обнаружения попыток взлома или попыток поиска уязвимостей (таких, как переполнение буфера, сканирование портов, CGI-атаки, идентификация операционной системы, идентификация версий используемых сетевых сервисов и др.). Гибкость и удобство Snort основываются на трех столпах:

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

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

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

ACTION PROTO IP_ADDR1 PORT1 DIRECTION IP_ADDR2 PORT2 [ (OPTIONS) ]

ACTION

Имеются три основных директивы, определяющие дальнейшие действия при обнаружении сетевого пакета, соответствующего некоторому правилу: pass, log и alert.

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

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

ruletype redalert
{

type alert
output alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql, user=snort dbname= snort host= localhost

}

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

PROTO

В настоящее время для анализа доступны три протокола, и, соответственно, допустимы три значения этого параметра - tcp,udp,icmp. В будущем, возможно, появится поддержка ARP, IPX, IGRP, GRE, RIP, OSPF и других.

IP_ADDR

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].

PORT

Задание номеров портов осуществляется точно также, как и в Linux-утилите ipchains. То есть кроме единственного номера порта можно задать диапазон портов через двоеточие, например, 6000:6010 - порты с 6000 по 6010 включительно, :1024 - порты с 1 по 1024, 1024: - порты с 1024 по 65536. Как и в случае IP-адресов, символ ! инвертирует условие, а ключевое слово any обозначает все порты.

DIRECTION

Этот оператор позволяет определить направление движения пакета:

-> (одностороннее) - правило будет применяться только к пакетам, идущим с IP_ADDR1 на IP_ADDR2;

<> (двустороннее) - направление движения пакета роли не играет.

OPTIONS

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

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

Параметры, задающие дополнительные условия на соответствие правилу:

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

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

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

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

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

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

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

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

ack - задает значение поля подтверждения в TCP-пакете;

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

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

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

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

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

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

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

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

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

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

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

Параметры, значения которых имеют смысл при соответствии анализируемого пакета всем условиям:

msg - содержит текст сообщения;

logto - задает альтернативный файл для записи в него содержимого пакета;

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

resp - если пакет соответствует правилу, то Snort выполнит одно из указанных

действий - например, закроет соединение, отправив TCP-RST-пакет одному из хостов.

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

Ниже приводятся некоторые примеры определения правил.

log tcp any any -> 192.168.1.0/24 6000:6010

Согласно этому правилу все пакеты, адресованные на обычно используемые системой X Window порты хостов некоторой подсети, будут записываться в лог.

alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 any (msg:"IDS004 - SCAN-NULL Scan";flags:0; seq:0; ack:0;)

Такое правило обнаруживает попытку так называемого NULL-сканирования портов.

alert tcp !192.168.1.45/32 any -> 192.168.1.45/32 80 (msg:"IIS-_vti_inf";flags:PA; content:"_vti_inf.html"; nocase;)

Адресованные web-серверу пакеты, содержащие в себе запрос к файлу _vti_inf.html, рассматриваются как попытка воспользоваться одной из уязвимостей Internet Information Server, что вызовет при обнаружении таких пакетов генерацию сообщения об этом событии, а сам пакет запишется в лог-файл.

alert tcp any any <> any 6688 (msg:"Napster Client Data"; flags:PA; content:".mp3"; nocase; resp: rst_all)

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

alert tcp any 80 <> 192.168.1.0/24 any (content-list: "adults.txt"; msg: "Not for children!"; react: block, msg;)

Этим правилом блокируется доступ на web-сайты, адреса которых перечислены в файле adults.txt. При обнаружении запроса к нежелательному серверу соединение с ним закрывается, генерируется сообщение «Not for children!», которое кроме записи в лог отправляется и браузеру. Таким образом, Snort может выполнять функции web-фильтра.

activate tcp !192.168.1.0/24 any -> 192.168.1.0/24 143 (flags: PA; content: "|E8C0FFFFFF|\bin|"; activates: 1; msg: "IMAP buffer overflow!";) dynamic tcp !192.168.1.0/24 any -> 192.168.1.0/24 143 (activated_by: 1; count: 50;)

Директива activate ничем не отличается от alert за исключением того, что в разделе опций правила activate всегда присутствует опция activates, предназначенная для вызова на исполнение другого правила. Вызвать можно только правило dynamic. Директива dynamic в свою очередь ничем не отличается от директивы log. Она также предназначена для записи пакетов в лог, но имеет при этом два дополнительных параметра: activated_by, которая ассоциирует правило dynamic с правилами activate, а также count, которая указывает для какого количества пакетов должно отработать правило, то есть сколько пакетов, следующих за перехваченным пакетом должны быть записаны в лог. Приведенное выше правило activate анализирует пакеты на предмет попытки реализации атаки на переполнение буфера и в случае обнаружения таковой вызывает правило dynamic для записи в лог-файл следующих 50 пакетов. Если атака была успешной, то, анализируя впоследствии файл, можно установить, какой именно урон был нанесен.

log tcp any any <> 192.168.1.0/24 23 (session: printable;)

Такое правило особенно полезно, когда требуется сохранить в лог-файл в читаемом виде все, что вводит или видит пользователь в течение telnet-, ftp-, rlogin-, или даже web-сессии.

На сайте 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'a очень широка. Чтобы не ждать обновления набора правил на сайте после публикации нового очень опасного эксплойта, можно очень быстро составить правило самостоятельно. Для этого достаточно найти в интернете новый эксплойт, применить его против подопытного хоста-жертвы, записывая в лог при этом весь трафик между атакующим хостом и хостом-жертвой. Анализируя затем лог, необходимо найти уникальную сигнатуру эксплойта. Например, в следующем пакете

052499-22:27:58.403313 192.168.1.4:1034 -> 192.168.1.3:143 TCP TTL:64 TOS:0x0 DF ***PA* Seq: 0x5295B44E Ack: 0x1B4F8970 Win: 0x7D78 90 90 90 90 90 90 90 90 90 90 90 90 90 90 EB 3B ...............;

5E 89 76 08 31 ED 31 C9 31 C0 88 6E 07 89 6E 0C ^.v.1.1.1..n..n.

B0 0B 89 F3 8D 6E 08 89 E9 8D 6E 0C 89 EA CD 80 .....n....n.....

31 DB 89 D8 40 CD 80 90 90 90 90 90 90 90 90 90 1...@ ...........

90 90 90 90 90 90 90 90 90 90 90 E8 C0 FF FF FF ................

2F 62 69 6E 2F 73 68 90 90 90 90 90 90 90 90 90 /bin/sh.........

строчка /bin/sh явно выглядит подозрительно. Таким образом эта строчка и несколько предшествующих ей байт и будут представлять собой сигнатуру эксплойта. Новое правило для Snort будет выглядеть примерно так:

alert tcp any any -> 192.168.1.0/24 143 (content:"|E8C0 FFFF FF|/bin/sh"; msg:"New IMAP Buffer Overflow detected!";)

Теперь рассмотрим возможности по расширению Snort.

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

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

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

В частности, процедура определения сканирования портов реализована именно при помощи препроцессора. Под «сканированием портов» этот препроцессор понимает отправку с одного и того же IP-адреса SYN-, FIN-, NULL-, SYNFIN- или XMAS-пакетов контролируемым хостам более, чем на P портов, за время меньше T, или на один порт сразу нескольким хостам. Следующие версии Snort будут также обнаруживать распределенное сканирование портов, когда пакеты на сканируемые хосты посылаются от нескольких атакующих хостов. Польза от применения этого препроцессора заключается в том, что при обнаружении атаки нет необходимости генерировать уведомление об атаке для каждого пакета, а можно сделать это для всей атаки в целом.

Очень интересным модулем является SPADE-препроцессор фирмы Silicon Defence. SPADE расшифровывается как Statistical Packet Anomaly Detection Engine - код для обнаружения статистически аномальных пакетов. SPADE - это часть проекта SPICE (Stealthy Portscan and Intrusion Correlation Engine), полную информацию о котором можно найти по адресу http://www.silicondefense.com/pptntext/spice-ccs2000.pdf .

 Spade просматривает трафик, находит пакеты, которые согласно некоторым статистически критериям принимаются за аномальные, и передаёт информацию о них процедуре журналирования для записи в лог. Выделение аномальных пакетов происходит примерно следующим образом: каждому пакету присваивается оценка его аномальности, основанная на истории просмотренного трафика. Для этого создается таблица с оценками вероятностей появления различных видов пакетов, основанная на частоте их появления за некоторый период и времени появления (более свежим пакетам присваивается больший вес). Так, например, для web-сервера

P(dip=198.168.1.1,dport=80)= 0.3и
P(dip=198.168.1.1,dport=12543) =0.001.

Оценка аномальности рассчитывается непосредственно из вероятности появления пакета:

A(X)= -log 2(P(X)).

Таким образом аномальность пакета на 80 порт хоста 198.168.1.1 выразится
числом 1.737, а аномальность пакета на порт 12543 того же хоста - числом 9.97.

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

Начиная с версии 1.7 озможно использовать для вывода информации одновременно несколько подключаемых модулей:

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

alert_fast - выводит в указанный файл информацию о возможной атаке в однострочном укороченном формате.

alert_full - то же самое, что и alert_fast, но в указанный файл записывается и сам перехваченный пакет. Пожалуй, лучше всего получающийся таким образом файл просматривать, обработав его для начала perl-сценарием SnortSnarf от уже упоминавшейся фирмы Silicone Defense. Результатом работы сценария является очень подробный и удобный в использовании отчет, пример которого можно найти по адресу http://www.silicondefense.com/snortsnarf/example

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

alert_smb - посылает сообщение об атаке по протоколу WinPopup на указанные NETBIOS-хосты.

log_tcpdump - записывает в файл перехваченные пакеты в формате утилиты tcpdump.

database - очень интересный модуль, позволяющий сохранять всё информацию о перехваченных пакетах в базу данных. В настоящее время поддерживаются базы данных PostgreSQL, MySQL, Oracle, а также ODBC-совместимые базы данных. На основе информации, сохраненной в базе данных очень удобно формировать различные отчеты о, например, наиболее навязчивых атакующих хостах, типичных атаках, наиболее вероятном времени проведения атаки и т. п.

XML - этот модуль был разработан в координационном центре CERT как часть проекта AIRCERT. Основная его цель - создание целой инфраструктуры по обнаружению вторжений внутри локальной сети, где запущенные на нескольких компьютерах экземпляры Snort'a выполняют роль сенсоров. Полную информацию об этом модуле можно найти по адресу http://www.cert.org/kb/snortxm

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

Прочитано 7086 раз Последнее изменение Среда, 07 января 2015 16:20