WikiDer > Неправильное использование и злоупотребление сервером NTP

NTP server misuse and abuse

Неправильное использование и злоупотребление сервером NTP охватывает ряд действий, которые вызывают повреждение или деградацию Сетевой протокол времени (NTP), начиная от переполнения его трафиком (фактически DDoS атака) или нарушение политики доступа к серверу или NTP Правила участия. Один инцидент был заклеймен NTP вандализм в Открой письмо из Поул-Хеннинг Камп к маршрутизатор производитель D-Link в 2006 году.[1] Позже этот термин был расширен другими, чтобы задним числом включить другие инциденты. Однако нет никаких доказательств того, что какая-либо из этих проблем является преднамеренным вандализмом. Чаще всего они вызваны недальновидностью или неудачно выбранными конфигурациями по умолчанию.

А умышленная форма злоупотребления сервером NTP стало известно в конце 2013 года, когда NTP-серверы использовались как часть Усиление атак типа "отказ в обслуживании". Некоторые серверы NTP будут отвечать на один пакет запроса UDP «monlist» с пакетами, описывающими до 600 ассоциаций. Используя запрос с поддельный IP-адрес злоумышленники могут направить усиленный поток пакетов в сеть. Это привело к одной из крупнейших распределенных атак типа «отказ в обслуживании», известных в то время.[2]

Общие проблемы клиента NTP

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

Одна из наиболее распространенных программных ошибок NTP - генерировать пакеты запросов с короткими (менее пяти секунд) интервалами до получения ответа.

  • При размещении позади агрессивных брандмауэры которые блокируют ответы сервера, эта реализация ведет к нескончаемому потоку клиентских запросов к различным заблокированным серверам NTP.
  • Такие чрезмерно нетерпеливые клиенты (особенно те, которые опрашивают один раз в секунду) обычно составляют более 50% трафика общедоступных серверов NTP, несмотря на то, что они составляют незначительную часть от общего числа клиентов.

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

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

Известные случаи

Тардис и Тринити-колледж, Дублин

В октябре 2002 г. один из первых известных случаев неправильного использования сервера времени привел к проблемам с веб-сервером на Тринити-колледж, Дублин. В конечном итоге трафик был связан с некорректными копиями программы под названием Tardis.[3] тысячи копий по всему миру связываются с веб-сервером и получают метку времени через HTTP. В конечном итоге решение заключалось в изменении конфигурации веб-сервера, чтобы предоставить настроенную версию домашней страницы (значительно уменьшенную в размере) и вернуть фиктивное значение времени, из-за чего большинство клиентов выбирали другой сервер времени.[4] Позднее была выпущена обновленная версия Tardis, чтобы исправить эту проблему.[нужна цитата]

Netgear и Университет Висконсин-Мэдисон

Первый широко известный случай проблем с NTP-сервером начался в мае 2003 года, когда Netgearаппаратные продукты наводнили Университет Висконсина-Мэдисонас NTP сервер с просьбами.[5] Сотрудники университета изначально предположили, что это злонамеренный Распределенный отказ в обслуживании атаковали и предприняли действия, чтобы заблокировать наводнение на границе своей сети. Вместо того, чтобы ослабить (как это делают большинство DDOS-атак), поток увеличился, достигнув к июню 250 000 пакетов в секунду (150 мегабит в секунду). Последующее расследование показало, что источником проблемы были четыре модели маршрутизаторов Netgear. Было обнаружено, что клиент SNTP (Simple NTP) в маршрутизаторах имеет два серьезных недостатка. Во-первых, он полагается на единственный сервер NTP (в Университете Висконсин-Мэдисон), чей IP-адрес был жестко закодирован во встроенном ПО. Во-вторых, он опрашивает сервер с интервалом в одну секунду, пока не получит ответ. Всего было произведено 707 147 продуктов с неисправным клиентом.

Netgear выпустила обновления прошивки для затронутых продуктов (DG814, ​​HR314, MR814 и RP614), которые опрашивают собственные серверы Netgear, опрашивают только раз в десять минут и прекращают работу после пяти сбоев. Хотя это обновление устраняет недостатки исходного клиента SNTP, оно не решает более серьезной проблемы. Большинство потребителей никогда не обновят прошивку своего маршрутизатора, особенно если кажется, что устройство работает нормально. Сервер NTP Университета Висконсина-Мэдисона продолжает получать высокий уровень трафика от маршрутизаторов Netgear со случайными лавинными потоками до 100 000 пакетов в секунду.[нужна цитата] Netgear пожертвовала 375 000 долларов отделу информационных технологий Университета Висконсина в Мэдисоне за помощь в выявлении недостатка.[нужна цитата]

SMC и CSIRO

Также в 2003 году другой случай вынудил NTP-серверы Австралийский Организация Содружества научных и промышленных исследований (CSIRO) Национальная измерительная лаборатория закрыта для общественности.[6] Было показано, что трафик идет из плохого NTP реализация в некоторых SMC модели маршрутизаторов, в которых IP-адрес сервера CSIRO был встроен в прошивку. SMC выпустила обновления прошивки для своих продуктов: известно, что это касается моделей 7004VBR и 7004VWBR.

D-Link и Пол-Хеннинг Камп

В 2005 году Поул-Хеннинг Камп, менеджер единственного Датский NTP-сервер Stratum 1, доступный для широкой публики, наблюдал огромный рост трафика и обнаружил, что от 75 до 90% исходило от маршрутизаторов D-Link. Серверы NTP уровня 1 получают сигнал времени от точного внешнего источника, такого как приемник GPS, радиочасы или откалиброванные атомные часы. По соглашению, серверы времени Stratum 1 должны использоваться только приложениями, требующими чрезвычайно точного измерения времени, такими как научные приложения или серверы Stratum 2 с большим количеством клиентов.[7] Маршрутизатор домашней сети не соответствует ни одному из этих критериев. Кроме того, политика доступа к серверу Кампа явно ограничивала его серверами, напрямую подключенными к Датский интернет-обмен (DIX). Прямое использование этого и других серверов Stratum 1 маршрутизаторами D-Link привело к огромному росту трафика, увеличению затрат на полосу пропускания и нагрузке на сервер.

Во многих странах официальные услуги хронометража предоставляются государственным агентством (например, NIST в США.). Поскольку не существует датского эквивалента, Камп обеспечивает свое время "pro bono publicoВ свою очередь, DIX согласился предоставить бесплатное соединение для своего сервера времени, предполагая, что задействованная полоса пропускания будет относительно низкой, учитывая ограниченное количество серверов и потенциальных клиентов. Ввиду увеличения трафика, вызванного маршрутизаторами D-Link, DIX потребовала от него уплаты ежегодной платы за подключение в размере 54,000 DKK[нужна цитата] (примерно 9 920 долларов США или же €7,230[8][9]).

Камп связался с D-Link в ноябре 2005 года, надеясь заставить их решить проблему и компенсировать ему время и деньги, которые он потратил на отслеживание проблемы, а также расходы на пропускную способность, вызванные продуктами D-Link. Компания отрицала наличие каких-либо проблем, обвинила его в вымогательстве и предложила компенсацию, которая, по утверждению Кампа, не покрывала его расходы. 7 апреля 2006 года Камп разместил эту историю на своем сайте.[10] История была подхвачена Slashdot, Reddit и другие новостные сайты. После обнародования информации Камп понял, что маршрутизаторы D-Link напрямую опрашивают другие серверы времени Stratum 1, нарушая при этом политики доступа как минимум 43 из них. 27 апреля 2006 года D-Link и Камп объявили, что они «мирно разрешили» свой спор.[11]

ИТ-провайдеры и swisstime.ethz.ch

Более 20 лет ETH Цюрих предоставил открытый доступ к серверу времени swisstime.ethz.ch для оперативной синхронизации времени. Из-за чрезмерного использования полосы пропускания, составляющего в среднем более 20 ГБ в день, возникла необходимость направить внешнее использование на общедоступные пулы серверов времени, такие как ch.pool.ntp.org. Неправильное использование, вызванное главным образом тем, что ИТ-провайдеры синхронизируют свои клиентские инфраструктуры, предъявляет необычно высокие требования к сетевому трафику, что заставляет ETH принимать эффективные меры. По состоянию на осень 2012 г., доступ к swisstime.ethz.ch изменен на закрытый. С начала июля 2013 г., доступ к серверу полностью заблокирован для протокола NTP.

Snapchat на iOS

В декабре 2016 года сообщество операторов NTPPool.org заметило значительный рост трафика NTP, начиная с 13 декабря.[12]

Исследование показало, что Snapchat приложение, работающее на iOS был склонен к запросам все Серверы NTP, которые были жестко запрограммированы в стороннюю библиотеку NTP iOS, и что запрос к домену, принадлежащему Snapchat, последовал за потоком запросов NTP.[13]После того, как с Snap Inc. связались,[14] их разработчики решили проблему в течение 24 часов после уведомления, обновив свое приложение.[15] В качестве извинений и помощи в работе с создаваемой ими нагрузкой Snap также предоставил серверы времени для пулов NTP Австралии и Южной Америки.[16]

В качестве положительного побочного эффекта используется библиотека NTP с открытым исходным кодом, а настройки по умолчанию, подверженные ошибкам, были улучшены.[17] после отзывов сообщества NTP.[18][19][требуется полная цитата]

Тестирование подключения на повторителях Wi-Fi TP-Link

Прошивка для TP-Link Повторители Wi-Fi в 2016 и 2017 годах жестко запрограммированы пять серверов NTP, включая Университет Фукуока в Японии, а также в пулах серверов NTP в Австралии и Новой Зеландии и неоднократно выдавал один запрос NTP и пять DNS запросы каждые пять секунд, потребляющие 0,72 ГБ в месяц на устройство.[20] Чрезмерные запросы были неправильно использованы для проверки подключения к Интернету, которая отображала состояние подключения устройства в интерфейсе веб-администрирования.[20]

Проблема была признана филиалом TP-Link в Японии, который подтолкнул компанию к изменению дизайна теста подключения и выпуску обновлений прошивки для решения проблемы для затронутых устройств.[21] Маловероятно, что затронутые устройства установят новую прошивку, поскольку расширители WiFi от TP-Link не устанавливают обновления прошивки автоматически и не уведомляют владельца о доступности обновлений прошивки.[22] Доступность обновления прошивки TP-Link также зависит от страны, хотя проблема затрагивает все расширители диапазона WiFi, продаваемые по всему миру.[20][22]

Сообщается, что серверы Университета Фукуока отключены в период с февраля по апрель 2018 г. и должны быть удалены из списков общедоступных серверов времени NTP.[23]

Технические решения

После этих инцидентов стало ясно, что помимо определения политики доступа к серверу, необходимы технические средства обеспечения соблюдения политики. Один из таких механизмов был предоставлен путем расширения семантики Поле идентификатора ссылки в пакете NTP, когда Слоистое поле равно 0.

В январе 2006 г. RFC 4330 был опубликован, обновляя детали SNTP протокол, но также в предварительном порядке уточняют и расширяют связанный протокол NTP в некоторых областях. Разделы с 8 по 11 из RFC 4330 имеют особое отношение к этой теме (Пакет Kiss-o'-Death, О том, как быть хорошим гражданином сети, Лучшие практики, Соображения безопасности). В разделе 8 представлены пакеты Kiss-o'-Death:

В NTPv4 и SNTPv4 пакеты такого типа называются пакетами Kiss-o'-Death (KoD), а передаваемые ими сообщения ASCII называются кодами поцелуя. Пакеты KoD получили свое название, потому что раньше их использовали для указания клиентам прекратить отправку пакетов, которые нарушают контроль доступа к серверу.

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

В 2015 году из-за возможных атак на Network Protocol Time,[24] сетевое время безопасности для NTP (Интернет-проект проект-ietf-ntp-using-nts-for-ntp-19)[25] был предложен с использованием Безопасность транспортного уровня выполнение. 21 июня 2019 г. Cloudflare запустили пробную службу по всему миру,[26] на основе предыдущего Интернет-проекта.[27]

Рекомендации

  1. ^ Камп, Поул-Хеннинг (2008-04-08). «Открытое письмо D-Link об их вандализме против NTP». FreeBSD. Архивировано из оригинал на 2006-04-08. Получено 2006-04-08.
  2. ^ Галлахер, Шон (11 февраля 2014 г.). «Крупнейшая DDoS-атака, когда-либо направленная на сеть доставки контента Cloudflare». Ars Technica. В архиве из оригинала от 07.03.2014. Получено 2014-03-08.
  3. ^ «Тардис 2000». В архиве из оригинала на 2019-08-17. Получено 2019-06-13.
  4. ^ Мэлоун, Дэвид (апрель 2006 г.). «Нежелательный HTTP: у кого время?» (PDF). ;авторизоваться:. Ассоциация USENIX. В архиве (PDF) из оригинала от 28.07.2013. Получено 2012-07-24.
  5. ^ «Неисправные маршрутизаторы наводнили сервер времени в Интернете в Висконсинском университете, Netgear сотрудничает с университетом в решении проблемы». Университет Висконсина-Мэдисона. Архивировано из оригинал на 2006-04-10. Получено 2020-07-06.
  6. ^ "Сетевые устройства почти разрушают атомные часы". Taborcommunications.com. 2003-07-11. Архивировано из оригинал на 2013-02-04. Получено 2009-07-21.
  7. ^ Лестер, Энди (19 февраля 2006 г.). «Помогите спасти находящиеся под угрозой исчезновения серверы времени». O'Reilly Net. Архивировано из оригинал на 2007-08-18. Получено 2007-08-07.
  8. ^ «Конвертер валют - Google Финансы». В архиве из оригинала 31.03.2017. Получено 2016-11-11.
  9. ^ «Конвертер валют - Google Финансы». В архиве из оригинала 31.03.2017. Получено 2016-11-11.
  10. ^ Камп, Поул-Хеннинг (27 апреля 2006 г.). «Открытое письмо D-Link об их вандализме по протоколу NTP: обновление от 27 апреля 2006 г.». FreeBSD. Архивировано из оригинал на 2006-04-27. Получено 2007-08-07.
  11. ^ Лейден, Джон (11 мая 2006 г.). "D-Link улаживает спор с компьютерным фанатом времени'". Реестр. В архиве из оригинала на 2019-05-10. Получено 2020-05-26.
  12. ^ «Недавнее увеличение трафика пула NTP: 2016-12-20». Пул NTP. 2016-12-10. В архиве из оригинала от 21.12.2016. Получено 2016-12-20.
  13. ^ "Архив рассылки NANOG: Недавнее увеличение трафика пула NTP: 2016-12-19". NANOG / opendac от shaw.ca. 2016-12-19. В архиве из оригинала на 24.09.2017. Получено 2016-12-20.
  14. ^ "Архив списка рассылки NANOG: Недавнее увеличение трафика пула NTP: 2016-12-20 18:58:57". NANOG / Джад Бутрос из Snap inc. 2016-12-20. В архиве из оригинала на 2017-04-19. Получено 2017-04-19.
  15. ^ "Архив списка рассылки NANOG: Недавнее увеличение трафика пула NTP: 2016-12-20 22:37:04". NANOG / Джад Бутрос из Snap inc. 2016-12-20. В архиве из оригинала на 2017-04-20. Получено 2017-04-20.
  16. ^ "Архив списка рассылки NANOG: Недавнее увеличение трафика пула NTP: 2016-12-21 02:21:23". NANOG / Джад Бутрос из Snap inc. 2016-12-21. В архиве из оригинала на 2017-04-19. Получено 2017-04-19.
  17. ^ «Библиотека iOS NTP: переход к версии 1.1.4; git commit на github.com». GitHub. 2016-12-20. В архиве из оригинала на 2020-07-05. Получено 2017-04-19.
  18. ^ "Библиотека NTP iOS: Проблема № 47: жестко заданные имена пулов NTP; github.com". GitHub. 2016-12-19. В архиве из оригинала на 2020-07-05. Получено 2017-04-19.
  19. ^ «Журнал инцидентов пула NTP - чрезмерная нагрузка на серверы NTP». Пул NTP. 2016-12-30. В архиве из оригинала на 2017-04-19. Получено 2017-04-19.
  20. ^ а б c Александерсен, Даниэль (23.11.2017). «Прошивка репитера TP-Link растрачивает 715 МБ / месяц». Ctrl Блог. В архиве из оригинала на 20.12.2017. Получено 2017-12-21.
  21. ^ «TP-Link 製 無線 LAN 中 継 器 に よ る NTP サ ー バ ー へ の ア ク セ に 関 し て» (на японском языке). TP-Link. 2017-12-20. В архиве из оригинала на 20.12.2017. Получено 2017-12-21.
  22. ^ а б Александерсен, Даниэль (2017-11-20). «TP-Link обслуживает устаревшие прошивки или вообще не использует их на 30% своих европейских сайтов». Ctrl Блог. В архиве из оригинала от 22.12.2017. Получено 2017-12-21.
  23. ^ "大学 に お け る 公開 用 NTP サ ー ビ ス の 現状 と 課題" (pdf) (на японском языке). Университет Фукуока. В архиве (PDF) из оригинала на 2018-01-29. Получено 2018-01-29.
  24. ^ Малхотра, Анчал; Коэн, Исаак Э .; Бракке, Эрик; Гольдберг, Шарон (2015-10-21). «Атака на сетевой протокол времени» (pdf). Бостонский университет. В архиве (PDF) из оригинала на 2019-05-02. Получено 2019-06-23. Мы исследуем риск того, что сетевые злоумышленники могут использовать неаутентифицированный трафик протокола сетевого времени (NTP) для изменения времени в клиентских системах.
  25. ^ Franke, D .; Сибольд, Д .; Teichel, K .; Dansarie, M .; Сундблад, Р. (30 апреля 2019 г.). Безопасность сетевого времени для протокола сетевого времени. IETF. Идентификационный черновик-ietf-ntp-using-nts-for-ntp-19. Архивировано из оригинал (HTML) 13 июня 2019 г.. Получено 23 июн 2019.
  26. ^ Малхотра, Анчал (21.06.2019). "Представляем time.cloudflare.com". Блог Cloudflare. Архивировано из оригинал (HTML) на 2019-06-21. Получено 2019-06-23. Мы используем нашу глобальную сеть, чтобы обеспечить преимущество в задержке и точности. Все наши 180 точек по всему миру используют anycast для автоматической маршрутизации ваших пакетов на ближайший к нам сервер. Все наши серверы синхронизируются с поставщиками услуг stratum 1 time, а затем предлагают NTP для широкой публики, аналогично тому, как работают другие общедоступные поставщики NTP.
  27. ^ Franke, D .; Сибольд, Д .; Teichel, K .; Dansarie, M .; Сундблад, Р. (17 апреля 2019 г.). Безопасность сетевого времени для протокола сетевого времени. IETF. Идентификатор проекта-ietf-ntp-using-nts-for-ntp-18. Архивировано из оригинал (HTML) 15 июня 2019 г.. Получено 23 июн 2019.

внешняя ссылка