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

Начался приём работ на конкурс WebHiTech-2012. В этом году заявки принимаются по новой схеме, качество каждой оценивается жюри уже на этапе отбора. Подать заявку можно на сайте конкурса.

Как известно, почтовые серверы, принимающие почту для адресов заданного домена, обозначаются при помощи MX-записей. Я собрал значения этих записей со всех делегированных и доступных в DNS доменов .RU (по состоянию на 15.04.12). Собственно, интересно было посмотреть, как используются сервисы для доменов от “Яндекса” и Google (с хостерами и так всё ясно).

Итак, “Яндекс” (“Почта для домена”) предлагает установить в качестве значения MX-записи – mx.yandex.ru. То есть, можно предположить, что если у домена такая MX-запись, то, с большой вероятностью, этот домен используется для яндексовского почтового сервиса. Таких доменов удалось обнаружить 96201.

Google для своих Google Apps предлагает список из пяти почтовых серверов, все они встречаются сравнимое число раз, я взял в качестве показателя самый приоритетный (и самый распространённый) – aspmx.l.google.com. Такую запись удалось обнаружить для 97226 доменов.

То есть, примерно поровну. И примерно 96201+97226=193427 доменов второго уровня .ru используют сервисы электронной почты от поисковых систем. Впрочем, это всего лишь ~5% от общего числа зарегистрированных доменов. Мало. Понятно, что подсчёт MX-записей даёт несколько размытую картину, так как администраторы доменов нередко настраивают DNS с ошибками. Но, тем не менее, показатели информативные.

Дефект (скорее, уязвимость) в интерфейсе приёма заявок на New gTLD ICANN признала 12 апреля, хотя, подтверждают, что сообщения о проблемах от пользователей поступали с 19 марта. Сегодня – 14 апреля, и пока что ICANN, в своём стиле, только обещает 16 апреля сообщить о том, смогут ли они возобновить приём заявок 17 апреля.

Вчитайтесь: через двое суток после аварии, ICANN, на полном серьёзе, выпускает официальное сообщение о том, что ещё через два дня опубликуют очередное сообщение, в котором будет уведомление о поступлении следующего сообщения. Это рафинированный образец бюрократии в действии.

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

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

Впрочем, посмотрим, как оно повернётся.

Конкурс WebHiTech в 2012 году планируем проводить в новом формате. Старт приёма заявок – на РИФе, некоторые подробности – в официальном сообщении.

Ещё немного Интернета. Вот “Битрикс” с шумом запускает проект bitrix24.ru. Конечно, “облачный”. Позиционируют как корпоративный интранет. Естественно, всякое у них написано про то, как обеспечивают безопасность, что, мол, только по https, все дела. Цитата с сайта: “Безопасность вашей информации превыше всего!”. И, без сомнения, для корпоративного интранета безопасность действительно важна. Особенно, если какая-то компания удумает держать интранет в “облаке”, под “Битриксом”. Судя по всему, вертится проект на амазоновском EC2.

Но я о другом. Идём на https://bitrix24.ru/ и – любуемся на кривой самоподписанный сертификат, который отдаёт нам сервер:

Issuer: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;
Subject: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;

Тот же сертификат отдаёт www1.bitrix24.ru. При этом у проекта есть сертификат для *.bitrix24.ru – его отдают другие их веб-серверы.

А благодаря смелым настройкам DNS “Битрикс24”, можно открывать “сайт” под любым выдуманным (несуществующим) адресом третьего уровня внутри bitrix24.ru, например, http://alskdjfhg.bitrix24.ru/, и наблюдать страницу-заглушку, которая, судя по тексту, обозначает временную недоступность сервиса в целом. Поведение, очевидно, совершенно некорректное. (Update, 22.06.12: поведение исправили, показывают страницу “Несуществующий домен”.) Проявив чуть больше смекалки, и попробовав адреса уровнем ниже третьего (a.b.c.bitrix24.ru), повторно наблюдаем кривое использование SSL-сертификата, но теперь уже в случае с сертификатом для *.bitrix24.ru, который, вообще-то, при правильном применении, вполне себе валидный (выдан Go Daddy CA).

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

Дополнение (13.04.12): не менее показательно, что в разделе “Безопасность – техническим специалистам” на сайте написано буквально следующее (цитата): “на уровне операционной системы веб-серверов «Битрикс24» через сетевой экран закрыт внешний доступ по все портам, кроме 443”; но при этом нетрудно убедиться, что их веб-сервер охотно отвечает на 80 порту (301 Moved Permanently), перенаправляя на тот же IP, но на 443 порт. Понятно, что иначе и быть не может – пользователи не умеют https набирать.

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

Продолжаем неделю интернет-адресации на dxdt.ru. Я подумал, что данные по адресации внутри домена .ru, которые я извлекаю из DNS для того, чтобы собирать SSL-сертификаты с работающих веб-сайтов, довольно занятны сами по себе. В общем, сделал такой вот сервис: http://adr.dxdt.ru/ – он позволяет получить список доменов, а вернее, имён хостов, которые соответствуют заданному IP-адресу. Работает только для .ru. И не в режиме онлайн. Запросы можно делать простым GET-ом, формат описан на странице сервиса: там вообще только Apache, это такой очень простой сервис.

(Интересности: есть немало имён с адресом 1.1.1.1 или с адресом 0.0.0.0; само собой, распространен 127.0.0.1.)

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

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

RU-CENTER и ICANN реализовали совместный проект по инсталляции российского узла сервера L-Root.

Addon (05/04/2012): а вот и сообщение на сайте ICANN.

Вообще, локальных узлов корневых серверов много, адресуются они, обычно, с помощью anycast. То есть, обращаясь к тому или иному серверу по одному и тому же IP-адресу, но из разных сегментов Сети, вы будете попадать на наиболее “близкий” физический сервер. Расстояние тут измеряется в терминах топологии Интернета, конечно. Примерно так результат для l.root-servers.net теперь выглядит “с близкого расстояния”, из московского дата-центра:

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
1 MSK-KHOUSE-NR1.nic.ru (109.70.27.19) 0.772 ms 1.111 ms 1.245 ms
2 MSK-STD-NR1.nic.ru (193.232.147.215) 1.348 ms 1.351 ms 1.458 ms
3 l.root-servers.net (199.7.83.42) 1.226 ms 1.223 ms 1.213 ms

А вот вариант из Ирландии (Amazon, кусочек):

$ traceroute l.root-servers.net
traceroute to l.root-servers.net (199.7.83.42), 30 hops max, 60 byte packets
[…]
4 ec2-79-125-0-135.eu-west-1.compute.amazonaws.com (79.125.0.135) 0.684 ms ec2-79-125-0-133.eu-west-1.compute.amazonaws.com (79.125.0.133) 0.470 ms 0.453 ms
5 178.236.0.232 (178.236.0.232) 0.816 ms 178.236.0.124 (178.236.0.124) 1.403 ms 1.134 ms
6 178.236.0.124 (178.236.0.124) 1.117 ms 1.127 ms 178.236.0.131 (178.236.0.131) 1.229 ms
7 inex.woodynet.net (193.242.111.60) 2.421 ms 178.236.0.131 (178.236.0.131) 1.158 ms inex.woodynet.net (193.242.111.60) 2.602 ms
8 inex.woodynet.net (193.242.111.60) 2.343 ms 3.063 ms 2.784 ms
9 l.root-servers.net (199.7.83.42) 1.906 ms 1.865 ms 1.615 ms

В общем, больше серверов, хороших и разных.

(На правах технократического юмора.) Если вы хотите версию того, как можно вызвать аварию всех 13 корневых серверов глобальной DNS, то вот такой вариант: взломан скрытый сервер VeriSign, с которого раздаётся зона на эти самые корневые сервера. В результате, 31 марта, хакеры распространят испорченную корневую зону. DNS сломается. Не требуется даже генерировать подписи DNSSEC, ведь задача состоит не в том, чтобы подменить адресацию, а в том, чтобы всё сломать.

В ноябре прошлого года при обходе зоны .ru (для доменов вида [www.]domain.tld в DNS искалась А-запись) удалось получить адреса для 2762616 имён. По состоянию на 27.03.2012 – таких имён удалось найти уже 2993620. Прирост – 231004 домена.

По IP-адресам: уникальных IP – 204275. Прирост (относительно 09.11.11) – 16944 адреса. Поделим приросты: 231004/16944 ~13.6 домена на один IP-адрес. Впрочем, это такой очень размытый показатель. Для всей зоны тот же показатель составляет ~14.6 домена на IP-адрес.

Обнаружилось 246624 домена (~8.2%) для которых указано более одной А-записи. Нашлось 14 IP-адресов, на каждый из которых указывает более 10000 доменов .ru. Рекорд, как обычно, за доменной парковкой Sedo – 141407 доменов указывают на один IP, относящийся к этому сервису.

“Яндекс” в своём репертуаре. Сравниваем результаты поиска по запросу “DNSSEC пример”, в Google на первом месте ссылка на nox.su, потом подробная статья на “Хабрахабре”, ссылающаяся на nox.su, и т.д., добротно, в общем:

Теперь “Яндекс” – тут nox.su вообще нет в выдаче, наверху статья с “Хабрахабра” и другие тематические страницы, которые ссылаются на nox.su:

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