Monday, December 11th, 2017

Еще раз о специализированных инструментах (Часть 2)

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

В первой части этой статьи рассказывалось о том, как IDS может обнаруживать определенные инструменты для безопасности (security tools). Было рассказано о сетевом анализаторе пакетов (packet sniffer) и сетевом сканере (network scanner). В этой статье анализ продолжается.

Если вы хотите ознакомиться с остальными частями этой темы, пожалуйста, прочитайте:

В первой части этой статьи мы остановились на том, что сформировали несколько пакетов с помощью сетевого сканера под названием nmap. Этот сетевой сканер в свою очередь сформировал несколько предупреждений, которые упоминались в файле “alert.ids” в директории журналов Snort. Это было результат сканирования портов на компьютере, на котором мы запустили Snort. Теперь мы знаем, что nmap сформирует IDS. Все это хорошо, но что конкретно сделал nmap, что позволило Snort узнать об его присутствии? В самом деле, хороший вопрос, на который мы должны найти ответ. Во первых, давайте снова взглянем на файл “alert.ids”.

44

Рисунок 1

Теперь мы должны индивидуально поработать с каждым сообщением. Сначала мы должны посмотреть на само сообщение. Мы должны отследить правило Snort, которое сработало, когда nmap сформировал несколько пакетов, посланных для сканирования компьютера, на котором запущен Snort. Наконец, мы должны посмотреть на пакет, который был послан nmap для завершения нашего анализа. На этом давайте приступим непосредственно к анализу!

Первое сообщение, которое мы получили, было “ICMP PING NMAP”. Глядя на это сообщение можно получить много важной информации. Мы знаем, что Snort классифицировал его, как “attempted information leakage (попытка утечки информации)”. В действительности это верно для определенного содержимого, т.к. эхо пакет ICMP (echo packet) в основном используется для того, чтобы узнать, активен ли компьютер по определенному IP адресу. Это будет верно, если эхо ответ ICMP (echo reply) вернулся в ответ на эхо запрос (echo request). Если этой информации вам недостаточно, то вы должны посмотреть в директорию с правилами (/rules) Snort, чтобы увидеть само правило. Там вы получите номер SID, которые можете использовать на домашней странице Snort для получению более четкого объяснения правила. Взгляните ниже и поймете, о чем я говорю.

45

Рисунок 2

После того, как вы нашли и открыт набор правил icmp ruleset с помощью блокнота или любого другого редактора, вы быстро найдете правило под названием “ICMP PING NMAP”, как видно из рисунка ниже.

46

Рисунок 3

Теперь выберите правило и прочитайте всю строчку, посвященную ему. На этой строчке вы найдете номер SID number. Это тот самый номер, который вы должны ввести на домашней странице Snort homepage в закладке rules (правила). На этой странице вы сможете найти более подробное описание интересующего вас правила. Очень важно, чтобы вы понимали, как и почему срабатывает правило. Не достаточно просто сказать, что это сообщение, важно понимать, почему оно появилось. Благодаря этим знаниям вы сможете отличить фальшивые срабатывания от настоящих сообщений об опасности. Хорошо теперь давайте взглянем на содержимое пакета, который был послан nmap. Пожалуйста, посмотрите на пакет, представленный ниже.

10:14:46.687500 IP (tos 0x0, ttl 48, id 28060, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.1.104 > 192.168.1.107: ICMP echo request seq 45131, length 8
0
x0000: 4500 001c 6d9c 0000 3001 9921 c0a8 0168 E…m…0..!…h
0
x0010: c0a8 016b 0800 ed7c 5a37 b04b k…|Z7.K

Хорошо, если у вас нет возможности перейти на домашнюю страницу Snort homepage и посмотреть точное описание правила в разделе правил (rules section), я приведу его ниже в этой статье.

“Команда Nmap ICMP ping, по умолчанию посылает нулевые данные в команде ping. Nmap обычно выполняет команду ping для компьютера с помощью icmp, если у пользователя имеются привилегии root”

Согласно описанию этого правила Nmap не посылает никаких данных в пакете с командой ping. Очень мало сетевых утилит по управлению посылают данные в эхо пакете ICMP echo packet. Наш пакет, как можно увидеть выше, ничего не имеет в разделе “payload”, как и должно быть. Поэтому, скорее всего это пакет Nmap. Пожалуйста, запомните, что подчеркнутая часть пакета, представленного выше – это само ICMP сообщение. Остальное – это заголовок IP header, необходимый для маршрутизации этого сообщения. Поэтому все замечательно! У нас наблюдается настоящий прогресс. Не следует недооценивать знания, необходимые для отслеживания сообщений на этом уровне. Если вам посчастливилось работать в индустрии компьютерной безопасности, то знания такого рода позволят значительно сэкономить вам время.

Теперь давайте взглянем на следующее сообщение из нашего файла “alert.ids”. Оно называется “TCP port scan (сканирование порта)”. Достаточно странно, я никогда бы в жизни не нашел категорию в директории правил (rules directory), где бы располагалось такое специфическое правило. Если кто-нибудь из вас найдет его, то, пожалуйста, напишите мне письмо, т.к. мне будет очень интересно его найти. Как бы то ни было, это правило сообщает, что было обнаружено сканирование порта. Первая странность “DgmLen: 162”, что можно увидить в файле alert.ids на рисунке выше. Это очень странно для сканирования порта, т.к. обычно для сканирования порта используется обычный пакет TCP/IP или UDP/IP. И, конечно же, в запросе сканирования не должно содержатся никаких данных. Плюс к этому должно насторожить IP PROTO = 255 и TTL = 0.

Теперь еще одна странная вещь. Я перешел к моему файлу с пакетом, который я перехватил с помощью tcpdump.exe и не нашел ни одного такого пакета. Не было ни одного пакета с размером 162, и другими похожими характеристиками. Тут произошло одно из двух. Первое, tcpdump.exe просто не записал в журнал информацию о пакете, т.к. он был послан не из интерфейса, и второе, что Snort неверно истолковал то, что было послано. Наиболее вероятно, что tcpdump.exe просто не записал информацию о пакет в журнал. Эту уже случалось со мной, и вероятно случится снова. Поэтому я просто отброшу эту аномалию и перейду к следующему сообщению.

SCAN nmap XMAS – это пакет, в котором установлен лишь одни флаги URG/PSH/FIN. Теперь это старый и неэффективный способ сканирования, который все еще используется некоторыми людьми. Правило snort для него можно увидеть ниже.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:”SCAN nmap XMAS”; flow:stateless; flags:FPU,12; reference:arachnids,30; classtype:attempted-recon; sid:1228; rev:7;)

Наш пакет, которые приведен ниже, кажется великолепно подходит под это правило. Пожалуйста, обратите внимание, на подчеркнутые части пакета. Мы видим, что флаги присутствуют “FP” и “urg”. Мы знаем, что значение для этих флагов “29” (это 0x29 или 29 в шестнадцатиричной системе) полях для флагов TCP. Тогда все замечательно!

10:14:47.109375 IP (tos 0x0, ttl 53, id 24630, offset 0, flags [none], proto: TCP (6), length: 60) 192.168.1.104.47824 > 192.168.1.107.53: FP, cksum 0xd1e3 (correct), 1815364556:1815364556(0) win 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
0x0000: 4500 003c 6036 0000 3506 a162 c0a8 0168 E..<‘6..5..b…h
0x0010: c0a8 016b bad0 0035 6c34 43cc 0000 0000 …k…5l4C…..
0
x0020: a029 0800 d1e3 0000 0303 0a01 0204 0109 .)…………..
0
x0030: 080a 3f3f 3f3f 0000 0000 0000 ..????……

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

Источник 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 – часть ... [+]