В последней части этой серии статей мы рассмотрим сообщения безопасности, сгенерированные мной. В этом двоичном журнале будут несколько атак и немного обычного серфинга. А теперь посмотрим и отделим солому от пшеницы.
Если вы хотите увидеть другие статьи из этого цикла, пожалуйста, прочитайте:
Пакетный анализ 101
На протяжении последних трех статей мы рассматривали способы настройки своей собственной системы обнаружения вторжений и лабораторию анализа. В данной заключительной части мы увидим, как с помощью этих очень похожих инструментов провести некоторый анализ. На самом деле, по разным причинам, найдется не много людей, проводящих пакетный анализ. Множество людей просто не знакомо с TCP/IP на пакетном уровне, к тому же найдется не так много работ, в которых это требуется. Если вы следили за серией данных статей, то сможете уменьшить количество этих причин и развить свои навыки.
Довольно часто системным администраторам дополнительно поручается задача обеспечения информационной безопасности в сети. Быть системным администратором – это и так довольно тяжелая работа, а тут еще до кучи добавляется задача обеспечения безопасности. Изучение TCP/IP может быть пугающим, но оно во многом оправдано. Как никак, TCP/IP – это абсолютная основа, на которой построены связи между компьютерами. Полезно иметь очень хорошую хватку, чтобы понять это. Существует много отличных инструментов, которые упростят для вас TCP/IP, но на самом деле не помогут вам в понимании его теории.
Вперед!
Ну что ж, хватит болтовни на сегодня, давайте перейдем к сущности предмета. Для начала, скачайте, пожалуйста, созданный мною файл двоичного журнала. Это позволит вам вводить в точности такие же команды, которыми пользуюсь я и, следовательно, получить такие же результаты. По сути, вы можете следовать за мной, повторяя мой беглый анализ. Для этого, вам требуется обработать этот файл двоичного журнала через Snort. В результате, у вас появится файл «alert.ids» в папке журнала. Это и есть тот журнал, который вы, в свою очередь, обработаете через Snortsnarf. Вот синтаксис обработки файла двоичного журнала, на случай если вы его забыли:
C:\snort\etc> c:\snort\bin\snort.exe –r “binary_file” –c snort.conf –A full
Я также полагаю, что вы делаете это под win32. Существуют разные способы запуска Snort на это задание. Тот способ, который я вам показал, является самым быстрым, чтобы заставить Snort работать для вас. Как только вы поближе познакомитесь с этой программой, можете позднее внести некоторые изменения в файл snort.conf. Итак, вы выполнили вышеуказанные действия и получили файл «alerts.ids», который располагается в папке журналов. Во время этих действий вы могли получить ошибку, связанную с правами доступа к каталогу «log». В этом случае, просто создайте каталог «log» в директории «C:\snort\etc» следующей командой:
“mkdir log”
После этого, вышеуказанная команда будет работать. Теперь, получив файл, мы пропустим его через Snortsnarp. Вот синтаксис:
C:\SnortSnarf-021111.1> snortsnarf.pl –win –rs alert.ids
Эта программа обработает выходной файл Snort «alert.ids» и покажет нам результат на нескольких приятно оформленных страницах. Snortsnarf очень хорош как показом этих приятных страниц, так и благодаря нескольким отличным ссылкам на сайты и т.п. Появление каталога «snfout.alert.ids» означает готовность программы к работе. Этот каталог вам нужно будет открыть в web-браузере.
Рисунок 1
Из Рисунка 1 видно, что у нас есть файл «index.html». Щелкните по нему, так как в нем будет находиться вся информация верхнего уровня. Ниже находится скриншот как раз с теми сообщениями безопасности, которые были мною сгенерированы. У вас должно быть то же самое. Могут быть небольшие отличия, если вы включили правила не из стандартного набора, поставляемого со Snort.
Рисунок 2
Теперь щелкнем по первому сообщению безопасности “NETBIOS SMB DCERPC LSASS” и посмотрим, что происходит. Щелкнем по ссылке «сводка» (Summary), которая даст нам информацию о том, что происходит с этим сообщением безопасности. Теперь мы видим девять сообщений безопасности, инициированных с адреса 192.168.1.102 и направленных на адрес 192.168.1.101. Отсюда я щелкну по 192.168.1.102, что даст нам больше информации по этому сообщению. В частности, мы увидим именно тот пакет, который первым это сообщение и вызвал. Смотрите, пожалуйста, ниже;
[**] [1:537:12] NETBIOS SMB IPC$ share access [**]
[Classification: Generic Protocol Command Decode] [Priority: 3]
03/13-11:15:24.142705 192.168.1.102:32781 -> 192.168.1.101:139 TCP TTL:64 TOS:0x0 IpLen:20 DgmLen:127
DF ***AP*** Seq: 0x3A7C1D85 Ack: 0xFA4695E6 Win: 0x5B4 TcpLen: 32
TCP Options (3) => NOP NOP TS: 5456290 4504
С помощью этого, мы теперь можем обратиться к нашему двоичному файлу журнала и узнать, что же случилось в дальнейшем. Следуя вышеприведенным рекомендациям, мы создадим BPF-фильтр, который поможет нам быстро найти этот пакет. Я лично построю фильтр, основанный на IP-адресе номере порта источника. Я делаю это по той причине, что порт источника 32781 – это временный порт, и маловероятно, что он снова появится в файле после завершения сессии. Давайте попробуем! Заметьте, что вам придется вводить команду DOS, а нижеприведенную команду выполнить через windump.exe
C:\windump.exe> windump.exe –r “binary_file” –nXvSs 0 ip and host 192.168.1.102 and src port 32781 |more
Выполнив эту команду, отметим, что мы находимся на первом этапе TCP/IP-взаимодействия между хостами 192.168.1.102 и 192.168.1.101. В данной точке следует отметить, что как только связь установлена, мы получаем пакет с временной меткой 11:15:24.119210, как показано ниже.
11:15:24.119210 IP (tos 0x0, ttl 64, id 24060, offset 0, flags [DF], length:
152) 192.168.1.102.32781> 192.168.1.101.139: P [tcp sum ok]
981212356:9812124
56(100) ack 4198929678 win 1460 <nop,nop,timestamp 5456266 4504> NBT Packet
0x0000: 4500 0098 5dfc 4000 4006 5848 c0a8 0166 E…].@.@.XH…f
0x0010: c0a8 0165 800d 008b 3a7c 1cc4 fa46 950e …e….:|…F..
0x0020: 8018 05b4 80dc 0000 0101 080a 0053 418a ………….SA.
0x0030: 0000 1198 0000 0060 ff53 4d42 7200 0000 …….`.SMBr…
0x0040: 0018 0120 0000 0000 0000 0000 0000 0000 …………….
0x0050: 0000 d815 0000 7b46 003d 0002 4d45 5441 ……{F.=..META
0x0060: 5350 4c4f 4954 0002 4c41 4e4d 414e 312e SPLOIT..LANMAN1.
0x0070: 3000 024c 4d31 2e32 5830 3032 0002 4e54 0..LM1.2X002..NT
0x0080: 204c 414e 4d41 4e20 312e 3000 024e 5420 .LANMAN.1.0..NT.
0x0090: 4c4d 2030 2e31 3200 LM.0.12.
Вышеприведенный пакет говорит нам о том, что был использован Metasploit и, возможно, эксплоит LSASS, как следует из ссылки LANMAN в ascii-содержимом. Хотя это может и не выглядеть так, как будто вы сделали много, следуя за мной, но вы определенно выполнили это. Вы установили планку для будущего развития способностей пакетного анализа. Учитывая это, с вашего позволения я сохраню в секрете оставшуюся информацию двоичного журнала.
Вызов
Используя как вывод Snortsnarp, так и двоичный журнал для дальнейших поисков, я очень приветствую ваше желание узнать, что же происходит. Один бросаю вам один простой вызов! Можете ли вы ответить мне по электронной почте, какая в точности временная метка у пакета, когда хост 192.168.1.102 получает доступ к 192.168.1.101 на системном уровне через эксплоит LSASS? Пожалуйста, напишите мне ваш ответ или вопросы, если вам не удалось это выяснить. Мне будет просто объяснить еще раз тот же самый процесс, который мы до этого рассматривали. За исключением полного знания протоколов и атак, все можно найти в Google. Если вы чего-то не знаете — поищите это в Google, ведь есть шанс, что кто-то другой это видел! Я искренне надеюсь, что данная серия статей открыла вам глаза на мир пакетного криминала и компьютерной безопасности. И помните: чем лучше вы будете понимать TCP/IP, тем легче вам будет в понимании всех остальных околокомпьютерных тем.
Источник www.windowsecurity.com
Tags: redirect