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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более практичное расстояние – 100 метров. Получаем 0.2 сек. = 200 мс при средней скорости подлёта 500 м/с. 200 миллисекунд – это 200 тыс. тактов процессора, работающего на частоте 1 Мгц. 200 тыс. операций – как оценка, выглядит достаточной для вычисления параметров перехвата. При этом, 1 Мгц – по нынешним меркам очень медленно даже для военной специальной ЭВМ. Нужно, впрочем, скинуть время, необходимое для актививрования бортового перехватчика (поджиг ускорителей и т.п.) и передачи в этот перехватчик данных целеуказания.

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

Ускорители со специальным топливом – они срабатывают очень быстро, хватит 5-10 мс плюс ещё 10 мс накинем на выполнение разворота. Тут, впрочем, кроется весьма хитрое “ноу-хау”: нужно так устроить корректирующие двигатели, чтобы они точно дозировали создаваемый момент, иначе противоракета будет разворачиваться с ошибкой, что сделает всю систему бесполезной. В используемом нами масштабе, заметным становится время, за которое противоракета достигнет точки перехвата. Предположим, что противоракета также показала среднюю скорость 500 м/с (очень такой прикидочный расчёт). Получается, что через 20 мс (10% от общего интервала в 200 мс) противоракета пролетела 10 метров. С запасом хватает для наземной бронированной техники (с точки зрения защиты пехоты перехват должен осуществляться как можно ближе к танку; у самолётов – там ситуация иная, но это для другой записки).

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

Промежуточный итог: для медленных целей (500 м/с) времени на вычисление параметров и на сам перехват – целый вагон (у нас специально занижена потенциальная производительность ЭВМ). Выглядит всё реально.

Теперь предположим, что появились упомянутые в комментах гиперзвуковые кинетические снаряды. Скорость такого боеприпаса – 1500 – 2000 м/с. То есть, времени меньше в четыре раза (скорость в четыре раза выше). Но, собственно, для вычислительной части времени всё равно достаточно (мы же взяли самую медленную ЭВМ) и даже задержки на передачу данных опять не заметны. Если противоракета продолжает тратить 40 мс на прибытие в точку встречи, то гиперзвуковой снаряд за это время пролетает всего 80 метров, что укладывается в предложенную схему (дистанция 100 метров). Так что, в теории, не так всё плохо. А ведь есть ещё лазеры. Для перехвата.

После перехода на WordPress 3.0 из-за различий в API поломались во многих местах комментарии dxdt.ru: не работала (не выводилась) капча, в нестандартном формате выводились имена авторов комментариев (с лишними точками) и т.п. Сейчас всё поправлено. Спасибо всем, кто обратил внимание на возникшие неполадки.

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

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

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

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

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

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

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

Два заголовка из новостной ленты:

Компания “Сухой” завершила предварительные наземные и летные работы по программе создания истребителя 5-го поколения

На завершение работ по созданию истребителя 5-го поколения нужно еще 30 млрд рублей

Так что теперь дело за индусами. Благо, интерес они озвучивали. Собственно, следующий шаг как раз будет в направлении Индии (если только Штаты не надумают разрешить F-22 отдавать на экспорт).

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

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

Очевидно, что скоро подобные системы начнут продвигать на борт самолётов, как единственный эффективный способ борьбы с противовоздушными ракетами.

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

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

Вот, выходит, что ещё одно направление у РЭБ в “киберпространстве” возникает.

Многие используют Google в качестве калькулятора: вводим в поисковый запрос выражение, получаем результат вычислений. Учитывая, что Google всегда под рукой в браузере, такой путь удобнее стандартного варианта с вызовом программы калькулятора. А теперь представьте, насколько избыточен такой подход.

Посмотрим на процесс в деталях. Для проведения одной элементарной операции с целыми числами задействуется огромное число компьютеров: начинается всё на локальном ПК с браузером, выполняющим сотни тысяч арифметических операций (аналогичных по сложности исходной операции) для формирования http-запроса; дальше работают десятки маршрутизаторов, пересылающих пакеты, каждый из которых опять же выполняет сотни арифметических действий; пыхтит коммуникационное оборудование на более низких уровнях модели OSI, и это оборудование тоже много вычисляет, упаковывая пакеты в каналах, кодируя и декодируя данные; лишь потом приходит черёд серверов Google, которые запрашивают базы данных (потому что всё равно идёт поисковая выдача).

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

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

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

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

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

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

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

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

Новостные агентства (АРМС-ТАСС) делятся показательными цитатами:

Объединенная авиастроительная корпорация (ОАК) получила уведомление США, “практически запрещающее поставки в Иран самолетов Ту-204″…

Причина в том, что самолёт должен летать благодаря Pratt & Whitney, а это штатовская компания:

…в двигателях [Ту-204] используются комплектующие американской моторостроительной компании “Пратт энд Уитни”.
[…]
Авиалайнер оборудуется двигателем ПС-90А2, созданным пермским ОАО “Авиадвигатель” в сотрудничестве с “Пратт энд Уитни”.

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

Авиационные двигатели всегда были проблемой, и не только в советском самолётостроении. Но в данном случае интересны именно формулировки в прессе (а здесь речь о трансляции позиции PR-службы ОАК, это нужно учитывать), когда в одном ряду и “запрет на поставки” и “сотрудничество”.

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

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

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

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

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

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

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