2.7.1. Методы и инструменты

Для достижения своих целей злоумышленник использует прослушивание (sniffing), сканирование сети и генерацию пакетов. Под генерацией пакетов понимается создание и отправка специально сконструированных датаграмм или кадров, позволяющих злоумышленнику выполнить ту или иную атаку. Особо выделим здесь фальсификацию пакетов, то есть создание IP-датаграмм или кадров уровня доступа к сети, направленных якобы от другого узла (spoofing).

2.7.1.1. Прослушивание сети

Прослушивание сети Ethernet (а подавляющее большинство локальных сетей используют именно эту технологию) является тривиальной задачей: для этого нужно просто перевести интерфейс в режим прослушивания (promiscuous mode). Легко доступны программы, не только записывающие весь трафик в сегменте Ethernet, но и выполняющие его отбор по установленным критериям: например, программа tcpdump или входящая в поставку ОС Solaris программа snoop.

Среди других сетевых технологий подвержены прослушиванию сети FDDI и радиосети (например Radio Еthernet). Несколько сложнее для злоумышленника извлечь трафик из телефонных выделенных и коммутируемых линий – главным образом, из-за сложности физического доступа и подключения к таким линиям1. Однако следует помнить, что злоумышленник может оккупировать промежуточный маршрутизатор и таким образом получить доступ ко всему транзитному трафику, независимо от используемых технологий на уровне доступа к сети.

Ограничить область прослушивания в сети Ethernet можно разбиением сети на сегменты с помощью коммутаторов2. В этом случае злоумышленник, не прибегая к активным действиям, описанным в п. 2.7.2, может перехватить только кадры, получаемые или отправляемые узлами сегмента, к которому он подключен. Единственным способом борьбы с прослушиванием сегмента Ethernet является шифрование данных.

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

AntiSniff выполняет три вида тестов узлов сегмента Ethernet. Первый тест основан на особенностях обработки разными операционными системами кадров Ethernet, содержащих IP-датаграммы, направленные в адрес тестируемого узла. Например, некоторые ОС, находясь в режиме прослушивания, передают датаграмму уровню IP, независимо от адреса назначения кадра Ethernet (в то время как в обычном режиме кадры, не направленные на MAC-адрес узла, системой вообще не рассматриваются). Другие системы имеют особенность при обработке кадров с широковещательным адресом: в режиме прослушивания MAC-адрес ff:00:00:00:00:00 воспринимается драйвером интерфейса как широковещательный. Таким образом, послав сообщение ICMP Echo внутри «неверного» кадра, который при нормальных обстоятельствах должен быть проигнорирован, и получив на него ответ, AntiSniff заключает, что интерфейс тестируемого узла находится в режиме прослушивания.

Второй тест основан на предположении, что программа прослушивания на хосте злоумышленника выполняет обратные DNS-преобразования1 для IP-адресов подслушанных датаграмм (поскольку часто по доменному имени можно определить назначение и важность того или иного узла). AntiSniff фабрикует датаграммы с фиктивными IP-адресами (то есть не предназначенные ни одному из узлов тестируемой сети), после чего прослушивает сеть на предмет DNS-запросов о доменных именах для этих фиктивных адресов. Узлы, отправившие такие запросы, находятся в режиме прослушивания.

Тесты третьей группы, наиболее универсальные, с одной стороны, так как не зависят ни от типа операционной системы, ни от предполагаемого поведения прослушивающих программ. С другой стороны, эти тесты требуют определенного анализа от оператора, то есть – не выдают однозначный результат, как в двух предыдущих случаях кроме того, они сильно загружают сеть. Тесты основаны на том, что интерфейс, находящийся в обычном режиме, отфильтровывает кадры, направленные не на его адрес, с помощью программно-аппаратного обеспечения сетевой карты, и не задействует при этом ресурсы операционной системы. Однако в режиме прослушивания обработка всех кадров ложится на программное обеспечение злоумышленника, то есть, в конечном счете, на операционную систему. AntiSniff производит пробное тестирование узлов сети на предмет времени отклика на сообщения ICMP Echo, после чего порождает в сегменте шквал кадров, направленных на несуществующие MAC-адреса, при этом продолжая измерение времени отклика. У систем, находящихся в обычном режиме, это время растет, но незначительно, в то время как узлы, переведенные в режим прослушивания, демонстрируют многократный (до 4 раз) рост задержки отклика.

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

2.7.1.2. Сканирование сети

Сканирование сети имеет своей целью выявление подключенных к сети компьютеров и определение работающих на них сетевых сервисов (открытых портов TCP или UDP). Первая задача выполняется посылкой ICMP-сообщений Echo с помощью программы ping с последовательным перебором адресов узлов в сети. Сто2ит попробовать отправить Echo-сообщение по широковещательному адресу – на него ответят все компьютеры, поддерживающие обработку таких сообщений1.

Администратор сети может обнаружить попытки сканирования путем анализа трафика в сети и отслеживания Echo-сообщений, за короткий промежуток времени посылаемых последовательно по всем адресам сети. Для большей скрытности злоумышленник может существенно растянуть процесс во времени («медленное сканирование») – это же касается и сканирования портов TCP/UDP. Также злоумышленник может применить «обратное сканирование» (inverse mapping): в этом случае на тестируемые адреса посылаются не сообщения ICMP Echo, а другие сообщения, например RST-сегменты TCP, ответы на несуществующие DNS-запросы и т. п. Если тестируемый узел не существует (выключен), злоумышленник получит в ответ ICMP-сообщение Destination Unreachable: Host Unreachable.

Следовательно, если сообщение не было получено, то соответствующий узел подключен к сети и работает.

Программа traceroute1 поможет в определении топологии сети и обнаружении маршрутизаторов2.

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

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

Сканирование в режиме половинного открытия (half-open scanning) не имеет описанного недостатка, но требует от злоумышленника возможности формировать одиночные TCP-сегменты в обход стандартного модуля TCP (или, при использовании уже написанных программ, как минимум – прав суперпользователя). В этом режиме злоумышленник направляет на сканируемый порт SYN-сегмент и ожидает ответа. Получение ответного сегмента с битами SYN и ACK означает, что порт открыт; получение сегмента с битом RST означает, что порт закрыт. Получив SYN+ACK, злоумышленник немедленно отправляет на обнаруженный порт сегмент с битом RST, таким образом ликвидируя попытку соединения. Так как соединение так и не было открыто (ACK от злоумышленника не был получен), то зарегистрировать такое сканирование гораздо сложнее.

Третий способ – сканирование с помощью FIN-сегментов. В этом случае на сканируемый порт посылается сегмент с установленным битом FIN. Хост должен ответить RST-сегментом, если FIN-сегмент адресован закрытому порту. FIN-сегменты, направленные на порт, находящийся в состоянии LISTEN, многими реализациями TCP/IP игнорируются (стандарт требует в состоянии LISTEN посылать RST-сегменты в ответ на сегменты, имеющие неприемлемый ACK SN; про сегменты, имеющие только флаг FIN, ничего не говорится). Таким образом, отсутствие отклика говорит о том, что порт открыт. Варианты этого способа сканирования – посылка сегментов с флагами FIN, PSH, URG («Xmas scan») или вообще без всяких флагов («Null scan»).

Конечно, сканирование SYN-сегментами дает более надежные результаты, однако, к счастью, многие брандмауэры могут не пропускать SYN-сегменты без флага ACK из Интернета во внутреннюю сеть1 (так, запрещаются соединения хостов Интернета с внутренними хостами, инициируемые из Интернета, но разрешаются соединения, инициируемые изнутри).

Программа tcplogd может зарегистрировать попытки сканирования в различных режимах.

Для определения открытых портов UDP злоумышленник может отправить на тестируемый порт UDP-сообщение. Получение в ответ ICMP-сообщения Port Unreachable (тип 3, код 3) говорит о том, что порт закрыт.

Программа-сканер может также определить операционную систему сканируемого узла по тому, как узел реагирует на специальным образом сконструированные, нестандартные пакеты: например, TCP-сегменты с бессмысленными сочетаниями флагов или ICMP-сообщения некоторых типов, и по другим признакам.

В марте 2001 г. в списке рассылки Bugtraq шла оживленная дискуссия об опции TCP Timestamp (Временной штамп) [McDanel]. У многих систем часы модуля TCP, чьи показания помещаются в опцию Timestamp, связаны с системными часами, что позволяет по значению опции определить uptime – время, прошедшее с момента загрузки компьютера. Эта информация может представлять потенциальную угрозу для безопасности компьютера в следующих аспектах.

Однако возможность выполнения реальных атак с использованием значения uptime пока остается под вопросом.

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

2.7.1.3. Генерация пакетов

Генерация датаграмм или кадров произвольного формата и содержания производится не менее просто, чем прослушивание сети Ethernet. Библиотека libnet обеспечит программиста всем необходимым для решения этой задачи. Библиотека libpcap предоставляет инструментарий для обратного действия – извлечения пакетов из сети и их анализа.

На многочисленных сайтах Интернета злоумышленник может найти уже готовые программы, генерирующие пакеты целенаправленно для выполнения какой-либо атаки или сканирования сети (например, программа nmap, упомянутая выше). Применение таких программ часто не требует от злоумышленника ни квалификации программиста, ни понимания принципов работы сети1, что делает многие из описанных атак, особенно атаки типа «отказ в обслуживании», широко доступными для исполнения.

2.7.1.4. Полезные утилиты

ping

% ping 1.16.195.84

Программа ping (Windows, UNIX) посылает по указанному адресу эхо-запросы ICMP и принимает эхо-ответы, вычисляя при этом время оборота пакета. При прерывании программы выводится статистика: среднее время оборота пакета и процент потерянных пакетов. (Для вывода статистики в ОС Solaris ping следует запускать с ключом –s.)

traceroute

% traceroute 1.16.195.84

Программа traceroute (Windows – tracert) выводит список промежуточных узлов сети на маршруте от данного узла к указанному. Принцип работы программы следующий: к указанному узлу отправляется датаграмма с TTL=1. Первый маршрутизатор вычитает единицу из TTL, и обнаруживает, что TTL=0. Датаграмма уничтожается, а отправителю посылается ICMP-сообщение Destination Unreachable: TTL exceeded. Программа traceroute выводит адрес отправителя этого сообщения в качестве первого узла маршрута. Потом процедура повторяется с TTL=2, и таким образом обнаруживается второй маршрутизатор – и так далее. Для надежности программа отправляет по три датаграммы с каждым значением TTL. По умолчанию traceroute пытается по полученному IP-адресу определить доменное имя каждого пункта маршрута, это вносит задержку в работу программы. Для отключения этого режима traceroute нужно запустить с ключом –n (Windows – tracert –d).

arp

Программа arp (Windows, UNIX) позволяет получить доступ к таблице протокола ARP. Основные режимы:

показать всю arp-таблицу:

% arp -a 

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

% arp -d IP-адрес

внести вручную Ethernet-адрес для указанного IP-адреса:

% arp -s IP-адрес адрес_ethernet

whois

Программа whois производит запрос Интернет-регистратуры об административной (организационной) принадлежности указанного IP-адреса, автономной системы и т. д.

Solaris:

% whois -h сервер_регистратуры предмет_запроса

% whois -h whois.ripe.net 193.124.169.0

% whois -h whois.ripe.net AS12332

Linux:

% whois предмет_запроса@сервер_регистратуры

% whois 193.124.169.0@whois.ripe.net

% whois AS12332@whois.ripe.net

FreeBSD:

% whois –h сервер_регистратуры предмет_запроса

Для направления запросов к регистратурам Интернета в версии FreeBSD whois есть специальные ключи, устраняющие необходимость ввода имени регистратуры. Например, для запросов RIPE:

% whois –r 193.124.169.0@whois.ripe.net

% whois –r AS12332

Адреса whois-серверов регистратур: для Европы и России – whois. ripe.net, для Америки – whois.arin.net, Азии – whois.apnic.net.

nslookup

% nslookup ns.exmpl.ru

% nslookup 212.91.220.172

Программа nslookup производит преобразование имени DNS в IP-адрес и обратно. Подробнее об этой программе см. п. 3.2.5.

2.7.2. Перехват данных

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

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

2.7.2.1. Ложные ARP-ответы

Для перехвата трафика между узлами А и В, расположенными в одной IP-сети, злоумышленник использует протокол ARP (п. 2.2.7). Он рассылает сфальсифицированные ARP-сообщения так, что каждый из атакуемых узлов считает MAC-адрес злоумышленника адресом своего собеседника (рис. 2.78).

Рис. 2.78. Схема ARP-атаки

План атаки:

1. Злоумышленник определяет MAC-адреса узлов А и В:

% ping IP(A); ping IP(B); arp –a

2. Злоумышленник конфигурирует дополнительные логические IP-интерфейсы на своем компьютере, присвоив им адреса А и В и отключив протокол ARP для этих интерфейсов, чтобы их не было «слышно» в сети, например:

# ifconfig hme0:1 inet IP(A) –arp
# ifconfig hme0:2 inet IP(B) –arp

Затем он устанавливает статическую ARP-таблицу:

# arp –s IP(A) MAC(A)
# arp –s IP(B) MAC(B)
и разрешает ретрансляцию IP-датаграмм (переводит компьютер в режим маршрутизатора).

3. Злоумышленник отправляет на МАC-адрес узла А кадр со сфабрикованным ARP-ответом, в котором сообщается, что IP адресу В соответствует MAC-адрес Х. Аналогично узлу В сообщается, что IP адресу А соответствует тот же MAC-адрес Х (рис. 2.78). Для формирования сообщений можно использовать библиотеку libnet. Так как ARP – протокол без сохранения состояния, то узлы А и В примут ARP-ответы, даже если они не посылали запросов. Далее злоумышленник периодически (достаточно это делать раз в 20-40 секунд) повторяет посылку сфальсифицированных ARP-ответов для обновления сфабрикованных записей в ARP-таблицах узлов А и В, чтобы удерживать эти узлы в неведении относительно истинных адресов и не дать им сформировать соответствующие ARP-запросы.

4. Введенные в заблуждение узлы А и В пересылают свой трафик через узел Х, полагая, что сообщаются друг с другом непосредственно. Злоумышленник может просто прослушивать трафик или изменять передаваемые данные в своих интересах.

Узел В может быть шлюзом сети, в которой находится узел А. В этом случае злоумышленник может перехватывать весь трафик между узлом А и Интернетом.

Также злоумышленник может вообще не передавать кадры узла А узлу В, а выдавать себя за узел В, фабрикуя ответы от его имени и отсылая их в А (см. также п. 2.7.3).

Разделение сети на сегменты с помощью коммутаторов, очевидно, не является препятствием для описанной ARP-атаки.

Отметим, что в сфабрикованных ARP-ответах злоумышленник может вместо своего MAC-адреса указать несуществующий адрес Ethernet. Впоследствии он может извлекать из сети кадры, направленные на этот адрес путем прослушивания сети или перепрограммирования MAC-адреса своей сетевой карты. Это потребует несколько бо2льших усилий, но взамен злоумышленник сможет практически полностью замести следы, поскольку его собственный MAC-адрес уже нигде не фигурирует.

Для обнаружения ARP-атак администратор должен вести базу данных соответствия MAC- и IP-адресов всех узлов сети и использовать программу arpwatch, которая прослушивает сеть и уведомляет администратора о замеченных нарушениях. Если сеть разделена на сегменты коммутаторами, то администратор должен настроить их таким образом, чтобы в сегмент, где находится станция администратора, перенаправлялись кадры из всех сегментов сети вне зависимости от того, кому они предназначены.

Использование статических ARP-таблиц, по крайней мере – на ключевых узлах (серверах, маршрутизаторах), защитит их от ARP-атаки, правда, за счет накладных расходов на поддержку этих таблиц в актуальном состоянии.

Пользователю на атакуемом хосте, не снабженном статической ARP-таблицей, крайне сложно заметить, что он подвергся ARP-атаке, поскольку представляется маловероятным, что пользователь помнит MAC-адреса других узлов своей сети и периодически проверяет ARP-таблицу своего компьютера. Возможно, что операционная система отслеживает изменения в ARP-таблице и вносит в лог-файл записи вида «arp info for 0x11223344 overwritten by 01:02:03:04:05:06», однако, в общем случае, для отслеживания ARP-атак следует полагаться на администратора сети и программу arpwatch.

2.7.2.2. Навязывание ложного маршрутизатора

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

Ложное сообщение ICMP Redirect

Как правило, навязывание ложного маршрутизатора выполняется с помощью фальсифицированных ICMP-сообщений Redirect, так как документ RFC-1122 требует, чтобы хосты обязательно обрабатывали такие сообщения. В подложном сообщении злоумышленник объявляет свой собственный адрес в качестве адреса маршрутизатора (рис. 2.79).

Рис. 2.79. Навязывание ложного маршрутизатора с помощью ICMP Redirect

Напомним действия хоста А при получении сообщения Redirect. Хост А считает, что Redirect является реакцией на ранее отправленную датаграмму некому хосту В, причем заголовок и первые 64 бита этой датаграммы возвращаются внутри полученного сообщения. Из возвращенного заголовка хост А определяет, что он должен сделать перенаправление для датаграмм, направленных в В, и вносит в свою таблицу маршрутов частный маршрут к хосту В через маршрутизатор, указанный в сообщении Redirect. Следует обратить внимание, что все сообщения Redirect обрабатываются одинаково независимо от кода сообщения – таким образом, посылка Redirect с кодом 0 («перенаправление для сети получателя») не вызовет изменения маршрута в сеть, в которой находится получатель, а приведет к установке частного маршрута к хосту В, как и в случае сообщения с кодом 1.

Сообщение Redirect должно быть отправлено маршрутизатором, который в таблице маршрутов хоста А является следующим маршрутизатором на пути в В, при этом хост В не должен находиться в той же IP-сети, что и А, а новый объявленный маршрутизатор Х, наоборот, обязан находиться в одной IP-сети с хостом А.

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

Отметим, что трафик из В в А будет по-прежнему направляться маршрутизатором непосредственно хосту А, минуя злоумышленника (рис. 2.79), потому что маршрутизатор и хост А находятся в одной сети, следовательно, маршрутизатор в принципе не может использовать никаких промежуточных узлов для достижения хоста А.

Несмотря на такой «половинчатый» перехват, злоумышленник может просматривать и модифицировать данные, направляемые из А в В, а если он находится в одном сегменте с хостом А или маршрутизатором, то и наблюдать за ответами узла В, направляемыми в А. Более того, злоумышленник может вообще не пересылать датаграммы в узел В, а отвечать на них сам, фабрикуя датаграммы от имени узла В (см. также п. 2.7.3).

Для устранения возможности описываемой атаки необходимо отключить на хосте обработку сообщений Redirect. Несмотря на то, что это действие противоречит требованиям к хостам, установленным в документе RFC-1122, оно выглядит совершенно разумным, особенно для хостов в сетях с единственным шлюзом, однако не все операционные системы могут поддерживать такое отключение.

Вообще говоря, для пользователя атакуемого узла не составит особого труда раскрыть замысел злоумышленника: полученное сообщение Redirect отобразится в виде неожиданно появившейся строки в таблице маршрутов, направляющей данные для хоста В через узел Х1. Кроме того, программа traceroute скорее всего покажет дополнительный промежуточный узел на пути к В. К сожалению пользователи обычно не заглядывают в таблицу маршрутов и не запускают traceroute, если поведение сетевых программ не вызывает у них подозрений, поэтому злоумышленник имеет хорошие шансы остаться незамеченным.

Атака при конфигурировании хоста

В некоторых случаях навязывание ложного маршрутизатора может быть произведено с помощью ICMP-сообщения Router Advertisement или через протокол DHCP.

Сообщения Router Advertisement могут использоваться хостами для установки маршрута по умолчанию, однако в реальной жизни такое происходит нечасто, так как для удаленного динамического конфигурирования стека TCP/IP хоста обычно используется протокол DHCP. Если же хост все-таки обрабатывает сообщения Router Advertisement, то сформировав подложное сообщение, злоумышленник может перенаправить на себя весь трафик хоста А, адресованный за пределы его сети, а не только трафик, адресованный узлу В. Как и в предыдущем случае, данные на обратном пути будут доставляться маршрутизатором на хост А непосредственно, минуя злоумышленника.

Фальсификация сообщений протокола DHCP будет успешна, если хост конфигурирует себя через этот протокол. В ответ на запрос DHCPDISCOVER злоумышленник оперативно возвращает хосту подложное сообщение DHCPOFFER, где в числе дополнительных параметров указывает себя в качестве маршрутизатора по умолчанию. Чтобы опередить предложение от легитимного сервера, злоумышленник может рассылать DHCPOFFER непрерывно, чтобы сделавший запрос хост получил предложение немедленно. В этом случае также происходит «половинчатый» перехват.

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

Атака на протоколы маршрутизации

Если злоумышленник хочет перехватить трафик между узлами сети Р и узлами сети Q, и при этом не находится ни в одной из сетей P или Q, но расположен на пути между ними, он может попытаться ввести в заблуждение маршрутизаторы. Маршрутизаторы не реагируют на сообщения ICMP Redirect, поэтому для успешной атаки необходимо, чтобы они использовали какой-либо протокол маршрутизации. В этом случае злоумышленник может сформировать подложные сообщения протокола маршрутизации с целью переключения требуемых маршрутов на себя. Например (рис. 2.80) узел Х, приняв широковещательные RIP-сообщения, рассылаемые узлами А (вектор P=3) и В (вектор Q=2), отправляет сообщение с вектором Q=1 на индивидуальный адрес маршрутизатора А, а сообщение P=2 – на индивидуальный адрес В.

Рис. 2.80. Навязывание ложного RIP-маршрутизатора X
для перехвата трафика между сетями P и Q

Возможна ситуация, когда значение вектора, объявляемого, например, маршрутизатором В: Q=1. В этом случае Х не может немедленно предложить лучшего маршрута, но он может применить следующий прием. Сначала, выбрав паузу в рассылке RIP-сообщений маршрутизатором В, Х от имени В отправляет в А вектор Q=16, что заставит маршрутизатор А удалить из своей таблицы маршрут в сеть Q, так как до этого А отправлял датаграммы в Q через В. Сразу же вслед за этим Х отправляет вектор Q=1 от своего имени, и А устанавливает маршрут в сеть Q через Х. Последующие векторы Q=1 от В будут проигнорированы, поскольку они не предлагают лучшего маршрута.

IBGP-соседи для пересылки датаграмм друг другу могут пользоваться результатами работы внутреннего протокола маршрутизации, злоумышленник может предварительно атаковать протокол внутренней маршрутизации, замкнув на себя трафик между сетями, в которых находятся BGP-маршрутизаторы (например, это сети P и Q на рис. 2.80) и модифицируя данные BGP-соединения в своих целях.

Конечно, атака на протокол BGP выглядит трудноосуществимой, но, тем не менее, такие атаки возможны. Аутентификация TCP-сегментов с помощью алгоритма MD5 поможет избежать неприятностей.

2.7.3. Имперсонация

Предположим, что узел А обменивается IP-датаграммами с узлом В, при этом узлы идентифицируют друг друга по IP-адресам, указываемым в датаграммах. Предположим далее, что узел В имеет особые привилегии при взаимодействии с А: то есть А предоставляет В некоторый сервис, недоступный для других хостов Интернета. Злоумышленник на узле Х, желающий получить такой сервис, должен имитировать узел В – такие действия называются имперсонацией узла В узлом Х.

Говоря о сервисах, мы имеем в виду приложения UDP или TCP, то есть речь идет об имперсонации UDP-сообщений или TCP-соединений1. Часто одновременно с имперсонацией злоумышленник предпринимает атаки типа «отказ в обслуживании» (п. 2.7.7) против узла В для исключения последнего из процесса сетевого взаимодействия.

Хосты А, В и Х могут располагаться друг относительно друга различным образом, от этого зависит, какие методы имперсонации применит злоумышленник.

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

Напомним, что перехват трафика возможен, когда:
1) А, В и Х находятся в одной IP-сети (ARP-атака);
2) А и Х находятся в одной сети, а В – в другой (навязывание ложного маршрутизатора);
3) А и В находятся в разных сетях, а Х находится на пути между ними (или включает себя в маршрут путем атаки на протокол маршрутизации).

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

2.7.3.1. Имперсонация без обратной связи

Рассмотрим самый сложный случай: перехват и прослушивание данных, отправляемых из А в В невозможны. Этот случай (рис. 2.81) является наиболее общим: узел Х находится в сети, не имеющей никакого отношения к узлам А и В и не лежащей между ними (А и В могут находиться как в одной, так и в разных сетях).

Рис. 2.81. Имперсонация без обратной связи

Подчеркнем, что имперсонация без обратной связи имеет смысл лишь тогда, когда злоумышленнику для достижения своей цели достаточно только передать данные на узел А от имени узла В, и последующий ответ узла А уже не имеет значения. Классическим примером такой атаки является отправка злоумышленником на порт сервера Rlogin TCP-сегмента, содержащего какую-либо команду операционной системе узла А (о протоколе Rlogin см. п. 3.3.2). Узел А выполняет эту команду, полагая, что она поступила с узла В.

Если имперсонация UDP-сообщений без обратной связи остается тривиальной, злоумышленник должен только сфабриковать датаграмму, адресованную от узла В узлу А, и отправить ее по назначению, то в случае с TCP все обстоит не так просто. Прежде чем отправить узлу А сегмент с данными, узел Х должен установить с ним соединение от имени узла В. Напомним, как происходит установление соединения: узел Х от имени В отправляет в А сегмент с битом SYN, где указывает начальный номер ISN(В). Узел А отвечает узлу В SYN-сегментом, в котором подтверждает получение предыдущего сегмента, и устанавливает свой начальный номер ISN(A). Этот сегмент злоумышленник никогда не получит.

Здесь возникает две проблемы: во-первых, узел В, получив от А ответ на SYN-сегмент, который он никогда не посылал, отправит узлу А сегмент с битом RST, тем самым сводя к нулю усилия злоумышленника. Во-вторых, узел Х все равно не сможет отправить в А следующий сегмент (как раз это должен быть сегмент с данными), потому что в этом сегменте узел Х должен подтвердить получение SYN-сегмента от А, то есть поместить в поле ACK SN заголовка своего сегмента значение ISN(A)+1. Но злоумышленник не знает номера ISN(A), потому что соответствующий сегмент ушел к узлу В.

Первая проблема решается относительно просто: злоумышленник проводит против узла В атаку типа «отказ в обслуживании» с тем расчетом, чтобы узел В не был способен обрабатывать сегменты, приходящие из А. Например, можно поразить узел В шквалом SYN-сегментов от несуществующих узлов1 (подробнее об отказах в обслуживании см. п. 2.7.7). Впрочем, к облегчению злоумышленника, может оказаться, что узел В просто выключен.

Для решения второй проблемы злоумышленник должен уметь предсказывать значения ISN(A). Если операционная система узла А использует какую-либо функцию для генерации значений ISN (например, линейную зависимость от показания системных часов), то последовательно открыв несколько пробных соединений с узлом А и проанализировав присылаемые в SYN-сегментах от А значения ISN, злоумышленник может попытаться установить эту зависимость опытным путем.

Хорошая реализация TCP должна использовать случайные числа для значений ISN (более подробное обсуждение этого вопроса можно найти в RFC-1948). Несмотря на кажущуюся простоту этого требования, проблема с угадыванием номеров ISN остается актуальной и по сей день1.

Итак, приведем схему атаки для имперсонации TCP-соединения без обратной связи (рис. 2.82).

Рис. 2.82. Схема атаки с имперсонацией TCP-соединения без обратной связи

1. Злоумышленник выводит из строя узел В.

2. Злоумышленник делает несколько пробных попыток установить соединения с узлом А с целью получить от А последовательность

2.7.3.2. Десинхронизация TCP-соединения

Злоумышленник Х, находящийся в одном сегменте сети с узлами А и В или на пути между А и В, может произвести десинхронизацию TCP-соединения между А и В для установления полного контроля над соединением, то есть, злоумышленник получит возможность действовать как от имени А, так и от имени В1. Впервые эта атака была описана в [Joncheray].

Определим, что такое десинхронизация TCP-соединения. При установленном соединении каждый из узлов А и В знает, октеты с какими номерами может прислать ему собеседник в данный момент: если последнее подтверждение, высланное узлом А, было ACKARB и при этом узел А объявил окно WARB, то А ожидает от В октетов с номерами SNBRA, попадающими в объявленное окно, то есть:

ACKARB ? SNBRA ? ACKARB + WARB
Аналогично в узле В ожидается от А:
ACKBRA ? SNARB ? ACKBRA + WBRA

Если, например, узел А по какой-то причине получает от В сегмент с номером SNBRA, не попадающим в окно, то этот сегмент уничтожается, а в ответ А отправляет в В сегмент с SNARB, ACKARB, WARB, чтобы указать узлу В, какие именно октеты ожидает получить А. Отметим, что скорее всего этот сегмент не содержит данных, но, как говорилось выше в п. 2.5.2, номер SNARB в этом сегменте тем не менее должен быть указан, где SNARB – номер следующего октета данных, который А когда-либо вышлет в В.

Предположим, злоумышленнику каким-то образом удалось сбить показатели счетчиков узлов А и (или) В так, что вышеприведенные неравенства больше не выполняются (как это можно сделать, мы обсудим ниже). Далее мы будем использовать обозначения вида SNАRВ(В), что означает «приемлемый SNАRВ с точки зрения В».

Теперь, если В посылает в А сегмент с неким номером SNBRA(В), адекватным с точки зрения В, но уже не попадающим в окно в узле А, то А возвращает узлу В подтверждение со своим значением ACKARB= =SNBRA(А). Однако в этом же сегменте имеется номер SNARB(А), который теперь уже В рассматривает как не попадающий в свое окно и отправляет в А подтверждение SNВRА(В), ACKВRА= SNARB(А). Номер SNBRA(В), как и раньше, неприемлем для А, и узел А вновь отправляет в В подтверждение, и этот цикл, называемый ACK-шторм, теоретически продолжается до бесконечности, а практически – до тех пор, пока один из ACK-сегментов не потеряется в сети1. Чем сильнее шторм, тем больше загрузка сети, тем выше процент потерь, следовательно, тем быстрее шторм прекратится.

Итак, в десинхронизированном состоянии любая попытка обмена данными вызывает только ACK-шторм, а сами сегменты с данными участниками соединения уничтожаются.

В это время злоумышленник, знающий «правильные» номера с точки зрения обоих узлов, берет на себя функции посредника (рис. 2.83). Он прослушивает сеть, обнаруживает сегмент с данными длиной L октетов, направленный, например, из А в В, меняет в нем номер SNARB(А) на ожидаемый узлом В номер SNARB(В) и, пересчитав контрольную сумму, отправляет сегмент в В от имени А. После этого в узел А от имени В злоумышленник отправляет подтверждение на этот сегмент, содержащее правильный с точки зрения А номер SNВRА(А). Во время этого обмена в виде побочного явления возникают два ACK-шторма: первый инициирует узел В, получивший из А оригинальный сегмент с SNARB(А) № SNARB(В), а второй шторм возникает, когда узел А получает от В сегмент, подтверждающий получение данных от Х, и в этом сегменте SNВRА(В) № SNВRА(А).

(L1, L2 – объем данных в пересылаемых сегментах)
Рис. 2.83. Действия злоумышленника-посредника
в десинхронизированном соединении между узлами А и В

Разумеется, злоумышленник затевает атаку не для того, чтобы просто ретранслировать сегменты, которые он и так может подслушать. Ничто не мешает ему изменять содержащиеся в сегментах данные или добавлять свои: на рис. 2.83 это отображено в виде «данных 2», имеющих длину L2 октетов, в то время как оригинальные данные обозначены «данные 1» длиной L1 октетов. Например, если имеет место сессия программы telnet и А посылает в В некоторую команду, то злоумышленник может вставить в этот сегмент еще одну команду. Результат выполнения своей команды он получит, подслушав ответный сегмент SNВRА(В), направленный из В в А, который узел А не воспримет из-за несовпадения порядковых номеров, так как SNВRА(В) № SNВRА(А). Зато злоумышленник, удалив из этого сегмента результат выполнения своей команды, отправит то, что осталось (то есть результат оригинальной команды) в А от имени В уже с приемлемым порядковым номером SNВRА(А).

Злоумышленник может вообще игнорировать сегменты, посылаемые узлом А и отправлять в В только свои данные, получая ответы прослушиванием сети и соответственно реагируя на них, но в этом случае узел А заметит, что В не отвечает на его команды, и может забеспокоиться.

Рассмотрим, каким образом злоумышленник может перевести TCP-соединение в десинхронизированное состояние.

Ранняя десинхронизация

Ранняя десинхронизация (рис. 2.84): злоумышленник, прослушивая сеть, обнаруживает момент установления соединения между А и В, от имени А сбрасывает соединение RST-сегментом и тут же открывает его заново, но уже с новыми номерами ISN. Разберем эту процедуру в деталях.

Сначала А посылает в В сегмент SYNАRВ, ISNАRВ(А), потом В отвечает сегментом SYNВRА, ISNВRА(1), ACKВRА(ISNАRВ(А)+1). По получении этого сегмента А переходит в состояние ESTABLISHED и посылает в В подтверждающий сегмент ACKАRВ(ISNВRА(1)+1).

В этот момент злоумышленник от имени А отправляет в В сегмент RSTАRВ и следом за ним сегмент SYNАRВ, ISNАRВ(X), содержащий те же номера портов, но другой номер ISNАRВ= ISNАRВ(X), неприемлемый для А.

При получении этих сегментов узел В закрывает установленное соединение с А, а затем тут же вновь отрывает его и отправляет в А сегмент SYNВRА, ISNВRА(2), ACKВRА(ISNАRВ(Х)+1), где ISNВRА(2) – новый начальный порядковый номер, ISNВRА(1) № ISNВRА(2).

Узел А не воспринимает этот сегмент из-за несовпадения порядковых номеров, но злоумышленник от имени А посылает в В сегмент SNАRВ=ISNАRВ(Х)+1, ACKАRВ(ISNВRА(2)+1).

Рис. 2.84. Ранняя десинхронизация TCP-соединения
(сегменты ACK-шторма не показаны)

После этого оба узла А и В находятся в состоянии ESTABLISHED, но соединение десинхронизировано (рис. 2.85).

Рис. 2.85. Состояние соединения после ранней десинхронизации

Отметим, что некоторые реализации TCP в нарушение стандарта в ответ на получение RST-сегмента сами отправляют RST-сегмент. В этом случае десинхронизация описанным способом невозможна.

Десинхронизация нулевыми данными

Десинхронизация нулевыми данными (рис. 2.86): злоумышленник, дожидаясь момента, когда соединение находится в неактивном состоянии (данные не передаются), посылает узлу А от имени В и узлу В от имени А фальсифицированные сегменты с данными, вызывая тем самым десинхронизацию. Посылаемые данные должны быть «нулевыми» – то есть приложение-получатель должно их молча игнорировать и не посылать никаких данных в ответ. Этот метод десинхронизации подходит для Telnet-соединений, которые, во-первых, часто находятся в неактивном состоянии, а во-вторых, в протоколе Telnet имеется команда «нет операции» (IAC NOP). Сегмент, содержащий произвольное число таких команд (IAC NOP IAC NOP :), будет принят приложением и полностью проигнорирован1.

Рис. 2.86. Десинхронизация TCP-соединения нулевыми данными
(сегменты ACK-шторма не показаны)

После описанной процедуры имеет место следующая ситуация, показанная на рис. 2.87.

Рис. 2.87. Состояние соединения после десинхронизации нулевыми данными

Имперсонация с помощью десинхронизации является сравнительно простой и очень эффективной атакой. Она позволяет злоумышленнику установить полный контроль над TCP-соединением без использования ложных сообщений ARP, ICMP или протоколов маршрутизации, без атак типа «отказ в обслуживании», которые могут быть обнаружены администратором сети или атакуемого узла. Обнаружить такие атаки можно, прослушивая сеть на предмет ACK-штормов.

Для защиты от описанных в этом пункте атак маршрутизатор (шлюз, брандмауэр), соединяющий сеть с внешним миром, должен быть настроен на запрет пропуска пакетов;

а) приходящих на внешний интерфейс, но имеющих адрес отправителя из внутренней сети;

б) приходящих на внутренний интерфейс, но имеющих адрес отправителя из внешней сети.

Случай а) соответствует ситуации, когда узлы А и В находятся во внутренней сети, а злоумышленник расположен снаружи и пытается послать узлу А датаграмму якобы от узла В. Случай б) соответствует ситуации, когда злоумышленник находится во внутренней сети, а узлы А и В – снаружи. Подчеркнем, что предложенные меры не защитят от всех разновидностей имперсонации: например, когда узел Х находится в одной сети с узлом А или В, или, естественно, когда все три узла расположены в одной сети.

Хороший алгоритм генерации случайных номеров ISN защитит от атаки в случае отсутствия обратной связи, но бесполезен, если злоумышленник может видеть сегменты, передаваемые из А в В.

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

2.7.4. Несанкционированное
подключение к сети

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

Прослушивание сети (сегмента сети) даст злоумышленнику много полезной информации. В частности, он может определить, какие IP-адреса имеют узлы сети, и с помощью ICMP Echo-запросов (программа ping) определить, какие адреса не используются (или компьютеры выключены). После этого злоумышленник может присвоить себе неиспользуемый адрес.

Найти IP-адрес маршрутизатора по умолчанию можно, подслушав кадры с датаграммами, направленными на IP-адреса, не принадлежащие сети. Эти кадры направлены на MAC-адрес маршрутизатора. Очевидно, что узлы сети время от времени генерируют ARP-запросы о MAC-адресе маршрутизатора; ответы на эти запросы, посылаемые маршрутизатором, содержат как его MAC-адрес, так и IP-адрес. Зная MAC-адрес маршрутизатора и подслушав такие ответы, злоумышленник определит искомый IP-адрес.

Для обнаружения маршрутизатора злоумышленник может использовать также сообщения ICMP Router Advertisement/Solicitation.

Для определения маски сети злоумышленник может послать на адрес маршрутизатора сообщение ICMP Address Mask Request. В ответ маршрутизатор должен выслать маску сети в сообщении Address Mask Reply.

Если маршрутизатор не поддерживает сообщения Address Mask Request/Reply, злоумышленник может применить следующий простой метод. Путем арифметических вычислений он определяет минимальную сеть, включающую его собственный адрес и найденный адрес маршрутизатора, и назначает себе маску этой сети. Например, пусть адрес, присвоенный злоумышленником, X=10.0.0.57, а адрес маршрутизатора G=10.0.0.1, то есть, расписывая последний октет в двоичном виде: X=10.0.0.00111001
G=10.0.0.00000001

Максимальная общая часть обоих адресов (то есть, искомая минимальная сеть, включающая оба адреса): N=10.0.0.00XXXXXX
Значит, N=10.0.0.0/26, а маска – 255.255.255.192.

Все датаграммы, направленные за пределы этой минимальной сети, будут переданы маршрутизатору. Если маска определена неправильно, и на самом деле злоумышленник находится в сети, например, 10.0.0.0/16 и посылает датаграмму узлу 10.0.1.1, маршрутизатор примет эту датаграмму от злоумышленника и просто передаст ее узлу назначения в этой же самой сети.

Конечно, существует вероятность, что злоумышленник неправильно определит IP-адрес для присвоения и окажется за пределами сети. Кроме того, возможная конфигурация нескольких IP-сетей в одном сегменте Ethernet усложнит задачу злоумышленника. Однако после периода проб и ошибок злоумышленник имеет все шансы определить необходимые параметры для конфигурирования своего хоста.

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

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

Однако, если злоумышленник, определив IP- и MAC-адреса какого-либо компьютера в своей сети, дождется его выключения (или проведет против него атаку «отказ в обслуживании», приводящую к неспособности атакуемого хоста работать в сети), а потом присвоит себе его MAC- и IP-адреса, то обнаружить такого злоумышленника будет невозможно и все его действия будут приписаны атакованному хосту.

2.7.5. Несанкционированный обмен данными

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

В этом пункте мы рассмотрим два приема, которые может использовать злоумышленник для проникновения через некоторые фильтры.

2.7.5.1. Туннелирование

Предположим, злоумышленник хочет отправить данные с узла Х узлу А, находящемуся за пределами его сети, однако правила фильтрации на маршрутизаторе запрещают отправку датаграмм узлу А (рис. 2.88). В то же время разрешена отправка датаграмм узлу В, также находящемуся за пределами охраняемой сети.

Злоумышленник использует узел В как ретранслятор датаграмм, направленных в А. Для этого он создает датаграмму, направленную из Х в В, в поле Protocol которой помещается значение 4 («IP»), а в качестве данных эта датаграмма несет другую IP-датаграмму, направленную из Х в А. Фильтрующий маршрутизатор пропускает сформированную датаграмму, поскольку она адресована разрешенному узлу В, а IP-модуль узла В извлекает из нее вложенную датаграмму. Видя, что вложенная датаграмма адресована не ему, узел В отправляет ее по назначению, то есть узлу А (рис. 2.88).

Описанная операция называется туннелированием. Для ее осуществления злоумышленник может иметь, а может и не иметь сговора с узлом В – в зависимости от того, что представляет собой этот узел и как он сконфигурирован. Если В является маршрутизатором, то он может обрабатывать вложенные датаграммы без всякого сговора со злоумышленником, если только администратор не заблокировал такую возможность.

Того же самого результата можно добиться, применив IP-опцию Loose/Strict Source Routing.

Рис. 2.88. Туннелирование сквозь фильтрующий маршрутизатор

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

Очевидно, что туннелирование может использоваться и в обратном направлении, то есть, для проникновения из Интернета внутрь охраняемой сети. При этом узел Х находится в Интернете, а узлы А и В – в охраняемой сети и узлу В разрешено получение датаграмм из внешних сетей.

Для защиты от туннелирования следует запретить маршрутизатору транслировать во внешнюю сеть датаграммы с полем Protocol=4 и датаграммы с опциями. Напомним, что туннелирование используется для подключения сетей, поддерживающих групповую рассылку, к сети MBONE через сети, не поддерживающие групповую маршрутизацию. В этом случае все маршрутизаторы защищаемой (внутренней) системы сетей должны поддерживать групповую маршрутизацию, а инкапсуляция и извлечение групповых датаграмм должны выполняться непосредственно на фильтрующем маршрутизаторе.

2.7.5.2. Атака крошечными фрагментами
(Tiny Fragment Attack)

В случае, когда на вход фильтрующего маршрутизатора поступает фрагментированная датаграмма, маршрутизатор производит досмотр только первого фрагмента датаграммы (первый фрагмент определяется по значению поля IP-заголовка Fragment Offset=0, – см. п. 2.2.4). Если первый фрагмент не удовлетворяет условиям пропуска, он уничтожается. Остальные фрагменты можно безболезненно пропустить, не затрачивая на них вычислительные ресурсы фильтра, поскольку без первого фрагмента датаграмма все равно не может быть собрана на узле назначения.

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

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

Злоумышленник формирует искусственно фрагментированную датаграмму с TCP-сегментом, при этом первый фрагмент датаграммы имеет минимальный размер поля данных – 8 октетов (напомним, что размеры фрагментов указываются в 8-октетных блоках). В поле данных датаграммы находится TCP-сегмент, начинающийся с TCP-заголовка. В первых 8 октетах TCP-заголовка (п. 2.5.2) находятся номера портов отправителя и получателя и поле Sequence Number, но значения флагов не попадут в первый фрагмент. Следовательно, фильтр пропустит первый фрагмент датаграммы, а остальные фрагменты он проверять не будет. Таким образом, датаграмма с SYN-сегментом будет успешно доставлена на узел назначения и после сборки передана модулю TCP.

На рис. 2.89 пример датаграммы из 2 фрагментов (IP-заголовки выделены серым). В поле данных первого фрагмента находится 8 октетов TCP-заголовка. В поле данных второго фрагмента помещена остальная часть TCP-заголовка с установленным флагом SYN.

Описанный выше прием проникновения сквозь фильтр называется «Tiny Fragment Attack» (RFC-1858). Использование его в других случаях (для обхода других условий фильтрации) не имеет смысла, так как все остальные «интересные» поля в заголовке TCP и других протоколов находятся в первых 8 октетах заголовка и, следовательно, не могут быть перемещены во второй фрагмент.

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

1) не пропускать датаграммы с Fragment Offset=0 и Protocol=6 (TCP), размер поля данных которых меньше определенной величины, достаточной, чтобы вместить все «интересные поля» (например, 20);

2) не пропускать датаграммы с Fragment Offset=1 и Protocol=6 (TCP): наличие такой датаграммы означает, что TCP-сегмент был фрагментирован с целью скрыть определенные поля заголовка и что где-то существует первый фрагмент с 8 октетами данных. Несмотря на то, что в данном случае первый фрагмент будет пропущен, узел назначения не сможет собрать датаграмму, так как фильтр уничтожил второй фрагмент.

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

Второй аспект фрагментации, интересный с точки зрения безопасности, – накладывающиеся (overlapping) фрагменты. Рассмотрим пример датаграммы, несущей TCP-сегмент и состоящей из двух фрагментов (рис. 2.90, IP-заголовок выделен серым цветом). В поле данных первого фрагмента находится полный TCP-заголовок, без опций, дополненный нулями до размера, кратного восьми октетам. В поле данных второго фрагмента – часть другого TCP-заголовка, начиная с девятого по порядку октета, в котором установлен флаг SYN.

Видно, что второй фрагмент накладывается на первый (первый фрагмент содержит октеты 0-23 данных исходной датаграммы, а второй фрагмент начинается с октета 8, потому что его Fragment Offset=1). Поведение узла назначения, получившего такую датаграмму, зависит от реализации модуля IP. Часто при сборке датаграммы данные второго, накладывающегося фрагмента записываются поверх предыдущего фрагмента. Таким образом, при сборке приведенной в примере датаграммы в TCP-заголовке переписываются поля начиная с ACK SN в соответствии со значениями из второго фрагмента, и в итоге получается SYN-сегмент.

Рис. 2.90. Накладывающиеся фрагменты

Если для защиты от Tiny Fragment Attack применяется подход 1) из описанных выше (инспекция первого фрагмента датаграммы), то с помощью накладывающихся фрагментов злоумышленник может обойти эту защиту.

Маршрутизатор, применяющий второй подход, будет успешно противостоять Tiny Fragment Attack с накладывающимися фрагментами.

2.7.6. Принуждение к ускоренной
передаче данных

Механизм реагирования на заторы сети (congestion control), реализуемый протоколом TCP (п. 1.2.5.4, RFC-2581), позволяет злоумышленнику-получателю данных принудить отправителя высылать данные с многократно увеличенной скоростью [Savage]. В результате злоумышленник отбирает для своих нужд ресурсы сервера-отправителя и компьютерной сети, замедляя или блокируя соединения прочих участников сетевого взаимодействия.

Атаки выполняются путем специально организованной посылки злоумышленником подтверждений приема данных (ACK-сегментов). Все описываемые в этом пункте атаки эксплуатируют следующее неявное допущение, заложенное в протокол TCP: один участник TCP-соединения полностью доверяет другому участнику в том, что тот действует в строгом соответствии с теми же спецификациями протокола, что и первый.

В следующих подпунктах мы будем считать, что узел А отправляет данные узлу В, а последний пытается принудить узел А передавать данные на завышенной скорости.

2.7.6.1. Расщепление подтверждений

Пусть узел А, после установления соединения, находится в режиме медленного старта. Окно перегрузки cwnd равно одному полноразмерному сегменту, который и высылается в В (рис. 2.91). Однако В, вместо того, чтобы ответить одним подтверждением о получении всего сегмента (ACK SN=1001), высылает несколько подтверждений с возрастающими номерами ACK SN (например, 300, 600 и, наконец, 1001), как бы подтверждая получение сегмента по частям.

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

В итоге при нормальном поведении узла В отправитель на следующем шаге увеличил бы окно cwnd только на 1 сегмент и отправил бы в В два следующих полноразмерных сегмента (SN=1001 и 2001). Но узел В, выслав три подтверждения вместо одного, вынудил узел А увеличить значение cwnd до 4 и отправить 4 сегмента вместо двух.

Рис. 2.91. Расщепление подтверждений

В общем случае, если полноразмерный сегмент содержит N октетов, то узел В может отправить M ? N подтверждений. Простые арифметические подсчеты показывают, что тогда на i-м шаге (то есть через время RTT?i, где RTT – время обращения) узел А будет отправлять не N?2i октетов, как это было бы при нормальном поведении получателя, а порядка N?M i октетов, если, конечно, узел В позаботится об объявлении подобающего размера окна получателя. Типичный размер поля данных сегмента – 1460 октетов. Наиболее агрессивное поведение получателя (1460 подтверждений на каждый сегмент) теоретически приведет к тому, что уже после третьего шага узел В может получить 2,9 Гбайт данных. Разумеется, скорость не может расти бесконечно – она будет ограничена возможностями сети и узла-отправителя.

2.7.6.2. Ложные дубликаты подтверждений

Опять рассмотрим ситуацию, когда узел А находится в медленном старте после установления соединения. А отправляет в В один сегмент (SN=1-1000), но узел В, вместо того чтобы ответить подтверждением ACK SN=1001, отвечает серией сфабрикованных подтверждений ACK SN=1 (рис. 2.92).

Получение дубликатов подтверждений включает на узле А алгоритмы быстрой повторной передачи (fast retransmit) и быстрого восстановления (fast recovery). Последний из них представляет в данном случае особый интерес. Напомним, что алгоритм быстрого восстановления базируется на предположении, что каждый полученный дубликат предыдущего подтверждения, кроме того, что говорит о потере сегмента, также подразумевает, что какой-то другой полноразмерный сегмент покинул сеть. Вследствие этого окно cwnd, измеряемое в полноразмерных сегментах, временно увеличивается на число полученных дубликатов, пока не придет подтверждение, отличное от предыдущих.

Поскольку сам дубликат подтверждения не несет никакой информации о том, получение какого именно сегмента вызвало отправку данного дубликата, ничто не может уберечь отправителя от ложных дубликатов подтверждений, сгенерированных получателем. Таким образом, получатель заставляет отправителя необоснованно увеличить окно cwnd и ускорить отправку данных.

Рис. 2.92. Ложные дубликаты подтверждений

Фактически узел А будет отправлять данные со скоростью, с которой В генерирует дубликаты подтверждений. В какой-то момент в узле А сработает таймер повторной передачи для сегмента SN=1-1000, поскольку он так и не был подтвержден. Узел В отреагирует на это посылкой кумулятивного подтверждения на все полученные к этому моменту данные и переключится на генерацию ложных дубликатов этого последнего подтверждения, снова вынуждая отправителя необоснованно увеличивать cwnd.

2.7.6.3. Преждевременные подтверждения1

Еще одна разновидность атаки строится на том, что получатель может заранее высылать подтверждения еще не принятых им, находящихся в пути сегментов, заставляя отправителя поверить, что данные уже доставлены, результатом чего будет увеличение cwnd и преждевременная отправка новых данных.

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

Более того, если получатель «перестарается» и подтвердит то, что еще не выслано, подтверждение будет просто проигнорировано отправителем и не приведет ни к каким неприятным последствиям.

В отличие от двух предыдущих атак атака преждевременными подтверждениями разрушает механизм обеспечения надежности передачи данных: если какой-либо из сегментов с данными, отправленный из А в В, потеряется в пути, повторной передачи этого сегмента не будет, поскольку он был уже заранее подтвержден получателем. Однако прикладные протоколы HTTP и FTP, с помощью которых и передается большинство данных в Интернете, предоставляют возможность запрашивать у сервера не весь файл, а его определенные части (большинство серверов поддерживают эту возможность). Поэтому, применив описанную атаку и получив основной объем данных с HTTP- или FTP-сервера на завышенной скорости, злоумышленник может впоследствии с помощью запросов на частичную передачу «залатать дыры», образовавшиеся из-за потерянных сегментов.

Описанные атаки особенно эффективны при передаче сравнительно небольших объемов данных (файлов), когда весь файл может быть передан взрывным образом за одно время обращения. Эксперименты [Savage] показали, что скорость загрузки файла увеличивается в несколько раз. Работа конкурирующих TCP-соединений (имеющихся в том же коммуникационном канале) практически блокируется, поскольку из-за резко возросшей интенсивности трафика другие соединения диагностируют состояние затора и принимают соответствующие меры по уменьшению скорости передачи данных, фактически освобождая канал для злоумышленника.

Для реализации описанных атак требуется сравнительно небольшая (несколько десятков строк) модификация модуля TCP на компьютере В. Для защиты от расщепления подтверждений достаточно доработать реализацию модуля TCP: разрешить увеличивать cwnd только после получения подтверждения, охватывающего целый сегмент. Адекватной защиты от двух других атак не существует. Чтобы решить эту проблему, авторы работы [Savage] предлагают внести в заголовок TCP дополнительное поле cumulative nonce, которое будет играть роль идентификатора сегмента; используя это поле, легитимные подтверждения должны ссылаться на сегмент (сегменты), получение которых вызвало отправку данного подтверждения. Это должно предотвратить отправку ложных дубликатов и подтверждений еще не полученных сегментов. За деталями мы отсылаем читателя к первоисточнику, однако маловероятно, чтобы дизайн протокола TCP был изменен.

В заключение упомянем о достаточно простом способе ускоренного получения файлов от отправителя по протоколам HTTP и FTP. Для этого получатель использует программу, способную получать файл по частям (сервер также должен поддерживать соответствующие расширения протоколов HTTP и FTP); пример такой программы для ОС Windows – Flashget. Для загрузки файла с сервера программа одновременно открывает несколько соединений, каждое из которых запрашивает свой фрагмент файла. Фрагменты впоследствии будут состыкованы на локальном диске получателя.

Предположим, что в коммуникационном канале одновременно передают данные 10 TCP-соединений. В результате работы алгоритмов реагирования на заторы они примерно поровну делят между собой полосу пропускания канала, и каждое получает 1/10 его часть. Но если программа загрузки файла открывает не одно, а, например, 5 соединений, то общее число соединений равно 14, из них получением частей одного файла занято 5 соединений, то есть, на получение файла отведено 5/14 = 36% канала, а не 10%, как было раньше.

2.7.7. Отказ в обслуживании

Атаки типа «отказ в обслуживании» (DoS, denial of service), по-видимому, являются наиболее распространенными [Moore] и простыми в исполнении. Целью атаки является приведение атакуемого узла или сети в такое состояние, когда передача данных другому узлу (или передача данных вообще) становится невозможна или крайне затруднена. Вследствие этого пользователи сетевых приложений, работающих на атакуемом узле, не могут быть обслужены – отсюда название этого типа атак. Атаки DoS используются как в комплексе с другими (имперсонация, п. 2.7.3), так и сами по себе.

DoS-атаки можно условно поделить на три группы:

2.7.7.1. Истощение ресурсов узла или сети

Smurf

Атака smurf состоит в генерации шквала ICMP Echo-ответов, направленных на атакуемый узел. Для создания шквала злоумышленник направляет несколько сфальсифицированных Echo-запросов от имени жертвы на широковещательные адреса нескольких сетей, которые выступят в роли усилителей. Потенциально большое число узлов, находящихся в сетях-усилителях и поддерживающих обработку широковещательных Echo-запросов, одновременно отправляет ответы на атакуемый узел. В результате атаки сеть, в которой находится жертва, сам атакуемый узел, а также и сети-усилители могут быть временно заблокированы шквалом ответных сообщений. Более того, если атакуемая организация оплачивает услуги провайдера Интернета пропорционально полученному трафику, ее расходы могут существенно возрасти.

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

Атаку smurf можно обнаружить путем анализа трафика на маршрутизаторе или в сети. Признаком атаки является также полная загрузка внешнего канала и сбои в работе хостов внутри сети. При обнаружении атаки следует определить адреса отправителей сообщений Echo Reply (это сети-усилители), установить в регистратуре Интернета их административную принадлежность и обратиться к администраторам с просьбой принять меры защиты для усилителей, описываемые ниже. Администратор атакуемой сети также должен обратиться к своему провайдеру с извещением об атаке; провайдер может заблокировать передачу сообщений Echo Reply в канал атакуемой организации.

Для устранения атак smurf защитные меры могут быть предприняты как потенциальными усилителями, так и администраторами сетей, в которых может находиться злоумышленник. Это:

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

SYN flood и Naptha

Распространенная атака SYN flood (она же Neptune) состоит в посылке злоумышленником SYN-сегментов TCP на атакуемый узел в количестве большем, чем тот может обработать одновременно (это число невелико – обычно несколько десятков).

При получении каждого SYN-сегмента модуль TCP создает блок TCB, то есть выделяет определенные ресурсы для обслуживания будущего соединения, и отправляет свой SYN-сегмент. Ответа на него он никогда не получит. (Чтобы замести следы и не затруднять себя игнорированием ответных SYN-сегментов, злоумышленник будет посылать свои SYN-сегменты от имени несуществующего отправителя или нескольких случайно выбранных несуществующих отправителей.) Через несколько минут модуль TCP ликвидирует так и не открытое соединение, но если одновременно злоумышленник сгенерирует большое число SYN-сегментов, то он заполнит все ресурсы, выделенные для обслуживания открываемых соединений, и модуль TCP не сможет обрабатывать новые SYN-сегменты, пока не освободится от запросов злоумышленника. Постоянно посылая новые запросы, злоумышленник может продолжительно удерживать жертву в блокированном состоянии. Чтобы снять воздействие атаки, злоумышленник посылает серию сегментов с флагом RST, которые ликвидируют полуоткрытые соединения и освобождают ресурсы атакуемого узла.

Целью атаки является приведение узла (сервера) в состояние, когда он не может принимать запросы на открытие соединений. Однако некоторые недостаточно хорошо спроектированные системы в результате атаки не только перестают открывать новые соединения, но и не могут поддерживать уже установленные, а в худшем случае – зависают.

Атаку SYN flood можно определить как удерживание большого числа соединений на атакуемом узле в состоянии SYN-RECEIVED. В последнее время было показано1, что большое число соединений в состояниях ESTABLISHED и FIN-WAIT-1 также вызывает отказы в обслуживании на сервере. Эти отказы выражаются по-разному в различных системах: переполнение таблиц процессов (process table attack) и файловых дескрипторов, невозможность открытия новых и обрыв установленных соединений, зависание серверных процессов или всей системы.

Подобные бреши в безопасности стеков TCP/IP получили собирательное название Naptha. Подчеркнем, что выполнение атаки Naptha не требует от злоумышленника тех же затрат по поддержанию TCP-соединений, что и от атакуемого узла. Злоумышленник не создает блоков TCB, не отслеживает состояния соединений и не запускает прикладных процессов; при получении TCP-сегмента от атакуемого узла злоумышленник просто генерирует приемлемый ответ, основываясь на флагах и значениях полей заголовка принятого сегмента, чтобы перевести или удержать TCP-соединение на атакуемом узле в нужном состоянии. Разумеется, злоумышленник, чтобы скрыть себя, будет посылать сегменты от имени несуществующего (выключенного) узла и принимать ответные сегменты от атакуемого узла методом прослушивания.

Полной защиты от описанных атак не существует. Чтобы уменьшить подверженность узла атаке администратор должен использовать программное обеспечение, позволяющее установить максимальное число открываемых соединений, а также список разрешенных клиентов (если это возможно)1. Только необходимые порты должны быть открыты (находиться в состоянии LISTEN), остальные сервисы следует отключить. Операционная система должна иметь устойчивость к атакам Naptha – при проведении атаки не должно возникать отказа в обслуживании пользователей и сервисов, не имеющих отношения к атакуемым.

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

Если SYN-сегменты начинают поступать в большом количестве и на большой скорости, то маршрутизатор переходит в «агрессивный» режим: время ожидания ответа от клиента резко сокращается, а каждый вновь прибывающий SYN-сегмент приводит к исключению из очереди одного из ранее полученных SYN-сегментов. При снижении интенсивности потока запросов на соединения маршрутизатор возвращается в обычный, «дежурный» режим.

Отметим, что применение TCP Intercept фактически переносит нагрузку по борьбе с SYN-атакой с атакуемого хоста на маршрутизатор, который лучше подготовлен для этой борьбы.

Затопление датаграммами (UDP flood)

Атака состоит в затоплении атакуемой сети шквалом UDP-сообщений. Для генерации шквала злоумышленник использует сервисы UDP, посылающие сообщение в ответ на любое сообщение. Примеры таких сервисов: echo (порт 7) и chargen (порт 19). От имени узла А (порт отправителя –7) злоумышленник посылает сообщение узлу В (порт получателя – 19). Узел В отвечает сообщением на порт 7 узла А, который возвращает сообщение на порт 19 узла В, и так далее до бесконечности (на самом деле, конечно, до тех пор, пока сообщение не потеряется в сети). Интенсивный UDP-трафик затрудняет работу узлов А и В и может создать затор в сети.

UDP-сервис echo может быть также использован для выполнения атаки fraggle. Эта атака полностью аналогична smurf, однако менее популярна у злоумышленников из-за меньшей эффективности.

Для защиты от атак типа UDP flood следует отключить на узлах сети все неиспользуемые сервисы UDP (отметим, что вам вряд ли когда-нибудь вообще понадобятся сервисы echo и chargen). Фильтр на маршрутизаторе-шлюзе должен блокировать все UDP-сообщения кроме тех, что следуют на разрешенные порты (например, порт 53 – DNS).

В заключение этого подпункта отметим, что использование промежуточных систем для реализации атак, связанных с генерацией направленного шквала пакетов (типа smurf), оказалось весьма плодотворной идеей для злоумышленников. Такие атаки называются распределенными (Distributed DoS, DDoS). Для их реализации злоумышленниками создаются программы-демоны, захватывающие промежуточные системы и впоследствии координирующие создание направленных на атакуемый узел шквалов пакетов (ICMP Echo, UDP, TCP SYN). Захват систем производится путем использования ошибок в программах различных сетевых сервисов. Примеры таких распределенных систем – TFN, trin001.

Ложные DHCP-клиенты

Атака состоит в создании злоумышленником большого числа сфальсифицированных запросов от различных несуществующих DHCP-клиентов. Если DHCP-сервер выделяет адреса динамически из некоторого пула, то все адресные ресурсы могут быть истрачены на фиктивных клиентов, вследствие чего легитимные хосты не смогут сконфигурироваться и лишатся доступа в сеть.

Для защиты от этой атаки администратору следует поддерживать на DHCP-сервере таблицу соответствия MAC- и IP-адресов (если это возможно); сервер должен выдавать IP-адреса в соответствии с этой таблицей.

2.7.7.2. Сбой системы

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

Ping of death

Атака состоит в посылке на атакуемый узел фрагментированной датаграммы, размер которой после сборки превысит 65 535 октетов. Напомним, что длина поля Fragment Offset заголовка IP-датаграммы – 13 битов (то есть, максимальное значение равно 8192), а измеряются смещения фрагментов в восьмерках октетов. Если последний фрагмент сконструированной злоумышленником датаграммы имеет, например, смещение Fragment Offset=8190, а длину – 100, то его последний октет находится в собираемой датаграмме на позиции 8190*8+100=65620 (плюс как минимум 20 октетов IP-заголовка), что превышает максимальный разрешенный размер датаграммы.

Teardrop

Атака использует ошибку, возникающую при подсчете длины фрагмента во время сборки датаграммы. Предположим, фрагмент А имеет смещение 40 (Fragment Offset=5) и длину 120, а фрагмент В – смещение 80 и длину 160, то есть фрагменты накладываются, что, в общем-то, разрешено. Модуль IP вычисляет длину той части фрагмента В, которая не накладывается на А: (80+160) – (40+120)=80, и копирует последние 80 октетов фрагмента В в буфер сборки. Предположим, злоумышленник сконструировал фрагмент В так, что тот имеет смещение 80, а длину 72. Вычисление длины перекрытия дает отрицательный результат: (80+72) – (40+120)= –8, что с учетом представления отрицательных чисел в машинной арифметике интерпретируется как 65528, и программа начинает записывать 65 528 байтов в буфер сборки, переполняя его и затирая соседнюю область памяти.

Land

Атака состоит в посылке на атакуемый узел SYN-сегмента TCP, у которого IP-адрес и порт отправителя совпадают с адресом и портом получателя.

Nuke

Атака состоит в посылке на атакуемый TCP-порт срочных данных (задействовано поле Urgent Pointer). Атака поражала через порт 139 Windows-системы, в которых в прикладном процессе не была предусмотрена возможность приема срочных данных, что приводило к краху системы.

2.7.7.3. Изменение конфигурации
или состояния узла

Перенаправление трафика на несуществующий узел

В п. 2.7.2 были рассмотрены различные методы перехвата трафика злоумышленником. Любой из этих методов может быть использован также и для перенаправления посылаемых атакуемым узлом (или целой сетью) данных «в никуда», результатом чего будет потеря связи жертвы с выбранными злоумышленником узлами или сетями.

В случае с протоколом BGP злоумышленнику достаточно сбросить TCP-соединение между BGP-соседями (см. «Сброс TCP-соединения») ниже, чтобы каждый из соседей удалил маршруты, полученные от другого, и распространил информацию о недостижимости этих маршрутов другим своим соседям. К счастью, применение BGP-аутентификации, которая, напомним, работает на уровне TCP, существенно затрудняет эту задачу, поскольку злоумышленник, не зная пароля, не может сфабриковать приемлемый RST-сегмент.

В дополнение отметим, что при использовании в сети любого протокола маршрутизации злоумышленник может генерировать сфальсифицированные сообщения протокола, содержащие некорректные или предельные значения некоторых полей (порядковых номеров, возраста записи, метрики), что приведет к нарушениям в системе маршрутизации (см., например, [Vetter], [Wang]).

Навязывание длинной сетевой маски

Если хост получает маску для своей сети через ICMP-сообщение Address Mask Reply, то, сформировав ложное сообщение с длинной маской (например, 255.255.255.252), злоумышленник существенно ограничит способность атакуемого хоста к соединениям (коннективность). Если в «суженной» злоумышленником сети не окажется маршрутизатора по умолчанию, то жертва сможет посылать данные только узлам, попадающим под навязанную маску.

В настоящее время хосты динамически конфигурируются с помощью протокола DHCP (что, впрочем, открывает перед злоумышленником более широкие возможности: выдав себя за DHCP-сервер, злоумышленник может полностью исказить настройки стека TCP/IP атакуемого хоста). Тем не менее, следует проверить, как система отреагирует на получение ICMP Address Mask Reply.

Десинхронизация TCP-соединения

Десинхронизация TCP-соединения была рассмотрена в п. 2.7.3. Очевидно, что если после выполнения десинхронизации злоумышленник не будет функционировать в качестве посредника, то передача данных по атакованному TCP-соединению будет невозможна.

Сброс TCP-соединения

Если узел А установил соединение с узлом В, то злоумышленник может принудить узел А преждевременно закрыть это соединение. Для этого злоумышленник может послать узлу А от имени В сфальсифицированный RST-сегмент или ICMP-сообщение Destination Unreachable.

Для формирования приемлемого для узла А RST-сегмента злоумышленник должен подслушивать соединение для того, чтобы поместить в RST-сегмент номер SN, находящийся в рамках доступного окна узла В, иначе узел А сфабрикованный сегмент проигнорирует.

Реакция TCP-модуля узла А на получение ICMP-сообщений Destination Unreachable четко не определена стандартами, хотя документ RFC-1122 утверждает, что уровень IP должен передать соответствующее сообщение модулю TCP, а тот в свою очередь обязан на него как-то прореагировать. Также RFC-1122 говорит, что при получении такого сообщения с кодом 2 (Protocol Unreachable) или 3 (Port Unreachable) модулю TCP следует ликвидировать соединение, к которому это сообщение относится1.

Принуждение к передаче данных на заниженной скорости

Злоумышленник может вынудить модуль TCP узла А снизить скорость передачи данных узлу В в TCP-соединении следующими способами.

2.7.8. Обсуждение

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

Еще раз подчеркнем, что безопасность применительно к сервисам прикладного уровня рассматривается в соответствующих разделах главы 3. Более мощные, специализированные средства защиты (брандмауэры, криптографические протоколы) рассматриваются в главе 4.

2.7.8.1. Фильтрация на маршрутизаторе

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

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

Прокси-сервер находится под контролем администратора предприятия, что позволяет реализовывать различные политики для дифференцированного управления доступом пользователей к сервисам и ресурсам Интернета, фильтрации передаваемых данных (защита от вирусов, цензура и т.п.), кэширования (там, где это применимо).

С точки зрения Интернета от имени всех пользовательских хостов предприятия действует один прокси-сервер, то есть имеется только один потенциальный объект для атаки из Интернета, а безопасность одного прокси-сервера, управляемого профессионалом, легче обеспечить, чем безопасность множества пользовательских компьютеров.

В главе 3, описывая сервисы Интернета, мы будем обсуждать возможность использования прокси-серверов.

2.7.8.2. Анализ сетевого трафика

Анализ сетевого трафика проводится для обнаружения атак, предпринятых злоумышленниками, находящимися как в сети организации, так и в Интернете.

2.7.8.3. Защита маршрутизатора

Мероприятия по защите маршрутизатора проводятся с целью предотвращения атак, направленных на нарушение схему маршрутизации датаграмм или на захват маршрутизатора злоумышленником.

Примеры защитных мероприятий на маршрутизаторах Cisco приведены в п. 2.7.9.

2.7.8.4. Защита хоста

Мероприятия по защите хоста проводятся для предотвращения атак, цель которых – перехват данных, отказ в обслуживании, или проникновение злоумышленника в операционную систему.

2.7.8.5. Превентивное сканирование

Администратор сети должен знать и использовать методы и инструменты злоумышленника и проводить превентивное сканирование сети организации для обнаружения слабых мест в безопасности до того, как это сделает злоумышленник. Для этой целиимеется также специальное программное обеспечение – сканеры безопасности, network security scanners, типа Nessus.

2.7.9. Меры безопасности
на маршрутизаторах Cisco

2.7.9.1. Списки доступа

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

Списки доступа, производящие отбор по IP-адресам, строятся командами access-list в режиме глобальной конфигурации, каждый список определяется номером – числом в диапазоне 0-99. Каждая такая команда добавляет новый критерий отбора в список: router(config)# access-list номер_списка {deny | permit} IP-адрес [маска]

IP-адрес и маска записываются в десятично-точечной нотации, при этом в маске устанавливаются биты, значение которых в адресе следует игнорировать, остальные биты сбрасываются. Например, чтобы строка списка сработала для всех хостов с адресами 1.16.124.ххх, адрес должен быть 1.16.124.0, а маска – 0.0.0.255. Комбинация адрес-маска вида 0.0.0.0 255.255.255.255 (то есть соответствующая всем возможным адресам) может быть записана в виде одного ключевого слова any.

Операторы permit и deny определяют, соответственно, положительное (принять, пропустить, отправить) или отрицательное (отбросить, отказать, игнорировать) будет принято решение при срабатывании данного критерия отбора. Например, если список используется при фильтрации датаграмм по адресу источника, то эти операторы определяют, пропустить или отбросить датаграмму, адрес источника которой удовлетворяет комбинации адрес-маска.

Список доступа представляет собой последовательность из одного и более критериев отбора, имеющих одинаковый номер списка. Последовательность критериев имеет значение: маршрутизатор просматривает их по порядку; срабатывает первый критерий, в котором обнаружено соответствие образцу; оставшаяся часть списка игнорируется. Любые новые критерии добавляются только в конец списка. Удалить критерий нельзя, можно удалить только весь список. В конце списка неявно подразумевается критерий «отказать в любом случае» (deny any) – он срабатывает, если ни одного соответствия обнаружено не было.

Для аннулирования списка доступа следует ввести команду router(config)# no access-list номер_списка

Чтобы применить список доступа для фильтрации датаграмм, проходящих через определенный интерфейс, нужно в режиме конфигурации этого интерфейса ввести команду router(config-if)# ip access-group номер_списка {in | out}

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

Отбор датаграмм производится по IP-адресу источника датаграммы.

Рис. 2.93. Пример сети для фильтрации

Следующий пример разрешает прием на интерфейсе e0 только датаграмм, следующих из сети 1.16.195.0/24 (напомним, что в конце каждого списка подразумевается deny all). Это типичная мера безопасности при приеме датаграмм из локальной сети предприятия (рис. 2.93).

router(config)# access-list 1 permit 1.16.195.0 0.0.0.255
router(config)# interface e0
router(config-if)# ip access-group 1 in

С другой стороны, датаграммы, имеющие адрес отправителя во внутренней сети, не должны поступать на внешний интерфейс se0:

router(config)# access-list 2 deny 1.16.195.0 0.0.0.255
router(config)# access-list 2 permit all
router(config)# interface se0
router(config-if)# ip access-group 2 in

2.7.9.2. Расширенные списки доступа

В предыдущем пункте были рассмотрены стандартные (standard) списки доступа. Существуют также расширенные (extended) списки доступа, имеющие большее количество параметров и предлагающие более богатые возможности для контроля трафика.

Расширенные списки доступа создаются также с помощью команды access-list в режиме глобальной конфигурации, но номера этих списков лежат в диапазоне 100-199.

Пример синтаксиса команды создания строки расширенного списка для контроля TCP-соединений:

router(config)# access-list номер_списка {deny | permit} tcp IP-адрес_источника маска [оператор порт [порт]] IP-адрес_получателя маска [оператор порт [порт]] [established]

Маски для адреса источника и хоста назначения определяются так же, как и в стандартных списках. Оператор должен иметь одно из следующих значений: lt (строго меньше), gt (строго больше), eq (равно), neq (не равно), range (диапазон включительно). После оператора следует номер порта (или два номера порта в случае оператора range), к которому этот оператор применяется. Комбинация оператор-порт, следующая сразу же за адресом источника, относится к портам источника. Соответственно, комбинация оператор-порт, следующая сразу же за адресом получателя, относится к портам хоста-получателя.

Применение этих комбинаций позволяет фильтровать TCP-сегменты не только по адресам мест отправки и назначения, а и по номерам портов.

Ключевое слово established определяет сегменты TCP, передаваемые в состоянии установленного соединения. Это значит, что строке, в которую включен параметр established, не будут соответствовать сегменты с не установленным флагом ACK или RST.

Как и в стандартных списках, операторы deny и permit определяют, соответственно, отбросить или пропустить датаграмму с TCP-сегментом, параметры которой удовлетворяют указанным в строке списка доступа.

Пример: «запретить установление соединений с помощью протокола Telnet со всеми хостами сети 1.16.195.0 netmask 255.255.255.0 со стороны всех хостов Интернета, причем в обратном направлении все соединения должны устанавливаться; остальные TCP-соединения разрешены». Фильтр устанавливается для входящих сегментов со стороны Интернета на интерфейс se0 (см. рис. 2.93).

outer(config)# access-list 100 permit tcp any 172.16.252.0 0.0.255 eq 23 established
router(config)# access-list 100 deny tcp any 172.16.252.0 0.0.255 eq 23
router(config)# access-list 100 permit tcp any any
router(config)# access-list 100 permit ip any any
router(config)# interface se0
router(config-if)# ip access-group 100 in

Указание ip вместо tcp в команде access-list означает «все протоколы». Отметим, что в конце каждого списка доступа подразумевается deny ip any any, поэтому в предыдущем примере мы указали permit ip any any для разрешения произвольных датаграмм, не попавших под предшествующие критерии.

Расширенный список с протоколом ip позволяет также производить фильтрацию произвольных датаграмм по адресу отправителя и по адресу получателя (в стандартных списках фильтрация производится только по адресу отравителя).

Критерии для фильтрации UDP-сообщений составляются аналогично TCP, при этом вместо tcp следует указать udp, а параметр established, конечно, не применим.

Контроль за ICMP сообщениями может осуществляться с помощью критериев отбора типа:

router(config)# access-list номер_списка {deny | permit} icmp адрес_источника маска адрес_назначения маска [icmp-тип [icmp-код]]

где icmp-тип и, если требуется уточнение, icmp-код определяют ICMP-сообщение (см. п. табл. 2.3).

Вообще, в расширенных списках можно работать с пакетами любого IP-протокола. Для этого после оператора deny/permit надо указать название протокола (eigrp, gre, icmp, igmp, igrp, ipinip, ospf, tcp, udp) или его номер, которым он кодируется в поле Protocol заголовка датаграммы. Далее указываются адреса источника и хоста назначения с масками и, возможно, дополнительные параметры, специфичные для данного протокола.

Отметим вариант ipinip, соответствующий инкапсуляции IP-датаграммы внутри другой датаграммы. Маршрутизацию таких датаграмм в Интернет и из него следует запретить (если только не используется туннелирование групповых датаграмм):

router(config)# access-list 101 deny ipinip any any
router(config)# access-list 101 allow ip any any
router(config)# interface se0
router(config-if)# ip access-group 101 in
router(config-if)# ip access-group 101 out

В конце команды access-list (расширенный) можно указать параметр log, тогда все случаи срабатывания данного критерия (то есть обнаружения датаграммы, соответствующей критерию), будут протоколироваться на консоль или как указано командой logging. После того, как протоколируется первый случай срабатывания, дальше сообщения посылаются каждые 5 минут с указанием числа срабатываний за отчетный период.

Просмотр имеющихся списков доступа (c указыванием числа срабатываний каждого критерия):

router# show access-lists

Более подробную статистику работы списков доступа можно получив, включив режим ip accounting. Режим включается в контексте конфигурирования интерфейса. Следующая команда включает режим учета случаев нарушения (то есть, датаграмм, которые не были пропущены списком доступа на данном интерфейсе).

router(config-if)# ip accounting access-violations

Просмотр накопленной статистики (с указанием адресов отправителей и получателей датаграмм):

router# show ip accounting access-violations

При конфигурировании запрещающих фильтров (в конце которых подразумевается deny all) администратор должен не забыть оставить «дверь» для сообщений протоколов маршрутизации, если они используются на конфигурируемом интерфейсе.

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

Более подробно со списками доступа Cisco можно ознакомиться в книге [Sedayao].

2.7.9.3. Ограничение доступа к маршрутизатору

Доступ к маршрутизатору для его конфигурирования может производиться двумя способами: через последовательный консольный порт, непосредственно подсоединенный к терминалу или компьютеру администратора (консольной станции), или через Telnet.

Очевидно, что второй способ следует по возможности ограничить. Для этого надо применить список доступа к виртуальному терминалу с помощью команды access-class. Предположим, компьютерыадминистраторов расположены в диапазоне 1.16.195.8/29. Соответствующие команды:

router(config)# access-list 12 permit 1.16.195.8 0.0.0.7
router(config)# line vty 0 4
router(config-line)# ip access-class 12 in

Безусловно, более надежным решением, которое мы настоятельно рекомендуем, является полное отключение возможности подсоединиться к маршрутизатору через Telnet: router(config)# line vty 0 4
router(config-line)# transport input none
Если необходимо конфигурировать маршрутизатор с удаленного хоста, то вместо Telnet следует использовать защищенный терминальный доступ (например, SSH) для подключения к консольной станции (рис. 2.94). К одной консольной станции может быть подключено несколько маршрутизаторов.

Рис. 2.94. Организация доступа к маршрутизаторам

Устройствами Cisco можно управлять также через web-интерфейс, для чего в маршрутизатор встроен HTTP-сервер. К сожалению, аутентификация пользователя этим сервером проводится по схеме Basic, то есть пароль передается через сеть в открытом виде. HTTP-сервер в маршрутизаторах по умолчанию отключен, но в других устройствах (коммутаторах) может быть задействован. Отключение HTTP-сервера:

router(config)# no ip http server

2.7.9.4. Разное

Отключение неиспользуемых сервисов:
router(config)# no service udp-small-servers
router(config)# no service tcp-small-servers
router(config)# no ip bootp server
router(config)# no ip http server
router(config)# no service finger
router(config)# no cdp run

Блокирование датаграмм с опцией Source Routing:

router(config)# no ip source-route

Отключение маршрутизации широковещательных сообщений для предотвращения атак smurf (в режиме конфигурации каждого интерфейса):

router(config-if)# no ip directed-broadcast

Механизм Proxy ARP может использоваться маршрутизатором для поддержки работы хостов, не использующих сетевые маски, в бесклассовой сети. Например, хост 1.2.3.4 находится в сети 1.2.3.0/24, но, не поддерживая CIDR, считает, что находится в сети 1.0.0.0/8. При необходимости отправить датаграмму по адресу 1.5.6.7 хост выдает ARP-запрос, поскольку IP-адрес 1.5.6.7 принадлежит сети 1.0.0.0/8. Маршрутизатор, услышав этот запрос, отвечает от имени хоста 1.5.6.7, возвращая свой MAC-адрес. После этого хост 1.2.3.4 отправляет кадр с датаграммой маршрутизатору, а тот маршрутизирует ее далее по назначению. Поскольку все современные системы поддерживают бесклассовую адресацию, механизм Proxy ARP следует отключить (в режиме конфигурации каждого интерфейса):

router(config-if)# no ip proxy-arp

Статические записи в ARP-таблице можно создать командой

router(config)# arp IP-адрес MAC-адрес arpa

а просмотреть содержимое таблицы командой

router# show arp

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

router# show ip interface имя_интерфейса

Для защиты от атак SYN flood маршрутизаторы Cisco предлагают механизм TCP intercept, который мы описывали выше в п. 2.7.7.1. Для защиты с помощью этого механизма всех хостов сети 1.16.195.0/24 следут ввести команды:

router(config)# access-list 121 permit tcp any 1.16.195.0 0.0.0.255
router(config)# ip tcp intercept list 101

Кроме уже описанного нами режима перехвата, который включен по умолчанию, TCP Intercept может работать в пассивном режиме (watch). В этом случае SYN-сегменты пропускаются к серверу, но если через некоторое время (по умолчанию 30 с) соединение не было установлено, то маршрутизатор отправляет серверу сегмент RST. Переключение между режимами:

router(config)# ip tcp intercept mode watch
router(config)# ip tcp intercept mode intercept

Также имеется несколько команд для настройки параметров механизма TCP Intercept, с которыми, при необходимости, читатель ознакомится в документации Cisco.