Для лучшего понимания проблемы, посмотрим на график штатной нагрузки на сервер.

На графике видна нагрузка на сервер (количество запросов в секунду) от обычных клиентов NTP сервера (зелёным), от клиентов, веделенных в отдельную группу (жёлтым) и от клиентов, обслуживание которых приостановлено по тем или иным причинам (красным). График обновляется практически в реальном времени, с задержкой в доли секунды. Построением графика и вообще охраной NTP сервера занимается специально созданный для этого продукт. Он анализирует запросы, приходящие на сервер и в полностью автоматическом режиме принимает решение об обслуживании запроса или его игнорировании. История создания этого продукта весьма интересна и заслуживает отдельного поста.

Так вот. При настройке синхронизации времени по планировщику, каждый системный администратор, не подозревая того, добровольно принимает участие в DDoS атаке на NTP сервер. Как? Очень просто.

Перед настройкой синхронизации время на локальном компьютере отстаёт от точного. В некоторых случаях незначительно, на несколько секунд, в некоторых - на минуты. Суть не в этом. Она в том, что после первой синхронизации на локальном компьютере будет установлено точное время, с точностью до долей секунды. И если синхронизация настроена через планировщик, например, раз в пять минут, то ровно в 00 секунд локальный компьютер отправит запрос на NTP сервер. А теперь представим, что сервер в сутки обслуживает десятки тысяч клиентов...

График нагрузки приобретает вид пилы. Как видно, в начале каждой минуты на сервер приходит более 100 запросов в секунду. Это и есть те клиенты, которые настроили синхронизацию по шедулеру, с интервалом, кратным минуте (1, 2, 7, 50, роли не играет). После этого, сервер, справлявшийся со штатными нагрузками без проблем, каждую минуту начинает захлёбываться запросами и чтобы сохранить работоспособность, перестаёт на непродолжительное время вообще принимать их.

Таким образом, нет ничего удивительного в том, что мощнейшие NTP серверы перестают периодически отвечать на запросы. Для ограждения нашего сервера от подобной проблемы, был разработан модуль, который следит за периодичностью запросов, приходящих от одного клиента, и если он настроил синхронизацию по шедулеру, то модуль отказывает ему в обслуживании. Такой клиент получит время с сервера всего несколько раз, после чего будет добавлен в чёрный список на несколько суток. Количество запросов от таких клиентов выделено красным на верхнем графике. Им приходится отказывать в обслуживании запроса дабы сохранить работоспособность сервера. Они, в свою очередь, переставая получать время с сервера, не пытаются найти информацию на сайте компании о причинах, а ищут другой сервер и начинают "валить" уже его.

За несколько лет поддержки публичного NTP сервера, я могу уверенно сказать, что самый большой процент администраторов, настраивающих синхронизацию по шедулеру с интервалом в один час, руководствуется принципом "ну раз в час - совсем редко, сервер справится". Со стороны сервера пики нагрузки, приходящиеся на 00 минут 00 секунд достигают 30-ти кратной величины от штатных нагрузок. Десятки тысяч клиентов приходят с запросами точного времени. И если тысяча из них настроит запрос по шедулеру в начале каждого часа, то это будет обычный DDoS на сервер.

Используйте только специально разработанные средства синхронизации времени. Службу времени в Windows или ntpd в Linux. Эти службы написаны с пониманием RFC, они сами оценивают точность хода часов компьютера и подстраивают периодичность синхронизации.