ещё момент: ntp также может работать по tcp, но там трафика очень мало, буквально единицы пакетов в минуту.
Можно ещё добавить блокировку диапазонов из RFC6890, это серые и special purpose адреса. Нужные серые конечно же надо разрешить на нужных интерфейсах или можно их ограничить по ttl. Если давать больше скорости то от транзитных 10/8 и 100.64/10 приходит ооочень дофига icmp и добавлять их в таблицы для рейтлимита просто незачем.
официальные государственные рекомендации давали операторам связи (возможно и другим структурам типа банков). Конечным пользователям никаких рекомендаций не озвучивалось. Сейчас в каждом роутере, телефоне и холодильнике прописан ntp pool, менять его везде вручную это бред.
в нормальном режиме при старте ntp-демон может делать частые запросы (burst), далее буквально за несколько минут их часота понижается, по дефолту доходя до 2^10сек или 1 запрос в ~17 минут в стабильно синхронизированном состоянии.
тоже интересно. Например, такая пачка вылетает раз в 5 сек (все ответы от серверов приходят, но яндекс-девайс всё равно спрашивает). Тут даже видно что уже в одну миллисекунду некоторые сервера запрашиваются дважды. Допустим iburst, но зачем каждые 5 сек и у такого кол-ва серверов? Попутно ещё раз в 20-30 секунд ресолвится какой-то из [0-3].ru.pool.ntp.org.
прошу прощения за мультипостинг, отвечаю набегами.
Такими правилами получится отрезать бОльшую часть. Но некоторая часть icmp приходят от транзитных узлов (возможно, это фаервол/защита на пути к конечному хосту). То есть обмен такой:
clientIP -> Server: ntp request
Server -> clientIP: ntp reply
TransitHost -> Server: ICMP: udp port on host clientIP unreachable.
Блокируя/рейтлимитя TransitHost мы не срезаем ntp-запросы и ответы, ведь запросы приходят "не от него".
не скажу про Яндекс, не исследовал и их девайсов у меня нет. По-моему 99% линукс-девайсов, включая холодильники и тостеры, сейчас использует общий адрес pool.ntp.org (который пул старается отресолвить в ближайшие к клиенту региональные сервера, так что рекомендации у них немногого странные). Не удивлюсь если у Яндекса тоже прописано просто pool.ntp.org.
Во избежание внезапностей можно добавить скрипт, анализирующий GPG/GLN координаты, выдаваемые приёмником и "если что" переключающий демона на внешние сервера, а потом обратно.
Если у вас есть мониторинг, также стоит добавить в него алярмы на изменение координат/стратума/текущего выбранного конфига.
и в самом 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 для снижения нагрузки
Стратум 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-трафика на ТСПУ. Сомнительно, но окэй.
звучит как ftpmail. Пишешь на определённый емейл ftpmail@... письмо со ссылкой, сервер скачивает с ftp указанное и высылает тебе ответным письмом. В общем этакий прокси по почте.
можно поставить на квартиру/линию/шкаф/сервер реле напряжения. И в целом полезная штука для спасения техники и у большинства моделей на случай "моргания" есть функция задержки подачи напряжения. Т.е. после появления питания "на приходе" реле сразу не "проключает" его дальше, оно отсчитывает заданное время (например, минуту) и только потом коммутирует питание в линию..
У многих недорогих ИБП на 1-2 батарейки нет холодного автостарта при разряженных батареях. Их надо включать кнопкой вручную после того как разрядились батареи и ИБП выключился.
бу sata можно посмотреть не только интел, есть другие варианты по запросу "SSD MLC". Масса дисков ~6-10летней давности ssd была на MLC (вопрос какая там скорость записи). Kingston KC400 терабайтный у меня с 2016 года около 5 лет использовался в ноуте как единственный диск (система+данные) и до сих пор показывает 100% живости. Подозреваю обманывает :-)
Intel DC в современных спеках указывают уже 3d TLC. Из новых интересно узнать про Micron, по TBW он схож с интелом при более низкой цене. TBW разительно растёт с ростом объёма диска.
Не вместо. Дополнительно. Это независимые процессы. С оператора обязанность "блокировать" никто не снимал. Даже при наличии ТСПУ оператор обязан регулярно загружать реестр и несёт ответственность за блокировку по реестру.
Поэтому провайдер может быть вообще не в курсе, что там РКН с интернет-трафиком делает.
не "может быть", а именно что не в курсе. О том, что загрузили "что-то новенькое" оператор узнаёт по косвенным признакам, когда клиенты начинают обрывать техподдержке телефоны. Либо от сообщества.
Очевидно, с тех пор как Вы работали в провайдере много воды утекло.
Коробочка для оценки качества фильтрации называется "Ревизор". Никто не отменял обязанность блокировать по списку запрещенных сайтов "чем хочешь" и проверку Ревизором. Если вдруг обнаруживается что не блокируешь - атата.
ТСПУ это другое. Оно тоже блокирует. И запрещенные сайты. И телеграмм. И впны. И ютуб вот "замедляет". Потому что. И оператор обязан пропускать трафик через него.
Кстати, дополнительно ещё (помимо всего) анализируют BGP связность и если вдруг между российскими AS трафик пошёл через нероссийскую, то, потрудитесь объяснить и принять меры.
ещё момент: 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
официальные государственные рекомендации давали операторам связи (возможно и другим структурам типа банков). Конечным пользователям никаких рекомендаций не озвучивалось. Сейчас в каждом роутере, телефоне и холодильнике прописан ntp pool, менять его везде вручную это бред.
в нормальном режиме при старте ntp-демон может делать частые запросы (burst), далее буквально за несколько минут их часота понижается, по дефолту доходя до 2^10сек или 1 запрос в ~17 минут в стабильно синхронизированном состоянии.
всё верно, amplification подразумевает увеличение объёма. Но reflection никто не отменял.
тоже интересно. Например, такая пачка вылетает раз в 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
прошу прощения за мультипостинг, отвечаю набегами.
Такими правилами получится отрезать бОльшую часть. Но некоторая часть icmp приходят от транзитных узлов (возможно, это фаервол/защита на пути к конечному хосту). То есть обмен такой:
clientIP -> Server: ntp requestServer -> clientIP: ntp replyTransitHost -> Server: ICMP: udp port on host clientIP unreachable.Блокируя/рейтлимитя TransitHost мы не срезаем ntp-запросы и ответы, ведь запросы приходят "не от него".
не скажу про Яндекс, не исследовал и их девайсов у меня нет. По-моему 99% линукс-девайсов, включая холодильники и тостеры, сейчас использует общий адрес pool.ntp.org (который пул старается отресолвить в ближайшие к клиенту региональные сервера, так что рекомендации у них немногого странные). Не удивлюсь если у Яндекса тоже прописано просто pool.ntp.org.
Совсем точно не анализировал, выборочно смотрел, похоже было что большинство запросов из РФ. Ссылку на источник пожалуйста. Гугл не помог :(
Во избежание внезапностей можно добавить скрипт, анализирующий GPG/GLN координаты, выдаваемые приёмником и "если что" переключающий демона на внешние сервера, а потом обратно.
Если у вас есть мониторинг, также стоит добавить в него алярмы на изменение координат/стратума/текущего выбранного конфига.
и в самом 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 для снижения нагрузки
Размеры хэшей могут быть маловаты, у меня было более 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
на IPv4 мне в пике приходило до 1.8млн пакетов/с и 855мбит/с трафика.
~9-11 cентября они несколько дней подряд лежали, так что не нужно надеяться только на них
Стратум 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-трафика на ТСПУ. Сомнительно, но окэй.
звучит как ftpmail. Пишешь на определённый емейл ftpmail@... письмо со ссылкой, сервер скачивает с ftp указанное и высылает тебе ответным письмом. В общем этакий прокси по почте.
можно поставить на квартиру/линию/шкаф/сервер реле напряжения. И в целом полезная штука для спасения техники и у большинства моделей на случай "моргания" есть функция задержки подачи напряжения. Т.е. после появления питания "на приходе" реле сразу не "проключает" его дальше, оно отсчитывает заданное время (например, минуту) и только потом коммутирует питание в линию..
У многих недорогих ИБП на 1-2 батарейки нет холодного автостарта при разряженных батареях. Их надо включать кнопкой вручную после того как разрядились батареи и ИБП выключился.
топовые поколения одноплатников совсем не бюджетные.
Есть ещё такое на M2 SSD https://habr.com/ru/articles/823814/
бу sata можно посмотреть не только интел, есть другие варианты по запросу "SSD MLC". Масса дисков ~6-10летней давности ssd была на MLC (вопрос какая там скорость записи). Kingston KC400 терабайтный у меня с 2016 года около 5 лет использовался в ноуте как единственный диск (система+данные) и до сих пор показывает 100% живости. Подозреваю обманывает :-)
Intel DC в современных спеках указывают уже 3d TLC. Из новых интересно узнать про Micron, по TBW он схож с интелом при более низкой цене. TBW разительно растёт с ростом объёма диска.
Не вместо. Дополнительно. Это независимые процессы. С оператора обязанность "блокировать" никто не снимал. Даже при наличии ТСПУ оператор обязан регулярно загружать реестр и несёт ответственность за блокировку по реестру.
не "может быть", а именно что не в курсе. О том, что загрузили "что-то новенькое" оператор узнаёт по косвенным признакам, когда клиенты начинают обрывать техподдержке телефоны. Либо от сообщества.
Очевидно, с тех пор как Вы работали в провайдере много воды утекло.
Коробочка для оценки качества фильтрации называется "Ревизор". Никто не отменял обязанность блокировать по списку запрещенных сайтов "чем хочешь" и проверку Ревизором. Если вдруг обнаруживается что не блокируешь - атата.
ТСПУ это другое. Оно тоже блокирует. И запрещенные сайты. И телеграмм. И впны. И ютуб вот "замедляет". Потому что. И оператор обязан пропускать трафик через него.
Кстати, дополнительно ещё (помимо всего) анализируют BGP связность и если вдруг между российскими AS трафик пошёл через нероссийскую, то, потрудитесь объяснить и принять меры.