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

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

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

Занятное сейчас время в истории российского Интернета. Больше года назад мы с Артемием Ломовым написали для “Доменных имён” статью “Сценарии конца Интернета”, я уже как-то приводил на неё ссылку. В качестве первого сценария конца в статье приводится сбой “Красной кнопки” – механизма, призванного блокировать отдельные сайты. Процитирую пару моментов:

Предположим, что такую кнопку создали. Неважно как. […] При создании кнопки не предусмотрели всех мер по ее защите, по исключению ложного срабатывания. Еще бы! Кнопку конструировали для того, чтобы отключить интернет-ресурсы, и всякие излишние меры предосторожности тут вредны — вдруг в ответственный момент они помешают?

В общем, однажды кнопку включат для того, чтобы заблокировать один интернет-ресурс, но в результате срабатывания технологического механизма заблокированным и отключенным окажется весь Интернет. «У-упс! » — вежливо произнесет оператор кнопки, обозначив окончание очередной эпохи.

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

На днях начала просматриваться вторая веха интернет-истории. Она связана с борьбой за “копирайт”. Конечно, этот сценарий, – он не новый, – тоже описан в статье:

Сценарий может подкорректировать вмешательство государств, которые […] запретят использование файлообменных протоколов и заодно социальных сетей, обяжут провайдеров блокировать соответствующие виды трафика и, например, разрешать доступ только по «белым спискам». Не ограниченное фильтрами использование Интернета вообще автоматически приравняют к «нарушению копирайта», не размениваясь на уточнения, и обычные пользователи потеряют ко всему этому технологическому безобразию интерес.

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

Историческое время.

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

Как я некоторое время назад писал, на сайте Роскомнадзора опубликованы технические рекомендации по методам осуществления блокировки доступа к ресурсам Интернета. Сегодня рекомендации обновили. Смотрим, какой метод описан в документе:

Рекомендовать использование следующей технологии для реализации блокирования:
[…]
b. Трансляция с помощью запросов в DNS доменного имени в IP-адрес

c. Создание и распространение по системе маршрутизации сети доступа провайдера специального маршрута для данного IP-адреса, направляющего трафик в специальный анализирующий сегмент

d. Проведение анализа проходящего через анализирующий сегмент сервер [трафика] (в исходном документе, видимо, опечатка – АВ), выявление запросов к URL, содержащихся в списке блокировки, уничтожение данных запросов или перенаправление их на специальный ресурс, уведомляющий о факте блокировки.

То есть, IP-адрес, соответствующий блокируемому домену, берётся из DNS, трафик, поступающий на этот адрес, отправляется в систему DPI, которая выбирает из пользовательского потока запросы на конкретные адреса, внесённые в список блокируемых. В случае с HTTP – это, например, GET. В целом, выглядит логично.

(Да, понятно, что есть куча специальных случаев, но это другая история.)

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

Естественно, современная реализация TLS использует сеансовые ключи, генерируемые тем или иным алгоритмом, реализующим протокол Диффи-Хэллмана. Хитрость этого протокола в том, что даже если атакующий получил секретный ключ, используемый сервером, он не сможет расшифровать с его помощью сеансовый ключ. Но задачи, лежащие в основе и RSA, и схемы Диффи-Хэллмана – математически связаны между собой. Поэтому, если уж предположить, что некое агентство сумело сделать прорыв в этой области, то, вероятно, такой прорыв коснулся и той, и другой задачи. И вот поэтому появился смысл для записи сеансов HTTPS (и не только их), чтобы потом, с некоторой задержкой, расшифровать интересующие фрагменты трафика.

Известно, что по каналам Интернета ходит большой объём пользовательского трафика, который, при непрерывной записи, сложно полностью хранить (в течение длительного времени). Предположим, что гигабитный канал, имеющий усреднённую загрузку 80%, генерирует около 290 гигабайт “полезного” трафика в час. Это примерно 7 терабайт в сутки, то есть, если мы используем хранилище данных в 1000 терабайт (несколько тысяч жёстких дисков, несколько стоек в дата-центре), его не хватит и на полгода.

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

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

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

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

Для того чтобы расшифровать ранее записанный трафик, требуется сеансовый ключ. Этот ключ – симметричный, его экземпляр есть на сервере (и на клиенте). Предположим, что трафик записывается где-то на пути, в точке перехвата, находящейся между клиентом и сервером, например, это зеркальный канал на опорной сети. Сервер запоминает сеансовые ключи (это, кстати, требуется для управления TLS-сессиями), а позже передаёт их копии стороне, записавшей трафик. Теперь трафик можно расшифровать и разобрать постфактум. И вот сеансовый ключ, как раз, строго необходим для расшифровки сообщения. При условии, что HTTPS реализован в современном варианте, запись трафика и, позже, получение только секретного ключа, соответствующего SSL-сертификату, не позволяет расшифровать трафик, так как для генерации сеансового ключа используется протокол Диффи-Хэллмана.

Сделал вот такую страничку: DNSSEC.PW. Планирую там собирать всякие полезные ссылки на публикации, утилиты, справочные материалы, связанные с DNSSEC.

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

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

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

Добротные аппаратные DPI-решения для анализа интернет-трафика сейчас доступны даже для обычных коммерческих компаний. Очевидно, у АНБ с такой аппаратурой проблем давно нет. А доступ к серверам – нет, не требуется.

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

Понятно, что такой инструмент “ломает” DANE. (Напомню, что DANE привязывает, при помощи DNSSEC, SSL-сертификаты к домену.) Один из сценариев: интернет-провайдер подменяет в ответе DNS-резолвера цепочку подписей для домена, включая туда нужные записи DANE, показывающие на “подменный” SSL-сертификат. DANE рекомендует проводить проверку подписей DNS на клиенте, тем самым обеспечивается защита от подмены данных резолвером интернет-провайдера, однако в случае с “теневой зоной” никакой защиты нет: все подписи валидны, а сертификат получаем “подменный”. Более того, DANE, при условии подходящей браузерной реализации, тут позволяет использовать “недоверенный” (даже самоподписанный) сертификат, удостоверив его DNSSEC, что даже облегчает перехват HTTPS (потому что не нужно привлекать удостоверяющий центр).

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

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

Конечно, у подобных систем есть свои проблемы. Например, они могут конфликтовать с геораспределёнными системами, которые по своим внутренним причинам отдают пользователям из разных регионов разные данные. Впрочем, эта особенность в большей степени касается SSL-сертификатов, чем DNSSEC.

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

CMS определяются по сигнатурам. Конкретная сигнатура для веб-сервера строится на основании анализа его ответов на специальный набор запросов. Естественно, сама методика опроса серверов должна быть оптимизирована в плане нагрузки. Например, там где только возможно, используются не GET-запросы, а HEAD. Также ограничен разумной величиной поток запросов на конкретный веб-сервер.

Робот корректно представляется в User-Agent. В нашем случае вот так: “Web-Monitoring/1.0; +http://monoid.nic.ru/”. Здесь присутствует адрес в корпоративном домене, под которым находится веб-страница с максимально подробным описанием того, что это за “зверь” забежал на ваш сайт. Почитайте: monoid.nic.ru. Практика подтверждает, что такая страница – необходимый элемент: она снижает обеспокоенность веб-мастеров.

Для IP-адреса, с которого ходит робот, обязательно нужна заполненная обратная зона, с говорящим именем, расположенная в том же узнаваемом корпоративном домене. В нашем случае это monoid-srv.nic.ru. Корректная обратная зона приветствуется не веб-мастерами, но админами и инженерами NOC-ов. (Да, возможно, с точки зрения внешнего наблюдателя, идеально было бы держать веб-сервер с информационной страницей на том же IP, с которого ходит робот, но технологически добротная реализация этого варианта слишком уж затратна.)

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

(А подробное описание методики с оценкой точности, подготовленное Артемием Ломовым, тоже опубликовано на stat.nic.ru.)

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

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

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

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

Между прочим, многие проблемы установления определённых технических границ в виртуальном пространстве давно решаются средствами протоколов маршрутизации (BGP), которые, собственно, для этого и придуманы. Но вот как привязать BGP к политической карте мира?