Инструменты и методология анализа пакетов (Часть 4)

Пакетный анализ 101

В течение последних трех статей мы видели, как настроить нашу собственную маленькую систему обнаружения вторжений и аналитическую лабораторию. В этой заключительной части мы увидим, как мы можем использовать те же самые инструменты для проведения некоторого анализа. Немногие на самом деле занимаются анализом пакетов по нескольким причинам. Многие люди не знакомы с TCP/IP на уровне пакетов, и не так много заданий, которые на самом деле требуют от вас этого. Если вы следовали этой серии статей, вы можете в некоторой степени смягчить эти причины и улучшить свои навыки.

Довольно часто системному администратору также поручают управлять безопасностью в своей сети. Быть системным администратором и так достаточно сложно, не говоря уже о добавлении к этому задаче безопасности. Изучение TCP/IP также может быть непростой задачей, но оно принесет вам дивиденды во многих отношениях. В конце концов, TCP/IP — это абсолютная основа, на которой строится связь между компьютерами. Это платит, чтобы быть в состоянии иметь очень хорошее понимание этого. Существует множество прекрасных инструментов, которые помогут вам разобраться во всем, но на самом деле они не заставят вас понять теорию этого.

На с этим!

Достаточно болтовни, а пока давайте перейдем к сути дела. Сначала загрузите двоичный файл журнала, который я создал. Это позволит вам вводить те же команды, что и я, и, следовательно, получать такие же результаты. По сути, вы можете следить за мной, пока я делаю свой беглый анализ. Для этого вам нужно будет взять бинарный лог-файл и обработать его через Snort. Это приведет к тому, что у вас будет файл «alert.ids» в вашем каталоге журнала. Именно этот журнал вы, в свою очередь, будете обрабатывать через Snortsnarf. Если вы забудете, синтаксис для обработки двоичного файла журнала будет следующим:

C:snortetc> c:snortinsnort.exe -r «двоичный_файл» -c snort.conf -A полный

Я также предполагаю, что вы делаете это в win32. Существуют различные способы вызова Snort для выполнения этой работы. Способ, который я показал вам выше, — это самый быстрый способ заставить Snort работать на вас. Вы можете внести некоторые изменения в snort.conf позже, когда освоитесь с программой. Итак, вы сделали все вышеперечисленное и создали файл «alert.ids». Это будет в вашем каталоге журналов. Вы можете получить ошибку при выполнении вышеуказанного. Это будет касаться невозможности доступа к каталогу «log». Что вы можете сделать, так это просто создать каталог журналов в C:snortetc Это делается следующим образом;

«журнал mkdir»

После этого ваш первоначальный синтаксис для snort будет работать. Теперь, когда у вас есть файл, мы обработаем его через Snortsnarf. Синтаксис следующий;

C:SnortSnarf-021111.1> snortsnarf.pl -win -rs alert.ids

Эта программа возьмет файл «alert.ids», который является выходом Snort, и выведет его на несколько хорошо отформатированных HTML-страниц для нас. Snortsnarf очень удобен тем, что дает нам эти замечательные страницы, а также несколько отличных гиперссылок на сайты для поиска и т. д. Теперь, когда программа готова, она сгенерирует каталог с именем «snfout.alert.ids». Именно этот каталог вы захотите перейти через веб-браузер.

Итак, на картинке выше мы видим, что у нас есть файл «index.html». Давайте нажмем на него, так как здесь будет вся наша информация высокого уровня. Ниже приведено изображение точных сигналов тревоги, которые были сгенерированы мной. У вас тоже должно быть так же. Может быть небольшая разница, если вы включили правила, отличные от стандартного набора правил, поставляемого со Snort.

Теперь мы нажмем на первое предупреждение под названием «NETBIOS SMB DCERPC LSASS» и посмотрим, что происходит. Мы нажмем на включенную сводную ссылку, так как это даст нам сводку, как рекламируется, о том, что происходит с этим предупреждением. Теперь мы видим, что было девять предупреждений, инициированных 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 ID:24062 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, смещение 0, флаги [DF], длина:
152) 192.168.1.102.32781 > 192.168.1.101.139: P [сумма TCP в порядке]
981212356:9812124
56(100) ack 4198929678 win 1460 <nop,nop,timestamp 5456266 4504> Пакет NBT
0x0000: 4500 0098 5dfc 4000 4006 5848 c0a8 0166 E…][email protected]@.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 лм.0.12.

Приведенный выше пакет говорит нам о том, что используется инструмент Metasploit и, возможно, также эксплойт LSASS из-за ссылки на LANMAN в содержимом ascii. Хотя может показаться, что вы многого не сделали, следуя за мной, вы определенно сделали это. Вы заложили планки для дальнейшего расширения возможностей анализа пакетов. Имея это в виду, я буду держать остальную часть двоичного журнала в секрете, если хотите.

Соревнование

Используя как вывод Snortsnarf, так и двоичный журнал для дальнейшего поиска, я настоятельно рекомендую вам выяснить, что происходит. Один простой вызов для вас! Можете ли вы сообщить мне по электронной почте, какова точная временная метка пакета, в котором 192.168.1.102 получает доступ на системном уровне к 192.168.1.101 с помощью эксплойта LSASS? Пожалуйста, напишите мне свой ответ или вопросы, если вы не можете его найти. Для меня дальнейшее продолжение означало бы просто еще раз объяснить тот же процесс, который мы использовали до сих пор. За исключением всесторонних знаний о протоколах и атаках, нужно использовать Google. Если вы чего-то не знаете, используйте для этого Google, и есть вероятность, что кто-то еще это видел! Я искренне надеюсь, что эта серия статей открыла глаза на мир криминалистики пакетов и компьютерной безопасности. Помните, что чем лучше вы понимаете TCP/IP, тем лучше вы понимаете все, что связано с компьютером.