Читаем без скачивания Защита от хакеров корпоративных сетей - Коллектив авторов

Рис. 11.3. «Порча» кэша протокола ARP

Рис. 11.4. Доступные соединения между выбранными хостами

В рассматриваемом случае был выбран коммутатор A Linksys BEFSR81 и сетевой клиент, на машине которого запущен Windows 2000 Advanced Server. Для определения операционной системы узла с IP-адресом 192.168.1.100 была использована опция идентификации операционной системы. Обратите внимание на сгенерированное коммутатором (192.168.1.1) для Windows 2000 server (192.168.1.100) сообщение авторизованному диспетчеру простого протокола сетевого управления SNMP (SNMP – Simple Network Management Protocol, простой протокол сетевого управления. Протокол сетевого администрирования, широко используемый в настоящее время. Входит в стек протоколов TCP/IP) о запросе со стороны неавторизованного диспетчера. Обычно это является признаком использования хоста получателя сообщения (192.168.1.100) для управления коммутатором.

При нажатии клавиши h в любой момент времени работы программы выводится окно с краткой подсказкой. На рисунке 11.5 показана подсказка начальной страницы, на которой видны все хосты сегмента, а на рис. 11.6 – подсказка после выбора хоста.

Рис. 11.5. Окно подсказки начальной страницы

Рис. 11.6. Опции выбранного соединения

Помните, о чем говорилось в разделе, посвященном перехвату UDP-сессий? Из-за отсутствия в протоколе UDP-средств корректировки ошибок и гарантий доставки пакетов перехватить UDP-сессию гораздо проще, чем сессию протокола TCP. В этом заслуживающем особого внимания случае злоумышленник может нанести большой вред, просто перехватив SNMP-соединение. Вы спросите: почему? Ответ прост. Если у злоумышленника есть доступ к конфигурации коммутатора, то он обладает слишком большими возможность что-то сделать на этой сети или по отношению к ней. В данном случае коммутатор используется как шлюз для выхода в Интернет, так что дух захватывает от потенциального вреда, который может нанести злоумышленник. Но давайте перейдем с точки зрения практики к более интересным вещам.

Рассмотрим следующий сценарий. У злоумышленника есть доступ к запущенному на сервере протоколу FTP, но установить соединение он может только с хостом, IP-адрес которого равен 192.168.1.103. При запуске программы Ettercap злоумышленник видит порт 21 на сервере, который сначала активизируется, а затем переходит в состояние пассивного ожидания (silent state). Злоумышленник выбирает порт 21 и создает соединение между FTP-сервером и клиентом. После установки соединения у него появляется возможность по своему желанию перехватывать и модифицировать трафик сети или вставлять свои данные в передаваемую по сети информацию (см. рис. 11.7).

Рис. 11.7. Выбор SMB-соединения

На рисунке приведен образец экранной формы, на которой представлен обзор трафика сети Microsoft от сетевого клиента к серверу. Порты 137 и 139 закреплены за сетевой базовой системой ввода-вывода Microsoft NetBIOS и сервисами сессии. Порт 445, так же как и порты 138 и 139 в предыдущих версиях Windows, используется для обеспечения работы сервисов каталога Microsoft (Microsoft directory services) и обеспечивает большинство функциональных возможностей для протокола SMB (SMB – Server Message Block, блок серверных сообщений. Протокол разработан Microsoft, Intel и IBM. Он определяет регламент совместного использования файлов компьютерами в сети и отвечает за структуризацию запросов и связь с различными операционными системами. Аналогичен протоколу NCP) поверх TCP/IP в Windows 2000. Недавно опубликованная по адресу www.newsbytes.com/news/01/169408.html статья раскрывает некоторые проблемы безопасности, которые может создать этот порт для типового оборудования, объединенного в сеть. Достаточно интересен тот факт, что даже после отключения NetBIOS по TCP/IP с помощью изменения конфигурации сетевой карты этот порт будет все еще обнаруживаться.

Допустим, злоумышленник выбирает порт 445, который в момент выбора находится в состоянии пассивного ожидания (silent state). Несомненно, что этому порту соответствует управляемое соединение между клиентом с IP-адресом 192.161.1.103 и сервером. При работе злоумышленника со списком файлов каталога или при другом варианте просмотра к нему из сети поступают SMB-сообщения, нагружая сеть и искажая передаваемые по ней данные в результате шумовых помех.

На рисунке 11.8 показано внутреннее представление части активного соединения клиента с совместно используемым сервером при использовании вывода в текстовом формате. При желании злоумышленник может записать эту информацию в журнал для дальнейшего использования.

Рис. 11.8. Внутренние представление SMB соединения

Программа SMBRelay

Давайте более внимательно рассмотрим предыдущий пример. Как, не рассматривая вставку ложных пакетов, легче всего перехватить SMB-сессию? Конечно, c помощью программы SMBRelay.

SMBRelay – это программа, написанная SirDystic cDc, которая позволяет перехватывать SMB-сообщения, вынуждая клиента разорвать соединение после аутентификации пользователя. После разрыва соединения злоумышленник захватывает существующую SMB-сессию, используя тот же самый мандат (учетную запись с параметрами доступа пользователя, сформированную после его успешной аутентификации). Единственный способ противодействовать этому – использовать возможность подписи SMB-сообщений на обоих концах соединения. Вполне вероятно, что в результате этого производительность работы сети снизится на 10–15 % и будут разорваны большинство совместимых назад (не исключающих использование прежних версий или модификаций) соединений клиента, поэтому при выборе данной возможности следует проявить осторожность.

Подробные сведения об изменениях, которые необходимо выполнить для поддержки подписи SMB-сообщений, можно найти по адресу http://support.microsoft.com/support/kb/articles/Q161/3/72.asp.

Наблюдатели перегрузки сети

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

Повторные передачи и дублирующие пакеты не являются чем-то необычным в обычных сетях, но в большинстве случаев содержимое пакетов должно быть одинаковым. Для рассмотренных примеров работы протоколов ARP и службы DNS вполне возможно написать программу, которая наблюдала бы за ответами, вычисляла бы кэш-величину пакета, а затем сохраняла бы эти данные в течение определенного периода времени. Поступление другого пакета с согласованными подходящим образом характеристиками, но с различными кэш-величинами свидетельствовало бы о возможных сетевых проблемах. (Следует очень внимательно отнестись к игнорированию частей пакета, которые нельзя на 100 % считать подозрительными до подсчета кэш-величины, как, например, время жизни пересылаемого пакета TTL). В основном это принцип систем обнаружения вторжения IDS со всеми их преимуществами и недостатками.

Перегрузка сети уведомлениями ACK (ACK Storms)

Ранее в этой главе был кратко рассмотрен пример перехвата Telnet-сессии. Цель перехвата заключалась в выполнении команды на сервере. Для этого примера автор сознательно выбрал короткую команду, в выводе результатов выполнения которой не было необходимости. На то были причины. Протокол TCP может идеально подойти для перехвата сессии. Если злоумышленник попытается контролировать оба конца соединения или удержать затянувшееся перехваченное соединение, то он может столкнуться с некоторыми трудностями. Давайте выясним, почему.

Напомним, что протокол TCP является надежным средством доставки сетевых пакетов данных. Так как TCP находится выше обслуживаемого протоколом IP ненадежного уровня, на котором пакеты иногда теряются, искажаются или принимаются вне очереди, то протокол TCP вынужден взять на себя ответственность за решение этих проблем. Существенным является то, что протокол TCP в случае необходимости решает подобные проблемы путем повторной передачи пакетов. Реализующее протокол TCP программное обеспечение сохраняет на каждом хосте копию всех ранее посланных данных до тех пор, пока не будет получено уведомление (ACK-пакет) об успешном приеме данных, генерируемое получателем пакетов на другом конце соединения. Данные удаляются только после подтверждения приема. Если в поддерживаемой программным обеспечением очереди на отправку данных имеются данные, на которые в течение определенного промежутка времени не получено уведомление об их приеме, то они посылаются повторно, предполагая, что ранее эти данные потерялись при передаче.

Если злоумышленник попытается вклиниться в TCP-соединение и претендует на то, чтобы стать участником соединения, то он должен вступить в конкурентную борьбу с хостом, за который злоумышленник себя выдает, для того чтобы раньше него получить пакет с правильными последовательными номерами. Для разбираемого примера предположим, что злоумышленник не может блокировать пакеты, поступающие от легитимного хоста. Случаи, когда это возможно, ранее обсуждались. Во время конкурентной борьбы наступает момент, когда злоумышленник получает один из пакетов раньше легитимного хоста. Если это произошло, то можно сказать, что перехват соединения состоялся. Проблема заключается в том, что хост, за который злоумышленник себя выдает и который только что уступил в конкурентной борьбе, все еще собирается отослать свой пакет.