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

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

Собственно, теперь, когда зону успешно подписали, о втором шаге рассказывает уже ICANN: в официальном блоге пишут про предложенный Деном Камински (Dan Kaminsky) инструментарий, внедряющий поддержку DNSSEC на стороне браузера (например, упоминают “частную” версию Google Chrome, полностью поддерживающую DNSSEC) и почтового клиента. Собственно, это правильно.

До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.

В ночь с 15 на 16 июля корневую зону DNS подписали настоящим ключом и опубликовали открытые ключи для проверки подписей DNSSEC. Таким образом, Минторг США, компания VeriSign и ICANN завершили развёртывание DNSSEC в корневой зоне. Собственно, теперь DNSSEC можно использовать в глобальной DNS. Ключи каждый может взять на сайте IANA.

Теперь поддержку DNSSEC начнут массово вводить в доменах первого уровня.

Напомню, что следующие шаги на пути к новому Интернету – внедрение IPv6 и модернизация принципов маршрутизации (через внедрение криптографических механизмов).

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

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

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

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

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

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

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

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

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

Реализовать подтверждение можно и чисто электронными средствами: электронный скан подписывается закрытым ключом регистратора и возвращается подавшему его администратору.

В продолжение темы про привязку авторизации к адресам e-mail. Как должна работать правильная напоминалка пароля от того или иного интернет-сервиса по e-mail?

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

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

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

А в дополнение к одноразовым ссылкам нужна капча в самом интерфейсе смены пароля.

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

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

Можно воспользоваться анализом служебного GSM-трафика. Суть сводится вот к чему. Наверняка у разыскиваемого абонента есть другой, вполне официальный мобильный телефонный аппарат. Требуется найти этот аппарат, и идентифицировать абонента по нему. Предположим, что оператор связи ведёт подробные логи перемещения аппаратов между сотами и логи звонков этих аппаратов (доставки/отправки SMS, передачи данных и т.п.). В общем, понятно, что такие логи нужны и на практике имеются за какой-то период.

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

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

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

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

Радиоэфир общий по своей физической сути. Есть международные соглашения, регулирующие использование спектра частот. Но, по большому счёту, если вдруг очень сильно потребуется организовать вещание на той или иной частоте, то ни у одной международной (или просто коммерческой) организации не найдётся средств, чтобы технически вещание полностью заблокировать. Да, можно ставить помеху, блокируя приём передач в некотором кусочке пространства. Можно, в общем, вести РЭБ. Но просто взять, нажать кнопку, и отключить доступ к частоте для всех слушателей и для вещателя – такого, очевидно, нельзя сделать.

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

Посмотрим на сценарий с DNS чуть более детально. Предположим, что кому-то требуется перехватить управление некоторым национальным доменом. Адресация в национальном домене глобально определяется серверами имён, которые указаны для него в корневой зоне. Первый путь для перехвата: изменяется запись в корне, новая версия указывает на другие сервера имён. Часто можно услышать, что корневую зону поддерживает большое число корневых серверов (их – 13), узлы которых распределены по всему миру и находятся под управлением разных компаний. Это так. Но файл корневой зоны все эти серверы получают из одного источника, со скрытого сервера, управляемого компанией VeriSign. Соответственно, если изменить адреса в исходном файле, то при очередном обновлении изменения распространятся на все экземпляры корневой зоны.

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

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

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

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

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

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

(А при этом IP-адреса корневых серверов зашиты в системном программном обеспечении. Изменить их можно, но только в ручном режиме, при условии, тысячи системных администраторов будут действовать согласованно.)

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

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

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

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

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

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

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

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

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

Занимательности добавляет тот факт, что “брошенные” адреса периодически становятся доступными для новой “регистрации” совсем другими пользователями. И это вовсе не исключительная проблема бесплатных почтовиков (пишут, что проблемные домены имели в контактах адреса @mail.ru, @bk.ru и т.п.). Да, с освободившимися аккаунтами бесплатной почты – всё понятно. Эти адреса вне конкуренции: освобождаются чаще, захватить проще. Однако есть же и другие способы.

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

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