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

Свежая популярная тема – распределённые атаки на WordPress с перебором паролей администратора сайта. Надо сказать, что в логах веб-сервера действительно заметен рост числа серийных HTTP-запросов POST, с адресом скрипта, который проводит логин пользователей. То есть, я легко нашёл на одном из сайтов более пяти тысяч таких запросов за сутки с одного IP-адреса. А вообще адресов-источников несколько, понятно, но обычно там десятки запросов, не тысячи.

Нельзя сказать, что подобного сканирования не было раньше, но за период с 10 апреля по сегодняшний день – рост на порядок виден невооружённым взглядом. Вот такой теперь Интернет, что тут скажешь. К непрерывному SSH-сканированию добавляются массовые проверки веб-приложений. Хотя, никакой новости тут нет, разве что огромная популярность WordPress-а подгоняет публикации в СМИ.

(Что касается противодействия: я, например, просто настроил динамические правила в брандмауэре, использовав fail2ban + iptables; обычное решение, думаю, что адекватное.)

Ко Дню космонавтики – кадр со стартующей ракетой из советского фильма “Космический рейс” (1935 год). Ракета стартует по классической схеме, с эстакады, прямо из просторного города будущего, разбрасывая кучу искр.

Занятный момент есть в официальном FAQ по Google Public DNS – они пишут, что если адрес, который не проходит валидацию DNSSEC, является популярным и хорошо известным, то для него может быть сделано исключение: валидацию отключат.

Вообще говоря, учитывая ошибки в управлении безопасными зонами (с DNSSEC), решение выглядит разумно: невалидным может оказаться и какой-нибудь домен первого уровня, без всяких атак злоумышленников, такое уже случалось несколько раз (тут как бы в корне подписи не “обрушили”, что уж говорить о доменах уровнем ниже).

С другой стороны, именно популярные доменные зоны и могут стать привлекательной целью для атак. И, выходит, Google результаты таких атак будет транслировать пользователям. Не очень радужная перспектива.

Цитата из FAQ:

How does Google Public DNS handle lookups which fail DNSSEC validation?

If a client requests a validated lookup for a signed domain, but Google Public DNS cannot validate the lookup (due to misconfiguration, missing or incorrect RRSIG records or DNSKEY records, etc.), it will return an error response (SERVFAIL). However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily blacklist the zone from validation until the problem is fixed.

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

На конференции РИФ, менее чем через две недели, будет представлен очередной номер журнала “Доменные имена”. Тема номера: Интернет после апокалипсиса. Небольшой анонс, с картинкой, – в блоге RU-CENTER.

Издание Flightglobal делится картинкой, изображающей новое, шестое, поколение истребителей от Boeing. Вроде, особо новой картинка не выглядит, но, тем не менее:

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

Важнейшая архитектурная особенность DNS – кэширование адресной информации. Рекурсивные кэширующие резолверы должны некоторое время сохранять полученные из DNS ответы и, – вместо того, чтобы снова отправлять запрос на авторитативный сервер, – отвечать данными из кэша. Это оптимизирует нагрузку на систему в целом. Организация “сквозного” кэширования для групп резолверов представляет собой непростую задачу. Я посмотрел, как обстоит дело с кэшем у широко анонсированной бета-версии “Яндекс.DNS“.

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

Беда в том, что “Яндекс” пришёл далеко не один раз, не дождавшись истечения TTL (“время жизни” ответа, управляющее продолжительностью нахождения данных в кэше). Можно предположить, как всё это устроено на стороне “Яндекса”: используется группа серверов-резолверов (часть из них имеет адреса из диапазона 213.180.200.240/29), с раздельными кэшами, балансировка входящих запросов не учитывает состояние кэшей, взятое относительно источника запроса. То есть, пока каждый резолвер не загрузит данные, требуемые для ответа на запрос, вероятность попасть в кэш мала. Дело в том, что последовательные запросы отрабатывают разные резолверы: хорошо видно, как они повторно приходят на NS до истечения TTL.

Результат: кэширование реализовано вне традиций DNS. Одинаковые повторные запросы даже для одного и того же клиента, до истечения TTL, постоянно уходят на авторитативные серверы, что прямо противоречит смыслу существования подобного “кэширующего” резолвера (DNS-сервера), а в случае распространения “Яндекс.DNS”, создаёт ненужную дополнительную нагрузку, то есть заметно ухудшает ситуацию: вместо одного запроса провайдерского резолвера получаем несколько (пять-десять) запросов от “Яндекса”.

(Да, Google Public DNS кэширует правильно, повторно раньше времени не приходит.)

Думаю, в “Яндексе” есть объяснение, почему так сделано. Но сделано некрасиво. Даже для бета-версии.

“Яндекс” запустил открытый сервис DNS (открытые резолверы). Сервис похож на Google Public DNS. Однако у яндексового варианта есть дополнение – фильтрация адресов:

Яндекс.DNS – это бесплатный DNS-сервис, блокирующий опасные сайты и сайты для взрослых.

(http://dns.yandex.ru/)

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

При обработке запроса об адресе “заблокированного” ресурса приходит ответ, содержащий IP-адрес некоего принадлежащего “Яндексу” сервера перенаправлений, который отвечает по HTTP (это уже прямая подмена соединения!) редиректом на специальную страницу внутри yandex.ru. Эта страница устроена так, что охотно показывает сообщение о блокировании любого адреса, который передан в параметре URL-а. Например: http://yandex.ru/adult?url=yandex.ru – пишет, что “заблокирован” yandex.ru. Это, мягко говоря, технологически некрасиво. (Да, многие операторы связи сейчас делают подобное. Это известно.)

Почему плохо портить ответы DNS? Прежде всего потому, что пользователь остаётся с заведомо сломанным сервисом резолвинга, в который добавлена ещё пара уязвимых точек. Одна ошибка администраторов может перенаправить массу пользователей добропорядочного сайта на некую страницу-заглушку. И это в лучшем случае. В худшем, если сервис поломают, – получаем классический фишерский инструмент с подменой DNS. Обратите внимание, что пользователи подобных сервисов заведомо остаются без DNSSEC. Это при том, что Google Public DNS поддержку DNSSEC наоборот – внедряет (в комментариях уточнили: уже внедрил). Да, понятно, что взломать могут и резолвер интернет-провайдера. Проблема в том, что потенциальная аудитория сервиса “Яндекса” куда как более разнообразна, дефект, при этом, заложен в этот сервис архитектурно, чего нельзя сказать о стандартных резолверах.

Естественно, блокировать нехороший контент нужно. Но для этого не требуется ломать DNS. Нужно использовать белые и чёрные списки, встроенные в браузер. И подходящий браузер у “Яндекса” есть.

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

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

Сегодня, 01.04.13, поменял для большей части фона dxdt.ru цвет на чёрный. А цвет текста – на зелёный. Сейчас вернул обратно. Похоже, мало кто заметил. Может, нужно было так зелёным по чёрному и оставить?

Забавное видео – пара ПАК ФА сопровождает гражданский лайнер Boeing 747 (так написано):

(Видео – по ссылке под картинкой. Найдено в блоге The DEW Line.)