Credit: Paul Keller, Flickr.comИнтересная новость (принёс её BugTraq.Ru): Google теперь предлагает открытый для всех пользователей Сети сервис DNS. Достаточно в настройках клиентской машины установить адреса DNS-серверов 8.8.8.8 или/и 8.8.4.4 и преобразованием адресов займётся сервис Google. Использовать такие серверы можно вместо традиционных провайдерских (в большинстве клиентских компьютеров в качестве сервера DNS установлен сервер интернет-провайдера; но это не всегда так).

Возникает резонный вопрос: что даёт обработка DNS-запросов Гуглу? А даёт она очень много подробной статистики о том, какие пользователи куда ходят. Дело в том, что практически всякая активность современного интернет-пользователя в Сети использует DNS-запросы. Поэтому наблюдение над этими запросами позволяет больше знать о “повадках пользователя”.

Конечно, для получения представления о картине “следящей” мощности Google нужно смотреть на введение обработки DNS на фоне того, что уже имеется очень распространённый статистический сервис Google Analytics, установленный на огромном количестве веб-страниц и действует гигантская рекламная сеть, которая также собирает статистику о пользователях. Рекламная сеть и Analytics формируют историю активности пользователей, отслеживая их переходы по разным сайтам.

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

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



Комментарии (13) »

8 декабря в СДК МАИ пройдёт церемония вручения призов первого технологического конкурса веб-сайтов WebHiTech-2009. Да не просто церемония, а ещё и конференция по клиентским технологиям сообщества веб-разработчиков “Веб-стандарты”. Это полезное, интересное и бесплатное мероприятие. Начало мини-конференции – около 13:00, начало церемонии награждения – около 18:00. С программой знакомьтесь на сайте WebHiTech, там же можно зарегистрироваться, пока есть места.



Comments Off on Ссылка: Церемония вручения призов WebHiTech и встреча ВСТ

Собственно, сложно было ожидать другого варианта с новым доменом РФ:

Самые звучные домены в новой кириллической доменной зоне – .РФ – принадлежат одной компании. Она своевременно оформила права на соответствующие товарные знаки (пишут СМИ)

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

Вот так вот. А кто-то, вроде бы, надеялся, что домен будет доступен для рядовых пользователей Интернета? На практике, конечно, всё достаётся профессиональным коммерческим игрокам рынка.



Комментарии (4) »

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

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

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

F22-brukho

Всё это очень старые проблемы, известные в истории реактивной авиации. И вовсе не обязательно связаны они с ракетами. Например, ещё в 40-50-х годах прошлого века, на первых реактивных истребителях, при неудачном, относительно воздухозаборника двигателя, размещении стволов пушечного вооружения, конструкторы сталкивались с отказами при стрельбе: пороховые газы затягивались в компрессор, нарушали обтекание лопаток турбин, в результате чувствительные двигатели глохли.

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

(Фото: Boeing, Lockheed Martin)



Комментарии (14) »

Памятка про домен .РФ

Чтобы не забыть, про домен .РФ:

7dc62caaf8894a9d7c16cd34cd22e267b9b2e725

SHA-1



Комментарии (2) »

F-35 “обычной” модификации, летает:

F-35-CTOL

(По клику – фото большего разрешения. Прислал: Lockheed Martin)



Comments Off on F-35 CTOL

Credit: Pasukaru76, FlickrПродолжаем “неделю” информационной безопасности Интернета в блоге dxdt.ru. С введением технологии DNSSEC связано много “непоняток”, что, в общем-то, ожидаемо. Одна из этих “непоняток” – реальные возможности по управлению адресным пространством, возникающие у держателя главного ключа. (Напомню, кратко, что DNSSEC – это набор протоколов, вводящий в DNS криптографические механизмы подтверждения подлинности адресной информации.)

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

О чём идёт речь: сейчас на типичной клиентской машине (персональном компьютере, подключенном к Интернету, работающем под управлением ОС Windows), для получения информации из DNS используется так называемый stub resolver – это такая весьма простая программа (или, скажем, системная служба – не важно), которая лишь отправляет запросы о получении IP-адреса для того или иного домена на внешний DNS-сервер. Основная особенность тут в том, что stub resolver не выполняет “рекурсивного поиска” в глобальной DNS, а поручает всю работу по такому поиску известному DNS-серверу (обычно, это сервер, принадлежащий интернет-провайдеру).

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

Думаю, теперь понятно, что внедрение поддерживающих DNSSEC резолверов на клиентские машины хорошо оправдывается решением только что описанной проблемы “последней мили DNS”, тем более, что DNSSEC задумана как технология обеспечения защиты информации в схеме “точка-точка”, а не “точка-шлюз”. Собственно, движение уже намечено: резолвер DNS в Windows 7 использует такую схему работы с DNSSEC, в которой валидность адресной информации по запросу резолвера проверяет тот или иной доверенный DNS-сервер. Сложно сказать, как скоро в рядовые пользовательские системы придёт рекурсивный резолвер и как именно он будет устроен, но можно отметить, что аналогичная древовидная система уже работает у типичных “клиентов Интернета” – это SSL-сертификаты, известные многим по реализации в браузерах.

Итог: DNSSEC проникает в корневую зону DNS и во все домены первого уровня (а дальше – ниже), а также и на клиентские машины. С точки зрения управления Интернетом – второй момент имеет не меньшую важность.

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

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

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



Комментарии (5) »

Credit: Brenda StarrЧтение комментариев к заметке про эффективный и практичный способ уничтожения данных на жёстком диске приводит к мысли о том, что “программистский подход” всё ещё силён в понимании вопросов безопасности.

(Напомню, что речь в той заметке про уничтожение жёсткого диска ударом молотка, и о том, почему достаточно одного удара по шпинделю – брутально, да, но эффективно.)

1.

Первый момент из комментариев: давайте будем шифровать данные, а ключ уничтожим (спрячем, удалим и т.п.). Вроде, утеря ключа для хорошей криптосистемы похожа на уничтожение данных, а молотком бить не нужно – так рассуждают комментаторы.

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

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

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

2.

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

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

При этом любительские шифры с “мегаключом” длинной в “стопятсот” байтов – раскрываются специалистами с лёгкостью, так как содержат тривиальные алгоритмические дефекты. И, конечно, атаки на современные практические криптосистемы также используют дефекты проектирования этих систем, ошибки в алгоритмах и в реализациях алгоритмов. (Длинные ключи – в 1024 бита и больше – в случае криптографии с открытым ключом, имеют под собой иную математическую основу, как раз связанную с особенностями используемых алгоритмов.) “Мегадлинный” ключ не является достаточным условием стойкости криптосистемы, а скорее наоборот – свидетельствует о том, что это наивная криптосистема.



Комментарии (18) »

Credit: Brent and MariLynn, FlickrСейчас всплеск интереса к приближающемуся домену РФ – первому в мире кириллическому домену верхнего уровня. Про фишинг, использующий особенности записи адресов Интернета, думаю, все читатели слышали. Интересно взглянуть на фишинговые угрозы в разрезе возросшей популярности кириллицы в адресах – что там нового нас ждёт.

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

Важный момент: для кодирования отличных от латинской азбуки символов в имена, допустимые для DNS, используется специальный алгоритм Punycode. Так, на вход этого алгоритма могут подаваться произвольные символы Unicode, а на выходе получается строка из латинских букв, дефисов и цифр (понятно, есть и обратное преобразование).

Как я уже писал ранее, домены верхнего уровня – это домены верхнего уровня, а при этом никто не запрещает использовать многоязычные имена в других доменных зонах, третьего уровня, скажем, и ниже. Punycode здесь также работает, а ограничения регистраторов доменов на смешивание символов – нет.

Превращение алфавитов осуществляют браузеры (в большинстве практически важных для фишера случаев). От введения дополнительного слоя преобразований безопасность пользователя в данном случае не может улучшиться, это очевидно. Ожидать, конечно, нужно и дыр в реализациях преобразований Punycode. Но с появлением и распространением домена РФ важнее умелое использование этих технологий в других доменных зонах.

Гипотетический пример: доменное имя, закодированное вот такими “кракозябрами”: xn--80adjurfhd.xn--click-uye2a8548c.dxdt.ru – в представлении Unicode выглядит приблизительно (эта страница может быть не в UTF-8, поэтому один символ я заменяю) так: “проверка.рф⁄click.dxdt.ru”. Здесь для имитации слеша использован спец.символ из таблиц Unicode с кодом 0x2044; (“знак деления”). Итоговый URL может быть таким: http://проверка.рф⁄click.dxdt.ru/ – мимикрия под “проверка.рф”, реально домен находится в зоне .dxdt.ru. Понятно, что на практике использовать будут другие варианты исходных доменов, какие-нибудь известные бренды.

Addon (05/11/09): оказывается, не все сразу понимают, о чём идёт речь. Пояснение: возьмите любой современный браузер (как заметили в комментариях: исключая Opera 10.x) и скопируйте с этой страницы в адресную строку текст:

http://проверка.рф⁄click.dxdt.ru/

нажмите enter – в результате браузер перейдёт по указанному частично кириллическому адресу на веб-страничку с поясняющим текстом (хоть домена РФ пока и не существует).



Комментарии (8) »

Flickr, Ken_MayerНаблюдение над комментариями к записям про паспортизацию Рунета (“домены по паспорту”) и наблюдение за вопросами на профильных семинарах показывают, что пользователи (да и не только они) не в курсе основной особенности такого документа как паспорт. А ведь паспорт, – самый традиционный бумажный, – это типичный пример средства биометрической идентификации человека. Биометрические данные сохраняет и демонстрирует фотография.

Как известно, надёжное, с точки зрения безопасности, использование биометрических систем идентификации возможно только при непосредственном присутствии самого носителя исходных биометрических данных, потому что идентификация состоит в “сличении записанных характеристик” с, как говорится, оригиналом-носителем. Это, кстати, касается не только традиционных паспортов, но и новомодных сканеров отпечатков пальцев, детекторов капилляров ладони и прочей подобной чудо-техники.

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

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

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

При ближайшем рассмотрении все описанные высокотехнологичнные методы (которые мы, вероятно, встретим в практике, как только биометрические системы станут повсеместными) перекликаются с их прародителем – с теми самыми “сканами паспортов”.

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



Комментарии (1) »

Как вы понимаете, аудитория у dxdt.ru специальная, высокотехнологичная, отличная от средней аудитории Рунета. Очередное подтверждение тому – распределение просмотров страниц по браузерам (данные Google):

browsers

Пояснение: Firefox и Chrome – сильно выше среднего.



Комментарии (12) »