 |
|
|
|
STAT — совсем другая IDS
STAT – совсем другая IDS Сегодняшний бизнес тяжело представить без использования Интернет и сетей TCP/IP. Доступ к необходимой информации с любой точки планеты является несомненным удобством, стоит воспользоваться хоть раз, и уже не представляешь свой бизнес без этого. Но вместе с тем это несет и свои проблемы. Сегодня основную нагрузку по защите сетей принимают на себя firewall и приложения уровня домена, предназначенные для подтверждения подлинности пользователей. Несмотря на то что эти приложения в основном справляются со своей задачей, они не могут полностью решить все проблемы по защите сетей и отдельных хостов. И как следствие, на помощь приходят системы обнаружения атак (СОА или Intrusion detection systems – IDS). СОА, анализируя информацию относительно всех контролируемых действий, выполненных в компьютерной системе или сети, производят поиск доказательств злонамеренных действий. Проверяемая информация может принимать форму контрольных записей, произведенных средствами аудита операционной системы, записи в журналах приложений и различными типами датчиков, в том числе и трафик, полученный прослушиванием сетевых интерфейсов. Одни системы, используя заранее составленные описания атак (сигнатуры) и сравнивая, принимают решения о начале атаки. Такие IDS относятся к классу signature/rule-based/misuse и, как правило, не могут обнаруживать новые, еще не занесенные в базу атаки, что делает их бесполезными в начале эпидемий, к тому же они склонны генерировать ложные позитивные предупреждения. Другие, anomaly detection-системы, используют разные методы и алгоритмы, в которых используются и контролируются модели «нормального» поведения системы, основанные на статистических данных или на некоторых правилах, отклонения от которых свидетельствуют о возможных неприятностях. Такие системы, хоть также обладают недостатками, так как требуется некоторое время на их обучение, которое к тому же при некоторых обстоятельствах может быть и не 100% эффективным. Они все же позволяют обнаруживать новые атаки, но также не застрахованы от выдачи ложных тревог, особенно в динамичных средах. Скорее всего, в ближайшем будущем будут использоваться комбинированные системы, сочетающие в себе положительные свойства обеих систем. За примером далеко ходить не надо – Snort (http://www.snort.org) поддерживает проверку аномалий в сети посредством препроцессоров (preprocessors). Препроцессоры проверяют данные пакетов после декодера Snort, но до того как механизм детектирования начинает сравнивать правила, добавляя дополнительные возможности всей системе. Хотя в сильно загруженных сетях их применение может увеличить нагрузку на систему, и к тому же большая их часть находится в концептуальном состоянии, и они могут вызывать большое количество ложных срабатываний, но, надо отметить, возможна тонкая подстройка препроцессоров под конкретные условия. Но, несмотря на наличие препроцессоров, Snort все-таки больше signature IDS, чем anomaly. Совсем другой подход. Проект State Transition Analysis Technique (STAT) использует несколько иной метод обнаружения угроз. Основан этот метод на абстракциях, где вместо конкретных деталей используются обобщенные модели атак, которые затем описываются в возможных сценариях атак. Процесс абстракции от обычной формы (т.е. простых контрольных записей или сетевых пакетов) к представлению более высокого уровня сделан так, чтобы различные действия в системе статистически независимых низкоуровневых факторов были по возможности представлены к единому типу. Кроме того, методология STAT поддерживает такой подход моделирования, который представляет только те действия, которые являются критическими для эффективности атаки в целом. При этом отход от специфики конкретной атаки делает возможным обнаруживать ранее неизвестные варианты атаки или атаки, использующие подобные механизмы, т.е. подход STAT лишен недостатков, присущих signature-based-подходу. Методы, заложенные в сценариях STAT, могут быть применены для создания любого вида датчиков host-based, network-based и application-based, что делает данную технологию универсальной. К примеру, два тогда еще концептуальных датчика NetSTAT и USTAT прошли в конце прошлого века полевые испытания в MIT Lincoln Laboratory и Air Force Research Laboratory (AFRL). В ходе которых заслужили высокую оценку, и, главное, была доказана жизненность предложенных методик обнаружения атак и обнаружена схожесть путей представления сценариев атак и архитектуры различных типов датчиков. Концепции, на которых базируется STAT, принцип работы Основу проекта составляют пять понятий:
Методика анализа смены состояний (STAT) описывает возможные угрозы как некие сценарии. В сценариях атаки представлены как последовательности состояний, которые характеризуют эволюцию состояний защиты системы от начального до скомпрометированного. Описания атак включают в себя как минимум две позиции: запускающее initial-состояние и по крайней мере одно конечное состояние компрометации системы. Так, в сценарии атаки, описывающей попытку нарушить защиту операционной системы, формулируются утверждения вроде монопольного использования файла, идентификации или авторизации пользователя, а в сценарии, описывающем сканирование портов, описываются типичные действия и сегменты TCP, используемые при сканировании портов хоста. Для описания сценариев атаки используется расширяемый язык STATL. Вообще надо отметить, в последнее время заметен интерес к подобным разработкам и появилось множество языков, что полностью оправдывает себя, т.к. появляется возможность выявить общие закономерности, присущие атакам, произвести их классификацию и анализ зависимостей среди различных атак, что позволит опознавать скоординированные и растянутые по времени атаки против компьютерных систем. По крайней мере сейчас известны шесть категорий «attack languages»: языки событий, языки реакции, языки отчетов, языки корреляции, языки эксплоитов и языки детектирования. STATL относится к последней категории, т.е. к языкам детектирования, которые имеют соответствующие механизмы и абстракции, позволяющие описать атаку. Сама же атака в STATL представляется как последовательность состояний и переходов. Состояния характеризуют систему в различные моменты развития атаки. Описывается только необходимое для определения атаки (например, атрибуты файловой системы). Переходы же ассоциируются со специфическими условиями, которые необходимо выполнить для перехода в новое состояние. Например, после обнаружения бинарных данных в запросе веб-сервера ожидается открытие еще одного TCP-соединения или запуск приложения. Возможное развитие событий контролируется фильтрами утверждений перехода, которые определяют более конкретные условия, которым может соответствовать дальнейшее развитие атаки. Например, открытие соединения только со специфическим портом или запуск критических приложений. При этом переходы в зависимости от результата могут приобретать значение consuming, nonconsuming или unwinding. STATL включает несколько встроенных типов: int и u_int, bool, string, timeval (для временных меток) и timer (для отслеживания событий в течение определенного интервала времени ) и также включены массивы. При этом невозможно определить новые типы данных в пределах сценария, специфические типы должны определяться в ориентированной на конкретную задачу библиотеке. Поэтому сетевые и host-датчики кроме встроенных имеют и специфические типы данных. В документации можно найти примеры построения сценария на языке STATL, позволяющие более подробно разобраться с технологией, в данный же момент все имеющиеся сценарии и расширения языка STATL, переписаны в код C++ и откомпилированы в библиотеки STAT development tools, хотя в архивах приложений встречаются ознакомительные сценарии и модули, написанные на языке STATL, позволяющие самому создать необходимое описание события. Для возможности разработки и тестирования собственных сценариев имеются необходимые приложения:
Кроме того, в документе «Translating Snort rules to STATL scenarios» (http://www.cs.ucsb.edu/~rsg/pub/2001_eckmann_RAID01.pdf.gz) обсужден процесс перевода правил Snort в сценарии STATL, но, к сожалению, упоминаемой в нем утилиты snort2statl на сайте обнаружить не удалось. STATL позволяет использовать особенности методики STAT независимо от конкретного приложения и области применения, т.к. может быть легко адаптирован к различным целевым средам и также содержит конструкции, которые могут помочь быстро адаптировать язык к любой специфической области. Например, расширения STATL для описания происходящего на основании записей в логах веб-сервера Apache, имеют поля вроде host, ident, authuser, date, request, status, bytes и пр. После определения возможных событий устанавливаются предикаты, основанные на них. Так, например, isCGIrequest() возвращает истину в том случае, когда событие – запрос на выполнение CGI-скрипта; в случае, когда клиенту возвращается ошибка 400-500, истину принимает предикат isClientError(); а когда в запросе обнаруживаются бинарные строки, что может свидетельствовать о попытке переполнения буфера, истину принимает предикат isBinary(). Все события и определения предиката сгруппированы в расширениях языка, и после того как наборы событий и связанные с ними предикаты для расширений языка определены, их возможно использовать в описаниях сценариев STATL. Дальнейшая работа системы по обнаружению атаки Сценарии STATL обрабатываются во время выполнения ядром STAT. Для этого сценарии компилируются в Scenario Plugin, который является динамически загружаемой библиотекой (.so в UNIX или DLL в Windows). Кроме того, все расширения языка, использованного в сценариях, должны быть откомпилированы в Language Extension Module, который также является динамически загружаемой библиотекой. Само ядро STAT обеспечивает единые для сценариев параметры вроде таймеров, концепций состояния, перехода и соответствия события и фактически производит анализ, сравнивая входящий поток со сценариями, имеющимися в Scenario Plugins. Для расширения возможностей предусмотрено расширение ядра за счет добавления модулей, отвечающих за анализ определенных событий (сетевой трафик, логи приложений и событий, отслеживаемых операционной системой, системные вызовы и пр.), что позволяет собрать IDS практически под конкретные условия. При этом возможно изменение в процессе выполнения загрузкой/выгрузкой STAT-based приложений при помощи директив управления, посланных ядру STAT. Ядро вместе с загруженными модулями и определяет возможности системы. Если же STAT запущен без модулей, он работает в «пустой» конфигурации, т.к. содержит только образ ядра, ожидающего событий или сообщений управления. Источник событий обеспечивается модулем Event Provider, который, собирая данные (т.е. события) из внешней среды (анализ логов, сетевых пакетов), фильтрует те, которые не представляют интерес, преобразовывает остающиеся события в объекты событий (как определено Language Extension Module), преобразовывает эти события в универсальные события STAT и добавляет эти события во входную очередь ядра STAT. При этом Event Providers может быть добавлен и удален динамически, также ядро может работать одновременно с несколькими Event Provider. Для обработки событий необходимо загрузить одно или несколько Scenario Plugins в ядро STAT. Прототипы сценария содержат структуры данных, представляющие в условленных сценарием терминах состояние и изменение глобальных переменных и набор некоторых параметров активации. Прототип создает первый образец сценария. Такой образец находится в начальном состоянии, соответствующем сценарию атаки. Ядро STAT, анализируя определенный сценарий, помечает образец для событий, ассоциированных с начальным состоянием сценария. Теперь ядро готово для обработки события. Если событие соответствует помеченному, то происходит необходимая оценка и утверждение состояний, и в случае удовлетворительного ответа принимается решение о соответствии. При этом, так как могут изменяться последствия, то может создаваться и новый сценарий. Каждый образец сценария фактически представляет описание атаки в прогрессе. В результате работы сценария в конце может быть выдан некоторый выход. Это может быть регистрация, предупреждающее сообщение, перестройка firewall, другим вариантом может быть выдача т.н. синтетического события, которое обрабатывается подобно любому другому событию и может использоваться, чтобы представить изменения цепочки сценария. За ответ на событие отвечает Response Modules, представляющий собой набор функций, способных реализовать любой необходимый тип реакции, в том числе и в зависимости от установок и на промежуточные состояния сценария. Теперь STAT-based приложение полностью сконфигурировано, необходимые модули в зависимости от потребностей могут быть в любой момент загружены/выгружены, все необходимые зависимости осуществляются либо самим приложением, либо инфраструктурой MetaSTAT. Инфраструктура MetaSTAT В защищаемой сети развертывается сеть датчиков, составленная из компонентов, соединенных между собой посредством локальной связи и инфраструктуры управления. Для контроля работы, координации действий, совместимости и управления STAT-based приложениями предназначен набор MetaSTAT, состоящий из:
Выходы датчиков в форме предупреждений собираются т.н. мета-сенсорами, каждый такой мета-сенсор отвечает за подмножество развернутых датчиков и может координировать действия с другими мета-сенсорами (корреляция результатов, например). Компоненты MetaSTAT могут быть организованы в иерархической структуре, для возможности развертывания большого количества датчиков в больших сетях. Инструменты STAT Принципы, заложенные в STAT, были использованы при разработке нескольких компонентов, позволяющих собрать STAT-based IDS под определенные задачи.
Установка и работа Домашняя страница проекта в Интернете находится по адресу http://www.cs.ucsb.edu/~kemm/netstat.html/projects.html, здесь вы найдете документацию и собственно сам софт. Страница для закачки разбита по приложениям, причем если вы хотите установить только LinSTAT (http://www.cs.ucsb.edu/~kemm/netstat.html/software/linstat.html), то на этой странице найдете все необходимые компоненты для удовлетворения зависимостей. Доступны как прекомпилированные rpm-пакеты (для RedHat 7.3), так и исходные тексты. Надо сказать, что в rpm-пакетах можно найти только базовые приложения, да и то, например, модули ядра будут работать только с тем ядром, для которого они компилированы, при использовании в другой системе получите примерно такое сообщение:
Поэтому наиболее общим вариантом будет установка из исходников. Как сказано в документации, для установки достаточно ввести стандартные ./configure, make, make install и все. Но при установке MetaSTAT (с остальными приложениями проблем практически не было) на RedHat 7.3 и 9, SuSE 9.1, Linux XP, Slackware 9.1, проблемы возникали в каждом случае (в RedHat 7.3 и Slackware меньше) поэтому, скорее всего, придется немного повозиться в каждом конкретном случае. Например, такая ошибка преследовала во всех системах.
Но libxml установлен, ищем, где: # find /usr /opt -name parser.h
Исправить ситуацию можно так: # ln -s /usr/include/libxml2/libxml /usr/include/libxml После этого:
Проблема с glib в SuSE решилась таким образом:
# ln -s /usr/lib/libglib-1.2.so.0.0.10 /usr/lib/libglib-1.2.so А еще: # ln -s /opt/gnome/lib/libgnome.so.32.4.3 /opt/gnome/lib/libgnome.so.0 # ln -s /usr/lib/libcrypto.so.0.9.7 /usr/lib/libcrypto.so.2 # ln -s /usr/lib/libssl.so.0.9.7 /usr/lib/libssl.so.2 Смысл, думаю, ясен. Хотя от MetaSTAT можно поначалу отказаться вообще и установить позднее, все компоненты можно использовать отдельно без централизованного управления. А так скачиваем необходимые сенсоры и распаковываем командой tar xzvf название_пакета. После чего в текущем каталоге образуется подкаталог STAT-1.0. При задании команды ./configure без дополнительных параметров будут найдены все распакованные сенсоры, они находятся в STAT-1.0/Sensors/ и можно установить любой из них, просто зайдя в нужный каталог и дав необходимые команды. Либо можно отменить автодетектирование, добавив опцию --disable-autodetect, и затем указать на нужные сенсоры (например, --enable-netstat, --enable-linstat), и нелишней будет опция --enable-java для компиляции Java-компонентов. После компиляции и установки появится каталог /usr/local/stat/, в котором собраны все библиотеки сценариев и основные настройки сенсоров. Большинство файлов не требует вмешательства. Для более точной подстройки некоторых датчиков загляните в подкаталог providers, где в подкаталогах соответствующих датчиков найдете файл provider_config. Например, в файле /usr/local/stat/providers/apache_provider_1.0/provider_config по умолчанию такая запись use_command_line_args, свидетельствующая о том, что параметры берутся с командной строки. А в linuxstat_provider_1.0/provider_config занесены файлы и каталоги, доступ к которым будет контролироваться сенсором LinSTAT. Теперь конкретней о некоторых сенсорах и сопутствующих приложениях. Как уже говорилось выше, LinSTAT является версией утилиты аудита системы SNARE (System iNtrusion Analysis and Reporting Environment) с уже настроенными параметрами контроля. После установки в вашем распоряжении будет динамически загружаемый модуль ядра auditmodule.o и три утилиты auditdaemon, linuxstat и praudit. Модуль, работая в пространстве ядра, отлавливает критические системные вызовы вроде «execve» (выполнение команды), «open» (открыть файл), «mkdir» (создать каталог) и отправляет результат к подпрограмме, которая собирает всю информацию относительно процесса и пользователя, его запустившего, или просто попытавшегося выполнить рассматриваемый системный вызов. Модуль сохраняет информацию во временном буфере, который может быть прочитан при помощи auditdaemon или linuxstat. Эти две программы по сути являются пользовательским интерфейсом к auditmodule.o, считываются данные через устройство /proc/audit. При этом auditdaemon собирает все данные и сохраняет их в бинарном формате в файл (по умолчанию /var/log/snare/audit), для того чтобы просмотреть события, ее можно извлечь при помощи praudit. #auditdaemon -o /var/log/snare/audit-`date -I` #praudit -c /var/log/snare/audit-2004-09-02
Утилита linuxstat работает в двух режимах live и offline. В режиме live информация берется непосредственно с /proc/audit и сразу же анализируется сценариями STAT, в offline анализируется файл, созданный auditdaemon. В live-режиме программу можно запустить так: #linuxstat -name LinSTAT:1.0 -hostname localhost -live А в offline так: #linuxstat -name LinSTAT:1.0 -hostname localhost -offline /var/log/snare/audit-2004-09-02 Для примера пробуем занести новые данные в файл /etc/passwd, в live-режиме система сразу же выдает предупреждающее сообщение.Для запуска при старте системы используется скрипт /etc/init.d/linstat, который берет данные из файла /etc/sysconfig/linuxstat. В этих файлах можно изменить параметры запуска и месторасположение исполняемых и файлов отчетов.
Для запуска при старте системы используется скрипт /etc/init.d/linstat, который берет данные из файла /etc/sysconfig/linuxstat. В этих файлах можно изменить параметры запуска и месторасположение исполняемых и файлов отчетов. # /etc/init.d/linstat start_lin
После чего идут сообщения об активированных сценариях.
Сенсор webSTAT анализирует логи веб-сервера Apache, после установки будет доступна только одна утилита – webstat, которая и принимает в качестве аргумента лог-файл. Работает также в двух режимах offline и live. Первый реализуется опцией [-auditfile | -a]: # webstat -a /var/log/apache2/access_log Второй при помощи опции [-interface | -i]: #webstat -i /var/log/apache2/access_log Теперь для контроля работы набираем в строке браузера: http://server/cgi-bin, после чего система выдает сообщение:
При повторной попытке:
Обратите внимание, что система различает первую и последующие попытки одной и той же атаки. Использование сенсора logSTAT аналогично предыдущему: #logstat -i /var/log/messages -i /var/log/secure либо: #logstat -a /var/log/messages -a /var/log/secure
Датчик NetSTAT также может работать в двух режимах. Если запустить с указанием сетевого интерфейса, то будут контролироваться проходящие через него пакеты: #netstat -i eth0
И как входные данные можно использовать информацию, собранную внешней утилитой, например tcpdump. #netstat -a tcpdump_file Для удобства параметры можно занести в provider_config: interface eth0 или auditfile /audit/file.tcpdump Принцип работы остальных сенсоров STAT аналогичен и, думаю, ясен. К сожалению, STAT только-только выбрался из концептуального состояния и еще не успел обзавестись полноценными средствами сбора и вывода данных, так что их придется создавать самому, а поэтому о массовом использовании разговор пока не идет. Проведенные тестовые испытания подтвердили жизненность методики STAT, были обнаружены не только уже известные атаки, но и тестировались уязвимости обнаруженные, после того как система была установлена, но все равно в отчетах одного из сенсоров появлялось предупреждающее сообщение. В этом проявляется одна из основных достоинств STAT, т.е. работающая IDS фактически не требует никаких обновлений и может эксплуатироваться большой промежуток времени без внимания администратора. Остается надеяться, что наработки не пропадут даром. Успехов. |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
