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

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

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

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

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

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

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 подвержен уязвимости «усиление трафика» (комментарий)

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

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

гуру

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Page last updated: May 02, 2011.

Page last updated: May 02, 2011.

и на ней:

Development 4.2.7p421 2014/02/10

у них машина времени была, да?

Я нашёл объяснение: Stable releases have an even Minor Release number Development releases have an odd Minor Release number

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

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

Кто «вы»? Я ничего не предлагаю и вообще использую openntpd.

ТС предлагает.

False. Прочитай, для начала, сообщение (до конца), а потом пройдись по ссылкам. Там все написано.

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

я читал

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

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

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

Только вот дата обновления страницы там не от 2011 года, а от 2014.

достал. Удивляйся: http://support.ntp.org/bin/view/Main/SoftwareDownloads

а про эту беду давно известно было.

Надо же, заметил.

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

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

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

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

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

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

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

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

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

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

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

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