Before reading this article, it is recommended to read the previous one: Audio over Bluetooth: most detailed information about profiles, codecs, and devices / по-русски

Some wireless headphone users note low sound quality and lack of high frequencies when using the standard Bluetooth SBC codec, which is supported by all headphones and other Bluetooth audio devices. A common recommendation to get better sound quality is to buy devices and headphones with aptX or LDAC codecs support. These codecs require licensing fees, that's why devices with them are more expensive.

It turns out that the low quality of SBC is caused by artificial limitations of all current Bluetooth stacks and headphones' configuration, and this limitation can be circumvented on any existing device with software modification only.

This article is also available in Russian / Эта статья также доступна на русском языке

The mass market of smartphones without the 3.5 mm audio jack changed headphones industry, wireless Bluetooth headphones have become the main way to listen to music and communicate in headset mode for many users.
Bluetooth device manufacturers rarely disclose detailed product specifications, and Bluetooth audio articles on the Internet are contradictory and sometimes incorrect. They do not tell about all the features, and often publish the same false information.
Let's try to understand the protocol, the capabilities of Bluetooth stacks, headphones and speakers, Bluetooth codecs for music and speech, find out what affects the quality of the transmitted audio and the delay, learn how to capture and decode information about supported codecs and other device features.

TL;DR:

• SBC codec is OK
• Headphones have their own per-codec equalizer and post processing configuration
• aptX is not as good as the advertisements say
• LDAC is a marketing fluff
• Voice audio quality is still low
• Browsers are able to execute audio encoders compiled to WebAssembly from C using emscripten, and they won't even lag.

Перед прочтением этой статьи рекомендуется ознакомиться с предыдущей статьёй: Аудио через Bluetooth: максимально подробно о профилях, кодеках и устройствах / in English

Некоторые пользователи беспроводных наушников отмечают низкое качество звука и недостаток высоких частот при использовании стандартного Bluetooth-кодека SBC, который поддерживают все аудиоустройства. Частой рекомендацией для улучшения звука является покупка устройств и наушников с поддержкой кодеков aptX и LDAC. Эти кодеки требуют лицензионных отчислений, поэтому устройства с их поддержкой стоят дороже.

Оказывается, низкое качество SBC обусловлено искусственными ограничениями Bluetooth-стеков и настроек наушников, и это ограничение можно обойти на любых существующих устройствах, путём программных изменений смартфона или компьютера.

This article is also available in English

Из-за массового выпуска смартфонов без аудиоразъема 3.5 мм беспроводные Bluetooth-наушники для многих стали основным способом прослушивания музыки и общения в режиме гарнитуры.
Производители беспроводных устройств не всегда пишут подробные характеристики товара, а статьи о Bluetooth-аудио в интернете противоречивы, местами некорректны, не рассказывают о всех особенностях, и часто копируют одну и ту же не соответствующую действительности информацию.
Попробуем разобраться с протоколом, возможностями Bluetooth-стеков ОС, наушников и колонок, Bluetooth-кодеков для музыки и речи, выясним, что влияет на качество передаваемого звука и задержку, научимся собирать и декодировать информацию о поддерживаемых кодеках и других возможностях устройств.

TL;DR:

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.

TL;DR: В APPX-файл Universal Windows Platform можно упаковать обычный exe-файл, который будет запускаться в Windows 10 (сборка 1607 и новее) примерно так же, как обычные exe-файлы. Это можно использовать для атак социальной инженерии, с помощью рассылки через email — почтовые провайдеры не блокируют файлы APPX. Файл должен быть подписан действующей цифровой подписью.

Universal Windows Platform

Universal Windows Platform — (сравнительно) новый стандарт для создания универсальных приложений под Windows 10, Windows 10 Mobile, Xbox One и Hololens. Стандарт появился с выходом Windows 10, и предоставляет API с ограничением привилегий и изоляцией, формат контейнера и метаданных внутри него.
UWP-приложения широко представлены в Microsoft Store. Они самодостаточны, безопасны, не требуют прав администратора для установки, хранят настройки в строго отведённых местах, и могут быть удалены начисто, прямо из «пуска».

UWP — попытка Microsoft избавиться от старых архитектурных подходов к разработке программ: внедрить разделение привилегий так, как это сделано на мобильных платформах, уйти от WinAPI GUI с пиксельной сеткой (для полноценной поддержки экранов любой плотности пикселей).
Программы UWP можно писать на C#, C++, VB и JS, а в качестве GUI-фреймфорка предлагается к использованию XAML, DirectX и HTML.

До недавнего времени, UWP-программы могли быть только изолированными, но в сборке Windows 10 1607 Microsoft реализовала Desktop Bridge — возможность упаковки любых Win32-программ в виде UWP, без использования UWP API, ограничений привилегий и изоляции.
Эта функция открывает простор для атак социальной инженерии.

Русская версия этой статьи.
Modern PC motherboards' firmware follow UEFI specification since 2010. In 2013, a new technology called Secure Boot appeared, intended to prevent bootkits from being installed and run. Secure Boot prevents the execution of unsigned or untrusted program code (.efi programs and operating system boot loaders, additional hardware firmware like video card and network adapter OPROMs).
Secure Boot can be disabled on any retail motherboard, but a mandatory requirement for changing its state is physical presence of the user at the computer. It is necessary to enter UEFI settings when the computer boots, and only then it's possible to change Secure Boot settings.

Most motherboards include only Microsoft keys as trusted, which forces bootable software vendors to ask Microsoft to sign their bootloaders. This process include code audit procedure and justification for the need to sign their file with globally trusted key if they want the disk or USB flash to work in Secure Boot mode without adding their key on each computer manually.
Linux distributions, hypervisors, antivirus boot disks, computer recovery software authors all have to sign their bootloaders in Microsoft.

I wanted to make a bootable USB flash drive with various computer recovery software that would boot without disabling Secure Boot. Let's see how this can be achieved.

English version of this article.

Введение

Прошивки современных материнских плат компьютера работают по спецификации UEFI, и с 2013 года поддерживают технологию проверки подлинности загружаемых программ и драйверов Secure Boot, призванную защитить компьютер от буткитов. Secure Boot блокирует выполнение неподписанного или недоверенного программного кода: .efi-файлов программ и загрузчиков операционных систем, прошивок дополнительного оборудования (OPROM видеокарт, сетевых адаптеров).
Secure Boot можно отключить на любой магазинной материнской плате, но обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.

Большинство материнских плат поставляется только с ключами Microsoft в качестве доверенных, из-за чего создатели загрузочного ПО вынуждены обращаться в Microsoft за подписью загрузчиков, проходить процедуру аудита, и обосновывать необходимость глобальной подписи их файла, если они хотят, чтобы диск или флешка запускались без необходимости отключения Secure Boot или добавления их ключа вручную на каждом компьютере.
Подписывать загрузчики у Microsoft приходится разработчикам дистрибутивов Linux, гипервизоров, загрузочных дисков антивирусов и программ для восстановления компьютера.

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

TL;DR: IPFS позволяет хостить статические сайты распределённо, доступ к которым можно осуществлять через публичные кеширующие гейты (прозрачные реверс-прокси) в интернете, без необходимости устанавливать программу посетителю. Такие сайты можно раздавать без маршрутизируемого («белого») статического IP-адреса (будет работать за NAT), они остаются работоспособными при кратковременном (несколько часов) отсутствии раздающих, за счет кеша на гейтах. К гейтам по желанию можно привязать свой домен, причём добавить DNS-записи можно на несколько гейтов одновременно, для повышения надёжности и балансировки нагрузки. Сайт могут скачать другие пользователи IPFS и помочь с раздачей.
IPFS отлично подходит для статических блогов, простых сайтов, файловых архивов (в качестве замены Bittorrent), а также просто для единовременной передачи больших файлов без предварительной загрузки их на какой-либо сервис.

Что такое IPFS?

IPFS — децентрализованная пиринговая система передачи файлов, по принципу работы похожая на BitTorrent, но с возможностью доступа через HTTP, для Web. Все скачиваемые пользователем файлы временно кешируются IPFS-демоном и раздаются другим пользователям, запрашивающим их. Важные файлы можно «прикрепить» (pin) к IPFS-демону, тогда они не исчезнут из кеша.

Geektimes присоединился к некой «партнерской программе», заменяющей прямые ссылки ссылками со скриптом перенаправления.

В код HTML добавился следующий внешний скрипт:

<script src="//js.mamydirect.com/js/?h=CqwpgTi7" type="text/javascript" async></script>

Скрипт, подключенный на страницы гиктаймза, заменяет ссылки, ведущие не на файлы .jpg, .bmp, .pdf, .png, .zip и .gif, находящихся не на доменах из черного списка, ссылкой с редиректом через скрипт http://js.mamydirect.com/redir/clickGate.php, вида:

http://js.mamydirect.com/redir/clickGate.php?u=RGm1L5B5&m=1&p=8d1pun3ZhJ&t=CqwpgTi7&st=&s=&splash=0&abp=1&url=https%3A%2F%2Fmeduza.io%2Fnews%2F2017%2F06%2F09%2Fdyru-v-reestre-roskomnadzora-ispolzovali-protiv-platezhnyh-serverov-rossiyskih-bankov&r=https%3A%2F%2Fgeektimes.ru%2Fpost%2F289947%2F

Он же, в свое время, добавляет куки PHPSESSID и совершает перенаправление на URL, указанный в ссылке.

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

Начиная с 6 июня, на части DNS, обслуживающих российские доменные зоны, разрешен трансфер (AXFR), который позволяет получить полный список доменных имен зон .ru, .su, .tatar, .рф и .дети.

AXFR-запрос доступен на следующих серверах:

• a.dns.ripn.net
• b.dns.ripn.net
• d.dns.ripn.net

Все провайдеры интернета в России вынуждены блокировать ссылки, внесенные в Единый реестр запрещенных сайтов. Он представляет собой огромную свалку ссылок (в том числе не соответствующих стандартам), доменов и IP-адресов. Общей методики блокировок не существует, есть только абстрактные рекомендации от Роскомнадзора, поэтому каждый провайдер блокирует сайты по-своему, в меру понимания реестра, своей технической продвинутости и бюджета.

Подавляющее большинство провайдеров используют те или иные системы анализа трафика, чтобы блокировать конкретные URL, а не IP-адрес: аппаратные комплексы DPI, открытые DPI под Linux, прозрачные прокси-серверы. Этого вполне достаточно для блокировки ссылок в HTTP, но не все системы поддерживают анализ домена (параметра SNI) в HTTPS-трафике, из-за чего провайдерам с такими системами приходится блокировать HTTPS-ссылки реестра по IP-адресу.

Также в реестре есть сайты, внесенные по домену, без указания протокола. Некоторые провайдеры блокируют такие записи по IP-адресу, другие — только HTTP и HTTPS-протокол у этих доменов. Чтобы не покупать дорогие конфигурации DPI, которые могут анализировать весь огромный поток трафика, провайдеры пропускали через DPI только известные IP-адреса заблокированных сайтов, и обходились конфигурацией дешевле.

Преимущественно медиафайлы. На полном серьезе, без шуток.

Введение

Бывает, случается так, что вы хотите скачать альбом 2007 года исполнителя, который кроме вас известен 3.5 людям, какой-нибудь испанский ска-панк или малопопулярный спидкор европейского происхождения. Находите BitTorrent-раздачу, ставите на закачку, быстро скачиваете 14.7%, и… все. Проходит день, неделя, месяц, а процент скачанного не увеличивается. Вы ищете этот альбом в поисковике, натыкаетесь на форумы, показывающие ссылки только после регистрации и 5 написанных сообщений, регистрируетесь, флудите в мертвых темах, вам открываются ссылки на файлообменники вроде rapidshare и megaupload, которые уже сто лет как умерли.


_{Увы, частая ситуация в попытке хоть что-то скачать}

Такое случается. В последнее время, к сожалению, случается чаще: правообладатели и правоохранительные органы всерьез взялись за файлообмен; в прошлом году закрылись или были закрыты KickassTorrents, BlackCat Games, what.cd, btdigg, torrentz.eu, EX.ua, fs.to, torrents.net.ua, и еще куча других сайтов. И если поиск свежих рипов фильмов, сериалов, музыки, мультиков все еще не представляет большой проблемы, несмотря на многократно участившееся удаления со стороны правообладателей контента из поисковых систем, торрент-трекеров и файлообменников, то поиск и скачивание оригинала (DVD или Blu-Ray) фильмов и сериалов или просто ТВ-рипов 7-летней давности на не-английском и не-русском языке — не такая уж простая задача.

29 сентября Роскомнадзор, следуя решению Октябрьского районного суда г. Ставрополя от 2013 года, внес IP-адрес 93.184.220.29 в реестр запрещенных сайтов. Данное решение суда обязывает заблокировать сайты и мобильные приложения некоторых букмекерских контор, и если с блокировкой веб-сайтов все очевидно, то, по всей вероятности, с ограничением работоспособности приложений эксперты Ставропольской прокуратуры (от их имени было подано исковое заявление) сталкивались впервые, и просто задекларировали все IP-адреса, к которым обращалось приложение в момент запуска, включая адреса CRL (списка отзыва сертификатов) и серверов OCSP (сервер проверки состояния сертификатов) глобальных удостоверяющих центров, которые используются для шифрования по протоколу HTTPS.



Об этом решении суда стало известно благодаря блокировке ссылок на файлы CRL Comodo в июле этого года («Роскомнадзор заблокировал самого себя и некоторые сайты правительства (Comodo)» от BupycNet), теперь же в реестр внесен адрес, принадлежащий другому удостоверяющему центру — Digicert.

_{Если вы не видите эту картинку, то данные вашей учетной записи Windows уже скомпрометированы.}

Введение

Давным-давно, когда компьютеры были одноядерными и прекрасно работали с 256 МБ RAM, а сети под управлением Windows уже использовались очень широко, ребята из Microsoft подумали, что было бы удобно аутентифицироваться только один раз, при загрузке компьютера, а доступ на внутренние ресурсы происходил бы автоматически, без ввода пароля, и сделали так называемую технологию единого входа (Single Sign-on). Единый вход работает очень просто: когда пользователь пытается получить доступ к какому-либо ресурсу с NTLM-аутентификацией (стандартный способ аутентификации в сетях Windows), ОС сразу передает название домена, имя учетной записи и хеш пароля текущего пользователя, и если под этими данными войти не удалось, показывает диалог ввода имени пользователя и пароля. Шли годы, проблемы с безопасностью реализации технологии единого входа давали о себе знать, одни из которых успешно исправляли, другие исправляли менее успешно, а о третьих почему-то совсем забыли. Так и забыли о проблеме передачи учетных данных для единого входа на SMB-ресурсы (сетевые ресурсы: файлы и папки, принтеры, и т.д.) через интернет, которую можно эксплуатировать во всех современных ОС, включая Windows 10 со всеми последними обновлениями. Об этой особенности работы стека аутентификации вспоминают каждые 1-2 года, последний раз о ней рассказывали на Blackhat US 2015, но Microsoft не спешит что-либо менять.

Введение

Эта история началась практически сразу после написания статьи об исследовании аркады небезызвестной корейской компании: в аркадном автомате Tank! Tank! Tank! от Namco вышел из строя жесткий диск (что неудивительно, т.к. производитель установил в автомат не отличающиеся надежностью Seagate 7200.12), диск взяли с рабочей аркады и скопировали его через WinHex, после чего игра перестала запускаться. Предположив, что целостность диска была нарушена неосторожным нажатием клавиши в окне редактирования данных на диске в WinHex, был взят другой диск с еще одного рабочего автомата, скопирован аналогичным образом, который также перестал запускаться. Тут-то и стало понятно, что в диск каким-то образом встроена защита от копирования.

^{Aqua Mine}
Ревизор — программно±аппаратный комплекс для мониторинга доступа к сайтам из реестра со стороны провайдеров — берет свое начало в октябре 2015 года, когда компания «МФИ Софт», та же компания, что сделала СОРМы, выиграла тендер на разработку ПО за 84 миллиона рублей. Согласно условиям тендера, разработчик должен был предоставить работоспособное ПО под Windows и Linux и 700 аппаратных «Агентов» в срок до 14.12.2015, всего через 2.5 месяца, и, похоже, все было готово даже на пару недель раньше дедлайна. Провайдерам в добровольно-принудительном порядке уже в начале декабря предлагалось установить один из трех вариантов Ревизора: в виде образа виртуальной машины VMWare, основанной на OpenWRT 14.07, в виде программы-сервиса под Windows, либо же в виде железного «Агента», который представлял из себя маршрутизатор TP-Link MR3020 с установленным на него OpenWRT и необходимым ПО. Многие провайдеры отказывались от установки комплекса из-за того, что он не сертифицирован, а использоваться будет только им во вред, а другим устройств просто не досталось, и им пришлось установить софтовую версию.

Итак, у меня в руках последняя версия VMWare-образа и exe-файла Ревизора. Давайте же посмотрим, что внутри!

Некоторые из нас не пользуются интернетом без VPN по тем или иным причинам: кому-то нужен выделенный IP, и проще и дешевле купить VPS с двумя IP, чем покупать адрес у провайдера, кто-то хочет получать доступ ко всем веб-сайтам, а не только разрешенным на территории РФ, третьим нужен IPv6, а провайдер его не предоставляет…
Чаще всего VPN-соединение устанавливают на самом устройстве, которое используется в определенный момент, что вполне оправданно, если у вас только один компьютер и один телефон, и вы их редко используете одновременно. Если же в вашей домашней сети множество устройств, или, например, есть такие, на которых VPN настроить нельзя, было бы удобнее поднимать туннель прямо на домашнем роутере, чтобы не задумываться о настройке каждого устройства по отдельности.

Если вы хоть раз устанавливали OpenVPN на свой маршрутизатор, вы, вероятно, были неприятно удивлены скоростью его работы. SoC'и даже дешевых роутеров без особых проблем пропускают через себя окологигабитный трафик, за счет выноса функций маршрутизации и NAT на отдельный чип, предназначенный исключительно для выполнения этой задачи, а основные процессоры таких роутеров довольно слабы, т.к. нагрузки на них практически никакой нет. Такой компромисс позволяет достигнуть высокой скорости работы роутера и заметно снизить цену готового устройства — маршрутизаторы с мощными процессорами стоят в несколько раз дороже, и позиционируются уже не только как коробка для раздачи интернета, но и в качестве NAS, торрентокачалки и домашней мультимедиа-системы.

Мой роутер, TP-Link TL-WDR4300, нельзя назвать новым — модель появилась в середине 2012 года, и обладает 560 МГц-процессором архитектуры MIPS32 74Kc, мощности которого хватает лишь на 20-23 Мб/с шифрованного трафика через OpenVPN, что по меркам скорости современного домашнего интернета совсем немного.
Как бы нам повысить скорость шифрованного туннеля? Мой роутер довольно функциональный, поддерживает 3x3 MIMO, да и вообще, хорошо работает, не хотелось бы его менять.
Так как сейчас принято делать 10-мегабайтные интернет-страницы, писать десктопные приложения на node.js и паковать их в 100-мегабайтный файл, наращивать вычислительные мощности вместо оптимизации, мы совершим нечто ужасное — переложим VPN-подключение на производительный одноплатный «компьютер» Orange Pi One, который установим в корпус роутера, не занимая существующие сетевые и USB-порты, всего за $9.99*!
_{* + доставка, + налоги, + на пиво, + MicroSD.}

SSLv2, протокол шифрования от Netscape, вышедший в 1995 году и потерявший актуальность уже в 1996, казалось бы, в 2016 году должен быть отключен во всем ПО, использующем SSL/TLS-шифрование, особенно после уязвимостей POODLE в SSLv3, позволяющей дешифровать 1 байт за 256 запросов, и FREAK, связанной с ослабленными (экспортными) версиями шифров.

И если клиентское ПО (например, браузеры) давно не поддерживает подключения по протоколу SSLv2, и, с недавнего времени, и SSLv3, то с серверным ПО не все так однозначно.

Группа исследователей из Тель-Авивского университета, Мюнстенского университета прикладных наук, Рурского университета в Бохуме, Университета Пенсильвании, Мичиганского университета, Two Sigma, Google, проекта Hashcat и OpenSSL обнаружили уязвимость под названием DROWN — Decrypting RSA using Obsolete and Weakened eNcryption, которая позволяет дешифровать TLS-трафик клиента, если на серверной стороне не отключена поддержка протокола SSLv2 во всех серверах, оперирующих одним и тем же приватным ключом.

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

Почему это возможно?

Несмотря на то, что у большинства веб-серверов протокол SSLv2 отключен по умолчанию, и его никто не будет включать намеренно, данная атака позволяет дешифровать TLS-трафик, имея доступ к любому серверу, поддерживающему SSLv2, и использующему такой же приватный ключ, что и веб-сервер. Часто можно встретить использование одного и того же сертификата для веб-сервера и почтового сервера, а также для FTPS.

Общий вариант атаки эксплуатирует уязвимость в экспортных шифрах SSLv2, использующие 40-битные ключи RSA.

Одним из преимуществ IPv6 является отсутствие необходимости NAT из-за большого количества адресов в целом и длины выдаваемых пользователям подсетей в частности. Казалось бы, никто просто так не подключится к какому-нибудь одноплатнику, который вы только-только подключили в домашнюю сеть с поддержкой IPv6. Никто же, в здравом уме, не будет сканировать всю вашу подсеть. Если весь IPv4-интернет можно просканировать в течение десятков минут, то на полное сканирование одной только /64 (минимальная подсеть, рекомендуемая к выдаче клиентам) уйдут десятки тысяч лет. К тому же, если каким-то образом злоумышленник узнал ваш IPv6-адрес, всегда можно активировать поддержку IPv6 Privacy Extensions, с которыми ваш адрес будет рандомизироваться раз в сутки или чаще.
Казалось бы, вероятность сканирования вашего одноплатника, который не обращается к внешним ресурсам, крайне низка. Однако, есть одна вещь, которая настроена почти на каждом компьютере — периодическая синхронизация времени через NTP.

NTP

Подавляющее большинство дистрибутивов Linux устанавливаются с настроенной автоматической синхронизацией времени через NTP, используя серверы pool.ntp.org. Как оказалось, стать частью pool.ntp.org достаточно просто, чем и воспользовались Shodan, задействовав 5 NTP-серверов в разных частях света, для верности используя несколько IP-адресов на одном сервере, чтобы вероятность попадания запроса клиента именно на их сервер была выше. Таким образом, в пуле ntp.org оказалось 45 IPv6-адресов машин Shodan, которые сканируют любой подключающийся к ним IPv6-адрес в ответ.
Обнаружил факт сканирования и вычислил все серверы Shodan Brad Hein. Вычислить все сканирующие NTP-серверы вручную достаточно сложно, т.к. NTP-демон обращается ко многим NTP-серверам последовательно для более точной синхронизации времени. Для автоматизации процесса был написан скрипт, который обрабатывает журнал файрволла и соединяется с подозрительными хостами еще раз, чтобы удостовериться, что они действительно сканируют в ответ, используя свежий временный IPv6-адрес.
Подтвердить принадлежность хостов к Shodan было довольно легко — почти все серверы использовали настоящие имена хостов в PTR-записи, вида *.scan6.shodan.io

На данный момент, серверы Shodan исключили из пула ntp.org.