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

memcpy(arp->ar_tha, arp->ar_sha, ETHER_ADDR_LEN); memcpy(arp->ar_sha, user_mac, ETHER_ADDR_LEN);

Ах, акронимы! Какой замечательный способ начинать день! ARP-акронимы на самом деле не слишком плохи – tha и sha не означают ничего больше, кроме как «адрес хоста получателя» и «адрес хоста отправителя». В копировании на месте важно то, что это точный эквивалент только что сделанного на уровне Ethernet: «Отправитель ARP в поле user_mac информирует ARP-получателя, кто послал ARP запрос последним». Автор надеется, что читатель не удивится избыточности протокола:

arp->ar_op = htons(ARPOP_REPLY);

memcpy(test_ip, arp->ar_spa, IPV4_ADDR_LEN);

memcpy(arp->ar_spa, arp->ar_tpa, IPV4_ADDR_LEN);

Наконец, после преобразования пакета из формата запроса в формат ответа была выполнена замена IP-адресов. В рассматриваемом случае замена выполнена при помощи использования не требующей особого пояснения временной переменной. (Команда XOR тоже сгодилась бы, но автор ленив, а читатель должен был это понять.) После всех манипуляций был получен разумно законченный и правильный вариант ответа на ARP-запрос, который отправляется с инвертированными IP-адресами, ARP-адресами аппаратных средств и правильными характеристиками Ethernet-пакета. Бум, сделано:

i = libnet_write_link_layer(l, dev, packet, pkthdr.caplen);

if (verbose)

Структура pkthdr полезна. Фактически это небольшая коллекция метаданных в момент их захвата. Они все потребуются для дальнейшей обработки. Элемент структуры caplen хранит длину захваченных данных. Он полностью подходит для функции установления связи и записи данных, которая нуждается в счетчике числа предполагаемых для отправки байтов. Поскольку при модификации пакетов situ длина их данных в общем случае не будет изменяться (хотя такое и могло произойти), знание оригинальной длины пакета позволяет узнать точное количество отосланных обратно данных. Также поможет и то, что рассматривается протокол с фиксированным размером пакетов, как, например, FTP, а не протокол с пакетами переменной длины, как, например, DNS:

/* Handle ARP replies (responding with upstream IP) */

} else if (eth->ether_type == ntohs(ETHERTYPE_ARP) &&

arp->ar_op == htons(ARPOP_REPLY) &&

Ниже представлен тот же самый процесс, что и при прослушивании запросов ARPOP_REQUEST, только теперь осуществляется проверка полей ARPOP_REPLY:

memcpy(upstream_mac, arp->ar_sha, ETHER_ADDR_LEN);

if (verbose)

fprintf(stdout, “Router Found: %hu.%hu.%hu.%hu at

%X:%X:%X:%X:%X:%X\n”,

upstream_ip[0], upstream_ip[1], upstream_ip[2],

upstream_ip[3],

upstream_mac[0], upstream_mac[1], upstream_mac[2],

Помните путь назад, когда был отослан ARP-запрос на поиск нашего маршрутизатора? Ниже показано, как обработать ответ. Следует взять предложенный MAC-адрес, запомнить его в буфере upstream_mac, копируя его из данных, на которые указывает указатель arp->ar_sha. И все, сделано. Отметим, что в действительности такой подход, когда не учитываются состояния программы (обработка без памяти), уязвим к атакам спуфинга. В любое время злоумышленник может безнаказанно послать в адрес программы незатребованный ответ на ARP-запрос, для того чтобы он был использован для обновления величины upstream_mac. Для борьбы с этим есть неплохие способы, например для предотвращения обновления соединения можно использовать триггерную переменную, для реагирования на вышедшие из строя сайты – предусмотреть монитор маршрутизатора и т. д., но рассмотрение подобных способов выходит за рамки этой главы:

/* Handle ICMP ECHO (Ping) */

} else if (!memcmp(eth->ether_dhost, user_mac,

ETHER_ADDR_LEN) &&

ntohs(eth->ether_type) == ETHERTYPE_IP &&

memcmp((u_char *) & ip->ip_dst, user_ip,

IPV4_ADDR_LEN) &&

ip->ip_p == IPPROTO_ICMP &&

Ах, утилита ping! Как автор по тебе тоскует! Без всякого сомнения, это лучшее средство определения, в каком режиме работает хост: в сети или автономно. Пытаясь достичь хоста, утилита не ищет сведений о нем в ARP-кэше. В процессе работы утилита отображает результат обработки текущих запросов. Фактически утилита ping является эхо-сигналом подканала ICMP протокола IP, направленного к адресуемому хосту с параметром IP ethertype и верным аппаратным адресом. Для того чтобы удостовериться в том, что полученный пакет является пакетом утилиты ping, проверяются пять условий. Несколько необычный способ принятия решения используется для проверки протокола IP, но он работает:

/* Swap Source and Destination MAC addresses */

memcpy(test_mac, eth->ether_dhost, ETHER_ADDR_LEN);

memcpy(eth->ether_dhost, eth->ether_shost, ETHER_ADDR_LEN);

Алиса посылает пакет Бобу… Боб отвечает Алисе пакетом с инвертированными значениями полей. Все, что делается в приведенном ниже примере, – это инвертирование значений полей отправителя и получателя, для того чтобы сформировать ответ:

/* Swap Source and Destination IP addresses */

test_ipa = ip->ip_dst;

ip->ip_dst = ip->ip_src;

То же самое, что было сделано для MAC-адресов, теперь делается на сетевом уровне для IP-адресов:

/*

* Change the packet to a reply, and decrement time

* to live

*/

icmp->icmp_type = ICMP_ECHOREPLY;

Системы, подверженные какому-либо риску зациклиться при маршрутизации, с каждым «прыжком» должны уменьшать счетчик предписанного времени жизни пересылаемого пакета TTL. Это общее правило. Если этого не сделать, то можно получить довольно странные результаты из-за существования риска бесконечной циклической маршрутизации данных. Кроме того, уменьшение значения TTL позволяет избежать усиления действия циклов обратной связи, губительных для сетей. В приведенном ниже примере пакеты с нулевым значением величины TTL не удаляются. Автор привел нижерасположенный фрагмент кода для того, чтобы читатель лучше понял суть дела:

/* Recalculate IP and TCP/UDP/ICMP checksums */

libnet_do_checksum(packet + LIBNET_ETH_H, IPPROTO_IP,

LIBNET_IP_H);

libnet_do_checksum(packet + LIBNET_ETH_H, IPPROTO_ICMP,

Поскольку данные пакета были модифицированы (было уменьшено значение предписанного времени жизни пересылаемого пакета TTL), то следует откорректировать контрольные суммы, гарантируя тем самым целостность пакета при воздействии на него шума, помех или чего-то еще. Способ формирования контрольных сумм применяется на транспортном уровне (протоколы TCP/UDP/ICMP), который обеспечивает доставку между конечными точками сети. Контрольные суммы обычно применяются в протоколе ICMP. Для протоколов TCP и UDP метод контрольных сумм не применяется из-за сложностей успешного его применения в протоколе IP. В данном примере использование контрольной суммы рассматривается только для примера. В реальных условиях приведенный алгоритм маршрутизации работает гораздо лучше. При вызове алгоритма маршрутизации для указания длины обрабатываемых данных используется поле ip->ip_len, что, возможно, приводит к уязвимости этого способа к некоторым типам атак (из-за излишнего доверия к значению переменной, представляющей фактическую длину полного набора данных). Так что будьте внимательны: