3. Визначення топології мережі

Установив возможные сетевые адреса, можно попытаться определить топологию сети, а также возможные пути проникновения в неё.

Эта задача может быть выполнена с помощью утилиты traceroute (ftp://ftp.ee.lbl.gov/traceroute.tar.gz), которая входит в комплект поставки практически всех версий 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, чтобы определить точный путь, по которому проходят наши пакеты. Как уже упоминалось выше, эта утилита играет роль зонда, с помощью которого можно выяснить топологию представляющей интерес сети. Кроме того, она позволяет выявить устройства управления доступом (программные брандмауэры или маршрутизаторы с фильтрацией пакетов), которые могут отфильтровывать инициируемый исследователем поток данных.

Рассмотрим следующий пример.

C:\Documents and Settings\root>tracert tellurian.net

Трассировка маршрута к tellurian.net [216.182.1.7]

с максимальным числом прыжков 30:

1 959 ms 207 ms 190 ms 77.109.0.225

2 782 ms 725 ms 170 ms 77.109.0.175

3 213 ms 243 ms 207 ms ffm-b1-link.telia.net [213.248.93.49]

4 349 ms 1479 ms 372 ms globalcrossing-119012-ffm-b7.telia.net [213.248.103.42]

5 863 ms 322 ms 1170 ms 146.82.34.230

6 423 ms 874 ms 728 ms ge5-1.core3.tdc.nwt.tellurian.net [216.182.7.166]

7 488 ms 958 ms 333 ms ge2-1-colo3.tdc.nwt.tellurian.net [66.97.0.18]

8 307 ms 1060 ms 512 ms www.tellurian.net [216.182.1.7]

Трассировка завершена.

На основании полученной информации можно проследить путь, по которому пакеты передаются к точке назначения. На всем пути следования пакеты нигде не были заблокированы. Поэтому можно предположить, что достигнут реальный узел сети, а сегмент, через который пакет прошел на предпоследнем шаге (7), — это пограничный маршрутизатор организации. Сегмент 7 может быть реализован как в виде выделенного программного брандмауэра, так и в виде простого фильтрующего маршрутизатора. На данном этапе об этом пока трудно судить. Как правило, именно на устройство, находящееся в сегменте, непосредственно за которым находится реальный компьютер сети, возлагается задача маршрутизации (например, маршрутизатор или брандмауэр).

Рассмотренный пример слишком прост. В реальных ситуациях к одному и тому же узлу может вести несколько маршрутов, создаваемых устройствами с несколькими интерфейсами (например, маршрутизаторы серии 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 для этих целей по умолчанию используются пакеты протокола ICMP, называемые эхо-запросами (echo request).

Поэтому, если исследуемый узел блокирует либо пакеты UDP, либо ICMP, вы можете получать в разных операционных системах различные результаты. Среди других интересных параметров traceroute можно отметить параметр -g, который позволяет задать режим маршрутизации с потерей источника запроса. Если вы уверены, что интересующий вас шлюз пропускает пакеты с измененным источником (что является очень большой ошибкой администратора этого шлюза), то можно попробовать включить данный режим, указав нужное количество участков (более подробную информацию можно получить с помощью команды man traceroute).

Есть и несколько других параметров, которые позволяют обойти устройства управления доступом. Например, параметр –p n утилиты traceroute дает возможность указать начальный номер порта UDP (n), который будет увеличиваться на 1 при каждой попытке отслеживания маршрута. Таким образом, мы не сможем использовать фиксированные номера портов, не модифицируя traceroute. Однако, Майкл Шиффман (Michael Schiffman) уже создал модуль обновления (http://www.packetfactory.net/Projects/firewalk/traceroute.diff), который позволяет с помощью дополнительного параметра –S остановить автоматическое увеличение счетчика для traceroute версии 1.4а5 (ftp://cerias.purdue.edu/pub/tools/unix/netutils/traceroute/old/). Это позволяет в каждом отправляемом пакете использовать один и тот же номер порта, надеясь на то, что устройство управления доступом пропустит эти пакеты во внутреннюю сеть. Как правило, для этих целей лучше всего подходит 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.945ms 36.336ms 40.146ms

4 hssitrt.bigisp.net (10.11.31.14) 54.094 ms 66.162 ms 50.873 ms

5 * * *

Из листинга видно, что попытка использования утилиты 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.029 ms 10.027 ms 8.494 ms

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.449 ms 56.213 ms 65.627 ms

Поскольку теперь пакеты не вызывают подозрения у устройства управления доступом (сегмент 4), они без проблем его преодолевают. Таким образом, мы можем зондировать узлы, находящиеся за устройством управления доступом, просто отправляя запросы по протоколу UDP в порт 53. Кроме того, если вы будете зондировать систему, которая опрашивает порт 53 на предмет поступления сообщений по протоколу UDP, вы не получите обычного сообщения ICMP о том, что данная система недоступна. Таким образом, если вы не увидели информации об узле, это означает, что пакеты дошли до цели.

Все операции, которые мы проделывали до сих пор с утилитой traceroute, выполнялись в командной строке. Если вам по душе графический интерфейс, то можно воспользоваться утилитой VisualRoute (www.visualroute.com) или NeoTrace (http://www.neotrace.com/). Утилита VisualRoute наглядно представляет каждый пройденный сегмент маршрута и связывает его с запросами whois. Хотя, эта утилита и представляет получаемые данные в удобном формате, однако, как правило, её возможностей для широкомасштабного зондирования больших сетей оказывается недостаточно.

Утилита позволяет не только получить информацию о каждом сегменте маршрута, но и сведения о географическом местоположении соответствующего узла, данные о нем из базы whois и тип Web-cepвepa.

Существуют специальные приемы, позволяющие уточнить данные о списке ACL, используемом для конкретного устройства управления доступом. Одним из таких методов является сканирование протокола брандмауэра (firewall protocol scanning).

Также в Сети доступно множество Web-ресурсов, которые предоставляют все рассмотренные возможности: http://whatismyipaddress.com/, www.network-tools.in, www.whois.net.

Контрмеры: как пресечь зондирование сети

Мы лишь слегка затронули такую обширную тему, как методы зондирования сети. Однако уже сейчас можно сформулировать некоторые соображения о том, как предотвратить рассмотренные выше попытки зондирования.

Во-первых, многие коммерческие системы выявления вторжений (NIDS — Network Intrusion Detection Systems) позволяют выявлять попытки зондирования такого рода. Кроме того, подобные вторжения можно выявить с помощью одной из лучших бесплатных программ snort Марти Роша (Marty Roach) (http://www.snort.org/). Если вы хотите принять меры и защититься от зондирования сети с помощью утилиты traceroute, обратите внимание на утилиту RotoRouter, написанную Хамблом (Humble) (http://packetstorm.securify.com/Unix/loggers/rr-l.0.tgz). Эта утилита позволяет не только регистрировать запросы, сгенерированные утилитой traceroute, но и генерировать ложные ответы.

И, наконец, в зависимости от общей политики безопасности вашей организации можно настроить пограничные маршрутизаторы таким образом, чтобы ограничить поток данных по протоколам ICMP и UDP только строго определенными узлами. Такой подход позволит свести риск проникновения во внутреннюю сеть посредством зондирования к минимуму.

Выводы

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

В Internet постоянно "рыщет" множество квалифицированных и опытных взломщиков, которых еще никто и никогда не ловил за руку. Поэтому не забывайте о том, что чем меньше информации о внутренней архитектуре будет доступно в глобальной сети и чем тщательнее будет выполняться мониторинг всех событий, тем сложнее взломщику будет проникнуть в сеть.

Контрольные вопросы

1. Каковы возможности получения информации об удаленной сети через службу DNS?

2. Каковы возможные контрмеры обеспечения безопасности базы данных DNS?

3. Каким образом удаленно определяется топология сети и возможные пути проникновения в неё? Как пресечь зондирования сети?

1Зона — логический узел в дереве имён. Право администрировать зону может быть передано третьим лицам, за счёт чего обеспечивается распределённость базы данных. При этом персона, передавшая право на управление в своей базе данных хранит информацию только о существовании зоны (но не подзон!), информацию о персоне (организации), управляющей зоной, и адрес серверов, которые отвечают за зону. Вся дальнейшая информация хранится уже на серверах, ответственных за зону.

17