Анализ IDS


IDS обеспечивает три источника информации. Первый источник - сами предупреждения IDS, когда обнаруживается какая-то подозрительная деятельность. Второй источник информации - записи пакетов. Эти подробные сведения хранятся в двоичном файле и после совершения нападения используются для детального анализа. Третий источник информации - журналы сеансов ASCII, где Snort IDS хранит все данные ASCII, обнаруженные в потоке пакетов, например комбинации клавиш. Давайте продолжим анализ сканирования RPC, которое обнаружил наш брандмауэр, и посмотрим, какую информацию может предоставить система IDS.
IDS для Honeynet настроена таким образом, чтобы создавать предупреждение всякий раз, когда она обнаруживает подозрительные действия. Эти предупреждения через syslogd хранятся в файле регистрации, который затем просматривает Swatch, инструмент анализа журналов регистрации,

отлично подходящий для автоматизации. Затем Swatch переправляет сообщения по электронной почте администратору. Эти созданные IDS предупреждения являются дополнительным уровнем, так как брандмауэр уже настроен на то, чтобы предупреждать нас о любых действиях в сети. Однако у IDS есть дополнительное преимущество определения конкретного действия при помощи функций сравнения сигнатур, например: она может обнаружить нападение путем переполнения буфера или атаку на Web-сервер IIS. Эта возможность в режиме реального времени оповещает команду о том, что попытаются предпринять «плохие парни». После того как нападение будет обнаружено, мы будем знать, на что обращать особое внимание. В приведенном ниже примере рассматривается взлом операционной системы Linux. Система IDS обнаруживает запрос списка портов RPC, в то время как нападающий пытается выяснить, какие RPC-сервисы может запустить наша машина. После первоначального запроса списка портов IDS обнаруживает нападение с целью переполнения буфера. Эти предупреждения Snort не только извещают нас о том, что происходит нападение, но также предоставляют информацию, необходимую для более подробного анализа бинарных регистрационных файлов IDS.
Это предупреждение Snort указывает на то, что система 10.1.1.1 попыталась послать RPC-запрос нашей системе honeypot 172.16.1.104. Взломщик из удаленной системы, скорее всего, является привилегированным пользователем, так как номер исходного порта меньше 1023 - в данном случае порт 709. Сразу после этого запроса последовали два нападения со взломом, наверняка это был один и тот же взлом, так как действия были направлены на одни и тот же порт honeypot - 931. То есть порт 931 был динамически привязан к rpc.statd, RPC-сервису с существенными недостатками в плане обеспечения безопасности. В это время нам еще не известно, насколько успешно прошло нападение. Затем эти предупреждения Snort, хранящиеся в регистрационном файле /var/log/messages, переправляются по электронной почте администратору в режиме реального времени.
Обратите внимание на то, что у сигнатуры также есть номер-определитель, IDS362, который можно использовать, чтобы получить подробную информацию об этом нападении. Один из участников нашего проекта, Макс Вижн, создал базу данных, где подробно описывается более 400 сигнатур, которые может определить Snort. Такой анализ сигнатур дает подробное представление о том, на что похожа атака, что она означает, как обнаруживается сигнатура, и огромное количество другой важной ин-формации. Команда Honeynet регулярно пользуется этой открытой для общего пользования базой данных IDS-сигнатур. Сведения об этом раз-мещены по адресу: http://vywvxsnofrt.org. Там мы нашли следующий отчет об этом виде зондирования, IDS363.
Была обнаружена последовательность знаков 0x90. В зависимости от контекста это обычно указывает на команду NOP (команда в процессорах фирмы Intel, обозначающая отсутствие каких-либо действий), выраженную в машинном коде процессоров семейства х8б. При многих нападениях путем переполнения буфера высылается серия байтов NOP (no-operation), чтобы увеличить шансы успешного взлома. Эта атака обычно называется «NOP sled».
Сразу же после нападения мы получаем очередное предупреждение брандмауэра, указывающее на то, что взломщик из удаленной системы blackhat. example.com установил соединение с нашей honeypot через порт 39168.
Это предупреждение извещает нас о том, что взломщик из удаленной системы только что попытался установить соединение с нашей honeypot через порт с номером 1023, сразу же после совершения нападения. У порта 39168 нет ни одного привязанного к нему сервиса, так что все это очень подозрительно. Кроме того, наша система IDS Snort не предупредила об этом соединении. Скорее всего, получилось так, что нападение путем переполнения буфера RPC создало временную командную оболочку, и теперь взломщик подсоединился к ней. Мы можем предположить, что, установив для соединения с приемником черный ход, нападающий получит доступ к honeypot через командную строку. Это простое соединение - вероятнее всего, TELNET или соединение netcat - IDS не заметила, так как оно не соответствует ни одной заданной сигнатуре; это простое TCP-соединение одного порта машины нападающего с одним портом honeypot. Однако брандмауэр предупредил нас об этих действиях, так как любой входящий и исходящий из Honeynet трафик подозрителен. Это доказывает ценность системных журналов брандмауэра. Система предупреждения IDS не смогла обнаружить соединение; однако брандмауэр его зарегистрировал, так как само соединение уже подозрительно, несмотря на то что не соответствует ни одной из сигнатур IDS. Это указывает на важность многоуровневой записи информации. Давайте посмотрим, подтвердится ли наша гипотеза.
Snort также записала эти соединения в бинарный регистрационный файл, в том числе и полезную нагрузку пакетов. Теперь мы можем извлечь подробную информацию о нападении, просмотрев бинарные файлы регистрации. Эти подробности помогут нам, например, раскрыть вид нового нападения, которое не соответствует сигнатурам IDS, получить определенную информацию об IP или заголовках протоколов UDP/TCP, записи «дактилоскопии» (см. главу 7) или разнообразные другие данные. На основании нашего опыта можно сказать, что записанные в бинарный регистрационный файл входящие и исходящие из Honeynet пакеты оказались самым ценным источником информации. В случае с нашим RPC-нападением можно взглянуть на то, как происходил взлом системы. Просмотрев все пакеты, составляющие соединение, мы также сможем установить, было ли соединение с портом 39168 нелегальным.
Во-первых, мы запрашиваем в регистрационном бинарном файле Snort данные обо всех действиях, связанных с портом 39168, который, по нашему мнению, был использован для установления нелегального соединения. Основная цель взлома, скорее всего, состояла в том, чтобы создать оболочку, выполняющую команды этого порта. Пакет был зарегистрирован 9 декабря в 07:17:22.
1. Пакет был послан из системы 10.1.1.1 с порта 2646 на нашу honeypot, порт 39168.
2. Это пакет TCP; Time to Live (время жизни) - 49 пересылок; Type of Service (тип сервиса), 0; Packet ID 50108; длина IP-заголовка 20 байт; общий объем пакета 1500 байт; установлен бит Don't Fragment (не фрагментировать).
3. Установлены биты кодов Push и Ack: Sequemce number 0x6B9CD06A; Acknowledge number 0x4D5819B6: размер окна 0x7D78; объем TCP заголовка 32 байта.
Ниже приводится информация заголовка пакета. Система Snort также позволяет посмотреть переданную полезную нагрузку пакета в двух разных форматах. Первый формат представлен в шестнадцатеричной форме - это столбец двухзначных чисел слева. Второй формат - это перевод шестнадцатеричной системы в ASCII (правый столбец).
Преобразованный код ASCII показывает команды, которые будут выполнены на нашей honeypot. Предположение оказалось верным: соединение с портом 39168 - это соединение с временным запасным ходом, через который загружаются команды, использованные взломщиком для изменения конфигурации нашей системы. Запасной ход в данном случае - это оболочка, выполняющая команды, присылаемые через этот порт с правами root (у пользователя тот же UID, что и у сервиса rpc.statd).
Третий уровень информации, который может предоставить Snort, - комбинации клавиш. Snort делает это путем сбора всей информации ASCII и сохранения текста ASCII в однородном текстовом файле. Эти сведения могут иметь жизненное значение, так как они шаг за шагом описывают -действия взломщика. Однако это эффективно, только когда информация передается открытым текстом. Snort может записывать зашифрованный трафик, однако он не представляет никакой ценности, так как данные невозможно разобрать без соответствующих секретных ключей для расшифровки. В случае с атакой, использовавшей rpcstatd, мы записали действия, выполненные в оболочке, привязанной к порту 39168, поскольку они были переданы открытым текстом. Мы можем видеть, как при помощи временного запасного хода, подчиняющегося порту 39168, взломщик создает постоянный запасной ход. Это те же самые данные, которые мы видели в пакете, но Snort взяла все данные ASCII и конвертировала их в гораздо более удобный для чтения формат.
Приведенный ниже код - это регистрационный файл, SESSION:39618-1646, созданный в Snort. Поле SESSION указывает на то, что это файл врезки сеанса связи. Номер 39618-1646 - исходный порт и порт назначения, между которыми устанавливалось соединение.
В данном случае взломщик создает две учетных записи, user и sendmail, добавляя соответствующие записи в файлы /etc/passwd и /etc/shadow на машине-«жертве». Затем он создает постоянный запасной выход, привязанный к порту 16000, изменяя конфигурацию inetd так, чтобы всякий раз при соединении через порт 16000 запускалась командная оболочка. После редактирования inetd. conf атакующий посылает программе inetd сигнал HUP, чтобы она перечитала файл конфигурации.

Такой анализ выполняется и для систем на основе Windows NT. Например, далее приводится образец кода из нападения на NT. В этом нападении мы рассматриваем данные, аналогичные нападению на Linux rpc.statd; в нашем случае, однако, honeypot - это Web-сервер IIS (Internet Infotmation Server), работающий под управлением NT и подвергшийся unicode-на-падению, еще одному весьма распространенному виду взлома. Сначала Snort предупреждает нас о подозрительных действиях: unicode-нападе-нии в сочетании с прослеживанием информации о структуре директории. Эти предупреждения были созданы в Snort, переправлены для архивации на сервер syslogd и по электронной почте администратору в режиме реального времени, точно так же, как и в случае с нападением на rpc.statd. Ниже приводятся два предупреждения, сгенерированные во время атаки. Как и в случае с операционной системой Linux, это один из первых показателей того, что совершается нападение.
Обратите внимание, что во втором предупреждении мы опять встречаемся с номером IDS, определяющим этот вид предупреждения, в данном случае IDS297.
База данных Макса Вижна по адресу http://vjwvxsnort.org дает нам следующую информацию. Оказывается, что это нападение является попыткой разбить древовидную структуру Web-каталогов.
Многие Web-серверы и CGI-сценарии уязвимы перед нападениями через прослеживание каталогов. Во ряде случаев Web-приложение может позволять доступ к определенной части файловой системы. При отсутствии соответствующей проверки вводимых пользователем данных сервер зачастую может добавить в путь директории «..», что разрешает доступ к вышестоящим каталогам. В результате можно подняться до корневого каталога и получить доступ ко всей файловой системе.
На основании предупреждений системы Snort становится понятно, что нужно искать в бинарных регистрационных файлах Snort. Помните, она захватила и записала все пакеты этого нападения. Для того чтобы провести анализ данных, мы можем подробно рассмотреть каждый пакет. Предыдущее предупреждение указывает на то, что нападение произведено из системы 10.1.1.1, исходный порт 2310. Если поискать именно этот пакет в бинарном регистрационном файле, можно получить следующую информацию. Перед нами атака с использованием Unicode, осуществленная путем создания специального HTTP-запроса.
Взломщик воспользовался уязвимым местом Web-сервера IIS и заставил honeypot выполнить команду: листинг директории \Inetpub. При unicode-нападении используется ошибка сервера IIS в функции проверки определенной кодировки символов.
Таким образом, мы узнали, что одна из наших honeypot была взломана группой румынских хакеров. Затем они использовали honeypot как центральный пункт для обмена информацией, и мы записали все чаты, в которых они общались. Один из лидеров записал себя на видеокамеру и затем переслал изображение на Web-сайт в режиме реального времени. На кадрах был не только он, но и экран компьютера. Он хотел, чтобы товарищи увидели его в режиме реального времени, однако не предполагал, что создатели проекта Honeynet смогут заглянуть через его (виртуальное) плечо и записать URL. Это был один из первых случаев, когда мы владели визуальной информацией об одном из взломщиков. В главе 11 очень подробно рассказывается о том, какую ценность могут представлять перехваченные разговоры IRC.
Макс Вижн разработал инструментарий, который быстро и эффективно выделяет из IRC важную для анализа информацию. Этот инструмент, privmsg.pl, берет необработанный двоичный системный журнал, выделяет сеансы IRC, а затем преобразует данные так, чтобы отображались только разговоры. Результат может быть представлен в текстовом формате ASCII или в HTML с цветовым выделением. Этот инструмент оказал проекту Honeynet неоценимую услугу, так как позволил быстро получать важные сведения от взломщиков, пользующихся IRC.
В файле ire.html будут содержаться разговоры IRC, выделенные из бинарного регистрационного файла Snort.
Мы только что проанализировали два нападения на основании данных, которые собрала выбранная нами система IDS Snort, и обнаружили, что Snort представляет собой один из самых мощных инструментов сбора данных. Три основные области его использования - предупреждение, анализ пакетов и захват открытого текста. В совокупности эти данные могут содержать подробную информацию о действиях взломщиков.