Выбрать язык


Выбрать язык | Show only


Русский | English


четверг, 25 августа 2016 г.

Защита от DDoS подручными средствами. Часть 2. NTP Amplification

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



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

В прошлой статье рассматривался протокол
DNS и варианты его защиты от использования в DDoS-атаках. Продолжим анализ атак типа "усиление" (amplification). 

NTP amplification
Суть атаки заключается в том, чтобы в ответ на NTP-запрос приходил ответ, в несколько раз больший, чем запрос. Поскольку протокол NTP, как и DNS, основан на UDP, в запросе подменяется адрес отправителя на адрес жертвы, но многократное увеличение ответа происходит не за счет рекурсии, а в связи с возможной уязвимостью сервиса ntpd. Естественно, не каждый запрос к серверу вызывает подобный эффект, а только команды  REQ_MON_GETLIST и  REQ_MON_GETLIST_1, которые изначально разрабатывались для того, чтобы администратор сервера мог вести учет клиентов, которые используют его NTP-сервер, и отслеживать обращения к серверам. Согласно CVE-2013-5211, данное свойство признано уязвимостью, которая устранена в версии ntpd 4.2.7p26. Несмотря на то, что с момента выхода обновленной версии NTP-сервера прошло 2 года, сейчас в Интернет большое количество IP-адресов, подверженных вышеописанной уязвимости.

Как проверить, уязвим ли ваш NTP-сервер к подобной атаке?
На самом сервере можно выполнить команду:

# ntpd –version

Предположим, сервер устарел, уязвим и показывает версию:

ntpd 4.2.6p5

Контрольная проверка того, что данная версия действительно отвечает на MON_GETLIST и  MON_GETLIST_1, производится командой

ntpdc -c monlist <server-address>

которую можно выполнить как непосредственно на сервере, так и со стороны клиента.
Уязвимый ntpd выдаст приблизительно следующее:

remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
xx.xxx.12.217            123 192.168.10.128         6 4 4    1d0      9      44
xx.xxx.132.250           123 192.168.10.128         6 4 4    1d0      9      45
xxxx.yyyyy.ru            123 192.168.10.128         6 4 4    1d0      9      46
xx.xxx.205.75            123 192.168.10.128         6 4 4    1d0      9      47
xxxx.xxxxxxxx.ru         123 192.168.10.128         1 4 4    1d0     51      51
xxxx.yyyyyyyy.ru         123 192.168.10.128         1 4 4    1d0     52      52
xxxx.zzzzzzzz.ru         123 192.168.10.128         1 4 4    1d0     53      53
<skipped>

При этом tcpdump покажет, что для получения объемного ответа запрос нужен всего один, не требующий верификации источника:

13:31:13.403225 IP 192.168.10.129.38131 > 192.168.10.128.ntp: NTPv2, Reserved, length 192
13:31:13.440938 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441190 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441624 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441894 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.443563 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.443952 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444270 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444621 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444894 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.445510 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446094 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446267 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446861 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.447352 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.447620 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440

Попробуем посчитать коэффициент усиления данной атаки при заданном выше количестве пакетов. Он равен отношению объема ответа к объему запроса.
Учитывая то, что tcpdump в значении length показывает только количество байт полезной нагрузки, добавляем к каждому пакету (и запросу, и ответу) по 42 байта заголовков:

14 - Ethernet;
20 - IP
8 - UDP.

Получим, что в ответ на один запрос объемом
192+42=234 байта 

уязвимый сервер отдал 15 ответных пакетов по
440+42=482 байта,

итого
482х15=7230 байт.

Коэффициент усиления в данном случае равен:
7230/234 = 30,9

Рассмотрим ответный пакет, изображенный на рис. 1. 



Рис. 1. Ответный пакет NTP-сервера.
Видим, что каждый ответ объемом 482 байт содержит 6 адресов из списка monlist. При этом, команда 

ntpdc -c monlist <server-address>

может вернуть до 600 записей. Несложная математика подсказывает, что ответных пакетов по 482 байта может быть до 100 на один 234-байтный запрос. Соответственно, коэффициент усиления может достигать значения:
482х100/234=206

Несложно подсчитать, сколько при таком коэффициенте нужно запросов от подменного IP-адреса жертвы для того, чтобы осуществить атаку мощностью 1 Gbps. Сначала переведем байты в биты:
234 байт (запрос) = 234х8 = 1872 бит;
482 байт (ответ) = 482х8 = 3856 бит;
1 гигабит = 1024х1024х1024 = 1 073 741 824 бит

Для вытеснения легитимного трафика с канала в 1 Gbps необходимо такое количество ответов в секунду:
1 073 741 824 / 3 856 = 278 460

При том, что «правильно приготовленный» сервер может отдать 100 ответов на 1 запрос, количество необходимых запросов в секунду для получения 1 Gbps ответных пакетов должно быть:
278 460 / 100 = 2784,6
что совсем немного в масштабах Интернета.

Для осуществления эффективной DDoS-атаки NTP-amplification злоумышленник будет использовать следующие особенности:
1.      Возможность подмены IP-адреса запроса на адрес жертвы.
2.      Поиск и поддержание актуальной базы уязвимых NTP-серверов.
3.      Генерация легитимных запросов к уязвимым серверам для поддержания объемных ответов на команду monlist.
4.      Высокая интенсивность запросов зараженными ПК-«зомби».

Как защитить NTP-сервер?

Unix

ntpd.conf
Естественно, для того, чтобы ваш NTP-сервер не принимал участия в DDoS-атаках, наиболее правильным будет обновить сервер до версии  ntpd 4.2.7p26 и более свежих. Но даже если по какой-либо причине это не удается выполнить оперативно, отключение возможности использования команд REQ_MON_GETLIST и  REQ_MON_GETLIST_1 производится одной строчкой в конфигурационном файле:

disable monitor

с последующим рестартом ntpd. После этого на запросы подобных команд NTP-сервер будет отвечать приблизительно следующее:

:~$ ntpdc -c monlist 192.168.10.128
***Server reports data not found

NTP не является лишним сервисом, поскольку он производит синхронизацию системного времени с внешними серверами, и его удаление может сказаться на качественной работе остальных сервисов. Поэтому, для того, чтобы защитить ntpd, необходимо внести в конфигурационный файл следующие строки:

# Если NTP-сервер обслуживает клиентов — разрешаем запрос времени, но не изменение.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Указываем доверенные IP-адреса
restrict 127.0.0.1
restrict 192.51.100.1
restrict 192.51.100.2
restrict 192.51.100.3

IPv6
Опять же, как и в случае с DNS: если IPv6 не используется на вашем сервере, то лучше его отключить, указав в /etc/sysctl.conf строку:

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

sudo sysctl -p /etc/sysctl.conf

iptables

Как и в случае с DNS, запрос NTP, содержащий запрос  MON_GETLIST или  MON_GETLIST_1, может быть описан правилом iptables. На рис. 2 показан формат пакета, содержащего подобный запрос.



Рис. 2. Пакет, содержащий «вредоносный» NTP-запрос.

Как видно, байт под номером 45 содержит шестнадцатеричную последовательность 0x2a, идентифицируя NTP-запрос как содержащий MON_GETLIST_1.

Составим последовательность команд iptables, которая:
- пропускает NTP-запросы клиентов из подсети 192.0.2.0/24,

iptables -v -A INPUT -s 192.0.2.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT

дает возможность синхронизироваться с вышестоящими серверами 192.51.100.1-3 

iptables -v -A OUTPUT -m iprange --dst-range 192.51.100.1-192.51.100.3 -m state --state NEW -p udp --dport 123 -j ACCEPT

и блокирует все запросы к серверу, содержащие MON_GETLIST_1

iptables -v -A INPUT -p udp --dport 123 -m string --from 44 --to 46 --algo bm --hex-string '|2A|' -j DROP

Cisco

Поскольку уязвимы не только Unix-сервера, но и не менее популярное в сети Интернет оборудование Cisco, рассмотрим, как защитить сетевые устройства от использования в DDoS-атаках NTP amplification.
Перечень зарегистрированных Cisco Systems дефектов, связанных с CVE-2013-5211, в зависимости от типа программного обеспечения, показан в источнике [1]. На примере Cisco IOS рассмотрим предлагаемые производителем варианты диагностики и защиты устройства [2].
Согласно информации от поставщика, версии IOS, начиная с 12.4(15)XZ, 12.4(20)MR, 12.4(20)T, 12.4(20)YA, 12.4(22)GC1, 12.4(22)MD, 12.4(22)YB, 12.4(22)YD, 12.4(22)YE и 15.0(1)M в соответствующих ветках, неуязвимы, поскольку поддерживают NTP v4.
Проверяется поддерживаемая версия NTP командой:

ios_router# show subsys name ntp

Не подверженные уязвимости версии покажут следующее:

Name                               Class       Version
ntp                                Protocol    4.000.000

Тем не менее, даже если ПО неуязвимо, стоит обеспечить его дополнительную защиту, поскольку сам производитель указывает, что 100% защита от возможности эксплуатации подобной уязвимости состоит только в отключении NTP-сервера.
Необходимо дополнить конфигурацию устройства Cisco следующим образом.
Создать блокирующий список доступа:

ios_router(config)# ip access-list standard DENY
ios_router(config-std-nacl)# deny any

Применить его для блокировки запросов к устройству как к NTP-серверу:

ios_router(config)#ntp access-group query-only DENY
ios_router(config)#ntp access-group serve DENY

Если маршрутизатор выполняет роль NTP-сервера для легитимных клиентов, находящихся в подсети 192.0.2.0/24, список доступа будет иметь вид:

ios_router(config)#ip access-list standard PERMIT_NTP_CLIENTS
ios_router(config-std-nacl)#permit 192.0.2.0 0.0.0.255
ios_router(config-std-nacl)#deny any

и будет применяться только для предоставления возможности синхронизации времени:

ios_router(config)#ntp access-group serve-only PERMIT_NTP_CLIENTS

Разрешить общение с вышестоящими NTP-серверами можно, добавив их в доверенный список:

ios_router(config-std-nacl)#permit 198.51.100.1
ios_router(config-std-nacl)#permit 198.51.100.2
ios_router(config-std-nacl)#permit 198.51.100.3
ios_router(config-std-nacl)#deny any

и применив с помощью команды:

ios_router(config)#ntp access-group peer PERMIT_NTP_PEER

Таким образом, маршрутизатор Cisco будет защищен от нелегитимных запросов, но при этом иметь возможность винхронизироваться с вышестоящим сервером и выполнять роль сервера для клиентов в своей сети.

uRPF-check

В соответствии с рекомендациями BCP38 и RFC2827, универсальными для предотвращения возможности быть орудием DDoS-атак, основанных на методике подмены IP-адреса, нетранзитный L3-интерфейс маршрутизатора, к которому подключаются потенциальные NTP-клиенты, должен быть сконфигурирован для проверки входящих пакетов на наличие в таблице маршрутизации:

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

Выводы

Выполнив описанные настройки, мы напрямую не защитимся от атак на нашу сеть и сервера, но сделаем невозможным использование своих ресурсов для атак на других, а также минимизируем количество оснований для кричащих заголовков в прессе «Русские хакеры атаковали...».
Итого, уменьшить количество DDoS-атак типа NTP amplification, минимизировать участие своего инфраструктурного сегмента можно с помощью следующих действий, не требующих дополнительных финансовых вложений:
·      Обновление NTP-сервера до версии не ниже 4.2.7p26.
·      Отключение IPv6, если данный протокол не используется.
·      Безопасная конфигурация NTP-сервиса на серверах и сетевом оборудовании, обеспечивающая отсутствие обработки запросов MON_GETLIST и MON_GETLIST_1.
·      Применение правил iptables, запрещающих входящие NTP-пакеты со значением 0x2a в сорок пятом байте.
·      Применение проверок uRPF на активном сетевом оборудовании.
И если так поступит каждый администратор сервера либо сетевого оборудования с сервисом NTP, доступным из сети Интернет, цифровой мир приблизится еще на один шаг к совершенству.

1.      Cisco Network Time Protocol Distributed Reflective Denial of Service Vulnerability https://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-5211
2.      Cisco IOS Software NTP Control Mode 7 vulnerability CSCtd75033 https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtd75033



Комментариев нет:

Отправить комментарий