Узлы под воздействием атак

Конечно, очень важно понимать, как предотвратить возможность использования узла в качестве усилителя атаки, однако еще важнее разобраться в том, как определить, что узел уже используется для этих целей. Как упоминалось в предыдущих главах, нужно ограничить возможность поступления данных ICMP и UDP лишь заданных типов и только на требуемые узлы. Причем это нужно обеспечить на пограничных маршрутизаторах. Естественно, такая мера не позволит защититься от атак Smurf и Fraggle, приводящих к насыщению полосы пропускания. Гораздо лучше обратиться к провайдеру услуг Internet и совместными усилиями максимально ограничить входящий трафик ICMP. Эти защитные меры можно усилить с помощью режима CAR (Committed Access Rate — допустимая частота обращений), который можно установить на устройствах Cisco IOS 1.1СС, 11.ICE и 12.0. Это позволит ограничить трафик ICMP некоторой разумной величиной, например 256 или 512 Кбайт.
Обнаружив, что узел задействован в атаке, нужно сразу же связаться с сетевым центром провайдера услуг Internet. He забывайте, что выявить источник атаки трудно, но все же возможно. Для этого в процессе тесного сотрудничества с провайдером понадобится тщательно исследовать уязвимый узел, поскольку именно он является получателем ложных пакетов. Помните о том, что если узел принимает участие в атаке, то генерируемые им пакеты ничем не отличаются от остальных сетевых пакетов.
Систематизированный анализ каждого маршрута в обратном направлении, начинающийся с усиливающего узла, позволит выявить сеть, из которой была предпринята атака. При этом понадобится отслеживать каждый сегмент пути, пройденный ложным пакетом. Для автоматизации этого процесса группа специалистов по вопросам безопасности MCI разработала сценарий dostracker на языке Perl, который после помещения на маршрутизаторе Cisco сразу же приступит к отслеживанию маршрута в обратном направлении вплоть до выявления источника атаки. К сожалению, эта программа окажется гораздо менее полезной, если у вас нет доступа ко всем маршрутизаторам, задействованным в атаке.
Мы также рекомендуем обратиться к документу RFC 2267, Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing (Фильтрация сетевых вторжений: защита от атак DoS с применением ложных исходных IP-адресов), авторами которого являются Пауль Фергюсон (Paul Ferguson) из компании Cisco Systems и Даниель Сени (Daniel Senie) из компании Blazenet, Inc.

Атака с помощью переполнения пакетами SYN

До того как атака Smurf не стала такой популярной, наиболее разрушительной считалась атака с помощью переполнения пакетами SYN. Упоминавшаяся в начале этой главы атака на компанию PANIX является прекрасным примером реализации такой атаки. Давайте подробно разберемся с тем, что же происходит в этом случае.
Как уже упоминалось, инициализация соединения TCP представляет собой процесс, состоящий из трех шагов (рис. 12.1).

Рис. 12.1. Соединение SYN

В обычной ситуации пакет SYN отсылается с определенного порта системы А на конкретный порт системы в, который находится в состоянии LISTEN. В этот момент потенциальное соединение системы в находится в состоянии SYN_RECV. На этой стадии система в передает системе А пакет SYN/ACK. Если процесс проходит нормально, система А передает обратно пакет АСК и соединение переходит в состояние ESTABLISHED.
Описанный механизм прекрасно работает в большинстве случаев, однако некоторые из его изъянов позволяют взломщику сгенерировать условие DoS. Проблема заключается в том, что большинство систем заранее выделяет некоторое количество ресурсов при установке потенциального (potential) соединения, т.е. соединения, которое еще не полностью установлено. Несмотря на то что многие системы могут поддерживать тысячи параллельных соединений с определенным портом (например, 80), достаточно дюжины или около того потенциальных запросов на соединение, чтобы израсходовать все доступные ресурсы. Именно этот механизм и применяется взломщиком для атаки с помощью переполнения пакетами SYN.
В начале атаки SYN взломщик тоже передает пакет SYN с системы А системе В, однако при этом в качестве исходного адреса указывает ложный адрес несуществующего узла. После этого система А посылает пакет SYN/ACK по ложному адресу. Если узел по этому адресу существует, то системе В обычно обратно отсылается пакет RST, поскольку этот узел не инициировал установку соединения. Однако не забывайте о том, что взломщик наверняка выбрал недостижимую систему. Следовательно, после того, как система в отправила пакет SYN/ACK, она никогда не получит ответного пакета RST от системы А. Это потенциальное соединение останется в состоянии SYN_RECV и будет помешено в очередь на установку соединения. Из этой очереди потенциальное соединение может быть удалено лишь после истечения выделенного промежутка времени. Этот промежуток времени в каждой системе различен, однако он не может быть меньше 75 секунд, а в некоторых реализациях протокола IP минимальный интервал может достигать 23 минут. Поскольку очередь на установку соединения обычно имеет небольшой размер, взломщику достаточно отправить несколько пакетов SYN с интервалом 10 секунд, чтобы полностью заблокировать определенный порт.
У вас, очевидно, уже давно возник вопрос: "А почему эта атака является такой разрушительной"? Во-первых, для ее успешной реализации достаточно небольшой полосы пропускания. Для нарушения работоспособности промышленного Web-сервера злоумышленнику достаточно модемной линии связи 14.4 Кбит/с. Во-вторых, подобная атака является скрытой, поскольку взломщики при рассылке пакетов SYN используют ложный исходный адрес. Это значительно затрудняет идентификацию источника нападения. По иронии судьбы эта атака уже несколько лет назад была предсказана многими экспертами по вопросам безопасности.

Контрмеры: защита от атак с использованием пакетов SYN

Чтобы определить, подвержена ли атаке ваша система, можно воспользоваться командой netstat, если она поддерживается операционной системой. Многочисленные соединения в состоянии SYN_RECV свидетельствуют о том, что именно в этот момент проводится атака.
Далее приводятся четыре основных способа защиты от атак с использованием пакетов SYN. Хотя каждый из подходов имеет свои достоинства и недостатки, все они способны снизить воздействие сфокусированной атаки SYN. Не забывайте о сложности выявления злоумышленника, поскольку он использует ложный исходный адрес. Однако в решении этой задачи может помочь утилита dostracker группы MCI (если вы имеете доступ к маршрутизаторам каждого сегмента пути).

Увеличение размера очереди на установку соединений

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

Уменьшение периода ожидания установки соединения

Сокращение интервала ожидания установки соединения также поможет снизить влияние атаки. Тем не менее, это тоже не самое оптимальное решение проблемы.

Использование пакетов обновления программного обеспечения и защита от потенциальных атак SYN

Как следует из названия подраздела, большинство современных операционных систем имеет встроенные механизмы выявления и предотвращения атак с использованием пакетов SYN. Для получения перечня таких операционных систем и соответствующих модулей обновления читайте отчет СА-96:21 группы CERT TCP SYN Flooding and IP Spoofing Attacks.
Поскольку атаки SYN получили в глобальной сети широкое распространение, были разработаны и другие решения проблемы атак DoS. Например, современное ядро системы Linux версии 2.0.30 и более поздних версий имеет режим SYN cookie. Если этот режим включен, ядро будет выполнять выявление и регистрацию возможных атак SYN. После этого будет использоваться криптографический протокол, известный под названием SYN cookie, который позволит легитимным пользователям устанавливать соединение даже в процессе предпринятой атаки.
В других операционных системах, например Windows NT с установленным сервисным пакетом SP2 или более поздними, реализован динамический механизм выделения ресурсов (см. статью базы данных Microsoft Q142641). Когда длина очереди на установку соединений достигает некоторого предопределенного порога, система автоматически выделяет дополнительные ресурсы. Так что очередь никогда не будет переполнена.

Использование сетевых систем IDS

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

Атаки DNS

В 1997 году группа специалистов по вопросам безопасности Secure Networks, Inc. (SNI), которая в настоящее время называется Network Associates, Inc. (NAI), опубликовала отчет о различных изъянах реализации BIND (Berkeley Internet Name Domain) системы DNS (NAI-0011, BIND Vulnerabilities and Solutions). Версии BIND до 4.9.5.+Р1 могут кэшировать фиктивную информацию, если активизирован режим рекурсии. Этот режим позволяет серверу имен обрабатывать запросы на получение данных о зонах и доменах, которые он не обслуживает. Когда серверу имен приходит запрос на получение информации о неизвестной зоне или домене, он перенаправляет запрос авторизованному серверу имен этого домена. После получения ответа от этого сервера первый сервер имен передает полученные данные обратно узлу, сгенерировавшему запрос.
К сожалению, если режим рекурсии активизирован в уязвимых версиях BIND, взломщик может модифицировать буфер сервера имен, выполняющего рекурсивный поиск. Эта ситуация известна как обман записи PTR (PTR record spoofing). При этом атака направлена на процесс преобразования IP-адресов в имена узлов. Несмотря на то что атака основывается на использовании доверительных отношений между узлами, все же сохраняется возможность генерации условия DoS системы DNS. Например, взломщик может попробовать "убедить" целевой сервер имен поместить в свой буфер данные, отображающие имя www.abccompany.com в несуществующий адрес 0.0.0.10. Когда пользователи уязвимого сервера имен попробуют обратиться к узлу www. abccompany.com, то им никогда не удастся получить ответ с узла 0.0.0.10. Это приведет к генерации состояния DoS на узле www.abccompany.com.

Контрмеры: защита службыDNS

Для разрешения проблем службы BIND обновите ее версию до 4.9.6 или 8.1.1 и выше. Поскольку изъян многих версий BIND связан с возможностью повреждения буфера, лучше всего обновить ее используемую версию до самой последней, в которой реализованы дополнительные средства зашиты. Для получения более подробной информации по этому вопросу обращайтесь по адресу http://www.isc.org/bind.html. Информацию о модулях обновления можно найти в отчете СА-97.22 BIND — the Berkeley Internet Name Daemon.