Протокол РОРЗ используется как упрощенный протокол почты, который хранит сообщения на сервере, пока клиентская машина не соединится и не выгрузит их по запросу. Он делает не слишком много по обработке сообщения на сервере; служба РОРЗ просто слушает порт TCP 110, пока почта не будет извлечена, и удаляет ее из почтового хранилища. Это не очень развитый протокол, но он достаточно эффективен.
Когда клиент РОРЗ хочет создать соединение, он следует схеме одиночных рабочих команд. Подобно протоколу SMTP, который был рассмотрен ранее, команды состоят из символов ASCII, разделенных пробелами. Эти команды имеют длину в три или четыре символа. Модификаторы для команд РОРЗ могут быть до 40 символов длиной.
Сервер РОРЗ дает два типа ответов. Первый ответ является положительным. Отрицательным ответом является -ERR. Оба эти ответа должны быть представлены заглавными буквами и содержать либо знак -, либо знак +.
Некоторые команды будут создавать многострочный ответ с сервера (например, команда list), и каждая строка будет заканчиваться комбинацией возврата каретки и перевода строки (та же самая комбинация ASCII 13 и ASCII 10 использовалась в протоколе SMTP). Когда все строки будут посланы, сервер пошлет . (ASCII 46) и дополнительный перевод строки. Это та же комбинация <RLF>.[T04Ka]<RLF>, которую мы видели в протоколе SMTP.
Четыре состояния РОРЗ Во время процесса соединения клиента и получения почты РОРЗ проходит через четыре состояния. После начального соединения TCP и последующего приветствия сервер входит в состояние авторизации, в котором клиент идентифицирует себя. Вслед за состоянием авторизации РОРЗ входит в состояние транзакции и получает команды с клиентской машины для обработки почты. После успешной обработки почты и отправки клиентом команды завершения quit сеанс входит в фазу обновления и освобождает ресурсы, использованные во время состояния транзакции. Затем соединение TCP закрывается. Эта последовательность событий для успешного сеанса подробно описана в следующем списке.
1. Клиентская машина запрашивает у DNS адрес.
2. Когда адрес получен, машина инициирует трехходовое квитирование на порте 110.
3. Вслед за трехходовым квитированием сервер посылает приветствие.
4. Клиент отвечает именем пользователя.
5. Сервер проверяет, существует ли пользователь в системе, и отвечает с помощью +ОК.
6. Клиент отвечает паролем.
7. Сервер отвечает +ОК.
8. Клиент запрашивает состояние почтового ящика.
9. Сервер отвечает, посылая число и размер сообщений в почтовом ящике.
10. Клиент запрашивает список сообщений.
11. Сервер отвечает.
12. Клиент пересылает себе сообщения.
13. Клиент стирает сообщения на сервере.
14. Когда все сделано, он посылает команду завершения quit.
15. Сервер отвечает с помощью+ОК
Таблица 8.2 суммирует команды РОРЗ, которые обычно встречаются в трассировках сетевого мониторинга.
Графическая панель показывает текущее состояние сети. Эти панели имеют изменяемый размер, позволяя лучше представить данные. Это полезное свойством при мониторинге процесса перехвата. Это высокоуровневое представление может помочь при поиске неисправностей, предоставляя перечисленную ниже информацию.
• Процент загруженности сети
• Число кадров в секунду
• Число байтов в секунду
• Число широковещательных сообщений в секунду
• Число мультивещательных сообщений в секунду
Панель общей статистики показывает числовой итог информации, содержащейся в графической панели. Появляется также статистика относительно перехваченных данных. Панель сообщает, сколько кадров находится в буфере, какая доля буфера использована, были или нет какие-либо кадры отброшены в связи с переполнением буфера. Дополнительная статистика предоставляет информацию о сетевой плате.
Панель статистики сеанса (ниже графической панели) перечисляет сетевые адреса компьютеров, общающихся во время текущего сеанса перехвата. Она показывает, сколько кадров находится в сети и в каком направлении они движутся. Обратите особое внимание на стрелку, так как она используется в сетевом мониторе для указания направления потока данных (используется также при создании фильтров перехвата). Стрелка всегда указывает в направлении компьютера, который будет получать информацию. Например, на рис. bigguy в столбце сетевого адреса 1 посылает 31 кадр в PROX в столбце сетевого адреса 2. PROX посылает 25 кадров назад bigguy.
Панель статистики станции (ниже статистики сеанса) более подробно представляет информацию из статистики сеанса, перечисляя число байтов посланных и полученных каждой станцией, представленной в буфере перехвата. Информация о посланных широковещательных и мультивещательных сообщениях особенно полезна для быстрого выявления потенциальных проблем в сети. Кроме того, может понадобиться исследовать направление потока данных и размеры различных происходящих обменов данными. Все это может оказаться потенциальными узкими местами сети.
Когда сеанс перехвата закончен, что мы имеем? Сетевой монитор упрощает задачу анализа данных, организуя перехваченные данные в несколько различных представлений и выполняя большую часть анализа протокола. На рис. мы видим сводное представление. Оно полезно для получения обзора информации, содержащейся в перехваченных данных. Большое число кадров BPDU на рис. являются конфигурационными сообщениями коммутатора.
Добавляя подробное и шестнадцатеричное представления из меню Window, можно найти такую информацию, как адрес источника и адрес места назначения кадра. На рис. мы видим источник и место назначения трафика BPDU, который поглощает большую часть полосы пропускания сети. Вооружившись этой информацией, можно перейти к машине и
Чтобы защитить свою сеть от неавторизованного просмотра, сетевой монитор может легко определить другие экземпляры программы в сети. Он может сделать это независимо от того, работает или нет программа. Как показано на рис., если драйвер установлен на машине, он будет сообщать имя машины, имя зарегистрированного на компьютере пользователя, адрес Ethernet машины, номер версии программы и перехватывает ли программа данные, или просто установлена. Чтобы получить эту информацию, необходимо выбрать в меню Tools пункт Identify network monitor users (Идентифицировать пользователей сетевого монитора). Важно отметить, что если имеются сетевые сегменты, разделенные маршрутизатором, который не пересылает мультивещательные сообщения, то невозможно будет определить установки сетевого монитора в другом сегменте, не соединившись с этим сегментом. Это связано с тем, что Netmon использует суффикс NetBIOS для объявления о своем присутствии в сети. Суффикс BE объявляет агента сетевого монитора, а суффикс BF объявляет в сети само приложение сетевого монитора. Если они не пересылаются, то необходимо будет соединиться с определенным сегментом, чтобы определить незаконные установки этих инструментов.
После выбора пункта меню "Определить пользователей сетевого монитора" машина Netmon посылает запрос станции BONE, как показано в следующей распечатке. Протокол BONE (сокращение от Bloodhound Oriented Network Entity, что может быть приблизительно переведено как "Сетевая ищейка") используется сетевым монитором, чтобы он мог общаться. Этот ьапрос станции является очень маленьким кадром многоадресной рассылки 802.3, который использует только 29 байтов.
Ответ направляется в машину, которая послала запрос, и является маленьким кадром 802.3, в этот раз требующим около 125 байтов. Ответ сообщает статус драйвера; 0x00000003 означает, что драйвер установлен и активен, но не перехватывает данные. Он содержит версию драйвера, машину, адрес MAC машины и имя любого пользователя, которое было сконфигурировано при конфигурировании драйвера.
