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

Вот, кстати, к вопросу о том, что на свободе по пользовательским компьютерами может разгуливать куча вредоносного ПО, которое современные меганавороченные антивирусы не распознают (просто, хвалёные эвристические и статистические методы на практике работают не так, как в маркетинговых статьях и заявлениях, запугивающих пользователей): Mikko Hypponen из F-Secure пишет в Wired, что код нашумевшего вируса Flame находился в базах разработчиков антивирусов более двух лет, но никто его не исследовал.

В 2012 году на roem.ru сообщают: “MD5 больше не надёжен”.

Вообще, о том, что MD5 не является стойким вариантом для преобразования паролей с целью их сохранения, стало известно примерно через пару лет после разработки MD5 (1991). Но, спустя ещё, примерно, два десятка лет – “ненадёжность” MD5 остаётся открытием. В принципе, это объясняет и то, почему разработчики продолжают MD5 применять везде, где только могут.

Вот ещё один штрих: Microsoft распространила сообщение, подтверждающее, что из-под их УЦ выпустили “левые” сертификаты, удостоверявшие, в том числе, вредоносный код. Уязвимы все поддерживаемые версии Windows. Вот вам и доверенный канал для обновлений ОС.

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

В TechNet подробности. Собственно, пишут, что Flame как раз был подписан по этой схеме.

Дефект (скорее, уязвимость) в интерфейсе приёма заявок на New gTLD ICANN признала 12 апреля, хотя, подтверждают, что сообщения о проблемах от пользователей поступали с 19 марта. Сегодня – 14 апреля, и пока что ICANN, в своём стиле, только обещает 16 апреля сообщить о том, смогут ли они возобновить приём заявок 17 апреля.

Вчитайтесь: через двое суток после аварии, ICANN, на полном серьёзе, выпускает официальное сообщение о том, что ещё через два дня опубликуют очередное сообщение, в котором будет уведомление о поступлении следующего сообщения. Это рафинированный образец бюрократии в действии.

New gTLD – очень шумное начинание. Одно из самых шумных с момента создания ICANN. Понятно, что сломать, в принципе, могут всё что угодно. Но, в случае с закрытым сервисом ICANN, списывать очки на этот бесспорный момент – очень непросто. Кроме того, не факт, что там была какая-то сложная и серьёзная причина для сбоя, вполне вероятно, что просто тривиальная ошибка программиста, вылезшая в “боевой” продукт по причине отсутствия аудита качества.

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

Впрочем, посмотрим, как оно повернётся.

Ещё немного Интернета. Вот “Битрикс” с шумом запускает проект bitrix24.ru. Конечно, “облачный”. Позиционируют как корпоративный интранет. Естественно, всякое у них написано про то, как обеспечивают безопасность, что, мол, только по https, все дела. Цитата с сайта: “Безопасность вашей информации превыше всего!”. И, без сомнения, для корпоративного интранета безопасность действительно важна. Особенно, если какая-то компания удумает держать интранет в “облаке”, под “Битриксом”. Судя по всему, вертится проект на амазоновском EC2.

Но я о другом. Идём на https://bitrix24.ru/ и – любуемся на кривой самоподписанный сертификат, который отдаёт нам сервер:

Issuer: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;
Subject: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;

Тот же сертификат отдаёт www1.bitrix24.ru. При этом у проекта есть сертификат для *.bitrix24.ru – его отдают другие их веб-серверы.

А благодаря смелым настройкам DNS “Битрикс24”, можно открывать “сайт” под любым выдуманным (несуществующим) адресом третьего уровня внутри bitrix24.ru, например, http://alskdjfhg.bitrix24.ru/, и наблюдать страницу-заглушку, которая, судя по тексту, обозначает временную недоступность сервиса в целом. Поведение, очевидно, совершенно некорректное. (Update, 22.06.12: поведение исправили, показывают страницу “Несуществующий домен”.) Проявив чуть больше смекалки, и попробовав адреса уровнем ниже третьего (a.b.c.bitrix24.ru), повторно наблюдаем кривое использование SSL-сертификата, но теперь уже в случае с сертификатом для *.bitrix24.ru, который, вообще-то, при правильном применении, вполне себе валидный (выдан Go Daddy CA).

И это, наверняка, не все проколы. Ну и вот как тут можно говорить про безопасность корпоративного интранета в подобном “облаке”, которое разработчики не сумели настроить?

Дополнение (13.04.12): не менее показательно, что в разделе “Безопасность – техническим специалистам” на сайте написано буквально следующее (цитата): “на уровне операционной системы веб-серверов «Битрикс24» через сетевой экран закрыт внешний доступ по все портам, кроме 443”; но при этом нетрудно убедиться, что их веб-сервер охотно отвечает на 80 порту (301 Moved Permanently), перенаправляя на тот же IP, но на 443 порт. Понятно, что иначе и быть не может – пользователи не умеют https набирать.

Провёл маленькое исследование: пока добирался из загорода до московского офиса, компьютер (ноутбук) в машине записывал из эфира сигналы WiFi-устройств. Из-за московских пробок время в пути составило около двух часов.

Статистика: встретилось 533 клиентских устройства WiFi. Обратите внимание: это не точки доступа, которых повстречалось более 1500 штук, а разные планшеты, смартфоны, ноутбуки и тому подобные штуки. Всё это время автомобиль находился на разных городских улицах, не во дворах, то есть, разумно предположить, что большая часть – мобильные устройства. (И это не метро! Там плотность устройств была бы выше, это очевидно.) Из 533 устройств 363 (~68%) не были, в момент обнаружения, привязаны к точке доступа. То есть, это неплохо подтверждает гипотезу о преобладании мобильных устройств в полученной выборке.

Так вот, 130 устройств передавали в эфир список идентификаторов точек доступа, к которым они ранее подключались. Я писал об этой особенности реализации WiFi раньше. 130 штук – это около 24%, примерно четверть. Немало, да.

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

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

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер 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-атаку. Тут такой момент: во многих случаях, если трафик можно определить как “мусорный”, то и с атакой проблем меньше – можно эффективно фильтровать трафик по критерию “мусорности”, и он не будет доходить до точки приложения атаки. Хорошая атака как раз подразумевает, что сложно измерить долю именно “мусорного трафика”.

Микроэлектронные комплектующие, которые производятся и закупаются за рубежом, могут содержать в себе аппаратные закладки (строго говоря, и отечественные микросхемы тоже могут содержать закладки, но это уже другая категория рисков). Понятно, что такие закладки могут вредить оборудованию, в составе которого используются вредоносные микросхемы. Тут нетрудно наметить сразу несколько направлений борьбы.

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

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

Вот даже Алекс Экслер в Испании подключается к “соседскому” открытому Wi-Fi, и исследует сетевые сервисы (я надеюсь, при помощи специально сконфигурированного ноутбука). А вы говорите! Что же ожидать от простых пользователей? Они тоже подключаются куда попало. В том числе, и всякими смартфонами, в которых куча персональной информации.

Кстати, есть специальные программные пакеты, имитирующие некую живую “открытую” сеть, с точкой входа через Wi-Fi. Для чего? Чтобы приманивать любопытных. Ну не только для этого, ещё и для своевременного обнаружения вторжений и исследования угроз. Вообще, понятно, что можно поднять такое приманивающее окружение самостоятельно, используя свободное ПО. Да.

А потом удивляются, что почту взламывают.

(Ага, это юмор по выходным.)

Кстати, обсуждение заметки про VPN в чужих сетях, навело на другую интересную мысль. Учитывая, что устройств, использующих доступ к Интернету, при себе всё больше, логичным решением для, например, отеля, является своя точка доступа Wi-Fi с тем же самым VPN-ом, засунутым внутрь. Должно быть удобно, потому что позволит использовать даже те устройства, которые с OpenVPN не дружат.

Чтобы проверить решение на практике, я взял валявшийся без дела роутер Wi-Fi ASUS RT-N12, залил в него прошивку DD-WRT, с поддержкой OpenVPN, загрузил сертификаты (там есть панелька в веб-интерфейсе даже, можно не браться за консоль) и – всё работает, благо, внутри у него Linux. Сложностей настройки не выявил. То есть, теперь сценарий такой: подключаем к чужой проводной сети (Ethernet, понятно) роутер, он поднимает внутри VPN, и получаем собственный зашифрованный и безопасный Wi-Fi, через который могут работать и смартфоны, и планшеты, и старый КПК. Удобно.