Это перевод оригинальной публикации Артема ximaera Гавриченкова «Understanding the facts of memcached amplification attacks», опубликованной в блоге APNIC (Азиатско-Тихоокеанский сетевой информационный центр).

Неделя с 25 февраля по 3 марта была высокоинтенсивной с точки зрения memcached-амплифицированных DDoS-атак во всех уголках мира, то есть в интернете.

Тем не менее, давайте еще раз вспомним все факты, которые нам известны об амплифицированных атаках.

Факт номер один: Амплификаторы были, есть и будут есть

NTP (Network Time Protocol) был первым протоколом, злонамеренно использованным в качестве амплификатора (усилителя) DDoS-атак еще в 2013 году. Тысячи и сотни тысяч NTP-серверов к тому моменту были развернуты по всей сети, так что использование данного вектора амплификации было вполне выгодно злоумышленникам. И NTP давал такую возможность, что вылилось в волну амплифицированных NTP DDoS-атак. В начале 2014 года на какое-то время NTP в качестве главного амплификатора стал даже популярнее протокола DNS (Domain Name System).

В 2015 году мы увидели массовый подъем ботнетов. Они использовали основанные на UDP (User Datagram Protocol) амплификаторы, установив рекорд по полосе DDoS-атак, наблюдавшихся к тому моменту. Разные ботнеты использовали разные техники, но комбинация тысяч скомпрометированных устройств и NTP- или DNS-амплификации делала такие атаки крайне опасными, как показал отказ в обслуживании компании Dyn и OVH в 2016. Совместное противодействие командно-контролирующим центрам ботнетов (C&C) сделало возможным избежание потенциального захвата ботнетами контроля над всей сетью.

Тот же 2016 год наглядно продемонстрировал, что NTP и DNS не единственные протоколы, использующиеся в качестве амплификаторов. Portmap, SNMP, SSDP, Chargen, MSSQL, CLDAP и некоторые другие сетевые протоколы предоставляют отличные возможности для усиления DDoS-атак. Несмотря на это, уже следующий 2017 год принес множество разнообразных уязвимостей, позволяющих эксплуатировать темные стороны других протоколов, ведь атакующие со знанием не ходят в отпуск и пытаются искать новые, ранее не изученные, векторы атак.

Видеоинтервью на английском об атаках с DNS амплификацией:

Факт номер два: Амплификация не изменилась и не эволюционировала — просто нашлись новые уязвимости

Более того — именно уязвимости и являются причиной, по которой мы засвидетельствовали события конца февраля и начала марта 2018 года. После того как в 2017 году группа китайских исследователей из 0Kee описала путь амплификации через memcached, у злоумышленников ушло всего пару месяцев на то, чтобы установить мировой рекорд амплифицированной DDoS-атаки, проведенной с помощью незащищенного memcached сервера. Будучи свободно распространяемым, бесплатным и присутствуя практически в каждом Linux-дистрибутиве, memcached являет собой мощнейший инструмент разрушения, предоставляя гипотетически бесконечный фактор амплификации (по нашим данным, коэффициент амплификации более 10000х, по данным Akamai — более 50000х). В этом случае мы снова упираемся в пропускную способность транзитных соединений как основное требование для выживания под подобной атакой канального уровня.

Ссылка на оригинальную презентацию 0Kee.

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

Общая концепция отражения и амплификации нисколько не поменялась. Сначала нелегитимные запросы отправляются на уязвимый (открытый всему миру на порту 11211) сервер memcached (эта техника традиционно называется IP-spoofing). После этого UDP-сервер подготавливает ответ и с помощью атакующего отправляет тысячи ответов на цель, заливая этим вполне легитимным с точки зрения memcached флудом ответов целевой хост. Огромные значения PPS и BPS не могут быть обойдены какими-то общими способами и средствами, так как такой объем трафика быстро делает устройства маршрутизации на границах сетей недоступными вследствие исчерпания ресурса.
 

Факт номер три: Когда что-то работает — оно работает; но иногда против вас

Итак, уже установлен новый мировой рекорд в полосе DDoS-атаки: Arbor Networks показала 1,7 Тбит/с на одного из своих клиентов, в то время как GitHub под защитой Akamai пережил 1,3 Тбит/с. К атаке на GitHub было приковано внимание многих медиа, так как это крупный и популярный ресурс, на нормальную работу которого опирается множество сервисов и продуктов по всему миру. Клиент Qrator Labs — платежная система Qiwi, успешно нейтрализовала атаку в 480 Гбит/с амплифицированного memcached UDP-трафика.

Статистика Shodan все еще показывает большое количество активных memcached амплификаторов, открытых для злоумышленников из любой точки планеты:

Как можно увидеть из данного скриншота, континентальный Китай и США являются двумя основными источниками memcached амплификаторов. Qrator.Radar также собрал некоторую статистику по количеству доступных и уязвимых memcached-серверов:

Количество таких серверов падает очень быстро. Почему? Никто не хочет ни убивать, ни быть убитым. Операторы (классические провайдеры связи и транзитные операторы) переживают о своих сетях и о том, что они могут быть использованы в качестве инструмента усиления того, что с легкостью можно назвать «незаконным».

Для того чтобы сделать эту информацию еще более очевидной и понятной, мы собрали статистику по количеству амплификаторов в customer cone отдельных автономных систем, вот пример верхней части этого списка:

DDoSmon также предоставляет возможность получать достаточно детальную статистику по количеству целей memcached-амплифицированных DDoS-атак, где также видны актуальные тренды: https://ddosmon.net/memcached_amplification_attack

Факт номер четыре: все, что может быть исправлено, должно быть исправлено

Пользователи memcached должны отключить поддержку UDP в случае, если они не используют UDP для передачи данных. Также memcached должен слушать только localhost — не все доступные интерфейсы, как это происходит в некоторых установках по умолчанию.

Любой игрок крупнее отдельно взятой компании, отвечающей только за себя или одного человека, ответственного за конкретный ресурс, должен на 100% убедиться в том, что никакие memcached серверы НЕ видны из остальной сети и закрыты файрволом.

Обязательно обратите внимание на рекомендации AUSNOG (Australian Network Operators’ Group) к имплементации Explotable Port Filters. 

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

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

Здесь содержится сразу несколько рекомендаций: http://www.senki.org/memcached-on-port-11211-udp-tcp-being-exploited/

NTT рекомендует добавить memcached UDP/11211 в тот же самый список “exploitable ports”, как NTP, CHARGEN и SSDP. Ниже показан пример конфигурации для IOS XR, позволяющий установить rate-limit на чувствительные к амплификации UDP-порты до 1% от емкости. Qrator Labs считает данный способ обработки memcached-трафика крайне полезным и эффективным, рекомендуя его к развертыванию:

ipv4 access-list exploitable-ports
permit udp any eq ntp any
permit udp any eq 1900 any
permit udp any eq 19 any
permit udp any eq 11211 any
!
ipv6 access-list exploitable-ports-v6
permit udp any eq ntp any
permit udp any eq 1900 any
permit udp any eq 19 any
permit udp any eq 11211 any
!
class-map match-any exploitable-ports
match access-group ipv4 exploitable-ports
match access-group ipv6 exploitable-ports-v6
end-class-map
!
policy-map ntt-external-in
class exploitable-ports
police rate percent 1
conform-action transmit
exceed-action drop
!
set precedence 0
set mpls experimental topmost 0
!
class class-default
set mpls experimental imposition 0
set precedence 0
!
end-policy-map
!
interface Bundle-Ether19
description Customer: the best customer
service-policy input ntt-external-in
ipv4 address xxx/x
ipv6 address yyy/y
...
!
interface Bundle-Ether20
service-policy input ntt-external-in
...
... etc ...