Анатомия рефлекторных атак
Андрей РобачевскийРефлекторные атаки с усилением являются постоянно растущей угрозой для нормального функционирования Интернета, нанося существенный экономический и социальный ущерб. Гигантская асимметрия между незначительными силами и затратами атакующего и сокрушительной мощностью атак, еще более усиленная невозможностью обнаружения и наказания преступников, делают этот класс атак сущим проклятьем Сети. Благодаря чему такие атаки возможны, каковы пути решения проблемы 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»
Протокол | Протокол/ Порт | Наблюдаемый коэффициент усиления | Число доступных рефлекторов- усилителей |
DNS | UDP/53 | 100 | 7-15М |
SNMPv2 | UDP/161 | 12 | 5М |
NTP | UDP/123 | 4600 | 1.5М |
CHARGEN | UDP/19 | 360 | 90К |
SSDP | UDP/1900 | 80 | 3.7М |
- Компьютеры ботнета получают инструкцию начать атаку на жертву. По команде они посылают заданные запросы выбранным усилителям-рефлекторам, подменяя адрес отправителя на 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-атак в Интернете.