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

Рейтинг CMS от iTrack – довольно странный: не приводят количества сайтов в выборке (типа, 2 млн доменов второго уровня .RU обошли, хотя там не все делегированы, много сайтов на третьего уровня доменах) и не публикуют, на скольких сайтах из выборки установлены коммерческие CMS. Без этих данных рейтинг бесполезен.

Особенно забавно выглядит “подробное” описание методики: не публикуется список “сигнатур”; куча странных для изложения методики исследования фраз, типа “…учитывались домены, ответившие в течение 4 секунд на запрос по адресу http://domain.ru.” (какой запрос? почему в течение 4 секунд? что значит – “ответивший домен”? и т.п., и т.д.) Очень сомнительно.

Впрочем, довольно занимательна вот какая “аппроксимация”: S.Builder пишет на сайте, что на их CMS сделано более 3500 сайтов. Предположим, что сайтов 3500, и это всё сайты на доменах второго уровня в .ru (наилучший для рейтинга вариант). В рейтинге iTrack у S.Builder – 4% от всех коммерческих CMS. Это даёт оценку количества всех сайтов на коммерческих CMS в 87500 (понятно, что всё приблизительно). То есть, если продолжать в терминах рейтинга iTrack, общая доля всех платных CMS – всего около 4.4% от объёма сайтов. В десять раз меньше, чем у WordPress, например. (Реально, я думаю, платных российских CMS использует ещё меньше, чем 4% от всех сайтов.)

Кросс-пост отсюда: http://1.dxdt.ru/2009/07/20/

Новые правила регистрации доменов .RU – опубликовали, с разъяснениями про “предоставление документов”. В общем-то, вполне ожидаемо, метод предоставления копий “удостоверяющих данные” документов отдан на откуп регистраторам:

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

Интересно, когда начнут работать по “сканам”, присланным по электронной почте, как быстро найдётся специалист, который зарегистрирует домен на Васю Пупкина, прислав отличный “скан” “паспорта”?

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

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

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

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

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

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

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

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

Вот.

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

В адресном пространстве тесно. Говорят, что хороших доменов вообще не осталось. Вот по ссылке ниже (papyrus.ru) группа специалистов будет делиться неплохими свободными доменами, а точнее – доменными идеями. Получается такой список интересных доменных имён, которые доступны для регистрации (по whois) на момент опубликования.

(Кросс-пост отсюда: http://1.dxdt.ru/2009/06/17/.)

Сегодня немного “техничная” записка. Есть такой положительно оцениваемый админами и, очевидно, отличный продукт: веб-сервер 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), который в выступлении по радио высказывался за создание “официальных” ботнетов (ну, почему-то именно ботнетов) и средств нападения в киберпространстве Интернета.

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

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

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

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

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

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

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

Например, в ICANN тоже есть представители самых разных государств в комитетах. ICANN то и дело затевает разнообразные “публичные общественные обсуждения”. Но решения всё равно утверждает Минторг США.

Вообще, если взглянуть внимательнее на то, как строго штатовский минторг контролирует процедуру внедрения DNSSEC, становится ясно: там отлично понимают устройство реальных механизмов управления Глобальной Сетью и выпускать их из-под контроля не собираются.

Вот, кстати, первым источником уязвимостей в реализациях 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-трафик мало кто фильтрует.

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

Очень интересно следить за реакцией массовой аудитории на недавно запущенный домен верхнего уровня TEL. Как я уже писал, TEL задуман как обозначение глобальной базы данных, работающей на основе DNS и хранящей контактные и всякие персональные данные. Всё работает исключительно внутри DNS, используя DNS-запросы и серверы. Это основная хитрость.

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

Отношения Веба и TEL вообще сложные: хоть домен и позиционируется как “исключительно DNS”, администратору пришлось запустить proxy-сервис, который показывает содержание доменной зоны через Веб. См., например, nadya.tel браузером. Зачем? Да просто без подобного веб-туннеля массовой аудитории вообще нечего было бы показывать о домене. Ведь аудитория привыкла, что Интернет виден через веб-браузер – и только. Строки текста, возвращаемые (для тех, кто в курсе) dig – вообще непонятны. Приложения, извлекающие контакты из TEL через DNS, воспринимаются как “локальные адресные книги” и с Интернетом, в понимании пользователя, не связываются. Выходит, что TEL пытается бороться с Вебом. Весьма рискованная для TEL борьба.

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

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

Посмотрим, что там из TEL выйдет.

WebHiTech – это технологический конкурс веб-сайтов. Первый такой в Рунете. В прошлом году мы успешно провели первый из WebHiTech`ов. В этом году планируем очередной: WebHiTech-2009. То есть, конкурс должен стать ежегодным и регулярным. Правила, регламент – остаются практически без изменений, хотя некоторые нововведения по процедуре есть, но об этом несколько позже. Принимать заявки начнём осенью. В оргкомитете председательствует Артемий Ломов.

На данный момент главная новость такая: открыт сайт конкурса в новом дизайне. Пожалуйста, смотрите по адресу: http://www.webhitech.ru/. Кроме того, у конкурса обновлённый логотип.