RFC-2827

Появление атак DoS [1] явилось новым вызовом для провайдеров (ISP) и для сетевого сообщества. Имеются многочисленные трудности на пути противодействия этим атакам; существуют некоторые простые средства, позволяющие ограничить эффективность этих атак и область их действенности, но они не очень широко используются. Смотри также [12].

Этот метод атаки известен уже некоторое время. Бил Чезвик (Bill Cheswick) цитируется в [2], где он заявляет, что в последнюю минуту удалил главу из своей книги "Файерволы и безопасность Интернет" [3], так как администратор атакованной системы не мог обеспечить ее защиту. Упоминая метод, он считал целесообразным его применение.

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

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

2. Состояние дел

Упрощенная диаграмма атаки типа “TCP SYN шторм” изображена ниже:

                                                    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.]

Предположим, что:

• "ЭВМ" является атакуемой машиной.
• Атакер находится в пределах префикса, 204.69.207.0/24.
• Атакер осуществляет атаку, используя каждый раз случайное значение IP-адреса отправителя; в данном примере, адреса отправителя обозначаются также как в [4], отсутствуют в глобальных таблицах маршрутизации, и, следовательно, не достижим. Однако для реализации данного метода атаки могут использоваться любые недостижимые префиксы.

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

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

Аналогичные атаки реализовывались с использованием UDP и ICMP лавин. Первая атака (UDP лавина) использует фальсифицированные пакеты, чтобы попытаться подключиться к допустимой UDP услуге и вызвать отклик, адресованный другому сайту. Системные администраторы не должны никогда допускать внешним UDP-дейтограммам попадать в диагностические порты их системы. Последний вид атак (ICMP шторм), использует хитрую особенность откликов на широковещательные 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]. Возможно, благоразумно потребовать, чтобы конфигурация пограничных шлюзов (GW) не допускала прямого прохождения широковещательных через эти устройства.

Когда предпринимается атака 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, доступ которой к Интернет обеспечивается провайдером D. Фильтр входного трафика канала "маршрутизатора 2", который обеспечивает подключение к Интернет сети атакера, осуществляет ограничение трафика, разрешая прохождение пакетов, посланных из зоны с адресным префиксом 204.69.207.0/24, и запрещая использование атакером "неверных" адресов отправителя, которые находятся вне пределов диапазона, заданного этим префиксом. Другими словами, входной фильтр в "маршрутизаторе 2" должен осуществлять следующую функцию:

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

4. Другие возможные функции сетевого оборудования

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

• Реализация автоматического фильтрования на серверах удаленного доступа. В большинстве случаев, пользователь, дозванивающийся до сервера доступа, является индивидуальным пользователем своей ЭВМ. Единственно разрешенным адресом отправителя для этой ЭВМ является адрес, присвоенный ISP (статически или динамически). Сервер удаленного доступа может проверять каждый пакет на входе, чтобы гарантировать, что пользователь не фальсифицирует адрес отправителя. Очевидно, должна быть предусмотрена возможность того, что клиент легально подключает сеть через удаленный сервер, но это должно реализовываться опционно.

Мы рассматривали вариант, когда маршрутизаторы проверяют IP-адрес отправителя, как это предложено [8], но это методологически не будет работать хорошо в реальных сетях в настоящее время. Предлагаемый метод заключается в просмотре адреса отправителя на предмет того, проходит ли маршрут до него через тот же интерфейс, через который пришел пакет. При большом числе асимметричных маршрутов это будет весьма проблематично.

5. Проблемы

Фильтрация такого рода имеет шансы разрушить некоторые виды "специфических" услуг. В интересах сервис провайдеров, предлагающих такие услуги, рассмотреть альтернативные методы предоставления такого рода услуг, чтобы не страдать от входной фильтрации трафика. Мобильный IP, как это определено в [6], подвержен воздействию входной фильтрации трафика. Как это специфицировано, трафик к мобильному узлу туннелируется, но трафик от мобильного узла не туннелируется. Это приводит к тому, что в пакетах, посылаемых мобильным узлом, адрес отправителя не соответствует сети, к которой он подключен. Чтобы согласовать входную фильтрацию с другими соображениями, Рабочая группа Мобильного IP разработала методологию "реверсивных туннелей", специфицированную в [7]. Там предлагается метод передачи данных, посылаемых мобильным узлом, через туннель “домашнему агенту” до передачи информации в Интернет. У схемы реверсных туннелей существуют дополнительные преимущества, включая лучшую обработку мультикастного трафика. Такие реализации мобильных IP-систем располагают к использованию метода реверсных туннелей.

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

Если используется входная фильтрация в среде, где работает DHCP или BOOTP, сетевому администратору рекомендуется предоставить возможность пакетам с адресом отправителя 0.0.0.0 и адресом получателя 255.255.255.255 доходить до соответствующего сервера. Область направленного бродкаста должна контролироваться, произвольная переадресация таких пакетов недопустима.

6. Резюме

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

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

В ответственность всех сетевых администраторов входит предотвращение атак подобного рода.

DDoS-атаки против DNS и с использованием DNS

Распределенные DoS-атаки используют DNS-инфраструктуру (см. "The ultimate guide to preventing DNS-based DDoS attacks", Cricket Liu). Атакер посылает DNS-запросы. В поле адреса отправителя проставляется IP-адрес жертвы атаки. Такой жертвой может быть WEB-сервер, маршрутизатор, другой DNS-сервер или какой-то узел Интернет. Фальсифицировать DNS-запросы достаточно просто, так как они пересылаются UDP-дейтограммами. Запрос может содержать менее 100 байт, а DNS-отклик может включать в себя до 4096 байт (коэффициент увеличения трафика достигает 93). Если атакер посылает 2840 запросов в секунду, он инициирует паразитный трафик 93 Мбит/c. Если к атаке привлечена даже достаточно небольшая botnet, паразитный трафик блокирует сколь угодно быстродействующий сервер или маршрутизатор. В мире 33 млн. открытых рекурсивных DNS-серверов, что существенно облегчает работу хакеров.

7. Ссылки

[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]   Jelena Mirkovic, Janice Martin, and Peter Reiher, UCLA, "A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms."

[11]   Distributed Denial of Service Tools, http://www.cert.org/incident_notes/IN-99-07.html

[12]   F. Baker and P. Savola, "Ingress Filtering for Multihomed Networks," RFC 3704, March 2004.

[13]   "A Chronology of CERT Coordination Center Involvement with Distributed Denial-of-Service Tools,"

[14]   http://www.cdt.org/security/dos/000229senatehouse/chron.html

Yanet Manzano, "Tracing the Development of Denial of Service Attacks: A Corporate Analogy," 2003, http://www.acm.org/crossroads/xrds10-1/tracingDOS.html