Идентификатор и границы фрагмента: RFC2827/part-001, SHA-256=0e87d7328295ce6bce311dd450db29491cdafc57037747a77c3eabba2bc2e64b. От начала документа по страницу 6 включительно.
Network Working Group P. Ferguson
Request for Comments: 2827 Cisco Systems, Inc.
Obsoletes: 2267 D. Senie
BCP: 38 Amaranth Networks Inc.
Category: Best Current Practice May 2000
Фильтрация входящего сетевого трафика:
Противодействие атакам типа «отказ в обслуживании», которые используют
подмену IP-адреса источника
Статус данного документа
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение данного документа не ограничено.
Уведомление об авторском праве
Авторское право (C) The Internet Society (2000). Все права защищены.
Аннотация
Недавние случаи различных атак типа «отказ в обслуживании» (DoS), в
которых использовались поддельные адреса источника, оказались
проблемной темой для поставщиков интернет-услуг и интернет-сообщества
в целом. В этой статье рассматривается простой, эффективный и
прямой метод применения фильтрации входящего трафика для запрета
распространения DoS-атак с поддельными IP-адресами со стороны сетей,
расположенных за точкой агрегации поставщика интернет-услуг (ISP).
1. Введение
Возобновление атак типа «отказ в обслуживании» [1], направленных на
различные цели в Интернете, поставило перед сообществами поставщиков
интернет-услуг (ISP) и сетевой безопасности новые задачи по поиску
новых и инновационных методов смягчения последствий таких атак.
Трудностей в достижении этой цели много; уже существуют некоторые
простые средства для ограничения эффективности и масштаба этих атак,
но они не получили широкого внедрения.
Этот метод атаки известен уже некоторое время. Однако защита от него
остаётся постоянной проблемой. В [2] приводятся слова Bill Cheswick о
том, что в последний момент он исключил главу из своей книги,
"Firewalls and Internet Security" [3], поскольку у администратора
атакуемой системы не было способа эффективно защитить систему.
Упоминание метода, по его мнению, могло поощрить его использование.
Хотя обсуждаемый в этом документе метод фильтрации совершенно не
защищает от атак затоплением, исходящих из действительных префиксов
(IP-адресов), он не позволит атакующему из исходной сети выполнить
атаку такого рода с использованием поддельных адресов источника,
которые не соответствуют правилам входящей фильтрации. Всем
поставщикам интернет-связности настоятельно рекомендуется внедрить
описанную в этом документе фильтрацию, чтобы запретить атакующим
использовать поддельные адреса источника, не находящиеся в диапазоне
легитимно анонсированных префиксов. Иными словами, если ISP агрегирует
анонсы маршрутизации для нескольких нижестоящих сетей, следует применять
строгую фильтрацию трафика, чтобы запретить трафик, который утверждает,
что он возник за пределами этих агрегированных анонсов.
Дополнительное преимущество внедрения такого типа фильтрации состоит
в том, что источник можно легко отследить до его фактического
источника, поскольку атакующему пришлось бы использовать действительный
и легитимно достижимый адрес источника.
2. Предпосылки
Ниже показана упрощённая схема проблемы TCP SYN flooding:
204.69.207.0/24
host <----- router <--- Internet <----- router <-- attacker
TCP/SYN
<---------------------------------------------
Source: 192.168.0.4/32
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 10.0.0.13/32
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 172.16.0.2/32
SYN/ACK
no route
[etc.]
Предположим:
o «host» — целевая машина.
o Атакующий находится в «действительном» префиксе 204.69.207.0/24.
o Атакующий запускает атаку, используя случайно изменяющиеся адреса
источника; в этом примере адреса источника показаны как принадлежащие
[4], которые обычно отсутствуют в глобальных таблицах маршрутизации
Интернета и поэтому недостижимы. Однако для осуществления этого
метода атаки можно использовать любой недостижимый префикс.
Также стоит упомянуть случай, когда адрес источника подделан так,
чтобы казаться происходящим из другой легитимной сети, присутствующей
в глобальной таблице (таблицах) маршрутизации. Например, атакующий,
использующий действительный сетевой адрес, мог бы нанести серьёзный
ущерб, создав видимость, что атака исходит от организации, которая
фактически не была её источником и совершенно невиновна. В таких
случаях администратор атакуемой системы может быть склонен
фильтровать весь трафик, поступающий от видимого источника атаки.
Добавление такого фильтра привело бы затем к отказу в обслуживании для
легитимных, не враждебных оконечных систем. В этом случае
администратор атакуемой системы невольно становится сообщником
атакующего.
Дополнительно ситуацию усложняет то, что атаки TCP SYN flood приводят
к отправке пакетов SYN-ACK одному или многим хостам, не имеющим
отношения к атаке, но становящимся вторичными жертвами. Это позволяет
атакующему одновременно злоупотреблять двумя или более системами.
Аналогичные атаки предпринимались с использованием UDP- и ICMP-flooding.
Первая атака (UDP flooding) использует поддельные пакеты, чтобы попытаться
соединить службу chargen UDP со службой echo UDP на другой площадке.
Системным администраторам НИКОГДА (NEVER) не следует разрешать пакетам
UDP, адресованным портам системной диагностики, достигать их систем извне
их административного домена. Вторая атака (ICMP flooding) использует
коварную особенность механики репликации широковещательных пакетов в
IP-подсетях. Эта атака полагается на то, что маршрутизатор, обслуживающий
большую широковещательную сеть с множественным доступом, преобразует
широковещательный IP-адрес (например, адрес назначения 10.255.255.255)
в широковещательный кадр уровня 2 (для ethernet,
FF:FF:FF:FF:FF:FF). Аппаратное обеспечение Ethernet NIC (в частности,
оборудование MAC-уровня) при нормальной работе прослушивает лишь
ограниченное число адресов. Единственный MAC-адрес, общий для всех
устройств при нормальной работе, — это широковещательный адрес среды,
FF:FF:FF:FF:FF:FF. В этом случае устройство примет пакет и отправит
прерывание на обработку. Таким образом, поток таких широковещательных
кадров исчерпает все доступные ресурсы оконечной системы [9]. Возможно,
системным администраторам следует рассмотреть обеспечение того, чтобы
их граничные маршрутизаторы по умолчанию не разрешали пересылку
направленных широковещательных пакетов через свои маршрутизаторы.
Когда атака TCP SYN запускается с использованием недостижимого адреса
источника, целевой хост пытается зарезервировать ресурсы в ожидании
ответа. Атакующий многократно меняет фиктивный адрес источника в каждом
новом отправленном пакете, тем самым исчерпывая дополнительные ресурсы
хоста.
В качестве альтернативы, если атакующий использует в качестве адреса
источника чей-либо действительный адрес хоста, атакуемая система отправит
большое число пакетов SYN/ACK тому, кого она считает инициатором
последовательности установления соединения. Таким образом атакующий
наносит ущерб двум системам: целевой системе назначения, а также системе,
которая фактически использует подменённый адрес в глобальной системе
маршрутизации.
Результатом обоих методов атаки является крайне деградировавшая
производительность или, хуже того, сбой системы.
В ответ на эту угрозу большинство поставщиков операционных систем
модифицировали своё программное обеспечение, чтобы позволить целевым
серверам выдерживать атаки с очень высокими скоростями попыток
установления соединений. Это желательная и необходимая часть решения
проблемы. Для повсеместного внедрения и достижения полной эффективности
входящей фильтрации потребуется время, однако расширения операционных
систем можно внедрить быстро. Такое сочетание должно оказаться
эффективным против подмены адресов источника. Сведения об обновлениях
программного обеспечения поставщиков и платформ см. в [1].
3. Ограничение поддельного трафика
Проблемы, возникающие при таком типе атаки, многочисленны и включают
недостатки реализаций программного обеспечения хостов, методологий
маршрутизации и самих протоколов TCP/IP. Однако, ограничив транзитный
трафик, исходящий из нижестоящей сети, известными и намеренно
анонсированными префиксами, проблему подмены адресов источника в этом
сценарии атаки можно практически устранить.
11.0.0.0/8
/
router 1
/
/
/ 204.69.207.0/24
ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
A B C D 2
/
/
/
router 3
/
12.0.0.0/8
В приведённом выше примере атакующий находится в 204.69.207.0/24,
которой интернет-связность предоставляет ISP D. Фильтр входящего
трафика на входном (ingress) канале «router 2», обеспечивающего
связность с сетью атакующего, ограничивает трафик, разрешая только
трафик, исходящий от адресов источника внутри префикса
204.69.207.0/24, и запрещает атакующему использовать «недействительные»
адреса источника, находящиеся за пределами диапазона этого префикса.
Иными словами, входящий фильтр на указанном выше «router 2» проверял бы:
IF packet's source address from within 204.69.207.0/24
THEN forward as appropriate
IF packet's source address is anything else
THEN deny packet
Сетевым администраторам следует регистрировать сведения об отброшенных
пакетах. Это обеспечивает основу для мониторинга любой подозрительной
активности.
4. Дополнительные возможные возможности сетевого оборудования
Для будущих реализаций платформ следует рассмотреть дополнительные
функции. Стоит отметить следующую:
o Внедрение автоматической фильтрации на серверах удалённого доступа.
В большинстве случаев пользователь, подключающийся к серверу доступа,
является индивидуальным пользователем одного PC. ЕДИНСТВЕННЫЙ (ONLY)
действительный IP-адрес источника для пакетов, исходящих с этого PC,
— адрес, назначенный ISP (статически или динамически). Сервер
удалённого доступа мог бы проверять каждый пакет при входе, чтобы
удостовериться, что пользователь не подменяет адрес источника в
создаваемых им пакетах. Очевидно, также необходимо предусмотреть
случаи, когда заказчик легитимно подключает сеть или подсеть через
удалённый маршрутизатор, однако это, безусловно, можно реализовать
как необязательный параметр. Мы получили сообщения, что некоторые
поставщики и некоторые ISP уже начинают внедрять эту возможность.
Мы рассматривали предложение, чтобы маршрутизаторы также проверяли
IP-адрес источника отправителя, как предложено в [8], но эта методология
не будет хорошо работать в реальных современных сетях. Предложенный метод
состоит в поиске адресов источника, чтобы убедиться, что обратный путь
к этому адресу проходил бы через тот же интерфейс, по которому поступил
пакет. При числе асимметричных маршрутов в Интернете это явно было бы
проблематично.
5. Риски
Фильтрация такого рода потенциально может нарушить работу некоторых
типов «специальных» служб. Однако в интересах ISP, предлагающего такие
виды специальных служб, рассмотреть альтернативные методы реализации
этих служб, чтобы избежать воздействия фильтрации входящего трафика.
Mobile IP, как определено в [6], непосредственно затрагивается фильтрацией входящего трафика. Согласно спецификации, трафик к мобильному узлу туннелируется, а трафик от мобильного узла не туннелируется. В результате пакеты от мобильного узла (или узлов) имеют адреса источника, не соответствующие сети, к которой подключена станция. Чтобы учесть фильтрацию входящего трафика и другие соображения, Рабочая группа Mobile IP разработала методику «обратных туннелей», определённую в [7]. Она предоставляет способ туннелирования данных, передаваемых мобильным узлом, к домашнему агенту до их передачи в Интернет. Схема обратного туннелирования имеет и дополнительные преимущества, включая улучшенную обработку многоадресного трафика. Реализующим системы Mobile IP рекомендуется реализовать этот метод обратного туннелирования.
Как упоминалось ранее, хотя фильтрация входящего трафика резко снижает успешность подмены адреса источника, она не препятствует атакующему использовать поддельный адрес источника другого хоста в пределах разрешённого диапазона префиксного фильтра. Однако она гарантирует, что, когда атака такого рода действительно происходит, сетевой администратор может быть уверен, что атака фактически исходит из известных рекламируемых префиксов. Это упрощает поиск виновника, и, в худшем случае, администратор может заблокировать диапазон адресов источника до устранения проблемы.
Если фильтрация входящего трафика используется в среде, где применяется DHCP или BOOTP, сетевому администратору было бы разумно обеспечить, чтобы пакеты с адресом источника 0.0.0.0 и адресом назначения 255.255.255.255 при необходимости могли достигать relay agent в маршрутизаторах. Однако область репликации направленной широковещательной рассылки следует контролировать и не следует пересылать произвольно.
6. Резюме
Фильтрация входящего трафика на периферии сетей, подключённых к Интернету, снизит эффективность атак типа «отказ в обслуживании» с подменой адреса источника. Поставщики сетевых услуг и администраторы уже начали внедрять этот тип фильтрации на периферийных маршрутизаторах; рекомендуется, чтобы все поставщики услуг сделали это как можно скорее. Помимо содействия интернет-сообществу в целом в противодействии этому методу атак, это также может помочь поставщикам услуг определить источник атаки, если они могут категорически продемонстрировать, что в их сети уже применяется фильтрация входящего трафика на клиентских соединениях.
Администраторам корпоративных сетей следует внедрить фильтрацию, чтобы гарантировать, что их корпоративные сети не являются источником таких проблем. Действительно, фильтрация могла бы использоваться внутри организации, чтобы пользователи не создавали проблем, неправильно подключая системы к неверным сетям.
На практике фильтрация также могла бы помешать недовольному сотруднику совершать анонимные атаки.
Все сетевые администраторы несут ответственность за то, чтобы не стать невольным источником атаки такого рода.
7. Соображения безопасности
Основная цель этого документа — по сути повысить практики безопасности и осведомлённость интернет-сообщества в целом; по мере того как всё больше интернет-поставщиков и администраторов корпоративных сетей внедряют фильтрацию входящего трафика, возможность для атакующего использовать поддельные адреса источника в качестве методики атаки будет существенно снижаться. Отслеживание источника атаки упрощается, когда вероятность того, что источник является «действительным», выше. При сокращении количества и частоты атак в Интернете в целом появится больше ресурсов для отслеживания атак, которые всё же происходят.
8. Благодарности
Группа The North American Network Operators Group (NANOG) [5] в целом заслуживает особой признательности за открытое обсуждение этих вопросов и активный поиск возможных решений. Также благодарность Justin Newton [Priori Networks] и Steve Bielagus [IronBridge Networks]. за их замечания и вклад.
9. Ссылки
[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing
Attacks; September 24, 1996.
[2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street
Journal, 12 September 1996.
[3] "Firewalls and Internet Security: Repelling the Wily Hacker";
William R. Cheswick and Steven M. Bellovin, Addison-Wesley
Publishing Company, 1994; ISBN 0-201-63357-4.
[4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E.
Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[5] The North American Network Operators Group;
http://www.nanog.org.
[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[7] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[9] Thanks to: Craig Huegen; See:
http://www.quadrunner.com/~chuegen/smurf.txt.
10. Адреса авторов
Paul Ferguson
Cisco Systems, Inc.
13625 Dulles Technology Dr.
Herndon, Virginia 20170 USA
EMail: ferguson@cisco.com
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740 USA
EMail: dts@senie.com
11. Полное заявление об авторских правах
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам; производные работы, комментирующие или иным образом поясняющие его либо содействующие его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторских правах и этот абзац включены во все такие копии и производные работы. Однако сам этот документ не может быть изменён каким-либо образом, например путём удаления уведомления об авторских правах или ссылок на The Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки стандартов Интернета, в котором случае должны соблюдаться процедуры в отношении авторских прав, определённые процессом разработки интернет-стандартов, или когда это требуется для перевода документа на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны The Internet Society, его правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И THE INTERNET SOCIETY, И THE INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНО ВЫРАЖЕННЫХ И ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, В ЧАСТНОСТИ, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется The Internet Society.