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

Заголовок длинноват, да. Речь вот о чём: может ли мобильный телефонный аппарат быть скрытно использован для прослушивания разговоров его владельца? А если аппарат выключен? Вообще, пишут разное. Одни СМИ заявляют, что может. Другие знатоки вопроса отвечают, что никак нет, нельзя так прослушивать, особенно если выключен телефон. Возникает путаница.

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

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

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

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

Вот.

Да, конечно, можно для прослушивания использовать не только мобильные телефоны. Годятся разные другие бытовые предметы. Известны случаи, когда транслятором акустической информации в эфир являлись настенные часы, висевшие в кабинете, где проходили секретные переговоры. В часах штатно содержалась вполне себе обычная катушка индуктивности, жёстко связанная с большим циферблатом (да, изнутри). Побочный эффект был такой: циферблат играл роль мембраны, поэтому изменение давления воздуха (звук, по простому говоря) приводило к колебаниям катушки; в результате вся система работала микрофоном и передавала в эфир разговоры из кабинета, которые принимали в припаркованном под окном здания специальном автомобиле. Реальная история, довольно старая.

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

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

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

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

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

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

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

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

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

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

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

О чём же может идти речь в реальности? Вот о чём: в цепочке обработки персональных данных администраторов вводится новое обязательное звено, которое проверяет соответствие персональных данных тому лицу, которое их предъявляет. Собственно, это и есть аутентификация. Звено появляется в самом начале цепочки, ближе к клиенту.

Сотрудник компании-регистратора или, например, нотариус, непосредственно удостоверяют личность администратора, попросив его предъявить паспорт. Не “скан отправить факсом”, а вот лично предъявить паспорт в офисе (сверяется фото в паспорте с присутствующим тут же клиентом). Схема известная, да.

Вот действительно разумный способ ввести “домены по паспорту”. И, видимо, единственный реальный способ (так как технологии ЭЦП не достаточно распространены). А просто переводить на “сканы” – это очень смешно, не более.

Вот.

P.S. А ещё, обсуждение этой темы показало, что многие путаются в “двух соснах”: в идентификации и аутентификации. Объясняю популярно: идентификация – это когда звонит по телефону мужской голос и в ответ на ваш вопрос “А хто ето?” представляется Петром Ивановичем Булкиным, старшим сантехником по подъезду; аутентификация – это когда уже назвавшийся Булкиным мужской голос может ещё и правильно назвать девичью фамилию консьержки, а также другие пароли, известные только настоящему Петру Ивановичу, в результате вы более или менее уверены, что разговариваете действительно с сантехником Булкиным. Ну, просто голос у него претерпел аберрацию.

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

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

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

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

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

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

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

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

Пользователь “вычислен персонально”.

Более того, можно составить чёткие критерии, когда программа “извлечения данных” определила пользователя точно, а когда – нет: просто учитывается число оставшихся возможных вариантов.

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

Главное тут вот что: в приведённом решении хитрой задачи достигается “полная анонимность”, “полное обезличивание” на этапе сбора исходных данных; а позже, совсем другими серверами, из этих “обезличенных данных” восстанавливаются вполне точные персональные данные. Такая вот реконструкция алгоритмами data mining.

Кому интересно, вот ссылка на работу с исследованием этой темы: On the Anonymity of Home/Work Location Pairs. Также, около года назад, я писал про очень логически близкие к только что описанной технологии построения поведенческих профилей посетителей веб-сайтов.

Для тех, кто предпочитает сразу тему развивать: подумайте, что, в теории, аналогичная схема сработает и при анализе пользовательского интернет-трафика.

Сегодня немного “техничная” записка. Есть такой положительно оцениваемый админами и, очевидно, отличный продукт: веб-сервер nginx, единолично поддерживаемый автором – Игорем Сысоевым. Nginx очень популярен, используется массово.

Ну, думаю, понятно, что как всякий нормальный “интернетовский” серверный продукт nginx работает на платформе Unix/Linux. И вот на ReMIX в этом году Сысоев анонсировал бинарную версию nginx для Windows.

Что в этом особенно интересного?

А вот что: есть такая технология в DNS, называется fast-flux. В рамках этой технологии штатными средствами DNS быстро меняется соответствие конкретного доменного имени и IP-адреса сервера. Я как-нибудь напишу про fast-flux в подробностях, сейчас важен лишь один момент: fast-flux активно используется злоумышленниками для размещения вредоносного и просто “неправового” контента в Интернете. Злоумышленникам, fast-flux, применяемый вместе с ботнетом, позволяет скрывать следы и преодолевать провайдерские фильтры, блокирующие доступ по IP-адресам.

Важно: при этом сама технология fast-flux – не является “зловредной”, не использует какие-то уязвимости в DNS, а вполне “легитимна”. Но злоумышленники нашли ей своё применение.

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

Специалисты из рабочей группы ICANN, занимающейся fast-flux, включили nginx, отвечающий на http-запросы под “исследуемым доменом”, в список признаков “злонамеренного fast-flux”. Это произошло ещё до выхода Windows-версии nginx. И казалось странным. Но, вообще говоря, появление такого пункта указывало на то, что в Сети есть некоторое заметное число захваченных злоумышленниками unix-серверов.

Ну да, уязвимости есть в разных ОС.

При этом, естественно, подавляющая масса компьютеров, составляющих ботнет работает под управлением Windows.

Для хостингов, для нагруженных серверов веб-сайтов – ОС линейки Windows пока не актуальны. Но, понятно, для Microsoft, особенно в Рунете, портирование nginx под Windows – это важное событие: MS активно пробирается на “хостинговый” рынок. Поэтому, можно предположить, что Microsoft активно поддерживала идею пересаживания nginx на дополнительную платформу (хотя, сам автор nginx говорил на ReMIX, что исходная задумка очень старая; но факты таковы: бета-версия появилась только в 2009 году и анонсировалась на майкрософтовской конференции).

Если взглянуть на практическую сторону: довольно сложно придумать, где бы, на каком бы узле системы предоставления услуг типичного современного хостинг-провайдера windows-nginx мог с выгодой крутиться (за исключением, разве что, windows-хостеров). Дело в том, что там же везде и давно FreeBSD, ну или что-то близкородственное. И nginx давно есть.

Зато вот для использования в ботнетах, работающих на fast-flux, где Windows безоговорочно лидирует – очень кстати соответствующий “бинарник” nginx. Вот такой выходит неожиданный поворот.

Ещё раз отмечу, чтобы избежать кривотолков: nginx – очевидно, хороший эффективный рабочий инструмент, который злоумышленники просто возьмут на вооружение. (Nginx даже гораздо “легитимнее” fast-flux, если так можно сравнивать.) А интересным аспектом здесь будет то, у кого же больше окажется востребована версия nginx под Windows.

В конце апреля “Би-Би-Си” процитировали штатовского полковника (Charlie Williamson), который в выступлении по радио высказывался за создание “официальных” ботнетов (ну, почему-то именно ботнетов) и средств нападения в киберпространстве Интернета.

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

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

Ещё интереснее: как будут взаимодействовать с независимыми разработчиками, которые возьмут лицензированные штатами зловреды, исследуют их и выпустят бесплатное противодействующее ПО? Наверное, нужно будет как-то поправлять законы в США?

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

Вот, кстати, первым источником уязвимостей в реализациях DNSSEC (это “безопасное” расширение DNS) будут рационализаторские решения. Технические центры крупных доменов захотят экономить ресурсы и поправят технологии так, как удобнее с точки зрения экономии. Поправки породят уязвимости.

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

Так что с DNSSEC будет то же самое – дыры подготовят рационализаторы.

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

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

Записи с полезной информацией из доменов .tel допускают использование шифрования, регулярных выражений и, таким образом, могут содержать довольно хитрые структуры данных. Известно, что чем хитрее допустимая структура входных данных для некоторой программы, тем больше возможностей у злоумышленника изменить эти данные таким образом, чтобы вызвать сбой в программе (и даже формальная строгость структуры положение не спасает: можно вспомнить недавние дыры в FireFox, связанные с обработкой некорректно сформированных XML-документов). То есть, фундамент для эксплуатации ошибок в ПО, работающем с доменами .tel – есть. Этот фундамент позволяет превратить ошибки в уязвимости.

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

Возникает резонный вопрос, а что можно протолкнуть через DNS на клиентскую машину? Неспециалистам это кажется странным, но протолкнуть можно всё что угодно, только скорость будет не очень большая. Главное, чтобы на клиентской машине было ПО, готовое принимать данные через DNS-туннель.

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

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

Вот такие новые угрозы с новыми доменами.

The Register пишет про итальянских исследователей, которые с помощью лазерного “виброметра” научились читать вводимые на клавиатуре компьютера символы. Кроме того, в этой же статье эти же исследователи “читают” PS/2-клавиатуры через линии электропитания.

В первом случае используется анализ звука, производимого каждым нажатием клавиши пользователем, во втором – анализируют электрические “наводки” в электросети, также связанные со срабатыванием клавиш клавиатуры. Для автоматизации распознавания кодов символов используют специальное ПО, вполне ожидаемо работающее со словарём. Интересно, что атаки реализованы с минимальными затратами, измеряемыми сотнями долларов США.

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

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

Вот так. Ждём появления средств защиты для массовых пользователей.

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

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

Чтобы проще было разбираться, на всякий случай напомню, что же такое DNS. DNS – это такой сервис в Интернете, позволяющий преобразовывать символьные имена узлов в числовые IP-адреса, по которым и производится реальная адресация. (Ну и, вообще говоря, с помощью сервиса DNS специальным образом возможно осуществить и обратное преобразование: IP-адрес – в символьное имя.) Главный философский момент тут такой: DNS – именно сервис, работающий с помощью большого количества серверов, разбросанных по глобальному Интернету; напрямую к маршрутизации пакетов DNS не привязана – пакеты между узлами вполне ходят без всякой DNS, которую придумали-то для людей.

Вот.

1. DNSSEC,технически, это расширение DNS, позволяющее подписывать адресную информацию цифровой подписью. То есть администратор доменной зоны подписывает записи о соответствии доменных имён и IP-адресов в своей зоне. Потребитель адресной информации получает возможность проверить валидность подписи. Это важно потому, что тот самый потребитель обычно получает запрошенную DNS-информацию через третьи-пятые руки, а не напрямую от администратора интересующей его зоны – потребителя обслуживает тот DNS-сервер (кеширующий сервер), который, например, указан в настройках ОС. Пользователь вынужден доверять именно этому серверу. Но хуже всего, что и ответы этого “ближайшего” сервера злоумышленник может подделать. А без механизмов проверки подлинности полученную в ответ на запрос подделку выявить не представляется возможным.

2. DNSSEC позволяет победить такие вполне себе фундаментальные уязвимости в DNS, как, например, отравление кеша. Эти уязвимости позволяют нехорошим злоумышленникам перенаправлять пользователей Интернета на свои серверы, подменяя соответствие имён доменов и IP-адресов. Набрал мойбанк.ru, а браузер попал вовсе не на сервер банка. Кому-то может показаться, что более старые, чем Веб, уязвимости вовсе не так уж и опасны, они протухли. Но вот, скажем, если недавно продемонстрированную на практике возможность создания поддельного SSL-сертификата, вообще не отличимого от настоящего, прикрепить к отравлению кеша, то получится, что достаточно продвинутые злоумышленники могут клонировать сайт банка, снабдив его, в том числе, и валидным SSL-сертификатом. Даже крайне недоверчивый пользователь будет введён в заблуждение. Хорошо построенная атака может дать массовый эффект: пользователи крупного провайдера все как один пойдут вместо реального сервера банка на подставной, при этом в адресной строке браузера будет значиться правильный адрес, и SSL-сертификат не вызовет в браузере окон с предупреждениями.

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

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

5. У корневого центра есть свой секретный ключ. И с этим ключом в DNSSEC проблема, потому что не понятно, кому он должен достаться. Сложность ещё и в том, что у DNS Интернета одна корневая зона, а домены выстроены в иерархическую структуру, поэтому построение “плоской” структуры доверия затруднительно организационно (хоть некоторые администраторы доменов и пытаются тут что-то придумать). В схеме с одним главным ключом – проблема: в случае повсеместного внедрения DNSSEC (тут важно не забывать про клиентскую сторону тоже) к его обладателю все должны идти на поклон, и он сможет домены эффективно “выключать” по своему желанию.

Вот.

Вообще, несколько подробнее про DNSSEC в популярном изложении можно прочитать в недавнем выпуске журнала “Доменные имена”, который в электронном виде можно взять на сайте RU-CENTER. На 69-й странице там начинается моя статья про DNSSEC.

(Если есть какие-то вопросы – прошу в комментарии, я, возможно, сделаю отдельный раздел про DNSSEC.)

***

Дополнения (2012):

О DNSSEC, в течение нескольких лет, я написал много других публикаций и реализовал несколько технологических демонстраций, например, такой демонстрацией является первый подписанный домен в зоне .su – nox.su.

Корневую зону глобальной DNS (общепринятой) подписали в ночь с 15 на 16 июля 2010 года. Связанные с этой процедурой домыслы прессы, падкой на криптосенсации, привели к возникновению забавного “мема” о “шестёрке программистов, которых уполномочили перезагрузить Интернет, если он сломается”. Естественно, в реальности всё обстоит сильно иначе.

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

Как утверждает источник, на картинке – оригинальный механический замок высокой секретности, использовавшийся в СССР (насколько реальное происхождение замка соответствует этой версии – не ясно).

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

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

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

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