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

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

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

Между прочим, казнозарядные схемы огнестрельного оружия, будучи довольно очевидным решением, известны ещё с 15-16 веков – всякие там бомбарды и им подобные. То есть, это вовсе не придумка 20-го века, как, оказывается, многие полагают. Использовалась, например, приставная камора (это, грубо говоря, такая отдельная деталь, которую наполняли порохом и для выстрела прикрепляли к казённой части ствола). Соответственно, и казнозарядное стрелковое оружие всё это время пытались конструировать, тоже в 16 веке и, понятно, позже.

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

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

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

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

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

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

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

В продолжение темы про IPv6. У этого нового протокола есть интересное математическое (вычислительное, если хотите) отличие от IPv4. Так, в старом протоколе есть не более 2³²=4294967296 (около 4 млрд) потенциально различимых адресов. Предположим, что мы задумали каждому возможному адресу сопоставить один байт с некоторой информацией. Массив займёт примерно 4 гигабайта. Это объём ОЗУ обычного современного настольного компьютера. То есть, подобные таблицы, “перечисляющие” некоторым образом всё пространство IPv4, можно “ворочать” без особых вычислительных затрат. Не важно, для чего используются такие массивы-таблицы, для обозначения каналов доставки пакетов, для подсчёта обращений к некоторым узлам, для балансировки нагрузки глобально доступных сервисов или для чего-то ещё. Главное, что возможен простой, “прямой” способ работы со всем множеством адресов.

Реализовать подобное для IPv6 – не выйдет. 2¹²⁸ элементов невозможно уместить в память никакого существующего суперкомпьютера. Хуже того, их невозможно даже перебрать за разумное время ни на каком суперкомпьютере. Другими словами, множество адресов IPv6, перечислимое математически, не “перечислимо” в суровой программистской реальности, потому как “нет таких компьютеров”. Казалось бы – ну и ладно, кому нужны эти гигантские таблицы?

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

Хотя, понятно, конечно, что “на свободе” не должно ходить IPv6-адресов сильно больше, чем существует устройств, способных такие адреса использовать.

Технократический юмор по выходным.

Следом за кем-то из популяризаторов новой версии IP, всё чаще повторяют, что (в отличие от IPv4) “число адресов в новом протоколе – IPv6 – практически бесконечно”. Конечно, 2¹²⁸ – число большое. Но если сравнивать его с бесконечностью (даже потенциальной), то оказывается столь малым, что им можно просто пренебречь в расчётах. Другими словами, понятно, что новое адресное пространство не бесконечно. И можно придумать способы, приводящие к его исчерпанию за некое разумное время.

Хотя это будут непростые способы. Так, если задаться целью и выделить специальный класс адресов для геолокации, то ушедшие для обозначения каждого квадратного метра (а кому нужна точность выше?) земной поверхности IPv6-адреса практически никак не уменьшат пул свободных адресов. (Площадь Земли – примерно 5*10¹⁴ квадратных метров, а адресов доступно примерно 3*10³⁸; то есть, можно примерно все планеты в наблюдаемой Вселенной покрыть адресами, в несколько сотен слоёв.) А кроме того, использование IP-адресов для геолокационной привязки – не самое правильное решение, если только речь не идёт о фантастической глобальной сети связи с очень высокой плотностью узлов.

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

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

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

Мы тут обсуждаем смартфоны и сходную продукцию (ключевые слова: Apple, Android), в том смысле, что если сильно беспокоиться о том, что подобные устройства активно шпионят за “носителем” и “сливают информацию в центр”, то совсем нельзя пользоваться современными, удобными технологиями коммуникации. Действительно, удобно – и альтернативы нет. Куда податься? Ответ теоретика такой: в сторону открытых аппаратных платформ (ОС с открытым исходным кодом и так уже есть).

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

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

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

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

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

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

Другими словами, если Skype был кривым внутри, в смысле криптографии, то и раскрытие/нераскрытие исходников никак ситуацию для пользователей не ухудшит (разве что улучшит, кстати, если ПО будет получать соответствующие сертификаты).

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

Самое простое, это поиск IP-адреса пользователя в той или иной “геолокационной” базе. Такие базы содержат сведения о том, в какой регион выделялся данный IP-адрес. Так как первоисточником тут являются интернет-регистратуры, а уточнения часто делаются лишь по информации от провайдеров, то точность низкая. Определить местоположение “до дома” не выйдет.

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

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

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

Геопривязку не требуется ограничивать IP-адресами. Подходят другие уникальные идентификаторы, например, куки, выданные пользователям какого-то сервиса. Собственно, куки хорошо дополняют IP-адреса.

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

Ещё один источник сведений, правда, косвенный, это DNS. Так как обычный пользовательский компьютер выполняет поиск в DNS при помощи резолвера доступного в данный момент интернет-провайдера, и эти резолверы могут меняться, то, отслеживая запросы на подконтрольных NS (серверах имён), можно вычислить и провайдера, и дополнительные сведения о местоположении пользователя. Такой подход особенно помогает, если пользователь ходит из-за NAT, то есть, снаружи виден под некоторым “общим” IP-адресом.

И, похоже, это ещё не все способы.

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

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

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

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

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

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

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

А занятнее всего тут то, что такой смартфон ещё и собирает сведения о местоположении других, так сказать, “абонентов поневоле”, которые даже и не догадываются о происходящем, и вообще не подписывались под всеми этими соглашениями. Например, приложение в смартфоне собирает MAC-адреса замеченных в эфире точек доступа Wi-Fi и, привязав их к координатам, полученным от GPS, отправляет “в центр”. История известная.

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

Сделали страничку для тестирования IPv6: http://ipv6.nic.ru/ – можно проверить, что IPv6 скорее всего у вашего провайдера ещё нет (ну или есть, да, что сильно вряд ли).

Как это работает, если интересно: сервер один, два виртуальных хоста, один отвечает по IPv4, второй – по IPv6. Домашняя директория у них общая, поэтому PHP-код, генерирующий страницу, един, и БД, понятно, общая. Ни с “Апачем”, ни с PHP проблем в использовании IPv6 не возникло. Но, как обычно, в некоторых местах IPv6 попытался вставить палку в колесо. Например, нужно специально следить за соединениями с внешними серверами: на той машине, где вертится страница, используется оба стека (v6+v4), поэтому по умолчанию соединение “наружу” устанавливается по IPv6 – точнее, пытается установиться, потому что далеко не везде есть нужная коннективность. Ну и отдельная история: сходят с ума некоторые старые фильтры/регулярные выражения, когда к ним из переменных окружения веб-сервера поступают IPv6-адреса. Тут будет отдельный пучок проблем с CMS.