Рис. 9.1. Схема ARP-атаки
9. Проблемы безопасности протоколов TCP/IPМатериал настоящей главы цитируется по книге М.Мамаев, С.Петренко "Технологии защиты информации в Интернете" (СПб: "Питер", 2002). Данный фрагмент опубликован на сайте издательства "Питер".
9.2. Перехват данных
- 9.1.1. Прослушивание сети
- 9.1.2. Сканирование сети
- 9.1.3. Генерация пакетов
9.3. Имперсонация
- 9.2.1. Ложные ARP-ответы
- 9.2.2. Навязывание ложного маршрутизатора
9.4. Несанкционированное подключение к сети
- 9.3.1. Имперсонация без обратной связи
- 9.3.2. Десинхронизация TCP-соединения
9.5. Несанкционированный обмен данными
9.6. Принуждение к ускоренной передаче данных
- 9.5.1. Туннелирование
- 9.5.2. Атака крошечными фрагментами (Tiny Fragment Attack)
9.7. Отказ в обслуживании
- 9.6.1. Расщепление подтверждений
- 9.6.2. Ложные дубликаты подтверждений
- 9.6.3. Преждевременные подтверждения
9.8. Обсуждение
- 9.7.1. Истощение ресурсов узла или сети
- 9.7.2. Сбой системы
- 9.7.3. Изменение конфигурации или состояния узла
- 9.8.1. Фильтрация на маршрутизаторе
- 9.8.2. Анализ сетевого трафика
- 9.8.3. Защита маршрутизатора
- 9.8.4. Защита хоста
- 9.8.5. Превентивное сканирование
Литература
Бесплатное программное обеспечение
Сайты
Отечественные сайтыОглавление учебного пособия
Страница курса "Телекоммуникационные технологии"
Кафедра КТС
В данной главе рассматривается безопасность сетевого взаимодействия только на уровнях от доступа к сети до транспортного включительно, то есть охватываются аспекты безопасности собственно передачи данных через сети IP (Интернет). Здесь мы не останавливаемся на содержании этих данных и возможности их использования в неблаговидных целях. Последнее относится к безопасности прикладных протоколов и приложений Интернета.
Прежде чем перейти к разбору конкретных приемов, классифицируем действия злоумышленника — атаки, направленные против какого-либо узла (или, возможно, целой сети). Злоумышленник ставит перед собой определенную цель, как-то:
Для достижения своих целей злоумышленник использует прослушивание (sniffing), сканирование сети и генерацию пакетов. Под генерацией пакетов понимается создание и отправка специально сконструированных датаграмм или кадров, позволяющих злоумышленнику выполнить ту или иную атаку. Особо выделим здесь фальсификацию пакетов, то есть создание IP-датаграмм или кадров уровня доступа к сети, направленных якобы от другого узла (spoofing).
Прослушивание сети Ethernet (а подавляющее большинство локальных сетей используют именно эту технологию) является тривиальной задачей: для этого нужно просто перевести интерфейс в режим прослушивания (promiscuous mode). Легко доступны программы, не только записывающие весь трафик в сегменте Ethernet, но и выполняющие его отбор по установленным критериям: например, программа tcpdump или входящая в поставку ОС Solaris программа snoop.
Среди других сетевых технологий подвержены прослушиванию сети FDDI и радиосети (например Radio Еthernet). Несколько сложнее для злоумышленника извлечь трафик из телефонных выделенных и коммутируемых линий — главным образом, из-за сложности физического доступа и подключения к таким линиям. Однако следует помнить, что злоумышленник может оккупировать промежуточный маршрутизатор и таким образом получить доступ ко всему транзитному трафику, независимо от используемых технологий на уровне доступа к сети.
Ограничить область прослушивания в сети Ethernet можно разбиением сети на сегменты с помощью коммутаторов. В этом случае злоумышленник, не прибегая к активным действиям, описанным в п. 9.2, может перехватить только кадры, получаемые или отправляемые узлами сегмента, к которому он подключен. Единственным способом борьбы с прослушиванием сегмента Ethernet является шифрование данных.
Злоумышленник, прослушивающий сеть, может быть обнаружен с помощью утилиты AntiSniff, которая выявляет в сети узлы, чьи интерфейсы переведены в режим прослушивания.
AntiSniff выполняет три вида тестов узлов сегмента Ethernet. Первый тест основан на особенностях обработки разными операционными системами кадров Ethernet, содержащих IP-датаграммы, направленные в адрес тестируемого узла. Например, некоторые ОС, находясь в режиме прослушивания, передают датаграмму уровню IP, независимо от адреса назначения кадра Ethernet (в то время как в обычном режиме кадры, не направленные на MAC-адрес узла, системой вообще не рассматриваются). Другие системы имеют особенность при обработке кадров с широковещательным адресом: в режиме прослушивания MAC-адрес ff:00:00:00:00:00 воспринимается драйвером интерфейса как широковещательный. Таким образом, послав сообщение ICMP Echo внутри «неверного» кадра, который при нормальных обстоятельствах должен быть проигнорирован, и получив на него ответ, AntiSniff заключает, что интерфейс тестируемого узла находится в режиме прослушивания.
Второй тест основан на предположении, что программа прослушивания на хосте злоумышленника выполняет обратные DNS-преобразования для IP-адресов подслушанных датаграмм (поскольку часто по доменному имени можно определить назначение и важность того или иного узла). AntiSniff фабрикует датаграммы с фиктивными IP-адресами (то есть не предназначенные ни одному из узлов тестируемой сети), после чего прослушивает сеть на предмет DNS-запросов о доменных именах для этих фиктивных адресов. Узлы, отправившие такие запросы, находятся в режиме прослушивания.
Тесты третьей группы, наиболее универсальные, с одной стороны, так как не зависят ни от типа операционной системы, ни от предполагаемого поведения прослушивающих программ. С другой стороны, эти тесты требуют определенного анализа от оператора, то есть — не выдают однозначный результат, как в двух предыдущих случаях кроме того, они сильно загружают сеть. Тесты основаны на том, что интерфейс, находящийся в обычном режиме, отфильтровывает кадры, направленные не на его адрес, с помощью программно-аппаратного обеспечения сетевой карты, и не задействует при этом ресурсы операционной системы. Однако в режиме прослушивания обработка всех кадров ложится на программное обеспечение злоумышленника, то есть, в конечном счете, на операционную систему. AntiSniff производит пробное тестирование узлов сети на предмет времени отклика на сообщения ICMP Echo, после чего порождает в сегменте шквал кадров, направленных на несуществующие MAC-адреса, при этом продолжая измерение времени отклика. У систем, находящихся в обычном режиме, это время растет, но незначительно, в то время как узлы, переведенные в режим прослушивания, демонстрируют многократный (до 4 раз) рост задержки отклика.
В связи с вышеизложенным отметим, что представление о прослушивании как о безопасной деятельности, которую нельзя обнаружить, не соответствует действительности.
Сканирование сети имеет своей целью выявление подключенных к сети компьютеров и определение работающих на них сетевых сервисов (открытых портов TCP или UDP). Первая задача выполняется посылкой ICMP-сообщений Echo с помощью программы ping с последовательным перебором адресов узлов в сети. Стоит попробовать отправить Echo-сообщение по широковещательному адресу — на него ответят все компьютеры, поддерживающие обработку таких сообщений.
Администратор сети может обнаружить попытки сканирования путем анализа трафика в сети и отслеживания Echo-сообщений, за короткий промежуток времени посылаемых последовательно по всем адресам сети. Для большей скрытности злоумышленник может существенно растянуть процесс во времени («медленное сканирование») — это же касается и сканирования портов TCP/UDP. Также злоумышленник может применить «обратное сканирование» (inverse mapping): в этом случае на тестируемые адреса посылаются не сообщения ICMP Echo, а другие сообщения, например RST-сегменты TCP, ответы на несуществующие DNS-запросы и т. п. Если тестируемый узел не существует (выключен), злоумышленник получит в ответ ICMP-сообщение Destination Unreachable: Host Unreachable.
Следовательно, если сообщение не было получено, то соответствующий узел подключен к сети и работает.
Программа traceroute поможет в определении топологии сети и обнаружении маршрутизаторов.
Для определения того, какие UDP- или TCP-приложения запущены на обнаруженных компьютерах, используются программы-сканеры, например, программа nmap. Поскольку номера портов всех основных сервисов Интернета стандартизованы, то, определив, например, что порт 25/TCP открыт, можно сделать вывод о том, что данный хост является сервером электронной почты, и т. д. Полученную информацию злоумышленник может использовать для развертывания атаки на уровне приложения.
Сканирование TCP-портов хоста производится несколькими способами. Наиболее простой способ — установление TCP-соединения с тестируемым портом с помощью функции connect. Если соединение удалось установить, значит, порт открыт и к нему подсоединено серверное приложение. Достоинством этого способа является возможность выполнения сканирования любым пользователем, и даже без специального программного обеспечения: стандартная программа 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-сервисов злоумышленник, непосредственно подключенный к сегменту сети, может использовать простое прослушивание. Такая форма сканирования сети является более скрытной, чем рассылка тестирующих датаграмм.
Генерация датаграмм или кадров произвольного формата и содержания производится не менее просто, чем прослушивание сети Ethernet. Библиотека libnet обеспечит программиста всем необходимым для решения этой задачи. Библиотека libpcap предоставляет инструментарий для обратного действия — извлечения пакетов из сети и их анализа.
На многочисленных сайтах Интернета злоумышленник может найти уже готовые программы, генерирующие пакеты целенаправленно для выполнения какой-либо атаки или сканирования сети (например, программа nmap, упомянутая выше). Применение таких программ часто не требует от злоумышленника ни квалификации программиста, ни понимания принципов работы сети, что делает многие из описанных атак, особенно атаки типа «отказ в обслуживании», широко доступными для исполнения.
Простейшей формой перехвата данных является прослушивание сети. В этом случае злоумышленник может получить массу полезной информации: имена пользователей и пароли (многие приложения передают их в открытом виде), адреса компьютеров в сети, в том числе адреса серверов и запущенные на них приложения, адрес маршрутизатора, собственно передаваемые данные, которые могут быть конфиденциальными (например, тексты электронных писем) и т. п. Прослушивание сети и меры по обнаружению узлов, находящихся в режиме прослушивания, обсуждались в п. 9.1.1.
Однако если сеть разбита на сегменты с помощью коммутаторов, то злоумышленник может перехватить только кадры, получаемые или отправляемые узлами сегмента, к которому он подключен. Простое прослушивание также не позволяет злоумышленнику модифицировать передаваемые между двумя другими узлами данные. Для решения этих задач злоумышленник должен перейти к активным действиям, чтобы внедрить себя в тракт передачи данных в качестве промежуточного узла. (Такие атаки в англоязычной литературе называют man-in-the-middle attack.)
Для перехвата трафика между узлами А и В, расположенными в одной IP-сети, злоумышленник использует протокол ARP. Он рассылает сфальсифицированные ARP-сообщения так, что каждый из атакуемых узлов считает MAC-адрес злоумышленника адресом своего собеседника (рис. 2.78).
Рис. 9.1. Схема 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-адрес Х (рис. 9.1). Для формирования сообщений можно использовать библиотеку libnet. Так как ARP — протокол без сохранения состояния, то узлы А и В примут ARP-ответы, даже если они не посылали запросов. Далее злоумышленник периодически (достаточно это делать раз в 20–40 секунд) повторяет посылку сфальсифицированных ARP-ответов для обновления сфабрикованных записей в ARP-таблицах узлов А и В, чтобы удерживать эти узлы в неведении относительно истинных адресов и не дать им сформировать соответствующие ARP-запросы.
4. Введенные в заблуждение узлы А и В пересылают свой трафик через узел Х, полагая, что сообщаются друг с другом непосредственно. Злоумышленник может просто прослушивать трафик или изменять передаваемые данные в своих интересах.
Узел В может быть шлюзом сети, в которой находится узел А. В этом случае злоумышленник может перехватывать весь трафик между узлом А и Интернетом.
Также злоумышленник может вообще не передавать кадры узла А узлу В, а выдавать себя за узел В, фабрикуя ответы от его имени и отсылая их в А (см. также п. 9.3).
Разделение сети на сегменты с помощью коммутаторов, очевидно, не является препятствием для описанной ARP-атаки.
Отметим, что в сфабрикованных ARP-ответах злоумышленник может вместо своего MAC-адреса указать несуществующий адрес Ethernet. Впоследствии он может извлекать из сети кадры, направленные на этот адрес путем прослушивания сети или перепрограммирования MAC-адреса своей сетевой карты. Это потребует несколько больших усилий, но взамен злоумышленник сможет практически полностью замести следы, поскольку его собственный 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.
Для перехвата трафика, направленного от некоторого узла А в другую сеть, злоумышленник может навязать хосту свой адрес в качестве адреса маршрутизатора, которому должны быть переданы отправляемые узлом А данные. В этом случае узел А будет направлять трафик на узел злоумышленника, который после анализа и, возможно, модификации данных, отправит их далее настоящему маршрутизатору.
Ложное сообщение ICMP Redirect
Как правило, навязывание ложного маршрутизатора выполняется с помощью фальсифицированных ICMP-сообщений Redirect, так как документ RFC-1122 требует, чтобы хосты обязательно обрабатывали такие сообщения. В подложном сообщении злоумышленник объявляет свой собственный адрес в качестве адреса маршрутизатора (рис. 9.2).
Рис. 9.2. Навязывание ложного маршрутизатора с помощью ICMP Redirect
Напомним действия хоста А при получении сообщения Redirect. Хост А считает, что Redirect является реакцией на ранее отправленную датаграмму некому хосту В, причем заголовок и первые 64 бита этой датаграммы возвращаются внутри полученного сообщения. Из возвращенного заголовка хост А определяет, что он должен сделать перенаправление для датаграмм, направленных в В, и вносит в свою таблицу маршрутов частный маршрут к хосту В через маршрутизатор, указанный в сообщении Redirect. Следует обратить внимание, что все сообщения Redirect обрабатываются одинаково независимо от кода сообщения — таким образом, посылка Redirect с кодом 0 («перенаправление для сети получателя») не вызовет изменения маршрута в сеть, в которой находится получатель, а приведет к установке частного маршрута к хосту В, как и в случае сообщения с кодом 1.
Сообщение Redirect должно быть отправлено маршрутизатором, который в таблице маршрутов хоста А является следующим маршрутизатором на пути в В, при этом хост В не должен находиться в той же IP-сети, что и А, а новый объявленный маршрутизатор Х, наоборот, обязан находиться в одной IP-сети с хостом А.
Таким образом, для создания ложного сообщения Redirect с целью перехвата трафика между хостами А и В злоумышленник должен находиться в одной IP-сети с А и знать адрес маршрутизатора, через который А отправляет датаграммы в В. Если в сети имеется единственный шлюз, то он и является искомым маршрутизатором. Далее злоумышленник формирует IP-датаграмму, где в качестве адреса отправителя указан IP-адрес шлюза, а получателем является хост А. В датаграмму помещается сообщение Redirect, где в поле Адрес нового маршрутизатора значится IP-адрес злоумышленника, а дальше приводится заголовок произвольной датаграммы, якобы ранее направленной из А в В. Совершенно необязательно приводить там заголовок реальной датаграммы, потому что модуль IP не хранит информацию о ранее отправленных датаграммах. Получившееся сообщение отправляется адресату — хосту А, который считает, что оно прибыло от шлюза и меняет свою таблицу маршрутов. Новый маршрут к хосту В будет действителен в течение нескольких минут, поэтому, чтобы поддерживать его постоянно, злоумышленник должен посылать сфабрикованные сообщения периодически.
Отметим, что трафик из В в А будет по-прежнему направляться маршрутизатором непосредственно хосту А, минуя злоумышленника (рис. 9.2), потому что маршрутизатор и хост А находятся в одной сети, следовательно, маршрутизатор в принципе не может использовать никаких промежуточных узлов для достижения хоста А.
Несмотря на такой «половинчатый» перехват, злоумышленник может просматривать и модифицировать данные, направляемые из А в В, а если он находится в одном сегменте с хостом А или маршрутизатором, то и наблюдать за ответами узла В, направляемыми в А. Более того, злоумышленник может вообще не пересылать датаграммы в узел В, а отвечать на них сам, фабрикуя датаграммы от имени узла В (см. также п. 9.3).
Для устранения возможности описываемой атаки необходимо отключить на хосте обработку сообщений Redirect. Несмотря на то, что это действие противоречит требованиям к хостам, установленным в документе RFC-1122, оно выглядит совершенно разумным, особенно для хостов в сетях с единственным шлюзом, однако не все операционные системы могут поддерживать такое отключение.
Вообще говоря, для пользователя атакуемого узла не составит особого труда раскрыть замысел злоумышленника: полученное сообщение Redirect отобразится в виде неожиданно появившейся строки в таблице маршрутов, направляющей данные для хоста В через узел Х2. Кроме того, программа traceroute скорее всего покажет дополнительный промежуточный узел на пути к В. К сожалению пользователи обычно не заглядывают в таблицу маршрутов и не запускают traceroute, если поведение сетевых программ не вызывает у них подозрений, поэтому злоумышленник имеет хорошие шансы остаться незамеченным.
Атака при конфигурировании хоста
В некоторых случаях навязывание ложного маршрутизатора может быть произведено с помощью ICMP-сообщения Router Advertisement или через протокол DHCP.
Сообщения Router Advertisement могут использоваться хостами для установки маршрута по умолчанию, однако в реальной жизни такое происходит нечасто, так как для удаленного динамического конфигурирования стека TCP/IP хоста обычно используется протокол DHCP. Если же хост все-таки обрабатывает сообщения Router Advertisement, то сформировав подложное сообщение, злоумышленник может перенаправить на себя весь трафик хоста А, адресованный за пределы его сети, а не только трафик, адресованный узлу В. Как и в предыдущем случае, данные на обратном пути будут доставляться маршрутизатором на хост А непосредственно, минуя злоумышленника.
Фальсификация сообщений протокола DHCP будет успешна, если хост конфигурирует себя через этот протокол. В ответ на запрос DHCPDISCOVER злоумышленник оперативно возвращает хосту подложное сообщение DHCPOFFER, где в числе дополнительных параметров указывает себя в качестве маршрутизатора по умолчанию. Чтобы опередить предложение от легитимного сервера, злоумышленник может рассылать DHCPOFFER непрерывно, чтобы сделавший запрос хост получил предложение немедленно. В этом случае также происходит «половинчатый» перехват.
Отметим, что если хост принимает предложения только от определенных серверов, то злоумышленник может легко выдать себя за один из таких серверов, установив соответствующие обратные адреса в датаграммах с DHCP-сообщениями.
Атака на протоколы маршрутизации
Если злоумышленник хочет перехватить трафик между узлами сети Р и узлами сети Q, и при этом не находится ни в одной из сетей P или Q, но расположен на пути между ними, он может попытаться ввести в заблуждение маршрутизаторы. Маршрутизаторы не реагируют на сообщения ICMP Redirect, поэтому для успешной атаки необходимо, чтобы они использовали какой-либо протокол маршрутизации. В этом случае злоумышленник может сформировать подложные сообщения протокола маршрутизации с целью переключения требуемых маршрутов на себя. Например (рис. 9.3) узел Х, приняв широковещательные RIP-сообщения, рассылаемые узлами А (вектор P=3) и В (вектор Q=2), отправляет сообщение с вектором Q=1 на индивидуальный адрес маршрутизатора А, а сообщение P=2 — на индивидуальный адрес В.
Рис. 9.3. Навязывание ложного RIP-маршрутизатора X
для перехвата трафика между сетями P и Q
Возможна ситуация, когда значение вектора, объявляемого, например, маршрутизатором В: Q=1. В этом случае Х не может немедленно предложить лучшего маршрута, но он может применить следующий прием. Сначала, выбрав паузу в рассылке RIP-сообщений маршрутизатором В, Х от имени В отправляет в А вектор Q=16, что заставит маршрутизатор А удалить из своей таблицы маршрут в сеть Q, так как до этого А отправлял датаграммы в Q через В. Сразу же вслед за этим Х отправляет вектор Q=1 от своего имени, и А устанавливает маршрут в сеть Q через Х. Последующие векторы Q=1 от В будут проигнорированы, поскольку они не предлагают лучшего маршрута.
IBGP-соседи для пересылки датаграмм друг другу могут пользоваться результатами работы внутреннего протокола маршрутизации, злоумышленник может предварительно атаковать протокол внутренней маршрутизации, замкнув на себя трафик между сетями, в которых находятся BGP-маршрутизаторы (например, это сети P и Q на рис. 9.3) и модифицируя данные BGP-соединения в своих целях.
Конечно, атака на протокол BGP выглядит трудноосуществимой, но, тем не менее, такие атаки возможны. Аутентификация TCP-сегментов с помощью алгоритма MD5 поможет избежать неприятностей.
Предположим, что узел А обменивается IP-датаграммами с узлом В, при этом узлы идентифицируют друг друга по IP-адресам, указываемым в датаграммах. Предположим далее, что узел В имеет особые привилегии при взаимодействии с А: то есть А предоставляет В некоторый сервис, недоступный для других хостов Интернета. Злоумышленник на узле Х, желающий получить такой сервис, должен имитировать узел В — такие действия называются имперсонацией узла В узлом Х.
Говоря о сервисах, мы имеем в виду приложения UDP или TCP, то есть речь идет об имперсонации UDP-сообщений или TCP-соединений (соответственно, UDP-spoofing и TCP-spoofing). Часто одновременно с имперсонацией злоумышленник предпринимает атаки типа «отказ в обслуживании» (п. 9.7) против узла В для исключения последнего из процесса сетевого взаимодействия.
Хосты А, В и Х могут располагаться друг относительно друга различным образом, от этого зависит, какие методы имперсонации применит злоумышленник.
Если злоумышленник может перехватить трафик, идущий от узла А к В (одним из методов, описанных в предыдущем пункте), то задача имперсонации практически выполнена. Получая от узла А UDP-сообщения или TCP-сегменты, адресованные узлу В, злоумышленник не передает их по назначению, а вместо этого сам формирует пакеты от имени В. При этом узел В даже не подозревает о происходящем, поэтому атаковать его на предмет отказа в обслуживании не имеет смысла.
Напомним, что перехват трафика возможен, когда:
1) А, В и Х находятся в одной IP-сети (ARP-атака);
2) А и Х находятся в одной сети, а В — в другой (навязывание ложного маршрутизатора);
3) А и В находятся в разных сетях, а Х находится на пути между ними (или включает себя в маршрут путем атаки на протокол маршрутизации).
В остальных случаях злоумышленник не может перехватить данные, передаваемые из А в В. По-прежнему ничто не мешает ему отправлять в адрес А сфальсифицированные датаграммы от имени В, но ответные пакеты А будет отправлять узлу В, минуя злоумышленника. Важным обстоятельством в этих условиях является то, имеет ли узел Х возможность подслушивать эти ответные пакеты, или же злоумышленник вынужден работать вслепую.
Рассмотрим самый сложный случай: перехват и прослушивание данных, отправляемых из А в В невозможны. Этот случай (рис. 9.4) является наиболее общим: узел Х находится в сети, не имеющей никакого отношения к узлам А и В и не лежащей между ними (А и В могут находиться как в одной, так и в разных сетях).
Рис. 9.4. Имперсонация без обратной связи
Подчеркнем, что имперсонация без обратной связи имеет смысл лишь тогда, когда злоумышленнику для достижения своей цели достаточно только передать данные на узел А от имени узла В, и последующий ответ узла А уже не имеет значения. Классическим примером такой атаки является отправка злоумышленником на порт сервера Rlogin TCP-сегмента, содержащего какую-либо команду операционной системе узла А. Узел А выполняет эту команду, полагая, что она поступила с узла В.
Если имперсонация UDP-сообщений без обратной связи остается тривиальной, злоумышленник должен только сфабриковать датаграмму, адресованную от узла В узлу А, и отправить ее по назначению, то в случае с TCP все обстоит не так просто. Прежде чем отправить узлу А сегмент с данными, узел Х должен установить с ним соединение от имени узла В. Напомним, как происходит установление соединения: узел Х от имени В отправляет в А сегмент с битом SYN, где указывает начальный номер ISN(В). Узел А отвечает узлу В SYN-сегментом, в котором подтверждает получение предыдущего сегмента, и устанавливает свой начальный номер ISN(A). Этот сегмент злоумышленник никогда не получит.
Здесь возникает две проблемы: во-первых, узел В, получив от А ответ на SYN-сегмент, который он никогда не посылал, отправит узлу А сегмент с битом RST, тем самым сводя к нулю усилия злоумышленника. Во-вторых, узел Х все равно не сможет отправить в А следующий сегмент (как раз это должен быть сегмент с данными), потому что в этом сегменте узел Х должен подтвердить получение SYN-сегмента от А, то есть поместить в поле ACK SN заголовка своего сегмента значение ISN(A)+1. Но злоумышленник не знает номера ISN(A), потому что соответствующий сегмент ушел к узлу В.
Первая проблема решается относительно просто: злоумышленник проводит против узла В атаку типа «отказ в обслуживании» с тем расчетом, чтобы узел В не был способен обрабатывать сегменты, приходящие из А. Например, можно поразить узел В шквалом SYN-сегментов от несуществующих узлов1 (подробнее об отказах в обслуживании см. п. 9.7). Впрочем, к облегчению злоумышленника, может оказаться, что узел В просто выключен.
Для решения второй проблемы злоумышленник должен уметь предсказывать значения ISN(A). Если операционная система узла А использует какую-либо функцию для генерации значений ISN (например, линейную зависимость от показания системных часов), то последовательно открыв несколько пробных соединений с узлом А и проанализировав присылаемые в SYN-сегментах от А значения ISN, злоумышленник может попытаться установить эту зависимость опытным путем.
Хорошая реализация TCP должна использовать случайные числа для значений ISN (более подробное обсуждение этого вопроса можно найти в RFC-1948). Несмотря на кажущуюся простоту этого требования, проблема с угадыванием номеров ISN остается актуальной и по сей день2.
Итак, приведем схему атаки для имперсонации TCP-соединения без обратной связи (рис. 9.5).
Рис. 9.5. Схема атаки с имперсонацией TCP-соединения без обратной связи
Злоумышленник Х, находящийся в одном сегменте сети с узлами А и В или на пути между А и В, может произвести десинхронизацию TCP-соединения между А и В для установления полного контроля над соединением, то есть, злоумышленник получит возможность действовать как от имени А, так и от имени В. Для обозначения имперсонации, выполняемой таким методом, в англоязычной литературе используется термин TCP hijacking. Впервые эта атака была описана в [Joncheray].
Определим, что такое десинхронизация TCP-соединения. При установленном соединении каждый из узлов А и В знает, октеты с какими номерами может прислать ему собеседник в данный момент: если последнее подтверждение, высланное узлом А, было ACKAB и при этом узел А объявил окно WAB, то А ожидает от В октетов с номерами SNBA, попадающими в объявленное окно, то есть:
ACKAB <= SNBA <= ACKAB + WAB
Аналогично в узле В ожидается от А:
ACKBA <= SNAB <= ACKBA + WBA
Если, например, узел А по какой-то причине получает от В сегмент с номером SNBA, не попадающим в окно, то этот сегмент уничтожается, а в ответ А отправляет в В сегмент с SNAB, ACKAB, WAB, чтобы указать узлу В, какие именно октеты ожидает получить А. Отметим, что скорее всего этот сегмент не содержит данных, но номер SNAB в этом сегменте тем не менее должен быть указан, где SNAB — номер следующего октета данных, который А когда-либо вышлет в В.
Предположим, злоумышленнику каким-то образом удалось сбить показатели счетчиков узлов А и (или) В так, что вышеприведенные неравенства больше не выполняются (как это можно сделать, мы обсудим ниже). Далее мы будем использовать обозначения вида SNAB(B), что означает «приемлемый SNAB с точки зрения В».
Теперь, если В посылает в А сегмент с неким номером SNBA(B), адекватным с точки зрения В, но уже не попадающим в окно в узле А, то А возвращает узлу В подтверждение со своим значением ACKAB=SNBA(A). Однако в этом же сегменте имеется номер SNAB(A), который теперь уже В рассматривает как не попадающий в свое окно и отправляет в А подтверждение SNBA(B), ACKBA=SNAB(A). Номер SNBA(B), как и раньше, неприемлем для А, и узел А вновь отправляет в В подтверждение, и этот цикл, называемый ACK-шторм, теоретически продолжается до бесконечности, а практически — до тех пор, пока один из ACK-сегментов не потеряется в сети. Чем сильнее шторм, тем больше загрузка сети, тем выше процент потерь, следовательно, тем быстрее шторм прекратится.
Итак, в десинхронизированном состоянии любая попытка обмена данными вызывает только ACK-шторм, а сами сегменты с данными участниками соединения уничтожаются.
В это время злоумышленник, знающий «правильные» номера с точки зрения обоих узлов, берет на себя функции посредника (рис. 9.6). Он прослушивает сеть, обнаруживает сегмент с данными длиной L октетов, направленный, например, из А в В, меняет в нем номер SNAB(A) на ожидаемый узлом В номер SNAB(B) и, пересчитав контрольную сумму, отправляет сегмент в В от имени А. После этого в узел А от имени В злоумышленник отправляет подтверждение на этот сегмент, содержащее правильный с точки зрения А номер SNBA(A). Во время этого обмена в виде побочного явления возникают два ACK-шторма: первый инициирует узел В, получивший из А оригинальный сегмент с SNAB(A) != SNAB(B), а второй шторм возникает, когда узел А получает от В сегмент, подтверждающий получение данных от Х, и в этом сегменте SNBA(B) != SNBA(A).
Разумеется, злоумышленник затевает атаку не для того, чтобы просто ретранслировать сегменты, которые он и так может подслушать. Ничто не мешает ему изменять содержащиеся в сегментах данные или добавлять свои: на рис. 9.6 это отображено в виде «данных 2», имеющих длину L2 октетов, в то время как оригинальные данные обозначены «данные 1» длиной L1 октетов. Например, если имеет место сессия программы telnet и А посылает в В некоторую команду, то злоумышленник может вставить в этот сегмент еще одну команду. Результат выполнения своей команды он получит, подслушав ответный сегмент SNBA(B), направленный из В в А, который узел А не воспримет из-за несовпадения порядковых номеров, так как SNBA(B) != SNBA(A). Зато злоумышленник, удалив из этого сегмента результат выполнения своей команды, отправит то, что осталось (то есть результат оригинальной команды) в А от имени В уже с приемлемым порядковым номером SNBA(A).
Злоумышленник может вообще игнорировать сегменты, посылаемые узлом А и отправлять в В только свои данные, получая ответы прослушиванием сети и соответственно реагируя на них, но в этом случае узел А заметит, что В не отвечает на его команды, и может забеспокоиться.
Рассмотрим, каким образом злоумышленник может перевести TCP-соединение в десинхронизированное состояние.
Ранняя десинхронизация
Ранняя десинхронизация (рис. 9.7): злоумышленник, прослушивая сеть, обнаруживает момент установления соединения между А и В, от имени А сбрасывает соединение RST-сегментом и тут же открывает его заново, но уже с новыми номерами ISN. Разберем эту процедуру в деталях.
Сначала А посылает в В сегмент SYNAB, ISNAB(A), потом В отвечает сегментом SYNBA, ISNBA(1), ACKBA(ISNAB(A)+1). По получении этого сегмента А переходит в состояние ESTABLISHED и посылает в В подтверждающий сегмент ACKAB(ISNBA(1)+1).
В этот момент злоумышленник от имени А отправляет в В сегмент RSTAB и следом за ним сегмент SYNAB, ISNAB(X), содержащий те же номера портов, но другой номер ISNAB= ISNAB(X), неприемлемый для А.
При получении этих сегментов узел В закрывает установленное соединение с А, а затем тут же вновь отрывает его и отправляет в А сегмент SYNBA, ISNBA(2), ACKBA(ISNAB(Х)+1), где ISNBA(2) — новый начальный порядковый номер, ISNBA(1) != ISNBA(2).
Узел А не воспринимает этот сегмент из-за несовпадения порядковых номеров, но злоумышленник от имени А посылает в В сегмент SNAB=ISNAB(Х)+1, ACKAB(ISNBA(2)+1).
Рис. 9.7. Ранняя десинхронизация TCP-соединения
(сегменты ACK-шторма не показаны)
После этого оба узла А и В находятся в состоянии ESTABLISHED, но соединение десинхронизировано (рис. 9.8).
Отметим, что некоторые реализации TCP в нарушение стандарта в ответ на получение RST-сегмента сами отправляют RST-сегмент. В этом случае десинхронизация описанным способом невозможна.
Десинхронизация нулевыми данными
Десинхронизация нулевыми данными (рис. 9.9): злоумышленник, дожидаясь момента, когда соединение находится в неактивном состоянии (данные не передаются), посылает узлу А от имени В и узлу В от имени А фальсифицированные сегменты с данными, вызывая тем самым десинхронизацию. Посылаемые данные должны быть «нулевыми» — то есть приложение-получатель должно их молча игнорировать и не посылать никаких данных в ответ. Этот метод десинхронизации подходит для Telnet-соединений, которые, во-первых, часто находятся в неактивном состоянии, а во-вторых, в протоколе Telnet имеется команда «нет операции» (IAC NOP). Сегмент, содержащий произвольное число таких команд (IAC NOP IAC NOP …), будет принят приложением и полностью проигнорирован.
Кроме того, в начале Telnet-сеанса производится аутентификация пользователя. Ра-зумно (с точки зрения злоумышленника) произвести десинхронизацию после того, как введен пароль, а не в самом начале соединения. Отметим, что даже использование одноразовых паролей в этом случае пользователю не поможет.
Рис. 9.9. Десинхронизация TCP-соединения нулевыми данными
(сегменты ACK-шторма не показаны)
После описанной процедуры имеет место следующая ситуация, показанная на рис. 9.10.
Рис. 9.10. Состояние соединения после десинхронизации нулевыми данными
Имперсонация с помощью десинхронизации является сравнительно простой и очень эффективной атакой. Она позволяет злоумышленнику установить полный контроль над TCP-соединением без использования ложных сообщений ARP, ICMP или протоколов маршрутизации, без атак типа «отказ в обслуживании», которые могут быть обнаружены администратором сети или атакуемого узла. Обнаружить такие атаки можно, прослушивая сеть на предмет ACK-штормов.
Для защиты от описанных в этом пункте атак маршрутизатор (шлюз, брандмауэр), соединяющий сеть с внешним миром, должен быть настроен на запрет пропуска пакетов;
а) приходящих на внешний интерфейс, но имеющих адрес отправителя из внутренней сети;
б) приходящих на внутренний интерфейс, но имеющих адрес отправителя из внешней сети.
Случай а) соответствует ситуации, когда узлы А и В находятся во внутренней сети, а злоумышленник расположен снаружи и пытается послать узлу А датаграмму якобы от узла В. Случай б) соответствует ситуации, когда злоумышленник находится во внутренней сети, а узлы А и В — снаружи. Подчеркнем, что предложенные меры не защитят от всех разновидностей имперсонации: например, когда узел Х находится в одной сети с узлом А или В, или, естественно, когда все три узла расположены в одной сети.
Хороший алгоритм генерации случайных номеров ISN защитит от атаки в случае отсутствия обратной связи, но бесполезен, если злоумышленник может видеть сегменты, передаваемые из А в В.
В общем случае только шифрование данных или аутентификация сегментов могут гарантировать защиту от имперсонации.
Для незаконного подключения к сети злоумышленник, разумеется, должен иметь физическую возможность такого подключения. В крупных корпоративных и особенно университетских сетях такая возможность часто имеется. Следующим шагом для злоумышленника является конфигурирование параметров стека 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-адреса, то обнаружить такого злоумышленника будет невозможно и все его действия будут приписаны атакованному хосту.
С целью обеспечения безопасности внутренней (корпоративной) сети на шлюзе могут использоваться фильтры, препятствующие прохождению определенных типов датаграмм. Датаграммы могут фильтроваться по IP-адресам отправителя или получателя, по протоколу (поле Protocol IP-датаграммы), по номеру порта TCP или UDP, по другим параметрам, а также по комбинации этих параметров.
В этом пункте мы рассмотрим два приема, которые может использовать злоумышленник для проникновения через некоторые фильтры.
Предположим, злоумышленник хочет отправить данные с узла Х узлу А, находящемуся за пределами его сети, однако правила фильтрации на маршрутизаторе запрещают отправку датаграмм узлу А (рис. 9.11). В то же время разрешена отправка датаграмм узлу В, также находящемуся за пределами охраняемой сети.
Злоумышленник использует узел В как ретранслятор датаграмм, направленных в А. Для этого он создает датаграмму, направленную из Х в В, в поле Protocol которой помещается значение 4 («IP»), а в качестве данных эта датаграмма несет другую IP-датаграмму, направленную из Х в А. Фильтрующий маршрутизатор пропускает сформированную датаграмму, поскольку она адресована разрешенному узлу В, а IP-модуль узла В извлекает из нее вложенную датаграмму. Видя, что вложенная датаграмма адресована не ему, узел В отправляет ее по назначению, то есть узлу А (рис. 9.11).
Описанная операция называется туннелированием. Для ее осуществления злоумышленник может иметь, а может и не иметь сговора с узлом В — в зависимости от того, что представляет собой этот узел и как он сконфигурирован. Если В является маршрутизатором, то он может обрабатывать вложенные датаграммы без всякого сговора со злоумышленником, если только администратор не заблокировал такую возможность.
Того же самого результата можно добиться, применив IP-опцию Loose/Strict Source Routing.
Рис. 9.11. Туннелирование сквозь фильтрующий маршрутизатор
Отметим, что адрес отправителя датаграммы скрыть нельзя, поэтому, если маршрутизатор не пропускает также датаграммы, идущие из А, то есть осуществляет фильтрацию по адресу отравителя, то обмануть его вышеописанным способом невозможно. В этом случае злоумышленник имеет только одностороннюю связь с узлом А.
Очевидно, что туннелирование может использоваться и в обратном направлении, то есть, для проникновения из Интернета внутрь охраняемой сети. При этом узел Х находится в Интернете, а узлы А и В — в охраняемой сети и узлу В разрешено получение датаграмм из внешних сетей.
Для защиты от туннелирования следует запретить маршрутизатору транслировать во внешнюю сеть датаграммы с полем Protocol=4 и датаграммы с опциями. Напомним, что туннелирование используется для подключения сетей, поддерживающих групповую рассылку, к сети MBONE через сети, не поддерживающие групповую маршрутизацию. В этом случае все маршрутизаторы защищаемой (внутренней) системы сетей должны поддерживать групповую маршрутизацию, а инкапсуляция и извлечение групповых датаграмм должны выполняться непосредственно на фильтрующем маршрутизаторе.
В случае, когда на вход фильтрующего маршрутизатора поступает фрагментированная датаграмма, маршрутизатор производит досмотр только первого фрагмента датаграммы (первый фрагмент определяется по значению поля IP-заголовка Fragment Offset=0). Если первый фрагмент не удовлетворяет условиям пропуска, он уничтожается. Остальные фрагменты можно безболезненно пропустить, не затрачивая на них вычислительные ресурсы фильтра, поскольку без первого фрагмента датаграмма все равно не может быть собрана на узле назначения.
При конфигурировании фильтра перед сетевым администратором часто стоит задача: разрешить соединения с TCP-сервисами Интернет, инициируемые компьютерами внутренней сети, но запретить установление соединений внутренних компьютеров с внешними по инициативе последних. Для решения поставленной задачи фильтр конфигурируется на запрет пропуска TCP-сегментов, поступающих из внешней сети и имеющих установленный бит SYN в отсутствии бита ACK; сегменты без этого бита беспрепятственно пропускаются в охраняемую сеть, покольку они могут относиться к соединению, уже установленному ранее по инициативе внутреннего компьютера.
Рассмотрим, как злоумышленник может использовать фрагментацию, чтобы обойти это ограничение, то есть, передать SYN-сегмент из внешней сети во внутреннюю.
Злоумышленник формирует искусственно фрагментированную датаграмму с TCP-сегментом, при этом первый фрагмент датаграммы имеет минимальный размер поля данных — 8 октетов (напомним, что размеры фрагментов указываются в 8-октетных блоках). В поле данных датаграммы находится TCP-сегмент, начинающийся с TCP-заголовка. В первых 8 октетах TCP-заголовка находятся номера портов отправителя и получателя и поле Sequence Number, но значения флагов не попадут в первый фрагмент. Следовательно, фильтр пропустит первый фрагмент датаграммы, а остальные фрагменты он проверять не будет. Таким образом, датаграмма с SYN-сегментом будет успешно доставлена на узел назначения и после сборки передана модулю TCP.
На рис. 9.12 пример датаграммы из 2 фрагментов (IP-заголовки выделены серым). В поле данных первого фрагмента находится 8 октетов TCP-заголовка. В поле данных второго фрагмента помещена остальная часть TCP-заголовка с флагом SYN.
Рис. 9.12. Фрагментированный TCP-сегмент
Описанный выше прием проникновения сквозь фильтр называется «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-сегмент и состоящей из двух фрагментов (рис. 9.13, IP-заголовок выделен серым цветом). В поле данных первого фрагмента находится полный TCP-заголовок, без опций, дополненный нулями до размера, кратного восьми октетам. В поле данных второго фрагмента — часть другого TCP-заголовка, начиная с девятого по порядку октета, в котором установлен флаг SYN.
Видно, что второй фрагмент накладывается на первый (первый фрагмент содержит октеты 0–23 данных исходной датаграммы, а второй фрагмент начинается с октета 8, потому что его Fragment Offset=1). Поведение узла назначения, получившего такую датаграмму, зависит от реализации модуля IP. Часто при сборке датаграммы данные второго, накладывающегося фрагмента записываются поверх предыдущего фрагмента. Таким образом, при сборке приведенной в примере датаграммы в TCP-заголовке переписываются поля начиная с ACK SN в соответствии со значениями из второго фрагмента, и в итоге получается SYN-сегмент.
Рис. 9.13. Накладывающиеся фрагменты
Если для защиты от Tiny Fragment Attack применяется подход 1) из описанных выше (инспекция первого фрагмента датаграммы), то с помощью накладывающихся фрагментов злоумышленник может обойти эту защиту.
Маршрутизатор, применяющий второй подход, будет успешно противостоять Tiny Fragment Attack с накладывающимися фрагментами.
Механизм реагирования на заторы сети (congestion control), реализуемый протоколом TCP (RFC-2581), позволяет злоумышленнику-получателю данных принудить отправителя высылать данные с многократно увеличенной скоростью [Savage]. В результате злоумышленник отбирает для своих нужд ресурсы сервера-отправителя и компьютерной сети, замедляя или блокируя соединения прочих участников сетевого взаимодействия.
Атаки выполняются путем специально организованной посылки злоумышленником подтверждений приема данных (ACK-сегментов). Все описываемые в этом пункте атаки эксплуатируют следующее неявное допущение, заложенное в протокол TCP: один участник TCP-соединения полностью доверяет другому участнику в том, что тот действует в строгом соответствии с теми же спецификациями протокола, что и первый.
В следующих подпунктах мы будем считать, что узел А отправляет данные узлу В, а последний пытается принудить узел А передавать данные на завышенной скорости.
Пусть узел А, после установления соединения, находится в режиме медленного старта. Окно перегрузки cwnd равно одному полноразмерному сегменту, который и высылается в В (рис. 2.91). Однако В, вместо того, чтобы ответить одним подтверждением о получении всего сегмента (ACK SN=1001), высылает несколько подтверждений с возрастающими номерами ACK SN (например, 300, 600 и, наконец, 1001), как бы подтверждая получение сегмента по частям.
Отметим, что стандарт TCP при этом не нарушается, потому что в TCP подтверждается получение октетов, а не сегментов. Однако алгоритм медленного старта неявно подразумевает, что получатель посылает не более одного подтверждения при получении каждого очередного сегмента, и, как следствие, окно cwnd увеличивается на один полноразмерный сегмент с приходом каждого подтверждения, независимо от того, получение какого числа октетов оно подтверждает.
В итоге при нормальном поведении узла В отправитель на следующем шаге увеличил бы окно cwnd только на 1 сегмент и отправил бы в В два следующих полноразмерных сегмента (SN=1001 и 2001). Но узел В, выслав три подтверждения вместо одного, вынудил узел А увеличить значение cwnd до 4 и отправить 4 сегмента вместо двух.
В общем случае, если полноразмерный сегмент содержит N октетов, то узел В может отправить M <= N подтверждений. Простые арифметические подсчеты показывают, что тогда на i-м шаге (то есть через время RTT*i, где RTT — время обращения) узел А будет отправлять не N*2i октетов, как это было бы при нормальном поведении получателя, а порядка N*Mi октетов, если, конечно, узел В позаботится об объявлении подобающего размера окна получателя. Типичный размер поля данных сегмента — 1460 октетов. Наиболее агрессивное поведение получателя (1460 подтверждений на каждый сегмент) теоретически приведет к тому, что уже после третьего шага узел В может получить 2,9 Гбайт данных. Разумеется, скорость не может расти бесконечно — она будет ограничена возможностями сети и узла-отправителя.
Опять рассмотрим ситуацию, когда узел А находится в медленном старте после установления соединения. А отправляет в В один сегмент (SN=1–1000), но узел В, вместо того чтобы ответить подтверждением ACK SN=1001, отвечает серией сфабрикованных подтверждений ACK SN=1 (рис. 9.15).
Получение дубликатов подтверждений включает на узле А алгоритмы быстрой повторной передачи (fast retransmit) и быстрого восстановления (fast recovery). Последний из них представляет в данном случае особый интерес. Напомним, что алгоритм быстрого восстановления базируется на предположении, что каждый полученный дубликат предыдущего подтверждения, кроме того, что говорит о потере сегмента, также подразумевает, что какой-то другой полноразмерный сегмент покинул сеть. Вследствие этого окно cwnd, измеряемое в полноразмерных сегментах, временно увеличивается на число полученных дубликатов, пока не придет подтверждение, отличное от предыдущих.
Поскольку сам дубликат подтверждения не несет никакой информации о том, получение какого именно сегмента вызвало отправку данного дубликата, ничто не может уберечь отправителя от ложных дубликатов подтверждений, сгенерированных получателем. Таким образом, получатель заставляет отправителя необоснованно увеличить окно cwnd и ускорить отправку данных.
Фактически узел А будет отправлять данные со скоростью, с которой В генерирует дубликаты подтверждений. В какой-то момент в узле А сработает таймер повторной передачи для сегмента SN=1–1000, поскольку он так и не был подтвержден. Узел В отреагирует на это посылкой кумулятивного подтверждения на все полученные к этому моменту данные и переключится на генерацию ложных дубликатов этого последнего подтверждения, снова вынуждая отправителя необоснованно увеличивать cwnd.
Еще одна разновидность атаки строится на том, что получатель может заранее высылать подтверждения еще не принятых им, находящихся в пути сегментов, заставляя отправителя поверить, что данные уже доставлены, результатом чего будет увеличение 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%, как было раньше.
Атаки типа «отказ в обслуживании» (DoS, denial of service), по-видимому, являются наиболее распространенными [Moore] и простыми в исполнении. Целью атаки является приведение атакуемого узла или сети в такое состояние, когда передача данных другому узлу (или передача данных вообще) становится невозможна или крайне затруднена. Вследствие этого пользователи сетевых приложений, работающих на атакуемом узле, не могут быть обслужены — отсюда название этого типа атак. Атаки DoS используются как в комплексе с другими (имперсонация, п. 9.3), так и сами по себе.
DoS-атаки можно условно поделить на три группы:
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. В последнее время было показано, что большое число соединений в состояниях 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 (см. CERT Incident Note IN-99-07).
Ложные DHCP-клиенты
Атака состоит в создании злоумышленником большого числа сфальсифицированных запросов от различных несуществующих DHCP-клиентов. Если DHCP-сервер выделяет адреса динамически из некоторого пула, то все адресные ресурсы могут быть истрачены на фиктивных клиентов, вследствие чего легитимные хосты не смогут сконфигурироваться и лишатся доступа в сеть.
Для защиты от этой атаки администратору следует поддерживать на DHCP-сервере таблицу соответствия MAC- и IP-адресов (если это возможно); сервер должен выдавать IP-адреса в соответствии с этой таблицей.
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-системы, в которых в прикладном процессе не была предусмотрена возможность приема срочных данных, что приводило к краху системы.
Перенаправление трафика на несуществующий узел
В п. 9.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-соединения была рассмотрена в п. 9.3. Очевидно, что если после выполнения десинхронизации злоумышленник не будет функционировать в качестве посредника, то передача данных по атакованному 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 следует ликвидировать соединение, к которому это сообщение относится4.
Принуждение к передаче данных на заниженной скорости
Злоумышленник может вынудить модуль TCP узла А снизить скорость передачи данных узлу В в TCP-соединении следующими способами.
В этом пункте сведены воедино указанные выше по ходу изложения меры безопасности, которые могут помочь в борьбе с атаками, описанными в настоящей главе. Системный администратор, исходя из политики сетевой безопасности в своей организации, и имея четкое представление о возможных инцидентах и их последствиях, определит, какие меры являются необходимыми и приемлемыми для его сети.
Фильтры на маршрутизаторе, соединяющем сеть предприятия с Интернетом, применяются для запрета пропуска датаграмм, которые могут быть использованы для атак как на сеть организации из Интернета, так и на внешние сети злоумышленником, находящимся внутри организации.
Отметим, что более безопасным и управляемым решением, чем фильтрация того или иного TCP-трафика следующего от или к компьютеру пользователя, является работа пользователей через прокси-серверы. Прокси-сервер берет на себя функции предоставления пользователю требуемого сервиса и сам связывается с необходимыми хостами Интернета. Хост пользователя же взаимодействует только с прокси-сервером и не нуждается в коннективности с Интернетом. Таким образом, фильтрующий маршрутизатор разрешает прохождение TCP-сегментов определенного типа только от или к прокси-серверу. Преимущества этого решения следующие.
Прокси-сервер находится под контролем администратора предприятия, что позволяет реализовывать различные политики для дифференцированного управления доступом пользователей к сервисам и ресурсам Интернета, фильтрации передаваемых данных (защита от вирусов, цензура и т.п.), кэширования (там, где это применимо).
С точки зрения Интернета от имени всех пользовательских хостов предприятия действует один прокси-сервер, то есть имеется только один потенциальный объект для атаки из Интернета, а безопасность одного прокси-сервера, управляемого профессионалом, легче обеспечить, чем безопасность множества пользовательских компьютеров.
Анализ сетевого трафика проводится для обнаружения атак, предпринятых злоумышленниками, находящимися как в сети организации, так и в Интернете.
Мероприятия по защите маршрутизатора проводятся с целью предотвращения атак, направленных на нарушение схему маршрутизации датаграмм или на захват маршрутизатора злоумышленником.
Мероприятия по защите хоста проводятся для предотвращения атак, цель которых — перехват данных, отказ в обслуживании, или проникновение злоумышленника в операционную систему.
Администратор сети должен знать и использовать методы и инструменты злоумышленника и проводить превентивное сканирование сети организации для обнаружения слабых мест в безопасности до того, как это сделает злоумышленник. Для этой цели имеется также специальное программное обеспечение — сканеры безопасности, network security scanners, типа Nessus.
[Bellovin] Bellovin S.M. "Security Problems in the TCP/IP Protocol Suite" // Computer Communications Review, Vol. 19, No. 2, pp. 32-48, April 1989.
[McDanel] McDanel, B. "TCP Timestamping - Obtaining System Uptime Remotely" // Bugtraq, March 11, 2001.
[Zalewski] Zalewski M. "Strange Attractors and TCP/IP Sequence Number Analysis", April 2001.
[Newsham] Newsham, T. "Guardent White Paper: The Problem with Random Increments", February 2001.
[Joncheray] Joncheray L. "A Simple Active Attack Against TCP" // Proceedings of 5th USENIX UNIX Security Symposium, June 1995.
[Savage] Savage S., Cardwell N., Wetherall D., Anderson T. "TCP Congestion Control with a Misbehaving Receiver" // ACM Computer Communications Review, Vol. 29, No. 5, pp. 71-78, October 1999.
[Moore] Moore D., Voelker G.M., Savage S. "Inferring Internet Denial-of-Service Activity" // Proceedings of 10th USENIX UNIX Security Symposium, August 2001.
[Vetter] Vetter B., Wang F., Wu S.F. "An experimental study of insider attacks on the OSPF routing protocol" // IEEE International Conference on Network Protocol (ICNP), pp. 293-300, Atlanta, USA, October 1997.
[Wang] Wang F., Gong F., Wu S.F. Narayan R. "Intrusion Detection for Link State Routing Protocol Through Integrated Network Management" // Proc. of Eighth International Con-ference on Computer Communications and Networks, Boston, October 1999.
Purdue University CERIAS Security Archive. Разные программы.
Libnet. Библиотека для формирования кадров и даfтаграмм произвольного формата.
Libpcap. Библиотека для извлечения пакетов из сети (используется также программой tcpdump).
OpenSSL. Библиотека для поддержки SSL.
Tcpdump. Программа для прослушивания сети (sniffer).
Tcptrace. Программа для анализа и конвертирования дамп-файлов, записанных различными программами прослушивания.
AntiSniff. Программа для обнаружения в сети узлов, находящихся в режиме прослушивания.
Nmap. Сканер сети.
Nessus. Сканер для обнаружения проблем с безопасностью в сети. Использует nmap.
Nemesis. Программа для формирования сообщений различных протоколов.
Arpwatch. Программа для обнаружения несоответствия между IP- и MAC-адресами в сети.
Snort. NIDS (система обнаружения атак в сети).
SOCKS. Универсальный прокси-сервер для TCP-сервисов (reference implementation).
TCP wrappers. Программа мониторинга и фильтрации запросов на установление TCP-соединений через супердемон inetd.
Tcplogd. Программа для обнаружения попыток сканирования хоста.
Tripwire. Утилита для отслеживания изменений в файловой системе.
Xinetd. Супердемон для замены inetd. Осуществляет фильтрацию соединений и уменьшает риск DoS атак.
Tcpserver. Еще один вариант замены супердемона inetd.
SSH, OpenSSH, FreeSSH. Реализации протокола SSH - защищенного варианта Telnet + FTP.
Kerberos. Система распределенной аутентификации в сети.
Swatch. Утилита слежения за лог-файлами протоколов.
THE END