LINUX.ORG.RU

Демон ntpd подвержен уязвимости «усиление трафика»

 , ,


0

3

В январе 2014 года на сайте ntp.org появилось следующее сообщение:

NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice for more information.

Пользователей NTP настоятельно просим незамедлительно убедиться, что их NTP демон не подвержен атаке DRDoS (усиление трафика). См. NTP Security Notice для большей информации.

Несмотря на то, что уязвимость была закрыта еще в 2010 году в версии 4.2.7p26, во многих дистрибутивах до сих пор распространяется версия 4.2.6 или ранее. Пользователям этих версий следует обновиться на версию 4.2.7p26. Если это по каким-то причинам невозможно, следует использовать либо noquery в разрешениях по умолчанию, чтобы отключить все статусные запросы, либо disable monitor для отключения только команды ntpdc -c monlist, либо ограничить доступ к ntpd настройками файрволла.

Атака DRDoS в данном случае использует то, что демон ntpd работает по протоколу UDP, а также то, что пакет ответа на команды REQ_MON_GETLIST и REQ_MON_GETLIST_1 содержит в 3600~5500 раз больше данных, чем пакет запроса. Таким образом, если подделать IP адрес отправителя запроса на IP-адрес жертвы, то ей придет огромный трафик ответов от NTP сервера, забивая входящий канал мусором.

>>> Подробности

★★★

Проверено: Shaman007 ()

возможно глупый вопрос,
но речь идёт о том, что клиенту-«жертве» будет приходить большой трафик, тем самым забивая канал. Причём этот трафик будет по мнению «жертвы» ненужный, который нужно удалить.
Данный трафик для клиента-«жертвы» будет таким же ненужным и подлежащим удалению, как любой другой трафик в таких же количествах. Т.е. другой хост может просто забивать мусором (любого другого происхождения) канал «жертвы», и для жертвы не будет никакой разницы, так как результат будет одинаков.
Так вот вопрос, какая практическая ситуация тут может быть, что клиент-«жертва» будет так атакована наиболее удачно именно ntp-сервером?
Если в моих мыслях ошибки, прошу пояснить. Очень интересен этот вопрос.

Zhopin ()
Ответ на: комментарий от Zhopin

Создать большой трафик при помощи ntpd можно даже сидя через GPRS за счет усиления в 3-5 тысячи раз. И для этого нужно только найти достаточное количество жертв. Для 1 гигабит/с входящего канала жертвы хватит по 30 килобит/с трафика к 10 серверам ntp с открытой дырой по 100 мегабит исходящего канала на каждом.

Kiborg ★★★ ()
Ответ на: комментарий от true_admin

Ты же начал с наезда на меня что я «теоретизирую и ничего не понимаю».

Потому что так и есть. И я не наезжаю.

Там дорогая память потому что решение о том что делать с пакетом нужно принять до того как придёт новый пакет.

WUU? Коммутаторы-телепаты? А если в пакете MAC адрес назначения, которого нет в таблице маршутизатора/коммутатора, что тогда?

Для гигабитного эзернета это 96ns. И таких портов у свитча может быть и 24 и 48. И, на сколько я знаю, каждый порт содержит свою память (forward information base). Для 10G этот интервал 9.6ns. Поэтому поставить «много памяти» на каждый порт затруднительно.

Да, а для 40G это 2.4ns. Только числа должны быть еще лучше, т.к. скорость порта != скорости памяти. Выборка из памяти занимает n-наносекунд при этом чтобы гарантировать скорость порта, выборка из памяти должна быть как минимум в два раза меньше. Итого 1g/10g/40g: 48ns/4.8ns/1.2ns. Тоже самое в МГц: 20МГц/200МГц/800МГц.

Все бы ничего, если бы выборка из памяти действительно занимала столько времени. На самом деле, скорость памяти играет второстепенную роль, если процессор не может до нее достучатся вовремя. Современные реалии: http://www.extremetech.com/computing/100583-analyzing-bulldozers-scaling-sing...

Итого, получается, что все коммутаторы привязаны к процессорной памяти (L1/L2 cache). Больше инфы можно поискать самому в интернете. И почему не растет L1 тоже можно найти в инете.

Учитывая это, как бы там ни было, если избавиться от ограничения максимального кол-ва MAC-адресов для хранения в памяти, то решения типа port security, ip-mac-port binding, etc будут не нужны вовсе. Лично я считаю, что в современных реалиях должен имется способ, который решит эту задачу.

2) Почему ты решил что кто-то будет флудить новыми мак-адресами со скоростью всего лишь 1000 пакетов в секунду? Там и миллион можно на гигабите-то.

Это был пример.

3) Port security решает эту проблему значительно более элегантно.

Еще раз это костыль. Это не проблема TCP IP в частности. Проблема в реализации.

И скажи своему дружку, чтобы не сыпал терминами почем зря. Какого влез в диалог со своим DHCP Snooping, когда DHCP может не быть вообще, а mac flood есть и остался. Какого он не понял, что port security это та из одних костыльных техник, которые я и имел в виду. Еще раз: Port Security, IP-MAC-Port Binding, Static MAC address tables это все фактически одно и тоже.

Что касается DAI - софтверная реализация, о которой я говорил выше: Демон ntpd подвержен уязвимости «усиление трафика» (комментарий) Почитай линки!

Пусть читанет хоть раз, что пишут гуру:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_...

И пусть, ответит на свой тупой вопрос ко мне про ARP spoofing после этого!

У вас в черепной коробке каша. При чём здесь вообще ARP-spoofing?

Демон ntpd подвержен уязвимости «усиление трафика» (комментарий)

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

У тебя в голове каша. Обучать уму-разуму каждого дурня в интернетах слишком накладно. Так что придётся тебе с этой кашей как-то самому разбираться.

Из чего это следует? Это следует из того, что ты смешал в кучу всё, что под руку попалось. При этом видимо не понимаешь разницы между ARP spoofing и MAC flooding. Отсюда проистекает непонимание «какого влез в диалог со своим DHCP Snooping».

гуру

Были пострадавшие от смеха.

frob ★★★★★ ()
Ответ на: комментарий от frob

Тролль, зная ответы не станет их озвучивать. Вместо этого он готов написать 10 бесмыленных предложений, чтобы поднять свое ЧСВ. Он будет говорить, что ему лень, накладно и т.п. объяснять, даже если смысловые ответы укладываются в одно короткое предложение и их можно озвучить без вдумчивости и растоновки.

Продолжайте в том же духе. ЛОР вас ценит.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от Kiborg

не совсем понятно речь идёт ведь о upd пакетах, а они строго ограничены в размере. Если размер пакета превысит mtu, то будет фрагментирован, т.е. из большого трафика дойдут только первые пакеты, остальные останутся ещё на первом маршрутизаторе. Не совсем ясна ситуация, когда до клиента-«жертвы» дойдёт огромная цепочка udp пакетов и забьёт весь канал. Не понимаю практическое воплощение такой ситуации

Zhopin ()
Ответ на: комментарий от Zhopin

то будет фрагментирован

Верно, и произойдёт это на стороне (ntp-) сервера.

останутся ещё на первом маршрутизаторе.

Нет, для маршрутизатора это будут обычные IP-пакеты размера не превышающего mtu.

true_admin ★★★★★ ()

во многих дистрибутивах до сих пор распространяется версия 4.2.6 или ранее. Пользователям этих версий следует обновиться на версию 4.2.7p26.

а почему на http://www.ntp.org/downloads.html рекомендуют в продакшен 4.2.6p5?

Я чего-то не понимаю, или ты умнее разработчиков ntpd?

emulek ()
Ответ на: комментарий от selivan

Зачем держать целый сервер, закрывая фаерволами, если достаточно клиента?

ну у меня в десктопе такой висит. Он слушает пул в Сети и раздаёт время в локалку.

emulek ()
Ответ на: комментарий от true_admin

дык вы действительно предлагаете переводить продакшен на нестабильную версию для разработчиков? Это по вашему «безопасно», да?

И всё из-за какой-то ерунды, которая мало кому вообще нужна(т.к. многие вообще не юзают серверную конфигурацию, а остальные раздают время себе же в локалку, и DRDoS может быть инициирован только со своего же другого локалхоста)

emulek ()
Ответ на: комментарий от Kiborg

Прочитай, для начала, сообщение (до конца)

я читал

а потом пройдись по ссылкам. Там все написано.

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

emulek ()
Ответ на: комментарий от emulek

«Мои» ссылки, между прочим, ведут на тот же сайт. Только вот дата обновления страницы там не от 2011 года, а от 2014.

Kiborg ★★★ ()
Ответ на: комментарий от gh0stwizard

Ну что ж... «И не хочется, но нельзя упускать такой случай».

Твоя «гениальная» идея, согласно первому сообщению, состоит в том что:
- если в свичи поставить достаточно памяти для хранения всех MAC-адресов, то будет ликвидирована проблема [...] (тут ты начинаешь путаться в показаниях);
- вендоры — козлы, потому что «жмотят память».

Будем считать, что информация о том каков размер MAC-адреса не является секретной. На случай, если для тебя это секрет сообщаю: 48 бит.

Если не считать тебя умнее чем ты тут демонстрируешь, то для хранения потребуется 48*2^48 бит. Поскольку ты также показал неспособность посчитать сколько это, я тебе посчитаю...

48*2^48 бит = 6*2^48 байт = 6*2^48/2^50 пебибайт = 1.5 пебибайта

Ну и на закуску. «Вендоры-козлы», поэтому на роль «гуру» ты выбрал представителей компании имеющей примерно 60% рынка свичей.

Не делай так больше.

frob ★★★★★ ()
Ответ на: комментарий от frob

Лучше не спорь с ним, будет как с мегабаксом или drbarty (emulek).

PS свою ошибку про память портов я осознал. Намешалось то что у меня знакомый пытался сделать высокоскоростной оптический свитч без промежуточной буферизации. Поэтому надо было принимать решение о судьбе пакета сразу как только он прилетел. Иногда знания вредны :).

true_admin ★★★★★ ()
Ответ на: комментарий от frob

А теперь представь на минуту, что всетаки все MAC-адреса могут удержать роутер. Нужен ли будет Port security? Вообще, какие проблемы останутся?

Это тебе домашнее задание. Можешь не отвечать: читать снова 10 постов о том, какой ты крутой я не намерен.

gh0stwizard ★★★★★ ()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от true_admin

Спорить? Нет предмета спора и, судя по его последнему ответу, оппонента. Пусть продолжает притворяться, что живёт в мире иллюзий.

frob ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.