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

Кстати, поисковые машины, которые пытаются дотянуться до всего в Вебе, уже научились автоматически фильтровать и изменять собранный контент таким образом, чтобы не раскрывать личные данные тех или иных людей. Например, Google замазывает лица и автомобильные номера на панорамах улиц в Street View. Примерно то же можно сделать и с персональными данными, поиск утечек которых в “Яндексе” сейчас довольно популярное занятие, освещаемое СМИ.

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

Интересно, как нужно строить “безопасную” новую сеть поверх Интернета? (Да, такие предложения уже звучали несколько лет назад, а сейчас будут выдвигаться всё шире.) Понятно, что озвучиваемые в прессе идеи связаны с тремя узнаваемыми элементами: с Вебом, с доменами, и с “интернетом по паспорту”. Например, про специальную безопасную доменную зону верхнего уровня, типа .safe или .secure – уже лет пять говорят. И, скорее всего, что-то такое запустят в течение пары лет. Будет ли решение популярным, в этом вопрос.

С другой стороны, уже есть и DNSSEC, и HTTPS, и надёжные обратные зоны в .arpa – так что, во-первых, можно сделать “безопасной” любую доменную зону, хоть третьего уровня; во-вторых, можно обеспечить идентификацию хостов + идентификацию пользователей (обратная зона+электронные подписи в прямой DNS+связанный с тем же субъектом сертификат для доступа к веб-сайтам). Решит ли это проблему? Вряд ли. Потому что нужно как-то донести информацию о преимуществах до конечного пользователя, чтобы он надавил на провайдеров и они сподобились поддерживать новые технологии. Сделать это сложно. Пользователи могут не понимать, чего от них хотят.

Если же просто ввести тот или иной .secure, то может так получиться, что пользователи воспримут именно это текстовое окончание .secure в адресной строке как гарантию безопасности. Как обычно. Ну и злоумышленники кинутся подделывать адреса соответствующим образом, ведь, ни DNSSEC, ни даже https, для массового пользователя всё ещё не работают на практике. (Если с https ситуация ещё более или менее движется в сторону положительной, то с DNSSEC совсем худо.)

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

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

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

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

Кстати, всё больше появляется громко анонсируемых сервисов, предлагающих идентификацию пользовательских устройств, подключенных к Интернету. (Например, сейчас пишут про некий проект BlueCava, который предлагает подобную идентификацию.) Речь, конечно, не о банальной записи IP-адресов и куки-файлов, а о некоторых более развитых технологиях, позволяющих отличить один компьютер от другого.

То есть, интересно решение, которое основывается только на анализе параметров устройства “снаружи”, скажем, со стороны веб-сайта, и работает для подавляющего большинства сочетаний ОС/браузер/аппаратура. Практические демонстрации решений, идентифицирующих с той или иной точностью браузеры (но не компьютеры) вне зависимости от кук и IP-адресов, известны уже несколько лет. Хороший пример – Panopticlick. Попробуем разобраться, какие вообще есть источники информации для подобной идентификации.

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

Для уточнения нужно двигаться дальше. Точнее – глубже. Можно попытаться использовать параметры, привязанные к оборудованию. Скажем, как уже предлагалось, “дрейф” системных часов, в компьютерах, которые не синхронизируются по времени. Можно попытаться определить тип процессора и характеристики производительности. Как? Например, замеряя скорость выполнения функций, написанных на том же Javascript (скорость существенно зависит от браузера, впрочем) или внутри Flash. Кстати, наверняка широкое поле деятельности тут предложит HTML5.

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

Современные смартфоны содержат набор дополнительных сервисных устройств, информация от которых также может поступать через браузер на удалённый сервер. Например, GPS. Особенности конкретных реализаций интерфейсов вполне себе могут дать дополнительные биты информации для уточнения уникальности устройства.

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

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

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

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

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

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

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

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

Интересно, что есть довольно старая (более десяти лет ей, думаю) идея, сходного направления: можно ли массово и скрытно установив простые датчики или программные закладки в компьютеры и офисную технику, находящуюся в эксплуатации на территории другой страны, определить, что там начались некоторые значительные события в офлайне? Ну, грубо говоря: вот начали срочные приказы набирать в текстовом редакторе, нервничают, много опечаток, мышка дёргается – всё это мониторит логическая закладка в операционной системе, и передаёт некий простой сигнал в центр. Закладка при этом не читает ключевые слова (в отличие от монитора сообщений в Twitter’е), чтобы не выдать себя при анализе кода, а вот просто фиксирует побочные параметры. Центр, суммируя показатели, определяет, что да – началось, пора действовать.

Описанная только что система – совсем теоретическая, понятно. А вот если вы владеете серверами Twitter’а, то хитрые логические функции операционной системы становятся не нужны. Потому что у вас более совершенное решение, вообще кросс-платформенное: браузеры сейчас есть едва ли не во всех ОС. Понятно, что и Google, имея в активе систему статистики для веб-сайтов (Google Analytics), может самым замечательным образом мониторить состояние общественных настроений по скачкам посещаемости сайтов различной тематики. Тут вот и ключ к популярности исследований по “детектированию офлайновых событий”.

Да, очевидно, что использование одним пользователем одинакового пароля для нескольких сервисов – это плохо. Мало того, что могут специально заманить пользователя на некий специальный ресурс, а там предложить зарегистрироваться и выведать “стандартный” пароль, так ещё теперь пароли массово утекают из-за безалаберности администрации вполне добропорядочных ресурсов, не планировавших что-то там “взламывать” самостоятельно. Часто, во взломанной базе аккаунтов содержатся ещё и адреса e-mail. Если использован общий пароль, то злоумышленник уже знает к какому почтовому ящику данный пароль подходит.

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

(А кроме того, неприятно, что на дворе уже 21 век, а некоторые массовые интернет-сервисы продолжают пароли в открытом виде хранить, ну как при царе Горохе. Модель угроз у них, видишь ли, другая, искажённая до потери связи с реальностью.)

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

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

Как один из вариантов “навязывания” доступа к Интернету в тех странах, где его блокируют, обсуждаются перспективные “меш-сети”, построенные “стихийно” на базе устройств, розданных непосредственным участникам сети. То есть, у всех пользователей есть некие устройства связи, которые передают данные друг другу, по соседям, оказавшимся в зоне доступа. Если имеется возможность связываться по Wi-Fi, или через сотовую сеть, то эти средства коммуникации также используются. В теории, такая сеть может представлять собой полезный практический инструмент для обмена информации при нахождении участников где-то в городе. Потому что для обеспечения приемлемой связности нужна достаточно высокая плотность узлов, формирующих сеть.

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

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

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

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

Что получается в итоге? Получается, что для того, чтобы “меш-сеть”, созданная для “навязывания” Интернета и построения телекоммуникационной среды на некоторой произвольной территории, получила шансы на успех, требуется спроектировать довольно сложные базовые устройства и отладить новые хитрые протоколы связи. А иначе сеть подавят практически так же быстро, как и обычный локальный сегмент Интернета. То есть, затраты на получение подобной технологии и на её использование, оказываются очень ощутимыми. Пойдут ли на такие затраты?

В продолжение темы про IPv6. У этого нового протокола есть интересное математическое (вычислительное, если хотите) отличие от IPv4. Так, в старом протоколе есть не более 2³²=4294967296 (около 4 млрд) потенциально различимых адресов. Предположим, что мы задумали каждому возможному адресу сопоставить один байт с некоторой информацией. Массив займёт примерно 4 гигабайта. Это объём ОЗУ обычного современного настольного компьютера. То есть, подобные таблицы, “перечисляющие” некоторым образом всё пространство IPv4, можно “ворочать” без особых вычислительных затрат. Не важно, для чего используются такие массивы-таблицы, для обозначения каналов доставки пакетов, для подсчёта обращений к некоторым узлам, для балансировки нагрузки глобально доступных сервисов или для чего-то ещё. Главное, что возможен простой, “прямой” способ работы со всем множеством адресов.

Реализовать подобное для IPv6 – не выйдет. 2¹²⁸ элементов невозможно уместить в память никакого существующего суперкомпьютера. Хуже того, их невозможно даже перебрать за разумное время ни на каком суперкомпьютере. Другими словами, множество адресов IPv6, перечислимое математически, не “перечислимо” в суровой программистской реальности, потому как “нет таких компьютеров”. Казалось бы – ну и ладно, кому нужны эти гигантские таблицы?

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

Хотя, понятно, конечно, что “на свободе” не должно ходить IPv6-адресов сильно больше, чем существует устройств, способных такие адреса использовать.