Установив возможные сетевые адреса, возможно попытаться определить топологию сети, и возможные пути проникновения в нее.
Отслеживание маршрутов
Эта цель может оказаться выполнена при помощи утилиты traceroute (ftp://ftp.ee. lbl.gov/traceroute.tar.Z), которая входит в набор поставки почти всех версий UNIX и Windows NT. В системе Windows NT наименование утилиты адаптировано к формату 8.3 - tracert. Утилита traceroute, написанная Ван Якобсоном (Van Jacobson), представляет собою диагностическое средство, позволяющее отслеживать маршрут, по которому IP-пакеты проходят при передаче от одного узла к другому. Для приобретения от любого из отслеживаемых узлов сообщения ICMP TIME_EXCEEDED утилита использует параметр TTL (time to live - времени жизни) пакета IP. Любой маршрутизатор, какой обрабатывает подобный пакет, должен уменьшить на единицу значения поля TTL. Т.о., поле TTL играет роль счетчика пройденных узлов (hop counter). Мы воспользуемся утилитой traceroute, чтоб определить точный путь, по которому проходят наши пакеты. Как уже упоминалось выше, эта утилита играет роль зонда, при помощи которого возможно узнать топологию представляющей интерес сети. Также, она позволяет выявить конструкции управления доступом (программные брандмауэры или фильтрующие маршрутизаторы), которые имеют возможность отфильтровывать инициализируемый исследователем поток данных. Рассмотрим следующий пример.
[bash]$ traceroute Acme.net traceroute to Acme.net (10.10.10.1), 30 hops max, 40 byte packets 1 gate2 (192.168.10.1) 5.391 ms 5.107 ms 5.559 ms 2 rtrl.bigisp.net (10.10.12.13) 33.374 ms 33.443 ms 33.137 ms 3 rtr2.bigisp.net (10.10.12.14) 35.100 ms 34.427 ms 34.813 ms 4 hssitrt.bigisp.net (10.11.31.14) 43.030 ms 43.941 ms 43.244 ms 5 gate.Acme.net (10.10.10.1) 43.803 ms 44.041 ms 47.835 ms
На основании полученной информации возможно проследить путь, по которому пакеты, прошедшие ч/з маршрутизатор (шлюз), проследовали, миновав 3 узла (2-4), к точке назначения. На всем пути следования пакеты нигде не были заблокированы. На основании раньше полученной информации известно, что МХ-запись домена Acme. net указывает на узел gate.acme.net. Следственно, возможно предположить, что этот узел является не логическим устройством, а реальным ЭВМ сети, а сегмент, ч/з какой пакет прошел на предыдущем шаге (4), - это пограничный маршрутизатор организации. Сегмент 4 может оказаться реализован как в виде выделенного программного брандмауэра, так и в виде простого фильтрующего маршрутизатора. На данном этапе об этом пока тяжело судить. Обычно, на изобретение, находящееся на сегменте, именно за которым располагается настоящий ЭВМ сети, возлагается цель маршрутизации (к примеру, маршрутизатор или брандмауэр). Рассмотренный пример чересчур прост. В настоящих случаях к одному и тому же узлу может вести несколько маршрутов, создаваемых устройствами с несколькими интерфейсами (к примеру, маршрутизаторы серии Cisco 7500). Также, любой интерфейс может иметь свой перечень управления доступом (ACL - access control list). Чаще всего кое-какие интерфейсы подобного конструкции пропускают запросы traceroute, а иные - нет, что определяется конкретным списком ACL. Так, весьма важно при помощи traceroute получить схему всей сети. После как вы попробуете проследить при помощи traceroute маршруты, по которым проходят пакеты к каждому выявленному вами узлу сети, возможно сделать схему сети, наглядно демонстрирующую архитектуру шлюза Internet, и показывающую, в каких местах расположены конструкции, выполняющие функции управления доступом. Мы будем называть эту схему диаграммой путей доступа (access path diagram). Требуется отметить, что большая часть версий traceroute систем UNIX изначально отправляют пакеты UDP (User Datagram Protocol), а пакеты ICMP (Internet Control Messaging Protocol) - лишь в случае явного указания параметра -I. Хотя в Windows NT для таких задач изначально применяются пакеты протокола ICMP, называемые эхо-запросами (echo request). Потому, если исследуемый узел блокирует или пакеты UDP, или ICMP, вы можете получать в различных операционных системах разные результаты. Посреди иных интересных параметров traceroute возможно подчеркнуть параметр -q, какой позволяет пользователю определять маршрутизацию с потерей источника запроса. Если вы уверены, что интересующий вас шлюз пропускает пакеты с измененным источником (что является весьма высокой ошибкой администратора этого шлюза), то возможно попробовать включить данный режим, указав необходимое число участков (более подробную информацию возможно получить при помощи команды man traceroute). Есть и несколько иных параметров, которые позволяют обойти конструкции управления доступом. К примеру, параметр -р n утилиты traceroute позволяет указать начальный номер порта UDP (л), какой должен увеличиваться на 1 при любой попытке отслеживания маршрута. Так, мы не сможем применять фиксированные номера портов, не модифицируя traceroute. К радости, Майкл Шифман (Michael Schiffman) уже изобрел модуль обновления, какой позволяет при помощи дополнительного параметра -S остановить автоматическое повышение счетчика для traceroute версии 1.4а5 (ftp://ftp.ee.lbl.gov/traceroute-1. 4a5.tar. Z). Это позволяет в каждом отправляемом пакете применять 1 и тот же номер порта в надежде на то, что изобретение управления доступом пропустит эти пакеты во внутреннюю сеть. Как правило, для таких задач отлично подходит UDP-порт с номером 53 (запросы DNS). Т.к. многие узлы пропускают входящие запросы DNS, есть высокая вероятность того, что изобретение управления доступом не среагирует на подобную попытку проникновения.
[bash]$ traceroute 10.10.10.2 traceroute to (10.10.10.2), 30 hops max, 40 byte packets 1 gate (192.168.10.1) 11.993 ms 10.217 ms 9.023 ms 2 rtrl.bigisp.net (10.10.12.13)37.442 ms 35.183ms 38.202ms 3 rtr2.bigisp.net (10.10.12.14) 73.945 ms 36.336 ms 40.146 ms 4 hssitrt.bigisp.net (10.11.31.14) 54.094 ms 66.162 ms 50.873 ms 5 * * * 6 * * *
Из листинга видно, что попытка применения утилиты traceroute, которая изначально отсылает пакеты UDP, была заблокирована брандмауэром. Сейчас еще раз попробуем запустить утилиту traceroute, хотя на этот раз будем применять фиксированный порт UDP 53, какой используется для запросов DNS.
[bash]$ traceroute -S -p53 10.10.10.2 traceroute to (10.10.10.2), 30 hops max, 40 byte packets 1 gate (192.168.10.1) 10.029ms 10.027ms 8.494ms 2 rtrl.bigisp.net (10.10.12.13) 36.673 ms 39.141 ms 37.872 ms 3 rtr2.bigisp.net (10.10.12.14) 36.739 ms 39.516 ms 37.226 ms 4 hssitrt.bigisp.net (10.11.31.14)47.352 ms '47.363 ms 45.914 ms 5 10.10.10.2 (10.10.10.2),50.449ms 56.213ms 65.627ms
Т.к. сейчас пакеты не вызывают подозрения у конструкции управления доступом (сегмент 4), они без трудностей его преодолевают. Так, мы можем зондировать узлы, находящиеся за устройством управления доступом, просто отправляя запросы по протоколу UPD в порт 53. К тому же, если вы будете зондировать систему, которая опрашивает порт 53 на предмет поступления извещений по протоколу UDP, вы не получите обычного сообщения ICMP о том, что эта система недоступна. Так, если вы не видели информации об узле, это значит, что пакеты дошли прежде цели. Все операции, которые мы проделывали прежде сих пор с утилитой traceroute, выполнялись в командной строке. Если вам по душе графический Интерфейс, то возможно воспользоваться утилитой VISUALROUTE (www.visualroute.com) или NEOTRACE (http://www. neotrace. com/). Утилита VISUALROUTE наглядно представляет любой пройденный сегмент маршрута и связывает его с запросами whois. Впрочем, эта утилита представляет получаемые данные в удобном формате, хотя, чаще всего, ее возможностей для широкомасштабного зондирования крупных сетей оказывается недостаточно. Существуют особые приемы, позволяющие проверить данные о списке ACL, используемом для конкретного конструкции управления доступом. Одним из подобных методов является сканирование протокола брандмауэра (firewall protocol scanning), о чем пойдет речь в главе 11, "Брандмауэры".
Главная 