STAT — совсем другая IDS::Журнал СА 10.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1894
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1936
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1497
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1098
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1667
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 STAT — совсем другая IDS

Архив номеров / 2004 / Выпуск №10 (23) / STAT — совсем другая IDS

Рубрика: Безопасность /  Сетевая безопасность

Сергей Яремчук СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

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, принцип работы

Основу проекта составляют пять понятий:

  • State Transition Analysis Technique – STAT;
  • язык STATL;
  • ядро STAT;
  • инструментальные средства STAT;
  • инфраструктура MetaSTAT.

Методика анализа смены состояний (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, позволяющие самому создать необходимое описание события. Для возможности разработки и тестирования собственных сценариев имеются необходимые приложения:

  • STATL Parser – инструмент, написанный на Java, позволяет переводить сценарии, написанные на STATL, в сценарий C++ плагинов, который затем можно откомпилировать и загрузить в STAT-based приложение.
  • STATed – графический редактор для сценариев STATL, также реализованный на Java.
  • xSTAT – позволяет создать законченное универсальное STAT-based приложение без необходимости следовать за одиночным приложением, а фактически все сенсоры являются символическими ссылками на это имя и любой можно запустить, набрав xstat с соответствующими опциями.

Кроме того, в документе «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, состоящий из:

  • CommSTAT – позволяет создавать защищенные соединения между разнесенными по сети компонентами. Передаваемые данные форматируются согласно стандарту Intrusion Detection Message Exchange Format (IDMEF), предложенному Intrusion Detection Working Group (IDWG) of the Internet Engineering Task Force (http://www.ietf.org/html.charters/idwg-charter.html), который базируется на XML. Оригинальный IDMEF распознает два вида событий: Heartbeat и Alert, который был расширен необходимыми для управления датчиками сообщениями. Для защиты соединения используется SSL.
  • STAT Proxy – действует как посредник между STAT-based приложением и контроллером MetaSTAT, отвечает за поддержку репозитария host-based модулей STAT, для соединения с Controller использует CommSTAT. Также производит предварительную обработку сообщений и директив управления, и поддерживает интеграцию с инструментами сторонних разработчиков, не поддерживающих инфраструктуру STAT.
  • MetaSTAT Controller – сохраняет соединения к имеющимся STAT proxy и обеспечивает интерфейс, позволяющий отсылать управляющие сообщения STAT-based приложениям и контролировать их текущее состояние.
  • MetaSTAT Viewer – пакет включает приложение, написанное на Java и обеспечивающее графический пользовательский интерфейс, позволяющий просматривать предупреждения, сохраненные в централизованной базе данных. В настоящее время Viewer поддерживает просмотр IDMEF версии 0.3.
  • MetaSTAT Configurator – хранит базу данных задействованных модулей и датчиков, а также зависимостей между ними.
  • MetaSTAT Collector – отвечает за сбор и сохранение предупреждений, собранных управляемыми датчиками. Все предупреждения IDMEF можно сохранить во внешней базе данных (MySQL).

Выходы датчиков в форме предупреждений собираются т.н. мета-сенсорами, каждый такой мета-сенсор отвечает за подмножество развернутых датчиков и может координировать действия с другими мета-сенсорами (корреляция результатов, например). Компоненты MetaSTAT могут быть организованы в иерархической структуре, для возможности развертывания большого количества датчиков в больших сетях.

Инструменты STAT

Принципы, заложенные в STAT, были использованы при разработке нескольких компонентов, позволяющих собрать STAT-based IDS под определенные задачи.

  • USTAT – первый появившийся датчик, представляет собой host-based IDS, анализирующую контрольные записи, выданные Sun Solaris Basic Security Module (BSM).
  • NSTAT – расширение USTAT для работы с несколькими узлами, позволяет учитывать атаки на узлы, использующие NFS.
  • WinSTAT – также относится к IDS контролирующим отдельный узел и предназначен для анализа системных логов Windows NT для обнаружения следов возможных атак.
  • LinSTAT – представляет собой демон контроля происходящих событий в Linux-системах, для этих целей используется пакет SNARE, разработанный InterSect Alliance (http://www.intersectalliance.com).
  • NetSTAT – относится к сетевым системам обнаружения атак, анализирует сетевой трафик на предмет наличия пакетов, содержащих угрозу.
  • WebSTAT – application-based IDS, а по сути синтаксический анализатор лог-файлов, сгенерированых веб-сервером Apache, позволяющий обнаружить атаки и злонамеренные запросы.
  • LogSTAT – сенсор, анализирующий журналы формата UNIX syslog, но имеет библиотеку расширения, позволяющую отслеживать критические записи и в журналах Apache.
  • AlertSTAT – хотя и назван в некоторых документах датчиком, но относится к инструменту анализа выводов других датчиков и позволяет обнаруживать атаки более высокого уровня, в том числе и распределенные и многоступенчатые атаки.

Установка и работа

Домашняя страница проекта в Интернете находится по адресу 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-пакетах можно найти только базовые приложения, да и то, например, модули ядра будут работать только с тем ядром, для которого они компилированы, при использовании в другой системе получите примерно такое сообщение:

Starting linuxstat services: insmod: error inserting

"/usr/local/stat/sensors/linuxstat_sensor_1.0/auditmodule.o": -1 Invalid module format 

Поэтому наиболее общим вариантом будет установка из исходников. Как сказано в документации, для установки достаточно ввести стандартные ./configure, make, make install и все. Но при установке MetaSTAT (с остальными приложениями проблем практически не было) на RedHat 7.3 и 9, SuSE 9.1, Linux XP, Slackware 9.1, проблемы возникали в каждом случае (в RedHat 7.3 и Slackware меньше) поэтому, скорее всего, придется немного повозиться в каждом конкретном случае. Например, такая ошибка преследовала во всех системах.

checking for libxml/parser.h... no

The STAT Core needs libxml2 headers installed before it can be compiled (note that a link called

"libxml" and pointing to "libxml2/libxml" is needed)

Но libxml установлен, ищем, где:

# find /usr /opt -name parser.h

/usr/include/libxml2/libxml/parser.h

Исправить ситуацию можно так:

# ln -s /usr/include/libxml2/libxml /usr/include/libxml

После этого:

checking for pthread.h... yes

checking libxml/parser.h usability... yes

checking libxml/parser.h presence... yes

checking for libxml/parser.h... yes

Проблема с glib в SuSE решилась таким образом:

MetaSTAT needs glib installed before it can be compiled

configure: error: /bin/sh "./configure" failed for MetaSTAT

# 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

...

EVENT #26: act: READ, time: Thu Sep  2 17:46:59 2004, retcode: 2, exec_args: gpm, pathname:

/usr/sbin/gpm, uid: 0, gid: 0, euid: 0, egid: 0, pid: 991, ppid: 1, pwd: /, objname: /dev/tty0, owner: 0,

gowner: 0, inode: 36763, dev: 770, perm: rw—w----

...

End of file /var/log/snare/audit (33 events in 4335 bytes: 131.36 bytes/event)

Утилита 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. В этих файлах можно изменить параметры запуска и месторасположение исполняемых и файлов отчетов.

LinSTAT:1.0@09/02/2004 21:32:36: LOG: linux_restricted_write: 500: /etc/passwd written by

user 500, program /bin/bash

LinSTAT:1.0@09/02/2004 21:32:36: LOG:

<IDMEF-Message version="0.3">

<Alert ident="grinder-uUg3vo5" impact="attempted-admin">

<CreateTime ntpstamp="0xC4E1E5C4.0x6AFB1CF5">2004-09-02T18:32:36Z</CreateTime>

<Classification origin="unknown">

<name>restricted_dir_write</name>

<url>http://www.cs.ucsb.edu/~rsg/STAT</url>

</Classification>

<Analyzer analyzerid="LinSTAT:1.0:192.168.1.1">

<Process><name>LinSTAT:1.0</name>

</Process><Node><Address category="ipv4-addr">

<address>192.168.1.1</address>

</Address></Node></Analyzer>

<Source spoofed="unknown">

<User><UserId type="current-user">

<name>sergej</name>

<number>500</number>

</UserId>

<UserId type="current-group">

<name>500</name></UserId></User>

<Process><name>bash</name>

<path>/bin/bash</path>

<pid>22002</pid></Process>

</Source>

<Target><Process><name></name>

<path>/etc/passwd</path></Process></Target>

<AdditionalData type="string" meaning="ustat:target_directory">/etc/</AdditionalData>

<AdditionalData type="string" meaning="ustat:target_file">passwd</AdditionalData>

</Alert>

</IDMEF-Message>

Для запуска при старте системы используется скрипт /etc/init.d/linstat, который берет данные из файла /etc/sysconfig/linuxstat. В этих файлах можно изменить параметры запуска и месторасположение исполняемых и файлов отчетов.

# /etc/init.d/linstat start_lin

Starting linuxstat services: The audit module should be active now.

После чего идут сообщения об активированных сценариях.

LinSTAT:1.0@09/02/2004 15:37:54: LOG: <IDMEF-Message>

  <x-stat from="xstat@localhost" to="stat-controller@ahost.stattest.com">

    <x-stat_info id="1" return_value="0" return_string="OK" scenario_id="2">

    </x-stat_info>

  </x-stat>

</IDMEF-Message>

Сенсор 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, после чего система выдает сообщение:

webstat@localhost@08/26/2004 11:36:18: LOG: apache_regex_xml:

26/Aug/2004:11:36:18 +0300 : First Bad Request "GET /cgi-bin/ HTTP/1.1" :From 192.168.0.1

:Attack: cgi_dir

При повторной попытке:

webstat@localhost@08/26/2004 11:37:34: LOG: apache_regex_xml:

26/Aug/2004:11:37:34 +0300 : Subsequent Bad Request "GET /cgi-bin/ HTTP/1.1" :From

192.168.0.1 :Attack: cgi_dir

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

Использование сенсора logSTAT аналогично предыдущему:

#logstat -i /var/log/messages -i /var/log/secure

либо:

#logstat -a /var/log/messages -a /var/log/secure

[Sun Aug  29 10:01:56 2004] : Facility : kernel:  First Occurance : eth0: setting promiscuous mode.

logstat@localhost@29/08/2004 12:01:57: LOG: syslog_watch:

[Sun Aug  29 11:01:16 2004]: Facility : sshd[7717]:  First Occurance : failed password for root

from 192.168.0.20 port 22 ssh2

[Sun Aug  29 11:01:16 2004]: Facility : server[23101]:  Subsequent Occurance : dispatch_input:

bad request line

"aa~m?~n?~o?~p?%.236u%304$n%.217u%305$n%.6u%306$n%.192u%307$n~p~p~p~p~p~p~

p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p

~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~

p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p

~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~

p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p

~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~

p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p~p1???^g?_~mo^g~mq^l~iq^d~mq^~iq^h

~ia^1?i^q1?a^^pf?@?@y^l^bu^d<^at^m?@^a}???~@~i??0??@?@^cu?i1??hc^g~i[^

h~mk^h~ic^l^k?@1??~@?t/bin/sh"

logstat@localhost@01/09/2004 22:13:04: LOG: syslog_bufferoverflow:

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

#netstat -i eth0

Got UDP port unreachable

192.168.0.1 48361 -> 192.168.0.20 1

Inside tcpprobe, generating Half Open event

attacker: 192.168.0.1, attackerport: 48370, victim: 192.168.0.1, victimport:22

 

from="logging" transition"inactive"  to="end">

        CLASSIFICATION_NAME="tcpsweep"

        CLASSIFICATION_URL="http://www.cs.ucsb.edu/~rsg"

        SOURCE_NODEADDRESS="192.168.0.1"

        SOURCE_PORT="48361"

        TARGET_NODEADDRESS="192.168.0.20"

        ADDITIONAL_DATA="Alert only contains last attacker"

        threshold="3"

        timeout="3"

        victims=""

        victim_address="335587520"

        total_probed="1488"

        addr_probes=""

        t1="1"

 

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

#netstat -a tcpdump_file

Для удобства параметры можно занести в provider_config:

interface eth0

или

auditfile /audit/file.tcpdump

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

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


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru