Sunday, July 23rd, 2017

Подробный анализ незаконного получения доступа к компьютерным данным (часть 4)

Published on Февраль 2, 2009 by   ·   Комментариев нет

Если вы пропустили предыдущие части этой статьи, то, пожалуйста, прочитайте:

В третьей части этой статьи мы увидели, что Snort зафиксировал достаточно неплохо все, что случилось, когда хакер взламывал веб сервер. Но стоит отметить, что он пропустил использование основной программы, которая бы послана туда хакером. Как я уже упоминал в третьей части этой статьи, IDS – это не то устройство, которое гарантирует сетевую безопасность. В основе IDS лежит программа сравнения на соответствие шаблону. Шаблоны – это сигнатуры, которые были для него написаны, и которые постоянно обновляются. В то время, как поставщики IDS делают попытку сформировать широкий набор сигнатур, остается пространство для улучшения.

Существует большое количество вредоносного программного обеспечения, о котором должен знать и беспокоиться каждый специалист по сетевой безопасности. Примером одного из них может служить rootkits, а в случае нашей статьи FU rootkit. Другим примером может служить Трояны и скрытые дыры, как netcat. Проблема заключается в том, что не в каждом IDS есть для них сигнатуры. Это наводит на мысль, что нужно разрабатывать сигнатуры для вредоносного программного обеспечения. На этой ноте мы перейдем к изучению того, как написать сигнатуры для Snort IDS. Как вы скоро увидите, это не так уж сложно сделать.

Написание сигнатур для Snort

Лучший способ выучить что-то – это практика. Также неплохо бы иметь под рукой пример, на котором можно это изучить. Помня об этом, давайте взглянем на сигнатуру Snort ниже, которую я взял из набора правил по умолчанию.


alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN ipEye SYN scan";
flow:stateless; flags:S; seq:1958810375; reference:arachnids,236; classtype:
attempted-recon; sid:622; rev:7;)

Давайте подробнее рассмотрим эту сигнатуру, т.к. она поможет нам построить свою собственную, если сможем разобраться в нюансах. Самое первое поле, т.к. оно просто говорит alert (тревого).


tcp       это относится к используемому протоколу

$EXTERNAL_NET   используется для того, чтобы определить, откуда поступает трафик из внешнего источника:

Internet any      означает применить для всех портов, т.е. не указывается определенный порт

-->       символ направления, указывает, откуда трафик, в этом случае из внешнего источника во внутренний источник

$HOME_NET            используется для идентификации сети человека

(msg:”SCAN ipEye……….) такое сообщение высветится, при обнаружении сигнатуры

flow:stateless используется для обнаружения сигнатуры вне зависимости от состояния

session flags:S используется для указания точных TCP флагов и их комбинаций

seq:1958810375 используется для поиска определенной последовательности TCP sequence number

reference:arachnids,236 используется для идентификации определенной сигнатуры в

базе данных Arachnids IDS database classtype:attempted-recon используется для отметки, что тип класса сигнатуры
принадлежит

sid:622 – значение, используемое для уникальной идентификации сигнатур Snort

rev:7 используется для идентификации номера ревизии для сигнатуры

Обладая этой информацией мы сможем создать свою собственную сигнатуру Snort, а затем протестировать ее, чтобы убедиться в ее стабильности. Неплохо бы разработать сигнатуру для FU rootkit, которая использовалась в предыдущих частях этой статьи. Но с чего начать? Есть ли у нее какие-нибудь отличительные черты? Использует ли она жестко прописанный в коде порт, или обладает уникальным номером TCP последовательности? По существу, все уникально. Но самое уникальное – это ее название fu.exe. Этого уже достаточно, чтобы приступить к созданию нашей сигнатуры Snort.

Давайте создадим свою собственную сигнатуру Snort

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


alert ip any any -> any any (msg:"FU rootkit transfer or usage";
content:”fu.exe”; rev;1)

Выше изображен скелет сигнатуры для FU rootkit. Мы знаем, что двоичный файл fu.exe был передан по TFTP на веб сервер жертвы во время взлома. Это в действительности все, чем мы можем его идентифицировать. В пакете ниже показана ASCII строка fu.exe.


15:06:12.109375 IP (tos 0x0, ttl 128, id 451, offset 0, flags [none],
proto: UDP (17), length: 43) 192.168.111.23.1032 > 192.168.111.17.69:
15 RRQ "fu.exe" octet
0x0000:  4500 002b 01c3 0000 8011 d985 c0a8 6f17  E..+..........o.
0x0010:  c0a8 6f11 0408 0045 0017 c560 0001 6675  ..o....E...`..fu
0x0020:  2e65 7865 006f 6374 6574 0000 0000       .exe.octet....

Я не вставлял сюда external_net или home_net, чтобы максимально упростить пример. Содержимое файла snort.conf может иногда меняться, поэтому иногда лучше все упростить, по крайней мере, пока вы полностью не разберетесь с написанием сигнатур. Вы может также обратить внимание, что нет номеров портов, раздела flow, комбинаций флагов, а также других подобных полей в моей сигнатуре. Хотя в результате этого сигнатура получилась достаточно неточной, она все равно должна быть эффективной. Поэтому содержимое fu.exe должно быть достаточно уникальным, чтобы отсечь все фальшивые совпадения в ASCII содержимом нормальных пакетов. На этом, давайте продолжим, добавим наше правило к остальным и попробуем прогнать двоичный пакет со взломом.


[**] [1:0:1] FU rootkit transfer or usage [**]
[Priority: 0]08/09-15:40:58.171875 192.168.111.23:1029 -> 192.168.111.17:4321
TCP TTL:128 TOS:0x0 ID:665 IpLen:20 DgmLen:742 DF
***AP*** Seq: 0xAA205B6C  Ack: 0x2039E4DD  Win: 0xFA2D  TcpLen: 20

Успех! Наша сигнатура Snort сработала. Теперь, как упоминалось ранее, это достаточно слабая сигнатура с неполным набором других полей, чтобы отсечь фальшивые срабатывания. Вам стоит попытаться добавить другие поля в правиле Snort, и еще поиграть с FU rootkit, а затем изучить результаты. Это позволит вам обнаружить другие отличительные черты. Если вы их найдете, вы сможет добавить их описание в сигнатуру, или написать новую сигнатуру для определения FU rootkit.

Резюме

На протяжении четырех частей этой статьи мы рассмотрели, как хакер может потенциально профилировать вашу сеть. Далее, обладая этой информацией, этот же самые хакер может взломать вашу сеть, а затем развивать свои последующие стратегии по захвату. Общее у всей этой активности заключается в том, что она оставляет следы на пакетном уровне. Эти самые следы можно использовать для построения IDS сигнатур. Не при каждом взломе сети используется хорошо известные инструменты, как Nmap и FU rootkit. Поэтому необходимо постоянно обновлять сигнатуры, которые улавливают типичную активность хакеров.

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

Источник www.windowsecurity.com


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]