DDoS защита сервера от атак типа NTP Amplification

В нашем материале о ДДоС защите сервера против атак DNS Amplifications мы затронули тему отраженных атак. Но UDP протокол не является единственным протоколом для реализации Amplification атак. Сегодня мы познакомим вас с NTP Amplification.

DDoS защита сервера

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

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

На самом сервере можно выполнить команду:

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

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

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

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

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

Попробуем посчитать коэффициент усиления данной атаки при заданном выше количестве пакетов. Он равен отношению объема ответа к объему запроса.

Учитывая то, что tcpdump в значении length показывает только количество байт полезной нагрузки, добавляем к каждому пакету (и запросу, и ответу) по 42 байта заголовков:

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

Получим, что в ответ на один запрос объемом 192 + 42 = 234 байта уязвимый сервер отдал 15 ответных пакетов по 440+42 = 482 байта, итого 482х15 = 7230 байт. Коэффициент усиления в данном случае равен 7230/234 = 30,9.

Рассмотрим ответный пакет (см. рис. 1).

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

может вернуть до 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 необходимо такое количество ответов в секунду:1073741824/3856=278460.

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

Для осуществления эффективной DDoS-атаки NTP-amplification злоумышленник будет использовать следующие особенности:

>  Возможность подмены IP-адреса запроса на адрес жертвы.
>  Поиск и поддержание актуальной базы уязвимых NTPсерверов.
>  Генерация легитимных запросов к уязвимым серверам для поддержания объемных ответов на команду monlist.
>  Высокая интенсивность запросов зараженными ПК-«зомби».

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

ntpd.conf (Unix)

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

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

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

IPv6 (Unix)

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

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

Iptables (Unix)

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

 

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

Составим последовательность команд iptables, которая:

> пропускает NTP-запросы клиентов из подсети 192.0.2.0/24

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

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

DDoS Защита Cisco

Поскольку уязвимы не только Unix-серверы, но и не менее популярное в сети Интернет оборудование Cisco, рассмотрим, как защитить сетевые устройства от использования в DDoS-атаках NTP Аmplification.

Перечень зарегистрированных Cisco Systems дефектов, связанных с CVE-2013-5211, в зависимости от типа ПО, показан в источнике . На примере Cisco iOS рассмотрим предлагаемые производителем варианты диагностики и защиты устройства. Согласно информации от поставщика, версии 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 командой:

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

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

Необходимо дополнить конфигурацию устройства Cisco следующим образом. Создать блокирующий список доступа:

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

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

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

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

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

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

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

Выводы

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

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

> Обновление NTP-сервера до версии не ниже 4.2.7p26.
> Отключение IPv6, если данный протокол не используется.
> Безопасная конфигурация NTP-сервиса на серверах и сетевом оборудовании, обеспечивающая отсутствие обработки запросов MON_GETLIST и MON_GETLIST_1.
> Применение правил iptables, запрещающих входящие NTP-пакеты со значением 0x2a в 45-м байте.
> Применение проверок uRPF на активном сетевом оборудовании.

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

Рейтинг материала
[Голосов: 1 Рейтинг: 5]
27 января 2017, 01:17

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

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