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

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

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

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

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

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

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

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

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

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

На сайте GPGPU, посвящённом вычислениям с использованием графических ускорителей, – подборка ссылок на криптологические продукты, касающиеся перебора MD5 по большей части.

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

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

Вот. Есть и другой важный момент.

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

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

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

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

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

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

Управление доменами также реализовано непонятным образом: ой как не просто найти способ сменить NS-ы, скажем.

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

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

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

В продолжение недавней записки про “Касперских” – такой продукт, как Nod32 Smart Security, оказался весьма неплох. Удобный интерфейс, понятная логика. При этом по уровню замедления компьютера – “Касперские” даже и близко не стояли, Nod32 ощутимо быстрее. Рекомендую переходить.

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

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

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

При составлении собственного представления о безопасности использования конкретной CMS нужно учитывать её отношения с уязвимостями. Тут есть свои важные моменты. Например, то, что сайты под некоторой CMS “Имярек” “за отчётный период” не были взломаны, никоим образом не означает, что “Имярек” сколь-нибудь надёжна и безопасна. Почему? Потому что отсутствие взломов сайтов ничего нам не говорит о безопасности CMS.

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

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

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

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

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

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

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

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

Эта заметка – начало серии записок про выбор CMS и про безопасность CMS. Продолжение – в следующий раз. Кстати, в продолжении: нужно ли выбирать распространённую CMS? Платная или бесплатная? Что со “стоимостью владения”? и всякие другие интересные моменты.

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

Как известно, многоязычные домены устраивают таким образом, что на клиентской стороне многоязычное имя преобразуется в допустимую к использованию в DNS “абракадабру” из ASCII-символов. Например, “бармалей.ru” кодируется в XN——80AABSUKF5A.RU. То есть, с формальной точки зрения, никакого расширения алфавита в собственно DNS не происходит, а предлагается лишь начать регистрировать “абракадабры” строго определённого вида.

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

С другой стороны, все эти мероприятия по набиванию “абракадабры” в командную строку – прямо противоречат исходным целям DNS, ради которых она создавалась. Ведь доменную систему имён придумали как раз для того, чтобы вместо численной “абракадабры” (IP-адресов) предложить пользователям-человекам удобные для запоминания, “мнемонические” адреса (компьютерам-то DNS вообще не нужна). Однако вряд ли XN——80AABSUKF5A – это удобная для запоминания строка. Так что админы оказываются вытеснены в такую область, в которой назначение DNS становится каким-то другим. Как бы даже и противоположным, ведь запомнить “XN——…” – может быть сложнее, чем IP-адрес. (Тут, конечно, ситуация выглядит ещё более забавной, если вспомнить, что админов планируют пересадить на IPv6, но это уже другая история.)

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

И, понятно, что админам никуда не деться. В своё время они, по сходным причинам, переучивались, скажем, на Windows.

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

Как известно, новая версия программного продукта “Лаборатории Касперского” (KIS-2009) предлагает пользователю присоединиться к сети “Kaspersky Security Network”, формально для того, чтобы отправлять в лабораторию сведения о новых вирусах. Но, судя по всему, это такой первый (или второй?) шаг на пути “преобразования” компьютеров пользователей продуктов “Касперских” в узлы распределённой вычислительной сети.

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

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

Кстати, то, что некоторая CMS насчитывает N (N<10000) установок и при этом ни разу не была взломана – никак не гарантирует, что данная CMS сколь-нибудь защищена и безопасна; более того, такой показатель вообще не позволяет “определить безопасность” CMS.