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

Вот, старая тема вновь всплыла: говорят, что в Штатах записывают все телефонные разговоры внутри страны, чтобы потом, если вдруг, то запись поднять и прослушать.

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

Если есть система распознавания речи, то объём данных можно резко сократить, сжимая текстовое представление, полученное после расшифровки аудиосигнала. В таком варианте нет никаких проблем с хранилищем: люди за год не наговорят даже на сотню жёстких дисков. Распознавание не требуется вести в реальном времени, можно устроить буферную зону из которой данные перетекают в текст по мере обработки. Очевидно, что фрагменты, которые не удалось уверенно распознать, можно сохранять в звуковом виде, в качестве дополнения к текстовой расшифровке.

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

Интересное наблюдение. Издание “Лента.ру” – lenta.ru – обновило дизайн, не так давно. Вместе с дизайном, конечно, обновилась вёрстка страниц. Некоторое время назад я отметил, что верстальщики новой “Ленты” используют элемент HTML5 time без понимания, что это такое за элемент, демонстрируя, тем самым, карго-культ HTML5. В тот раз time использовали для “обрамления” строки, содержащей время публикации новости или статьи, при этом формат использовали вот такой (значение я, для примера, взял произвольное): “12:31, 31 января 2013“. Соответствующий код (неверный!):

<time>12:31, 31 января 2013</time>

Поясню: спецификация требует указывать время для time в машиночитаемом формате, либо внутри самого элемента, либо в атрибуте datetime. (Обратите внимание на этот атрибут – он чуть позже сыграет ключевую роль в карго-культе.) Собственно, элемент time для автоматической обработки и придумали, поэтому машиночитаемый формат необходим. “12:31, 31 января 2013” – формат, понятно, неверный. Смысла в подобном использовании time нет.

Теперь в “Ленте” подкорректировали вёрстку. В time добавлен атрибут datetime. Замечательно. Казалось бы, так и надо. Дело в том, что использование атрибута datetime, содержащего машиночитаемое представление времени, позволяет указать внутри самого элемента что угодно, в том числе, и “кириллическую” строку с названием месяца. Казалось бы, исправили ситуацию. Но, внимание: разработчики “Ленты” предпочли в качестве значения этого атрибута установить ту же самую строку недопустимого формата, которая раньше стояла только внутри time. Например: datetime=”10:41, 12 февраля 2013″. Просто скопировали, видимо.

И вот мы получили очередной карго-культ HTML5, включающий сложный обряд из двух ходов. Почему подобное происходит именно в “Ленте”? Вопрос риторический.

Меня попросили поделиться инструкцией о том, как настраивается VPN с использованием виртуального сервера из амазоновского EC2 (часть AWS – Amazon Web Services). Инструкцию размещаю на dxdt.ru, ведь в современном Интернете VPN – полезный инструмент. Подобные инструкции есть в Сети, но я попробовал ещё раз пройти всё детально по шагам, собрать все этапы вместе, включая настройку DNS. Более того, в рамках данной инструкции мы ещё разберёмся с созданием собственного “удостоверяющего центра” для выпуска SSL-сертификатов и создания инфраструктуры для аутентификации узлов. И DNS, и особенности управления сертификатами (отзыв сертификатов; проверка имён, например, при помощи директивы VPN tls-remote) – среди тех ключевых моментов, о которых постоянно забывают, настраивая “личный” VPN.

О том, для чего в технократическом хозяйстве пригодится VPN – я писал раньше, и не один раз. Если вдруг кто забыл, то под VPN подразумеваются зашифрованные каналы связи, организованные поверх открытого Интернета и ведущие от клиента к серверу VPN, при этом множество клиентов может быть объединено в виртуальную сеть. Главная особенность: трафик, идущий по VPN, практически недоступен для анализа и перехвата.

Описание длинное, с картинками, поэтому прячу под “Читать полностью”.

Читать полностью

Тут спрашивают, достаточно ли устроить 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, особого смысла вводить дополнительную проверку транзакций нет. Хотя, можно и ввести, конечно. Всё зависит от типа паранойи.

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

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

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

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

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

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

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

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

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

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

Update: сервис, описанный в этой заметке, более не доступен.

Сделал вот сервис dns.dxdt.ru – позволяет искать сведения об адресации, связанные с DNS. Бета-версия. За веб-интерфейсом скрывается база данных из примерно 13 млн документов, которые были получены при помощи опроса доменных зон .ru, .su, кириллической .рф.

Зачем нужно обходить доменные зоны? Давайте вспомним, что DNS работает “напрямую”, то есть в ответ на запрос о “буквенном имени” выдаёт IP-адрес, адрес почтового сервера или ещё что-то. Получить ответ на обратный запрос – “какие домены используют указанный IP-адрес?” – средствами DNS, в общем случае, нельзя. Есть специальные исключения, обратные зоны, но это совсем другая история. Поэтому для того, чтобы провести какой-то поиск, найти “соседей” данного сайта, вычислить общие черты, ещё что-то исследовать – нужно предварительно построить слепок сегмента DNS, опросив серверы имён и сохранив результаты. Собственно, отсюда и получаются все эти миллионы документов.

Как работает dns.dxdt.ru? Интересно было попробовать современные решения. Поэтому в качестве СУБД выбрана MongoDB – это NoSQL СУБД. Сам сервис использует два сервера минимальной конфигурации из амазоновского EC2: на одном работает MongoDB, это, так сказать, “бекэнд”, на втором – связка Apache, PHP, Memcached, это, стало быть, “фронтэнд”. Была идея использовать на “фронтэнде” Ruby, но данный язык, вполне ожидаемо, оказался чудовищно медленным. Отказался. Memcached кэширует не ответы БД, а форматированные результаты выдачи (то есть, итоговые HTML-страницы), что сильно ускоряет работу на повторяющихся запросах. При этом, впрочем, остаётся проблема с доставкой клиенту больших по объёму страниц: некоторые запросы генерируют десятки и сотни тысяч строк в ответе (таковы, например, запросы об ns-ах крупных регистраторов доменов).

Ещё одна особенность: кириллические домены полностью обрабатываются на стороне клиента, Javascript-ом в браузере. То есть, сервер отдаёт и принимает только классическое представление (ASCII), в котором многоязычные имена выглядят как строки с префиксом “xn--“. По-моему, это, прежде всего, идеологически правильно, так как всё “доменное многоязычие” существует именно на клиентском уровне, внутри DNS никаких Unicode-строк нет. Кроме того, реализация многоязычных имён на серверной стороне, вполне предсказуемо, потянула за собой кучу дополнительных задач – преобразование кодировок, контроль этих преобразований, ловля ошибок, обработка “нестандартных” символов и так далее, и тому подобное.

На следующем шаге планирую добавить в dns.dxdt.ru вывод некоторой статистики, обработку MX-ов. Наверное, что-то ещё. Сервис довольно специфический, но всё равно: вопросы, предложения, пожелания – всячески приветствуются в комментариях.

Тут Артемий Ломов сделал специальную страницу, имитирующую медленную загрузку элементов в браузер – можно вживую посмотреть, как отрисовываются разные блоки и “применяются” стили. Страница находится на сайте WebHiTech-а.

Продолжаем неделю интернет-адресации на 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. Но это пока что планы. Вопросы и пожелания принимаются в комментариях к этой записке.

Ещё немного веб-технологий. Как известно, dxdt.ru работает на WordPress (WP). Ещё лучше известно, что связка Apache+PHP+MySQL+WordPress – это монструозный источник нагрузки для сервера. Надо сказать, что так как большого трафика на dxdt.ru нет, то я никогда не тратил время на “повышение нагрузочной способности” этого конкретного веб-сайта. Но тут таки на досуге попробовал установить нахваливаемый многими плагин для WP – W3 Total Cache (W3TC). Оказалось, что, да, нахваливают обоснованно.

В случае с dxdt.ru, означенный плагин исправил ситуацию самым кардинальным образом. До установки плагина, тестирование (в терминологии blitz.io) двумя сотнями одновременных пользовательских коннектов приводило к тому, что сервер капитально ложился через несколько секунд (причину я не расследовал, но, похоже, что множество набежавших Apache+MySQL съедало всю доступную память). После установки и настройки этого самого W3TC – работоспособность, при тех же условиях, сохраняется, хотя часть “пользователей” (~8%) теряется. Неплохо, на мой вкус. Думаю, что соответствующий трафик – примерно 5 млн хитов в сутки – dxdt.ru не грозит. Да и “длительное” время ответа (~500 ms) не должно беспокоить.

Пояснение (03.04.12):

Насчёт времени ответа: всё просто, речь же шла о тесте из штатовского дата-центра, а dxdt.ru размещается в Ирландии, поэтому время ответа такое “большое”, пакетам требуется дважды пересечь океан. Сам сервер генерирует страницы примерно за 30-60 ms.

Дополнение:

Да, о настройках W3TC. Я использовал кэширование на диск и включил дополнительные правила mod_rewrite, как рекомендуют в описании плагина. То есть, это самая простая конфигурация. Но эффект заметен, так что – рекомендую.

Дополнение-2 (01.04.12):

Посмотрел на причину падений без плагина. Всё так и есть: без плагина W3TC, благодаря особенностям работы mod_php, Apache поднимает отдельный “тред” MySQL для каждого http-коннекта (то есть, для ста пользователей – сто “тредов”); с плагином – “тред” был замечен ровно один, вне зависимости от числа коннектов. Поэтому и не падает.