Малоизвестные подробности: разработка систем спуфинга
Малоизвестные подробности: разработка систем спуфинга
Ранее уже были обсуждены средства антиспуфинга, начиная от простых и заканчивая сложными, но по-прежнему не был получен ответ на вопрос «Как на самом деле создаются системы спуфинга?». Часто ответ на этот вопрос заключается в изучении сетевого трафика, повторной реализации протокола более простым и универсальным программным способом и отправкой сетевых данных самым неожиданным для получателя способом.
Плевок против ветра: создание скелета маршрутизатора в пространстве пользователя
Для достижения полной универсальности недостаточно просто полагаться на инструментальные средства уровня командной строки. Необходима программа. Но слишком большая программа может оказаться неудобной для использования. Зачастую функциональные возможности слишком большой программы никогда не бывают использованы полностью, из-за того что в них широко используются встроенные возможности специфических компонент ядра. К тому же необходимое количество функциональных возможностей вряд ли можно элегантно реализовать из-за невозможности совместить их в рамках одного интерфейса. Особенно когда это касается универсальных, в полном смысле этого слова, сетевых решений. Искусно настроенные сетевые средства, встроенные в современные ядра систем, непригодны для целей спуфинга. Прежде всего создателей систем спуфинга интересуют системы, которые не столько строго следуют общеизвестным правилам, сколько нарушают их.
Это – ошибкоустойчивость наоборот.
Что действительно необходимо, так это простая инфраструктура, с помощью которой можно получить доступ к произвольным пакетам, возможно с использованием, но лучше без использования фильтрации пакетов на уровне ядра. Кроме того, она должна обеспечивать эффективную и достаточно легкую обработку пакетов с последующей отсылкой, если это необходимо, их обратно. Возможным решением поставленной проблемы является программа 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 мс. Оба показателя могут быть улучшены при помощи незначительного упрощения кода.
Данный текст является ознакомительным фрагментом.