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

Да, очевидно, что использование одним пользователем одинакового пароля для нескольких сервисов – это плохо. Мало того, что могут специально заманить пользователя на некий специальный ресурс, а там предложить зарегистрироваться и выведать “стандартный” пароль, так ещё теперь пароли массово утекают из-за безалаберности администрации вполне добропорядочных ресурсов, не планировавших что-то там “взламывать” самостоятельно. Часто, во взломанной базе аккаунтов содержатся ещё и адреса e-mail. Если использован общий пароль, то злоумышленник уже знает к какому почтовому ящику данный пароль подходит.

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

(А кроме того, неприятно, что на дворе уже 21 век, а некоторые массовые интернет-сервисы продолжают пароли в открытом виде хранить, ну как при царе Горохе. Модель угроз у них, видишь ли, другая, искажённая до потери связи с реальностью.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зарисовки практического освоения IPv6. 8 июня проводится всемирный день IPv6. Соответственно, нужно подготовиться. Что выясняется: во-первых, шишки набиваются при внедрении нового протокола на пользовательских рабочих местах; в теории всё ПО (в том числе ОС) готово и должно работать, на практике оказывается, что по отдельности работает, а вот чтобы вместе – нет, тут наблюдаются неожиданные эффекты, типа автоматического получения ОС Windows сразу нескольких адресов для одного интерфейса, потому что так были восприняты анонсы ближайшего роутера.

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

В-третьих, очень интересной станет жизнь у веб-разработчиков: у многих скриптов будет начисто сносить крышу после того, как веб-сервер вместо привычных IPv4 принесёт в переменные окружения новую запись новых адресов. Там проблем уже сейчас просматривается много, а ещё больше запрятано внутри всяких фильтров и валидаторов. Ещё веселья добавит только что упомянутый факт, что речь не идёт о пересаживании с v4 на v6 – будет сразу два протокола.

И текущий расклад подтверждает простую мысль: дешевле всего будет строить IPv6-инфраструктуру с нуля, а не обновлять существующую.

Вот.

А между прочим, если смотреть с точки зрения конечного пользователя, то Интернет не такая уж распределённая и устойчивая сеть. С доменами – понятно. Но даже на уровне базовых протоколов (TCP/IP) сейчас у конечного пользователя всегда есть только один (в редчайших случаях – два) шлюз для соединения с этим самым Интернетом. То есть, подключение – центральное.

Да, с ноутбуком и Wi-Fi можно мигрировать между разными услугами доступа, разными сетями, но это несколько другой уровень обеспечения связности. Кстати, ввод IPv6 и создание плотного “поля” подключения к Сети может сделать доступ для конечного пользователя действительно распределённым, но, боюсь, только в теории. (Да и внедрение IPv6 идёт с жутким скрипом, единственный эффект от которого в том, что адреса IPv4 могут стать дорогим удовольствием для провайдеров, которые при этом всё равно останутся на старом протоколе.)

Занятно: в консорциуме W3C недавно создана рабочая группа, задача которой состоит в создании API и стандартов для прямых межбраузерных коммуникаций. Прямых – в том смысле, что браузеры для связи на прикладном уровне не используют промежуточных (центральных) серверов. Получается децентрализованная система, построенная на базе самих браузеров, и таким образом реализующая некий сервис для пользователей (идейно это всё аналогично сетям P2P, понятно).

Так, в описании задач упомянутой группы сказано про аудио-, видеосвязь между пользователями. Можно вспомнить, что в Skype как минимум для установления соединения необходим центральный сервер. Есть системы коммуникаций на базе Интернета (всякие ICQ тому пример), которые вообще работают только через центральный сервер. В W3C думают над P2P-заменой такому безобразию.

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

(Тему подсказал Vladimir Dyuzhev.)

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

Но можно обратить схему и увидеть, что отлично работает фильтрация по белому списку. Напомню, что в этом случае блокируется доступ ко всем ресурсам, кроме внесённых в белый список. Вывод: нужно заводить тематические домены, регистрация имён в которых будет строгой, сопряжённой с проверками. Тогда, при необходимости введения ограничений, можно очень просто реализовать надёжную фильтрацию по имени домена верхнего уровня, допуская только проверенные сайты для просмотра. По такому пути идёт КЦ домена .РФ со своей инициативой .ДЕТИ – тут как раз можно на школьных компьютерах настроить доступ только к этому домену и радоваться универсальной эффективной фильтрации малыми силами. (Главное, чтобы коммерция не победила и за регистрацией действительно строго следили. Следить придётся не только на втором уровне доменных имён, иначе от фильтрации толку не будет вообще. Скорее всего, должны допускаться только собственные сервера имён администратора зоны.) Совершенно аналогичная ситуация с доменной зоной .BANK, например. (Или есть уже старый работающий пример: GOV.)

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

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

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

Часто в разных СМИ и даже в презентациях на популярных конференциях можно услышать про ботнеты, насчитывающие миллионы компьютеров. (Например, на РИФе называли кто 30 млн, кто 50 млн – в общем, получается, кто больше.)

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

Итак, если узлы ботнета-миллионника в течение суток придут равномерным потоком в центр за новыми указаниями, то это будет – около 12 запросов в секунду, минимум. Нужно брать место в дата-центре или арендовать мощности в сервисах типа Amazon EC. А для того, чтобы боты приходили в центр равномерно – должен быть реализован очень хитрый алгоритм распределения нагрузки.

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

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

И это только теоретический устойчивый ботнет с числом узлов в миллион. Понятно, что для 30 млн – ситуация принципиально иная: рост сложности управления в подобных случаях не линеен.

Насколько можно преуспеть в реальности, показывает опыт добровольных сетей распределённых вычислений. Даже учитывая полное доверие и желание сотрудничать со стороны участников – сетей-миллионников здесь практически нет, и все те, которые есть, растут из старых, годами хорошо раскручиваемых, проектов, например, SETI@Home. Но в большинстве случаев, хороший результат – сотня тысяч участников.