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

Схема организации подписей и зон DNSSEC для dxdt.ru:

Картинка сгенерирована при помощи полезного сервиса DNSViz.

Кстати, довольно давно я завёл специально испорченную, в смысле DNSSEC, зону – dotsu.su. С её помощью удобно тестировать различные анализаторы DNSSEC. Текущая версия DNSViz выдаёт вполне корректную картинку для dotsu.su (раньше были сбои).

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

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

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

Ещё немного про TLS/SSL: Let’s Encrypt – это инициатива по созданию общедоступного бесплатного удостоверяющего центра (УЦ), а также программных инструментов и сервиса автоматической выдачи сайтам SSL-сертификатов, признаваемых браузерами. Более того, обещают, что сопутствующее ПО будет автоматически настраивать веб-сервер для работы по HTTPS.

Чуть подробнее: предполагается, что утилита Let’s Encrypt, будучи запущенной на сервере, сама сгенерирует ключи, свяжется с удостоверяющим центром, подтвердит управление сайтом (владение доменом), закажет и получит SSL-сертификат и настроит веб-сервер для работы с ним. Всё это с использованием специального протокола, который был разработан ранее. И бесплатно.

Выглядит, конечно, привлекательно. Но вызывает сомнение высокая степень автоматизации: всё ж SSL/TLS иногда требует обдумывания действий, иначе безопасность не повышается, а скорее наоборот. Всякое тиражное решение несёт с собой риск тиражирования не только хороших, правильных практик, но и ошибок, которые сделали разработчики решения. Можно спорить, насколько сильно нужно ошибиться в сервисе, автоматически внедряющем HTTPS на сервере, чтобы в результате ошибки уровень безопасности для этого сервера снизился – предполагается, что до момента запуска Let’s Encrypt сервер вообще использовал открытый протокол HTTP. Всяческие сценарии с захватом управления веб-сервером и автоматическим выпуском сертификата для его домена не очень пугают, так как если кто-то получил управление сервером, то он и так может сделать с ним всё что угодно, в том числе заказать сертификат (тут, впрочем, может потребоваться ещё и контроль электронной почты под доменом). Но, естественно, бесплатность процедуры несколько упрощает атаку.

Нет сомнений, что подобный сервис, к сожалению, окажется удобен для различных фишерских доменов, среди которых есть и простые тайпсквотерские (yanclex.ru), и более хитрые, комбинированные: например, что-нибудь вроде ssl-yandex.ru. Возможность быстро выпустить бесплатный сертификат и поднять HTTPS, вызывающий дополнительное доверие пользователей – она не может быть лишней. Впрочем, сейчас для этих же целей успешно выпускаются платные сертификаты DV (с валидацией по домену), с подставными реквизитами: возможности определить степень легитимности домена УЦ не имеет. Так что радикально Let’s Encrypt тут ситуацию не изменит.

Запуск сервиса обещают летом 2015 года. В числе участников инициативы значатся Mozilla и IdenTrust (это действующий УЦ), то есть можно ожидать появления нового УЦ как минимум в одном распространённом браузере. Как я понимаю, на первых порах Let’s Encrypt планирует вообще использовать для работы корень IdenTrust, с отдельным промежуточным сертификатом (по крайней мере, сейчас у них на сервере HTTPS устроен именно так). В общем, посмотрим, что получится.

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

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

HTTPS решает эти проблемы: изменить страницы на промежуточном узле простым способом не получится (что, естественно, не отменяет возможного перехвата HTTPS, но переводит задачу на принципиально иной уровень сложности). Конечно, всегда остаётся доступен старый способ: принудительная замена протокола на стороне пользователя, которая хорошо работает для ссылок (простая замена https:// на http://). Однако если пользователь привык заходить на сайт банка по браузерной закладке (типичный сценарий, кстати), попытка подмены протокола, – например, через редирект, – вызовет предупреждение в браузере (потому что для выполнения HTTP-редиректа тоже потребуется серверный SSL-сертификат, а его, скорее всего, у перехватывающего соединение узла нет).

И не стоит забывать о том, что уже есть поддерживаемые браузерами инструменты, позволяющие жёстко назначить HTTPS единственным протоколом для веб-сайта. Пример: HTTP Strict Transport Security.

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

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

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

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

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

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

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

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

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

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

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

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

А после того как в национальном сегменте умерли хотя бы две трети “цисок”, на восстановление связности потребуются многие месяцы (не исключено, что и годы).

Продолжается новомодный поток анонсов с громкими атаками на SSL/TLS: в этот раз – POODLE, позволяющая свести на нет секретность HTTPS (например) при использовании SSLv3. Занятно, что в сообщении по ссылке читаем: “Today, Firefox uses SSLv3 for only about 0.3% of HTTPS connections” (“Сейчас Firefox использует SSLv3 лишь для 0,3% HTTPS-соединений”).

(Подробное описание, PDF.)

Большой проблемой современного состояния SSL/TLS в Интернете является возможная “прозрачная” подмена сертификатов, проводимая при участии удостоверяющих центров. Одним из решений этой проблемы является построение независимой от иерархии удостоверяющих центров публичной системы аудита выданных сертификатов. Соответствующая инициатива называется Certificate Transparency (CT), я писал о ней примерно год назад. Результаты аудита, которые публикуются в специальных логах, могут, в том числе, автоматически проверяться браузерами. Технология активно развивается и уже частично поддерживается браузерами Chrome и Chromium. Конечно, есть проблема с полнотой логов, но важно, что поддержку включили.

Кстати, поговаривают, что в Chrome/Chromium будут требовать поддержки CT для EV-сертификатов (сертификатов с “дополнительной валидацией”) с февраля 2015 года. То есть, уже совсем скоро.

Посмотреть, как работает эта новая технология, можно, например, здесь: https://embed.ct.digicert.com/.

Кстати, я не так давно писал, что гипотетически возможен вариант с “внешним отключением Интернета“. Однако, насколько можно судить, сейчас в новостях речь идёт не просто об отключении Рунета, а о том, чтобы получить возможность всё же использовать Интернет, в том случае, если от него пытаются отключить внешние силы.

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

Технически, сломать национальный сегмент можно, если ломающая сторона обладает достаточными полномочиями и ресурсами. Тут сомнений быть не может. Ломать, естественно, нужно не на уровне DNS, а на уровне BGP (то есть, на уровне маршрутизации). Если у вас не работает BGP, то национальный сегмент разваливается на множество автономных систем, которые не могут обмениваться трафиком. То есть, нет даже единого интранета. Естественно, DNS при этом тоже не работает. Но локальные сети – остаются. Также, остаётся “локальный” обмен трафиком, если между несколькими автономными системами установлены прямые подключения (“пиры”). Например, у “Яндекса” есть прямые каналы к крупным российским хостингам (возможно, и к зарубежным). Эти каналы не видны для всего остального Интернета. (Не видны – в терминах BGP.)

(Очень интересно будет вспомнить, что отключение Интернета в Сирии, если верить иностранной прессе, произошло из-за ошибки сотрудников АНБ, которые удалённо ковырялись в пограничном маршрутизаторе и – сломали его. Медийное пространство хорошо выстроено, да.)

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