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

Ремарка к новостям блокирования: занятно, что на IP 216.239.32.21 – указывает около 7 тыс. доменов .RU, .SU, .РФ, и это IP из пула Google.

Тут спрашивают, достаточно ли устроить DNS-резолвер на собственном сервере или использовать сервис наподобие Google Public DNS, чтобы меньше беспокоиться о подмене ответов DNS (которые могут увести куда угодно)? Нет, не достаточно. Ключевой момент тут в IP-адресах. Предположим, что у вас настроен в качестве резолвера собственный сервер (пусть это будет BIND), доступный по IP-адресу 1.2.3.4. Откуда ваша локальная операционная система знает, что, отправляя запросы и получая ответы от 1.2.3.4, – она “разговаривает” именно с нужным резолвером?

Если в качестве точки перехвата трафика используются ближайший к вашему узлу шлюз, то очень легко сделать так, что по адресу 1.2.3.4 будет отвечать какой угодно подставной сервер. Посудите сами: сейчас даже новомодные точки доступа WiFi используют такую технологию, чтобы вместо нужного сайта показывать в браузере собственную страницу с сообщением об “ошибке соединения”, если там, например, кабель выпал (делать так, конечно, форменное безобразие). То же нередко реализуют интернет-провайдеры. Технология простая: маршрутизатор, вместо того, чтобы отправить пакеты в Интернет, перенаправляет их внутреннему узлу. Так что на запрос к 8.8.8.8 (гугловский DNS) может поступить самый неожиданный ответ: mail.google.com = 192.168.1.1. Более того, благодаря возможностям по спуфингу, существующим в типичной локальной сети, перехватить трафик может не только маршрутизатор. Ну и существует ещё несколько способов, позволяющих подставить другой сервер вместо вашего резолвера. Что, кстати, напоминает ситуацию со спуфингом GPS. (Как страшно жить.)

Возвращаемся к DNS. Что делать? А просто не нужно забывать об аутентификации. Так, если вы используете свой резловер без VPN, то потребуется настроить TSIG – то есть, подписывание запросов и ответов клиентом и сервером, стандартный механизм при обмене файлами зон.

Я делаю так: на локальной машине в качестве резолвера поднят BIND с поддержкой TSIG, для него в качестве “форвардера” настроен сервер резолвера – в файле конфигурации named.conf директива forwarders:

forwarders {
1.2.3.4;
};

(1.2.3.4 – IP-адрес резолвера).

Для удостоверения сообщений требуется общий секретный ключ. Его можно сгенерировать утилитой dnssec-keygen, входящей в пакет BIND9:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST megakey

(пояснения к параметрам: тип алгоритма HMAC-MD5, 128-бит, ключ для хоста).

Результатом работы является пара файлов, примерно с такими именами: Kmegakey.+157+14629.key и Kmegakey.+157+14629.private. Значение ключа, в виде строки Base64, можно взять из .private. Ключ, понятно, секретный.

Теперь в конфигурацию обоих BIND-ов, на клиенте, и на сервере, нужно добавить записи о ключе и директивы, предписывающие этот ключ использовать. Самый правильный способ: ключи вынести в отдельный файл, защитить его правами доступа, а в конфигурацию добавить с помощью include. Что, кстати, на отдельном виртуальном сервере может оказаться избыточным.

Описание ключа, для speckey.conf.key или прямо для named.conf:

key “resolver-key” {

};

Понятно, что SuperMEGAKey допустимо заменить на ваш собственный секретный ключ.

Назначение ключа узлу (серверу), в named.conf, ничего секретного в строке нет:

server 1.2.3.4 {

};
};

Здесь 1.2.3.4 – адреса узлов: на клиенте – серверный адрес, на сервере – клиентский.

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

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

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

Между тем, повысить надёжность поддержки DNS не так уж и сложно. Есть такой понятие, как вторичный сервер DNS (slave, secondary) – этот сервер получает данные об адресации внутри домена (файл зоны) с первичного или другого вторичного сервера, то есть, просто копирует данные, в автоматическом режиме. Понятно, что клиенты могут использовать для получения адресной информации и первичный, и любой из вторичных серверов. Разумно использовать в качестве вторичных серверы, расположенные в другом регионе, у другого провайдера, и так далее. То есть, построить систему, распределённую в техническом и административном смыслах. В таком случае авария серверов имён у одного провайдера не будет приводить к отказу домена в целом, то есть, сайт будет доступен.

Услуги поддержки вторичных серверов предоставляют все более или менее продвинутые DNS-хостеры. Скажем, RU-CENTER, GoDaddy и EasyDNS.

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

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

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

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

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

Но, во-первых, массовый пользователь игнорирует подобные предупреждения браузера, “заставляя” тот продолжить использование веб-сайта. Во-вторых, нет особых гарантий того, что удостоверяющие центры, входящие в список доверенных браузера, не участвуют в работе систем DPI. Собственно, вокруг второго момента, который, вообще-то, давно известен, сейчас разгорелся нешуточный сыр-бор. В случае, если автоматический инспектор трафика использует для генерации своих “перехватывающих” сертификатов сертификаты доверенного УЦ (не обязательно корневой, годятся промежуточные), то обычный пользователь браузера даже не увидит предупреждения, не заметит подмены. (Кстати, есть неплохой плагин для Firefox, позволяющий следить за тем, как браузер оперирует сертификатами – Certificate Patrol.)

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

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

Кстати, фокусам с подменой SSL-ей отчасти может помешать внедрение технологий вроде DANE. Но нужно учитывать, что, в теории, тот же DANE, если говорить о типичном пользователе Интернета, перехватывается аналогичными SSL методами, здесь лишь сильно сужается круг тех, кто может осуществить такой перехват. Что, логичным образом, возвращает нас к мысли о реальных причинах шума, высказанной в самом начале заметки.

Под брендом регистратора 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 и т.п.

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