В качестве ярких примеров систем, использующих очень точные и надёжные методы вычисления текущего времени, вовсе необязательно представлять себе комплексы, управляющие движением космических аппаратов или авиационных диспетчерских служб – хотя, безусловно, требования к точности часов всех элементов подобных систем находятся на высочайшем уровне. Стабильные и синхронизированные со всемирным временем часы нужны и в системах, выполняющих более простые задачи. К ним, например, можно отнести научные и производственные комплексы, осуществляющие обработку данных в режиме реального времени различными устройствами. Добавьте ещё всё, что связано с финансами – это проведение банковских транзакций, системы биллинга операторов сотовой связи и Интернет-провайдеров, осуществляющие тарификацию обслуживаемого ими трафика. Всё это – примеры систем, реализация которых невозможна без использования часов, синхронизированных и согласованных с универсальным временем. В вычислительных сетях протокол аутентификации клиентов также использует сравнение времени сервера с часами клиентов.
Развитие коммуникаций в наше время значительно упростило задачу получения точного времени. Сейчас у нас «над головой» (точнее, на орбитах вокруг Земли) находится несколько десятков спутников систем глобального позиционирования, бортовые часы которых практически являются эталонами времени. Сигналы, посылаемые ими, могут использоваться для очень точной синхронизации часов. В вычислительных сетях синхронизация обычно выполняется с серверами точного времени при помощи протокола NTP (Network Time Protocol) или его «облегчённой» разновидности - SNTP (Simple Network Time Protocol) в тех случаях, когда максимальная функциональность применения полного NTP не является необходимой.
Протокол NTP использует иерархическую систему уровней, или стратумов. Сервер NTP имеет наиболее высокий уровень (стратум 1), если он получает данные непосредственно от источника точного времени. Сервера, синхронизирующие свои часы с сервером 1-го стратума, в этой модели находятся на уровень ниже (стратум 2), и т. д. Протокол NTP, в отличие от SNTP, обеспечивает более высокую точность синхронизации, используя сложные алгоритмы расчёта времени передачи пакетов в сети, и может осуществлять контроль ошибок и фильтрацию UDP-пакетов.
В общих чертах работает SNTP-протокол довольно просто и обычно происходит в три этапа:
- Клиент, которому необходимо получить время, отправляет UDP-пакет, содержащий SNTP-запрос на общепринятый порт 123 NTP-сервера, и переходит в режим ожидания ответа. В этом запросе он проставляет метку времени собственных часов.
- При получении запроса сервер отвечает UDP-пакетом, содержащим SNTP-сообщение, отправляя его клиенту с 123 порта. В пакете записывается полученная метка времени клиента и метка времени самого сервера.
- При получении ответа клиент может использовать отметку времени, созданную им самим при отправке запроса, для подтверждения правильности ответа, пытаясь убедиться, что он отправлен именно на запрос этого клиента (если пакет отправлен на запрос из другого источника, вероятность того, что он содержит такую же отметку времени создания, крайне низка). Затем он извлекает значение отметки времени передачи, преобразуя его в соответствии с предполагаемым временем задержки, вызванной прохождением пакета по сети, и использует результат для установки времени своих системных часов.
Форматы пакетов для обоих протоколов одинаковы, что позволяет NTP-серверу работать как с клиентами NTP, так и с клиентами SNTP.
Структура кадра NTP
Сервера NTP, как правило, имеют лишь один открытый «наружу» порт – UDP 123. В такой конфигурации администратору не приходится особо заботиться о безопасности сервера, поскольку он практически неуязвим для атак злонамеренных программ. Тем не менее, очень важно обеспечить доступность сервера 1-го стратума для клиентов, ведь иначе теряется сам смысл его эксплуатации. Основной проблемой становится количество запросов, которые в состоянии обслужить NTP-сервер. Впрочем, и сами запросы могут генерироваться по весьма любопытным причинам.
Наиболее известные случаи NTP-вандализма
В середине мая 2003 года сотрудники университета Мэдисона обнаружили стремительно возросший Интернет-трафик, который был направлен на публичные NTP-сервера университета. Трафик представлял собой запросы протокола NTP, состоящие из пакетов в 76 байт, передаваемых на 123 порт UDP. Однако эти пакеты имели необычное свойство: несмотря на то, что они исходили из различных источников, все они были отправлены с порта номер 23457.
Для защиты серверов была изменена конфигурация роутеров, блокировавшая только эту часть входящих запросов к NTP-серверам, обычные запросы продолжали нормально обслуживаться. Был заблокирован лишь весь UDP-трафик, содержащий запросы к NTP-серверу, отправленные с порта 23457 на порт 123. В тот момент персонал просто подумал, что столкнулся с атакой типа «распределённый отказ в обслуживании» (DDoS-атака, от англ. Distributed Denial of Service, отказ в обслуживании), организованной с множества случайных адресов, и остановился на этом, предполагая, что флуд затихнет в течение нескольких часов, как это обычно и бывает в случае атак низкого профессионального уровня.
Месяц спустя выяснилось, что поток входящего NTP-трафика значительно увеличился, достигнув огромных значений - 250 тысяч пакетов в секунду, с объёмом свыше 150 МБит/с. Аккуратно отменяя блокирование доступа для некоторых интерфейсов, персонал начал изучать UDP-пакеты, включая их содержимое. Они выглядели правильными запросами формата SNTP версии 1, хотя их высокая интенсивность с каждого хоста была непонятна. Например, в течение одного периода отслеживания, множество клиентов производило примерно один запрос в секунду. Это было бы крайне странным для нормально функционирующего SNTP-клиента. Приложения, использующие SNTP, лишь устанавливают собственные системные часы с необходимой точностью, так, чтобы хост имел некое достаточное представление о текущем времени.
Запрос времени каждую секунду является просто нелепым, и достаточно далёк от обычного поведения клиента NTP. Если у вас на улице случайный прохожий спрашивает время – это нормально. Но если он начнёт интересоваться временем каждый раз сразу же после того, как вы ответите, и к нему присоединится ещё какое-то количество людей? Если это будет продолжаться неделями? Стало ясно, что необходимо разбираться с причинами происходящего.
Ни один из источников запросов не находился в локальной сети комплекса зданий университета. Это означало, что для расследования причин инцидента потребуется помощь администраторов удалённых серверов. Из наиболее активных IP-адресов были выбраны два клиента, расположенных в сетях других университетов. Сетевым администраторам отослали письмо с описанием проблемы и просьбой выяснить, какие ОС и SNTP-клиенты могут быть запущены на этих хостах, и какие службы могут отправлять с них запросы, используя 23457 порт UDP.
Полученные ответы содержали сведения о том, что источником трафика являлись роутеры производства Netgear (в частности, один из них был идентифицирован как модель MR814). Теперь события начали приобретать некий смысл. Большое количество хостов, использующих один и тот же порт, могло быть объяснено встроенным SNTP-клиентом с запрограммированным номером порта. Сотрудники университета Мэдисона стали собирать информацию о продуктах Netgear, в которых была заявлена поддержка NTP. После исследования кода выяснилось, что в некоторые из них производитель просто программно «зашил» сведения о NTP-серверах. Кроме IP-адресов из диапазонов, зарезервированных для локальных сетей, в них содержались IP-адреса глобальной маршрутизации, среди которых был и публичный сервер NTP университета Мэдисона. Проблема усугублялась ещё и тем, что из указанных в коде глобальных IP-адресов реальным NTP-сервером оказался лишь университетский, а встроенный клиент роутера, не получив ответа на SNTP-запрос, начинал генерировать новые запросы каждую секунду.
Выявив, наконец, причины NTP-флуда, сотрудники университета обратились к производителю роутеров. Netgear пришлось признать свою ошибку. Выяснилось, что к тому моменту уже было продано свыше семисот тысяч подобных устройств. Несложные расчёты показывают, что потенциально они были способны генерировать трафик 426Мбит/с (700000 пакетов UDP в секунду, каждый длиной 76 байт), направленный на один и тот же NTP-сервер.
Для решения проблемы была создана группа с участием представителей университета, производителя и независимых экспертов. Были довольно быстро выпущены исправленные версии программного обеспечения для устройств, содержащих ошибки в коде. Конечно, это не решило всех проблем – ведь выпуск новой версии прошивки производителем не значит её замену всеми пользователями, большая часть которых и не подозревала о подобных проблемах. Тем не менее, университет решил продолжить обслуживание дефектных устройств Netgear, предоставляя им возможность синхронизации системных часов (связано ли это решение с суммой $375,000, которая была выплачена Netgear университету Мэдисона, как говорят, «для повышения безопасности беспроводной сети и развитие сети комплекса зданий университета», автору доподлинно неизвестно).
В том же году подобный инцидент произошел в Австралии. На этот раз его участниками стали лаборатория национальных измерений организации по научным и производственным исследованиям Австралии (Commonwealth Scientific and Research Organisation, CSIRO) и калифорнийский производитель сетевого оборудования SMC Networks. Предельная загрузка NTP-серверов CSIRO (1-й стратум, источник – цезиевые часы, иначе называемые «атомными») оценивалась в 200кБит/с. Блокирование трафика, основная часть которого приходила из-за океана, приводило к тому, что устройства SMC при отсутствии ответа от NTP-сервера начинали отсылать запросы дважды в минуту. В конце концов, CSIRO приняла решение изменить адреса своих серверов точного времени (предварительно известив об этом своих партнёров), а провайдеры просто стали блокировать запросы от источников, расположенных вне Австралии.
Последняя наиболее известная проблема подобного рода произошла в 2005 году и впервые получила название «NTP-вандализм», закрепившееся впоследствии как общий термин для обозначения случаев злоупотребления NTP-серверами. Тогда «чёрная метка» досталась датскому серверу 1-го стратума, подключенному к национальной сети Danish Internet Exchange (DIX). Сервер принадлежал одному из разработчиков FreeBSD - Полу-Хёнингу Кампу (Poul-Henning Kamp), и хотя не принадлежал государственным или научным учреждениям, существовал на некоммерческой основе. В правилах использования прямо указывалось, что использовать его для синхронизации времени могут только NTP-серверы второго стратума, расположенные на территории Дании и приложения, работа которых требует чрезвычайно точного времени.
В роли вандала выступил концерн D-Link. По оценке владельца NTP-сервера, от 75% до 90% запросов генерировались роутерами, произведёнными D-Link. Когда количество таких пакетов превысило три миллиона в день, провайдер потребовал от Кампа оплатить расходы, вызванные значительным увеличением трафика в размере DKK 54,000 (примерно $8,800 USD) в год.
Так же, как и в случае с университетом Мэдисона, Камп обратился в D-Link, надеясь на решение проблемы и возмещение своих финансовых затрат, ею вызванных. В отличие от Netgear, D-Link стала отрицать наличие проблемы вообще, в ответ обвиняя Кампа в вымогательстве. Противостояние длилось почти полгода, пока Камп не предал широкой огласке все детали инцидента. Наконец, в апреле 2006 года стороны пришли к мирному соглашению. Было заявлено, что уже существующие продукты D-Link получат авторизованный доступ к NTP-серверу Кампа, а последующие – перестанут его использовать (финансовая сторона соглашения неизвестна, но по некоторым оценкам, содержание собственных серверов времени, способных обслуживать такой трафик, обходилась бы D-Link’у около $1000 в месяц).
Технические решения
Все эти случаи заставили задуматься разработчиков сетевых протоколов над тем, какими способами, кроме применения различных политик доступа, можно избежать подобных проблем в будущем. Одним из решений стали изменения, внесённые в четвертую версию протокола NTP, появившиеся в начале 2006 года и описанные в RFC 4330. Они включают в себя расширение семантики полей пакета NTP для возможности посылки сервером специального управляющего пакета с романтичным названием «поцелуй смерти» (Kiss-o'-Death, KoD). В таком пакете заголовки заполняются специальным образом – поле дополнительной секунды содержит значение 3, поле, указывающее стратум сервера, устанавливается в 0, а идентификатор ссылки содержит 4-х байтовый код, указывающий причину его посылки (на практике пока применяется лишь код RATE - превышение частоты запросов).
Отправка такого пакета клиенту означает, что сервер обнаружил нарушение клиентом правил доступа к нему, и обслуживание клиента будет прекращено. Клиент при его получении должен прекратить отсылку запросов и попытаться, если необходимо, найти другой NTP-сервер. Если клиент не сможет обнаружить другой доступный NTP-сервер, он должен уменьшить частоту запросов к прежнему серверу в соответствии с экспоненциально убывающим алгоритмом.
В документе также представлены рекомендованные принципы, в соответствии с которыми «правильным» NTP-клиентом должны формироваться интервалы времени, определяющие частоту запросов к серверу, использоваться элементы сетевой инфраструктуры (включая DNS и DHCP). Если во встроенном коде устройства планируется указание прямых адресов NTP-серверов, настоятельно рекомендуется делать это лишь после согласования с их владельцами.
В принципе, такие нововведения вполне разумны, однако сколько-нибудь ощутимая польза от них возможна будет лишь тогда, когда подавляющее количество NTP-серверов и клиентов в глобальной сети будут полностью соответствовать требованиям четвёртой версии протокола NTP. Увы, в ближайшее время надеяться на развитие событий таким образом не приходится (к слову, одним из «следов», благодаря которым Камп пришёл к выводу, что источником атак являются роутеры производства D-Link, было использование ими всеми протокола SNTP версии 1).
В качестве технического решения, позволяющего значительно уменьшить пиковую нагрузку на сервера точного времени, можно отметить проект pool.ntp.org. Он представляет собой большой виртуальный кластер географически распределённых ntp-серверов (на момент написания статьи в него входят 1742 сервера со всех континентов). Сам проект был запущен в 2003 году, явившись плодом дискуссии о значительных затратах, необходимых для содержания и эксплуатации надёжных серверов точного времени, способных постоянно обслуживать значительное количество запросов. Идея, положенная в его основу, очень напоминает рекурсивный механизм функционирования серверов DNS. Если в качестве сервера-поставщика точного времени будет указан просто сервер вида 0.pool.ntp.org, то реальный сервер, с которым будет осуществляться синхронизация времени, будет выбираться случайным образом при каждом запросе клиента из списка серверов, входящих в пул. Однако, пользователи пула могут самостоятельно выбирать региональные сервера точного времени, уточняя континентальную зону, или даже зону конкретной страны (как правило, чем ближе сервер, тем точнее выполняется синхронизация), например - 0.ru.pool.ntp.org для России. При этом необходимо помнить, что некоторые страны не представлены в пуле, а некоторые представлены одним - двумя серверами (например, Малайзия). Использование пула осуществляется бесплатно, кроме обслуживания компаний, производящих оборудование и программные продукты, NTP-запросы которых планируется обслуживать при помощи ресурсов pool.ntp.org.
Сама идея запуска публичного сервиса синхронизации с точными часами без обеспечения его стабильности и надёжности в условиях экстремальных нагрузок вряд ли имеет какой-либо смысл. История знает немало примеров почивших NTP-серверов с заявленным 1-м стратумом, "сообщавших" время, отличающееся от реального на десятки (!) секунд, или просто ставших недоступными для запросов. Сервис, позволяющий синхронизировать часы с точным источником времени - это именно тот случай, когда понятие надёжности является таким же важным, как и точность предоставляемых данных. Вот иллюстрация реальной работы NTP-сервера Mobatime Systems:
Статистика запросов NTP-сервера Mobatime Systems
Это достаточно яркий пример NTP-вандализма - 1 апреля 2009 года было заблокировано 75 хостов, отославших более 12 миллионов запросов в сутки. Схожая интенсивность атаки продолжалась в течение 3 суток, и её природу вряд ли можно объяснить банальными ошибками в коде устройств, или их неправильным конфигурированием. Для защиты от подобных атак на NTP-сервере Mobatime используются алгоритмы фильтрации входящего трафика. Такой механизм защиты позволяет отсечь лавинообразный поток "мусора", способный привести систему к полному отказу за короткое время.
Тем не менее, подобная защита станет практически бесполезной, в случае, если объем данных в канале передачи приблизится к его пропускной способности. При такой нагрузке отправка данных легитимным, незаблокированным клиентам станет просто невозможной из-за исчерпания ресурсов каналов связи. Единственным выходом из ситуации, гарантирующим почти полное исключение случаев NTP-вандализма, пожалуй, является создание непубличного сервера точного времени с ограничением доступа. Имея в своём распоряжении надёжный источник времени (например, приёмник данных, передаваемых системой GPS), такой NTP-сервер будет являться стабильным поставщиком сервиса точного времени.