Kurgan-Telecom Ru | Информационные технологии

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 1. DNS Amplification" из майского (2016) выпуска журнала "Системный администратор" .

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

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса DNS.

name='more'>
DNS amplification

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

Как такая атака выполняется.

Предположим, есть у нас такие участники:
192.168.10.128 - рекурсивный DNS-сервер;
192.168.10.129 - клиент.

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

client:~$ dig @192.168.10.128 google.com

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 271 IN A 173.194.122.227
google.com. 271 IN A 173.194.122.238
google.com. 271 IN A 173.194.122.228
google.com. 271 IN A 173.194.122.229
google.com. 271 IN A 173.194.122.233
google.com. 271 IN A 173.194.122.224
google.com. 271 IN A 173.194.122.230
google.com. 271 IN A 173.194.122.225
google.com. 271 IN A 173.194.122.226
google.com. 271 IN A 173.194.122.232
google.com. 271 IN A 173.194.122.231

;; MSG SIZE rcvd: 204

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

dns-server# tcpdump -n -s 0 host 192.168.10.129 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:11:20.965578 IP 192.168.10.129.47551 > 192.168.10.128.53: 28004+ A? google.com. (28)
22:11:20.989697 IP 192.168.10.128.53 > 192.168.10.129.47551: 28004 11/0/0 A 173.194.32.136, A 173.194.32.129, A 173.194.32.142, A 173.194.32.135, A 173.194.32.132, A 173.194.32.128, A 173.194.32.133, A 173.194.32.130, A 173.194.32.134, A 173.194.32.131, A 173.194.32.137 (204)

Видно, что запрос от клиента происходит всего один, далее рекурсивный сервер самостоятельно обращается к вышестоящим DNS, выясняя необходимую информацию, и в итоге клиент получает один ответный пакет во много раз больше размером (204 байт полезной нагрузки), чем исходный (28 байт). И это при том, что каждый пакет содержит еще 42 байта заголовков:
14 - Ethernet;
20 - IP
8 - UDP.
Итого, при запросе типа А по google.com 70-байтный запрос возвращает 246-байтный ответ.

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

client:~$ dig @192.168.10.128 -t ANY google.com

;; QUESTION SECTION:
;google.com. IN ANY

;; ANSWER SECTION:
google.com. 271 IN A 173.194.122.227
google.com. 271 IN A 173.194.122.238
google.com. 271 IN A 173.194.122.228
google.com. 271 IN A 173.194.122.229
google.com. 271 IN A 173.194.122.233
google.com. 271 IN A 173.194.122.224
google.com. 271 IN A 173.194.122.230
google.com. 271 IN A 173.194.122.225
google.com. 271 IN A 173.194.122.226
google.com. 271 IN A 173.194.122.232
google.com. 271 IN A 173.194.122.231
google.com. 571 IN MX 50 alt4.aspmx.l.google.com.
google.com. 571 IN MX 10 aspmx.l.google.com.
google.com. 571 IN MX 20 alt1.aspmx.l.google.com.
google.com. 571 IN MX 30 alt2.aspmx.l.google.com.
google.com. 571 IN MX 40 alt3.aspmx.l.google.com.
google.com. 20439 IN NS ns2.google.com.
google.com. 20439 IN NS ns1.google.com.
google.com. 20439 IN NS ns3.google.com.
google.com. 20439 IN NS ns4.google.com.
google.com. 20439 IN TYPE257 # 19 0005697373756573796D616E7465632E636F6D
google.com. 31 IN SOA ns2.google.com. dns-admin.google.com. 118858953 900 900 1800 60
google.com. 2439 IN TXT "v=spf1 include:_spf.google.com ~all"

;; MSG SIZE rcvd: 509

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

dns-server# tcpdump -n -s 0 host 192.168.10.129 and port 53

22:09:45.058655 IP 192.168.10.129.42278 > 192.168.10.128.53: 2825+ ANY? google.com. (28)
22:09:45.094795 IP 192.168.10.128.53 > 192.168.10.129.42278: 2825 23/0/0 A 173.194.32.128, A 173.194.32.136, A 173.194.32.135, A 173.194.32.134, A 173.194.32.130, A 173.194.32.137, A 173.194.32.131, A 173.194.32.133, A 173.194.32.132, A 173.194.32.129, A 173.194.32.142, NS ns4.google.com., NS ns1.google.com., NS ns3.google.com., NS ns2.google.com., MX aspmx.l.google.com. 10, MX alt1.aspmx.l.google.com. 20, MX alt4.aspmx.l.google.com. 50, MX alt2.aspmx.l.google.com. 30, MX alt3.aspmx.l.google.com. 40, Type257, SOA, TXT "v=spf1 include:_spf.google.com ~all" (509)

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

Злоумышленник, выполняющийатаку DNS amplification, для увеличения ее эффективности будет использовать следующие приемы:
Манипуляция размерами записей в DNS - чтобы ответ и коэффициент усиления был больше;
IP spoofing - чтобы ответ прилетел к жертве;
Высокая интенсивность DNS-запросов от имени жертвы.
Еще с 2000 года документы BCP38 и RFC2827 дают рекомендации, как противодействовать DDoS. Рассмотрим их практическую реализацию.

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

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

лишний сервис = лишняя уязвимость

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

client:~$netstat -nap | egrep 'udp|tcp'

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

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 192.168.10.128:53 0.0.0.0:* LISTEN 589/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 589/named
udp 0 0 192.168.10.128:53 0.0.0.0:* 589/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 589/named

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

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

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

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

client:~$netstat -nap | egrep 'udp|tcp'

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

Если в перечне видно подобное:

udp6 0 0 :::53 :::* 589/named

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

net.ipv6.conf.all.disable_ipv6 = 1
и выполнив команду:

sudo sysctl -p /etc/sysctl.conf

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

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

3. Разрешено только то, что разрешено. Явно не разрешенные доступы запрещаются.

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

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

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

allow-transfer {"none";};
allow-recursion {"none";};
recursion no;
Если же сервер выполняет роль и авторитативного, и рекурсивного DNS, необходимо разрешить выполнять запросы только из доверенных подсетей, модифицируя конфигурационный файл следующим образом:

acl "trusted_ip" {
192.168.0.0/16;
10.0.0.0/8;
localhost;
localnets;
};

options {

allow-recursion { trusted_ip; };
allow-query-cache { trusted_ip; };

};

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

EDNS0

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

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

client:~$ dig @192.168.10.128 -t ANY irs.gov

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

;; Truncated, retrying in TCP mode.

;; QUESTION SECTION:
;irs.gov. IN ANY

;; ANSWER SECTION:
irs.gov. 7077 IN RRSIG SOA 7 2 7200 20160416030058 20160409020058 13368 irs.gov. mmRD+b1bZHI+nKC3uc4zHtbfspUwMARdGVkWgsoYd0sRKwvKzxJyWzJ9 2/4zeNTB/nAFGcZAF3Cu5fklQ+WbrpsSk3Nq7emzZPo45DXWLk0/JcaH 2ydEGLXqJC5iF4uBhMxRoIOtzvFzXn4RqtiVRHUImv04ddjE8hdky2U1 0rA=
irs.gov. 7077 IN SOA ns1.irs.gov. it.aciouns.external.dns.admin.irs.gov. 2010085496 3600 1800 2419200 900
irs.gov. 7077 IN RRSIG NSEC3PARAM 7 2 7200 20160416030058 20160409020058 13368 irs.gov. MTDhI91CSla/AsANt3j9Bu5KmPyL0ZCbosh3V8qNIC89C+Ra0PofExcr FhGCSLNA518UgbcLp+a9CXWfkg4Pnc/Phm5aZQK1SqXW8kORlGTcR9l5 c3Liy01hG3ddooCH/fseY3htzvcfe8OIxj2emRougRhdWt3vB4Cl7NpT CR4=
irs.gov. 7077 IN NSEC3PARAM 1 0 100 AABBCCDD

;; MSG SIZE rcvd: 3334

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

20:10:11.512845 IP 192.168.10.129.47720 > 192.168.10.128.53: 62574+ ANY? irs.gov. (25)
20:10:11.513048 IP 192.168.10.128.53 > 192.168.10.129.47720: 62574| 4/0/0 RRSIG, SOA, RRSIG, Type51 (450)
20:10:11.513561 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [S], seq 1836767364, win 29200, options [mss 1460,sackOK,TS val 78657 ecr 0,nop,wscale 7], length 0
20:10:11.513580 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [S.], seq 1926843090, ack 1836767365, win 28960, options [mss 1460,sackOK,TS val 89135 ecr 78657,nop,wscale 7], length 0
20:10:11.513710 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 1, win 229, options [nop,nop,TS val 78657 ecr 89135], length 0
20:10:11.513755 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [P.], seq 1:28, ack 1, win 229, options [nop,nop,TS val 78657 ecr 89135], length 2737688+ ANY? irs.gov. (25)
20:10:11.513762 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [.], ack 28, win 227, options [nop,nop,TS val 89135 ecr 78657], length 0
20:10:11.513988 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [P.], seq 1:3337, ack 28, win 227, options [nop,nop,TS val 89135 ecr 78657], length 333637688 31/6/12 RRSIG, SOA, RRSIG, Type51, RRSIG, RRSIG, A 166.123.218.220, RRSIG, TXT "v=spf1 ip4:152.216.0.0/20 ip6:2610:30::/32 include:qai.irs.gov -all", RRSIG, MX emg6.irs.gov. 10, MX emg5.irs.gov. 10, MX emg3.irs.gov. 10, MX emg2.irs.gov. 10, MX emgw.irs.gov. 20, MX emg1.irs.gov. 10, MX emg4.irs.gov. 10, RRSIG, RRSIG, DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, DS, NS ns2.irs.gov., NS ns6.irs.gov., NS ns4.irs.gov., NS ns5.irs.gov., NS ns3.irs.gov., NS ns1.irs.gov. (3334)
20:10:11.514121 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 3337, win 281, options [nop,nop,TS val 78657 ecr 89135], length 0
20:10:11.518986 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [F.], seq 28, ack 3337, win 281, options [nop,nop,TS val 78658 ecr 89135], length 0
20:10:11.519093 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [F.], seq 3337, ack 29, win 227, options [nop,nop,TS val 89136 ecr 78658], length 0
20:10:11.519312 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 3338, win 281, options [nop,nop,TS val 78658 ecr 89136], length 0

Response Rate Limiting (RRL)

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

1. Авторитативный сервер
Чтобы не давать возможности использовать авторитативный DNS-сервер как источник для атаки, необходимо настроить ограничение на количество ответов в секунду, которые сервер предоставит одному IP-адресу. Подобное ограничение позволит сэкономить ресурсы сервера и снизить интенсивность атаки. Для использования Response Rate Limiting (RRL) данная функция должна быть активирована при компиляции DNS-сервера (--enable-rrl).
В конфигурационном файле named необходимо прописать, как минимум, такие параметры применимо к одному клиенту:
slip - количество пакетов, ответные пакеты на которые отправляются усеченными (truncated);
responses-per-second - количество ответов в секунду.
Например:
slip 2
responses-per-second 5

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

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

Рис. 1. DNS-запрос.
Из рисунка 1 видно, что запрос типа ANY идентифицируется двухбайтовой последовательностью символов 00ff, идущими под номерами 63-64 в данном пакете. Iptables считает последовательность символов с IP-заголовка, поэтому начинать искать данную последовательность в данном случае нужно будет, начиная с 49го байта. Соответственно, смещение для iptables будет равняться 48.
В соответствии с RFC 1034 и 1035, под query type выделено 2 байта с максимальным десятичным значением 255.
Значения типов 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 байта и зона.
Если выполнить

$ dig -t ANY qwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiop123.northwesternmutual

то в нем байты, обозначающие query type, будут идти под номером 138-139, и поиск 4-байтного 0000FF00 нужно начинать с 123 байта. Не самый большой запрос, но и вероятность подобных запросов очень невелика.
Соответственно, чтобы минимизировать возможный DDoS, нужно сконфигурировать iptables следующим образом:
пропускать за 10 секунд 3 DNS-запроса типа ANY с одного IP,
в UDP-пакетах с портом назначения 53,
считая запросом типа ANY последовательность "0000FF00" в 40-127 байтах пакета.
В итоге, искомая последовательность команд iptables будет иметь следующий вид:

iptables -N DNS_ANY
iptables -v -A DNS_ANY -m recent --name dns_any --update --seconds 10 --hitcount 3 -j DROP
iptables -v -A DNS_ANY -m recent --name dns_any --set -j ACCEPT
iptables -v -A INPUT -p udp --dport 53 -m string --from 40 --to 123 --algo bm --hex-string '|0000FF00|' -j DNS_ANY

При необходимости фильтровать интенсивность запросов других типов (TXT, DNSSEC, RRSIG) частота легитимных запросов может варьироваться в зависимости от использующих их сервисов. Если, все же, принято решение фильтровать интенсивность, для правил iptables вместо 0000FF00 выбираем следующие последовательности:
RRSIG - 00002E00
DNSKEY - 00003000
TXT - 00001000

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

Рис. 2. Подключение клиента.

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

CE(config-if)# ip verify unicast source reachable-via rx

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

Выводы

Выполнив описанные настройки, мы напрямую не защитимся от атак на нашу сеть и сервера, но сделаем невозможным использование своих ресурсов для атак на других, а также минимизируем количество оснований для кричащих заголовков в прессе «Русские хакеры атаковали...».
Итого, уменьшить количество DDoS-атак типа DNS amplification и минимизировать участие своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений:
Отключение неиспользуемых сервисов на всех серверах.
Управление обновлениями.
Ограничение рекурсивной обработки запросов только для клиентов предоставляемого сервиса.
Переход на TCP в соответствии с рекомендациями RFC5966.
Ограничение интенсивности ответов (Response Rate Limiting) на DNS-серверах посредством настроек Bind либо iptables.
Применение проверок uRPF на активном сетевом оборудовании.
И если так поступит каждый администратор серверов, доступных из сети Интернет, цифровой мир приблизится еще на один шаг к совершенству.