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

Свежая популярная тема – распределённые атаки на WordPress с перебором паролей администратора сайта. Надо сказать, что в логах веб-сервера действительно заметен рост числа серийных HTTP-запросов POST, с адресом скрипта, который проводит логин пользователей. То есть, я легко нашёл на одном из сайтов более пяти тысяч таких запросов за сутки с одного IP-адреса. А вообще адресов-источников несколько, понятно, но обычно там десятки запросов, не тысячи.

Нельзя сказать, что подобного сканирования не было раньше, но за период с 10 апреля по сегодняшний день – рост на порядок виден невооружённым взглядом. Вот такой теперь Интернет, что тут скажешь. К непрерывному SSH-сканированию добавляются массовые проверки веб-приложений. Хотя, никакой новости тут нет, разве что огромная популярность WordPress-а подгоняет публикации в СМИ.

(Что касается противодействия: я, например, просто настроил динамические правила в брандмауэре, использовав fail2ban + iptables; обычное решение, думаю, что адекватное.)

Занятный момент есть в официальном FAQ по Google Public DNS – они пишут, что если адрес, который не проходит валидацию DNSSEC, является популярным и хорошо известным, то для него может быть сделано исключение: валидацию отключат.

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

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

Цитата из FAQ:

How does Google Public DNS handle lookups which fail DNSSEC validation?

If a client requests a validated lookup for a signed domain, but Google Public DNS cannot validate the lookup (due to misconfiguration, missing or incorrect RRSIG records or DNSKEY records, etc.), it will return an error response (SERVFAIL). However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily blacklist the zone from validation until the problem is fixed.

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

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

Беда в том, что “Яндекс” пришёл далеко не один раз, не дождавшись истечения TTL (“время жизни” ответа, управляющее продолжительностью нахождения данных в кэше). Можно предположить, как всё это устроено на стороне “Яндекса”: используется группа серверов-резолверов (часть из них имеет адреса из диапазона 213.180.200.240/29), с раздельными кэшами, балансировка входящих запросов не учитывает состояние кэшей, взятое относительно источника запроса. То есть, пока каждый резолвер не загрузит данные, требуемые для ответа на запрос, вероятность попасть в кэш мала. Дело в том, что последовательные запросы отрабатывают разные резолверы: хорошо видно, как они повторно приходят на NS до истечения TTL.

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

(Да, Google Public DNS кэширует правильно, повторно раньше времени не приходит.)

Думаю, в “Яндексе” есть объяснение, почему так сделано. Но сделано некрасиво. Даже для бета-версии.

“Яндекс” запустил открытый сервис DNS (открытые резолверы). Сервис похож на Google Public DNS. Однако у яндексового варианта есть дополнение – фильтрация адресов:

Яндекс.DNS – это бесплатный DNS-сервис, блокирующий опасные сайты и сайты для взрослых.

(http://dns.yandex.ru/)

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

При обработке запроса об адресе “заблокированного” ресурса приходит ответ, содержащий IP-адрес некоего принадлежащего “Яндексу” сервера перенаправлений, который отвечает по HTTP (это уже прямая подмена соединения!) редиректом на специальную страницу внутри yandex.ru. Эта страница устроена так, что охотно показывает сообщение о блокировании любого адреса, который передан в параметре URL-а. Например: http://yandex.ru/adult?url=yandex.ru – пишет, что “заблокирован” yandex.ru. Это, мягко говоря, технологически некрасиво. (Да, многие операторы связи сейчас делают подобное. Это известно.)

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

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

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

В Nature, наконец-то, опубликована работа (Yves-Alexandre de Montjoye, César A. Hidalgo, Michel Verleysen, Vincent D. Blondel), где описанные методики идентификации исследованы в подробностях на реальной выборке данных:

We study fifteen months of human mobility data for one and a half million individuals and find that human mobility traces are highly unique. In fact, in a dataset where the location of an individual is specified hourly, and with a spatial resolution equal to that given by the carrier’s antennas, four spatio-temporal points are enough to uniquely identify 95% of the individuals.

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

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

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

Нередко спрашивают, где посмотреть на примеры SSL-сертификатов, связанных с тем или иным инцидентом, отражающим очередной провал в работе удостоверяющих центров. Откроем браузер Firefox, я взял версию 19.0.2, найдём там в настройках раздел Advanced, воспользуемся вкладкой Encryption и кнопкой View Certificates, выбрав в открывшемся окне вкладку Servers (я сделал скриншот):

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

Ещё немного по теме прослушивания Skype. Из сообщений представителей самого Skype и отчётов аудиторов давно известно, что это ПО использует стандартные криптографические примитивы (AES, RSA и так далее), но местами делает это, на уровне протоколов, проприетарным образом. Да, понятно, что, например, AES, в качестве основы шифрования потока данных, – это хороший тон. Да, Skype использует P2P-сеть для транспорта трафика, а ключи, как заявлено, генерируются на клиенте. Всё это хорошо. В теории. Вопрос – можно ли организовать прослушивание?

Ответ есть. Сразу оговорюсь, он тоже чисто теоретический. Протоколы обмена ключами между сторонами, образующими то самое P2P-соединение, нередко базируются на присутствии третьей стороны, которой доверяют оба участника. Третья сторона удостоверяет данные участников обмена информацией, в том числе, сессионные ключи от AES. Это стандартное хорошее решение (но не единственно возможное, заметьте). Насколько я помню, Skype использует собственный удостоверяющий сервер, открытые ключи которого известны клиентскому ПО и позволяют проверять подлинность рекивзитов других пользователей при установлении соединения.

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

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

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

СМИ опять пишут про то, что “китайская версия” Skype содержит встроенные средства “цензурирования” и просмотра пользовательской активности. Преподносится как новость. На самом деле, этой теме уже несколько лет. Занимательно, что в работе 2011 года, которая сейчас (почему-то только сейчас) послужила поводом для шума, перехват обращений китайского клиента TOM-Skype производили с помощью подмены ответов DNS:

To decrypt this file, we redirected skypetools.tom.com DNS queries to our own HTTP server, allowing us to force TOM-Skype to load keyfiles of our choosing.

Очень верный, эффективный метод.

Вопрос – зачем о подобной прозрачности некоторых разновидностей Skype в СМИ вспомнили сейчас? Сначала отправили пилотные публикации, их уже перепечатывают, на голубом глазу, менее расторопные сайты. Может, это связано с популярной в Штатах темой “китайских кибервойн”? Есть, конечно, ещё более банальное объяснение – отдуваться за Skype теперь нужно Microsoft. (Так считается. Хотя, не ясно почему. Skype всегда был, мягко говоря, подозрительной программой.)

Сделал простой сервис, позволяющий проверить из браузера, есть ли поддержка DNSSEC у DNS-резолвера, которым вы пользуетесь. Скорее всего, это резолвер интернет-провайдера. Сервис здесь: dnssec.dxdt.ru.

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

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

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

Многие знают, что у Google есть полезный DNS-сервис – открытый резолвер, воспользоваться которым может каждый, Google Publi. Буквально на днях, судя по ответам серверов, Google Public DNS стал проводить валидацию DNSSEC. То есть, подписанные домены теперь проверяются. Раньше такой функции не было.

Дальше немного технической части.

Убедиться в поддержке DNSSEC можно следующим образом (8.8.8.8 – один из адресов резолвера Google):

$ dig @8.8.8.8 -t A +dnssec dxdt.ru

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec dxdt.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45823 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

– наблюдаем установленный бит AD в ответе (зона dxdt.ru – подписана, это факт).

$ dig @8.8.8.8 -t A +dnssec broken.nox.su

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec broken.nox.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52027

– наблюдаем SERVFAIL, это правильно, потому что broken.nox.su – специально сломана, чтобы можно было протестировать поддержку DNSSEC; если резолвер не проводит валидацию, то в ответе будет IP-адрес (для broken.nox.su это, обычно, 0.0.0.0).

Ещё пример, используем добротно сломанный dotsu.su:

$ dig @8.8.8.8 -t A +dnssec dotsu.su

– ответом должен быть SERVFAIL, и оно так и есть, по крайней мере, на моей стороне.

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

Этот шаг Google может неплохо помочь в продвижении DNSSEC, а заодно повысит популярность их DNS-резолверов.