Коллектив авторов - Защита от хакеров корпоративных сетей

Ранее уже были обсуждены средства антиспуфинга, начиная от простых и заканчивая сложными, но по-прежнему не был получен ответ на вопрос «Как на самом деле создаются системы спуфинга?». Часто ответ на этот вопрос заключается в изучении сетевого трафика, повторной реализации протокола более простым и универсальным программным способом и отправкой сетевых данных самым неожиданным для получателя способом.

Плевок против ветра: создание скелета маршрутизатора в пространстве пользователя

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

Это – ошибкоустойчивость наоборот.

Что действительно необходимо, так это простая инфраструктура, с помощью которой можно получить доступ к произвольным пакетам, возможно с использованием, но лучше без использования фильтрации пакетов на уровне ядра. Кроме того, она должна обеспечивать эффективную и достаточно легкую обработку пакетов с последующей отсылкой, если это необходимо, их обратно. Возможным решением поставленной проблемы является программа DoxRoute 0.1, которая доступна по адресу www.doxpara.com/tradecraft/doxroute вместе со своей документацией, что является первым подобным случаем.

Проектирование несуществующего: сетевая карта, которая не существовала, но возвращала код возврата

В сети маршрутизатор всегда выполняет три вещи:

• отвечает на ARP-пакеты, которые ищут определенный MAC-адрес;

• отвечает на запросы ping, которые ищут определенные IP-адреса;

• передают транзитные пакеты дальше, возможно, запрашивая информацию о промежуточных точках маршрута пакетов.

Традиционно эти функции выполняются ядрами операционных систем. В худшем случае ядра операционных систем – это большие, неповоротливые, трудно управляемые животные. В лучшем – изящные, быстро работающие черные ящики с функциями адресования и фильтрации пакетов, выполняемыми сетевыми картами самостоятельно. В специализированных системах Cisco и некоторых других производителей большинство функций маршрутизации реализованы аппаратными средствами. Максимальную производительность демонстрируют оптоволоконные специализированные системы ASIC. Но сеть не заботит вопрос о том, каким образом задание будет выполнено: будет ли оно выполнено аппаратными средствами, ядром операционной системы или, как в рассматриваемом случае, парой-сотней строк программы на языке С, переносимой с одной платформы на другую.

Программа DoxRoute является интересным решением. Это был эксперимент, который продемонстрировал возможность реализации разумных возможностей спуфинга машин сети при помощи программы, вызывающей функции библиотек libnet и libpcap. Обычно считалось, что подобные функциональные возможности могут быть реализованы сложными программами ядра операционной системы. На самом деле было показано, что их можно реализовать программой, содержащей удивительное число изящных простых решений, направленных на достижение невообразимого уровня производительности. Вероятно, необычайный уровень производительности был достигнут благодаря работе библиотек libpcap, libnet непосредственно с обрабатываемыми пакетами при их получении и передаче. Для обработки 12-мегабитного потока данных потребовалось загрузить процессор P3-800 приблизительно на 2 %. При этом время ожидания эха при посылке управляющих сообщений по протоколу ICMP было уменьшено до 0.23 мс. Оба показателя могут быть улучшены при помощи незначительного упрощения кода.

Реализация программы DoxRoute: раздел за разделом

Выполнение DoxRoute довольно тривиально:

[root@localhost effugas]# ./doxroute -r 10.0.1.254 -c -v

10.0.1.170

ARP REQUEST: Wrote 42 bytes looking for 10.0.1.254

Router Found: 10.0.1.254 at 0:3:E3:0:4E:6B

DATA: Sent 74 bytes to 171.68.10.70

DATA: Sent 62 bytes to 216.239.35.101

DATA: Sent 60 bytes to 216.239.35.101

DATA: Sent 406 bytes to 216.239.35.101

DATA: Sent 60 bytes to 216.239.35.101

Поскольку рассматриваемая реализация программы неполная, то на самом деле в ней нет обработки состояний маршрутизатора (поэтому в тексте программы не следует заменять константы со значением 7200 с). Программа DoxRoute такова, что вполне возможно завершить процесс маршрутизации на одной машине и запустить его на другой, не сообщая об этом переключателю режимов работы программы. Можно найти большое количество инструментальных систем активного спуфинга. Например, инструментальное средство Ettercap (http://ettercap.sourceforge.net) является одним из наиболее интересных пакетов фальсификации для реализации атак «злоумышленник посередине» (MITM), направленных против сеансов сети. Пакет поддерживает большое количество протоколов. С помощью Ettercap можно реализовать различные специфические варианты спуфинга. Пакет DoxRoute обеспечивает инфраструктуру для ответа на вопрос: «Что произойдет, если к сети подключить машину для выполнения..?» Если можно обмануть внутренний маршрутизатор несколькими строчками кода, то фальсификация еще чего-нибудь будет ненамного сложнее.