Настройка NTP сервера в Windows

Начиная с Windows 2000 все операционные системы Windows включают в себя службу времени W32Time. Эта служба предназначена для синхронизации времени в пределах организации. W32Time отвечает за работу как клиентской, так и серверной части службы времени, причем один и тот же компьютер может быть одновременно и клиентом и сервером NTP (Network Time Protocol).

По умолчанию служба времени в Windows сконфигурирована следующим образом:

• При установке операционной системы Windows запускает клиента NTP и синхронизируется с внешним источником времени;
• При добавлении компьютера в домен тип синхронизации меняется. Все клиентские компьютеры и рядовые сервера в домене используют для синхронизации времени контроллер домена, проверяющий их подлинность;
• При повышении рядового сервера до контроллера домена на нем запускается NTP-сервер, который в качестве источника времени использует контроллер с ролью PDC-эмулятор;
• PDC-эмулятор, расположенный в корневом домене леса, является основным сервером времени для всей организации. При этом сам он также синхронизируется с внешним источником времени.

Такая схема работает в большинстве случаев и не требует вмешательства. Однако структура сервиса времени в Windows может и не следовать доменной иерархии, и надежным источником времени можно назначить любой компьютер. В качестве примера я опишу настройку NTP-сервера в Windows Server 2008 R2, хотя со времен Windows 2000 процедура не особо изменилась.

Запуск NTP сервера

Сразу отмечу, что служба времени в Windows Server (начиная с 2000 и заканчивая 2012) не имеет графического интерфейса и настраивается либо из командной строки, либо путем прямой правки системного реестра. Лично мне ближе второй способ, поэтому идем в реестр.

Итак, первым делом нам надо запустить сервер NTP. Открываем ветку реестра
HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpServer.
Здесь для включения сервера NTP параметру Enabled надо установить значение 1.

Затем перезапускаем службу времени командой net stop w32time && net start w32time

После перезапуска службы NTP сервер уже активен и может обслуживать клиентов. Убедиться в этом можно с помощью команды w32tm /query /configuration. Эта команда выводит полный список параметров службы. Если раздел NtpServer содержит строку Enabled :1 , то все в порядке, сервер времени работает.

Для того, чтобы NTP-сервер мог обслуживать клиентов, не забудьте на файерволле открыть UDP порт 123 для входящего и исходящего траффика.

Основные настройки NTP сервера

NTP сервер включили, теперь надо его настроить. Открываем ветку реестра HKLM\System\CurrentControlSet\services\W32Time\Parameters. Здесь в первую очередь нас интересует параметр Type, который задает тип синхронизации. Он может принимать следующие значения:

NoSync — NTP-сервер не синхронизируется с каким либо внешним источником времени. Используются часы, встроенные в микросхему CMOS самого сервера;
NTP — NTP-сервер синхронизируется с внешними серверами времени, которые указаны в параметре реестра NtpServer;
NT5DS — NTP-сервер производит синхронизацию согласно доменной иерархии;
AllSync — NTP-сервер использует для синхронизации все доступные источники.

Значение по умолчанию для компьютера, входящего в домен — NT5DS, для отдельно стоящего компьютера — NTP.

И параметр NtpServer, в котором указываются NTP-сервера, с которыми будет синхронизировать время данный сервер. По умолчанию в этом параметре прописан NTP-сервер Microsoft (time.windows.com, 0x1), при необходимости можно добавить еще несколько NTP-серверов, введя их DNS имена или IP адреса через пробел. Список доступных серверов времени можно посмотреть например здесь.

В конце каждого имени можно добавлять флаг (напр. ,0x1) который определяет режим для синхронизации с сервером времени. Допускаются следующие значения:

0x1 – SpecialInterval, использование специального интервала опроса ;
0x2 – режим UseAsFallbackOnly;
0x4 – SymmetricActive, симметричный активный режим;
0x8 – Client, отправка запроса в клиентском режиме.

При использовании флага SpecialInterval, необходимо установленное значение интервала в ключе SpecialPollInterval. При значении флага UseAsFallbackOnly службе времени сообщается, что данный сервер будет использоваться как резервный и перед синхронизацией с ним будут выполнятся обращения к другим серверам списка. Симметричный активный режим используется NTP-серверами по умолчанию, а клиентский режим можно задействовать в случае проблем с синхронизацией. Подробнее о режимах синхронизации можно посмотреть здесь, либо не морочиться и просто ставить везде ,0x1 (как советует Microsoft).

Еще один важный параметр AnnounceFlags находится в разделе реестра HKLM\System\CurrentControlSet\services\W32Time\Config. Он отвечает за то, как о себе заявляет NTP-сервер и может принимать следующие значения:

0x0 (Not a time server) — сервер не объявляет себя через NetLogon, как источник времени. Он может отвечать на NTP запросы, но соседи не смогут распознать его, как источник времени;
0x1 (Always time server) — сервер будет всегда объявлять о себе вне зависимости от статуса;
0x2 (Automatic time server) — сервер будет объявлять о себе только, если он получает надежное время от другого соседа (NTP или NT5DS);
0x4 (Always reliable time server) — сервер будет всегда заявлять себя, как надежный источник времени;
0x8 (Automatic reliable time server) — контроллер домена автоматически объявляется надежным если он PDC-эмулятор корневого домена леса. Этот флаг позволяет главному PDC леса заявить о себе как об авторизованном источнике времени для всего леса даже при отсутствии связи с вышестоящими NTP-серверами. Ни один другой контроллер или рядовой сервер (имеющие по умолчанию флаг 0x2) не может заявить о себе, как надежном источнике времени, если он не может найти источник времени для себя.

Значение AnnounceFlags составляет сумму составляющих его флагов, например:

10=2+8 — NTP-сервер заявляет о себе как о надежном источнике времени при условии, что сам получает время из надежного источника либо является PDC корневого домена. Флаг 10 задается по умолчанию как для членов домена, так и для отдельно стоящих серверов.

5=1+4 — NTP-сервер всегда заявляет о себе как о надежном источнике времени. Например, чтобы заявить рядовой сервер (не домен-контроллер) как надежный источник времени, нужен флаг 5.

Ну и настроим интервал между обновлениями. За него отвечает уже упоминавшийся выше ключ SpecialPollInterval,находящийся в ветке реестра HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpClient. Он задается в секундах и по умолчанию его значение равно 604800, что составляет 1 неделю. Это очень много, поэтому стоит уменьшить значение SpecialPollInterval до разумного значения, скажем до 1 часа (3600).

После настройки необходимо обновить конфигурацию сервиса. Сделать это можно командой w32tm /config /update.И еще несколько команд для настройки, мониторинга и диагностики службы времени:

w32tm /monitor – при помощи этой опции можно узнать, насколько системное время данного компьютера отличается от времени на контроллере домена или других компьютерах. Например: w32tm /monitor /computers:time.nist.gov
w32tm /resync – при помощи этой команды можно заставить компьютер синхронизироваться с используемым им сервером времени.
w32tm /stripchart– показывает разницу во времени между текущим и удаленным компьютером, причем может выводить результат в графическом виде. Например, команда w32tm /stripchart /computer:time.nist.gov /samples:5 /dataonly произведет 5 сравнений с указанным источником и выведет результат в текстовом виде.

w32tm /config – это основная команда, используемая для конфигурирования службы NTP. С ее помощью можно задать список используемых серверов времени, тип синхронизации и многое другое. Например, переопределить значения по умолчанию и настроить синхронизацию времени с внешним источником, можно командой w32tm /config /syncfromflags:manual /manualpeerlist:time.nist.gov /update
w32tm /query — показывает текущие настройки службы. Например команда w32tm /query /source покажет текущий источник времени, а w32tm /query /configuration выведет все параметры службы.

Ну и на крайний случай:
w32tm /unregister — удаляет службу времени с компьютера.
w32tm /register – регистрирует службу времени на компьютере. При этом создается заново вся ветка параметров в реестре.

Туннель во времени. Выводим данные с компьютера через Network Time Protocol

Содержание статьи

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

Этот трюк могут использовать и вирусописатели — для вывода данных из зараженных систем, причем незаметно для стандартных средств защиты.

WARNING

Создание и распространение вредоносных программ карается по статье 273 УК РФ. Ни автор, ни редакция «Хакера» не несут ответственности ни за какой вред, принесенный использованием материалов этой статьи.

Что такое NTP

NTP (Network Time Protocol) — протокол, который работает поверх UDP и используется для синхронизации локальных часов с часами на сервере точного времени. При работе в интернете точность синхронизации составляет до 10 мс, а в локальных сетях — до 0,2 мс. При этом NTP нечувствителен к задержкам канала.

Актуальная версия протокола (по данным Википедии) — 4, но мы будем использовать версию 3, которой для наших целей предостаточно.

Для максимальной точности служба обновления времени постоянно должна работать в фоновом режиме, регулярно отправляя запросы на сервер точного времени, то есть генерируя довольно много трафика. Это нам на руку, так как из-за этой особенности IDS давно не обращают внимания на трафик NTP.

За синхронизацию в Windows отвечает служба W32Time, а в Linux — демон ntpd или chronyd. Также существует более простая реализация этого протокола, известная как SNTP (Simple Network Time Protocol) — простой протокол сетевого времени. Применяют его во встраиваемых системах и устройствах, которые не требуют высокой точности, как, например, системы умного дома.

Структура пакета NTP

Структура пакета NTP описана в RFC 958 (v1), 1119 (v2), 1305 (v3) и 5905 (v4). Нас интересует версия 3, как довольно распространенная и простая, хотя ты свободно можешь пользоваться версией 4, она почти не отличается.

Для прожженных программистов на C есть псевдокод:

Теперь немного о назначении этих полей.

• Leap indicator (LI), 2 бита — число, предупреждающее о секунде координации. Может быть от 0 до 3, где 0 — нет коррекции, 1 — последняя минута дня содержит 61 с, 2 — последняя минута дня содержит 59 с, 3 — неисправность сервера. При значении 3 полученным данным доверять не следует. Вместо этого нужно обратиться к другому серверу. Наш псевдосервер будет всегда возвращать 0.
• Version number (VN), 2 бита — номер версии протокола NTP (1–4). Мы поставим туда 3.
• Mode — режим работы отправителя пакета. Значение от 0 до 7, где 3 — клиент, а 4 — сервер.
• Stratum — сколько посредников между клиентом и эталонными часами (включая сам NTP-сервер). 1 — сервер берет данные непосредственно с атомных (или других точных) часов, то есть между клиентом и часами только один посредник (сам сервер); 2 — сервер берет данные с сервера со значением Stratum 1 и так далее.
• Poll — целое число, задающее интервал в секундах между последовательными обращениями. Клиент может указать здесь интервал, с которым он хочет отправлять запросы на сервер, а сервер — интервал, с которым он разрешает, чтобы его опрашивали.
• Precision (точность) — число, которое сообщает точность локальных системных часов. Значение равно двоичному логарифму секунд.
• Root delay (задержка сервера) — время, за которое показания эталонных часов доходят до сервера NTP. Задается как число секунд с фиксированной запятой.
• Root dispersion — разброс показаний сервера.
• RefID (идентификатор источника) — ID часов. Если поле Stratum равно единице, то RefID — имя атомных часов (четыре символа ASCII). Если текущий сервер NTP использует показания другого сервера, то в RefID записан IP-адрес этого сервера.
• Reference — последние показания часов сервера.
• Originate — время, когда пакет был отправлен, по версии сервера.
• Receive — время получения запроса сервером.
• Transmit — время отправки ответа сервера клиенту, которое заполняет клиент.

Иллюстрация из Wikipedia

В целом процесс крайне прост и понятен, если изучить картинку. Клиент посылает запрос на сервер, запоминая, когда этот запрос был отправлен. Сервер принимает пакет, запоминает и записывает в пакет время приема, заполняет время отправки и отвечает клиенту. Клиент запоминает, когда он получил ответ, и получает нечто вроде RTT (Round-Trip Time, в простонародье — пинг) до сервера. Дальше он определяет, сколько времени понадобилось пакету, чтобы дойти от сервера обратно ему (время между запросом и ответом клиента минус время обработки пакета на сервере, деленное на два).

Чтобы получить текущее время, нужно прибавить полученную задержку канала к времени отправки ответа сервером. Вот только UDP на то и UDP, что задержки могут быть случайные и непредсказуемые, так что замеры повторяются по многу раз в день, вычисляется средняя ошибка, и локальные часы корректируются.

Ограничения на трафик по порту UDP-123

Системы обнаружения вторжений не такие глупые, какими могут показаться, так что просто пустить трафик, например, OpenVPN по 123-му порту UDP мы не сможем, по крайней мере без риска спалиться. Соответствие RFC все же проверяется. Это можно посмотреть на примере Wireshark.

Один из NTP-пакетов, пойманных Wireshark

Придется нам заставить наши пакеты соответствовать RFC. Проще всего это сделать, назначая некоторые поля по своему усмотрению. Мы можем внедрить свои данные в поля Transmit и Originate . Последнее не вполне соответствует RFC, но так глубоко проверки обычно не добираются.

Концепт

Идея проста: мы составляем собственный «заряженный» пакет NTP и пытаемся синхронизировать время со своим сервером. Чтобы не привлекать лишнего внимания к своей передаче, на каждый запрос должен отправляться внешне валидный ответ, в котором могут быть инструкции для клиента (читай: бота).

Чтобы всякие там системы предотвращения утечек (DLP) не мешали нам, можно, например, поксорить наши данные со статическим ключом. Естественно, в рамках PoC я не буду этого делать, но в качестве простейшего способа сокрытия данных должно сработать.

Для передачи данных с клиента на сервер подходят поля Poll , Originate и Transmit . Из них Poll пригоден ограниченно, но мы на этом останавливаться не будем. Если ты задумаешь учесть его ограничение, то имей в виду, что использовать в этом поле можно только младшие три бита (как я понял из документации). Без учета этого мы можем использовать 17 байт из 48 (35% всего объема пакета) на отправку данных, что уже неплохо.

А что на прием? Сервер заполняет поля Precision , Root delay , Root dispersion , Reference , RefID , Receive и, ограниченно, Poll . На ответ сервера в этом поле распространяются такие же ограничения, как на клиента. Итого имеем 29 (28 без Poll ) байт из 48 (60% пакета). Полезный объем пакета — 46 из 48 байт (96%). Оставшиеся два байта — флаги и заголовки, которые мы менять не можем без вреда для скрытности.

Реализация

Писать код и дебажить наше творение мы будем в Visual Studio. Я использую версию 2019 Community, благо она бесплатная, а скачать ее можно с сайта Microsoft.

Сервер

Как только IDE установлена, включена темная тема и любимый плей-лист, можно приступать. Для начала создадим новый проект типа «консольное приложение» (мы ведь не прячемся от юзера) с названием NtpTun_SERVER .

Создание проекта

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

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

Уже из этого кода видно, что мы будем притворяться сервером Stratum 3. Если бы мы были Stratum 1, то нужно было бы в поле RefID указывать ID атомных часов, которых у нас нет. А список серверов первого уровня общеизвестен, и, если IP нашего псевдосервера не окажется в таких публичных списках, обман быстро будет раскрыт.

Stratum 2 не следует использовать, потому что тогда RefID должен был бы содержать IP сервера первого уровня, список которых опять же известен. А вот третий уровень позволяет указывать в RefID IP сервера второго уровня, полного списка которых нет. То есть мы сможем в RefID передавать еще четыре байта произвольных данных.

Код методов упаковки и распаковки на скриншот не поместился, к тому же нам надо разобрать его отдельно. Вот он:

Тут никаких сложностей: принимаем массив байтов и при помощи BitConverter получаем оттуда данные.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее