Анонимная анонимность: борьба с утечками трафика и IP. Повышаем анонимность за прокси: скрытие ip адреса от утечки

26.01.2019

Зарубежный ресурс

На данный момент собрано 14 методов проверки:

1. Заголовки HTTP proxy

Некоторые прокси дописывают свои заголовки к запросу, который инициирует браузер пользователя. Нередко это реальный IP адрес пользователя.

Убедитесь, что прокси сервер, если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

HTTP_VIA, HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR, HTTP_X_FORWARDED, HTTP_FORWARDED, HTTP_CLIENT_IP, HTTP_FORWARDED_FOR_IP, VIA, X_FORWARDED_FOR, FORWARDED_FOR, X_FORWARDED, FORWARDED, CLIENT_IP, FORWARDED_FOR_IP, HTTP_PROXY_CONNECTION

2. Открытые порты HTTP proxy

IP адрес, с которого пришел запрос к нашей страничке может сказать о многом. Можно например посмотреть какие на той стороне открыты порты?

Самые паленые порты: 3128, 1080 и 8123. Если их не использовать, то вполне можно избежать необоснованных подозрений в использовании 3proxy, SOCKS 5 или Polipo.

3. Открытые порты web proxy

Как и в случае с HTTP, веб прокси можно повесить на любой порт, но мы хотели, чтобы тест работал очень быстро, поэтому ограничились обратным коннектом на порты 80 и 8080.

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

4. Подозрительное название хоста

Имея IP адрес можно попробовать отрезолвить хостнейм клиента. Стоп слова, которые могут намекать на туннель: vpn, hide, hidden, proxy.

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

5. Разница во временных зонах (браузера и IP)

Исходя из данных GeoIP можно узнать страну по IP пользователя, а следовательно и его временную зону. Дальше можно вычислить разницу во времени между браузером и временем соответствующим временной зоне VPN сервера.

Разница есть? Значит пользователь наверняка скрывается.

Для России точной базы latitude и longtitude для регионов нет, а так как временных зон много, то в конечном результате эти адреса мы не учитываем. С Европейскими странами всё наоборот, очень хорошо они палятся.

При переключении на VPN нужно не забывать переводить системное время, менять время в браузере, либо работать с русскими прокси.

6. Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из списка

Поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

7. Режим браузера Turbo

Собрав диапазоны IP адресов Google, Yandex и Opera, и сравнив с пользовательским адресом, можно предположить использование сервисов сжатия трафика в браузерах соответствующих компаний.

Как правило такие сервисы ещё и сливают ваш реальный адрес в заголовках. Как на средство анонимизации, рассчитывать на сжатие трафика не следует.

8. Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

Веб прокси (по нашему анонимайзеры) в принципе не надёжны, поэтому лучше обходить такие способы анонимизации совсем.

9. Утечка IP через Flash

Adobe Flash очень хорошо работает мимо пользовательских прокси. Инициировав соединение к нашему серверу, можно узнать IP пользователя.

Запустив специального демона, который логирует все входящие соединения с ключами-метками, можно многое узнать. Лучший способ не раскрывать свой адрес - не использовать Adobe Flash вообще, или отключать в настройках браузера. К примеру, браузер Firefox по умолчанию отключает flash, стоит задуматься.

10. Определение туннеля (двусторонний пинг)

Запустив пинг к клиентскому IP, со стороны нашего сервера, можно узнать приблизительную длину маршрута. То же самое можно сделать со стороны браузера, XMLHTTPRequest дёргает пустую страницу нашего nginx. Полученную разницу в петле более 30 мс можно интерпретировать как туннель.

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

Единственный способ защититься - запретить ICMP трафик к своему VPN серверу, правильно настроив свой фаервол.

11. Утечка DNS

Узнать какой DNS использует пользователь не проблема, мы написали свой DNS сервер, который записывает все обращения к нашим уникально сгенерированным поддоменам.

Следующим шагом собрали статистику на несколько миллионов пользователей, кто и какой DNS использует. Сделали привязку к провайдерам, отбросили публичные DNS и получили список пар DNS/ISP.

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

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Это не утечка IP адреса, но отдавая всем налево и направо имена авторизованных пользователей, к примеру VK сливает частные данные, которые подрывают всю анонимность серфинга.

Подробнее можно посмотреть документацию здесь

Пожалуйста или чтобы увидеть скрытый текст

Кнопка «Выход» после каждой сессии в общем то решает вопрос, но лучшая рекомендация - не использовать социальные сети

13. WEB-RTC

WebRTC позволяет устанавливать конференц-связь без использования плагинов через современные браузеры Mozilla и Chrome, но при этом раскрывает Ваш реальный IP даже при использовании VPN, а также список всех локальных IP-адресов, находящихся за NAT.
WebRTC поддерживается только в браузерах Chrome и Firefox. Родной поддержки WebRTC браузерами Internet Explorer и Safari не существует.

Отключение WebRTC в Firefox:
В адресной строке браузера вводим
Код:
about:config
Задаем в поиске:

Код:
media.peerconnection.enabled
Устанавливаем значение в "false" и снова проверяем!

Отключение WebRTC в Chrome:
В браузере Google Chrome для блокировки WebRTC необходимо установить плагин

Пожалуйста или чтобы увидеть скрытый текст

Отключение WebRTC на Android для пользователей Chrome:
В адресной строке браузера Chrome вводим:

Код:
chrome://flags/#disable-webrtc
Устанавливаем значение "enable"

Еще один альтернативный способ определения proxy и vpn:

14. MSS и MTU
MTU, или Maximum Transmission Unit - максимальное количество данных, которые могут быть переданы в одном пакете. MTU установлен у каждого сетевого адаптера, даже у тех маршрутизаторов, через которые трафик от вас до удаленного сервера идет транзитом. В большинстве случаев, в интернете используют MTU 1500, однако бывают заметные исключения, которые зачастую подчиняются некоторым правилам.

Когда ваш браузер или любое другое ПО, работающее с сетью, создает TCP-соединение к удаленному серверу, в заголовки пакета помещается значение Maximum Segment Size (MSS), которое сообщает серверу, какого максимального размера сегменты он может передавать в одном пакете. Это значение очень близкое к MTU, оно сразу дает понять серверу о возможностях вашего интернет-соединения, исключая излишнюю фрагментацию и позволяя утилизировать ваш канал по полной.
Когда вы отправляете пакет, будучи подключенным к VPN по какому-то протоколу (PPTP, L2TP(±IPsec), IPsec IKE), он помещается (инкапсулируется) в еще один пакет, что вносит свои накладные расходы, и большие пакеты, которые были бы отправлены без фрагментации без VPN, теперь придется фрагментировать. Чтобы избежать такой фрагментации, ОС устанавливает на сетевом интерфейсе MTU меньше, чем MTU реального сетевого интерфейса, из-за чего ОС не пытается создавать большие пакеты, которые требовали бы фрагментации.
В случае с PPTP, L2TP(±IPsec), IPsec, как я понимаю, нет каких-то стандартов на MTU туннеля, все устанавливают такие значения, чтобы работало в большинстве случаев, и устанавливаются они на глаз. Как правило, это 1400, что позволяет использовать, скажем, PPTP на каналах с MTU до 1440 без фрагментации (например, когда для доступа в интернет требуется еще один туннель, как часто бывает у российских провайдеров).

OpenVPN - почти самый популярный вариант VPN.
При совместимости со старым или кривым софтом, OpenVPN по умолчанию не устанавливает меньшее значение MTU на VPN-интерфейсе, а изменяет значение MSS внутри инкапсулированного TCP-пакета. За это отвечает параметр mssfix, установленный по умолчанию в значение 1450. Он изменяет MSS таким образом, чтобы он полностью утилизировал канал с MTU 1450, т.е. высчитывает свои накладные расходы таким образом, чтобы они проходили через канал с MTU 1450 и более без фрагментации. В результате у нас появляется возможность не просто определить пользователей OpenVPN со стандартным mssfix 1450, но и определить их протокол подключения (IPv4, IPv6), протокол транспортного уровня (TCP, UDP), параметры шифрования, сжатия и MAC, т.к. они вносят свои уникальные накладные расходы и отражаются в MSS.
Типичные параметры MSS:

Если используется шифрование в 64 бита, то это Blowfish, а если 128 бит - AES.

Тестирование двух VPN-сервисов: VyprVPN и ibVPN. Оба сервиса подвержены определению настроек описанным методом.
Если вы не хотите, чтобы вас обнаруживали таким способом, вы можете либо отключить mssfix, установив его в 0 и на сервере, и на клиентах, получив таким образом MSS 1460 (характерно для IPv4), что соответствует MTU 1500 - типичному MTU для обычного проводного соединения, которое есть у подавляющего большинства пользователей.
НО в этом случае вы получите излишнюю фрагментацию, что приведет к повышению задержек и уменьшению пропускной способности, поэтому стоит установить MTU в 1400, 1380 или похожее (должно быть кратно 10), т.к. такие значения часто используются провайдерами, например, мобильного интернета.

Теперь немного о

Пожалуйста или чтобы увидеть скрытый текст

Этот маленький проект расскажет вам о настройках вашего OpenVPN-соединения (если вы не изменяли mssfix), попытается определить вашу ОС и сравнить ее с ОС в User-Agent, получит PTR-запись для вашего IP и сравнит ее с набором правил, определяя, используете ли вы интернет-канал, рассчитанный на домашних или серверных пользователей.
Код:
First seen = 2015/07/24 17:19:29
Last update = 2015/07/24 18:39:37
Total flows = 7
Detected OS = Linux 3.11 and newer
HTTP software = Firefox 10.x or newer (ID seems legit)
MTU = 1409
Network link = OpenVPN UDP bs64 SHA1
Language = Russian
Distance = 15
Uptime = 1 days 19 hrs 39 min (modulo 165 days)

PTR test = Probably home user
Fingerprint and OS match. No proxy detected.
OpenVPN detected. Block size is 64 bytes long (probably Blowfish), MAC is SHA1.

ＷＩＴＣＨ？ также без проблем определяет пользователей Tor Browser, т.к. он использует одинаковый статичный User-Agent (с Windows) на всех ОС, а exit nodes запущены под Linux и FreeBSD.

В результате тестирования на разных ОС и провайдерах выяснилось:

Мобильный интернет от Beeline пропускает все соединения через прокси под Linux. Обнаружилось это, когда человек с Beeline зашел с iPhone на ＷＩＴＣＨ？, и ОС определилась как Linux. Вероятно, именно через него они меняют HTML-теги, добавляют тулбар с поиском mail.ru и изменяют дизайн сайтов.
MTU у мобильных устройств может быть буквально какой угодно, но, как правило, заканчивается на 0. Исключение - Yota с 1358. От чего это зависит - непонятно, подозреваю, что и от настроек на стороне оператора, и от телефонного модуля. Одна и та же SIM в разных телефонах использует разные MTU.
Код, который отвечает за mssfix в OpenVPN, очень медленный.

Ну и в конце статьи я предлагаю затестить
замечательный ресурс

Пожалуйста или чтобы увидеть скрытый текст

Этот проект может пассивно прослушивать трафик, определять ОС, MTU и браузер, оповестить о несовпадении ОС создателя пакетов и ОС в User-Agent.
p0f также имеет API. Немного

Пожалуйста или чтобы увидеть скрытый текст

Добавив экспорт MTU через API и обновив сигнатуры, можно детектировать пользователей популярных VPN-протоколов, пользователей прокси и тех пользователей, которые подделывают User-Agent.

Всем привет! Недавно, благодаря одному человеку, наткнулся на сервис 2ip.ru/privacy/ . Данный сервис предлагает Вам проверить степень своей анонимизации. Дефект моей системы для вбива заключался в том, что мерчи могли спалить наличие туннеля при помощи двустороннего пинга. Если сервис обнаружит у вас наличие туннеля, то соответственно появляется заветная надпись: "Вероятность анонимизации 99%"
Наша задача заключается в том, чтобы запретить компьютеру принимать запросы пинга от интернет ресурсов. Приступаем к настройке.Во-первых, для начала советую Вам настроить Фаерволл в соответствии с темой пользователя Kardiara
Я сделать это для того, чтобы исключить утечки, а также задобрить Богов Кардинга, принеся в жертву все исходящие подключения, кроме тех, которые производятся из Bitvise"a и Proxifier"a. После того как основная настройка Фаерволла произведена, вносим некоторые дополнения.
Шаг 1.
Заходим в расширенные настройки Фаерволла(Advanced settings).
SpoilerTarget">Спойлер: Спойлер
Шаг 2.
Выбираем Inbound Rules слева, а затем New Rule справа.
SpoilerTarget">Спойлер: Спойлер

Шаг 3.
Выбираем Custom Rule.
SpoilerTarget">Спойлер: Спойлер

Шаг 4.
Выбираем All Programs
SpoilerTarget">Спойлер: Спойлер

Шаг 5.
Выбираем Protocol type: ICMPv4, если используете для подключение протокол TCP/IPv4 или ICMPv6, если используете для подключения протокол TCP/IPv6 соответственно.
SpoilerTarget">Спойлер: Спойлер

В разделе Customize оставляем All ICMP types.
Шаг 6.
Оставляем всё как есть для того, чтобы наше правило действовало для всех подключений.
SpoilerTarget">Спойлер: Спойлер

Шаг 7.
Выбираем Block the Connection. Ведь нам же нужно заблокировать все запросы, связанные с протоколом ICMP (Ping).
Видим, что сервис не имеет доступа для проверки двустороннего пинга.
Что касается открытых портов. Пообщавшись с опытными людьми, пришел к выводу, что это не критично. Ведь разве не имеет права человек открыть порты? К примеру, для поднятия того же сервера Counter-Strike. Значение открытых портов Web Proxy может варьироваться в зависимости от самого туннеля.Можно увидеть: Yes, Maybe,No. Порты открыты именно на самом SSH сервере.
UPD : Подводя итоги двух дней исследований, сделал вывод о том, что на программном уровне данный тест никак не обойти.
1.Можно попытаться заблокировать ICMP траффик на самом сервере.
2.Обойти данный детект можно:
а.) Использованием дедиков
б.)Использовать быстрый интернет в совокупности с шустрым туннелем.
в.)Используя соксы,вместо SSH (?)
3.Лучше работать с мозиллы, чем с гугл хрома (Личные наблюдения)
4.Обязательно настройте фаерволл в соответствии с темой Kardiara, дабы исключить утечки при разрыве соединения.
5. Не забывайте о таком важном параметре как ProxyScore.

Ранее мы описывали достаточно шикарный способ утечки вашего реального IP адреса с помощью протокола Кроме этого способа также существуют другие методы определения вашего реального IP адреса. Сегодня мы раскажем вам о основных принципах обеспечения своей безопасности и анонимности в сети.

http://witch.valdikss.org.ru/ – позволяет определить какой тип подключения вы используете и исползуете ли вы VPN.

http://2ip.ru/privacy/ – позволяет собрать множество дополнительной информации о вашем браузере, типе подключения и IP адресе.

https://diafygi.github.io/webrtc-ips/ – определяет ваш IP адрес с помощью протокола WebRTC.

Мы подобрали для вас этакий чек-лист, который бы отвечал, «палишься» ты или нет? На данный момент список состоит из 12 методов проверки, о которых ниже и пойдет речь, в том числе о том, как на них не попасться, но сначала о самом простом по порядку.

Заголовки HTTP proxy

Убедитесь, что прокси сервер если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

Открытые порты HTTP proxy

Самые интересные порты 3128, 1080, 8123. Если их не использовать, то вполне можно избежать необоснованных подозрений в использовании 3proxy, SOCKS 5 или Polipo.

Открытые порты web proxy

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

Подозрительное название хоста

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

Разница во временных зонах (браузера и IP)

Разница есть? Значит пользователь наверняка скрывается.

Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из спискаcheck.torproject.org/cgi-bin/TorBulkExitList.py , поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

Режим браузера Turbo

Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

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

Утечка IP через Flash

Запустив специального демона, который логгирует все входящие соединения с ключами-метками, можно многое узнать. Лучший способ не раскрывать свой адрес - не использовать Adobe Flash вообще, или отключать в настройках браузера.

Определение туннеля (двусторонний пинг)

Запустив пинг к клиентскому IP, со стороны нашего сервера, можно узнать приблизительную длинну маршрута. То же самое можно сделать со стороны браузера, XMLHTTPRequest дёргает пустую страницу нашего nginx. Полученную разницу в петле более 30 мс можно интерпретировать как туннель.

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

Единственный способ защититься - запретить ICMP трафик к своему VPN серверу.

Утечка DNS

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Утечка через ВКонтакте

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

Подробнее можно посмотреть документацию здесь

Привет коллеги:-)! А давайте поговорим о мифической анонимности в сети . За последние несколько лет, мне на глаза попадалось несколько сценариев деанонимизации пользователя и я брал их себе на вооружение. Эти сценарии и опишу в текущей заметке. Мы рассмотрим случаи утечки реального IP и трафика при работе через VPN, соксы, прокси сервера и то, как можно от этого защититься . А вообще я любитель Tails’а и TOR’а:-).

Утечка VPN трафика и IP при обрыве соединения.

Одна из главных проблем в работе с частными виртуальными сетями – это утечка трафика . По-другому говоря, тот трафик, который должен был быть передан через VPN соединение в анонимном виде, попадает в открытый доступ. Данный сценарий не следствие проблем с клиентом или сервером. На самом деле всё гораздо интереснее. Самый банальный вариант – это обрыв VPN-соединения . К примеру, решил прочекать лист SSH или FTP акков, запустил сканер, отошёл по своим делам на несколько минут, приходишь, а соединение внезапно разорвано. Но чекер/сканер при этом продолжает функционировать, и работа идёт уже с твоего реального адреса.

Что делать в этом случае?

Чтобы избежать утечки трафика и реального IP, сохранив свою анонимность, в ситуациях, когда VPN-соединение внезапно разорвалось, попробуйте:

Утечка VPN трафика и IP при работе в сетях с IPv6 и IPv4.

Но есть и более коварные ловушки. Например, утечка VPN трафика довольно часто происходит на хостах, поддерживающих обе версии протокола IPv6 и IPv4 .

Сосуществование двух протоколов может приводить к довольно не приятной ситуации утечки трафика в обход VPN туннеля и раскрытие реального IP. Не смотря на то, что шестая версия протокола не имеет обратной совместимости с четвертой, обе версии словно «склеены» доменными именами (DNS). Рассмотрим простой пример: есть доменное имя веб-сервиса или сайта, у него одновременно прописаны A запись (IPv4 адрес хоста) и AAAA запись (IPv6 запись хоста), их может быть сразу по несколько каждых. Далее, когда наше ПО, поддерживающая оба протокола или только IPv6 (браузер, чекер, сканер и прочее), захочет начать взаимодействие с сайтом, она может запросить любой адрес из прописанных и начнет слать пакеты по полученному адресу и по соответствующему протоколу.

Ииии “сейчас вылетит птичка”:-(Многие VPN реализации не умеют работать с IPv6 протоколом, или игнорируют его. VPN клиент переадресовывает все пакеты с IPv4 адресом через свой туннель, а вот пакеты с IPv6 адресами в заголовке просто игнорируются или не узнаются… Как результат – если у домена указан только IPv6 адрес, трафик пойдет через локальный роутер в открытом виде с реального IP. Карамба, мы работаем себе в сеточке через VPN, а траф топает другими, не предусмотренными нами дорожками!
Повторюсь, основная причина кроется в том, что хоть два протокола и несовместимы друг с другом, но они поддерживаются системой доменных имён. Получается, что для системы поддерживающей оба протокола, невозможно обеспечить безопасное соединение с другой системой, не обезопасив и IPv4 и IPv6.

Провоцируем преднамеренную утечку трафика.

Атакующий пользователь может специальным образом вызвать подключение по шестому протоколу на компьютере жертвы, отправляя ICMPv6 Router Advertisement сообщения. Аналогичные пакеты данных можно отправлять через программы rtadvd (http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=rtadvd), SI6 Networks’ IPv6 Toolkit (http://www.si6networks.com/tools/ipv6toolkit/)или THC-IPv6 (http://thc.org/download.php?t=r&f=thc-ipv6-2.1.tar.gz), в результате при удавшемся ipv6 соединении можно получить утечку трафика и данных, перехватывая их далее MITM атакой.

Что делать в этом случае?

Чтобы отправлять весь трафик через VPN-соединение, тогда стоит сделать следующее:

В случае отсутствия поддержки IPv6 VPN клинетом, необходимо отключить шествую версию протокола на всех доступных сетевых интерфейсах. Тогда, у всех активных в сети приложений не будет другого выбора, кроме как использование IPv4 протокола. !!!Коротко!!! снимите галочку у протокола IPv6 в настройках сети!
В случае если IPv6 у VPN клиента поддерживается — стоит убедиться в том, что весь передаваемый трафик отправляется через VPN.

А теперь проверь себя!

Проверьте уязвимость своей конфигурации на утечку данных через сайт www.dnsleaktest.com , после чего примените советы, приведённые в этой статье, чтобы убрать утечку DNS-трафика.