Хотелось бы получить комментарии от Яндекс, почему их станция опрашивает ntp-сервера, а когда к ней от них приходит ответ, она плюёт в них ICMP Unreachable?
Тут есть ещё нюанс. В попытках борьбы с этим DDoS часть альтернативно одарённых администраторов вместо того чтобы резать исходящие запросы, начала резать входящие ответы от ntp-серверов. В результате чего, вполне нормальные ntp-клиенты мечутся по всему пулу, пытаясь узнать точное время. Ntp-серверы время им отдают, но до клиентов это время не доходит, например, около 48% ответов моего сервера реджектятся с icmp unreachable. Сколько просто дропается, мне неизвестно.
Было бы справедливо, если бы после этого Yandex взял на себя разборки с такими провайдерами. Думаю, Yandex'у будет проще преодолевать первые линии поддержки провайдеров, чем конечным пользователям. А технический инструмент для выявления таких ситуаций Yandex практически есть - это их собственный ботнет.
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Ну, так советы типа nf_conntrack_udp_timeout_stream=0 встречаются в этих ваших интернетах с 2016 года. Особенно, в контексте "пытаюсь завернуть исходящий udp трафик на самого себя".
Подтверждаю странное обилие icmp port unreachable, но сомневаюсь в DDoS, скорее уж, очередное рукожопие.
Отловил с десяток icmp port unreachable и посмотрел, что происходит. На первый взгляд, вполне нормальные ntp-клиенты с вполне нормальными интервалами между запросами, которые почем-то не принимают ответ.
Выглядит так, будто они забыли, что слали запрос и его надо бы принять.
Не удивлюсь, если начитались соседней ветки и не вникая в суть, навтыкали где попало notrack или же conntrack_udp_timeout в 0 поставили.
Другой вариант, что за NAT кто-то одновременно долбится куда-то, переполняя statefull nat, так что потом пакет с ответом либо неизвестно кому слать, либо шлёт не тому, кто спрашивал.
Это нормально. man ntpdate, man adjtime до просветления. Вкратце, ntpdate увидел небольшое расхождение и пытается "плавно" свести его на нет. Этот процесс вы и наблюдаете
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
Подобные обращения мы получали и раньше, но причиной всегда были сетевые ограничения на стороне пользователя (например, работодатель мог ограничивать запросы со стороны колонки в корпоративной сети)
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Для этого достаточно синхронизации между собой, нет необходимости долбить внешние сервера.
Самые хреновые кварцевые резонаторы, которые индустрия считает за кварц, а не за брак, плавают по частоте на 200 ppm в диапазоне температур -40+85 °C. Сомневаюсь, что станция испытывает столь резкие перепады температур, чтобы так часто синхронизоваться.
Кроме того, чем больше интервал между измерениями, тем точнее можно рассчитать ошибку частоты.
Как-то, когда у Андроида NITZ был более приорететным источником времени, чем NTP, мобильный оператор выдал мне время с отставанием на 15 минут. Было очень обидно.
Изучали сегодня с товарищем относительно свежую Yandex-станцию с относительно свежей прошивкой. Лезет нагло к pool.ntp.org. Работет в burst режиме. Эксперимента ради порезали ей исходящий ntp-трафик - ответила всплеском ntp-трафика, который потом сошёл на нет (видимо, перебирала всё, что могла найти в пуле). Экспериментов с частичной потерей пакетов не делали, но, возможно, частичная потеря пакетов будет её всегда держать в таком режиме
Сильно сомневаюсь, что на каком-нибудь 213.183.109.3, который плюется от 1000 до 3000 запросов в секунду, есть что-то с аналогичной Spamhaus ценностью, чтобы организовывать такую атаку. Скорее всего, там что-то взбесилось, но пристрелить это не удаётся, так-как провайдер игнорирует репорты.
Меньше чем за минуту ещё не все абюзеры успевают прийти, а потом ещё их запросам надо протолкаться в перегруженном канале. В общем, в текущей ситуации выявление аномалий весьма сложная задача.
Выглядело это так: аномально высокая частота запросов с 3-5 IP, достаточная, чтобы исчерпать лимит соединений механизма conntrack типично настроенного фаервола на Linux и т.п. statefull фаерволах, сагрить фаервол провайдера и т.д.
После чего система мониторинга пула исключает такой сервер из работы и перенаправляет весь его трафик на новых жертв. Ситуация повторяется.
Хотелось бы получить комментарии от Яндекс, почему их станция опрашивает ntp-сервера, а когда к ней от них приходит ответ, она плюёт в них ICMP Unreachable?
Лог под спойлером:
Скрытый текст
Тут есть ещё нюанс. В попытках борьбы с этим DDoS часть альтернативно одарённых администраторов вместо того чтобы резать исходящие запросы, начала резать входящие ответы от ntp-серверов. В результате чего, вполне нормальные ntp-клиенты мечутся по всему пулу, пытаясь узнать точное время. Ntp-серверы время им отдают, но до клиентов это время не доходит, например, около 48% ответов моего сервера реджектятся с icmp unreachable. Сколько просто дропается, мне неизвестно.
Было бы справедливо, если бы после этого Yandex взял на себя разборки с такими провайдерами. Думаю, Yandex'у будет проще преодолевать первые линии поддержки провайдеров, чем конечным пользователям. А технический инструмент для выявления таких ситуаций Yandex практически есть - это их собственный ботнет.
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Ну, так советы типа nf_conntrack_udp_timeout_stream=0 встречаются в этих ваших интернетах с 2016 года. Особенно, в контексте "пытаюсь завернуть исходящий udp трафик на самого себя".
Ну, да, очень оперативно. Больше месяца ru.pool.ntp.org лежал под DDoS.
Подтверждаю странное обилие icmp port unreachable, но сомневаюсь в DDoS, скорее уж, очередное рукожопие.
Отловил с десяток icmp port unreachable и посмотрел, что происходит. На первый взгляд, вполне нормальные ntp-клиенты с вполне нормальными интервалами между запросами, которые почем-то не принимают ответ.
Выглядит так, будто они забыли, что слали запрос и его надо бы принять.
Не удивлюсь, если начитались соседней ветки и не вникая в суть, навтыкали где попало notrack или же conntrack_udp_timeout в 0 поставили.
Другой вариант, что за NAT кто-то одновременно долбится куда-то, переполняя statefull nat, так что потом пакет с ответом либо неизвестно кому слать, либо шлёт не тому, кто спрашивал.
Это нормально. man ntpdate, man adjtime до просветления.
Вкратце, ntpdate увидел небольшое расхождение и пытается "плавно" свести его на нет. Этот процесс вы и наблюдаете
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Для этого достаточно синхронизации между собой, нет необходимости долбить внешние сервера.
Самые хреновые кварцевые резонаторы, которые индустрия считает за кварц, а не за брак, плавают по частоте на 200 ppm в диапазоне температур -40+85 °C. Сомневаюсь, что станция испытывает столь резкие перепады температур, чтобы так часто синхронизоваться.
Кроме того, чем больше интервал между измерениями, тем точнее можно рассчитать ошибку частоты.
А не подскажите, что конкретно сломается и какая точность времени требуется, чтобы не сломалось?
Как-то, когда у Андроида NITZ был более приорететным источником времени, чем NTP, мобильный оператор выдал мне время с отставанием на 15 минут. Было очень обидно.
Да, ещё она зачем-то регулярно шлёт запрос SOA для pool.ntp.org
Изучали сегодня с товарищем относительно свежую Yandex-станцию с относительно свежей прошивкой. Лезет нагло к pool.ntp.org. Работет в burst режиме. Эксперимента ради порезали ей исходящий ntp-трафик - ответила всплеском ntp-трафика, который потом сошёл на нет (видимо, перебирала всё, что могла найти в пуле). Экспериментов с частичной потерей пакетов не делали, но, возможно, частичная потеря пакетов будет её всегда держать в таком режиме
Так сейчас в пуле всего четыре активных сервера: https://www.ntppool.org/zone/ru
Сильно сомневаюсь, что на каком-нибудь 213.183.109.3, который плюется от 1000 до 3000 запросов в секунду, есть что-то с аналогичной Spamhaus ценностью, чтобы организовывать такую атаку. Скорее всего, там что-то взбесилось, но пристрелить это не удаётся, так-как провайдер игнорирует репорты.
Вполне вероятно. Получается, что каждая Yandex-станция ведёт себя как 1000 типичных, нормально сконфигурированных клиентов.
Меньше чем за минуту ещё не все абюзеры успевают прийти, а потом ещё их запросам надо протолкаться в перегруженном канале. В общем, в текущей ситуации выявление аномалий весьма сложная задача.
Для хронологии, меня это затронуло 26 октября.
Выглядело это так: аномально высокая частота запросов с 3-5 IP, достаточная, чтобы исчерпать лимит соединений механизма conntrack типично настроенного фаервола на Linux и т.п. statefull фаерволах, сагрить фаервол провайдера и т.д.
После чего система мониторинга пула исключает такой сервер из работы и перенаправляет весь его трафик на новых жертв. Ситуация повторяется.