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

Рефлекторные атаки с усилением являются постоянно растущей угрозой для нормального функ­ционирования Интернета, нанося существенный экономический и социальный ущерб. Гигантская асимметрия между незначительными силами и затратами атакующего и сокрушительной мощно­стью атак, еще более усиленная невозможностью обнаружения и наказания преступников, дела­ют этот класс атак сущим проклятьем Сети. Благодаря чему такие атаки возможны, каковы пути решения проблемы 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
NTP UDP/123 4600 1.5М
CHARGEN UDP/19 360 90К
SSDP UDP/1900 80 3.7М
  • Компьютеры ботнета получают инструк­цию начать атаку на жертву. По коман­де они посылают заданные запросы выбранным усилителям-рефлекторам, подменяя адрес отправителя на IP-адрес жертвы.
  • Серверы-рефлекторы отвечают на не­винные с виду запросы, реально поступающие от различных кли­ентов, в то же время обрушивая усиленный трафик на жертву. Поскольку обычно используется большое количество рефлекторов, расположенных в различных точ­ках Интернета, объем трафика уве­личивается по мере приближения к жертве.
  • Объем сгенерированного трафика превышает пропускную способ­ность каналов или максимальную производительность атакуемого сервера, тем самым вызывая отказ в обслуживании, или невозможность предоставления услуг. Услуга, под­вергшаяся атаке, на какое-то время перестает быть доступной в Интер­нете. Этот процесс схематически пред­ставлен на рис.1.

 

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

InternetInside_N2-22

Классическим примером рефлектор­ной атаки является так называемая атака “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 маршрут.

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

InternetInside_N2-23

 

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

InternetInside_N2-24

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

Начиная с конца 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-ре­золверам. Не исключено, что в будущем мы увидим новых фаворитов.

 

Рис. 4  Использование различных «усилителей» в рефлекторных атаках. Источник: Данные ATLAS компании Arbor Networks, www.slideshare.net/Arbor_Networks/at­las-q2-2015final

InternetInside_N2-25

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

Надеяться на то, что атаки 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 могут не вполне отражать реальность, поскольку в эксперименте как правило участвуют более технически обра­зованные пользователи, возможно, имею­щие больший контроль за своей сетью, это довольно широко открытая дверь для про­ведения рефлекторных атак.

 

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

InternetInside_N2-26

 

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

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

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

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

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

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Добавить комментарий