Анатомия рефлекторных атак

В марте этого года Интернет испытал очередную DDoS атаку. В этот раз атакуемой явилась компания Spamhaus (http://www.spamhaus.org/), обслуживающая т.н. "черные списки" сетей, являющихся источником спама и прочего безобразия. Атака длилась несколько дней и в своем пике достигла 120Гбит/с - весьма значительный трафик.

Детальное описание атаки интересно и поучительно (см., например, Хронологию Атаки http://blogs.cisco.com/security/chronology-of-a-ddos-spamhaus/). Атаки подобного рода не являются чем-то необычным. Пиковый объем трафика в этот раз действительно приблизился к рекордному, если не побил его, но исключения из общей печальной тенденции роста атак такого рода не составил.

Например, в последнем годовом отчете по безопасности инфраструктуры Интернета компании Arbor Networks эта тенденция видна достаточно ясно: 55% рост за последние 20 месяцев (см. рис 1). Цифры, вызывающие беспокойство, однако не следует забывать, что Интернет также вырос.

Так, согласно отчету "State of the Internet" компании Akamai (http://www.akamai.com/stateoftheinternet), средняя пропускная способность каналов увеличилась на 40-50%, хотя конкретные цифры существенно различаются для разных регионов. Также выросло и число широкополосных подключений, согласно статистике МСЭ (http://www.itu.int/ITU-D/ict/statistics/), от скромных 5-8% в Западной Европе и Северной Америке до впечатляющих 30% в России и Китае.

Рисунок 1. Среднемесячный размер атак согласно монитору ATLAS с 2009 года. (Источник: Arbor Networks, Inc.)

Возвращаясь к атаке на Spamhaus, замечу что хотя здесь использовались различные методы, включая атаку на систему маршрутизации[1], основным генератором трафика явилась т.н. рефлекторная атака с усилением - технология, впервые получившая широкую известность в 1997 году.

Атаки этого типа довольно незатейливы и в то же время весьма разрушительны, благо "строительного материала" в Интернете предостаточно. И основным "строительным блоком" является, как ни печально, глобальная система трансляции имен - DNS.

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

Рефлекторные атаки с усилением

Суть рефлекторной атаки достаточно проста и базируется на четырех основных ингредиентах:

Смешав эти ингредиенты, мы получим рефлекторную атаку с усилением. Работает она следующим образом.

  1. Выбирается один или несколько усилителей-рефлекторов. В качестве таковых могут служить DNS-серверы и «открытые» резолверы (о них мы поговорим чуть позже), готовые предоставить ответ на запрос со значительным коэффициентом усиления. Типичным является усиление трафика в 30-60 раз.

  2. Компьютеры ботнета получают инструкцию начать атаку на жертву. По команде они посылают заданные запросы выбранным усилителям-рефлекторам, подменяя адрес отправителя на IP-адрес жертвы.

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



  4. Объем сгенерированного трафика превышает пропускную способность каналов или максимальную производительность атакуемого сервера, тем самым вызывая отказ в обслуживании, или невозможность предоставления услуг. Услуга, подвергшаяся атаке, на какое-то время перестает быть доступной в Интернете.

Этот процесс схематически представлен на рис.2.

Рисунок 2. Схема рефлекторной атаки с усилением

Классическим примером рефлекторной атаки является т.н. атака "smurf" (получившая это название по имени модуля атакующей программы smurf.c, появившейся в Интернете в 1997 году, более подробно http://en.wikipedia.org/wiki/Smurf_attack). По сценарию этой атаки атакующий посылает запрос ICMP на широковещательный (broadcast) адрес локальной сети, в то же время подменяя адрес источника на адрес жертвы. По правилам, все устройства локальной сети должны отреагировать на этот запрос, тем самым генерируя трафик в направлении жертвы. В зависимости от числа устройств локальной сети, трафик может достигать значительного объема.

В качестве рефлекторов-усилителей также могут служить устройства, поддерживающие открытый доступ к услуге SNMP (Simple Network Management Protocol, http://ru.wikipedia.org/wiki/SNMP), используемой для мониторинга и управления сетью. Например, сценарий проведения SNMP-атаки включает использование ботнета для генерирования сотен тысяч запросов "GetBulkRequest" к сотням таких устройств. В этих атаках часто используются оконечные пользовательские устройства/домашние маршрутизаторы, на которых по умолчанию включена поддержка SNMP на "публичном" (обращенном к глобальному Интернету) интерфейсе. Размер типичного запроса "GetBulkRequest" составляет 60-102 байт (RFC3416, http://tools.ietf.org/html/rfc3416), в то время как ответ на него гораздо больше - 423 - 1560 байт, что может обеспечить усиление в более чем 25 раз.

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

Спуфинг - неизлечимое зло?

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

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

Разумеется, спуфинг не имеет никакого смысла для обычного пользователя услуг Интернета, поскольку обычно предполагается двусторонний обмен данными и получение ответов обратно. Но для проведения рефлекторных атак, как мы уже говорили, эта возможность незаменима. Более того, спуфинг позволяет атакующему практически не оставить следов. Отслеживание источника трафика с подмененными адресами чрезвычайно сложно и требует кооперации со стороны многих сервис-провайдеров, сбор и обмен данными и т.п. И даже если источник будет найден - он приведет к инфицированному компьютеру и его неведающему владельцу.

Возможность использования спуфинга для проведения атак известна давно - уже упоминавшиеся smurf-атаки использовали эту возможность для атаки жертвы с помощью протокола ICMP.

Спуфинг может быть использован в любой рефлекторной атаке, а в качестве рефлектора может выступать практически любое устройство, подключенное к Интернету, и принимающее входящие запросы. Все серверы, обеспечивающие услуги на базе TCP, например, вэб-серверы, являются рефлекторами, поскольку на запрос на создание соединения TCP SYN, сервер ответит пакетом SYN-ACK. Однако такие атаки не обладают усиливающим эффектом, что значительно снижает их привлекательность.

BCP38

В начале века были предложены способы противодействия спуфингу. Эти рекомендации известны под именем BCP38 (http://tools.ietf.org/html/bcp38). Суть их проста - Интернет сервис-провайдер должен отфильтровывать пакеты своих клиентов, адрес отправителя которых находится вне диапазона зарегистрированных адресов этого клиента. Разумеется, наиболее эффективным и безошибочным будет применить эту фильтрацию именно на границе между провайдером и его клиентом.

Основным методом является фильтрация трафика клиентов на основе списков доступа ACL (Access List), пропускающая любые пакеты с адресом источника в диапазоне сетей клиента и блокирующая любой другой трафик.

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

В случае сетей широкополосного доступа идеальным местом искоренения спуфинга являются широкополосные концентраторы доступа (Broadband access concentrators, BAC), которые агрегируют пользовательские каналы. Примерами BAC являются DSLAM (Digital Subscriber Line Access Multiplexer, http://ru.wikipedia.org/wiki/DSLAM) для DSL-сетей или CMTS (cable modem termination system http://en.wikipedia.org/wiki/Cable_modem_termination_system) для кабельных широкополосных сетей. Преимуществом использования BAC в качестве места фильтрования трафика с подложными адресами является то, что здесь можно отдельно идентифицировать каждое соединение, далее они мультиплексируются и задача становится сложнее.

Задача фильтрации в широкополосных сетях осложняется, если назначение IP-адресов пользователей происходит динамически, с помощью DHCP. В этом случае BAC должен контролировать все DHCP-запросы/ответы, извлекая из них информацию о назначенных адресах.

Надо заметить, что спуфинг в широкополосных сетях доступа может представлять серьезную проблему для самого оператора (в отличие от более распространенной ситуации, когда спуфинг скорее является угрозой для других сетей). Например с помощью спуфинга злоумышленник может перехватить трафик другого пользователя, нарушить систему учета, получить неавторизованный доступ к услугам или запустить атаку отказа в обслуживании на других пользователей сегмента. Не случайно проверка адреса источника SAV (Source Address Verification) является обязательной частью спецификации DOCSIS 3.0 (Data-Over-Cable Service Interface Specifications, http://www.cablelabs.com/specifications/CM-SP-SECv3.0-I15-130808.pdf), определяющей передачу данных в кабельных сетях.

uRPF

Для автоматизации фильтрации пакетов с подложными адресами в сетях операторов, предоставляющих услуги доступа в Интернет другим сетям, в 2004 году в документе BCP84 (http://tools.ietf.org/html/bcp84) было предложено использование механизма uRPF (Unicast Reverse Path Forwarding).

Идея uRPF заключается в использовании информации в таблице передачи FIB (Forwarding Information Base) - дистиллированной версии таблицы маршрутизации - для определения может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе.

Логика uRPF проста: если пакет получен с сетевого интерфейса, который, согласно FIB, используется для передачи данных адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае пакет отбрасывается.

Чтобы проиллюстрировать эту идею, рассмотрим сетевого оператора, обеспечивающему доступ нескольким сетям-клиентам (Рис. 3).

Рисунок 3. Работа uRPF в простейшем случае подключения сетей-клиентов

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

Ситуация осложняется, когда сеть-клиент использует несколько провайдеров, поскольку uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс. В данной же ситуации анонсы префикса клиента могут быть приняты с нескольких интерфейсов (см. рис. 4) - например, непосредственно от клиента и от пиров, также являющихся его провайдерами. Поскольку FIB содержит лишь «лучший маршрут», а именно только один интерфейс, через который следует передавать данные сети-клиенту, возникает асимметрия: легитимные пакеты могут быть получены с интерфейса, отсутствующего в FIB, и, соответственно, отброшены.

Рисунок 4. Работа uRPF и возможные проблемы в условиях подключения клиента к нескольким провайдерам

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

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

Еще одну особенность имеет применение uRPF в случае, когда используется не полная таблица маршрутизации, а т.н. default маршрут. В этом случае для трафика, полученного с интерфейса, на который указывает маршрут default, любой адрес источника, даже при отсутствии соответствующей записи FIB, пройдет проверку, поскольку default означает все возможные маршруты , что, собственно, эквивалентно отсутствию фильтрации вообще. Решением в данной ситуации является использование feasible uRPF на клиентских и пиринговых интерфейсах и неиспользование uRPF на интерфейсе, с которого получен default маршрут.

Идеальные рефлекторы

Начиная с конца 1990-х DNS активно используется в качестве рефлектора и усилителя. Действительно, DNS является для этого идеальной услугой:

Это последнее свойство было известно с самого начала, однако ограничение максимального размера ответа в 512 байт позволяло достичь лишь 8-9-кратного усиления. Ситуация существенно изменилась с внедрением расширений EDNS0, позволяющих использовать дейтаграммы размером более 512 байт, и DNSSEC, включающего дополнительные данные. Если раньше для создания максимально возможного ответа использовались синтетические записи (например, специально созданная запись TXT для определенного домена, то теперь стало возможно генерировать ответы большого размера для запросов, не вызывающих подозрения и использующих вполне безобидные домены.

Например, запрос

$ dig +dnssec isc.org. any

Text Box: $ dig +dnssec isc.org ANY
;; QUESTION SECTION:
;isc.org.			IN	ANY

;; ANSWER SECTION:
isc.org.		7200	IN	RRSIG	SPF 5 2 7200 20131026202736 201309
isc.org.		7200	IN	SPF	"v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.
isc.org.		7200	IN	RRSIG	DNSKEY 5 2 7200 20131026200127 2013
isc.org.		7200	IN	RRSIG	DNSKEY 5 2 7200 20131026200127 2013
isc.org.		7200	IN	DNSKEY	257 3 5 BEAAAAOhHQDBrhQbtphgq2wQ
isc.org.		7200	IN	DNSKEY	256 3 5 BQEAAAABwuHz9Cem0BJ0JQTO
isc.org.		3600	IN	RRSIG	NSEC 5 2 3600 20131026202736 20130
isc.org.		3600	IN	NSEC	_adsp._domainkey.isc.org. A NS SOA MX TXT AA
isc.org.		7200	IN	RRSIG	NAPTR 5 2 7200 20131026202736 201309
isc.org.		7200	IN	NAPTR	20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org.		60	IN	RRSIG	AAAA 5 2 60 20131026202736 20130
isc.org.		60	IN	AAAA	2001:4f8:0:2::69
способен сгенерировать ответ размером в 3223 байт, обеспечивая тем самым 50-кратное усиление.

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

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

Открытые резолверы представляют серьезную проблему, поскольку являются идеальными релекторами-усилителями: они готовы обслужить запросы от любого клиента, их число колоссально, они повсеместны. По подсчетам проекта Open Resolver (http://openresolverproject.org/) сегодня существует более 28 миллионов таких серверов!

Решение этой проблемы, или закрытие резолвера обычно состоит в задании списков доступа, в который включаются сети локальных клиентов, для которых данных резолвер обеспечивает трансляцию имен. Рекомендации по обеспечению правильного функционирования резолвера опубликованы в RFC5358 (http://tools.ietf.org/html/rfc5358). Однако следует иметь в виду, что даже в этом случае, при отсутствии мер по анти-спуфингу, о которых мы только что говорили, остается возможность использования резолвера для атаки локальных клиентов.

Response Rate Limiting (RRL) ограничение частоты ответов

С появлением возможности генерирования ответов большого размера со значительным усилением авторитетные серверы также могут эффективно использоваться в атаках в качестве усилителей-рефлекторов. Для уменьшения этого риска Пол Викси (Paul Vixie и Вернон Схряйвер (Vernon Schryver) предложили механизм ограничения частоты ответов, сначала внедренный в ПО BIND 9 (ISC), а впоследствии Knot DNS (CZ-NIC) и NSD (NLNetLabs).

Идея механизма проста: сервер отвечает только на ограниченное число запросов от одного и того же клиента, которым соответствует один и тот же ответ, в соответствии с заданным администратором параметром - числом ответов в секунду. Идентичными являются ответы для одного и того же существующего доменного имени (qname) и типа записи (qtype). Также ответы на несуществующие поддомены (NXDOMAIN) или пустые запросы (NODATA) считаются идентичными и, соответственно, учитываются при подсчете.

В отношении клиентов идентичными считаются клиенты, принадлежащие одной и той же сети (адресному блоку), размер которой задается администратором.

Этот механизм в первую очередь предназначен для авторитетных DNS серверов. В случае рекурсивных резолверов применять его следует с большой осторожностью, чтобы не нарушить работу локальных клиентов. Дело в том, что ввиду недостаточного кэширования DNS ответов многими приложениями, повторимость одинаковых запросов к резолверам от локальных клиентов достаточно велика, что может включить механизм ограничения. Например, при получении почтового сообщения почтовый сервер SMTP сделает запрос на записи NS, PTR, A и AAAA для входящего SMTP соединения. Далее, при получении команды Mail From для этого же сообщения сервер сделает дополнительные запросы для записей NS, A, AAAA, MX, TXT и SPF. Некоторые веб-браузеры также запрашивают одни и те же имена при обработке встроенных в веб-страницу изображений. Как мы уже говорили наиболее правильным решением в этом случае является закрытие резолвера таким образом, что он отвечает только на запросы, поступающие от локальных клиентов.

Изменение протокола

Механизм RRL имеет специальную возможность, позволяющую частично отвечать на запросы нормальных клиентов, адреса которых используются в попытке рефлекторной атаки. Вместо полного блокирования ответа, на каждый второй запрос (этот параметр конфигурируется) сервер отвечает неполным, обрезанным ответом небольшим пакетом с установленным флагом TC (truncation bit). В ответ на получение такого ответа правильно функционирующий клиент должен сделать попытку получить полный ответ с помощью транспортного протокола TCP. Поскольку TCP требует установления соединения (включающее троекратный обмен данными между клиентом и сервером), для подложных адресов такая возможность исключена.

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

Джефф Хьюстон (Geoff Huston), исследователь региональной Интернет-регистратуры APNIC, задался вопросом: а что, если вообще перевести DNS на использование протокола TCP?

Спецификации DNS рекомендуют поддержку TCP в качестве запасного варианта, когда ответ слишком велик, чтобы уместиться в пакет UDP без большой вероятности фрагментации. В своем исследовании Джефф попытался разобраться насколько широко обеспечивается поддержка TCP, а точнее переход клиентов на протокол TCP при получении неполного ответа с битом TC, в глобальном интернете.

Для этого он провел тестирование более 2 миллионов различных клиентов, используя жучок, встроенный в онлайн-рекламу Google Ads. При заходе на страницу, где присутствовала эта реклама, вэб браузер клиента делал необходимые DNS запросы для трансляции встроенных в рекламу имен, которые обрабатывались сервером Джеффа.

Результаты показали, что около 2% клиентов неспособны перейти на TCP по тем или иным причинам. К счастью, с наиболее популярными резолверами - теми, которые использовались значительным числом клиентов - такой проблемы не наблюдалось.

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

Как защититься?

Надеяться на то, что атаки DDoS, при всей простоте их проведения и плодородности среды их обитания, сойдут на нет не реалистично. И хотя полностью защититься от атаки DDoS во многих случаях либо не представляется возможным, либо является очень дорогостоящим удовольствием, каковы возможности уменьшения ущерба от атаки?

Наращивание производительности

Чем больше пропускная способность вашей сети и мощность серверов, тем потребуется более мощная атака и больше времени, чтобы привести к отказу в обслуживании ваших услуг. Однако силы здесь, к сожалению, неравны. Сгенерировать трафик в 1 Гбит/с несравнимо проще и дешевле, чем его обработать. Тем не менее, географически-распределенная инфраструктура предоставления услуги и хорошая связность, в том числе с использованием многочисленных провайдеров транзита, может существенно усилить противостояние атакам.

Использование технологии anycast

Для ряда услуг, особенно использующих транспортный протокол UDP и не требующих создания соединения, все более широкое распространение получает технология anycast. Суть ее заключается в анонсировании оператором одной и той же сети (префикса IP и автономной системы) в различных частях Интернета. Благодаря архитектуре системы маршрутизации для любого клиента существует единственный и самый "короткий" путь к любой другой сети Интернета. Таким образом, anycast позволяет клиенту установить связь с наиболее близкой в топологическом смысле сетью anycast без дополнительных изменений в ПО и протоколах.

Хотя эта технология наиболее широко используется для предоставления услуг DNS, при определенных условиях она может также быть использована даже для вэб-услуг.

В отношении DDoS anycast позволяет уменьшить концентрацию трафика и локализовать атаку, создавая местные точки притяжения . 

Блокирование трафика на границе

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

Распространенным способом автоматизации этого процесса и значительного уменьшения времени реакции на подобные инцидента является метод RTBH (Remote Trigger Black Hole, дословно Черная Дыра, Управляемая на Расстоянии). С его помощью внутреннее анонсирование атакуемой сети по протоколу iBGP специальным образом приведет к отбрасыванию трафика, адресованного этой сети, на граничных маршрутизаторах. Таким образом удается устранить побочный ущерб, хотя сама атака достигает желаемого результата отказа в обслуживании.

Подробно метод RTBH описан в RFC5635 (http://tools.ietf.org/html/rfc5635).

Координация с пирами и провайдерами транзита

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

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

Использование коммерческих продуктов и услуг по борьбе с атаками DDoS

Сегодня многие провайдеры облачных услуг хостинга включают противодействие атакам в свой пакет. Также существуют и специализированные услуги, например от компании Verisign (DDoS Protection Service) или Лаборатории Касперского (Kaspersky DDoS Prevention). Основой этих систем является распределенная высокопроизводительная сеть, позволяющая во время атаки перенаправлять на себя весь трафик атакуемой сети, анализировать и отфильтровывать атакующий трафик от полезного, передавая последний обратно в сеть клиента.

При достаточной производительности собственной сети можно использовать подобные системы фильтрации в рамках собственной инфраструктуры и под большим собственным контролем. Примером такого решения является Pravail Availability Protection System (APS) от компании Arbor Networks.

Социально-экономические трудности

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

Посмотрим, например, на проблему спуфинга. Технические методы борьбы были опубликованы более десяти лет назад, однако спустя 11 лет ситуация далека от идеальной. Согласно статистике проекта Spoofer (http://spoofer.cmand.org/), предоставляющего пользователям возможность проверить, позволяет ли их сеть/провайдер спуфинг, около 23% сетей открыты (см. рис 5). Учитывая, что результаты Spoofer могут не вполне отражать реальность, поскольку в эксперименте как правило участвуют более технически образованные пользователи, возможно имеющие больший контроль за своей сетью, это довольно широко открытая дверь для проведения рефлекторных атак.

Рисунок 5. Статистика открытых для спуфинга сетей (в процентах адресного пространства, анонсируемых префиксов и автономных систем). Источник: Проект Spoofer http://spoofer.cmand.org/.

Еще более печальна ситуация с открытыми резолверами. Чуть более, чем за семь лет их число стремительно возросло с 500 тысяч до 28 миллионов почти 60-кратное увеличение!

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

Известный экономический принцип экстерналии (http://ru.wikipedia.org/wiki/Экстерналия) в известной мере объясняет недостаточную степень использования этих мер сервис-провайдерами. Для изменения этой ситуации должны быть существенно уменьшена стоимость анти-спуфинга и выявлены дополнительные преимущества.

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

Хочется заметить, что Интернет, с его высокой степенью связности и взаимозависимости, открывает новый аспект безопасности. Безопасность и устойчивость Интернета зависит не только от того, насколько хорошо удается управлять рисками, представляющими угрозу для организации и ее ресурсов, но также, что очень важно, от признания и управления рисками, которые представляет сама организация (в результате своих действий или бездействия) для экосистемы Интернета - так сказать «исходящих» рисков. Этот аспект не всегда очевиден, особенно потому что преимущества от снижения таких рисков неявны, однако он является существенным условием фундаментального решения проблемы DDoS атак в Интернете.

Андрей Робачевский

Мнения, представленные в статье, не обязательно отражают официальную позицию Internet Society



[1] Атака на Spamhaus также включала «захват» префикса одного из DNS-серверов компании. Spamhaus использует DNS для предоставлении пользователям сведений о принадлежности того или иного адреса «черному» списку. Более подробно см. https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/