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

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

Вообще, можно, конечно, предположить, что таких государственных баз данных нет, но не ясно, как, в таком случае, работают аналитические подразделения АНБ. Ведь если каждый раз, когда уязвимость обнаружена, о ней бы сообщали разработчикам ПО, это повлекло бы за собой утечку информации о том, с чем работает данная служба. Особенно интересной представляется ситуация, когда уязвимость обнаружена в иностранном ПО (или в каком-нибудь иностранном оборудовании). Хотя, конечно, в Штатах такое положение дел встречается не так уж часто.

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

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

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

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

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

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

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

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

Известно, что параметры бытового электропитания, например, 220 вольт и 50 герц, в реальности далеки от стабильности: в линиях всегда присутствует шум разнообразной природы. Этот шум можно записывать, если подключить к проводам подходящую аппаратуру. Понятно, что ряд характеристик шума будет общим для той или иной большой группы потребителей. Более того, параметры шума будут уникальными для выбранного интервала времени.

Казалось бы, зачем нужен подобный архив, в котором хранятся записи шумов сетей электроснабжения? Одно из интересных применений состоит в датировке аналоговых (да и цифровых тоже, надо сказать) аудиозаписей. Механизм тут такой: шум электропитания оставляет следы в записи, эти следы можно выделить, сопоставить характеристики с архивными данными, и сказать, когда могла быть выполнена предоставленная запись. Такая методика иногда используется в рамках судебной экспертизы. Естественно, датировать так можно не только аудиозаписи.

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

(Вот одна из работ по данной теме.)

(Меня попросили простыми словами объяснить, как работают методы считывания секретных ключей через побочные излучения и наводки, например через измерение электрических параметров ноутбука, как продемонстрировано в недавней работе Genkin, Pipman, Tromer. Думаю, что описание достаточно интересно и для публикации на dxdt.ru, тем более, что в нём, на мой взгляд, есть наблюдения, полезные для понимания деталей работы современных реализаций RSA и принципов разработки криптографического ПО.)

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

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

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

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

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

Итак – секретной частью ключа RSA является расшифровывающая экспонента. Это целое число. Достаточно большое. В компьютерной памяти, естественно, оно представлено в двоичном виде. Операции с ним также осуществляются, грубо говоря, побитно – это одна из оптимизаций для быстрого умножения. После того, как исследователи определили, что можно различить исполняемые центральным процессором компьютера серии одних и тех же операций, измеряя потенциал на его корпусе, осталось найти такие зацепки в программном коде, которые позволили бы, на основе этих измерений, различать единицы и нули шифрующей экспоненты. Здесь и кроется основная задумка работы. Зацепки удалось найти в части кода GpuPG, осуществляющей умножение: здесь для 1 и 0 шифрующей экспоненты выбирались разные ветки кода, исполнение которых, при определённых условиях (см. ниже про шифротекст), оставляло разные следы в измеряемом канале утечки.

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

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

Выбрать правильный шифротекст, из-за особенностей реализации RSA, не представляло особого труда: подходит значение m – 1, где m = pq – модуль ключа, который, как известно, равен произведению двух простых чисел p и q. Значение модуля является открытым. (В секрете держится только разложение на p и q. Несмотря на то что, строго говоря, для расшифровывания сообщения нужно знать только расшифровывающую экспоненту, значения p и q сохраняются, чтобы в дальнейшем использовать их для оптимизации умножения при расшифровывании сообщений.)

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

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

И рекомендую почитать исходную работу (PDF).

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

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

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

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

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

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

Вот здесь, используя один из новых доменов верхнего уровня (.systems), объявляют о том, что раскроют исходные коды (и сопутствующую информацию – см. ниже) микроядра seL4. Главная особенность данного ядра ОС в том, что его реализация прошла через процедуру формального доказательства её соответствия спецификации. То есть, доказано, что в реализации отсутствуют некоторые классы типичных ошибок и уязвимостей. (Пишут, что всё это касается версии ядра для архитектуры ARM, и что seL4 – первое ядро, прошедшее подобную проверку.)

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

Некоторое время назад я оценивал, сколько нужно хранить трафика, чтобы иметь более или менее полный слепок пользовательской активности в Рунете за 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) – тоже не выглядят пугающе.

На сайте Ruward.ru публикуют некое исследование безопасности CMS, сравнивают коробочные (коммерческие) CMS и бесплатные CMS. Методика не ясна, но это другой разговор (с методиками вообще проблема в исследованиях, как известно).

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

Проиллюстрирую ситуацию сугубо практическим примером, основанным на наблюдениях за взломом сайтов на хостингах. Возможен тиражный взлом – это когда одна шаблонная уязвимость используется для того, чтобы автоматом заразить кучу ресурсов. Применительно к CMS, здесь видна следующая тенденция. Если у атакующего есть уязвимость, позволяющая ломать WordPress, то он может рассчитывать на заражение автоматом миллионов сайтов. Уязвимость коммерческой CMS, используемой на пяти тысячах сайтов, позволяет только эти пять тысяч и заразить. Думаю, понятно, какая уязвимость привлекательнее для массового взлома.

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

Вот.

Используя сервис RIPE NCC Atlas, я провёл пару простых измерений доступности сайта зимней Олимпиады www.sochi2014.com из разных регионов мира. Методика несложная: узлы сети Atlas “пингуют” (ICMP) хост, доступный под адресом www.sochi2014.com. Различие между измерениями в том, что в первом случае IP-адрес при помощи запроса в DNS определяет управляющий сервер (который раздаёт задания), а во втором – опрос DNS происходит на самих тестирующих узлах. Поэтому в результатах можно хорошо видеть, как работает балансировка, использующая DNS, в CDN Akamai.

Здесь, на картинке выше, определение имени проводил сервер, находящийся в Европе (вероятно, в Амстердаме), поэтому был получен IP-адрес для европейских пользователей, соответственно, для Штатов наблюдается большое время “отклика” (красные отметки). Типичные пользователи так с сервисом не работают, в Штатах должны использоваться местные DNS-резолверы.

На этой картинке – результаты второго измерения, метод скорректирован: определение IP-адреса для www.sochi2014.com проводится на тестирующем узле. Теперь всё окей: время отклика стабильно минимальное, в том числе, в Штатах. Это показывает, что работает хорошо распредлённая сеть серверов.

Отмечу, что для тестируемого имени используется большое количество IP-адресов, то есть, в ответ на запрос в DNS их возвращается несколько – “пинговался” же только один адрес из полученного списка.

Другой момент. Балансировка при помощи DNS имеет следующую особенность: вероятное местоположение пользователя, фактически, определяется про адресу DNS-резолвера, который его обслуживает. Так, запросы в DNS из, например, дата-центра в Дублине – возвращают для www.sochi2014.com одни адреса; выполнив запрос из московского дата-центра – получаем другие; а в случае использования Google Public DNS из Москвы – третьи. (Понятно, что опрос Google Public DNS из Штатов – даёт ещё один вариант.) Таким образом, если пользователь находится в Твери, но использует европейский DNS-резолвер, его браузер будет соединяться с европейскими серверами Akamai. Впрочем, в современном Интернете это чрезвычайно редкая конфигурация, так что её можно не принимать в расчёт.

(На картинках есть серые метки – это узлы Atlas, для которых запрос ICMP Echo в сторону олимпийского сайта не сработал. Такая ситуация вполне нормальна, и не означает, что недоступен сайт: “пинги” могут не ходить по сети, где установлен измеряющий узел, по самым разным причинам.)

По статистике сайта Blockchain.info, крупнейший пул GHash.IO приближается к 40% мощности всей сети Биткоин. Пул – это объединение узлов, занимающихся “майнингом” (добычей) биткоинов, то есть, обеспечивающих проведение транзакций. Захват большей части вычислительной мощности позволяет контролировать Сеть, так устроен протокол (подробнее о том, что и как – в отдельной заметке о биткоинах).

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

Так что, вероятно, близок очередной кризис биткоинов, а он будет сопровождаться шумихой в прессе, что добавит интереса теме. Посмотрим.