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

Под брендом регистратора R01 заработал бесплатный сервис WhoisHistory.ru, позволяющий просматривать административную и техническую историю использования доменов .ru, .su, .рф. Отображаются изменения администраторов, контактных данных, серверов имён и другой информации. Есть расширенный поиск доменов по различным критериям, например, по NS-ам, по IP, по организации, регистратору и так далее.

Думаю, это первый бесплатный сервис подобного типа для российских доменов. Сайт: whoishistory.ru.

В свете падения известных хостингов, которое сейчас обсуждают, поделюсь описанием того, как работает и где размещается dxdt.ru. Сайт я разместил на амазоновском EC2, на виртуальном сервере (сервер типа Small Instance). Операционная система Amazon Linux (это, по сути, Red Hat). Веб-сервер – Apache 2.2. Непродолжительное время использовал nginx в качестве обратного прокси к Apache, но, пока что , особого смысла в nginx, конкретно для dxdt.ru, не вижу: монструозный Apache справляется с небольшим трафиком.

БД – MySQL, на том же сервере; иногда с аппетитом кушает память. PHP + APC (это “ускоритель” PHP, как известно) + WordPress + кэшируюший плагин W3 Total Cache (очень полезный плагин оказался).

Есть поддержка HTTPS, но я использую собственный корневой сертификат (и это правильно, для данной модели), так что попытка обратиться по HTTPS стандартным браузером приведёт к ошибке/предупреждению. Понятно, что HTTPS предназначен для админки WordPress-а (WP). Тут надо заметить, что разработчики WP никак не допилят поддержку HTTPS, поэтому в некоторых случаях страницы (не принадлежащие к админке) генерируются с элементами, адресуемыми по HTTP (обычно, это картинки). Возможно, есть какой-то плагин, решающий эту проблему.

В целом, WP – неплохая CMS. Есть планы (о которых мне периодически напоминают) переписать dxdt.ru руками на специальный “движок”, отказавшись, наконец, от PHP. Интерес тут чисто спортивный. В качестве снарядов для данного спорта я сейчас рассматриваю связку Python + Django + MongoDB + какой-то не-Apache (nginx?). Но это планы, да.

Опыт использования амазоновского хостинга для dxdt.ru положительный. Доступность хорошая. Ресурсов хватает. Гибкости тоже. Нет трудностей с IP-шниками (кстати, важный фактор!). Например, удалось оперативно и без всяких проблем настроить обратную зону для IP-адреса dxdt.ru (это нужно для отправки почты с сервера) и всё такое прочее. Преимущество амазоновского сервиса в том, что тут предоставляется инфраструктура, то есть можно самостоятельно быстро поднять нужные серверы, что-то настроить, переключить адреса, ну и так далее. Это уровнем выше аренды обычного виртуального сервера, и удобнее, чем один физический выделенный сервер. Вообще, я амазоновским EC2 пользуюсь несколько лет, но для совсем других задач – сайты раньше там не хостил, а оказалось, что и для этого весьма хороший вариант. Кстати, домен dxdt.ru я поддерживаю тоже на паре NS-ов, находящихся в EC2 (это не амазоновский DNS, а виртуальные серверы с BIND-ом – всё жду, когда же КЦ и ТЦИ доделают DNSSEC в .ru, чтобы быстро внедрить поддержку, да, видно, нескоро это будет).

Вот.

Update (18/04/2014): эта записка некоторое время не обновлялась, а между тем, ещё в декабре 2012 года, в домене RU внедрили поддержку DNSSEC; конечно, домен dxdt.ru был подписан одним из первых.

Update (24/11/2014): c 21 ноября 2014 года dxdt.ru возвращает страницы только по HTTPS – этот безопасный протокол стал единственным для работы с сайтом.

(Вынесу сюда из комментов.) Как, в общих чертах, работает спуфинг для GPS? Чтобы разобраться, нужно вспомнить, что такое сама эта GPS в генеральном, так сказать, смысле. GPS позволяет приёмнику определить с высокой точностью расстояние до нескольких спутников, входящих в состав системы. Расстояние вычисляется на основе принимаемых со спутников радиосигналов, ключевыми моментами является знание точного времени, действующего во всей системе (приёмник + спутники), и информация о точном местоположении спутников в каждый момент времени. Дальше – чистая геометрия. Понятно, что для практической работы простого приёмника потребуется четыре спутника (почему, кстати, не три?), до которых известно расстояние, и так далее, и тому подобное.

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

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

Теперь предположим, что навигационная система использует несколько “внешних” источников навигационной информации. Например, GPS + ГЛОНАСС. С одной стороны, такая система может обнаружить расхождение между показаниями, если GPS “подспуфили”. Но не ясно, что в таком случае этой системе делать? Она не может определить, происходит ли спуфинг GPS или, наоборот, ГЛОНАСС. И почему, кстати, GPS заслуживает меньшего доверия, чем ГЛОНАСС? Если отключать навигацию при каждом расхождении показаний, то возникают новые требования к синхронности двух независимых навигационных источников. То есть, дополнительный риск отказа без всякого спуфинга.

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

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

Занятно, что, как рассказывают, для того чтобы воспользоваться дефектом в сервисе App Store, позволяющим бесплатно приобретать всякие дополнения к приложениям (которые, штатно – платные) требуется установить специальные доверенные SSL-сертификаты и поменять настройки DNS. Да, а потом будут удивляться очередному “мобильному” ботнету. Но уровень реализации сервисов Apple, конечно, впечатляет. В плане безопасности. Наверное, там есть какая-то причина, по которой они не привязывают сертификат от подобных API к “своему” УЦ.

В Интернете публикуют файл с пользовательскими паролями, стащенными, как пишут, из некоторого сервиса Yahoo! Сейчас пароли меняют. Традиционная статистика по лидерам среди пользовательских паролей (посчитал по исходному файлу, указаны пароли с числом вхождений больше 128):

123456:1667
password:780
welcome:437
ninja:333
abc123:250
123456789:222
12345678:208
sunshine:205
princess:202
qwerty:172
writer:164
monkey:162
freedom:161
michael:160
111111:160
iloveyou:140
password1:139
shadow:134
baseball:133
tigger:132
1a1a1a1b:131

1a1a1a1b – неплохой вариант, кстати. Интересно, если перечень реальный, то, после того, как пользователей попросят сменить пароли, сильно ли изменится рейтинг? Например, вместо 123456 – в лидеры может выйти 111111. Какой вообще смысл просить менять пароли, если политика позволяет использовать слабые варианты? Которые, к тому же, хранятся в открытом виде.

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

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

Обновилась БД на dns.dxdt.ru. Впрочем, пока что наиболее активный посетитель проекта – Google bot: очень активно ходит по внутренним ссылкам. Между тем, dns.dxdt.ru – инструмент, на мой взгляд, полезный, хотя и специальный, требующий понимания того, что ищем. Посмотрите, вот ссылка на занимательный кластер “фармацевтических” доменов (легальных, например, упса.рф). Для них в DNS зачем-то указаны “дефектные” IP в A-записях: 0.0.0.0, 1.1.1.1 и т.п.

Всяких занятных кластеров много. Может, сделать какую-нибудь автоматическую-тематическую кластеризацию?

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

Вот такие коты водятся в наших местах.

На фото ниже – C-5M (большой) и MC-130J, то есть, соответственно, представители стратегической и тактической составляющих штатовской военно-транспортной авиации. MC-130J Commando II (на снимке именно он) – это такой яркий образчик тактического крыла: самолёт, используемый силами специальных операций, предназначен для обеспечения дозаправки вертолётов, а также скрытной доставки грузов на территорию противника. С C-5M, думаю, и так всё понятно.

(Фото – Lockheed Martin, отсюда.)

Кстати, для провайдера, заблокировать доступ к сайту по IP-адресу – это самое простое решение, потому что IP-маршрутизация большей частью работает, примерно, на аппаратном уровне. То есть, очень быстро и прозрачно. А вот блокирование на уровне прикладных протоколов (DNS, HTTP), позволяющее сделать блокировку более избирательной – это уже сильно другая задача. Тут требуется анализ содержимого пакетов, а не заголовков, который тянет за собой дополнительное ПО и заметные вычислительные мощности.

Хотя, надо заметить, блокирование по прикладным протоколам математически выглядит куда более правильным – ведь для чтения сайтов используют именно их. В плане реализации особенно занимательно выглядит инспектирование HTTPS, да. Ну а верный способ построить эффективную систему, это строгий контроль пользовательского ПО, служащего для просмотра Интернета.

IETF предлагают новый код состояния HTTP (это, грубо говоря, ответ сервера): 451 Unavailable For Legal Reasons. Обратите внимание на числовое значение кода.