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

Ботнеты, по логике, должны находиться на переднем крае технологий распределения нагрузки или, если хотите, создания высоконагрузочных систем. Но почему-то о ботнетах не очень часто и подробно рассказывают на технологических конференциях.

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

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

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

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

Когда об этом расскажут на технологических конференциях?

Уже сильно больше года домены в зоне .RU открыто предлагают “в розницу” по цене регистрации значительно ниже установленных правилами 500 рублей (+100 руб. НДС). Если называть вещи своими именами, то имеет место некий демпинг: домены предлагают зарегистрировать, например, по 300, по 200, по 99 рублей.

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

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

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

По следам недавнего падения “Яндекса” “из-за проблем маршрутизации” в блоге “Яндекс.Поиск”, очевидно, не нашли ничего лучше, как воспользоваться собственным яндексовским сервисом “Рефераты” для генерирования ТЗ на “спасительное решение для яндексовского NOC”. Судите сами, цитата:

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

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

Кстати, внедрение DNSSEC приведёт к появлению новых типов атак на DNS, среди которых есть довольно интересные и неожиданные (впрочем, два упомянутых ниже типа специалистам давно известны и описаны в соответствующих RFC, но тем не менее).

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

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

На первый технологический конкурс веб-сайтов в Рунете – WebHiTech – очередной вал заявок. Этот вал, судя по всему, объясняется тем, что завтра (25 сентября) заканчивается приём заявок. Все спешат вскочить в последний вагон. А вообще статистика по конкурсу такая:

По состоянию на 23 сентября, оргкомитетом получено 275 заявок. Из них рассмотрено 269. 133 проекта допущено к участию в конкурсе, 136 заявок отклонено.

То есть, отбор суперстрогий: менее половины заявленных сайтов проходят в номинанты. Заявки отборочный комитет отклоняет с подробными объяснениями причин. Интересно, что целый ряд проектов активно приходили “на пересдачу”: вносили изменения на сайты и подавали заявки вновь.

Дальнейшие планы конкурса такие: в октябре жюри проголосует и определит победителей и призёров в трёх номинациях (но не только в них, потому что есть ещё секретная номинация – да, для особенно прилежных веб-мастеров, – и специальные призы). Работа жюри займёт весь октябрь. А уже где-то в ноябре мы публично объявим победителей и устроим церемонию вручения призов. Так что будет интересно.

Как известно, 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 параметров упоминаются только синонимы домена – и всё, несмотря на заявленные “все характеристики”. Это кошмар.

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

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

Безопасность веб-сайтов и окружающие эту безопасность вопросы постоянно возникают при обсуждении 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.

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

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