В предыдущей части этой серии я показал, что даже простой сетевой перехват может превратиться в сотни пакетов, вам совершенно не нужных. Я также показал, как отфильтровать эти «шумовые» пакеты, так чтобы вы могли видеть только интересные вам пакеты. Теперь я хочу продолжить обсуждение, показав вам, как вскрывать оставшиеся пакеты, так чтобы вы могли видеть содержащиеся в них данные.
В конце предыдущей статьи наш отфильтрованный набор пакетов выглядел так, как показано на Рисунке A. Как я объяснял в начале серии статей, я захватил эти данные, начав захват с помощью команды PING, а затем остановив захват. Моей целью было упростить все, насколько это возможно. Если вы посмотрите на Рисунок A, вы увидите, куда были отправлены ICMP пакеты, и где были получены ответы.
Рисунок A. Обычно полезно исключить ненужные пакеты.
Если бы это был настоящий захват, обычно не было бы никакой нужды погружаться глубже в данные, так как вы можете точно сказать, что происходит, исходя из колонки Description (Описание). Однако в реальности обычно все не так просто. Четкое определение происходящего при трассировке обычно требует просмотра индивидуальных пакетов.
Вообще-то ничего особенно значительного внутри ICMP пакета я показать не могу. Поэтому давайте посмотрим на некоторые захваченные LDAP пакеты. Как вы, наверное, знаете, LDAP означает Light Weight Directory Access Protocol (Облегченный протокол доступа к каталогам). LDAP используется для чтения информации из и записи информации в Active Directory.
Существуют две причины, почему я хочу вам показать, как анализировать LDAP пакеты. Во-первых, в сетях Windows LDAP пакеты — очень частое явление. А раз так, то вам в какой-то момент наверняка понадобится расшифровать LDAP пакеты.
Вторая причина, по которой я хочу показать вам, как просматривать внутренности LDAP пакета, состоит в том, что в этих пакетах содержатся данные, которые может прочитать человек. Это поможет вам понять, что в действительности делает пакет. Технология, которую я вам хочу показать, может использоваться для просмотра содержимого любого пакета; правда, не каждый пакет окажется вам понятным, конечно, если вы не эксперт по протоколам.
Взгляд внутрь пакета
Давайте начнем с просмотра содержимого фрейма номер 284. Описание просто говорит, что этот фрейм является поисковым запросом. Факт тот, что о машине, запускающей поисковый запрос LDAP, много не узнаешь. Единственный путь узнать, из чего состоит поисковый запрос, — посмотреть внутрь пакета.
Перед тем, как открыть пакет, щелкните на иконки, чтобы включить панель деталей и панель шестнадцатеричной записи. Когда все панели отобразятся, выберите пакет, на который вы хотите взглянуть. Когда вы это сделаете, вы увидите экран, похожий на то, что показано на Рисунке B.
Первое, что я хочу показать, — панель деталей. Если вы посмотрите на эту панель, вы заметите, что тут есть несколько разных расширяемых контейнеров (Frame, Ethernet, IP, TCP и LDAP). Причина такого разнообразия в том, что пакеты обычно иерархичны по своей природе. Пакет, который мы рассматриваем, является LDAP пакетом, но у компьютеров ведь LDAP не является родным языком. LDAP в действительности основывается на TCP протоколе. TCP, в свою очередь, является частью IP протокола. Каждый контейнер в панели деталей представляет собой индивидуальный слой инкапсуляции.
Если вы посмотрите на панель шестнадцатеричной записи, вы увидите шестнадцатеричное представление индивидуальных байтов, который составляют пакет. Обратите внимание, что каждый байт показывается на черном фоне. Причиной этому служит то, что таким образом отмечаются байты, которые соответствуют части пакета, выбранной в панели деталей. В данном конкретном случае выбран контейнер FRAME. Этот контейнер представляет весь фрейм, поэтому весь фрейм и высвечивается черным. Если бы я выбрал LDAP, тогда бы высветились черным только те байты, которые соответствуют данным LDAP (Рисунок C).
Рисунок C. В панели шестнадцатеричной записи отображается текущая часть пакета.
Вы, возможно, заметили, что каждый контейнер расширяемый. Щелкнув на знак плюса рядом с контейнером, вы проникните глубже в пакет. Часто возможно увидеть, что делает пакет, просто посмотрев глубже во фрейм. Если вы посмотрите внимательнее на Рисунок C, вы сможете увидеть несколько читаемых слов в кодировке ASCII выбранных шестнадцатеричных данных. Однако, эти «читаемые» данные довольно трудно прочитать. Слова начинаются на одной линии и заканчиваются на другой, и зачастую разделены непонятными символами. Черное выделение тоже усложняет чтение этой секции из-за напряжения, которое требуется для прочтения.
Более удобным способом просмотра содержимого пакета является расширение раздела LDAP пакета из панели Detail. Расширение контейнера LDAP обнаруживает, что этот конкретный пакет является LDAP поисковым запросом, как показано на Рисунке D. Это означает, что пакет был отправлен как попытка встать в очередь Active Directory.
Рисунок D. Расширение раздела LDAP пакета обнаруживает, что пакет является LDAP поисковым запросом.
Итак, теперь мы знаем, для чего нужен этот пакет, но мы пока еще не знаем, что этот пакет делает. LDAP запрос является попыткой получить информацию из Active Directory, но какую именно информацию он пытается получить? Если вы расширите контейнер LDAP: Protocol0p = SearchRequest, вы сможете увидеть, что один из подконтейнеров отмечен как Attribute Description List (Рисунок E). Если вы посмотрите на этот рисунок, вы заметите, что список Attribute Description List соответствует наиболее понятной части данных, отображаемых в панели шестнадцатеричной записи.
Рисунок E. LDAP поисковые запросы всегда сопровождаются списком распределения атрибутов.
Вы также заметите по рисунку, что контейнер Attribute Description List является расширяемым. Если вы его расширите, вы сможете увидеть, что Network Monitor четко отображает, какие атрибуты LDAP фрейма запрашивают информацию (Рисунок F).
Рисунок F. Network Monitor четко отображает, какие атрибуты LDAP фрейма запрашивают информацию.
Заключение
В этой серии статей я описал основы использования Network Monitor. Microsoft скоро выпустить Network Monitor версии 3, но все, что я описал в этих статьях, будет работать и в новой версии.
Автор: Брайн Позей (Brien Posey)
Источник: www.netdocs.ru