Отслеживание маршрутов

Эта задача может быть выполнена с помощью утилиты 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

На основании полученной информации можно проследить путь, по которому пакеты, прошедшие через маршрутизатор (шлюз), проследовали, миновав три узла (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). Это позволяет в каждом отправляемом пакете использовать один и тот же номер порта в надежде на то, что устройство управления доступом пропустит эти пакеты во внутреннюю сеть. Как правило, для этих целей лучше всего подходит 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, "Брандмауэры".

Содержание раздела