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

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

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

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

В марте 2013 года, компания Spamhaus, обслуживающая так называемые черные списки сетей, являющихся источником спама и прочего безобразия, стала объектом гигантской распределенной атаки отказа в обслуживании (Distributed Denial of Service attack, DDoS attack). Услуги компании попали под обстрел сотнями миллионов пакетов в секунду и трафиком, по некоторым оценкам достигшим пика в 300 Гбит/с, сметающим на своем пути сетевое оборудование.

Эта атака не исключение. В первом квартале 2015 года, по данным компании Arbor Networks, имела место атака в 334 Гбит/с. В том же квартале они зафиксировали 25 атак с объемом трафика больше, чем 100 Гбит/с. Большая часть этих атак является рефлекторными DDoS-атаками с усилением.

Этот тип атак также не нов – «технология» рефлекторной атаки с усилением впервые получила широкую известность в 1997 году. Но что действительно вызывает озабоченность, так это насколько относительно легко такие атаки организовать. Действительно, атаки этого типа довольно незатейливы и в то же время весьма разрушительны, благо «строительного материала» в Интернете предостаточно. Основными «строительными блоками» является наличие ботов с возможностью подмена IP-адреса источника (установка его на IP-адрес жертвы) и «рефлекторы» – например, открытые DNS-резолверы. Хорошо выбранный запрос DNS может предоставить 100-кратное усиление, что означает, что нужно сгенерировать 100 запросов общим потоком в 3 Гбит/с для создания сокрушительного суммарного потока в 300 Гбит/с. Этого можно достичь с помощью относительно небольшого набора клиентов.

Есть, конечно, DDoS-атаки, которые не используют эти два компонента; они бомбардируют жертву напрямую от многих глобально распределенных источников. Но такие атаки можно оттрассировать и они на два порядка сложнее и дороже.

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

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

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

• Использование возможности «спу­финга» — подмены IP-адреса отправи­теля на адрес «жертвы» с протоколами вроде UDP или ICMP, обеспечивающего передачу дейтаграмм без создания соеди­нения. Такие широко распространенные услуги Интернета, как SNMP и DNS ис­пользуют именно этот протокол переда­чи. Ключевым фактором здесь является отсутствие необходимости «рукопожатия», как, например, в случае с TCP, для начала передачи данных.
• Рефлекторы и усилители. Поскольку режимом работы многих услуг, основан­ных на протоколе UDP, является «за­прос- ответ», подмена адреса отправителя на адрес «жертвы» приведет к тому, что ответ на запрос будет доставлен именно туда. Представьте, что такого типа за­просы посланы из различных точек Ин­тернета. Все ответы на эти запросы будут направлены на один адрес, обеспечивая значительную концентрацию трафика в направлении «жертвы». «Хороший» реф­лектор также является усилителем, что означает, что размер ответа во много раз превышает размер запроса. Это позволяет создать асимметрию, когда относительно незначительный трафик запросов пре­вращается в мощный ответный поток.
• Ботнеты. Для эффективных атак такого рода необходима хорошо распределен­ная сеть источников. Инфицированные компьютеры, объединенные в ботнеты, являются для этого прекрасной стартовой площадкой.

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

Работает она следующим образом.

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

Таблица 1.  Типичные Усилители.  Источник: C. Rossow, «Amplification Hell: Revisiting Network Protocols for DDoS Abuse»

• Компьютеры ботнета получают инструк­цию начать атаку на жертву. По коман­де они посылают заданные запросы выбранным усилителям-рефлекторам, подменяя адрес отправителя на IP-адрес жертвы.
• Серверы-рефлекторы отвечают на не­винные с виду запросы, реально поступающие от различных кли­ентов, в то же время обрушивая усиленный трафик на жертву. Поскольку обычно используется большое количество рефлекторов, расположенных в различных точ­ках Интернета, объем трафика уве­личивается по мере приближения к жертве.
• Объем сгенерированного трафика превышает пропускную способ­ность каналов или максимальную производительность атакуемого сервера, тем самым вызывая отказ в обслуживании, или невозможность предоставления услуг. Услуга, под­вергшаяся атаке, на какое-то время перестает быть доступной в Интер­нете. Этот процесс схематически пред­ставлен на рис.1.

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

В качестве рефлекторов-усилителей так­же могут служить устройства поддержи­вающие открытый доступ к услуге SNMP (Simple Network Management Protocol), используемой для мониторинга и управле­ния сетью. Например, сценарий проведе­ния SNMP-атаки включает использования ботнета для генерирования сотен тысяч запросов “GetBulkRequest” к сотням таких устройств. В этих атаках часто используют­ся оконечные пользовательские устройства/ домашние маршрутизаторы, на которых по умолчанию включена поддержка SNMP на «публичном» (обращенном к глобаль­ному Интернету) интерфейсе. Размер типичного запроса “GetBulkRequest” составляет 60-102 байт (RFC3416), в то время как ответ на него гораздо больше – 423-1560 байт, что может обеспечить усиление в более чем 25 раз.

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

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

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

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

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

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

BCP38

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

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

В случае сетей широкополосного доступа идеальным местом искоренения спуфинга являются широкополосные концентраторы доступа (Broadband Access Concentrators, BAC), которые агрегируют пользователь­ские каналы. Примерами BAC являют­ся DSLAM (Digital Subscriber Line Access Multiplexer) для DSL-сетей или CMTS (cable modem termination system) для кабельных широкополосных сетей. Преимуществом использования BAC в качестве места филь­трования трафика с подложными адреса­ми является то, что здесь можно отдельно идентифицировать каждое соединение, да­лее они мультиплексируются и задача ста­новится сложнее.

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

Надо заметить, что спуфинг в широкопо­лосных сетях доступа может представлять серьезную проблему для самого операто­ра (в отличие от более распространенной ситуации, когда спуфинг скорее является угрозой для других сетей). Например, с помощью спуфинга злоумышленник мо­жет перехватить трафик другого пользо­вателя, нарушить систему учета, получить неавторизованный доступ к услугам или запустить атаку отказа в обслуживании на других пользователей сегмента. Не случайно проверка адре­са источника SAV (Source Address Verification) является обязатель­ной частью специ­фикации DOCSIS 3.0 (Data-Over-Cable Service Interface Specifications), определяющая переда­чу данных в кабельных сетях.

uRPF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Открытые резолверы представляют серьезную проблему, поскольку являются идеальными рефлекторами-усилителями: они готовы обслужить запросы от любого клиен­та, их число колоссально, они повсеместны. По подсчетам проекта Open Resolver сегодня существует более 15 миллионов таких серверов!

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

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

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

Идея механизма проста: сервер отвечает только на ограниченное число запросов от одного и того же клиента, которым соответ­ствует один и тот же ответ, в соответствии с заданным администратором параметром – числом ответов в секунду. Идентичными являются ответы для одного и того же суще­ствующего доменного имени (qname) и типа записи (qtype). Ответы на несуществующие поддомены (NXDOMAIN) или пустые за­просы (NODATA) также считаются идентич­ными и, соответственно, учитываются при подсчете.
В отношении клиентов идентичными считаются клиенты, принадлежащие одной и той же сети (адресному блоку), размер кото­рой задается администратором.

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

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

Как я уже упоминал, DNS яв­ляется не единственным эф­фективным усилителем. На рис. 4 показан растущий тренд использования других приложе­ний. Например, по данным системы ATLAS компании Arbor Networks, в первом кварта­ле 2015 года серверы точного времени, ис­пользующие протокол NTP, применялись в качестве рефлекторов-усилителей почти в 14% всех зафиксированных атак. Проект “NTP Scanning Project” содержит статистику потенциально открытых серверов времени, а также рекомендации по их проверке и правильной конфигурации. Другим попу­лярным протоколом стал SSDP, использу­ющийся для обнаружения устройств UPnP (Plug&Play). Многие оконечные устройства домашних сетей поддерживают этот прото­кол и являются открытыми для приема запросов извне сети, делая их замечательными рефлекторами, подобно открытым DNS-ре­золверам. Не исключено, что в будущем мы увидим новых фаворитов.

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

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

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

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

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

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

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

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

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

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

Распространенным способом автома­тизации этого процесса и значительного уменьшения времени реакции на подобные инциденты является метод RTBH (Remotely Triggered Black Hole, дословно «черная дыра, управляемая на расстоянии»). С его помощью внутреннее анонсирование ата­куемой сети по протоколу iBGP специаль­ным образом приведет к отбрасыванию трафика, адресованного этой сети, на гра­ничных маршрутизаторах. Таким образом удается устранить побочный ущерб, хотя сама атака достигает желаемого результата – отказа в обслуживании. Подробно метод RTBH описан в RFC5635.

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

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

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

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

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

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

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

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

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

Печальна ситуация и с открытыми реф­лекторами. Это и открытые резолверы (15 М), и открытые серверы времени (1,5 М), и системы, поддерживающие SSDP (3,7 M). Причина в большей степени экономическая. Например, внедрение механизмов антиспу­финга означает затраты, требует более под­готовленного персонала и включает опре­деленные риски (например, ошибочную фильтрацию легитимного трафика), в то же время преимущества этих мер недостаточно ощутимы. Меры эти позволяют исключить возможности использования сети в качестве стартовой площадки, но для безопасности самой сети и защиты ее от внешних атак они мало что значат.

Многие открытые рефлекторы являются бесплатным приложением модемов и марш­рутизаторов в домашних сетях – оконечных устройств в сетях широкополосного доступа.

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

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

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