Почему NTP требует двунаправленного доступа брандмауэра к порту UDP 123

Почему NTP требует двунаправленного доступа брандмауэра к порту UDP 123?

. ntpd требует полного двунаправленного доступа к привилегированному UDP-порту 123. .

У меня вопрос, почему? Для тех, кто не знаком с NTP, это выглядит как потенциальная дыра в безопасности, особенно когда я прошу моего клиента открыть этот порт в своем брандмауэре, чтобы мои серверы могли синхронизировать свое время. У кого-нибудь есть достойное оправдание, которое я могу дать своему клиенту, чтобы убедить его, что мне нужен этот доступ в брандмауэре? Помощь приветствуется! 🙂

Разрешить входящий трафик для портов NTP необходимо только в том случае, если вы действуете как сервер, позволяющий клиентам синхронизироваться с вами.

В противном случае наличие состояния NTP автоматически определит, заблокирован ли входящий пакет NTP или разрешен существующим состоянием брандмауэра, которое мы инициировали.

iptables -A OUTPUT -p udp —sport 123 —dport 123 -j ПРИНЯТЬ

iptables -A INPUT -m состояние — УСТАНОВЛЕНО, СОПУТСТВУЕТ -j ПРИНЯТЬ

Пожалуйста, дайте мне знать, если правила iptables являются правильными. У меня нет опыта работы с iptables. Мой NTP-клиент синхронизируется на моем маршрутизаторе pfSense с использованием только правила исходящего разрешения, потому что pfSense — это межсетевой экран с отслеживанием состояния.

NTP требует двунаправленного доступа через порт 123, потому что в NTP RFC указывается следующее относительно исходного порта клиента:

При работе в симметричных режимах (1 и 2) это поле должно содержать номер порта NTP PORT (123), назначенный IANA.

Поскольку исходный порт клиента — 123, когда сервер отправляет ответ обратно, он отправляет его на порт 123. Естественно, чтобы иметь возможность получить этот ответ, клиент должен разрешить входящие ответы на порт 123. Обычно ответы возвращаются на некотором эфемерном диапазоне портов .

В качестве упоминал Бен Кук , это требуется только при работе с брандмауэром без сохранения состояния, так как брандмауэр с состоянием позволяет получить ответ без явного правила.

Я думаю, что лучшим решением является включение порта 123 для входа, только для IP-адресов, которые, как ожидается, дадут вашему серверу сигнал ntp.
Внутри конфигурационного файла ntp, /etc/ntp.conf, есть адреса нескольких серверов ntp, на которые должен указывать ваш сервер. Вы можете использовать команду lookup, чтобы найти соответствующий ip для каждого адреса.

host -t a 0.debian.pool.ntp.org

Затем вы можете добавить правило в брандмауэр сервера:

iptables -I INPUT -p udp -s 94.177.187.22 -j ACCEPT

. и так далее.
Это может помешать любому злоумышленнику повредить ваш сервер.
Я думаю, что бесполезно ограничивать вывод.

Связь ntp-сервер с портом источника и назначения 123. Наиболее удобно явно разрешить это, по крайней мере, хостам, на которых вы запускаете службу ntp.

Вы могли бы рассмотреть только выставление внешнего хоста в Интернет, чтобы получить время из внешних источников. Внутренняя служба ntp, синхронизирующаяся с этим, может быть источником для всех устройств. Если эти хосты предназначены для этой цели, возможное воздействие ограничено: они принимают только трафик ntp и не хранят другие данные.

Альтернативно, вообще не используйте внешнюю IP-сеть. Например, используйте источник радио, например, GPS.

Как проверить, готов ли порт 123 к синхронизации времени?

Я собираюсь сделать синхронизацию времени для своего сервера.

Попробовал portqry на сервер времени с приведенными ниже результатами:

C:PortQryV2>portqry -n «time server» -e 123 -p оба

Вызывается целевая система запроса:

«time server»

Попытка преобразовать адрес IP в имя.

Не удалось разрешить IP address to name

запрос.

TCP порт 123 (неизвестная служба): не прослушивается

UDP порт 123 (служба ntp): LISTENING или FILTERED

UDP порт 123 (служба ntp): LISTENING или FILTERED

Я не уверен, доступен ли порт для синхронизации времени или нет. Но наша команда подтвердила, что никакой брандмауэр не должен блокировать это.

Он не показывает «LISTENING», потому что это порт UDP?

2 ответа

• как проверить, установлен ли принтер и готов ли он к работе с помощью C#?

Как программно проверить, установлен ли принтер или нет (а если он есть, то как проверить, включен ли он и готов ли к использованию?) в C# с помощью .NET 3.5 и Visual Studio 2008? Заранее спасибо,

Я отправил код данных (ZPL) по TCP/IP — SOCKET. Я хотел бы проверить состояние принтера zebra, если принтер zebra подключен к сети и готов. Я погуглил его, но не нашел решения. Я знаю статический адрес IP принтера zebra, а также порт.

ПРОСЛУШИВАНИЕ или FILTERED просто означает, что Portqry не получает ответа от указанного порта. Проблема должна быть в

Не удалось разрешить IP адрес в имя

разрешите имя хоста и повторите попытку.

Я попробовал PC, который не будет делать time syn. Он может разрешить имя хоста, но получил тот же результат для запроса UDP:

C:PortQryV2>portqry -n «IP Address» -e 123 -p оба

Запрос целевой системы называется:

«IP Address»

Попытка преобразовать адрес IP в имя.

IP адрес разрешен на xxx.corp.com

спрашиваю.

TCP порт 123 (неизвестная служба): НЕ ПРОСЛУШИВАЕТСЯ

UDP порт 123 (служба ntp): LISTENING или FILTERED

Похожие вопросы:

Создание приложения windows для проверки подключения к нескольким серверам. Как можно проверить, существует ли соединение с указанным портом на удаленном ip? Существует ли какая-либо встроенная.

У меня есть сторонняя библиотека, которая действует как сервер HTTP. Я передаю ему адрес и порт, которые он затем использует для прослушивания входящих соединений. Эта библиотека слушает таким.

Как проверить, готов ли документ (все js-файлы загружены, DOM готов) через jQuery? Там есть какой-нибудь флаг? Возникают проблемы, если некоторые файлы не загружаются полностью, и событие вызывается.

Как программно проверить, установлен ли принтер или нет (а если он есть, то как проверить, включен ли он и готов ли к использованию?) в C# с помощью .NET 3.5 и Visual Studio 2008? Заранее спасибо,

Я отправил код данных (ZPL) по TCP/IP — SOCKET. Я хотел бы проверить состояние принтера zebra, если принтер zebra подключен к сети и готов. Я погуглил его, но не нашел решения. Я знаю статический.

В новой ветви 0.5.1 есть официальный Windows исполняемый файл Node.js. Версия Linux Node.js использует установленные библиотеки, такие как v8, libev, libeio. Поскольку libev и libeio предназначены.

Следуя этому руководству , мне удалось настроить адаптер синхронизации для синхронизации данных между приложением Android и веб-сервером. Я вижу, что синхронизация работает, когда я заставляю.

У меня есть Cassandra, работающий в Docker, и я хочу запустить сценарий CQL, когда база данных будет готова. Я попытался проверить порт, чтобы определить, когда он готов : while ! nc -z localhost.

В моем приложении нужно проверить, открыт порт или нет. Вот ссылка на эту ссылку iOS SDK: как я могу проверить, открыт ли порт? Но ДНТ получит любое решение. А также обратитесь к этим двум github.

Я хотел бы сделать следующее: запустите контейнер docker когда 1-й процесс будет завершен, запустите второй контейнер когда 2-й будет закончен, запустите 3-й Я создал скрипт bash для запуска.

Как синхронизация времени стала безопасной

Как сделать так, чтобы время per se не врало, если у вас есть миллион больших и малых устройств, взаимодействующих по TCP/IP? Ведь на каждом из них есть часы, а время должно быть верным на всех. Эту проблему без ntp невозможно обойти.

Представим себе на одну минуту, что в одном сегменте промышленной ИТ инфраструктуры возникли трудности с синхронизацией сервисов по времени. Немедленно начинает сбоить кластерный стек Enterprise ПО, распадаются домены, мастера и Standby узлы безуспешно стремятся восстановить status quo.

Возможна также ситуация, когда злоумышленник намеренно старается сбить время через MiTM, или DDOS атаку. В такой ситуации может произойти все что угодно:

• истечет срок действия паролей учетных записей пользователей;
• истечет срок действия X.509 сертификатов;
• двухфакторная аутентификация TOTP перестанет работать;
• бэкапы «устареют» и система удалит их;
• сломается DNSSec.

Сломать NTP за 25 минут

Сетевые протоколы — милленниалы имеют одну особенность, они давно устарели и никуда уже не годятся, но заменить их не так-то легко даже тогда, когда набирается критическая масса энтузиастов и финансирования.

Основная претензия к классическому NTP в отсутствии надежных механизмов защиты от атак злоумышленников. Предпринимались разнообразные попытки решить эту проблему. Для этого сначала внедрили механизм заранее установленных ключей (PSK) для обмена симметричными ключами.

К сожалению этот способ себя не оправдал в виду простой причины — он плохо масштабируется. Нужна ручная настройка на стороне клиента в зависимости от сервера. Это значит, что вот так вот просто нельзя добавить еще одного клиента. Если на сервере NTP что-то меняется, надо перенастраивать все клиенты.

Тогда придумали AutoKey, но сразу же в нем обнаружили ряд серьезных уязвимостей в самом дизайне алгоритма и от него пришлось отказаться. Все дело в том, что начальное число (seed) содержит всего лишь 32-бита, оно слишком мало и не содержит достаточно вычислительной сложности для лобовой атаки.

• Key ID — симметричный 32-битный ключ;
• MAC (message authentication code) — контрольная сумма NTP пакета;

Где H() — криптографическая хэш функция.

Для расчета контрольной суммы пакеты используется та же функция.

Так получается, что вся целостность проверок пакетов держится на аутентичности кукис. Завладев ими, можно восстановить autokey и затем подделать MAC. Однако сервер NTP при их генерации использует начальное число (seed). Именно тут кроется подвох.

Функция MSB_32 отрезает от результата вычисления md5 хэша 32 старших бита. Клиентский куки не меняется до тех пор, пока параметры сервера неизменны. Дальше злоумышленнику остается лишь восстановить начальное число и получить возможность самостоятельно генерить куки.

Для начала следует подключиться к серверу NTP в качестве клиента и получить куки. После этого методом перебора злоумышленник восстанавливает начальное число следуя простому алгоритму.

Алгоритм атаки на вычисление начального числа методом перебора.

IP адреса известны, так что остается лишь создать 2^32 хэша до тех пор пока созданный куки не совпадет с тем, что получен от NTP сервера. На обычной домашней станции с Intel Core i5 на это уйдет 25 мин.

NTS — новый Autokey

Мириться с такими дырами в безопасности Autokey было невозможно и в 2012 г. появилась новая версия протокола. В целях скомпрометированного названия решили провести ребрендинг, так Autokey v.2 окрестили Network Time Security.

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

NTS соединение состоит из двух этапов, в которых используются протоколы нижнего уровня. На первом этапе клиент и сервер договариваются о различных параметрах соединения и обмениваются куки, содержащими ключи со всем сопутствующим набором данных. На втором этапе происходит собственно защищенный NTS сеанс между клиентом и сервером NTP.

NTS состоит из двух протоколов нижнего уровня: Network Time Security Key Exchange (NTS-KE), инициализация безопасного соединения поверх TLS, и NTPv4 — последней инкарнации протокола NTP. Чуть подробнее об этом ниже.

Первый этап — NTS KE

На данном этапе NTP клиент инициирует TLS 1.2/1.3 сеанс по отдельному TCP соединению с сервером NTS KE. Во время этой сессии происходит следующее.

• Стороны определяют параметры AEAD алгоритма для второго этапа.
• Стороны определяют второй протокол нижнего уровня, но на данный момент лишь NTPv4поддерживается.
• Стороны определяют IP адрес и порт NTP сервера.
• NTS KE сервер выдает куки под NTPv4.
• Стороны извлекают из материала куки пару симметричных ключей (C2S и S2C).

Второй этап — NTP под защитой NTS

На втором этапе клиент безопасно синхронизирует время с NTP сервером. Для этой цели он передает четыре специальных расширения (extension field) в структуре NTPv4 пакета.

• Unique Identifier Extension содержит случайный nonce для предотвращения атак путем повтора.
• NTS Cookie Extension содержит один из имеющихся в наличие у клиента NTP куки. Поскольку только клиент располагает симметричными AAED ключами C2S и S2C, сервер NTP должен извлечь их из материала куки.
• NTS Cookie Placeholder Extension способ для клиента запросить дополнительные куки с сервера. Это расширение необходимо, чтобы ответ сервера NTP не был намного длиннее, чем запрос. Это позволяет предотвратить атаки усиления.
• NTS Authenticator and Encrypted Extension Fields Extension содержит шифр алгоритма AAED с C2S ключем, заголовком NTP, временными отметками, и упомянутыми выше EF в качестве сопутствующих данных. Без этого расширения возможно подделать временные отметки.

Получив запрос от клиента, сервер проверяет подлинность NTP пакета. Для этого он должен расшифровать куки, извлечь алгоритм AAED и ключи. После успешной проверки NTP пакета на валидность сервер отвечает клиенту в следующем формате.

• Unique Identifier Extension зеркальная копия клиентского запроса, мера против атак путем повтора.
• NTS Cookie Extension больше куки для продолжения сеанса.
• NTS Authenticator and Encrypted Extension Fields Extension содержит шифр AEAD с S2C ключем.

NTPSec

В чем особенность NTP? Несмотря на то, что автор проекта Dave Mills старался как можно лучше документировать свой код, редкий программист сумеет разобраться в хитросплетениях алгоритмов синхронизации времени 35-детней давности. Часть кода написана до эпохи POSIX, а Unix API тогда сильно отличался от того, что используется в наши дни. Кроме того, нужны знания по статистике, чтобы очистить сигнала от помех на шумных линиях.

NTS была не первой попыткой починить NTP. После того, как злоумышленники научились использовать уязвимости NTP для усиления DDoS атак, стало ясно, что нужны радикальные перемены. И пока готовились и доводились до ума черновики NTS, National Science Foundation США в конце 2014 г. срочно выделил грант на модернизацию NTP.

Рабочую группу возглавил не абы кто, а Эрик Стивен Реймонд — один из основателей и столпов сообщества Open Source и автор книги Собор и Базар. Первым делом Эрик со товарищи попробовали перенести код NTP из платформы BitKeeper на git, но не тут-то было. Лидер проекта Harlan Stenn был против этого решения и переговоры зашли в тупик. Тогда было решено форкнуть код проекта, так возник NTPSec.

Солидный опыт, в том числе работа над GPSD, математический бэкграунд и магический навык чтения древнего кода — Эрик Реймонд был именно тем хакером, который мог вытащить такой проект. В команде нашелся специалист по миграции кода и всего за 10 недель NTP обосновалсяна GitLab-е. Работа закипела.

Команда Эрика Раймонда взялась за дело так же, как Огюст Роден при работе с глыбой камня. Удалив 175 KLOC старого кода, им удалось значительно сократить площадь атаки, закрыв множество дыр безопасности.

Вот неполный список попавших под раздачу:

• Недокументированные, устаревшие, устаревшие или сломанные refclock.
• Неиспользуемая библиотека ICS.
• libopts/autogen.
• Старый код для Windows.
• ntpdc.
• Autokey.
• C код ntpq переписан на Python.
• C код sntp/ntpdig переписан на Python.

• Значительно усилена защита кода от переполнения буфера. Чтобы предотвратить переполнение буфера, все небезопасные строковые функции (strcpy / strcat / strtok / sprintf / vsprintf / gets) заменили безопасными версиями, которые реализуют ограничение размера буфера.
• Добавлена поддержка NTS.
• Десятикратно повысили точность временного шага с помощью привязки физического оборудования. Это связано с тем, что современные компьютерные часы стали гораздо точнее тех, что были в момент зарождения NTP. Больше всех от этого выиграли GPSDO и выделенные радиостанции времени.
• Количество языков программирования сократилось до двух. Вместо скриптов Perl, awk и даже S, теперь сплошной Python. За счет этого больше возможностей повторного использования кода.
• Вместо лапши скриптов autotools проект стал использовать систему сборки программного обеспечения waf.
• Обновили и реорганизовали документацию проекта. Из противоречивой, и местами архаичной коллекции документов создали вполне сносную документацию. Каждый ключ командной строки и каждая сущность конфигурации теперь имеют единую версию правды. Кроме того, страницы руководства и веб документация теперь создаются из одних и тех же основных файлов.

Chrony

Была еще одна попытка заменить старый NTP более безопасный аналог. Chrony в отличие от NTPSec написан с нуля и предназначен для надежной работы в широком диапазоне условий, включая нестабильные сетевые соединения, частичная доступность или перегрузки сети и изменения температуры. Кроме того chrony обладает и другими преимуществами:

• chrony может быстрее синхронизировать системные часы с большей точностью;
• chrony меньше, потребляет меньше памяти и обращается к процессору только тогда, когда это необходимо. Для экономии ресурсов и энергии это большой плюc;
• chrony поддерживает метки времени на аппаратном уровне в Linux, что обеспечивает чрезвычайно точную синхронизацию в локальных сетях.

Для отключения функциональности сервера и NTP запросов к процессу chronyd достаточно прописать port 0 в файл chrony.conf. Это делается в тех случаях, когда нет нужды обслуживать время для NTP клиентов или одноранговых узлов. Начиная с версии 2.0, порт сервера NTP открыт только в тех случаях, когда доступ разрешен директивой allow или соответствующей командой, либо же настроен одноранговый узел NTP, или используется директива broadcast.

Программа состоит из двух модулей.

• chronyd — сервис, работающий в фоновом режиме. Он получает информацию о разнице системных часов с внешним сервером времени и корректирует локальное время. Он также реализует протокол NTP и может выступать в качестве клиента или сервера.
• chronyc — утилита командной строки для мониторинга и контроля программы. Используется для тонкой настройки различных параметров сервиса, например позволяет добавлять или удалять серверы NTP в то время, как chronyd продолжает работать.

Как настроить собственный удаленный сервер chrony в интернете для синхронизации времени в офисной сети. Далее пример настройки на VPS.

Пример настройки Chrony на RHEL / CentOS на VPS

Давайте теперь немного потренируемся и поднимем свой собственный NTP сервер на VPS. Это очень просто, достаточно выбрать подходящий тариф на сайте RuVDS, получить готовый сервер и набрать с десяток несложных команд. Для наших целей вполне подойдет такой вариант.

Переходим к настройке сервиса и первым делом ставим пакет chrony.

RHEL 8 / CentOS 8 используют другой пакетный менеджер.

После установки chrony нужно запустить и активировать сервис.

При желании можно внести правки в /etc/chrony.conf, заменив сервера NPT на ближайшие локальные для сокращения времени отклика.

Далее настраиваем синхронизацию NTP сервера с узлами из указанного пула.

Необходимо также открыть наружу NTP порт, иначе межсетевой экран будет блокировать входящие соединения от клиентских узлов.

На стороне клиента достаточно правильно выставить часовой пояс.

В файле /etc/chrony.conf указывает IP или название хоста нашего VPS сервера, на котором запущен NTP server chrony.

И наконец запуск синхронизации времени на клиенте.

В следующий раз расскажу, какие есть варианты синхронизации времени без интернета.

Универсальное компактное устройство синхронизации – NTP-сервер «УКУС-ПИ 02ДМ»

Универсальное компактное устройство синхронизации «УКУС-ПИ» является аппаратурой единого точного времени, обеспечивающей:

• формирование сигналов точного времени для временной синхронизации различного оборудования и систем;
• выполнение функций сервера 1-го уровня (Stratum 1) протокола сетевого времени NTP (Network Time Protocol) в сетях IP.

Электропитание устройства осуществляется от нерезервированного источника AC 220В / DC 60В / DC 24В / DC 12В. Энергопотребление не превышает 5 Вт.

Обслуживание устройства максимально упрощено. Первоначальное программирование и настройки устройства могут быть сделаны с использованием программного обеспечения «Система технического обслуживания», подключаемого к УКУС-ПИ 02ДМ через имеющиеся порты Ethernet, или через порт USB.

Во время эксплуатации текущее состояние устройства полностью контролируется с помощью 4-х многоцветных светодиодных индикатора. Более детальную информацию можно получать с использованием программного обеспечения «Система технического обслуживания».

Конструкция NTP-сервера

Конструктивно NTP-сервер выполнен в металлическом корпусе размерами (ВхШхГ) 90х145х40 мм, с элементами для установки на DIN рейку или крепление на стену. Возможна установка устройства на столе. Внешний вид устройства изображен на рисунке.

На устройстве расположены:

1. Два порта Ethernet 10/100 Base-T.
2. Выход сигнала 1PPS.
3. Порт RS-232.
4. Разъём антенны модуля ГЛОНАСС/GPS.
5. Разъём питания.
6. Разъем USB для управления устройством.
7. Светодиодные индикаторы для отображения текущего состояния устройства.

Технические характеристики NTP-сервера

Условия эксплуатации

Устройство предназначено для установки и эксплуатации в помещениях со следующими условиями окружающей среды: