Защита от DDoS-атаки типа «усиление» (amplification) своими руками

Чтобы сделать свой вклад в защиту всемирного киберпространства от DDoS, совсем не обязательно покупать дорогостоящее оборудование. Любой администратор сервера может поучаствовать без дополнительных материальных вложений, используя только знания и немного времени.
DDOS защита от DNS amplification

ДДоС атака DNS amplification

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

Источниками вредоносного трафика могут быть:
> третьи лица;
> клиенты хостинг-провайдера;
> абоненты интернет-провайдера.

Как такая атака выполняется? Предположим, есть у нас такие участники:

> 192.168.10.128 – рекурсивный DNS-сервер;
> 192.168.10.129 – клиент.

Выполняем элементарный DNS-запрос по FQDN, у которого гарантированно большое количество соответствующих ему IP-адресов:

На DNS-сервере запустим в это время tcpdump:


Видно, что запрос от клиента происходит всего один, далее рекурсивный сервер самостоятельно обращается к вышестоящим DNS, выясняя необходимую информацию, и в итоге клиент получает один ответный пакет во много раз больше размером (204 байта полезной нагрузки), чем исходный (28 байт). И это притом что каждый пакет содержит еще 42 байта заголовков:

> 14 – Ethernet;
> 20 – IP;
> 8 – UDP.

Итого: при запросе типа А по google.com 70-байтный запрос возвращает 246-байтный ответ.

Дальше – больше. Теперь давайте попробуем запросить не только A, но и все записи, касающиеся запрашиваемого FQDN.

На сервере tcpdump показывает ответ большего размера, чем в прошлом случае, поскольку клиенту возвращается информация о записях всех типов по домену google.com:

То есть один только ответ на запрос типа ANY по зоне google.com на момент в ответном пакете 509 + 42 = 551 байт. Есть такое понятие, как коэффициент усиления, который является соотношением размеров пакета-инициатора и ответного пакета. В описанных выше случаях он довольно небольшой (246/70 = 3.5 и 551/70 = 7.87, чего явно недостаточно для серьезной DDoS-атаки), но если количество записей увеличить, то ответ может составлять несколько килобайт.
Злоумышленник, выполняющий атаку DNS amplification, для увеличения ее эффективности будет использовать слеc, для увеличения ее эффективности будет использовать следующие приемы:

> манипуляция размерами записей в DNS – чтобы ответ и коэффициент усиления были больше;
>IP spoofing – чтобы ответ прилетел к жертве;
> высокая интенсивность DNS-запросов от имени жертвы.

Еще с 2000 года документы BCP38 и RFC2827 дают рекомендации, как противодействовать DDoS. Рассмотрим их практическую реализацию.

Отключение сервиса DNS

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

Проверить, какие сетевые службы запущены и готовы обрабатывать запросы, на Unix-сервере можно с помощью команды:

В случае наличия DNS-сервера увидим приблизительно следующее:

Если запущенный сервис в действительности не используется, а запущен исторически, то необходимо:

> остановить сервис DNS;
> удалить службу DNS-сервера из загрузочных скриптовсистемы;
> деинсталлировать DNS-сервер.

Во многих реализациях ОС все три действия могут быть выполнены при удалении пакета программ DNS-сервера (деинсталляции).

Защита DNS-серверов

Если же роль DNS-резолвера актуальна, то необходимо обеспечить максимальную защиту сервера от атак извне. Методы защиты используем следующие:

Метод 1. Отсутствие запущенных неиспользуемых сетевых сервисов и протоколов – проверяется той же командой:

с последующей остановкой и удалением пакетов, не используемых на сервере. Если в перечне видно подобное:

это говорит об использовании IPv6.
При обслуживании запросов исключительно по IPv4, необходимо отключить IPv6 (помним равенство «лишний сервис = лишняя уязвимость»), указав в /etc/sysctl.conf строку:

и выполнив команду:

Полный комплекс по защите ОС не описывается, поскольку объем материала уведет от основной мысли статьи.

Метод 2. Разрешение управляющих протоколов только из внутренней сети компании и доверенных IP.

Достигается либо ограничением с помощью внешнего firewall/VPN концентратора (при наличии), либо системного iptables/ ipfw/и т.п. в зависимости от архитектуры сегмента сети, в котором расположен сервер.

Метод 3. Разрешено только то, что разрешено.

Явно не разрешенные доступы запрещаются.

Метод 4. Установка последних стабильных обновленийи патчей ОС, а также используемых прикладных сервисов.

Ограничение рекурсии DNS

Если DNS-сервер исключительно авторитативный, то обработка рекурсивных запросов на нем не нужна. Он должен отвечать только на запросы по своей зоне, не перенаправляя их. Для этого на примере Bind в раздел options конфигурационного файла добавляются строки:

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

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

EDNS0

В RFC6891 описаны требования к поддержке Extension Mechanisms for DNS (EDNS0) серверами во избежание атак типа DNS amplification и при этом совместимости с RFC1035. По умолчанию для обработки запросов используется протокол UDP, но в случае когда размер UDP-сообщения в ответном пакете превышает 512 байт, должна происходить инициация запроса по протоколу TCP.

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

показывает следующее:

где за счет размеров и количества записей объем сообщения будет более 3 килобайт, то есть коэффициент усиления атаки будет уже порядка 50 при использовании протокола UDP. Но, как видно, в связи с тем, что был получен усеченный UDP-пакет, клиент переинициировал запрос, используя TCP. Красным выделено то, на что следует обратить внимание: переинициация по TCP и размер сообщения.

В дампе трафика переход на TCP выглядит так:

Response Rate Limiting (RRL)

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

1. Авторитативный сервер

Чтобы не давать возможности использовать авторитативный DNS-сервер как источник для атаки, необходимо настроить ограничение на количество ответов в секунду, которые сервер предоставит одному IP-адресу. Подобное ограничение позволит сэкономить ресурсы сервера и снизить интенсивность атаки. Для использования Response Rate Limiting (RRL) данная функция должна быть активирована при компиляции DNS-сервера (–enable-rrl).

В конфигурационном файле BIND необходимо прописать как минимум такие параметры применимо к одному клиенту: > slip – количество пакетов, ответные пакеты на которые отправляются усеченными (truncated); > responses-per-second – количество ответов в секунду.

Например:

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

2. Рекурсивный сервер

Для рекурсивных серверов подойдет другое решение обеспечения RRL. Логично, что большинство запросов к DNS серверам имеют тип A либо CNAME. Интенсивность query type ANY, TXT, RRSIG, DNSSEC в норме, на порядки ниже. Значит, частоту их обработки необходимо контролировать. Предположим, разрешить одному клиенту выполнять за 10 секунд не более трех запросов type ANY. Несмотря на то что подобная фильтрация более характерна для специфических решений класса Application Firewall, задача абсолютно выполнима с помощью всем известного инструмента iptables.

Любой DNS-запрос может быть идентифицирован как некая последовательность символов в пакете. Главное – понять вид последовательности, в каком месте искать и как указать это iptables. Рассмотрим пример запроса.

Из рис. 1 видно, что запрос типа ANY идентифицируется двухбайтовой последовательностью символов 00ff, идущих под номерами 63-64 в данном пакете. Iptables считает последовательность символов с IP-заголовка, поэтому искать данную последовательность в этом случае нужно будет начиная с 49-го байта. Соответственно, смещение для iptables будет равняться 48.

В соответствии с RFC 1034 и 1035 под query type выделено 2 байта с максимальным десятичным значением 255.

Рисунок 1. DNS-запрос

Значения типов DNS-запросов:
> ANY – 255 (0x00FF)
> RRSIG – 46 (0x002e)
> DNSKEY – 48 (0x0030)
> TXT – 16 (0x0010)

Следующим в пакете идет класс запроса. Согласно RFC это также 16-битная величина, значения которой находятся в диапазоне от 0x0001 до 0x00FF. То есть байт, следующий после типа запроса, будет также равен 0x00.

Сам по себе байт, предшествующий query type, также всегда будет равен двум нулям (0x00), поэтому для более четкого описания последовательности символов для поиска возьмем 0000FF00.

Самым коротким будет DNS-запрос к зоне root (.), где query type будет идти в 55-56-м байтах, и фрагмент 0000FF00 нужно считать начиная с 40-го байта для iptables. Ограничение на размер query name – 63 байта и зона.

Если выполнить:

то в нем байты, обозначающие query type, будут идти под номером 138-139, и поиск 4-байтного 0000FF00 нужно начинать с 123-го байта. Не самый большой запрос, но и вероятность подобных запросов очень невелика.

Соответственно, чтобы минимизировать возможный DDoS, нужно сконфигурировать iptables следующим образом:

>  пропускать за 10 секунд три DNS-запроса типа ANY с одного IP;
>  в UDP-пакетах с портом назначения 53;
>  считая запросом типа ANY последовательность 0000FF00 в 40-127-м байтах пакета.

В итоге искомая последовательность команд iptables будет иметь следующий вид:

 

При необходимости фильтровать интенсивность запросов других типов (TXT, DNSSEC, RRSIG) частота легитимных запросов может варьироваться в зависимости от использующих их сервисов. Если все же принято решение фильтровать

интенсивность, для правил iptables вместо 0000FF00 выбираем следующие последовательности:

uRPF-check. В случае когда зараженный клиент, инициирующий трафик с поддельных IP-адресов, на уровне L3 терминируется на вашем оборудовании, защититься от спуфинга из этой подсети можно, используя технологию Unicast Reverse Path Check (uRPF). Суть ее для подобных подключений в том, чтобы обрабатывать пакеты, влетающие на определенный интерфейс, только в случае присутствия IP-адреса в таблице маршрутизации через этот же интерфейс.

Предположим, в схеме подключения, обозначенной на рис. 2, необходимо выпускать в интернет только пакеты из «честных» подсетей клиента 192.0.2.0/24 и 198.51.100.0/24, не пропуская адреса из других подсетей.

3. Подключение клиента

Соответствующая команда Cisco IOS будет выглядеть следующим образом:

и может быть применена как на интерфейсе Gi0/1 маршрутизатора PE (provider edge router – граничный маршрутизатор провайдера, к которому подключается нетранзитный клиент), так и на интерфейсах VLAN2 и VLAN100 маршрутизатора CE (маршрутизатор клиента).

Выполнив описанные настройки, мы напрямую не защитимся от атак на нашу сеть и серверы, но сделаем невозможным использование своих ресурсов для атак на других, а также минимизируем количество оснований для кричащих заголовков в прессе «Русские хакеры атаковали…».

Рисунок 2. Схема подключения

Итого: уменьшить количество DDoS-атак типа DNS amplification и минимизировать участие своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений:

Отключение неиспользуемых сервисов на всех серверах.
> Управление обновлениями.
> Ограничение рекурсивной обработки запросов только для клиентов предоставляемого сервиса.
> Поддержка EDNS0.
> Ограничение интенсивности ответов (Response Rate Limiting) на DNS-серверах посредством настроек Bind либо iptables.
> Применение проверок uRPF на активном сетевом оборудовании.

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

Рейтинг материала
[Голосов: 1 Рейтинг: 5]
20 января 2017, 07:29

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *