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

Продолжаем неделю интернет-адресации на 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:

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

Тендер на техническое управление всей адресацией в Интернете – фактически, отменили (но будут проводить ещё один похожий). Официальная причина проста: не собрали достойных предложений. Напомню, что речь о так называемой IANA-функции, то есть, о важнейших технических рычагах, вроде распределения номеров автономных систем, IP-адресов, управления корневой зоной DNS. Ответственную организацию назначает минторг США, по результатам изучения предложений, мнения рынка и мнения сообщества.

Если в двух словах, то это означает, что ситуация с контролем над Интернетом становится всё интереснее. Сейчас IANA-функцию выполняет ICANN. Естественно, ICANN выдвигалась и в новом тендере, собирала поддержку от международного интернет-сообщества. Но, если бы всё было гладко, то минторг, в итоге, именно ICANN мог бы и выбрать, по накатанной, так сказать. А тут вот как вышло: “не получили ни одного подходящего предложения”.

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

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

Да, текстовый канал можно отслеживать, анализируя записи и убивая всё подозрительное, что не является текстом на естественном языке. Это не исключает связь, прикрытую стеганографией, но гарантированно делает скорость обмена совершенно мизерной – сгодится разве что текстовые петиции распространять. Но остаются файлы изображений, а здесь можно надёжно спрятать довольно большой трафик. Проблема, верно?

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

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

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

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер DNS, налаженный внутри VPN?

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

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

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

Другое решение – держать рекурсивный резолвер локально, на своём ноутбуке. Я не уверен, может ли это делать Windows (наверное, может), но с юниксоподобными системами проблем нет, достаточно поднять локальный BIND. Трафик резолвера нужно завернуть в VPN, это обеспечит секретность. (Тут есть подводный камень: использование NAT, – а трафик из VPN во внешний мир может выходить именно через NAT, – грозит тем, что испортится один из защитных механизмов DNS, который называется “рандомизация портов UPD на источнике запроса”; но это другая история.) А главный недостаток один: нужно на каждом клиенте VPN держать свой рекурсивный резолвер. Неудобно. Поэтому куда более логично разместить собственный резловер на сервере, обеспечивающем VPN. Всё равно этот сервер работает постоянно.

А кроме того, редкий провайдерский резолвер поддерживает DNSSEC. Я таких вообще не видел.

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

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