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

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

Доктайп HTML5 стал самым распространённым на веб-узлах Рунета, потеснив XHTML 1.0 Transitional. Строго говоря, это не означает, что HTML5 стал самым распространённым языком разметки: на страницах с доктайпом HTML5 всё равно используются элементы, упразднённые в этом стандарте. Однако популярность HTML5 сильно выросла, а пережитки прошлых стандартов будут встречаться на сайтах ещё долго – тут уж ничего не поделаешь.

Заработал nic.yandex. А www.yandex, почему-то, ещё не сделали. Странно.

“Яндекс” получил очередное одобрение ICANN для своей заявки на домен верхнего уровня yandex. Интересно, что скоро у “Яндекса”, возможно, появится вот такой “короткий” адрес: http://www.yandex/, то есть, без привычного .ru. Совсем строгая запись будет выглядеть вот так: http://www.yandex./ – крайняя справа точка обозначает корневой домен. А вот сделать просто http://yandex/ – пока не выйдет: правила ICANN для New gTLD запрещают.

В День независимости США NASA публикует картинку новой ракетной системы (Space Launch System, SLS), предназначенной, кроме прочего, для вывода на орбиту обитаемого космического корабля Orion (это замена российской космической технике). Пока что ничего из этого не летает, но в перспективе обещают полезную нагрузку в 130 тонн. 130 тонн это много. Первый экземпляр должен вывести пустой Orion в тестовый космический полёт. Нагрузка составит 70 тонн, что тоже является неплохим показателем.

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

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

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

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

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

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

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

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

Да.

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

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

Несколько часов назад в корне DNS делегированы столичные домены moscow и москва (кириллический). Проверить, как они работают, можно здесь:

http://nic.moscow/
http://nic.москва/

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

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

Итак, для перечисления интернет-пользователей всякой популярной системы достаточно 32 бит или четырёх байтов (2^32 это примерно 4,2 млрд), поэтому запись идентификаторов для контактов заданного пользователя потребует 4*10=40 байтов за сутки. Добавляем сюда отпечатки времени – 3 байта на запись (с точностью до секунд в сутках + служебные биты). Получаем: 40+3*10=70 байтов за сутки. Очень мало. (Можно легко засунуть сюда и тип используемых сервисов, кстати.)

Рассмотрим другое, более технологичное, представление, где контакт – это пара идентификаторов и метка времени (ID1,ID2,T): 4+4+3=11 байтов на запись, а записи хранятся в единой БД, общим потоком. Если посмотреть на такую структуру данных, взятую “по модулю” одного пользователя, то получим оценку в 110 байтов в сутки на пользователя (естественно, тут есть простор для оптимизации). То есть, за 180 дней (примерно шесть месяцев): 180*110=19800 – около 20 килобайт данных за сутки на каждого пользователя. Для десяти миллионов – всего-то 200 гигабайт (без оптимизации кодирования, заметьте).

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

Другое дело, если требуется хранить подробный лог, в котором, например, отражено, как именно взаимодействовали пользователи, куда каждый из них ходил, сколько сообщений отправил, что нажимал, сколько времени провёл за тем или иным занаятием. В таком случае необходимый объём данных легко вырастет на два порядка. А ведь занятно, что и 20 терабайт (200Gb*100) – тоже не выглядят пугающе.

На дворе – 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, которые (возможно) читают новый код. Но даже при равных показателях, АНБ может иногда повезти: они заметят дефект, который пропустили “конкуренты”.