Пользователь
0,0
рейтинг
25 августа 2013 в 12:52

Разработка → Методы анонимности в сети. Часть 2. Утечки данных


Привет, хабраюзеры!

Сегодня мы продолжим разговор про анонимность в интернете.
Вторая часть получилась чуть более сложной для новичков. Она будет состоять из двух разделов:
  • В первом разделе мы закончим разговор про централизованные решения для «анонимности»: VPN, SSH, SOCKSx.
  • Во втором — рассмотрим конкретные утечки деанонимизирующих данных.

Все части здесь:
Часть 1: Методы анонимности в сети. Просто о сложном.
Часть 2: Методы анонимности в сети. Утечки данных.
Часть 3: Методы анонимности в сети. Firefox.
Часть 4: Методы анонимности в сети. Tor&VPN. Whonix.

Централизованные средства «анонимности»


Сразу отмечу главное: никакое централизованное решение высокий уровень анонимности обеспечить не может, так как необходимо доверять центральному узлу.
Мы не будем рассуждать об организационных, политических и бюрократических сложностях на пути раскрытия анонимности.
Возможно, VPN-сервер в Панаме действительно более безопасен, чем такой же сервер в Испании. А возможно — нет.
Также как и не будем говорить про цепочки узлов, так как их надежность с трудом поддаётся оценке. С одной стороны, в виду организационных сложностей, риск раскрытия ниже, а с другой — мы должны быть достаточно уверены в каждом узле.
Перейдём к конкретике.

Прокси-серверы: http и SOCKSx

Рассмотрим подробнее http-заголовки в http-прокси.
HTTP-заголовок – это строка в http-сообщении с некоторыми параметрами вида: «Имя: Значение». Заголовков существуют достаточно много, ими при взаимодействии обмениваются между собой клиенты и серверы.
Например, следующее поле: «Date: Sat, 12 Dec 2012 15:41:52 GMT» возвращает от сервера клиенту текущее время и дату.
Один из таких заголовков: X-Forwarded-For, по сути, является стандартом для получения сервером оригинального адреса клиента при доступе к серверу через HTTP-прокси. И вот в этом заголовке, если его не фильтровать, передаётся вся цепочка прокси-серверов от начала до конца, например:
  • X-Forwarded-For: client1, proxy1, proxy2 …
  • X-Forwarded-For: 169.78.138.66, 169.78.64.103...

Также к заголовкам, разглашающим деанонимизирующую информацию, относятся: HTTP_VIA, HTTP_FORWARDED и др.

HTTP-прокси-серверы, которые скрывают ip-адрес клиента, называют анонимными. Такие серверы подразделяются на виды, деление это весьма условно, но, тем не менее, существуют:
  • Простые анонимные прокси (anonymous). Эти серверы не скрывают факта использования http-прокси, однако они подменяют ip-адрес клиента на свой.
  • Элитные анонимные (high anonymous/elite). Такие серверы ещё скрывают и сам факт использования http-прокси.

SOCKS-прокси, как вы помните, никаких заголовков не передают.

Рассмотрим разницу между SOCKS 4, 4a и 5. Существуют разные версии SOCKS:
  • SOCKS4. Такие серверы требуют от клиента, например, веб-браузера, только ip-адрес ресурса, к которому он обращается (адресата). Следовательно, клиенту надо как-то этот ip-адрес узнать, а узнать его клиент может только прямым DNS-запросом в обход прокси. Это может привести к деанонимизации, так как интернет-провайдер может видеть DNS-запросы в открытом виде, данная уязвимость называется DNS-leaks, она описана далее, во второй части статьи.
  • SOCKS4a. Является расширением SOCKS4. Главное отличие состоит в том, что SOCKS4a-сервер принимает от клиента только DNS-имя адресата, а не его ip-адрес. Это бывает необходимо, когда клиент не может самостоятельно определить ip-адрес адресата по DNS-имени.
  • SOCKS5. Также является расширением SOCKS4. Сервер SOCKS5 поддерживает UDP, IPv6, авторизацию и пр. И хотя SOCKS5-прокси могут принимать от клиента как ip-адрес, так и DNS-имя целевого ресурса, некоторые приложения, поддерживающие SOCKS5, могут сами получать ip-адрес адресата до того, как обратиться к SOCKS5-прокси, что также может привести к утечке DNS-запросов.

SSH. Сравнение SSH и VPN

SSH туннель — это туннель, создаваемый посредством SSH-соединения и используемый для шифрования передаваемых данных. Как гласит одноимённая статья в Википедии: «SSH (англ. Secure SHell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов)».
При использовании SSH-туннеля открытый траффик какого-либо протокола шифруется на одном конце SSH-соединения, клиенте, и расшифровывается на другом, SSH-сервере.
Схема работы SSH-туннеля показана на рисунке:

Протокол SSH поддерживает несколько вариантов работы:
  • В первом варианте туннелируемое приложение должно иметь настройки HTTP/SOCKS-прокси для направления траффика через локальный прокси-сервер в SSH-туннель. Если таких настроек нет, то можно использовать программы-соксификаторы, которые отправляют траффик через прокси-сервер.
  • Во втором случае можно организовать практически полноценное VPN-соединение и обойтись без настройки SOCKS. Начиная с версии 4.3, открытая реализация SSH, OpenSSH, может использовать туннельные сетевые интерфейсы 2-го и 3-го уровней модели OSI, то есть организовывать аналоги VPN-соединений.

Сравним VPN и SSH с точки зрения анонимности.

Цели
Исторически VPN и SSH предназначались для разных целей, что и объясняет их плюсы и минусы.
  • VPN призван обеспечить защищённый удалённый доступ к ресурсам корпоративной сети. Как только компьютер подключается к VPN-серверу, он становится частью «локальной» сети, а, следовательно, может получать все её сервисы: общие ресурсы, локальный сервис VoIP, также становятся возможными NetBios-, UDP-, и широковещательные запросы, единые VPN-политики и т.д. Через VPN в большинстве случаев отправляется траффик всей операционной системы и приложений.
  • SSH изначально предназначался для защищенного удаленного управления устройствами. SSH-соединение — это соединение с «конкретным устройством», а не с «сетью». Хотя мастера SSH могут делать с помощью него много крутых вещей.

Безопасность
Протоколы VPN и SSH достаточно безопасны за исключением разве что PPTP. Большинство возможных атак сводится к Man-in-the-middle и подмене сертификатов или ключей, однако это проблема аутентификации и внимательности пользователя.

Удобство
Удобство — понятие условное и субъективное, оно зависит от ваших целей и опыта.

К VPN-серверу легко подключиться, но для новичков может быть непросто его настроить.
Тогда как SSH-сервер более прост в настройке, но, например, вручную настраивать SSH-туннель для каждого приложения кому-то может показаться не совсем удобным.

Скорость
Скорость каждого средства зависит от конкретной реализации и используемых протоколов. Если сравнивать SSH и OpenVPN, поделюсь уже проведённым исследованием:
  • network — 96.5 Mbps.
  • network/SSH — 94.2 Mbps.
  • network/VPN — 32.4 Mbps.

Подводя итог, стоит отметить, что VPN-серверы более популярны, чем SSH. В интернете существует много коммерческих VPN-провайдеров. Однако и SSH-туннели тоже продаются в избытке на специализированных форумах.
Что разворачивать на своём сервере в Антарктиде — дело ваше.

Полезный совет

Иногда бывает ситуация, когда VPN-соединение по каким-либо причинам может разрываться. Если в случае с прокси-сервером, сетевое взаимодействие прекращается, то в случае с VPN траффик продолжит идти напрямую. Наиболее надёжным вариантом для недопущения этого является использование таблицы маршрутизации, где в качестве основного шлюза по умолчанию указан только шлюз VPN-сервера.
Делается это просто:
1. Удаляем любые маршруты по умолчанию:

2. Разрешаем доступ в интернет только к адресу VPN-сервера:

3. Добавляем маршрут по умолчанию со шлюзом – VPN-сервером:

Где: 192.168.0.1 — шлюз интернета, 55.55.55.55 — VPN-шлюз.
Еще одним способом является установка в свойствах открытого интернет-соединения несуществующих DNS-серверов, например, 127.0.0.1. В таком случае веб-сёрфинг и другие подобные задачи становятся невозможными без подключения к VPN-серверу.
Также существуют специальные программы, например, VPN-watcher, которые для заданных приложений проверяет VPN-соединение несколько раз в секунду и приостанавливает их работу, если VPN-соединение обрывается.
Спасибо за еще один способ Pongo: "Еще один способ обезопасить себя от разрыва vpn — это настройка файрвола. Подойдет в том числе и стандартный windows firewall. Есть инструкция с картинками. Причем блокирующие правила можно не создавать, а ограничиться 10-м пунктом. Для отдельных программ (например для openvpn) можно отдельно создать разрешающие правила, чтобы эти программы работали даже если впн не подключен."
Спасибо за еще один способ amarao: "Я думаю, если строить защищённую конструкцию, то следует просто выделять две сессии — защищённую и не защищённую. Лидера сессии положить в cgroups, откуда не-vpn интерфейс просто не доступен для использования — в этом случае информация будет отправляться только через этот интерфейс."

Деанонимизирующие данные и возможные уязвимости


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


Общее

IP-адрес. Самый «популярный» идентификатор в сети. Его ценность может быть разной в различных ситуациях, но как правило именно раскрытием ip-адреса принято пугать сетевых «анонимусов».
Решение: со скрытием ip-адреса справляются средства, описанные в первой статье: "Методы анонимности в сети. Просто о сложном"

DNS-leaks возникает тогда, когда приложение может отправлять свои DNS-запросы, используя DNS-серверы интернет-провайдера. Так часто бывает, когда люди через локальный прокси-сервер (привет, SOCKS 4, 5!) пытаются отправить в сеть Tor траффик различных приложений, которые резолвят DNS-имена в обход Tor.
Проверить, подвержены ли вы этой утечке можно здесь: www.dnsleaktest.com
Решение: при работе с VPN-соединением наиболее удобным вариантом является принудительное использование статических DNS-серверов VPN-провайдера либо, если VPN-сервер у вас личный, использование серверов OpenDNS (208.67.222.222, 208.67.222.220) или DNS Google (8.8.8.8, 8.8.4.4).
Чтобы не допустить подобных утечек в Tor, рекомендуется использовать Tor Browser Bundle либо, если уж хочется отправить в Tor траффик другого приложения, то наиболее безопасным и универсальным вариантов является изолирующий прокси, который будет рассмотрен в одной из следующих статей.
В сети I2P DNS-запросов нет. При работе с outproxy DNS-запросы выполняются на самом outproxy.
Спасибо за совет Rulin: "… при использовании Socks прокси в Firefox, DNS-leaks будет по умолчанию происходить, чтоб от этого избавиться, надо: В адресной строке набираем about:config, Жмем «I'll be careful, I promise!»,
Находим опцию network.proxy.socks, Двойным кликом меняем значение на true,
Все, теперь при использовании socks прокси, dns запросы будут тоже ходить через socks
".
Настройка «network.proxy.socks_remote_dns» определяет, где будут выполняться DNS-запросы при использовании SOCKS5. Значение «True» устанавливает, что они будут выполняться через SOCKS-прокси, а не на клиенте.

Профилирование возникает, когда большая часть траффика долго выходит в интернет через один узел, например, Тоr. Тогда появляется возможность отнести увиденную активность к одному псевдониму. Выходной узел может и не знать ваш ip-адрес, но будет знать, что вы делаете.
Решение: не использовать постоянные цепочки Tor, регулярно менять выходные узлы (VPN-серверы, прокси-серверы), либо, забегая вперёд, использовать дистрибутив Whonix.

MitM-атаки направлены на прослушивание и модификацию траффика на выходном узле, например Tor или любом прокси-сервере. Интересным вариантом является модификация выходным узлом цифровых подписей, GPG- или SSL-отпечатков, хеш-сумм скачиваемых файлов.
Решение: быть внимательным при появлении предупреждений о валидности сертификатов и ключей.

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

Одновременное подключение по анонимному и открытому каналу. В таком случае, например, при обрыве интернет-соединения, оборвутся оба соединения клиента с одним ресурсом. По данному факту серверу будет нетрудно вычислить и сопоставить два одновременно завершенных соединения и вычислить реальный адрес.
Решение: не допускать одновременного подключения к ресурсу по анонимному и открытому каналу.

Определение авторства текста. Подробнее здесь. Приложение может сравнить текст написанный анонимно и другой открытый текст, точно принадлежащий автору, и определить с высокой степень вероятности совпадение авторства.
Решение: шутки-шутками, но эта тема пока не достаточно изучена. Можно посоветовать прятать текст, который можно однозначно связать с вами. Тогда не с чем будет сравнивать и анонимный текст.

MAC-адрес сетевого интерфейса становится известен wi-fi точке доступа при подключении к ней клиента.
Решение: если переживаете за то, что точка доступа запомнит MAC-адрес вашего интерфейса, просто поменяйте его до подключения.

На этом ресурсе, посвящённом нашей «цифровой тени»: myshadow.org/trace-my-shadow, помимо всего прочего, мы можем увидеть, какие данные передаём о себе в сеть:


Что могут рассказать Браузеры?

Cookies — это текстовые файлы с какими-либо значениями, хранимые приложением (часто — браузером) для разных задач, например, аутентификации. Часто бывает, что клиент сначала посетил ресурс из открытого сеанса, браузер сохранил cookies, а потом клиент соединился из анонимного сеанса, тогда сервер может сопоставить cookies и вычислить клиента.
Более того, существуют так называемые 3rd-party cookies, которые сохраняются у нас, например, после просмотра рекламного баннера с другого сайта (3rd-party). И сайт-владелец этого баннера способен отслеживать нас на всех ресурсах, где размещёны его баннеры.
Тем, кто хочет изучить тему cookies подробнее, советую почитать статьи:

Flash, Java, Adobe. Эти плагины являются по сути отдельными приложениями, которые запускаются от имени пользователя. Они могут обходить настройки прокси, хранить свои отдельные долгоживущие cookies (Flash — Local Shared Objects) и пр. О регулярно публикуемых в них уязвимостях говорить излишне.

Fingerprint (отпечаток) браузера. Браузер предоставляет серверу десятки категорий данных, в том числе и так называемый user agent. Всё это может сформировать достаточно уникальный «цифровой отпечаток браузера», по которому его можно найти среди многих других уже в анонимном сеансе.
Какие именно данные отправляет ваш браузер серверу, можно посмотреть, например, здесь, здесь (он же panopticlick.eff.org) и здесь.

Скрипты Javascript, исполняемые на стороне клиента, могут собрать для сервера еще больше информации, в том числе и явно его идентифицирующей. Более того, если посещаемый нами сайт подвержен XSS, то включенные на нём скрипты Javascript помогут злоумышленнику провести успешную атаку со всеми вытекающими последствиями.

Web Bugs — это невидимые детали веб-страниц, используемые для мониторинга посещений сайта, способны дополнительно отсылать серверу разные данные о клиенте. Web Bugs от Гугла широко распространены по всему интернету.

HTTP-referer — это http-заголовок, с помощью которого веб-сайт может определить, откуда к нему идёт траффик. То есть, если вы кликнули по ссылке, которая передает http referer, то сайт, на который данная ссылка ведёт, сможет узнать, с какого именно сайта вы на него перешли.

Решение: про безопасную настройку каждого из браузеров, включая блокировку каждой из вышеописанных категорий идентифицирующих данных, очень подробно и ясно написано на ресурсе: fixtracking.com, от замечательного поисковика DuckDuckGo:


Приложения

Важно понимать, что изначально многие приложения задумывались и проектировались не столько для обеспечения анонимности, сколько для нормальной и эффективной работы в «трудных» сетевых условиях: обхода блокирующих межсетевых экранов, прокси-серверов.
В качестве примера я приведу лишь малую часть приложений, которые могут самостоятельно передавать в сеть идентифицирующие нас данные.
  • Некоторые клиенты BitTorrent игнорируют настройки прокси, отправляя траффик по открытым каналам.
  • Windows Update отсылает серверу десяток категорий данных, включая уникальный 128-битный идентификатор (GUID). Windows Update также уязвим к MitM, а следовательно, выходной узел, например, Tor, может быть источником атаки.
  • Лицензионные ключи платных или серийные номера бесплатных приложений также могут передаваться в интернет, например, при активации или обновлении, тем самым идентифицируя пользователя.
  • Windows Media Player может самостоятельно запрашивать информацию о музыке или обменивается служебными данными.
  • Данные о часовом поясе могут передаваться при использовании IRC-чата через протокол CTCP, Client-to-client protocol.
  • Дамп оперативной памяти ОС Windows, отправляемый в случае ошибки, также содержит идентифицирующие данные.
  • Метаданные файлов могут включать важные данные: дата создания, авторство и пр.

Решение: не использовать в анонимном сеансе любое недоверенное и непроверенное приложение.

Заключение


Спасибо за внимание! Буду рад конструктивным комментариям и уточнениям.
UPDATE: В следующей статье я расскажу про схему "при которой и пользоваться интернетом не напряжно и никаких следов такого рода не остаётся". А именно: разберу настройки веб-браузера, касающиеся анонимности, на примере Firefox.
@Pandos
карма
66,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (56)

  • +5
    Спасибо, хорошая статья.
    Я считаю, недостаточно одной не очевидной для новичков заметки: при использовании вайфая, ваш трафик может быть прослушан не только самой точкой, но и другими клиентами, подключенными к этой точке. Если точка открытая (без пароля), прослушать трафик — проще простого, если точка с паролем (PSK), то прослушать трафик можно зная пароль.
    • +1
      При этом, используя ARP-spoof, можно также слушать трафик и ловить сессии проводных клиентов, если у них одна и та же подсеть с беспроводными. Примером конкретной реализации, доступной даже школоте, можно считать DroidSheep.
    • 0
      AP Isolation?
    • +1
      Режим WPA2-Enterprise в корне закрывает вопрос, т.к. ключи для каждого клиента уникальны. Разве что, броадкасты останутся.
      У некоторых Tier2 вендоров (Ruckus, Aerohove) есть PPSK — индивидуальный PSK для каждого клиента.
      Я вот тут писал про это с несколько иного ракурса: habrahabr.ru/post/149661/

      Плюс, при поднятии тоннеля SSH/VPN поверх даже открытого Wi-Fi — пускай слушают :)
      • +1
        Это конечно, про это я знаю, но не упомянул исключительно потому, что считаю, что люди, которые даже используют 802.11x, не говоря уже о тех, кто настраивал его, хоть что-то знают в безопасности.
        Ну а, собственно, VPN необходим, я считаю, поверх вайфая в кафе.
    • 0
      Да Вы правы.
      Открытый wi-fi — это частный случай любого открытого канала связи. Просто добавляется ещё одна возможность слушать траффик, находясь в зоне доступности wi-fi точки. Но от этого как раз и спасают VPN/SSH.
  • 0
    Следовательно, клиенту надо как-то этот ip-адрес узнать, а узнать его клиент может только прямым DNS-запросом в обход прокси.
    Но ведь существует DNS over TCP, который можно пробросить через SOCKS4?
    • 0
      Но зачем, когда есть SOCKS5?
    • 0
      А конкретные примеры, как это реализовать привести можете?
      Пробросить через socks можно и UDP тоже, вопрос в том, что системные библиотеки не умеют работать через socks, а в большинстве приложенией разрешение имен делается через них.
      • 0
        То, что приложения могут работать не так, как мы хотим, не является недостатком протокола. В конце концов, злонамеренное приложение может и VPN сделать более не анонимным.

        Реализовать же можно запросто — поставить локальный dns-proxy, указав ему использовать только протокол tcp для исходящих запросов. Разумеется, на всех интерфейсах надо прописать 127.0.0.1 в качестве dns-сервера. Ну, а потом этот dns-proxy можно соксифицировать, если он не умеет ходить через SOCKS самостоятельно.
        • 0
          А в чем суть использования TCP? что не дает пробросить UDP через socks?
          • 0
            Очевидно, суть в возможности использовать четвертую версию протокола.
  • +5
    HTTP_X_FORWARDED_FOR — это не заголовок HTTP, заголовок называется «X-Forwarded-For».
    • 0
      Спасибо, поправил.
  • 0
    Очень полезно.
    Информация, которая все больше и больше (в текущих реалиях) становится необходимой к изучению даже обычному пользователю.
  • 0
    Только вчера про СОРМ-3 читал. Спасибо, пригодится.
    • 0
      о, кинь про третий, плиз
      • +4
        Вот так, например. См. ТТХ, адская машина.
        • +2
          — Количество загружаемых CDR телефонных соединений, млн/час — 5 000
          — Размер активной абонентской базы в сутки, тыс. абонентов — 2 000

          5000 млн. телефонных соединений в час?
          Прослушка 2 млн уникальных абонентов в сутки?
          Почему на Хабре нельзя материться?
  • 0
    Еще один способ обезопасить себя от разрыва vpn — это настройка файрвола. Подойдет в том числе и стандартный windows firewall. Есть инструкция с картинками. Причем блокирующие правила можно не создавать, а ограничиться 10-м пунктом. Для отдельных программ (например для openvpn) можно отдельно создать разрешающие правила, чтобы эти программы работали даже если впн не подключен.
  • +1
    Я думаю, если строить защищённую конструкцию, то следует просто выделять две сессии — защищённую и не защищённую. Лидера сессии положить в cgroups, откуда не-vpn интерфейс просто не доступен для использования — в этом случае информация будет отправляться только через этот интерфейс.
    • 0
      Да, оба варианта тоже актуальны. Спасибо!
  • +4
    Если сравнивать SSH и OpenVPN, поделюсь уже проведённым исследованием:
    network — 115 MBytes @ 96.5 Mbps.
    network/SSH — 112 MBytes @ 94.2 Mbps.
    network/VPN — 38.8 MBytes @ 32.4 Mbps.


    Это очень спорно и, скорее всего, мало соответствует текущей действительно. Во-1, тестирование от 2009 года. Во-2, не очень ясны настройки всей шифровальной кухни, сжатия и прочего. Я совсем недавно тестировал openvpn 2.3 на стомегабитах проседание от реальной скорости канала процентов 30 от силы, а никак не 60.

    А еще может я болван, но я не понимаю значения чисел через собачку. В каком направлении трафика тестирование? Почему два числа? Если это мегабайт и мегабиты, то почему они не в 8 раз различаются?

    Автор, Вы приводите эти цифры, Вы сами в них разобрались?
    • +1
      Правые числа — это измеренные скорости, а левые — это количество принятой информации в течении времени эксперимента. Если левые числа поделить на правые, то получим время эксперимента. Смысл левых чисел лично мне непонятен.
  • +2
    Думаю стоило упомянуть что при использовании Socks прокси в Firefox, DNS-leaks будет по умолчанию происходить, чтоб от этого избавиться, надо:
    В адресной строке набираем about:config,
    Жмем «I'll be careful, I promise!»,
    Находим опцию network.proxy.socks,
    Двойным кликом меняем значение на true,
    Все, теперь при использовании socks прокси, dns запросы будут тоже ходить через socks

    • 0
      А в Chrome по умолчанию наоборот? Или вообще не настраивается?
    • 0
      Может быть все-таки network.proxy.socks_remote_dns?
      • 0
        Да, всё верно:
        True: Perform all DNS lookups on remote proxy server (see bug 134105)
        False (default): Perform all DNS lookups client-side
  • 0
    Вот я сейчас провел тесты на своем VPN-сервере. Условия далеки от лабораторных, так как это боевая ВДС, просто в момент измерений я слежу, чтоб на ней ничего не грузило серьезно ни канал, ни процессор. OpenVPN использует включенное comp-lzo adaptive (поэтому скорость получается выше реальной)

    Тестрирую с помощью
    iperf -t 30 -c server на стороне клиента, то есть тестируется скорость передачи ОТ клиента к серверу. Реальный исходящий 40 мегабит, но на ВДСке shared 100, поэтому реально 40 мы не имеем.

    Итак:
    чистое соединение — ~30 мегабит\с
    vpn (openvpn 2.3 тюнингованный, gentoo linux) — ~35 мегабит\с (см. первый абзац)
    openssh (OpenSSH_5.9p1-hpn13v11, OpenSSL 1.0.1c 10 May 2012 из коробки с минимальными настройками) — ~ 30 мегабит\с

    Что нам доказывает мой коммент? Что пока Вы не поднимете тестовый стенд сами вот здесь и сейчас, померяете скорости и выложите результат с версиями и конфигами — цифры яйца выеденного не стоят, в реальности — прямо противоположны действительности.
  • 0
    И еще. Сами же пишете, что OpenSSH уже умеет использовать туннельные интерфейсы, а потом
    Через SSH-туннель единовременно отправляется траффик одного приложения.


    Вы уж определитесь, в каком времени Вы существуете.

    Да и редирект портов через -L нас не обязывает использовать одно приложение, мы просто редиректим один порт. Несколько -L — несколько портов.

    Да и -D, который ssh заставляет действовать как socks5 прокси, никто не отменял.
    • 0
      Спасибо за комменты, фраза: «Через SSH-туннель единовременно отправляется траффик одного приложения.» была лишней :)

      В оценке скорости был не прав. Действительно, для полноценного ответа на этот вопрос надо учесть много факторов, я оказался слишком опрометчив.
      Буквально сейчас измерил чистую скорость:

      А потом включил OpenVPN одного из коммерческих провайдеров:

      Ясное дело, что надо делать достоверную выборку. Займусь этим.
  • +1
    panopticlick.eff.org
    Забавный сервис. Как ни зайду — он всегда говорит, что у меня уникальный фингерпринт.
    • 0
      Как я понял по логике данного инструмента уникальный отпечаток ты можешь сам себе сделать — разработав и установив свой собственный шрифт в систему (при это вовсе не надо остальные шрифты сносить.) и больше нигде его не распространяя.
      Ну как вариант.
      • 0
        Могут оценивать схожесть фингерпринтов, например.

        Я не про это. Этот сервис, по логике вещей, увидев, как я захожу второй раз, должен сказать «кто-то уже заходил с таким же фингерпринтом столько-то минут назад, возможно, это были вы». А он просто каждый раз говорит, что мой фингерпринт уникален. Поэтому смысла в таком сервисе ноль.
        • 0
          Может они какой-то еще параметр(-ы) сверяют, не афишируя его(их).
          Например один и тот же IP, который заходит несколько раз подряд и при этом идет совпадения по всем остальным параметрам — можно сделать вывод с относительно высокой доли вероятности, что это один и тот же комп.
          Может они делают такое допущение.
          Ну как вариант)
        • 0
          panopticlick.eff.org/faq.php первый вопрос.

          Если в кратце, они ставят трехмесячные куки. Попробуйте отключить приём куки с их сайта. У Вас же что-то unix-like? Более — менее «рандомизироваться» позволяет смена user-agent'а у броузера. Я использую плагины для FF и chromium.

          Q:

          Why does your browser remain unique, even if you reload the page?

          A:

          As noted in the panopticlick privacy policy, the site uses a 3-month persistent cookie to try to prevent double-counting of browsers.

          Now, you may ask, what about people who block cookies? If you block cookies and hit reload, your browser will be multi-counted in the live data at panopticlick.eff.org, which means that the numbers will be overly optimistic about how non-rare your broswer is.

          We plan to do some analysis on the dataset to correct out these effects. One strategy would be to assume that the average number of reloads for a cookie-accepting user is the same as that for a cookie-blocking user. Another would be to use the encrypted IP addresses and fuzzy timestamps we have to try to recognise and discount cookieless reloads.

          Once we've run these analyses, we'll publish public data on the overall uniqueness rates we've seen.
  • 0
    В этот раз ни к чему особо придраться не могу (разве что цифры тестирования скорости ssh/vpn какие-то сомнительные, но это вроде как не принципиальная часть статьи). Только замечу что во втором разделе в этот раз вы только указываете на проблемы, но не предлагаете решений. Конечно специалистам это не требуется, но им и про сами проблемы читать не нужно…
    • 0
      Спасибо, с каждой новой статьёй я всё более критичен к каждому набираемому слову.
      Я уже в полной мере прочувствовал свою неправоту в части оценки скорости :) Поразмыслив про тестирование скоростей, понял, что эта тема может стоить отдельной статьи.

      По поводу решений проблем. В своём исходном материале решения для каждой из них у меня есть. Не публиковал их потому что специалист проблему решит, а неспециалисту в большинстве случаев достаточно просто скрыть свой ip-адрес.

      Думаете, стоит написать?

      • 0
        Я бы пожалуй добавил для примера описание какой-то конкретной работающей схемы с блокировкой ненужных куков, хранилищ браузера/флеша и т.п. Т.е. схему при которой и пользоваться интернетом не напряжно и никаких следов такого рода не остаётся. Причём в большинстве случаев для этого не нужен какой-то спец. софт, а нужна только спец. настройка обычного софта. И вот как раз эту настройку я бы и описал.

        О, кстати, только сейчас заметил что в описание браузеров вы про HTTP referer ничего не сказали, а это как бы отдельная специфическая дырка в анонимности.
        • 0
          Ок, я просто придерживал тему разбора схемы «при которой и пользоваться интернетом не напряжно и никаких следов такого рода не остаётся» на самый финал. Она достойна подробного описания, и если её включить сюда, то читать длиннющие статьи может быть скучно.
          Пока я описал некоторые приёмы в общем, плюс добавил славный ресурс от DuckDuckGo.

          Про реферер — верное замечание, добавил.
  • +1
    Учитывая последние события, актуальными становятся статьи не столько об устройстве *.onion и *.i2p, а о том, как их поднять, какие CMS в большей степени адаптированы и какие особенности нужно учитывать при создании таких сайтов.
  • 0
    Хозяйке на заметку, bittorrent клиент Vuze имеет замечательную настройку Advanced Network Settings -> Bind to local IP address or interface. Ставим туда к примеру tap0 и торрент трафик идёт только через SSH/VPN
    • +1
      Это всё полумеры — за каждым приложением и глюками в нём уследить невозможно. Поэтому единственный адекватный подход — настройка единственного роутинга в инет через vpn-интерфейс средствами OS (плюс для страховки заблокировать исходящие пакеты куда либо кроме vpn на файрволе).
      • 0
        Не всем это нужно. Иногда хочется чтобы было просто :) Мне VPN пока нужен только для торрентов. Но соединение может и упасть, отчего спасает данная настройка.
        • 0
          Из моего ответа на этот комментарий получилась целая статья: «Немножко анонимен».
          • 0
            Терпение, немного терпения :)
            Мы идём вглубь анонимности, начиная с самых основ. Цель первых статей — не обеспечить абсолютную анонимность, а ввести читателей в курс, научить базовым понятиям, не испугав. Иначе именно в них и будут ошибки.

            В конце будут действительно пилотажные вещи. Чтобы их правильно понять, необходимо понимать и различие между видами SOCKS ;)
            • +1
              Честно говоря, я не думаю, что обычным пользователям нужно разбираться в версиях SOCKS, архитектуре Tor или алгоритмах шифрования VPN. Им нужна тулза, которую они запустят, она им развернёт виртуалку, настроит Tor и файрвол в host OS, запустит в виртуалке кошелёк биткоин и предложит оплатить один из списка VPN-сервисов, после чего настроит VPN-подключение и завершится. А вот что обычным пользователям нужно, так что чётко понимать как важно избежать передачи по анонимному каналу каких-либо данных, которые могут связать этот анонимный канал с его реальной личностью.
              • 0
                Возможно, в чём-то вы правы.

                Начинающим пользователям может хватить и первой статьи, а также обычного VPN для обхода простеньких блокировок. В любом случае каждый человек может выбрать подходящее для него средство в зависимости от своих задач.
                С каждой следующей я повышаю градус технических подробностей. Соответственно, дальнейшие статьи в основном будут интересны уже фанатам. Там будут и более серьезные схемы анонимности.
  • 0
    Вы e-tags забыли упомянуть.
    • 0
      Да, спасибо, я указал ссылку на эту тему в тексте:
      Тем, кто хочет изучить тему cookies подробнее, советую почитать статьи:
      Cookie без куков.


      Потенциально все «временные» файлы браузера (cookies, кеш) — идентификаторы.
  • 0
    Flash, Java, Adobe. Эти плагины являются по сути отдельными приложениями, которые запускаются от имени пользователя. Они могут обходить настройки прокси, хранить свои отдельные долгоживущие cookies (Flash — Local Shared Objects) и пр.

    Кстати, что если на сайте стоит CAPTCHA с таким приложением, а Вам хочется отправить «злобный коммент»? — Использовать VPN?
    • 0
      Например, из такого сервиса: https://keeep.us/ru/captcha/
    • 0
      Если не хотите неожиданностей и заботитесь всерьёз об анонимности, советую полностью отключать Flash, Java, Adobe.
      Но в вашем случае, думаю, всё не настолько серьезно. Прикройтесь VPN или прокси. И пишите добрые комментарии :)
  • 0
    А зачем было замазывать ники на античате? forum.antichat.ru/showthread.php?t=328657
  • 0
    Не забываем про такой чудесный инструмент, как sshuttle
  • 0
    Я бы ещё посоветовал поднять свой кэширущий днс. Таким образом со стороны будет не видно как часто посешаешь какой либо ресурс. Также категорически не рекомендую пользоваться днс от провайдера. Во многих торрентах указан трекер retracker.local который резолвится днсом провайдера, итог: знаем кто — знаем что качает.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.