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

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

Определить посещаемость можно при помощи анализа HTTP-трафика, проводимого на сетях провайдеров доступа (либо на точках обмена трафиком, что неплохо подходит для российского сегмента Интернета). То есть, нужно использовать DPI. Наблюдая за трафиком, относительно несложно посчитать число заходов браузеров на заданный ресурс. Думаю, основная идея метода достаточно очевидна: считаются GET-запросы, содержащие заданный URL. Не обязательно даже следить за всем потоком трафика: полные данные можно вычислить по некоторой выборке.

Есть ещё дополнительные косвенные методы. Например, запросы к серверам DNS, скажем, к корневым. Частота запросов о заданном имени хоста (об адресе сайта) связана с посещаемостью этого сайта. Правда, запросы выполняют рекурсивные резолверы, поэтому собранную статистику нужно “нормировать” по числу клиентов, обслуживаемых тем или иным резолвером. (Последняя величина, кстати, тоже косвенно определяется из наблюдений за DNS-запросами, а точнее – за вариативностью этих запросов, приходящих от разных резолверов; грубо говоря, данные выдаёт “дисперсия”, но это детали.)

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

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

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

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

Для дистрибутива Fedora Linux планируют внедрение локального DNS-резолвера, валидирующего DNSSEC. Этот резолвер предлагается использовать по умолчанию. То есть, дистрибутив будет проводить проверку адресной информации непосредственно на клиенте, что обозначает завершающий этап развёртывания технологии DNSSEC. Естественно, только обозначает: потому что для окончания данного этапа – мы должны увидеть локальную валидацию по умолчанию в распространённых клиентских системах (ни Fedora, ни Linux к таким, к сожалению, не относятся).

Кстати, напомню, что я как-то сделал небольшой сервис для проверки средствами браузера того, поддерживается ли DNSSEC вашим системным окружением.

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

То же самое касается и угроз по отключению национального сегмента Интернета извне – здесь адекватным решением, в идеальном мире, также является не огораживание, а создание технологии распределения национального сегмента по всей Сети так, чтобы отключить его можно было только вместе со всеми остальными сегментами. Опять же, теоретический аппарат для таких технологий – есть.

Да.

Наш мир, конечно, не идеален.

(Политические комментарии – буду удалять. Надеюсь на понимание.)

На дворе – 21 век. Уже довольно давно. Тем не менее, официальный сайт корпорации Northrop Grumman содержит занимательный дефект, в духе 90-х. Дефект находится на виду, в довольно привлекательном разделе – News (“Новости”). Выявить этот дефект не составляет труда даже для начинающего веб-разработчика. Посмотрим на структуру URL-ов, которые используются в этом разделе, а собственно, на единственный параметр, который также представляет собой URL:

art=http://www.globenewswire.com/newsarchive/noc/press/xml/nitf.html?d=10076335

Полный исходный URL:
http://www.northropgrumman.com/mediaresources/Pages/NewsArticle.aspx?art=http://www.globenewswire.com/newsarchive/noc/press/xml/nitf.html?d=10076335

Думаю, многие уже догадались: URL из параметра – это ссылка на страницу-источник текста новости. Конечно, он не фильтруется сервером, можно подставить всё что угодно. Вместо фильтрации – некий сервис Yahoo, с помощью которого реализована данная замечательная возможность на сайте, исправно приходит по подставленному URL-у, и скачивает всё, что ему подсунут, транспортируя содержимое на сервер и показывая результат доверчивому пользователю под доменом www.northropgrumman.com. Что именно нужно подсунуть на специально подготовленной странице, которую можно разместить на любом внешнем сервере, выяснить несложно – достаточно посмотреть в исходный код штатных новостей PR-провайдера globenewswire.com: там, надо сказать, весьма прозрачный формат – и это единственный положительный момент в данной истории из области веб-разработки.

Очевидно, что, используя описанный механизм, можно “опубликовать” на официальном сайте Northrop Grumman любую удивительную новость, а потом поделиться ссылкой, в том числе, с прессой. Тем более, что параметры URL нетрудно закодировать URL encoding, спрятав подозрительный домен-источник (хорошо подходят IDN-ы, кстати).

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

В одной из записок про OpenSSL упоминается каталог уязвимостей, вероятно, используемый NSA (АНБ). Поясню, о чём идет речь: АНБ – всегда было агентством с большими аналитическими способностями; если посмотреть на известную часть истории, то АНБ активно конкурировало с ЦРУ именно на поле аналитических служб и методов обработки информации, с целью извлечения полезных сведений. Соответственно, было бы удивительно узнать, что специальная группа внутри АНБ не следит пристально за всеми обновлениями и изменениями одной из самых распространённых в мире криптобиблиотек – OpenSSL.

Уже для того, чтобы готовить отчёты и комментарии по результатам работы группы, требуется как-то анализировать исходный код, а не просто считать строки и операторы goto. Естественно, полагать, что специалисты АНБ находят все уязвимости – было бы преувеличением. Но достаточно прозрачные вещи, вроде Heartbleed, они должны иногда замечать.

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

Ещё немного про OpenSSL. Вся эта история с возможными утечками данных через Heartbleed является полезным уроком. Например, она показала, как очередной небольшой шаг в сторону усложнения и без того непростых протоколов семейства TLS привёл к огромному снижению уровня безопасности.

Откуда взялась уязвимость? В TLS добавили расширение Heartbeat (RFC 6520), довольно экзотическое, и уж точно не критическое для большинства современных сценариев использования TLS в Интернете. По сложившейся традиции, реализацию этого расширения быстренько загнали в OpenSSL. А в результате внедрения этой мало кем востребованной штуки – миллионы сервисов, сами того не желая, получили по огромной дыре. Они, выходит, использовали данное расширение TLS только для того, чтобы желающие могли получать несанкционированный доступ к оперативной памяти. Такая вот безопасность.

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

Хотя, конечно, TLS не сломан, всё идёт своим чередом. Есть шансы, что новая версия TLS будет проще, а пачку расширений отрежут. Посмотрим.

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

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

Кстати, это очередной хороший пример, объясняющий, почему может быть полезно хранить полный дамп шифрованного трафика. В штатных логах данная утечка никак не отражается, то есть, обнаружить в логах, что утекли ключи – не выйдет (только предположить, что могли утечь). А вот в дампе трафика ключи вполне себе будут заметны, и утечку можно детектировать с высокой точностью.

Пара полезных ссылок:

Diff исправления уязвимости (добавлена проверка границы области памяти, в общем-то, достаточно очевидная для опытного аудитора кода; но такой аудитор должен был ещё посмотреть в код, да).

Онлайн-инструмент для проверки уязвимости конкретного веб-сервера (проверил – похоже, работает корректно).

Сейчас нередко приходится слышать, что тотальный переход сайтов на HTTPS помешает проведению “мягких блокировок” избранных сайтов провайдерами. Потому что в HTTPS, для инспектора трафика, не видны полные URL. Впрочем, тут можно напомнить про SNI – в рамках этой технологии, практически все современные браузеры, охватывающие, наверное, не менее 90% пользователей, передают имя хоста, с которым устанавливают TLS-соединение (HTTPS), в открытом виде:

То есть, хоть URL-ов и не видно, но адрес сайта, с которым пытается соединиться пользователь, системам инспекции трафика (DPI) доступен: блокируй – не хочу.

Вообще, полезно иметь в виду, что ни TLS, ни, тем более, HTTPS, не разрабатывались для преодоления систем фильтрации и блокирования доступа, так что как-то радикально повлиять на ситуацию они не могут. Хотя, конечно, проведение “тонкого блокирования” затрудняют. Но проблема не в этом. Да и “тонкое блокирование” – похоже, мало кому нужно.

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

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

В старой записке про аутентификацию внутри DNS, в качестве примера упоминается именно та ситуация, которая (кто бы сомневался!) приключилась в турецком сегменте Сети:

Предположим, что у вас настроен в качестве резолвера собственный сервер (пусть это будет BIND), доступный по IP-адресу 1.2.3.4. Откуда ваша локальная операционная система знает, что, отправляя запросы и получая ответы от 1.2.3.4, – она “разговаривает” именно с нужным резолвером?

Пишут, что турецкие провайдеры, в целях блокирования доступа к интернет-ресурсам, перехватывают трафик, идущий в сторону сервисов Google Public DNS. То есть, трафик пользователей, предназначенный для 8.8.8.8 и 8.8.4.4, заворачивается на локальные узлы провайдера, которые отдают поддельные ответы DNS (в частности, об адресах twitter.com). Перехват касается и других хорошо известных сервисов DNS-резолвинга.

После того, как местные провайдеры начали подменять ответы DNS на собственных, провайдерских, резолверах, пользователи массово перешли на резолверы Google (думаю, многие видели фотографию из Турции, запечатлевшую написанный большими буквами на стене дома адрес 8.8.8.8). Следующим шагом стало заворачивание провайдерами трафика, адресованного данному сервису, на свои узлы. Надо заметить, что, из-за популярности Google, мера наверняка оказалась эффективной.

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

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