Методы анонимности в сети. Утечки данных!

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

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

Возможно, VPN-сервер в Панаме действительно более безопасен, чем такой же сервер в Испании. А возможно — нет.

Не будем говорить про цепочки узлов, так как их надежность с трудом поддаётся оценке. С одной стороны, в виду организационных сложностей, риск раскрытия ниже, а с другой — мы должны быть достаточно уверены в каждом узле.

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

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-соединение обрывается.

Еще один способ обезопасить себя от разрыва vpn — это настройка файрвола. Подойдет в том числе и стандартный windows firewall. Есть инструкция с картинками. Причем блокирующие правила можно не создавать, а ограничиться 10-м пунктом. Для отдельных программ (например для openvpn) можно отдельно создать разрешающие правила, чтобы эти программы работали даже если впн не подключен.

Если строить защищённую конструкцию, то следует просто выделять две сессии — защищённую и не защищённую. Лидера сессии положить в cgroups, откуда не-vpn интерфейс просто не доступен для использования — в этом случае информация будет отправляться только через этот интерфейс.

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

Какую идентификационную информацию о себе мы можем передать в интернет?

Общее

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.

При использовании 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). И сайт-владелец этого баннера способен отслеживать нас на всех ресурсах, где размещёны его баннеры.

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

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

Какие именно данные отправляет ваш браузер серверу, можно посмотреть, например, здесь и здесь.

Скрипты 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, отправляемый в случае ошибки, также содержит идентифицирующие данные.
• Метаданные файлов могут включать важные данные: дата создания, авторство и пр.

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

⚡️Читайте самые интересные материалы про безопасность на канале Безопасность Личности⚡️