Snort и ее коммерческие варианты

версия для печати

Роджер Клозе

20.08.2004

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

Когда в начале 80-х гг. по заданию американского правительства началась разработка первых систем обнаружения вторжений в сеть (Network Intrusion Detection System, NIDS), они предназначались для мониторинга сетей и выявления внутренних и внешних атак. В середине того же десятилетия коммерческие компании и организации приступили к созданию собственных NIDS, принялись покупать уже имеющиеся системы и стали бесплатно предоставлять их исходные коды.

Однако слабые тогда еще продукты повторяли некоторые свойства брандмауэров. Со временем это разочаровало не только системных администраторов. Gartner Group также считает приобретение NIDS неоправданным вложением средств, так что даже в мае 2003 г. было заявлено, что они достигли наинизжего уровня ее модели жизненного цикла информационного продукта и впредь использоваться не будут. Однако эту точку зрения разделяют далеко не все специалисты. На конференции 2004 г. по защите информационных технологий Мартин Рош, разработчик Snort, отметил: «Я читал этот отчет, обсуждал его с другими экспертами по безопасности и считаю его ошибочным».

ТЕСТИРОВАНИЕ

Различные журналы и институты, в частности BSI, Neophasis или LANline, занимаются тестированием и сравнением NIDS уже достаточно давно. В этой статье много места отводится сравнению коммерческих NIDS и свободно распространяемой Snort. Первые должны были доказать, чем они лучше бесплатной системы, продемонстрировать, за что же приходится платить, и подтвердить или опровергнуть, оправдывает ли себя их приобретение в принципе.

Поэтому сначала мы рассматривали системы на базе открытых кодов Packetalarm от Varysys и Opensnort от Sourcefire. К сожалению, компания Genua со своей NIDS Genudetect не смогла принять участие в сравнительном тестировании; эту систему предполагается изучить позднее.

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

УСЛОВИЯ ТЕСТИРОВАНИЯ

В тестовую сеть, прежде всего, входила система под управлением Windows или Linux, с которой осуществлялось нападение. Кроме того, в сети находились две уязвимых атакуемых системы с RedHat Linux 7.3 и Windows 2000 Server. Еще одна система, fragrouter, работала в качестве шлюза между атакующими и атакуемыми системами в целях усложнения распознавания атак (см. Рисунок 1).

Для получения реальной пропускной способности в локальной сети были инсталлированы дополнительные элементы: TCP Replay и различные генераторы пакетов данных.

Системы располагались в разделяемой сети, чтобы создаваемый трафик был доступен всем им одновременно. Дополнительно через коммутатор подключался компьютер для проведения спуфинга ARP (см. статью Томаса Демута «Опасности спуфинга ARP» в июньском номере «Журнала сетевых решений/LAN» за текущий год).

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

СЛАБЫЕ МЕСТА, ИНСТРУМЕНТАРИЙ И ОЖИДАНИЯ

Ни на одной целевой системе не были установлены последние заплаты для закрытия «дыр», поэтому и та и другая были очень уязвимы. Они предоставляли важные услуги либо для Internet, либо для корпоративной сети — Internet Information Server (IIS) с базой данных SQL, сервер Web Apache с шифрованием SSL, сервер Samba, сервер Wu-FTP и др. Именно на эти службы проводились атаки при помощи различных технологий и инструментов.

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

К примеру, атакующий посредством введения

‘ union all select @@version,
null, null, null; —

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

В случае сервера Apache SSL атаке подвергалось шифрование SSL посредством переполнения буфера (Bugtraq 5363). Сервер Samba также пытались взломать путем переполнения буфера (Bugtraq DDI-1013). У WuFTP использовалось слабое место в форматной строке (Bugtraq 1387), а DCOM RPC (Bugtraq 8205) заставлял сервер W2K выдать атакующему командную оболочку. Все эти атаки известны уже достаточно давно (см. Таблицу 1).

Таблица 1. Десять наиболее активных событий, происходивших во время теста.

Для того чтобы протестировать системы обнаружения вторжений на распознание новых атак, некоторые из старых способов взлома были несколько модифицированы. Посредством Ettercap проверялась реакция на спуфинг ARP. Помимо этого, использовались дополнительные сканеры — Nmap и Nessus.

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

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

SNORT В ИСХОДНОЙ ВЕРСИИ

В 1998 г. Мартин Рош, недовольный имеющимися на тот момент открытыми и коммерческими решениями, разработал свободно распространяемую систему распознавания атак Snort. Сегодня при более чем миллионе загрузок с сайта http://www.snort.org она представляет собой самую распространенную систему сетевой сигнализации в мире. За прошедшее время вокруг Snort образовалось множество различных проектов. Одним из наиболее известных является опирающаяся на РНР система анализа для баз данных об инцидентах, связанных с проникновениями (Analysis Console for Intrusion Databases, ACID). Она служит для визуализации журналов и поиска в соответствующей базе данных MySQL.

Во время тестирования Snort 2.1.0 инсталлировалась на систему Intel с тактовой частотой 2 ГГц и оперативной памятью 1024 Мбайт, оснащенную RedHat 9.0, MySQL 12.22 (дистрибутив 4.0.17) и прочими необходимыми для Snort программными компонентами. Информацию об инсталляции и конфигурации системы мы взяли с http://www.snort.org/docs/ в Internet.

Хотя системе не доставало интерактивной документации, при успешном распознавании нападения описание атаки можно было найти в Bugtraq, CVS или Anarchnids, а выдаваемого Snort собственного идентификационного номера (SID) в большинстве случаев было достаточно для распознавания события. Для точной идентификации множества правил Snort они подразделяются следующим образом: числа меньше 100 зарезервированы для будущего использования, значения от 100 до 1000000 указывают на правила в дистрибутиве Snort, а все значения свыше миллиона предназначены для локально разработанных правил.

Разработка правил для Snort заслуживает положительную оценку (см. пример правила во врезке «Описание правила Snort»). Новая сигнатура может быть опубликована на сайтах Web, например на http://www.whitehats.org. После чего она через маску ввода может быть интегрирована в работающую систему при помощи дополнительного инструмента Oinkmaster. К сожалению, на момент написания статьи (весна 2004 г.) сайт whitehats.org временно приостановил свою деятельность по экономическим причинам.

При возникновении проблем со Snort мы быстро получали компетентную помощь благодаря публикуемым новостям, форумам и каналам IRC.

Через две недели непрерывных атак выяснилось, что база данных MySQL работает очень медленно. Из-за большого числа протоколируемых событий часто случалось так, что даже простые поисковые запросы выполнялись очень долго. Графическое представление также оставляло желать лучшего: в зависимости от настроек происходило наложение графики, из-за чего она становилась нечитаемой. Однако самым большим недостатком Snort является слишком продолжительная и сложная фаза конфигурации, прежде чем она станет соответствовать заданным правилам и использоваться в рабочей сети.

OPENSNORT

Спрос на коммерческую версию Snort с технической поддержкой побудил Мартина Роша в 2001 г. на базе проекта с открытыми кодами основать предприятие Sourcefire.

В нашем тестировании принимало участие специализированное устройство NS-1000 от Sourcefire. Базовая операционная система Opensnort 3.01 занимала на установочном диске около 120 Мбайт. Она состоит из модифицированной системы Linux RedHat 7.3 с ядром 2.4.21sf.p4-24, базы данных MySQL версии 11.18 (дистрибутив 3.23.54), OpenSSH_3.7.1p2 и OpenSSL 0.9.7c. Система Snort интегрирована в версии 2.1.

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

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

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

Кроме того, Opensnort предлагает кэш DNS, а также интегрированную функцию для балансировки нагрузки, с помощью которой сеть может быть поделена между датчиками (до пяти устройств). Сюда же добавляется безупречная функция отчетности, результаты работы которой, к сожалению, представляются исключительно в формате PDF. Для дальнейшей оценки информации приходится вручную экспортировать данные CSV.

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

PACKETALARM

Компания Varysys Technologies основана в 2001 г., и сегодня в ней работают 23 сотрудника. IDS Packetalarm может поставляться как в аппаратном, так и в программном виде. Сама Varysys аппаратного обеспечения не производит, а уполномоченные дистрибьюторы не смогли предоставить соответствующего устройства для тестирования, поэтому с сайта производителя была загружена демонстрационная версия 3.5 объемом 99 Мбайт.

«Собственный» дистрибутив производителя базируется на несколько сокращенной и модифицированной версии Linux Debian 3.0 с ядром версии 2.4.24 и базе данных MySQL 11.18 (дистрибутив 3.23.53), а также Snort 2.02. Эта система инсталлировалась на самый обычный персональный компьютер, демонстрационная лицензия позволяла воспользоваться исчерпывающей функциональностью продукта. Препятствием может стать лишь совместимость продукта с аппаратными компонентами. После того как инсталляция с сетевыми картами VIA не удалась, через 15 мин ее все же удалось осуществить благодаря применению одного из интерфейсов на базе технологии 3Com.

Сначала в консоли с текстовым интерфейсом, работа с которым выполнялась с помощью курсора и табулятора, задаются базовые данные, чтобы позже администратор мог получать доступ к датчику через HTTPS. После регистрации через интерфейс Web производится конфигурирование с участием мастера, запрашивающего необходимые сетевые данные: DNS, SMTP и NTP. Если эта информация не предоставляется, то настройка не может быть завершена. На компакт-диске наряду с инструкцией по эксплуатации дается подробный обзор NIDS. Он состоит из 183 страниц и написан понятным языком. К сожалению, после инсталляции можно было пользоваться исключительно англоязычной версией интерактивной подсказки, которую приходилось искать по соответствующему пункту содержания.

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

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

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

К сожалению, во время тестовой фазы система (процессор AMD 1,4 ГГц, оперативная память 512 Мбайт, жесткий диск 40 Гбайт) время от времени переставала реагировать на команды из-за перегрузки накопителя и процессора.

СРАВНЕНИЕ КАНДИДАТОВ

Все три системы работают по одному принципу и используют приблизительно одни и те же 2000 правил, поэтому распознавание атак в сетях происходило практически одинаково. Однако Packetalarm вводит иное, чем у Snort и Opensnort, разбиение событий на группы. Это усложнило сравнение в процессе анализа атак.

При имитации с помощью Snot и Mucus были распознаны все сгенерированные атаки. Кроме того, системы показали практически одинаковое количество атак, когда те осуществлялись посредством сканера Nessus. Однако все изменилось во время частных тестов. Как видно по выдержкам из таблицы нападений (см. Таблицу 2), Packetalarm в случае атак WuFTP и DCOM RPC не смогла распознать эти события. Атака на сервер Samba посредством стандартного эксплоита не была замечена ни одной из систем. Это странно, поскольку уже достаточно давно существует правило именно для нее (попытка переполнения буфера NETBIOS SMB trans2open). Модифицированную атаку на код оболочки x86-NOOP смогла распознать только Packetalarm. После деблокировки Samba все кандидаты распознали запрос.

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

Методы инжекции SQL, с помощью которых хакеры через серверы Web могут получать информацию или — в зависимости от базы данных — даже номера кредитных карт, остались необнаруженными. Причина, по всей видимости, заключается в том, что ни одна из протестированных IDS не может различать законные и незаконные запросы. Для распознавания и ликвидации подобных слабых мест необходимы новые технологии, появления которых еще нужно дождаться. Администраторам, как и прежде, многое придется делать вручную.

Спуфинг ARP посредством Ettercap также не распознала ни одна из систем, хотя Snort обладает специальным препроцессором, который был соответствующим образом сконфигурирован (arpspoof). Для этого все IP- и МАС-адреса вручную записывались в Snort.conf. В Opensnort и Packetalarm препроцессор отсутствует; вероятно, пока он рассматривается как «экспериментальный» (экспериментальное обнаружение ARP).

Большим преимуществом Packetalarm и Opensnort по сравнению со свободно распространяемой системой Snort является специальная оптимизация. Так, к примеру, в них использовалось модифицированное ядро операционной системы — оно работает очень быстро совместно с оптимизированной базой данных MySQL. Создание правил, а также управление ими и пользователями были проще и нагляднее, чем у Snort. Множество настроек, которые в коммерческих NIDS проводятся быстро и просто через интерфейс Web, у Snort возможны только через командную строку.

После заполнения баз данных событий более чем миллионом записей выяснилось, что проблемы с поиском возникают не только у Snort. Удаление всех сохраненных событий происходило очень медленно и должно было быть повторено несколько раз, пока все внесенные данные действительно не исчезнут. В Packetalarm дополнительно указали на то, что процесс удаления мог бы длиться и дольше, что соответствовало действительности. Лучшей оказалась Opensnort — эта система удалила все записи быстрее конкурентов. К тому же Opensnort предлагает возможность изначального ограничения объема базы данных о событиях. Систему обнаружения вторжений, не обладающую такой функцией, взломщик смог бы намеренно сделать недееспособной.

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

Sourcefire и Snort обладают максимальной свободой конфигурации, поскольку они, в отличие от Packetalarm, предоставляют полный доступ к операционной системе по мере надобности.

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

Подробная таблица сравнения с оценкой будет дана по окончании серии тестов и включит все полученные впечатления.

ЗАКЛЮЧЕНИЕ

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

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

К сожалению, именно в плане распознавания атак коммерческие системы оказались неубедительными. В соответствии со своими правилами они ищут в атаке конкретные шаблоны, которые в большинстве случаев применяются только для доказательства правильности концепции, но редко используются в случае реального взлома. Во второй части серии мы рассмотрим NIDS именитых производителей. Однако эти системы не базируются на Snort — они являются продуктами с закрытыми исходными кодами и полностью разработаны в лабораториях их производителей. Посмотрим, будут ли «собственные разработки» лучше или хуже эталонной системы.

Роджер Клозе — эксперт в области информационной безопасности. С ним можно связаться по адресу: wj@lanline.awi.de.

Описание правила Snort

alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg: «IMAP EXPOIT x86 linux overflow»; flow: to_server,established; content: «l89d8 40cd 80e8 c8ffffffl/»; reference:bugtraq, 130; reference:cve, CVE-1999-0005; classtype:attempted-admin; sid:295; rev:5;)

Это правило Snort выдает сигнал тревоги, когда по TCP с любого IP-адреса с любым портом производится доступ к домашней сети и порту 143. Кроме того, флаг подтверждения приема должен быть установлен, поскольку соединение ТСР уже организовано, а в полезной нагрузке должно содержаться \x89\xd8\x40\xcd\x80\xe8\xc8\xff\xff\xff от кода оболочки атаки. Для получения дальнейшей информации об атаке дается ссылка на идентификатор Bugtraq 130, CVE 1999-0005 и идентификатор Snort 295. В менеджере событий тревога указывается в виде IMAP Exploit x86 linux overflow и относится к группе attempted-admin.

© AWi Verlag