Аннотация
Распространенной задачей применения однонаправленных шлюзов является синхронизация времени сервера, находящегося в конфиденциальной информационной сети, от сервера точного времени, находящегося в небезопасной сети. Обратная задача тоже актуальна — эталонный источник времени находится в конфиденциальном сегменте сети. В обоих случаях уровень безопасности конфиденциальной сети не должен быть уменьшен вследствие данного обмена.
Для синхронизации точного времени двух хостов применяются сервисы(службы) времени, использующие NTP протокол. Все однонаправленные шлюзы семейства СТРОМ позволяют пропускать данный протокол так как он базируется на транспортном протоколе UDP.
Тем не менее , со стороны заказчиков поступают вопросы, как реализовать данную задачу. Мы связываем это со специфическими настройками данного сервиса.
В данной статье мы покажем простейший пример синхронизации времени между двумя серверами. Для однонаправленного экранирования сегментов ЛВС был использован однонаправленный шлюз СТРОМ-1000: https://www.cryptoex.ru/product/стром-1000/
В качестве однонаправленного шлюза также могут использоваться СТРОМ-1000 МО или СТРОМ-100.
Базовой ОС для серверов выбрана Ubuntu 22.04 LTS. Также проведена проверка на ОС Astra Linux 1.7
Особенности использования протокола
Протокол NTP в общем случае используется в сетях с переменной ланетнтостью и является двунаправленным, поэтому настройки сервисов по умолчанию не подходят для решения задачи. Однако в сервисах предусмотрены режимы работы широковещательной рассылки (broadcast) и групповой рассылки (multicast). В данном случае NTP пакеты рассылаются сервером источником, а хосты приемники «не задают лишних вопросов».
Следует отметить, что в случае широковещательной односторонней рассылки следует избегать плавающей латентности. Для этого рекомендуется в структуре сети между источником времени и приемником обеспечить минимальную задержку. В предельном случае это подключение источника к интерфейсу входящего трафика, а приемника и к интерфейсу исходящего трафика.
Использование NTP на win платформах не рассматривалось. В результате беглого ознакомления c документацией не удалось обнаружить возможностей настройки сервера и клиента в широковещательный режим, что исключает штатное применение на платформах данного типа без использования дополнительного ПО.
Пример реализации синхронизации времени
Стенд для экспериментальной демонстрации показан на Рис. 1
Сервер 1
Сервер 1 является источником точного времени. На схеме для простоты не показан сетевой интерфейс, связанный с сегментом, имеющим доступ в интернет. Через этот интерфейс сервер будет синхронизировать свои часы с вышестоящими NTP источниками.
Устанавливаем сервис ntp:
$ apt install -y ntp
В файле конфигурации /etc/ntp.conf указываем строку: broadcast 10.0.0.2
Перезапускаем сервис:
$ systemctl restart ntp
Проверяем трафик на сетевом интерфейсе, подключенном к однонаправленному шлюзу с помощью tcpdump или wireshark.
В нашем случае дамп показан на Рис. 2, на котором мы можем наблюдать ntp пакет и обмен по ARP протоколу между Сервер 1 и СТРОМ-1000.
СТРОМ-1000
Загружаем в изделие конфигурацию, показанную на Рис. 1
Наблюдаем на LCD индикаторе увеличивающийся счётчик пакетов.
Сервер 2
Сервер 2 синхронизирует свое время по NTP broadcast пакетам, принятым с исходящего сетевого интерфейса СТРОМ-1000.
На сервере предварительно устанавливаем сервис ntp.
Исправляем файл конфигурации /etc/ntp.conf:
1. Комментируем все активные строки, начиная «# Specify one or more NTP servers.», исключая все возможные источники времени.
2. Задаем конфигурацию работы в качестве broadcast клиента:
nic listen enp8s0
disable auth
enable bclient
broadcastdelay 0.001
Перезапускаем сервис:
$ systemctl restart ntp
Проверяем трафик на сетевом интерфейсе, подключенном к однонаправленному шлюзу с помощью tcpdump или wireshark.
В нашем случае дамп показан на Рис. 3, на котором мы можем наблюдать NTP пакет, прошедший через СТРОМ-1000.
Проверяем состояние ntp сервера:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.0.0.1 194.190.168.1 2 b 53 64 376 0.000 +0.332 0.066
Заключение
В итоге мы рассмотрели задачу синхронизации времени между хостами, разделенными однонаправленным шлюзом, и показали пример рабочей реализации.
В данной статье мы не приводим результаты эксперимента, который вы можете проверить сами на вышеуказанном стенде:
1. Остановите сервис ntp на Сервер 2.
2. Установите системные часы Сервер 2 на неправильно значение времени.
3. Запустите сервис ntp на Сервер 2.
4. Периодически контролируйте статус ntp и системное время (ntpq -p, date). Через некоторое время часы синхронизируются с часами Сервер 1. Это произойдет не быстро, потому что используется широковещательный способ синхронизации по NTP.
Версия документа 2.2 от 27.09.2024 © ООО «КриптоЭкс»