Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
RFC 2827 описывает фильтрацию входящего трафика на границе сети как простой способ существенно сократить возможность DoS-атак с поддельными исходными IP-адресами. Поставщики интернет-связности призываются ограничивать трафик от нижестоящих сетей только легитимно анонсированными для них префиксами и регистрировать отброшенные пакеты. Метод не защищает от атак с адресами из разрешённого префикса, но упрощает установление сети-источника атаки. Документ отмечает совместимые исключения и риски для Mobile IP, DHCP/BOOTP, специальных сервисов и асимметричной маршрутизации.
Идентификатор и границы фрагмента: 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. Введение . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Предпосылки . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Ограничение поддельного трафика . . . . . . . . . . . . . . 5
4. Дополнительные возможности сетевого оборудования . . . . . . 6
5. Риски. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Резюме. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Соображения безопасности. . . . . . . . . . . . . . . . . 8
8. Благодарности . . . . . . . . . . . . . . . . . . . . . . 8
9. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Адреса авторов . . . . . . . . . . . . . . . . . . . . . . 9
11. Полное заявление об авторском праве . . . . . . . . . . . . 10
Ferguson & Senie Best Current Practice [Page 1]
RFC 2827 Network Ingress Filtering May 2000
1. Введение
Возобновление атак типа «отказ в обслуживании» [1], направленных на
различные цели в Интернете, поставило перед сообществами поставщиков
интернет-услуг (ISP) и сетевой безопасности новые задачи по поиску
новых и инновационных методов смягчения последствий таких атак.
Трудностей в достижении этой цели много; уже существуют некоторые
простые средства для ограничения эффективности и масштаба этих атак,
но они не получили широкого внедрения.
Этот метод атаки известен уже некоторое время. Однако защита от него
остаётся постоянной проблемой. В [2] приводятся слова Bill Cheswick о
том, что в последний момент он исключил главу из своей книги,
"Firewalls and Internet Security" [3], поскольку у администратора
атакуемой системы не было способа эффективно защитить систему.
Упоминание метода, по его мнению, могло поощрить его использование.
Хотя обсуждаемый в этом документе метод фильтрации совершенно не
защищает от атак затоплением, исходящих из действительных префиксов
(IP-адресов), он не позволит атакующему из исходной сети выполнить
атаку такого рода с использованием поддельных адресов источника,
которые не соответствуют правилам входящей фильтрации. Всем
поставщикам интернет-связности настоятельно рекомендуется внедрить
описанную в этом документе фильтрацию, чтобы запретить атакующим
использовать поддельные адреса источника, не находящиеся в диапазоне
легитимно анонсированных префиксов. Иными словами, если ISP агрегирует
анонсы маршрутизации для нескольких нижестоящих сетей, следует применять
строгую фильтрацию трафика, чтобы запретить трафик, который утверждает,
что он возник за пределами этих агрегированных анонсов.
Дополнительное преимущество внедрения такого типа фильтрации состоит
в том, что источник можно легко отследить до его фактического
источника, поскольку атакующему пришлось бы использовать действительный
и легитимно достижимый адрес источника.
Ferguson & Senie Best Current Practice [Page 2]
RFC 2827 Network Ingress Filtering May 2000
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], которые обычно отсутствуют в глобальных таблицах маршрутизации
Интернета и поэтому недостижимы. Однако для осуществления этого
метода атаки можно использовать любой недостижимый префикс.
Также стоит упомянуть случай, когда адрес источника подделан так,
чтобы казаться происходящим из другой легитимной сети, присутствующей
в глобальной таблице (таблицах) маршрутизации. Например, атакующий,
использующий действительный сетевой адрес, мог бы нанести серьёзный
ущерб, создав видимость, что атака исходит от организации, которая
фактически не была её источником и совершенно невиновна. В таких
случаях администратор атакуемой системы может быть склонен
фильтровать весь трафик, поступающий от видимого источника атаки.
Добавление такого фильтра привело бы затем к отказу в обслуживании для
Ferguson & Senie Best Current Practice [Page 3]
RFC 2827 Network Ingress Filtering May 2000
легитимных, не враждебных оконечных систем. В этом случае
администратор атакуемой системы невольно становится сообщником
атакующего.
Дополнительно ситуацию усложняет то, что атаки 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 тому, кого она считает инициатором
последовательности установления соединения. Таким образом атакующий
наносит ущерб двум системам: целевой системе назначения, а также системе,
которая фактически использует подменённый адрес в глобальной системе
маршрутизации.
Результатом обоих методов атаки является крайне деградировавшая
производительность или, хуже того, сбой системы.
Ferguson & Senie Best Current Practice [Page 4]
RFC 2827 Network Ingress Filtering May 2000
В ответ на эту угрозу большинство поставщиков операционных систем
модифицировали своё программное обеспечение, чтобы позволить целевым
серверам выдерживать атаки с очень высокими скоростями попыток
установления соединений. Это желательная и необходимая часть решения
проблемы. Для повсеместного внедрения и достижения полной эффективности
входящей фильтрации потребуется время, однако расширения операционных
систем можно внедрить быстро. Такое сочетание должно оказаться
эффективным против подмены адресов источника. Сведения об обновлениях
программного обеспечения поставщиков и платформ см. в [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, и запрещает атакующему использовать «недействительные»
адреса источника, находящиеся за пределами диапазона этого префикса.
Ferguson & Senie Best Current Practice [Page 5]
RFC 2827 Network Ingress Filtering May 2000
Иными словами, входящий фильтр на указанном выше «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, предлагающего такие
виды специальных служб, рассмотреть альтернативные методы реализации
этих служб, чтобы избежать воздействия фильтрации входящего трафика.
Ferguson & Senie Best Current Practice [Page 6]
Mobile IP, как определено в [6], непосредственно затрагивается фильтрацией входящего трафика. Согласно спецификации, трафик к мобильному узлу туннелируется, а трафик от мобильного узла не туннелируется. В результате пакеты от мобильного узла (или узлов) имеют адреса источника, не соответствующие сети, к которой подключена станция. Чтобы учесть фильтрацию входящего трафика и другие соображения, Рабочая группа Mobile IP разработала методику «обратных туннелей», определённую в [7]. Она предоставляет способ туннелирования данных, передаваемых мобильным узлом, к домашнему агенту до их передачи в Интернет. Схема обратного туннелирования имеет и дополнительные преимущества, включая улучшенную обработку многоадресного трафика. Реализующим системы Mobile IP рекомендуется реализовать этот метод обратного туннелирования.
Как упоминалось ранее, хотя фильтрация входящего трафика резко снижает успешность подмены адреса источника, она не препятствует атакующему использовать поддельный адрес источника другого хоста в пределах разрешённого диапазона префиксного фильтра. Однако она гарантирует, что, когда атака такого рода действительно происходит, сетевой администратор может быть уверен, что атака фактически исходит из известных рекламируемых префиксов. Это упрощает поиск виновника, и, в худшем случае, администратор может заблокировать диапазон адресов источника до устранения проблемы.
Если фильтрация входящего трафика используется в среде, где применяется DHCP или BOOTP, сетевому администратору было бы разумно обеспечить, чтобы пакеты с адресом источника 0.0.0.0 и адресом назначения 255.255.255.255 при необходимости могли достигать relay agent в маршрутизаторах. Однако область репликации направленной широковещательной рассылки следует контролировать и не следует пересылать произвольно.
6. Резюме
Фильтрация входящего трафика на периферии сетей, подключённых к Интернету, снизит эффективность атак типа «отказ в обслуживании» с подменой адреса источника. Поставщики сетевых услуг и администраторы уже начали внедрять этот тип фильтрации на периферийных маршрутизаторах; рекомендуется, чтобы все поставщики услуг сделали это как можно скорее. Помимо содействия интернет-сообществу в целом в противодействии этому методу атак, это также может помочь поставщикам услуг определить источник атаки, если они могут категорически продемонстрировать, что в их сети уже применяется фильтрация входящего трафика на клиентских соединениях.
Администраторам корпоративных сетей следует внедрить фильтрацию, чтобы гарантировать, что их корпоративные сети не являются источником таких проблем. Действительно, фильтрация могла бы использоваться внутри организации, чтобы пользователи не создавали проблем, неправильно подключая системы к неверным сетям.
Ferguson & Senie Best Current Practice [Page 7]
RFC 2827 Network Ingress Filtering May 2000
На практике фильтрация также могла бы помешать недовольному сотруднику совершать анонимные атаки.
Все сетевые администраторы несут ответственность за то, чтобы не стать невольным источником атаки такого рода.
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.
Ferguson & Senie Best Current Practice [Page 8]
RFC 2827 Network Ingress Filtering May 2000
[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
Ferguson & Senie Best Current Practice [Page 9]
RFC 2827 Network Ingress Filtering May 2000
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.
Ferguson & Senie Best Current Practice [Page 10]
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
Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Recent occurrences of various Denial of Service (DoS) attacks which
have employed forged source addresses have proven to be a troublesome
issue for Internet Service Providers and the Internet community
overall. This paper discusses a simple, effective, and
straightforward method for using ingress traffic filtering to
prohibit DoS attacks which use forged IP addresses to be propagated
from 'behind' an Internet Service Provider's (ISP) aggregation point.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Restricting forged traffic . . . . . . . . . . . . . . . . 5
4. Further capabilities for networking equipment. . . . . . . 6
5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 6
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
11. Full Copyright Statement . . . . . . . . . . . . . . . . . 10
Ferguson & Senie Best Current Practice [Page 1]
RFC 2827 Network Ingress Filtering May 2000
1. Introduction
A resurgence of Denial of Service Attacks [1] aimed at various
targets in the Internet have produced new challenges within the
Internet Service Provider (ISP) and network security communities to
find new and innovative methods to mitigate these types of attacks.
The difficulties in reaching this goal are numerous; some simple
tools already exist to limit the effectiveness and scope of these
attacks, but they have not been widely implemented.
This method of attack has been known for some time. Defending against
it, however, has been an ongoing concern. Bill Cheswick is quoted in
[2] as saying that he pulled a chapter from his book, "Firewalls and
Internet Security" [3], at the last minute because there was no way
for an administrator of the system under attack to effectively defend
the system. By mentioning the method, he was concerned about
encouraging it's use.
While the filtering method discussed in this document does
absolutely nothing to protect against flooding attacks which
originate from valid prefixes (IP addresses), it will prohibit an
attacker within the originating network from launching an attack of
this nature using forged source addresses that do not conform to
ingress filtering rules. All providers of Internet connectivity are
urged to implement filtering described in this document to prohibit
attackers from using forged source addresses which do not reside
within a range of legitimately advertised prefixes. In other words,
if an ISP is aggregating routing announcements for multiple
downstream networks, strict traffic filtering should be used to
prohibit traffic which claims to have originated from outside of
these aggregated announcements.
An additional benefit of implementing this type of filtering is that
it enables the originator to be easily traced to it's true source,
since the attacker would have to use a valid, and legitimately
reachable, source address.
Ferguson & Senie Best Current Practice [Page 2]
RFC 2827 Network Ingress Filtering May 2000
2. Background
A simplified diagram of the TCP SYN flooding problem is depicted
below:
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.]
Assume:
o The "host" is the targeted machine.
o The attacker resides within the "valid" prefix, 204.69.207.0/24.
o The attacker launches the attack using randomly changing source
addresses; in this example, the source addresses are depicted as
from within [4], which are not generally present in the global
Internet routing tables, and therefore, unreachable. However, any
unreachable prefix could be used to perpetrate this attack
method.
Also worthy of mention is a case wherein the source address is forged
to appear to have originated from within another legitimate network
which appears in the global routing table(s). For example, an
attacker using a valid network address could wreak havoc by making
the attack appear to come from an organization which did not, in
fact, originate the attack and was completely innocent. In such
cases, the administrator of a system under attack may be inclined to
filter all traffic coming from the apparent attack source. Adding
such a filter would then result in a denial of service to
Ferguson & Senie Best Current Practice [Page 3]
RFC 2827 Network Ingress Filtering May 2000
legitimate, non-hostile end-systems. In this case, the administrator
of the system under attack unwittingly becomes an accomplice of the
attacker.
Further complicating matters, TCP SYN flood attacks will result in
SYN-ACK packets being sent to one or many hosts which have no
involvement in the attack, but which become secondary victims. This
allows the attacker to abuse two or more systems at once.
Similar attacks have been attempted using UDP and ICMP flooding.
The former attack (UDP flooding) uses forged packets to try and
connect the chargen UDP service to the echo UDP service at another
site. Systems administrators should NEVER allow UDP packets destined
for system diagnostic ports from outside of their administrative
domain to reach their systems. The latter attack (ICMP flooding),
uses an insidious feature in IP subnet broadcast replication
mechanics. This attack relies on a router serving a large multi-
access broadcast network to frame an IP broadcast address (such as
one destined for 10.255.255.255) into a Layer 2 broadcast frame (for
ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer
hardware, specifically) will only listen to a select number of
addresses in normal operation. The one MAC address that all devices
share in common in normal operation is the media broadcast, or
FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and
send an interrupt for processing. Thus, a flood of these broadcast
frames will consume all available resources on an end-system [9]. It
is perhaps prudent that system administrators should consider
ensuring that their border routers do not allow directed broadcast
packets to be forwarded through their routers as a default.
When an TCP SYN attack is launched using unreachable source address,
the target host attempts to reserve resources waiting for a
response. The attacker repeatedly changes the bogus source address
on each new packet sent, thus exhausting additional host resources.
Alternatively, if the attacker uses someone else's valid host
address as the source address, the system under attack will send a
large number of SYN/ACK packets to what it believes is the originator
of the connection establishment sequence. In this fashion, the
attacker does damage to two systems: the destination target system,
as well as the system which is actually using the spoofed address in
the global routing system.
The result of both attack methods is extremely degraded performance,
or worse, a system crash.
Ferguson & Senie Best Current Practice [Page 4]
RFC 2827 Network Ingress Filtering May 2000
In response to this threat, most operating system vendors have
modified their software to allow the targeted servers to sustain
attacks with very high connection attempt rates. This is a welcome
and necessary part of the solution to the problem. Ingress filtering
will take time to be implemented pervasively and be fully effective,
but the extensions to the operating systems can be implemented
quickly. This combination should prove effective against source
address spoofing. See [1] for vendor and platform software upgrade
information.
3. Restricting forged traffic
The problems encountered with this type of attack are numerous, and
involve shortcomings in host software implementations, routing
methodologies, and the TCP/IP protocols themselves. However, by
restricting transit traffic which originates from a downstream
network to known, and intentionally advertised, prefix(es), the
problem of source address spoofing can be virtually eliminated in
this attack scenario.
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
In the example above, the attacker resides within 204.69.207.0/24,
which is provided Internet connectivity by ISP D. An input traffic
filter on the ingress (input) link of "router 2", which provides
connectivity to the attacker's network, restricts traffic to allow
only traffic originating from source addresses within the
204.69.207.0/24 prefix, and prohibits an attacker from using
"invalid" source addresses which reside outside of this prefix range.
Ferguson & Senie Best Current Practice [Page 5]
RFC 2827 Network Ingress Filtering May 2000
In other words, the ingress filter on "router 2" above would check:
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
Network administrators should log information on packets which are
dropped. This then provides a basis for monitoring any suspicious
activity.
4. Further possible capabilities for networking equipment
Additional functions should be considered for future platform
implementations. The following one is worth noting:
o Implementation of automatic filtering on remote access servers.
In most cases, a user dialing into an access server is an
individual user on a single PC. The ONLY valid source IP address
for packets originating from that PC is the one assigned by the
ISP (whether statically or dynamically assigned). The remote
access server could check every packet on ingress to ensure the
user is not spoofing the source address on the packets which he
is originating. Obviously, provisions also need to be made for
cases where the customer legitimately is attaching a net or
subnet via a remote router, but this could certainly be
implemented as an optional parameter. We have received reports
that some vendors and some ISPs are already starting to
implement this capability.
We considered suggesting routers also validate the source IP address
of the sender as suggested in [8], but that methodology will not
operate well in the real networks out there today. The method
suggested is to look up source addresses to see that the return path
to that address would flow out the same interface as the packet
arrived upon. With the number of asymmetric routes in the Internet,
this would clearly be problematic.
5. Liabilities
Filtering of this nature has the potential to break some types of
"special" services. It is in the best interest of the ISP offering
these types of special services, however, to consider alternate
methods of implementing these services to avoid being affected by
ingress traffic filtering.
Ferguson & Senie Best Current Practice [Page 6]
RFC 2827 Network Ingress Filtering May 2000
Mobile IP, as defined in [6], is specifically affected by ingress
traffic filtering. As specified, traffic to the mobile node is
tunneled, but traffic from the mobile node is not tunneled. This
results in packets from the mobile node(s) which have source
addresses that do not match with the network where the station is
attached. To accommodate Ingress Filtering and other concerns, the
Mobile IP Working Group developed a methodology for "reverse
tunnels", specified in [7]. This provides a method for the data
transmitted by the mobile node to be tunneled to the home agent
before transmission to the Internet. There are additional benefits
to the reverse tunneling scheme, including better handling of
multicast traffic. Those implementing mobile IP systems are
encouraged to implement this method of reverse tunneling.
As mentioned previously, while ingress traffic filtering drastically
reduces the success of source address spoofing, it does not preclude
an attacker using a forged source address of another host within the
permitted prefix filter range. It does, however, ensure that when an
attack of this nature does indeed occur, a network administrator can
be sure that the attack is actually originating from within the known
prefixes that are being advertised. This simplifies tracking down the
culprit, and at worst, the administrator can block a range of source
addresses until the problem is resolved.
If ingress filtering is used in an environment where DHCP or BOOTP is
used, the network administrator would be well advised to ensure that
packets with a source address of 0.0.0.0 and a destination of
255.255.255.255 are allowed to reach the relay agent in routers when
appropriate. The scope of directed broadcast replication should be
controlled, however, and not arbitrarily forwarded.
6. Summary
Ingress traffic filtering at the periphery of Internet connected
networks will reduce the effectiveness of source address spoofing
denial of service attacks. Network service providers and
administrators have already begun implementing this type of filtering
on periphery routers, and it is recommended that all service
providers do so as soon as possible. In addition to aiding the
Internet community as a whole to defeat this attack method, it can
also assist service providers in locating the source of the attack if
service providers can categorically demonstrate that their network
already has ingress filtering in place on customer links.
Corporate network administrators should implement filtering to ensure
their corporate networks are not the source of such problems. Indeed,
filtering could be used within an organization to ensure users do not
cause problems by improperly attaching systems to the wrong networks.
Ferguson & Senie Best Current Practice [Page 7]
RFC 2827 Network Ingress Filtering May 2000
The filtering could also, in practice, block a disgruntled employee
from anonymous attacks.
It is the responsibility of all network administrators to ensure they
do not become the unwitting source of an attack of this nature.
7. Security Considerations
The primary intent of this document is to inherently increase
security practices and awareness for the Internet community as a
whole; as more Internet Providers and corporate network
administrators implement ingress filtering, the opportunity for an
attacker to use forged source addresses as an attack methodology will
significantly lessen. Tracking the source of an attack is simplified
when the source is more likely to be "valid". By reducing the
number and frequency of attacks in the Internet as a whole, there
will be more resources for tracking the attacks which ultimately do
occur.
8. Acknowledgments
The North American Network Operators Group (NANOG) [5] group as a
whole deserves special credit for openly discussing these issues and
actively seeking possible solutions. Also, thanks to Justin Newton
[Priori Networks] and Steve Bielagus [IronBridge Networks]. for
their comments and contributions.
9. References
[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.
Ferguson & Senie Best Current Practice [Page 8]
RFC 2827 Network Ingress Filtering May 2000
[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. Authors' Addresses
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
Ferguson & Senie Best Current Practice [Page 9]
RFC 2827 Network Ingress Filtering May 2000
11. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ferguson & Senie Best Current Practice [Page 10]