dxdt.blog: занимательный интернет-журнал

Сейчас модно рассуждать о том, что вот-вот – и появятся “общественные” трансляции событий на стадионах во время чемпионатов мира. Например, по футболу. Очевидно, в ближайшей перспективе можно будет использовать продвинутые смартфоны и новые сети связи для трансляции видео на веб-сайты. Столь же очевидно, что FIFA хочет подобные трансляции ограничить – дабы не вышло лишней конкуренции за контент.

И вот как раз технических-то проблем с ограничением нет: просто, в перечень требований к стадиону включаются условия, ограничивающие доступ к услугам связи на определённый период. Ограничения могут вводить сами операторы связи, ничего не нарушая (создание посторонней помехи, также решающее проблему – нарушает условия использования радиоэфира). Голосовую связь и SMS – наверное, закрывать не станут. Но вот ограничить полосу для передачи данных вполне могут.

Запустили новый этап регистрации доменов .РФ. В результате наблюдается аномальный вал заявок на регистрацию СМИ, цель – получение приоритета на “вкусные” имена. Подробнее пишут в блоге RU-CENTER.

Addon: кстати, вышло официальное сообщение Роскомнадзора по теме.

Общедоступный технологический фундамент крепнет – энтузиасты теперь могут строить хитрые системы, ранее принципиально им недоступные.

Два важнейших фактора: сети связи и вычислительные мощности “в компактном размере”. Ну и GPS, конечно, помогает. Одно из известных достижений: любительские “беспилотники” – небольшие авиамодели, на борту которых установлен автопилот с поддержкой GPS. Такие летательные аппараты уже сейчас могут летать по длинному заданному маршруту с довольно высокой точностью, лишь бы погода не подкачала.

Но GPS – штука более мощная, потому что даёт дешёвый механизм синхронизации времени. Если сюда приплюсовать Интернет, то перед энтузиастами открывается очень интересное поле для деятельности: можно строить хорошо распределённые в пространстве (десятки километров) системы сенсоров, с синхронным временем. Что такие системы могут делать? Они могут определять координаты разных источников сигналов. Схема тут ясна: основу для вычисления координат источника даёт разница во времени прихода отслеживаемого сигнала в разные точки сети (координаты точек известны). Есть проблемы, конечно. Но есть и интересное развитие: по точно такой схеме работают пассивные системы локации, использующие “побочный” электромагнитный фон.

Суть такая (я как-то писал об этом): в результате технологической деятельности в эфире работает куча передатчиков, излучающих самые разнообразные сигналы. Пассивная система, во-первых, принимает основной сигнал от того или иного существующего передатчика; во-вторых, принимает отражённые разными целями сигналы этого же передатчика. Непосредственно, основной передатчик может слушать один приёмник, который формирует опорный сигнал. Такой приёмник снабжаем, например, узконаправленной антенной. Другие приёмники сети принимают отражённые сигналы. (Впрочем, понятно, что в реальности все приёмники могут принять не только исходный сигнал, но и какие-нибудь отражения. “Лишние” данные фильтруются на основе информации о свойствах опроного сигнала.)

Собранные сетью сигналы с точными временными и “географическими” метками передаются через Интернет в некий центр. Центр – это достаточно мощный компьютер, который вычисляет возможную конфигурацию источников отражений и строит искомую картину наблюдений. Получаем “систему мониторинга”. (Тут нужно учитывать, что там возникает вычислительно сложная комбинаторная задача; но и центр можно сделать не “центром”, а распределённой вычислительной системой, увеличив доступную мощность.) В качестве источников опорных сигналов годятся телевизионные передатчики, базовые станции GSM и т.п.

(Надо заметить, что мне уже пару раз присылали описания проектов похожих систем. Наверное, что такое уже может быть сделано.)

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

В схеме (по правилам), администратор домена отправляет скан паспорта регистратору через Интернет (как один из способов, который, наверняка, наиболее распространён). Но администратор не получает гарантий, что его скан был получен и принят (с учётом даты и времени получения). То есть, при возникновении спорной ситуации, недобросовестный регистратор может заявить, что скана вообще не получал. При этом у администратора домена нет возможности как-то доказать, что скан передавался.

Со своей стороны, если потребуется, регистратор всегда может доказать, что обладает сканом – просто предъявив его. Такой вот перекос доверия. Конечно, это стандартная проблема с “односторонней аутентификацией”, встречающаяся много где ещё: в электронных аукционах, в сетях GSM. Бороться можно очевидным способом: требуя документального подтверждения передачи скана паспорта.

Реализовать подтверждение можно и чисто электронными средствами: электронный скан подписывается закрытым ключом регистратора и возвращается подавшему его администратору.

Пожалуй, вынесу сюда из комментариев – читатель с ником AA пишет про закладки в микросхемах:

Придумался еще один вариант закладок. Немного нетипичный, но все же:
Для изготовления микросхем используется легирование полупроводниковой основы примесями. “Потенциальный союзник” может ввести дополнительный этап (еще один проход резист-литография-травление-легирование-отчистка, в существующие десятки таких проходов) в пп/производство, когда у некоторых (единичных!) особо мелких транзисторов легирование затворов будет вестись не стандартными примесями, а короткоживущим (десятки лет) ее изотопом. Через какое-то время изотоп распадется поменяв валентность, что приведет к сбою данного транзистора. Что получаем – данная партия сбис гарантированно сломается через n лет, не важно, была ли она в использовании или на складах. Фон от пикограмм (или меньше??) изотопа не детектируется, на ускоренном старении (для определения времени работы микрухи) данный вариант закладки не будет найден. Минусы – нельзя выключить вовремя, плюсы – не надо пытаться запихнуть управляющий импульс в микруху, экранирование и запасные микрухи (из той же партии) дело не спасут.

Специфические микрухи для закладывания изотопов – высокоскоростные и многоканальные АЦП, DSP.

В отношении кириллицы в именах доменов часто используют аналогию с многоязычными именами файлов в операционных системах. Мол, вот ввели же кириллические (и многоязычные) имена файлов. Это плохая аналогия. Почему? Прежде всего потому, что домены – это не файлы. Их имена вводятся и используются иначе.

Во-первых, кириллические адреса вводятся не в DNS, а чисто на клиентской стороне. Так что сами доменные зоны как были “латинскими”, так и остались. Зато появился дополнительный уровень представления, который, к тому же, с точки зрения технического специалиста (админа, например), расщепляет множество доменных имён на два класса – “традиционные” и “в кракозябрах” (то есть, кодированные в Punycode).

Во-вторых, домены адресуют группы разнородных ресурсов, доступных для неопределённого круга “клиентов” (DNS – глобальная система). При этом сами интернет-ресурсы в своей работе постоянно используют доменные имена для “обратных” ссылок (базовые URL для веб-сайтов, адреса e-mail, доступ с терминалов и т.д., и т.п.). Файлы – это объекты более “локальные”, наружу, конечно, передаются, но обязательно через какой-то “шлюз” (например, через веб-сервер). Даже директории (вполне себе файлы, да), адресующие группы объектов в файловой системе, это не эквиваленты доменов в современном Интернете.

Практическое проявление описанных различий сейчас хорошо видно на веб-сайтах, которые бодро перешли на кириллицу в адресах. Например, документ с описанием домена РФ на сайте Координационного центра (администратора этого домена) имеет вот такой URL: http://кц.рф/ru/domains/domenrf/. Посмотрите сами, где здесь домены и где “файлы”, которые уже давно допускают использование многоязычия.

Это я не к тому, что адреса на кириллице плохо. Просто ситуация – сильно отличается от случая с именами файлов.

В одной из прошлых заметок я писал (правда, больше в шутку) о скрытых (навязанных) вычислениях, которые могут проводить распространённые ОС в рамках процедуры получения обновлений. Результаты этих вычислений, понятно, могут использоваться производителями ОС: грех же не воспользоваться миллионами бесплатных часов машинного времени.

Интересно, что навязать пользовательскому компьютеру такие вычисления можно и без доступа к системе обновлений. Логичное решение – посещаемый веб-сайт. Конечно, можно что угодно запрограммировать на JavaScript и отправлять результаты подсчётов на сервер после загрузки страницы, или даже считать всё время, пока страница загружена, а результаты отправлять асинхронно, с помощью AJAX. Но JavaScript – медленный, да и решение получается слишком банальное.

Изящное решение могло бы быть вот каким: навязанная вычислительная задача “зашивается” в рендеринг веб-страниц. Например, когда браузер размещает в окне визуальные блоки, определяемые специально подготовленным CSS-ом (таблицами разметки страниц), он решает задачи, близкие к комбинаторным (ведь позиционирование блоков может быть относительным и абсолютным, с разной глубиной, с разным выравниванием и т.п.).

CSS-ы можно генерить разные при каждом обращении браузера. В каждый экземпляр CSS-ов транслируется кусочек задачи, кусочек навязанных вычислений. Получить информацию об итоговом расположении блоков сложнее, нужно привязывать всё к каким-нибудь фоновым картинкам. Возникают вопросы: кто-то уже такое делал? Выгодно ли это в вычислительном плане, относительно затрат на формирование CSS-ов?

Интересно, что “Яндекс” мог бы первым из крупных проектов выкатить полностью кириллическую адресацию. Вот у них в “Словарях” уже можно кириллицу использовать в URLе (http://slovari.yandex.ru/слово/), и есть домен яндекс.рф, в том числе с поддоменом словари.яндекс.рф. Но пока почему-то там редиректы понаставлены. А пора бы уже запустить полноценную версию.

В продолжение темы про привязку авторизации к адресам e-mail. Как должна работать правильная напоминалка пароля от того или иного интернет-сервиса по e-mail?

Очевидно, нельзя высылать почтой пароль (новый/старый) в открытом виде. Высылать нужно специальную ссылку на интерфейс смены пароля. Ссылка работает по https и содержит одноразовый ключ, действующий определённое время. К счастью, эта схема уже фактически стала стандартным вариантом. Тем не менее, иногда можно от разработчиков услышать возражения такого типа: какая разница, что высылать, сам пароль или ссылку? если кто-то посторонний читает почту, то он одинаковым образом сможет получить и то, и другое. Возражение ошибочное. Схема со ссылкой существенно безопаснее. Судите сами.

Ссылка – одноразовая (там одноразовый ключ). Значит, если её первым использует легитимный получатель, то для злоумышленника она бесполезна. Использованные ссылки можно смело сохранять в почтовых архивах. Сравните с хранением письма, содержащего пароль в открытом виде (а часто письма как раз сохраняются месяцами и годами). Разовое использование ссылки (или, что эквивалентно, её устаревание) гарантированно делает безопасными все “следы” этой ссылки в тех многочисленных логах, в которых она могла засветиться.

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

А в дополнение к одноразовым ссылкам нужна капча в самом интерфейсе смены пароля.

Как часто пишут, мобильный телефон может быть “анонимизирован”: сам аппарат приобретается “с рук” на рынке, и там же, без регистрации паспорта, покупается SIM-карта (хотя такие “симки” продаваться, вообще-то, не должны, но, тем не менее). Стандартные методы идентификации абонента GSM на таком телефонном аппарате не работают, по понятным причинам. Вопрос: а как тогда можно вычислить реального абонента, при условии участия оператора (операторов) связи?

Понятно, что сработает наружное наблюдение в сумме со специальным оборудованием, перехватывающим уникальный идентификатор аппарата (а он обязательно есть, иначе телефон не сможет осуществлять вызовы в сети GSM) из эфира. Логика не сложная: оператор связи выдаёт примерное местоположение абонента, дальше работает “наружка”, уточняя данные на месте визуально (если это место людное). Но это непростой по организации способ.

Можно воспользоваться анализом служебного GSM-трафика. Суть сводится вот к чему. Наверняка у разыскиваемого абонента есть другой, вполне официальный мобильный телефонный аппарат. Требуется найти этот аппарат, и идентифицировать абонента по нему. Предположим, что оператор связи ведёт подробные логи перемещения аппаратов между сотами и логи звонков этих аппаратов (доставки/отправки SMS, передачи данных и т.п.). В общем, понятно, что такие логи нужны и на практике имеются за какой-то период.

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

Однако всё можно упростить, взяв в качестве исходной “сигнатуры” для поиска логи перемещений и звонков для идентифицируемого “анонимного” телефона. Информация о звонках (и использовании аппарата вообще) нужна для того, чтобы из получившейся выборки по истории перемещения удалить записи, соответствующие аппаратам, по которым разговаривали одновременно с разговором по “анонимному” телефону. Использование анонимного аппарата только для передачи данных или для приёма SMS-ок – задачу обнаружения, конечно, сильно усложняет.

Понятно, что можно хорошо развить метод, добавив ещё поведенческих признаков (кросс-звонки, длительность разговора и т.п.). Всё строится на анализе логов с помощью автоматизированных инструментов, никаких записей разговоров не требуется.

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

Радиоэфир общий по своей физической сути. Есть международные соглашения, регулирующие использование спектра частот. Но, по большому счёту, если вдруг очень сильно потребуется организовать вещание на той или иной частоте, то ни у одной международной (или просто коммерческой) организации не найдётся средств, чтобы технически вещание полностью заблокировать. Да, можно ставить помеху, блокируя приём передач в некотором кусочке пространства. Можно, в общем, вести РЭБ. Но просто взять, нажать кнопку, и отключить доступ к частоте для всех слушателей и для вещателя – такого, очевидно, нельзя сделать.

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

Посмотрим на сценарий с DNS чуть более детально. Предположим, что кому-то требуется перехватить управление некоторым национальным доменом. Адресация в национальном домене глобально определяется серверами имён, которые указаны для него в корневой зоне. Первый путь для перехвата: изменяется запись в корне, новая версия указывает на другие сервера имён. Часто можно услышать, что корневую зону поддерживает большое число корневых серверов (их – 13), узлы которых распределены по всему миру и находятся под управлением разных компаний. Это так. Но файл корневой зоны все эти серверы получают из одного источника, со скрытого сервера, управляемого компанией VeriSign. Соответственно, если изменить адреса в исходном файле, то при очередном обновлении изменения распространятся на все экземпляры корневой зоны.

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

Понятно, что на новых серверах домена верхнего уровня может быть прописана совсем другая адресация. Но можно и сохранить имевшуюся на момент перехвата управления. Для этого потребуется заблаговременно получить файл зоны с действующих серверов имён. Этот файл содержит все записи о доменах уровнем ниже. Разместив на новых серверах имён копию старого файла зоны, можно замаскировать перехват: для пользователей ничего не изменится. (Конечно, файл зоны может быть “засекречен”, но, на уровне положения администраторов корня DNS, такой расклад выглядит непрактичным: ну реально ж попросить свежую копию заранее.)

Забрав управление доменом описанном незаметном режиме, новый администратор может переадресовать только какие-то ключевые сайты, оставив основную часть адресных настроек без изменений. Этот способ особенно хорош в том случае, если новый администратор не желает, чтобы под удар попали лояльные к нему интернет-сервисы: ведь понятно, что если “снести” домен полностью, то недоступными окажутся все ресурсы сразу; копирование установленной адресации – сильно смягчает ситуацию для рядовых пользователей. (Да, старые администраторы не смогут менять настройки доменов и т.п., и т.д. но это не так страшно.)

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

Вывод: в отличие от, например, радиоэфира, получается, что в Интернете не только можно отключить “главным рубильником” вещателей и слушателей, но и избирательно подменить вещателей (скорректировав адресные записи для выбранных доменов второго уровня). Все изменения делаются центрально и сразу во всём виртуальном пространстве. Никакой “РЭБ” вести невозможно, а главный тот, у кого рубильник.

И это мы ещё не рассмотрели ни DNSSEC, которая повышает эффективность “отключения частот”, добавляя новые “главные рубильники”, сильно затрудняя развёртывание альтернативных корней DNS, ни IP-адресацию. Последняя, кстати, позволяет отобрать управление доменом верхнего уровня, не прибегая к изменению записей в корневой зоне DNS. Достаточно подкорректировать распределение номеров автономных систем и забрать IP-адреса, по которым доступны действующие серверы имён. При этом для IP-маршрутизации в Интернете также скоро появится аналог DNSSEC, который криптографическими методами усилит управление адресацией.

(А при этом IP-адреса корневых серверов зашиты в системном программном обеспечении. Изменить их можно, но только в ручном режиме, при условии, тысячи системных администраторов будут действовать согласованно.)

Да, конечно, всё это теоретические сценарии. Но интересные. Так что, думаю, в следующих записках разбор темы можно продолжить. Тем более, что актуальность Интернета у нас растёт семимильными шагами.