Комментарии 381
Спасибо за то, что вовремя привлекли внимание к проблеме. Причина — в ошибке на стороне прошивки умных колонок. Опубликовали статью, в которой рассказали об инциденте и о принимаемых мерах.
Поправьте если не прав. ощущение что нагрузка выросла резко, что не может быть естественно.
Боюсь тут попытки использовать NTP сервера для Ddos-атак.(собственно потому настройка NetSpeed и не работает)
Настройка NetSpeed - это не абсолютная скорость. Относительная. То есть если у одного сервера выбрано 512 кбит/с, а у другого - 5 мбит/с, то в среднем первый получит в 10 раз меньше запросов. Но 10% от "очень много" всё равно "очень много".
Я анализировал трафик, когда мои сервера попадают в пул обратно - 1 000 000 пакетов набегает меньше чем за минуту, при этом статистика не показывает большого криминала (ну то есть из 1 000 000 пакетов в топе пара адресов с 3-5 тыс запросов).
Меньше чем за минуту ещё не все абюзеры успевают прийти, а потом ещё их запросам надо протолкаться в перегруженном канале. В общем, в текущей ситуации выявление аномалий весьма сложная задача.
А Вы проверяли ваш сервис на эту уязвимость. В свое время тоже крови попортили :(.
Я перевел свои сервера на OpenNTPD. У него на тот момент этого бага не было, ну или monit отключить, вроде тоже помогало.
Я попробовал поставить не 512, а 1 КБ/с, подхачив в браузере запрос. Пока в виртуалку прилетает максимум мегабит 5 Мбит трафика (при 512 прилетало 150 Мбит), продолжаю наблюдение.
Не похоже это на DDoS — просто потому что:
интенсивный трафик наваливается только когда пул включает твой сервер в выдачу клиентам;
трафик спадает ниже 1 Мбит/с после того как пул исключает тебя из выдачи.
То есть трафик практически полностью создают клиенты-новички, которые впервые приходят с запросом (в том числе, возможно, настроенные на ускоренную первичную синхронизацию — с увеличенным количеством запросов). Те же, кто остаётся пользоваться сервером для последующих запросов, нагрузки практически не создают.
Если бы это была DDoS-атака типа refrection + amplification и т. д., направленная на сторонние серверы-жертвы (не разу не NTP даже), то трафик не иссякал бы после исключения сервера из выдачи пула, а продолжался бы практически с той же интенсивностью.
Для хронологии, меня это затронуло 26 октября.
Выглядело это так: аномально высокая частота запросов с 3-5 IP, достаточная, чтобы исчерпать лимит соединений механизма conntrack типично настроенного фаервола на Linux и т.п. statefull фаерволах, сагрить фаервол провайдера и т.д.
После чего система мониторинга пула исключает такой сервер из работы и перенаправляет весь его трафик на новых жертв. Ситуация повторяется.
Стратум 2 на роутере - это сильно...
Хотелось бы более глубокого анализа, конечно - куда делись серверы (сходу предполагаю когтистую лапу РКН), почему пул не уважает собственные настройки скорости.
Вы не пробовали, кстати, ограничивать доступ по региону IP-адресов?
Куда делись - это прям вопрос. Может быть, здесь кто-то из сервердержащих увидит и ответит.
Доступ по региону ограничивать не имеет смысла, потому что в топе запросов российские адреса, а мониторинг в основном забугорный и, если он не сможет достучаться до сервера и проверить его ответы в течение какого-то довольно длительного (типа полдня) времени - он не добавит его в пул.
Красная линия, как пишут, количество зарегистрированных серверов. Т.е. одновременно с выпадением хостов в неактивные операторы серверов поудаляли инстансы оттуда, возможно как раз с ростом нагрузки.
Нет, это сам пул удаляет неактивные серверы после некоторого времени.
Признаюсь честно: я прозевал уведомления об готовящемся удалении 2 из 3 моих серверов, привычно проигнорировав очередное письмо от мониторинга пула, посчитав их за рядовые уведомления о временных проблемах доступности — которые мониторинг выявляет раз в месяц минимум, учитывая отсутствие мониторящих хостов в России и частые проблемы с транс-граничной блокировкой NTP (это как когда кто-то на протяжении 20 лет постоянно кричит «Волки! Волки!» по поводу и без повода).
сходу предполагаю когтистую лапу РКН
РКН тут скорее всего не при делах потому что у меня успешно получается на нескольких моих виртуалах в Германии и Швеции запросить время по NTP от нескольких других виртуалок в России (СПб и Москва). То есть трафик на границе не зафильтрован.
Согласен. Немного почитав форум пула я пришёл к мнению, что причина в другом.
Началось всё, судя по всему, с ддоса. Сильно увеличился трафик, слабенькие NTP-серверы начали из-за этого вываливаться из пула, не отвечая на мониторинговые пробы - ну или владельцы сами их отключили. Это, в свою очередь, усугубило ситуацию, ещё увеличив трафик на оставшиеся. В результате остался (надеюсь) неибиваемый Cloudflare и ещё пара других.
Стратум 2 на роутере - это нормально. NTP-пул это не какой-то централизованный CDN-проект. Пул это полностью "волонтёрская" история. Любой со статическим ip может запустить у себя демона, зарегистрироваться в пуле и обрабатывать запросы. В пуле процентов 80-90 это именно энтузиасты. Поэтому железо и каналы связи там очень разные. Начиная от домашних роутеров и малинок с GPS на ADSL 20Мбит/с и заканчивая корп.серверами (в духе "мы у себя подняли сервер, не жалко выставить в пул, нагрузка небольшая") и даже специализированными аппаратными серверами включая цезиевые/рубидиевые источники.
Раньше в пуле присутствовали сервера интернет-проектов/хостингов/датацентров, например кластер от msk-ix. Сейчас все они из пула выключились (хотя некоторые ещё не удалились).
На приведённом графике красная линия это количество зарегистрированных в пуле серверов из ру-сегмента. Красная линия это удалённые из пула сервера. Либо вручную, либо автоматически пулом из за длительной недоступности. То есть сервера сейчас окончательно покидают пул и этот процесс развивается.
Желтая линия - число активных серверов. Во-первых это сервера, которым "поплохело". Пул мониторит все "включенные" сервера, если сервер ведёт себя нестабильно (теряет запросы или отклонение времени у него сильно "скачет"), у сервера падает рейтинг (score) и сервер временно исключается из пула. Как только score достигнет "хорошей" величины (достаточно примерно 30-60 минут стабильного поведения) сервер автоматически возвращается в активные и пул направляет на него запросы. Во-вторых это деактивированные администраторами сервера. Сервер может быть в пуле, но администратор выставил статус "не посылать мне запросы". При этом пул продолжает его мониторить, но активным он не считается.
Видно что в конце октября число активных серверов обвалилось очень резко. Возможно, действительно пул убивают Яндекс-девайсы, которые примерно с конца октября начали слать запросы каждые 5 сек (в нормальном режиме Ntp-клиент стабилизируется на интервале maxpoll=2^10сек = ~17 минут). И появление сообщений об этой чрезмерной ntp-активности Яндекс-девайсов и обрушение на графике произошли в конце октября.
Ещё для понимания о серверах и нагрузке: лет 15 назад я запускал сервер на машине уровня Pentium3 (1 ядро ~1ГГц, достался даром в 1U исполнении) и он легко справлялся. Сейчас людям не хватает сервера с шестиядерным Xeon 3.6ГГц т.к. периодически из пула приходит до 1.8млн запросов в секунду и до гигабита трафика. В таких условиях корпоративные "производительные" сервера вынуждены выключаться из пула (ведь сервер в первую очередь для организации, а потом уже для пула), а мелкие домашние сервера на малинках-роутерах как у автора поста, гораздо раньше ложатся под шквалом запросов или их канал забивается трафиком под завязку.
Беглый анализ трафика на моём сервере показывает что в нём нет явно выраженного флуда с нескольких source ip. Есть некоторые /24 откуда ntp-запросы бегут достаточно активно (десятки в секунду), но это запросто может быть NAT за которым сидят флудящие Яндекс-станции или множество других ntp-клиентов (они ведь сейчас "в каждом холодильнике"). За минуту приходят запросы с нескольких млн разных source ip (преимущественно из РФ), некоторые присылают запросы по 3-7-9 раз. Это тоже в пределах нормы, при старте ntp-клиент может делать burst и прислать несколько запросов подряд, а где-то это ip nat-пула. Возможно в трафике есть спуфленные source ip, но отличить их от легитимных на первый взгляд не удалось.
Какие предположения о причинах пропадания серверов озвучиваются:
1) ntp reflection атаки увеличили нагрузку и "завалили" часть серверов. Нагрузка перераспределилась на оставшиеся, им тоже поплохело и они временно "вылетели" из пула и так по нарастающей. На форуме пула это верно назвали "коллапсом ru-сегмента пула".
2) рост нагрузки от Яндекс-девайсов.
3) юридическое: некоторым операторам приходили запросы от правоохранительных органов "чей это ip участвует в атаке?". Я думаю уже один такой запрос может заставить убрать свой сервер из пула. Никому не нужны маски-шоу и объяснения с дядями в погонах почему с их подключения идут атаки.
4) корпоративные сервера также могут уйти из за изменения политики компании, введения защит/ограничений по GeoIP (мониторинг пула перестал видеть такие сервера и через какое-то время их удалил), увеличения нагрузки, возможно в некоторые организации кому-то поступили настоятельные рекомендации или даже чёткие инструкции.
5) фильтрация ntp-трафика операторами. Я бегло анализировал трафик, примерно на 25% ответов моего сервера я получаю icmp port unreachable, часть от транзитных хостов. Выглядит что где-то настроен фаервол, пропускающий ко мне запросы, но отшибающий мои ответы. Или просто ко мне пришли запросы со спуфленными source ip.
6) фильтрация ntp-трафика на ТСПУ. Сомнительно, но окэй.
У Яндекса разве нет своего пула? ЕМНИП, правила ntp.org не поощряют такое использование пула. Хотя в ЯО вообще советуют Stratum 1 для синхронизации.
не скажу про Яндекс, не исследовал и их девайсов у меня нет. По-моему 99% линукс-девайсов, включая холодильники и тостеры, сейчас использует общий адрес pool.ntp.org (который пул старается отресолвить в ближайшие к клиенту региональные сервера, так что рекомендации у них немногого странные). Не удивлюсь если у Яндекса тоже прописано просто pool.ntp.org.
Свои субдомены есть у многих компаний и всех популярных дистрибутивов.
Изучали сегодня с товарищем относительно свежую Yandex-станцию с относительно свежей прошивкой. Лезет нагло к pool.ntp.org. Работет в burst режиме. Эксперимента ради порезали ей исходящий ntp-трафик - ответила всплеском ntp-трафика, который потом сошёл на нет (видимо, перебирала всё, что могла найти в пуле). Экспериментов с частичной потерей пакетов не делали, но, возможно, частичная потеря пакетов будет её всегда держать в таком режиме
Яндексможно вас попросить это как-нибудь прокомментировать?
тоже интересно. Например, такая пачка вылетает раз в 5 сек (все ответы от серверов приходят, но яндекс-девайс всё равно спрашивает). Тут даже видно что уже в одну миллисекунду некоторые сервера запрашиваются дважды. Допустим iburst, но зачем каждые 5 сек и у такого кол-ва серверов? Попутно ещё раз в 20-30 секунд ресолвится какой-то из [0-3].ru.pool.ntp.org.
16:34:41.041688 > 89.248.203.107.123: NTPv4, Client
16:34:41.042071 > 85.21.78.91.123: NTPv4, Client
16:34:41.042315 > 194.26.229.100.123: NTPv4, Client
16:34:41.042741 > 95.163.215.213.123: NTPv4, Client
16:34:41.042775 > 162.159.200.123.123: NTPv4, Client
16:34:41.042800 > 94.103.83.26.123: NTPv4, Client
16:34:41.042828 > 51.250.9.134.123: NTPv4, Client
16:34:41.042861 > 51.250.11.43.123: NTPv4, Client
16:34:41.043314 > 90.156.156.202.123: NTPv4, Client
16:34:41.043347 > 90.156.156.202.123: NTPv4, Client
16:34:41.043408 > 162.159.200.1.123: NTPv4, Client
16:34:41.047801 > 95.163.215.213.123: NTPv4, Client
16:34:41.048559 > 192.36.143.130.123: NTPv4, Client
16:34:41.048589 > 185.187.90.73.123: NTPv4, Client
16:34:41.048630 > 91.107.124.159.123: NTPv4, Client
16:34:41.048669 > 77.37.134.150.123: NTPv4, Client
Ой, подозреваю что Яндекс ответит, что для избежания таких ошибок в будущем они в процесс найма добавят ещё два алгоритмических, одно архитектурное интервью и одно культурное интервью.
А если серьезно и без троллинга — другие штатные линуксовые сервисы ntp ведут себя так же, или это фирменное поведение только Яндекс—станции?
Моих две станции с Алисой ужасно спамят (по 8,3k в сутки) запросов идут на сервера. Я обращался с Яндекс, сказали что это нормально :(
Яндекс5 запросов в минуту - для чего вам настолько точное время?
Здравствуйте! Алиса работает через сеть интернет, поэтому постоянно находится на связи с сервером: например, проверяет, нет ли сейчас установленных будильников.
Также Станция постоянно синхронизирует время с NTP: если оно будет отличаться от серверного — возможны сбои в работе колонки.
NTP-серверам хватает точности, разъехавшейся за 15 минут, а Алисе нет? Выглядит как (очень) неудачная реализация, честно говоря. Ладно бы оно ходило на какие-то яндексовские серверы...
Но это же не повод нарушать правила пула, который вы используете:
Don't send excessively frequent queries. Reasonable query intervals are typically from once or twice a day to a 4-5 times an hour depending on the application. Really consider how often the device will need "fresh time". A standard ntpd or openntpd server works, too.
А не подскажите, что конкретно сломается и какая точность времени требуется, чтобы не сломалось?
Есть подозрения что может сломаться стереопара/мультирум 🌚
Если на яндекс-станциях так быстро и так сильно время уезжает, то это говорит как минимум о серьёзных проблемах железа. И ntp тут не поможет вовсе. И тем более не в том виде, в котором люди показывали
Мультирум обычно синхронизируется не по ntp из интернета, а самими устройствами между друг другом. Для этого может использоваться ntp, но лучше подходят специализированные протоколы (ptp). По крайней мере, в нормальной технике так.
Для этого достаточно синхронизации между собой, нет необходимости долбить внешние сервера.
Самые хреновые кварцевые резонаторы, которые индустрия считает за кварц, а не за брак, плавают по частоте на 200 ppm в диапазоне температур -40+85 °C. Сомневаюсь, что станция испытывает столь резкие перепады температур, чтобы так часто синхронизоваться.
Кроме того, чем больше интервал между измерениями, тем точнее можно рассчитать ошибку частоты.
Я вроде не в Яндексе, но испанский стыд испытал.
Нормальные ntp-клиенты после запуска опрашивают сервер времени часто, высчитывает "уплывание" собственных часов и начинает корректировать свои часы, изредка (обычные настройки по умолчанию - раз в 17 минут) сверяясь с эталоном - внешними серверами. Это нормальный принцип работы ntp, он позволяет поддерживать расхождение времени с эталоном на уровне миллисекунд!!!!
Никакая синхронизация раз в 5 секунд не нужна, это явно косяк или отсутствие мозга у разработчиков. Пожалуйста, подключите к обсуждению вопроса реальных разрабов.
Да, ещё она зачем-то регулярно шлёт запрос SOA для pool.ntp.org
Стратум 2 на домашнем интернете это сильно.
Лечить надо не призывом поднимать NTP на виртуалках, лечить надо походом к инженерам крупных провайдеров, чтобы они подсветили проблему руководству и выделили парочку мощных машин на хороших каналах (десяточки вполне хватит) для распределения нагрузки.
Бывшие коллеги из крупного провайдера посмеются. Во первых там с железом очень не очень, на сетевые дела бюджеты еще как-то выделялись. Но никто свои циск/жуниперы на мощных каналах в энторнет выставлять не будет. Это риски, и зачем?
Ну вон timeweb же выставил.
Ещё Selectelпроявил заинтересованность, но пока не подтвердили запуск нод.
Ну то ж не провайдер, провайдер в моем понимании это домашний интернет, а то хостинг
Да хоть стратум 1 — ставите себе GPS-приёмник с 1PPS и в путь; тем боле что как раз в домашних условиях с этим проще, чем в ЦОД. И в пуле было полно таких любительских серверов. На то пул и нужен, что владелец сервера сам выбирает посильную для себя нагрузку, и если не справляется, то система исключает его из выдачи, пока он не придёт в норму.
А вот если у вас серьёзный сервер, тогда можно его включить и в список https://support.ntp.org/Servers/ для статической конфигурации на нижестоящих серверах, участвующих или не участвующих в пуле. При этом такой сервер также может участвовать в пуле.
Gps много где теперь глушат.
Хуже когда не глушат, а спуфят.
В современном разговорном языке это уже синонимы - что так что эдак у человека навигация в телефоне не работает. Без специальных программ телефон не покажет что случилось . Во втором случае перебросит куда-то и дата будет некорректная.
а только время спуфить могут? если да, то зачем?
если нет, т.к. сервак - стационарный девайс, то спуфинг легко обнаружить - если данные с GPS-приёмника не совпадают с реальными координатами приёмника...
Время с координатами и количеством видимых спутников поддельные.
Именно по количеству спутников, уровню сигнала спутников и некорректному времени легко обнаружить. А по координатам никак, если не знаешь точно, где находишься. Именно время сейчас проблема для энергетики - на электроподстанциях стоят серверы точного времени, которые теперь выдают некорректное время.
Как раз для большинства серверов то точные координаты - не проблема, можно хоть руками вбить - они все стационарные объекты, а вот точное (единое) время - это вещь очень нужная, как ни странно, почти для всего, ведь почти везде периодически бывают всевозможные проблемы и для их диагностики есть как минимум системные логи и логи их основного сервиса, а то и целые регистраторы параметров. И без адекватных отметок времени все эти данные резко становится крайне проблемно если вообще возможно использовать. Как трек с навигатора рисует круги на полях я уже видел, но вот что при этом происходит с отдаваемым GPS-приемником временем я как-то никогда внимания не обращал, везде время со внутренних часов регистратора шло. Если спуфят все параметры одновременно - тогда это еще пол беды, по координатам выловить можно, но если то одно то другое отдельно - тогда печаль, конечно.
В общем, я уже подумываю о покупке китайского приемника сигнала DCF77, небольшой платки с Ethernet-ом на STM32, конвертера из 48В в 3.3В и пластиковой коробочки с гермовводом... по Московской области ловить еще должно...
Можно брать точное время у мобильных операторов. Они откуда-то его в себе в сеть берут.
Как-то, когда у Андроида NITZ был более приорететным источником времени, чем NTP, мобильный оператор выдал мне время с отставанием на 15 минут. Было очень обидно.
Тоже попадал на такое, причем на старом кнопочном телефоне. Пришлось даже отключить "время сети" в настройках. Конечно это лучше чем ничего, но особого доверия к ним нет.
Году в 2014 удалось напороться на телефон без RTC и поэтому была включена синхронизация времени с оператором (до этого на всех телефонах всегда отключал её из-за вот таких косяков). Иногда расхождение с реальностью было на годы
Мобильные операторы берут время от серверов точного времени гос. служб, отвечающих за это время.
Читал, что на каждой базовой станции установлен GPS приёмник, т.к. точное время крайне важно для работы TDMA в GSM
Я слышал что на базовых станциях GSM должен просто стоять рубидиевый генератор и если питание не отключать то за всю его жизнь поправка времени на БС нужна будет ровно один раз, сразу после ее запуска. Но как там сейчас ситуация не знаю, может что и поменялось.
для TDMA оно нафиг не сдалось как раз, а вот для производных от CDMA - обязательно, чтоб БС друг друга не глушили.
Время тоже спуфят иногда, уже сталкивались, к сожалению.
Можно не только по координатам проверять. Если у нас есть доступ к интернету, то время от времени сверять время со спутника со временем с нескольких серверов NTP. Плюс можно реализовать проверку, что время со спутника не изменилось резко на большой промежуток времени.
В данном случае координаты не нужны, а только PPS. Приемник лучше брать как минимум с двумя стандартами - GPG и Glonass. Мы как-то давно перешли со стандартных NTP на приемник, а вот в этом году регулярно получаем запросы свыше, смысл которых прекратить использование GPG в критически важных устройствах.
походом к инженерам крупных провайдеров
А так же к операторам дата-центров, чтобы они свои сервера в эти пулы внесли или поставили новые. Selectelи прочие причастные - может, скооперируетесь?
Особенно с учетом того, что если народ предложением в статье воодушевится - оно же все равно у вас стоять будет, но уже без нормального мониторинга, присмотра, файрволлов итд.
@vdsinaruменя прогнала куда подальше с моим NTP-сервером :)
Если дата-центр внесёт в пул свой сервер, он не получит выручку.
Если народ предложением в статье воодушевится, дата-центр получит выручку от этих заказов.
у селектела есть свои открытые ntp сервера, давно их использую на роутере вместо пула. в локальной сети через dhcp в качестве сервера времени отдается адрес роутера
А они точно открытые ?
vikarti@RIARU2v2:~$ sudo ntpdate -v 0.spb.ntp.selectel.ru
25 Nov 11:04:53 ntpdate[1190]: ntpdate 4.2.8p15@1.3728-o Wed Feb 16 17:13:02 UTC 2022 (1)
25 Nov 11:05:06 ntpdate[1190]: no server suitable for synchronization found
трейсроут идет нормально, маршруты к ним - не через VPN
https://kb.msk-ix.ru/public/ntp-server/
недавно перешёл на использование вот этих
Может постараться понять, что с теми серверами стало? Есть возможность диагностики?
Я простой пользователь (чайник), но это самые логичные вопросы, что приходят на ум дилетанту.
Потому что если это какая-то атака (допустим), то никто не даст гарантии, что и новые ваши сервера не попадут под эту атаку.
У меня тут, к слову, пару месяцев назад мощная ДДоС атака на моего провайдера была - вообще ничего не работало.
Раз у нас государство лезет в интернет со своим контролем, то пусть и NTP серверами занимается, на базе всяких НИИ. И т.п. общественно важными вещами.
я в курсе про эти сервера.
Имел ввиду про распределение нагрузки s2 и s3. Вы призываете сообщество решать проблему, а нужно призывать государство, ибо оно постоянно создает нам проблемы, вот пусть и занимается этими проблемами самостоятельно.
Это прям биполярочка какая-то: государство создаёт проблемы и их решает героически :)
Если вы пользуетесь рекомендациями государства по настройке NTP, то проблем у вас нет. ntp.org - популярный, но обычный частный проект, причём зарубежный. Использовать его - ваш добровольный выбор, это даже не умолчание для большинства систем.
А так вообще было предсказуемо, что глобальные сетевые структуры распадаются.
Подскажете, где ознакомиться с рекомендацией государства по настройке NTP?
На Госуслугах список серверов взять или где?
Если вас не забанили в Яндексе, то можно набрать там что-нибудь воде "росстандарт синхронизация времени ntp".
Специально поискал именно в Яндексе, как и вы и посоветовали. Не помогло.
Выдает ссылки на всякие форумы метрологов и разные вконтактики. Ну и реклама ВНИИФТРИ само собой. Когнечно же есть ссылки на посты на Хабре об NTP как таковом. Но речь-то о гос рекомендациях. Мануалы по ntpd я и сам почитаю.
Вас не затруднит дать ссылочку на рекомендации для физ лиц?
Это не реклама ВНИИФТРИ, а ВНИИФТРИ является организацией, ответственной за эталон времени в России. Вопрос, действительно, имеет метрологический характер. Никакого другого времени, кроме происходящего из ВНИИФТРИ, Российское государство не признаёт.
Если вы возмёте российские дистрибутивы линукса (некоторые), то там автоматически и прописан ВНИИФТРИ в качестве источника.
Физ. лицу бессмысленно давать рекомендации, так как у него могут быть самые разные цели и задачи.
Я в курсе кто такие ВНИИФТРИ. Я также в курсе, как их ntp серверы выпали из ntp пула (начали давно, закончился процесс как раз в даты начала проблем). Никаких заявлений, что их выкинули злобные буржуины не видел.
Впрочем, это неважно. Речь о том, что вы изначально утверждали, будто государство выдало мне (частному лицу, а не организации, тем более критической инфраструктуры) какие-то рекомендации по части настройки ntp.
Сейчас вы признали, что частникам рекомендаций нет. ОК.
То, что вендоры прописывают свои серверы, по крайней мере должны - это известное требование самого ntp пула. Того самого "зарубежного частного проекта". Это он изначально требует от вендоров увеличивать надежность путем прописывания особых ntp серверов вместо использования "частных".
Интересно, влетит ли Яндексу за то, что они рекомендациям государства не следовали?
Речь о том, что вы изначально утверждали, будто государство выдало мне (частному лицу, а не организации, тем более критической инфраструктуры) какие-то рекомендации по части настройки ntp.
Когда это я такое утверждал?
Изначально. Используя обращение "вы" (даже не "ваша организация"). Причем в контексте "использовать его [ntp.org ] - ваш добровольный выбор", что очевидно не относится к организациям КИИ и прочим зарегулированным.
Разве что в фразе "если вы пользуетесь рекомендациями государства по настройке NTP, то проблем у вас нет" вы имели ввиду "салоны по ноготочкам или установке пластиковых окон". Но, IMHO, к ним так же относится "Физ. лицу бессмысленно давать рекомендации, так как у него могут быть самые разные цели и задачи".
Впрочем, ссылку на "рекомендации государства мне" вы так и не предоставили, кем бы вы меня не считали.
А я не обещал рекомендации государства ВАМ. Это вы почему-то считаете, что государство вам должно предоставить какое-то решение. А государство предоставляет решения только тем, кто работает в государственных интересах. Если вы относитесь к таковым, то обязаны руководствоваться ФЗ "Об обеспечении единства измерений" и, таким образом, прослеживать свои измерения времени к эталону, который находится во ВНИИФТРИ. Если нет, то можете пользоваться этим эталоном или другим, с вас никто не спросит до тех пор, пока вы этим измерением не начнёте что-то официально доказывать. Но если вы не пользуетесь государственным эталоном для измерения, то государственные органы не только не обязаны, но и не имеют права способствовать вам в такой деятельности. Вроде же очевидная логическая цепочка.
Если вы пользуетесь рекомендациями государства по настройке NTP, то проблем у вас нет.
А я не обещал рекомендации государства ВАМ.
В общем, @Antra, ВАМ никто ничего не обещал, и проблемы у ВАС будут :) Не понимаю, что вас не устраивает :)
официальные государственные рекомендации давали операторам связи (возможно и другим структурам типа банков). Конечным пользователям никаких рекомендаций не озвучивалось. Сейчас в каждом роутере, телефоне и холодильнике прописан ntp pool, менять его везде вручную это бред.
У меня лично в роутере вроде бы как прописан сервер ZyXEL, в телефоне совершенно точно - сервер Apple, а холодильник я в интернет не пускаю.
Вы имеете полное право настраивать свои устройства так, как считаете нужным, но предъявлять претензии российскому государству за работу иностранной организации - настолько же бессмысленно, как упрекать Apple в ошибках Windows.
~9-11 cентября они несколько дней подряд лежали, так что не нужно надеяться только на них
Это и есть корень всех проблем.
17 октября 2024 года ВНИИФТРИ отключил часть серверов от пула. Нагрузка на оставшиеся сервера в зоне RU возросла. Сначала отключились мелкие энтузиасты (перешли в режим мониторинга), за ними и более серьезные ребята под еще большей нагрузкой. Зона схлопнулась.
ВНИИФТРИ пытался вернуться пару недель назад, но большая часть проб до них не дохадила. Потом они снова удалили часть серверов.
https://www.ntppool.org/a/cx44tf2c8fkiqg7n6xfv
https://www.ntppool.org/scores/89.109.251.22
https://www.ntppool.org/scores/89.109.251.23
https://www.ntppool.org/scores/89.109.251.24
Возможно, они как-то переделывают сеть (нельзя исключать Великий Российский Файрвол).
В общем, суть в следующем. Пока (если) ВНИИФТРИ не вернется в пул, зона RU будет мертва.
она уже жива благодаря прекрасным неравнодушным людям из этой темы :)
Мне кажется, вы путаете причину и следствие. Имхо, ВНИИФТРИтовские серверы в середине октября прилегли от нагрузки (reflection-ддос + взбесившиеся Алисы) - и именно поэтому выпали из пула. Потом примерно то же самое начало происходить и с серверами помельче.
ВНИФТРИ свои NTP сервера выводил из пула с начала года. Те что оставались в пуле не участвовали по причини низкого рейтинга еще до начала увеличения нагрузки. 17 октября может и совпало то что вышел их последний рабочий сервер. Хотя с другой стороны, если сервер поставлен на удаление он сразу перестает выдаваться пулом. Но проблемы начались именно в этот день (это даже на графике видно в начале поста). Сегодня они вообще целиком лежали, как и их сайт. Хотя зона и сама справилась без них благодаря сообществу, и тут я рад что ошибся.
Они и занимаются. Кто шатал NTP о них знает и в конфиге из статьи они упоминаются. Но вот как выясняется иногда лучше не заморачиваться с выбором "ближайшего" пула по стране и брать из разных проектов
Предупреждение подмены IP-адресов
Это должны делать Интернет-провайдеры по отношению к своим клиентам (см. BCP38). Вы со своей стороны никак не можете убедиться, что UDP-запрос пришёл от того, чей IP-адрес указан в заголовке.
Ограничение скорости и контроль доступа
Ну да, конечно, это именно то, что нужно для публичного сервера в составе пула.
Использование услуг защиты от DDoS
Пример конкретного решения с поддержкой NTP, которое можно развернуть у себя на сервере, а не заказать как услугу у некоего стороннего провайдера?
На самом деле, сам NTP-софт мог бы применять какие-то лимиты на частоту ответа по каждому IP-адресу:
вообще,
если приходит только начальный запрос без продолжения диалога,
если приходит запрос продолжения при отсутствии начала диалога.
Но тут надо понимать, что за одним IP-адресом могут скрываться тысячи легитимных клиентов провайдера, сидящих за NAT, и даже если у всех провайдеров будут свои NTP-серверы, не все клиентские устройства вообще позволяют задать адрес сервера, и тем более не все клиенты станут это делать.
А решение "в лоб" не работает? Напр. тупо настроить белый список IP с которых обычно проверяют работу узла пула, а для всех остальных врубить в файрволе DROP входящих пакетов превышающих определённый рейт (один по IP источника, и другой вообще на всё кроме IP из белого списка). На первый взгляд это решит все вопросы (кроме того, который на конечном сервере решить невозможно в принципе - забивания всего входящего канала мусорным трафиком) и позволит сохранить (относительно) работоспособный сервис для большинства нормальных клиентов.
Сильно сомневаюсь, что на каком-нибудь 213.183.109.3, который плюется от 1000 до 3000 запросов в секунду, есть что-то с аналогичной Spamhaus ценностью, чтобы организовывать такую атаку. Скорее всего, там что-то взбесилось, но пристрелить это не удаётся, так-как провайдер игнорирует репорты.
Не так давно встречал такой вопрос https://t.me/ctorecords/3686
Очень похоже что это оно:
Всем привет.
Вопрос касается служебного (вспомогательного) трафика , который генерит Яндекс станция.
Может тут найдутся желающие обсудить эту тему ?
Пару недель назад я заметил, что в нашей системе хранения абонентских NAT трансляций появилась аномалия. Количество UDP трансляций превысило TCP.
Сколько себя помню, всегда было наоборот. Стал выяснять.
У нас несколько независимых узлов, на каждом свое оборудование. В ночь на 24 октября на всех узлах разом количество UDP трансляций резко выросло. Т.е. это не 1 какой-то узел. Это судя по всему массовое явление.
Трансляции у нас логируются и по этому беглого взгляда на журналы достаточно, что бы понять. Дохрена сессий на порт UDP 123. Взял конкретного абонента и выяснил, что это Яндекс станция каждые 5 секунд запрашивает по 6 раз NTP серверы.
Вот вопрос, нахрена ? Нахрена так часто "сверять часы" ?
Может кто знает ответ ?
p.s. Проверил на своей домашней "алисе". Ровно каждые 5 сек. по 4 NTP запроса.
Вполне вероятно. Получается, что каждая Yandex-станция ведёт себя как 1000 типичных, нормально сконфигурированных клиентов.
Вспомнил, читал тут похожее про злодейства алисы: https://habr.com/ru/articles/848368/
Интересно, конечно, они свои сервера запилили или вот прям community пулы заиспользовали (ну а шо, принято решение резать косты)
Я на роутере перехватываю запросы NTP помимо раздачи по DHCP, чтобы они шли на роутер в любом случае, а сам роутер в качестве клиента NTP уже решает какой использовать сервер из списка
/ip firewall nat add action=redirect chain=dstnat comment="NTP mikrotik time server" dst-address-list=!local dst-port=123 in-interface-list=LAN log=yes log-prefix="NTP redirect" protocol=udp
протокол NTP так работает. Первое время он сверяет каждые 64 секунду, потом если сервер стабилен начинает увеличивать интервал и в итоге, если не происходит сбоев, обновляет каждые 1024 секунды. Если мне память не изменяет, то это максимум. А почему так? Просто люди ученые, которые разрабатывали этот стандарт, пришли к такому выводу и так сделали RFC. Вы можете провести свое исследование и предложить на его основе правку RFC.
Любопытно, что такой модный яндекс не использует собственные сервера NTP для своих устройств.
Обычно важно не столько сверхточное время, сколько одинаковое. Если время отличается на несколько секунд, могут не пустить на какой-нибудь ресурс. При этом за день часы компьютера вполне способны уйти на десяток секунд. Так что раз в сутки мало.
Полагаю, что логично не заморачиваться с одной синхронизированной подсеткой, а приводить таки к единому мировому времени, ибо завсегда может понадобиться подключиться к чему-то за пределами синхронизированной сетки.
А вы вообще читали сообщение, на которое отвечаете?
Надо смотреть не только на то, как часто идут запросы и сколько их, а ещё и приходят ли ответы. Если ответы не доходят (как раз из-за проблем с перегрузкой серверов), или что-то с ними не так, то запросы так и будут повторяться. Другое дело, что с нормальным NTP-софтом такие запросы в случае отсутствия ответов не должны повторяться чаще, чем раз в минуту, даже если настроена ускоренная начальная синхронизация (iburst).
Скрытый текст
Только вчера начал смотреть Дюну:Пророчество. Может с ЯндексСтанциями уже пора поступать так же, как с игрушкой мелкого говнюка?
Скрытый текст
Вот вопрос, нахрена ? Нахрена так часто "сверять часы" ?
Яндекс даже фильтры на собственном маркете разломал так что пользоваться в принципе невозможно, что уж говорить про такие вещи как ntp, нынешние разработчики в яндексе вряд ли даже знают что это.
Кстати, по-хорошему, производители программно-аппаратных устройств ни в коем случае не должны прописывать обычные адреса пула — xx.pool.ntp.org — вместо этого они должны запросить у пула собственную зону, например yandex.pool.ntp.org, и прописывать именно её, чтобы в случае проблем можно было легко прибить трафик от разбушевавшиихся клиентов.
The NTP Pool for vendors: https://www.ntppool.org/vendors.html
У нас была ситуация, что Яндекс-станции создавали слишком большое колличество соединений, и у абонентов за провайдерским нат переставал работать интернет, так как станция исчерпывала лимит соединений, установленный разработчиком DPI-решения.
Нахрена так часто "сверять часы"
Не пора ли начать восстание машин? 🤔
Подтверждаю, по данным моего adguard-home яндекс станция мини за прошедший сутки сделала 11 тыс. запросов к ru.pool.ntp.org
По итогу яндекс подтвердил и исправил.
Для их же навигации?
А что это за серверы ntp.msk-ix.ru, ntp4.vniiftri.ru, ntp5.vniiftri.ru? Это Stratum 1, Stratum 2 или Stratum 3?
Какие серверы мне нужно указать, чтобы стать Stratum 2?
Был участником проекта, отключил после резко возросшего количества запросов в конце прошлого месяца.
По анализу трафика это выглядит как ddos. Множественные запросы с одного адреса, с кучи разных адресов. Что-то примерно по 200 запросов в секунду с адреса. Нормальные клиенты себя так не ведут.
Может, есть какая-то настройка "не отвечать одному и тому же адресу чаще, чем раз в N секунд / минут / часов"? Или входной канал все равно будет забит и это не поможет?
Настройка-то есть. Я поднял на домашнем сервере контейнер с Chrony и установил там Ratelimit. Давится роутер обработкой пакетов, я никогда не видел, чтобы у RB4011 было 100% CPU.
Проблема в том что если реально дело в DDoS - адрес будет подменным.
Это не поможет. Вы в таком сценарии будете отбрасывать пакеты которые к вам уже пришли, т.е. канал они заняли. Да, таким образом можно снизить нагрузку на железо сервера, если шейпер потребляет меньше ресурсов чем сетевая служба, но нельзя снять нагрузку с входящего канала.
#hate@skilledsaf
Не разделяю мнение автора по этим вопросам
Сервера S1 в большинстве своем с огромным запасом, особенно на пирингах и соответствующей защитой
Большинство популярных OS: Windows/Mac OSX/Android по-умолчанию используют свои NTP сервера S1. Если завтра отключат полностью нтп пул - ничего не случится.
Если вы владелец сервера, то вам найти S1 от ближайшего пиринга или ДЦ где все стоит - вопрос 1 минуты.
поэтому считаю что ничего не надо делать и не страдать фигней. Для установки NTP надо куда больше чем просто купить vps по цене двух чашек кофе. Придется заморачиваться защитой.
Самый простой способ узнать, отключить автору статьи свой сервер. Чтобы лягли оставшиеся 4)
Чтобы лягли оставшиеся 4)
В ru.pool.ntp.org на самом деле не только российские сервера.
nslookup ru.pool.ntp.org
выдает:
192.36.143.130 - это time100.stupi.se.
162.159.200.123 - time.cloudflare.com.
193.192.36.3 - nsa.lds.net.ua.
176.215.178.239 - и только это российский ojab.ru.
Это воспроизводится сейчас из самых разных локаций. Стабильно выскакивают cloudflare и stupi.
По-моему всё чуть сложнее.
Если указать pool.ntp.org - пул сам понимает, откуда ты, и подсовывает тебе сервер, который ближе к тебе. Чем ближе сетевое расстояние - тем меньше погрешность, в большинстве применений это в целом пофиг.
Чисто теоретически, IMHO, если вдруг исчезнут все RU-сервера, то ru.pool.ntp.org будет отдавать какой-нибудь Cloudflare и сильно страшного ничего не произойдёт. Но никто не мешает тому же Cloudflare добавить RU адреса в бан, и вот тогда уже будет опаньки.
Если запрашивать из России, то pool.ntp.org отдает ровно то же самое, что и ru.pool.ntp.org. Поэтому, возможно, что разницы нет.
В данный момент, помимо нескольких российских серверов (я их действительно насчитал 4, делая много запросов), в российский пул, как заметил @pae174, подключены также один шведский сервер и целых два cloudflare, причем с большим приоритетом (выдаются гораздо чаще, чем российские). CloudFlare выдержит любой трафик и любые DDoS. Кажется, опасаться нечего.
Почему? Он уже сейчас отдает почти все время сервера CloudFlare, и будет их отдавать, даже если все российские отключатся.
Ну так это от оператора сервера зависит кто его в пул внес, и спрятал за CF. Сомневаюсь что это сам CF, а точного способа узнать нет
Это сам cf, у них есть ntp, откройте гугл.
Точно: Cloudflare's time servers are included in pool.ntp.org ↗ which is the default time service for many Linux distributions and network appliances.
Даже если это так. Что будет когда на cf надавят, что бы она остановила свои сервера?
Я вам даже больше скажу, настоящее веселье начнется, когда на них надавят, чтобы они остановили 1.1.1.1 / 1.0.0.1.
У других НИХ уже все готово, провайдеров же обязали использовать НСДИ [ https://habr.com/ru/articles/667162/ ]
Потенциальная проблема:
вариант 1 - РКН в своей борьбе за все хорошее против всего плохого (или наоборот) - забанит Cloudflare целиком
вариант 2 - РКН решит что NTP это критическая инфраструктура и начнет от всех кто в ru.pool.ntp.org отдается - требовать выполнения своих правил к этой инфраструктуре
Почему вы обобщаете? Откуда инфа что на многих?
Ну раз CF есть пусть они и отбивают эту атаку если это атака. Что-что, а CF еще в РФ и вряд ли они сложат ntp для РФ. Вот собственно и нет проблем
CF отдается на ru запрос, только что проверил
Если на многих устройствах будет ru.pool.ntp.org и на эти устройства пошлют неверное время, то это приведет к возможности взломать эти устройства по Zero-day уязвимостям, а дальше это может позволить прорваться в какую-то внутреннюю инфраструктуру.
Во-первых, это приведет максимум к массовой неработоспособности TLS (что, конечно, уже само по себе приравнивается к пожару одновременно с наводнением), все остальное — домыслы.
Во-вторых, кто именно подменит время, и каким образом?
Фантазия здесь лишняя, давайте опираться на реальность. Уже сейчас любой мог бы добавить в пул сервер, который выдавал бы неверное время. А если бы он их добавил достаточно много, то мог бы "перетянуть на себя" большую часть запросов и как минимум нарушить функционирование многих устройств в интернете. Раз этого не происходит — очевидно, что пул не дает работать таким серверам.
Определенные железки, у которых найдены zero-day, эксплуатируемые через интернет, но только при определенном значении системных часов, причем эти zero-day в статистически значимом количестве куплены некими хакерами за немалые деньги, в надежде, что хоть одна из железок защищает какую-то супер важную инфраструктуру, и при этом берет время с ru.pool.ntp.org. Выглядит очень правдоподобно!
пул почти мгновенно выплёвывает серверы с неверным временем.
Давайте посмотрим. Последим за новостными рассылками по ИБ тематике.
Начнется все с того, что у народа начнет отваливаться загрузка сайтов из-за неверно рабочего времени, ну, а дальше, что уже там на ломают или не на ломают и к чему это
Предположим, что поддельный сервер будет выдавать неверное время только атакуемым клиентам. Тогда народ ничего не заметит, пул тоже.
Выдавить все NTP сервера можно было и раньше, и достаточно легко — сотня узлов в датацентрах с толстыми каналами перетянули бы на себя почти весь NTP трафик, 90% уж точно.
А вот те 120 (или 140) серверов, которые были, но исчезли — они точно были настоящие? Ну, это если включить фантазию :)
Можете пояснить связь между zero-day и неверным временем?
Допустим, у меня естьт некий уязвимый сервис. Даже неважно, опубликована эта уязвимость или еще нет. Каким образом неверное время скажется? Что за zero-day такой, что пока на компе время точное, он не работает?
Я могу представить, что "Час Х" - особый сигнал для таймбомбы. Но если кто-то мне уже внедрил такую таймбомбу, можно было бы ее и попроще активировать, нежели грохая все остальные ntp серверы.
Гипотетически, может быть уязвимость, завязанная на текущее время. Например, при внезапном уходе времени в прошлое в каком-то вычислении может получиться отрицательный временной интервал, который некорректно обрабатывается. Или, скажем, можно заставить систему войти в аккаунт, у которого срок действия истек, или принять истекший сертификат.
Наверное, такого рода ошибки вполне реальны во всяких кривых китайских IoT, но их прекрасно ломают и без захвата NTP.
Серьезная инфраструктура не доверяет какому попало NTP серверу извне. Ну и даже стандартный ntpd не дает откатывать время назад, а только замедлять ход времени.
Идея с истекшим сертификатом понравилась. Хоть и не вижу реально, как может использоваться, но самому в голову не приходило такое.
Впрочем, насколько я знаю, ntpd в норме не позволяет делать резкие скачки времени.
Under ordinary conditions,
ntpdadjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. Thentpdalgorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when
ntpdis first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the-xoption is included on the command line, the clock will never be stepped and only slew corrections will be used.
Нужно, чтобы сложилась куча факторов - и ntpd неверно реализован (или явно настроен разрешать перемещения во времени/скачки по эпохам), и в каком-то софте проблемы, связанные со временем...
В кривых китайских IoT, как вы пишете, такое возможно. Но там действительно и попроще способы есть. Да и вообще довольно странно захватывать ntp пул просто чтобы уронить кучу бытовых железок (ибо корпоративные обычно пользуются собственными DNS, NTP и прочими серверами, а не 1.1.1.1/8.8.8.8 или вовсе "какой подсунут").
Где-то в тех же числах перестал работать из России ntp2.kangran.su, до этого работавший десятки лет. И не работает до сих пор.
Интересно, а что случилось с дефолтными для винды time.windows.com , *.nist.gov - РКН или санкции? Несколько месяцев не работали, буквально прошлой ночью прописал ntp.msk-ix.ru наконец; ВНИИФТРИ все не перебирал, но ни сейчас, ни когда пробовал ранее в этом году - та же ошибка что и со стандартными была.
Я к свомему Mikrotik'у подключил GPS приёмник с Ali, без 1pps, но для моей домашней сети такой точности времени более чем достаточно.
Да какая там статья - максимум заметка в Twitter:
- подключить GPS приёмник к роутеру (использую GPS VK-172, который покупал за 300 рублей в 2021-м, сейчас есть лучше). Приёмник повесить на окно или вывести на улицу, так, чтобы видно было открытое небо
- установить пакеты GPS и NTP
- В меню System - GPS выбрать нужный порт, поставить галочку "Set System Time" и, конечно, включить GPS (галочка на "Enabled").
- Теперь нужно подождать. Когда наберётся достаточное количество спутников, вы увидите в окне текущие дату/время по UTC, свои геокоординаты и количество принимаемых спутников. Когда появится галочка "Valid", Микротик начнёт использовать полученное время и устанавливать по нему системные часы.
- Теперь нужно включить NTP Сервер (System - NTP Server) и установить галочку "Use Local Clock".
NTP сервер может начать раздавать время не сразу.
В Windows можно проверить NTP сервер при помощи NTP Checker
https://www.ntp-time-server.com/ntp-software/ntp-check.html
Если налететь на помехи от военных все будет не так хорошо. Не знаю, умеют ли они сдвигать время в будущее, но в прошлое минут на 5-20 - запросто.
Собственно, я так в машине определяю, будет навигатор работать или точно нет - если на панели часы расходятся с часами на экране - стало быть, помехи, навигатор бесполезен.
Вот, тоже об этом подумал. Военная тема. Как они устанавливают время на своих девайсах и защищаются от помех на частотах ГЛОНАСС. Возможно, все по проводу
Возможно, военным девайсам не нужно постоянно сверять время с внешними сервисами, по проводу и без, т.к. в них стоит микруха, обеспечивающая достаточную точность на протяжении всего срока службы (либо в промежутке между ТО) изделия?
Например такое есть для гражданского рынка.
На днях часы на мобиле перевелись на 2 часа вперед, как раз ехал по навигатору. Минут через 30 вернулись к норме
А не часовой пояс сменился? Если например в телефоне выставлена настройка "часовой пояс сети" - то не только время, но и часовой пояс берётся от базовой станции. Несколько лет назад при поездках в места, близкие к соседней области (с отличающимся часовым поясом) телефон переключался на другую БС, и часовой пояс менялся, на экране телефона выглядело что время поменялось на час. С тех пор я выставляю только чтобы время бралось от базовой станции, а часовой пояс ставлю вручную.
А какой смысл в GPS без pps? Как будто NTP даст точность гораздо лучше, и делать ничего не надо
Для меня статья читается примерно так:
"Друзья, я обнаружил, что на улице стало холодать и поставил одну из своих батарей снаружи. Позже выяснилось, что батарея совсем холодная и мало того, холодными стали и остальные мои батареи и вся система ГВС. В результате я выстудил дом, но улицу согреть не смог. Это наша общая проблема, поэтому обращаюсь к обеспеченным людям: купите и выставьте по батарее на улицу, чтобы решить ее и всем помочь."
Простите, конечно, ТС, но вопрос явно не пользовательского уровня.
Путь длиною в миллион шагов не пройдешь, не сделав первый шаг.
Так, из века в век, подрыв основ начинает одиночка-смельчак.
Немного статистики:
США и Канада — 925 и 150 серверов в пуле соответственно,
Германия — 905,
Великобритания — 300,
Франция — 284,
Нидерланды — 273,
Швейцария — 150.
Между тем Россия:
2014 год — пик 120 серверов (плавно доросло с 2004), затем резкий спад до 90,
2017 год — пик 140 серверов, затем резкий спад до 70,
2024 год — пик 150 серверов, затем резкий спад до 120 (перед коллапсом).
То есть у нас на 146 млн. населения столько же серверов в пуле, сколько в Канаде (41 млн.) или Швейцарии (9 млн.) и вдвое меньше, чем в Великобритании, Франции (по 68 млн.) или Нидерландах (18 млн.), а сравнивать с Германией и США вообще бесполезно.
Вопрос - пользовательского уровня все же.
Традиционно - батареи ставились на улицу и все работало и все устраивало достаточно, никто не пробовал к батареям подцепить термопары чтоб зря не грели, никто не подходил к ним слишком часто и никто не говорил что надо заблокировать батарею наркоманам а то иш придумали греться.
Есть такие моменты в инфраструктуре интернета которые так сделаны и все работало, потихоньку всплывает - история что OpenSSL'ем занято по сути 2 человека, причем кому попало там лезть не стоит - будет хуже - всплыла полноценно после heartbleed'а (наладили спонсорство и дополнительных людей нашли), история что TZ_database (база данных часовых поясов) вообще одним конкретным человеком поддерживается - всплыла после иска разработчиков софта для астрологии (https://habr.com/ru/articles/129924/ ), теперь официально поддерживается IANA.
Ну почему бы Яндексу не сделать свои NTP, со всеми их неэпическими облаками и DNS-серверами, учитывая, что их станции используют NTP от частных пользователей? Вы не находите тут некоторый перекос интересов и даже может быть, использование труда энтузиастов в коммерческих целях?
Вот мне тоже интересно - https://www.ntppool.org/vendors.html в Яндексе вообще - читали? Если читали - почему сделали так?(а они НЕ сделали 0.{yandex
yndx}.pool.ntp.org - не резолвится, для сравнения),
Яндексвообще в курсе, что тут происходит? А то обсуждают, а никто и не упомянул даже (не то чтобы написать куда-то).
Так.... Попробовал опубликовать свой NTP, по заверению сайта - "больно не будет, пакеты маленькие"...
Как только рейтинг превысил 12.6 мой микротик умер, перезагрузился и снова умер. 400 000 пакетов ему переварить и каждому раздать время оказалось непосильной задачей.
И это только было на IPv6....
Буду думать дальше :-)
Странно. Как раз на IPv6 никакой беды не случилось — как было 30–40 серверов в российской зоне в течение последних трёх лет, так и осталось, потому что трафик там околонулевой. Проблемы могут быть только у dual-stack серверов — которые участвуют в пуле одновременно как IPv4 и IPv6, и соответственно страдают по части IPv4, но эффект распространяется и на IPv6.
IPv4 и IPv6 в пуле представлены как разные сервера. Один и тот же сервер нужно добавлять дважды. Так что, по идее, проблемы v4 на v6 влиять не должны.
Если только ваш IPv6-трафик не бегает по отдельному каналу и не обрабатывается отдельным роутером, и ваш NTP-сервер также не является узким местом. В противном случае проблемы из-за перегрузки IPv4-трафиком очень даже влияют на доступность вашего IPv6-сервера, а если он ещё и время получает только через Интернет (то есть не имеет локальных источников типа GPS) — то и на точность хода, а оба этих параметра определяют рейтинг вашего сервера в пуле.
я предупреждал :)
на IPv4 мне в пике приходило до 1.8млн пакетов/с и 855мбит/с трафика.
если что придумаешь пиши, а то точно такая же проблема
Посмотри, какие запросы личный кабинет пула шлёт при смене netspeed. Типа https://manage.ntppool.org/manage/server/update/netspeed?netspeed=1&server=XXX&auth_token=YYYY
Можно поставить 1 кбит/с вручную. Я поставил, мой домашний сервак вывозит
Вообще, не зря сетевики измеряют нагрузку в pps, а не в bps. Сетевому оборудованию больнее, когда слишком много пакетов.
Выставил свой микрот для фану. Но проблема выглядит надуманой.
Смартфон получает данные с мобильной сети, винда с time.windows.com, линукс со своих серверов тоже по-умолчанию
В общем, как и многие тут писали, сначала всё было хорошо, потом резко пришёл ТРАФИК и микротик просто тупо лёг. Обвёл кружочком на графике.
Трафик похож на какой-то паразитный; немного почитал интернеты, пошаманил с рейтлимитингом (выставил максимум 56 запросов в час) и вроде бы ситуация стабилизировалась. Правила fw ниже. В prerouting добавил как раз чтобы разгрузить процессор
chain=input action=accept protocol=udp in-interface=ether1-Internet dst-port=123 dst-limit=56/1h,5,src-address/1d log=no log-prefix="NTP"
chain=prerouting action=accept in-interface=ether1-Internet dst-port=123 dst-limit=56/1h,5,src-address/1d log=no log-prefix="" protocol=udp
Нагрузка на процессор присутствует, но она не 90-100, а на уровне 30-50. Возможно, у кого-то есть подробный гайд как это дополнительно оптимизировать на микротике? Мне кажется, фоновый расход в 50% CPU это совсем не "капелечка трафика"
Пока что оставил на 512 kbps, через пару дней посмотрим. PS Надеюсь, все, кто минусует, успешно подняли свои ноды и придумали как их защищать от ддоса, иначе не совсем понятна реакция
шлагбаум, завязанный на мой интернет, стоит открытый (это его стандартное поведение при пропадании связи со шлюзом).
- Ваша дверь открывается через интернет, но как Вы попадёте домой, если будут проблемы с интернетом?
- В этом случае дверь просто откроется и всё.
Отличная система безопасности!
Это прям как киношное "разбить панель для ввода кода и секретное хранилище откроется само собой".
Это абсолютно правильная система охраны для 99 процентов помещений и территорий. В случае любого нештатного поведения просто все замки, шлагбаумы и турникеты открываем. Безопасность людей важнее всего, а ее может гарантировать только такое поведение системы.
Да, я в курсе, что сейчас в отрасли этот #$%# считается нормой.
Безопасность людей важнее всего, а ее может гарантировать только такое поведение системы.
Если смарт-замок на двери в квартиру будет открываться щёлчком на подъездном электрощите, то это не "безопасность".
А рано или поздно, отрасль придёт именно к этому решению.
Для домашних замков давно придумали ручное открытие изнутри. Полностью механическое без ключа.
Если в вашем смарт замке такого нет, то он и должен открываться при пропадании питания (если нет батареек и всего такого). Вы не хотите сгореть в квартире, потому что дверь закрылась и нет вариантов ее открыть. А электричество пожарные выключили, это нормальное действие для них.
Если в вашем смарт замке такого нет, то он и должен открываться при пропадании питания (если нет батареек и всего такого).
Тут важным фактом является то, что Вы пишете не "такого замка не должно быть", а "если такой замок есть".
Я верю что есть все что угодно. Хочется верить что оно все ведет себя самым разумным и безопасным для людей способом.
Есть миллионы офисных дверей по карточкам. Они все ведут себя именно так. Включая выходы на улицу. Что-то случилось - просто все открываем. Люди ценнее любого имущества. Не вижу почему любой другой замок зависящий от электричества должен вести себя по другому.
Хочется верить что оно все ведет себя самым разумным и безопасным для людей способом.
А существование замков, которые просто открываются при отключении электричества, не наводит Вас на мысль, что Ваша вера в разумность тщетна?
Сам факт существования таких замков, должен наводить на оптимистическую мысль "хуже очень даже может быть".
Оно наоборот наводит меня на мысль что люди не разучились думать и делать нормально. Как раз возможность существования замков которые могут не открыться в случае чего и убить меня приводит меня в ужас.
#%$# данного обсуждения в том, что Вы врядли шутите.
И чтобы в голове не висело.
Как раз возможность существования замков которые могут не открыться в случае чего и убить меня приводит меня в ужас.
Тогда Вас должно приводить в ужас существование замков не имеющих автономного механического открывания, то есть - критически зависящих от наличия электричества и связи с удалённым центром.
Да, оно приводит меня в ужас. Надеюсь что я в таких помещениях не бываю примерно никогда. И надеюсь что все кто там бывает как минимум читают какую-нибудь инструкцию что делать при пожаре и подписываются что прочитали. И это нормальная инструкция, согласованная пожарным надзором.
Да, оно приводит меня в ужас.
Но если замок может функционировать без электричества, то зачем делать автооткрывание при пропаже электричества?
По моему вы не совсем понимаете вашего собеседника. Замок должен иметь возможность открытия без электричества (какой именно – не важно). Если такая возможность не заложена изготовителем, то такой замок должен открываться сам. Иначе это просто не безопасно для людей внутри помещения.
___
Если замок ДОЛЖЕН иметь возможность открываться вручную, то не может быть никакого "Если такая возможность не заложена".
Я писал про открытие без электричества, про "вручную" я ничего не писал. Чисто технически, автоматическое открытие замка может считаться таким способом. Безопасность этого способа – это уже отдельный вопрос. Например, для внутренних дверей это может быть допустимо. Или дверь парадного жилого дома.
Замок должен иметь возможность открытия без электричества (какой именно – не важно). Если такая возможность не заложена изготовителем, то такой замок должен открываться сам.
Если замок ДОЛЖЕН иметь возможность открываться вручную, то не может быть никакого "Если такая возможность не заложена".
Это к вопросу о том, что я понимаю что пишут мои собеседники, а они не всегда понимаю что сами пишут.
Иначе это просто не безопасно для людей внутри помещения.
Если у замка нет возможности ручного открытия, то небезопасно находиться внутри помещения.
Господа, Вы выбрали не верную аналогию и Ваш спор сейчас из за этого, а не по сути.
Закрытый замок это упрощение, которое приводит к спору и невозможности разрешения задачи.
Усложните задачу, разделите одно действие (открыт/закрыт) на два: - должен выпускать наружу/ не пускать внутрь. И предмет Вашего спора на некоторое время пропадет.
Да, замок даже без электричества не должен пускать внутрь злоумышленника. Но должен выпускать наружу всех. Теперь аналогия что электрический замок не должен терять все свои функции (даже по сравнению с механическим) становится понятна, его функциональность должна редуцироваться до предыдущего примлемого - механического.
Да, замок даже без электричества не должен пускать внутрь злоумышленника.
Он сможет отличить пожарного, приехавшего вытащить потерявших сознание сотрудников, от злоумышленника?
Так же как и механический замок: по наличию в умелых руках пожарного механической же монтировки для его, замка, вандального вскрытия.
Поэтому да, тут Вы правы, к моей абстракции добавляем следующий уровень детализации: не впускать не всех подряд, а только тех, кому не очень надо, кто не озаботился наличием сложных технических устройств его взлома. Но пожарного этого увидят и услышат все соседи и управдом, как и злоумышленника.
А обычный механический замок умеет автоматический открываться по кодовой фразе "я из МЧС"?
Замок не должен пускать внутрь никого. У пожарных/МЧС есть оборудование и навыки вышибать дверь/окно. И, в отличие от злоумышленников, им не требуется соблюдать тишину и не привлекать внимания.
Если же замок открывает дверь щелчком рубильника на лестничной клетке - такой даже для почтового ящика не годится. Максимум - висюлька на девчачий "дневник"
интересно что это можно было бы реализовать и скорее всего реализовано в офисных дверях по принципу: "толкаешь - открыто, тянешь - закрыто". Думаю что противопожарные двери так и работают с этой вот большой горизонтальной ручкой.
Обычный механический замок запрещено ставить на пожарные выходы.
Есть электромеханические замки с открытием изнутри, но они менее надёжны и блокируют вход при отсутствии электричества, поэтому их тоже почти не ставят на подъезды МКД.
А обычный механический замок умеет автоматический открываться по кодовой фразе "я из МЧС"?
Замок не должен пускать внутрь никого. У пожарных/МЧС есть оборудование и навыки вышибать дверь/окно. И, в отличие от злоумышленников, им не требуется соблюдать тишину и не привлекать внимания.
Если же замок открывает дверь щелчком рубильника на лестничной клетке - такой даже для почтового ящика не годится. Максимум - висюлька на девчачий "дневник"
А как, к слову, электрический замок сможет отличить приехавшего пожарного? У него вроде ж тоже брелка с собой нет.
На некоторое время, так как на старте был шлагбаум. Который должен открыться перед скорой. Насколько я знаю есть штатный способ для любой машины с мигалкой заехать в любой московский двор. И этот способ работает через сеть (не электрическую). Значит шлагбаум без связи должен открыться, на случай стоящей рядом скорой, которую он не слышит.
шлагбаум в Москве - это больше не про безопасность, а про зарезервировать парковочные места во дворе за жильцами.
мне не нравится это решение, я был бы рад, чтобы его не было, но, увы.
100%, ничего общего с безопасностью эта система не имеет. Это реакция на проблему которая была создана искусственно дорожными властями города Москвы с треклятым Лискутовым во главе, которые на городских дорогах половину парковочных мест везде позакрывали, а в тех местах где оставили сделали их платными. Пока этого безобразия не было никто кроме жителей самых элитных домов в центре города и не думал никакие шлагбаумы ставить, все неместные чем по этим непонятным дворам ныкаться все равно предпочитали просто ставить тачку на дороге: одну центральную полосу для проезда оставляли а слева и справа везде машины стояли и никаких проблем не было.
Вы пишите верно, именно для того, чтобы зарезервировать. Тут две стороны монеты, с одной стороны - да, это не очень хорошо (как гость - не можете встать, как живущий - иногда это сопряжено с поборами и т.д.), но с другой - когда во дворе паркуется (внезапно) пачка таксистов или газелей и иных машин, которые явно тут не живут, во дворе начинается сущий ад.
а не рассматривали возможность, что это не игры ркн, а ддос направленный на ру сегмент?
Ничосе, пользователя @protomentoзабрали. Дело принимает интересный оборот!
Там можно выставить скорость поменьше, а не только 512. Правда, мне для этого пришлось поправить запрос в браузере, потому что форма не совсем работает
Upd Поднял один.
Сейчас на скорости 512Кб летит примерно 200к пакетов, что примерно 150Мб
Из странного - много icmp unreachable
эта выставленная скорость почти ни на что не влияет
Поднял парочку. Чтобы от timeweb слишком много не зависело.
просто оставлю это тут
cat /etc/modprobe.d/xt.conf
options xt_recent ip_list_tot=500000
cat /etc/sysctl.d/20-my.conf
net.netfilter.nf_conntrack_udp_timeout=0
iptables -A INPUT -d x.x.x.x/32 -p udp -m recent --rcheck --seconds 1200 --name icmp_udp_unreachable --mask 255.255.255.255 --rsource -m udp --dport 123 -j DROP
iptables -A INPUT -d x.x.x.x/32 -p icmp -m icmp --icmp-type 3 -m recent --set --name icmp_udp_unreachable --mask 255.255.255.255 --rsource -j DROP
iptables -A INPUT -d x.x.x.x/32 -p udp -m udp --dport 123 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 1 --hashlimit-mode srcip --hashlimit-name ntp_rate_limit --hashlimit-htable-size 500000 --hashlimit-htable-max 500000 --hashlimit-htable-gcinterval 5000 --hashlimit-htable-expire 5000 -j ACCEPT
iptables -A INPUT -d x.x.x.x/32 -p udp -m udp --dport 123 -j DROPеще рекомендую посмотреть на очереди сервера (multiqueue) : ethtool -l eth1
в идеале должны соответствовать ядрам
мультизапуск chronyd тоже очень полезен. не знаю, как он работает, но по сути балансируются как-то между сервисами udp запроса без регистрации и смс
в дебиан на основе /etc/systemd/system/chronyd.service
просто копируете содержимое в
/etc/systemd/system/chronyd{1,2,3,4}.service
внутри делаете
PIDFile=/run/chrony/chronyd{1,2,3,4}.pid
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS -f /etc/chrony/chrony{1,2,3,4}.confв файликах /etc/chrony/chrony{1,2,3,4}.conf
добавляете строчку
pidfile /run/chrony/chronyd{1,2,3,4}.pidне знаю, как он работает, но по сути балансируются как-то между сервисами udp запроса без регистрации и смс
Это механизм REUSEPORT, ядро хеширует заголовок пакета и запихивает в один из процессов, слушающих этот порт, в зависимости от хеша.
Размеры хэшей могут быть маловаты, у меня было более 800тыс в минуту разных source ip, присылающих icmp unreach
chrony можно ещё запускать как
1 основной демон, берущий время от источника и отвечающий на 127.0.0.1
N(по числу ядер) демонов-клиентов, которые берут время от первого и отвечают вопрошающим. Настраиваются с опцией copy (копирует с основного refid, stratum) см https://chrony-project.org/faq.html#_can_ntp_server_be_separated_from_ntp_client
и в самом chrony ещё можно увеличить clientloglimit до нескольких миллионов или сразу до максимума, если можно выделить пару гиг оперативки. Вроде как эта таблица используется и для рейтлимита в самом демоне, но это не точно.
This directive specifies the maximum amount of memory that chronyd is allowed to allocate for logging of client accesses and the state that chronyd as an NTP server needs to support the interleaved mode for its clients. The default limit is 524288 bytes, which enables monitoring of up to 4096 IP addresses at the same time and holding NTP timestamps for up to 4096 clients using the interleaved mode (depending on uniformity of their polling interval). The number of addresses and timestamps is always a power of 2. The maximum effective value is 2147483648 (2 GB), which corresponds to 16777216 addresses and timestamps.
либо наоборот попробовать сделать noclientlog для снижения нагрузки
прошу прощения за мультипостинг, отвечаю набегами.
Такими правилами получится отрезать бОльшую часть. Но некоторая часть icmp приходят от транзитных узлов (возможно, это фаервол/защита на пути к конечному хосту). То есть обмен такой:
clientIP -> Server: ntp request
Server -> clientIP: ntp reply
TransitHost -> Server: ICMP: udp port on host clientIP unreachable.
Блокируя/рейтлимитя TransitHost мы не срезаем ntp-запросы и ответы, ведь запросы приходят "не от него".
@kkursor полагаю, что имеет смысл добавить это в тело поста.
а можете по правилам пояснить? я правильно понимаю, что, получив icmp_unreachable, отправитель попадает в бан и запросы от "него" уже не воспринимаются?
cat /etc/modprobe.d/xt.conf
options xt_recent ip_list_tot=500000Увеличивам размер таблицы xt_recent. По умолчанию 100. Эта таблица вроде как кольцевой буфер, но 100 маловато. 500к может многовато, оптимальный размер не подбирал, вроде и так норм.
Если recent уже используется в iptables, сначала надо убрать правила, выгрузить модуль, добавить файлик (файлик когда угодно можно добавить). Можно загрузить модуль вручную, но он будет и так загружен, когда правила добавятся. Ну или добавить файлик и ребутнуться.
cat /etc/sysctl.d/20-my.conf
net.netfilter.nf_conntrack_udp_timeout=0Показалось полезным, т.к. нам совершенно не нужно отслеживать "соединения" для ntp, т.к по сути там нет как такового соединения для обмена.
Это правило срабатывает (блокирует ntp трафик на 123 порт), если в таблице нашлось соединение и еще не прошло 1200 секунд с момента последнего пакета. Б
iptables -A INPUT -d x.x.x.x/32 -p udp -m recent --rcheck --seconds 1200 --name icmp_udp_unreachable --mask 255.255.255.255 --rsource -m udp --dport 123 -j DROPЭто правило добавляет в таблицу по src, если от него пришёл icmp тип 3 и заодно блокируем.
iptables -A INPUT -d x.x.x.x/32 -p icmp -m icmp --icmp-type 3 -m recent --set --name icmp_udp_unreachable --mask 255.255.255.255 --rsource -j DROPВ данном правиле мы ограничиваем ACCEPT лимитом в 1 запрос в секунду так же по src. Размер таблицы 500к, обнуление через 5 секунд (хотя в случае 1 запроса в секунду, обнуление особого смысла не имеет).
iptables -A INPUT -d x.x.x.x/32 -p udp -m udp --dport 123 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 1 --hashlimit-mode srcip --hashlimit-name ntp_rate_limit --hashlimit-htable-size 500000 --hashlimit-htable-max 500000 --hashlimit-htable-gcinterval 5000 --hashlimit-htable-expire 5000 -j ACCEPTБлокируем трафик, если предыдущее правило не сработало по причине лимитов.
iptables -A INPUT -d x.x.x.x/32 -p udp -m udp --dport 123 -j DROPЕще у меня на всякий случай есть правила
iptables -A INPUT -d x.x.x.x/32 -p icmp -m limit --limit 10/sec -m icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -d x.x.x.x/32 -p icmp -j DROPно они опциональны.
Что касается правило с hashlimit, чтоб изменить его параметры надо удалить правило и добавить заново.
проще всего это делать так
iptables-save -c > /tmp/g
edit /tmp/g
cat /tmp/g|iptables-restore -cалгоритм такой - сохраняем правила, редактируем, комментируем правила hashlimit и следующее правило с DROP (иначе весь трафик будет блочиться на время манипуляций, что негативно сказыватеся на score). делаем cat /tmp/g|iptables-restore -c еще раз редактируем - раскомментируем, и еще раз cat /tmp/g|iptables-restore -c
и еще, вроде как поведение этих всех правил может отличаться в зависимости от версии ядра, системы и дистрибутива.
у меня это всё работает на debian 11.9, 5.10.0-28-amd64
в общем пробовать нужно осторожно
Iptables-apply?
как-то даже пошёл гуглить, что делает эта команда. никогда не пользовался. возможно apply и то что надо в данном случае, но я не проверял.
Apply загружает правила из файла, который сделал save, и делает автооткат, если чёто поломал
никогда этим не пользовался (во всяком случае не помню). но попробую запомнить, спасибо.
хотя я обычно непосредственно через iptables добавляю и удаляю правила. использую алиас ipt="iptables -n -v --line-numbers" в bashrc
а в более сложных случаях save - restore, но теперь попробую как-нибудь через apply
ещё момент: ntp также может работать по tcp, но там трафика очень мало, буквально единицы пакетов в минуту.
Можно ещё добавить блокировку диапазонов из RFC6890, это серые и special purpose адреса. Нужные серые конечно же надо разрешить на нужных интерфейсах или можно их ограничить по ttl. Если давать больше скорости то от транзитных 10/8 и 100.64/10 приходит ооочень дофига icmp и добавлять их в таблицы для рейтлимита просто незачем.
0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.0.0/29
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
240.0.0.0/4
#255.255.255.255/32
А можно что то подобное для Mikrotik?
ну примерно так, но я не пробовал, но по логике должно работать
/ip firewall mangle add action=add-src-to-address-list address-list=icmp_unreachble address-list-timeout=20m chain=input dst-address=5.5.5.5 icmp-options=3:3 protocol=icmp
/ip firewall filter add action=drop chain=input dst-address=5.5.5.5 dst-port=123 protocol=udp src-address-list=icmp_unreachble
/ip firewall filter add action=accept chain=input dst-address=5.5.5.5 dst-port=123 limit=1,5:packet protocol=udp
/ip firewall filter add action=drop chain=input dst-address=5.5.5.5 dst-port=123 protocol=udp
Возможно уже озвучили, но ходят слухи, что около месяца назад "с ума" посходили яндекс станции, и начали генерировать сотни ntp запросов на пустом месте, каждые 5 секунд опрашивали от 5 до 15 различных ntp серверов...но судя по всему, буквально несколько часов назад, это прошло...
но судя по всему, буквально несколько часов назад, это прошло
Благодаря статье добавились люди, поднявшие свои серверочки.
Яндекс станции и прочие стали успевать получать ответы, а не посылать запросы еще и еще из-за маленького таймаута, окончательно добивая выживших.
И жизнь стала налаживаться.
Просто версия, может и софт в Яндекс Станции пофиксили. А вообще интересно было бы глянуть на распределение адресов, с которых шла куча пакетов. Насколько он отличается от обычного профиля.
200 тысяч пакетов в секунду все еще вижу. Не пофиксили.
Ну, может софт раскатывают поэтапно.
- Вот если бы у меня была Алиса, я бы поснифферил, много ли она ntp запросов отправляет и куда. Может даже подменил ей IP сервера, возвращаемый DNS, на забугорный и сравнил частоту запросов...
- Жаль, что у тебя нет Алисы...
(по мотивам "поделился бы апельсином")
У меня, кстати, Алиса как раз есть у детей. Хотя мы находимся не в РФ и куда её NTP улетать будет сложно сказать. Но поснифферю сейчас ради интереса.
Посниферил часок, вообще NTP пакетов не заметил, из UDP только DNS.
Забавно. Возможно после успешного получения времени она долго ему верит. А вот ежели начала интересоваться, не успокоится, пока не узнает.
Интересно, как будет себя вести, если запретить для нее NTP (дропами/реджектами) протокол наружу. Будет изредка ломиться или со страшной силой...
Это я не вас напрягаю. Тем более не детей без Алисы оставить подзуживаю :) Просто мысли в слух. Вдруг кто-то уже проверял.
Ну или у вас уже обновилась... Не знаю, можно ли у нее узнать версию/дату последнего обновления...
Ой, как хорошо тут! Все понимают о чём речь. А я вчера пробивался сквозь насмешки, доказывая, что GPS это в первую очередь точное время, а потом уже координаты, так как одного без другого быть не может. Увы, в ответ услышал только: ты чего, не знаешь, что GPS это куча спутников передающих твои координаты?!
А в чём прикол пула из пользовательских серверов?
Я пользуюсь (как клиент) сервисом времени https://www.ntp-servers.net/
Никогда не замечал, чтобы их сервера не справлялись с нагрузкой.
В том что ntp-servers.net использует пулы
dig ntp6.ntp-servers.net
ntp6.ntp-servers.net. 300 IN CNAME 2.europe.pool.ntp.org.
Пользовался ими еще когда они были stratum1/2.ru, домены эти не продлили, время поплыло.
К тому же раньше у них были свои S1 и S2 сервера, но приемники умерли, а новые пока не приобрели.
И да, использовать пул - надежнее.
Катастрофа это авария с человеческими жертвами.
Если все живы, поправьте, пожалуйста, заголовок.
Спасибо.
Вы, вероятно, не знаете старый советский анекдот про разницу между бедой и катастрофой...
Вы неправы. Мои пруфы: https://gramota.ru/meta/katastrofa
Ваши пруфы?
В авиации термин "Катастрофа" - это происшествие с человеческими жертвами. Происшествие без жертв - это авария.
Но в "общечеловеческом" языке грань может быть не столь чёткой.
Достаточно Ваши внимательно прочитать.
в уме Алеши с каждым часом нарастало убеждение о неминуемой ужасной катастрофе, готовой совершиться. В чем именно состояла катастрофа и что хотел бы он сказать сию минуту брату, может быть, он и сам бы не определил
Братья Карамазовы, Ф.М. Достоевский.
Меняем Алешу на @kkursor, в чем состоит катастрофа он знает и рассказал об этом в данном топике.
классно, когда есть до чего доебаться! 👍
во многом благодаря ему все ваши компьютеры, смартфоны, серверы и прочие гаджеты имеют точное время
Сорри за глупый вопрос, а почему так? Может я не использую конкретно эти NTP-серверы
Timed out waiting for reply from 89.109.251.21:123 (ntp1.vniiftri.ru)
ntp2-4.vniiftri.ru аналогично поплохело
В пуле уже 46 активных серверов (https://www.ntppool.org/zone/ru). Вот она сила сообщества. Один попросил о помощи и сотни неравнодушных энтузиастов откликнулись на этот призыв. Сотни человек, которые даже не были друг с другом знакомы, совместными силами решили исправить проблему и восстановить численность NTP-серверов.
Спасибо всем, кто помогает. Ребята - вы лучшие!
Пусть ты сейчас один, если я встану с тобой,
Завтра за нами сомкнётся уже толпа. (с)
Спасибо, товарищи! Вы - лучшие!
Судя по дискуссии, теперь у дудосера есть больше простора для амплификации атаки.
не похоже это на дудос. Это реально больше похоже на кривую прошивку какого-то суперпопулярного устройства.
когда народ набижал, ужасная нагрузка резко спала. Она ещё утром была непереносима - а сейчас нормально вполне и даже по меркам домашнего интернета допустимо.
Похоже, похоже. Вот тут товарищ очень грамотно всё расписал - что много пакетов от мелких провайдеров (видимо, у них квалификации сетевиков не хватает, чтобы запретить спуфинг source-адресов).
Это не отменяет того, конечно, что чем больше серверов - тем проще эти всплески размазывать по ним.
Плюс, как только сервер добавляется в пул - начинает приезжать не только NTP-трафик, но и udp port unreachable в почти равном объёме. Это хорошо заметно на графике - легитимный NTP-трафик даёт картину 1 к 1:
амплификация в случае ntp это когда на один запрос monlist отдаётся гораздо больший ответ. в данном случае это не актуально, поскольку данная команда не доступна по крайней мере в случае с chrony, да и в новых версиях ntp её вроде как нет. злоумышленнику придётся отправить столько же пакетов и такого же объёма. другое дело, что они так обходят файрволы разных внутрироссийских сервисов. ну я выше написал, что можно с помощью iptables сделать, чтоб снизить использование атакующими ntp серверов.
У меня целых три станции Яндекса и с домашнего ротера микротик собирается netflow, примерно с 24 октября выросло Flows по 123 порту и по записям это все три станции (ip адреса в локалке за ними зарезервированы и не меняются). Вчера около 21:15 прекратили сходить с ума и вернулись к нормальным значениям
Мой мониторинг
На моих серверах все закончилось в 21 только
Пожалуйста, кто-нибудь напишите инструкцию для docker-compose. Думаю чем проще будет инструкция тем больше людей подтянется. У меня в распоряжении NAS с 8 потоками и 800мбит каналом, добавлю его в пул
pool ntp.msk-ix.ru iburst pool ntp4.vniiftri.ru iburst pool ntp5.vniiftri.ru iburst
Сервера vniiftri сейчас недоступны, я бы добавил больше серверов в инструкцию, так как один сервер msk-ix.ru и этого мало.
Поискав немного, нашел в дополнение такой список действующих stratum 1 ntp серверов в зоне ru
ntp.sstf.nsk.ru
ntp1.niiftri.irkutsk.ru
ntp2.niiftri.irkutsk.ru
atomic.zxlab.ru
ntp.zev.su
ntp1.ab2b.ru
ntp2.ab2b.ru
ntp.oborona.netпервые три это тоже ВНИИФТРИ в других локациях
Можно взять облачные/CDN (гугл и фейсбук отдают stratum1, cloudflare - stratum3)
server time.google.com (говорят он как-то по-особенному работают и лучше не использовать)
server time.facebook.com
server time.cloudflare.com
а всё таки, почему не стоит использовать time.google.com ? я наоборот прописал time2.google.com в качестве основного. у знаменитого 194.190.168.1 например разброс по времени +40/-10 мс согласно score
проверял через https://www.ntppool.org/scores/216.239.35.4 . пинг до него красивый и ровный 15.7-15.8
перечисленные выше сервера слабоваты по качеству, согласно score. пара серверов только ничего. а так, даже мой сервачок уже 19.9 по score
Добавил два своих сервера, автору спасибо
@kkursor, мне московские сервера ВНИИФТРИ перестали отвечать, я думаю что они в последнее время сильно ограничивают активность запросов, замечал что после перезапуска демон до них не может достучаться по несколько часов. Имеет смысл указывать в конфиге только один из серверов ВНИИФТРИ + ntp.msk-ix.ru + использовать больше "облачных"/CND источников, например
server time.google.com
server time.facebook.com
server time.cloudflare.com
они тоже могут оказаться заблокированными на ТСПУ, интересно что cloudflare отдаёт stratum 3
ещё из российских был, похоже уже не отвечает
server stratum1.net
от хабровчанина @gag_fenix https://habr.com/ru/articles/118266/
Мобатайм mobatime.ru раньше сервера времени держал и давал доступ к ним для синхронизации и на главной их сайта часы были с показом разницы с временем компа, сейчас зашел к ним - осталась только продажа оборудования - часов с синхронизацией и самих, собственно, серверов ТВ.
Да я таки тоже вернулся в строй.
pool 130.149.17.21 iburst
pool 131.188.3.220 iburst
pool 185.131.196.23 iburst
pool 82.209.210.87 iburst
Вот эти юзаю для поддержания Stratum 2
У меня вот эти сервера используются, часть наши, часть заграничные
Вообще список серверов можно тут еще смотреть https://support.ntp.org/Servers/StratumOneTimeServers
Ну и через ntpdate -q и ntpd -pn смотреть что сервер живой
Тоже вернулся в строй, уже лет 6 в нем, даже на хабре писал как-то
server -4 ntp.ix.ru iburst
server -4 vniiftri.khv.ru iburst
server -4 ntp1.niiftri.irkutsk.ru iburst
server -4 ntp2.ab2b.ru iburst
server -4 ntp.sstf.nsk.ru iburst
server -4 ntp.sonur.ru iburst
server -4 ntp0.nl.uu.net iburst
server -4 ntp2.fau.de iburst
server -4 ntp.nic.kz iburst
server -4 time.esa.int iburst
Ещё есть сервера time.apple.com time.nist.gov time.windows.com (у винды stratum 3, но главное распределеность)
Спасибо за то, что вовремя привлекли внимание к проблеме. Причина — в ошибке на стороне прошивки умных колонок. Опубликовали статью, в которой рассказали об инциденте и о принимаемых мерах.
люблю такие детективы :)
Тоже поднял NTP-сервер, но непонятно, есть ли от него польза, на странице статистики говорится: "Текущий рейтинг: 3.7 (в пуле используются только сервера с рейтингом выше 10)". Текущий рейтинг считается только по точности, или ещё важно время работы? То есть, нужно постараться повысить точность сервера, или просто подождать?
Спасибо, что обратили внимание на проблему.
Кого смог попросил предоставить свой NTP сервер для пула, так же со своей стороны из домашнего кластера vSphere предоставил сервер.
Количество серверов теперь радует глаз. Но, мне кажется, что зоне ru.pool.ntp.org не хватает серверов мониторинга.
ВНИИФТРИ сервера свои "починили". Переделали профиль с noname на более официальный.
https://www.ntppool.org/a/VNIIFTRI
Осталось дождаться того же от "виновника торжества" ;)
Катастрофа в российской зоне проекта NTPPool.org