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

Опубликовали отчёт по результатам годичного мониторинга систем управления контентом (CMS) и других веб-технологий в Рунете. Кроме прочего, там есть граф переходов веб-узлов между разными CMS. Например, видно, что Joomla! активно теряет установки.

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

То, что заявлена поддержка VPN, не означает, что трафик защищён от перехвата провайдером этого VPN. Соответственно, если вы заходите через некий “бесплатный VPN-анонимайзер” на livejournal.com (или в другой веб-сервис, например, в веб-почту), то кто-то может утащить ваш пароль. Более того, вероятен перехват HTTPS – проверено на практике: многие не утруждают себя чтением и пониманием предупреждений систем безопасности браузеров, а сразу нажимают “Всё равно продолжить”. Хуже того, злонамеренные узлы могут проводить инъекцию кода в веб-страницы, что также ведёт к утечкам важных данных. По факту, риски здесь более опасные, чем некая “блокировка доступа” к той или иной страничке. (TOR-клиенты я бы тоже не рекомендовал – это не VPN, а лишь средство анонимизации; TOR-трафик тоже подвержен перехвату на выходных узлах.)

Если нужно использовать VPN, то либо настройте свой (это не так сложно; например, вот описание настройки VPN c использованием Amazon EC2), либо приобретите подписку у более или менее проверенного провайдера VPN. Сейчас VPN штатно поддерживается всеми распространёнными операционными системами.

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

Из пресс-релиза ЦБ РФ:

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

Отмечу, что операции в сети Биткоин можно эффективно отслеживать путём анализа интернет-трафика – там ничего не шифруется. Грамотно настроенная система DPI извлечёт и факты “выпуска валют”, то есть, в случае биткоинов, – публикацию новых блоков blockchain.

(Подробнее про биткоины я писал ранее.)

В Рунете количество индексных страниц веб-сайтов с доктайпом HTML5 за год увеличилось в 2,25 раза. Чуть подробнее, с графиками – в блоге RU-CENTER.

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

Новый сайт Sochi2014.com вполне логично размещён на мощностях Akamai (один из крупнейших мировых провайдеров услуг CDN) – это хорошо. Но вот с HTTPS повторяется типичная для Akamai история: при попытке безопасного соединения с https://www.sochi2014.com/ – серверы отдают “провайдерские” SSL-сертификаты, выпущенные не для sochi2014.com, а для имён вроде *.akamaihd.net, a248.e.akamai.net и прочих. В результате – имеем в браузере предупреждение системы безопасности, что уже не очень хорошо.

Проблема, кстати, весьма старая, и Akamai её, похоже, так и не поправил.

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

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

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

Сейчас в Сети массово внедряются новые домены верхнего уровня, с самыми разными именами (.link, .moscow, .shop и др. – список можно посмотреть на специальной странице). Уже на этапе обсуждения технических аспектов появления новых строк в корневой зоне DNS, возникли опасения, что возможен конфликт имён, так как некоторые корпоративные сети используют собственные, “локальные”, домены верхнего уровня, выбирая их произвольно. Примеры: .corp, .lan и так далее.

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

ICANN (организация, управляющая адресацией Интернета) решила зарезервировать в новых доменах имена второго уровня, которые наблюдались в трафике корневых серверов за некоторый промежуток времени. То есть, регистрация таких имён будет, как минимум в течение некоторого времени, невозможна. Резервирование должны осуществить администраторы соответствующих новых доменных зон. Cписки резервируемых имён опубликованы ICANN в соответствующих разделах сайта. Вот, например, список для .link (длинный, 34377 строк), а вот – для кириллического домена .дети (всего несколько десятков строк). Для домена moscow – резервируются 6236 строк.

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

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

Эта заметка – популярный обзор того, как работает сеть Биткоин и соответствующая ей валюта. Основные темы: логика протокола, blockchain, некоторые расхожие мифы, связанные с биткоинами, “майнинг” и перспективы системы.

Читать полностью