По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 2. NTP Amplification" из июньского (2016) выпуска журнала "Системный администратор" .
В прошлой статье рассматривался протокол DNS и варианты его защиты от использования в DDoS-атаках. Продолжим анализ атак типа "усиление" (amplification).
Чтобы сделать свой вклад в защиту всемирного киберпространства от 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