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

28.01.2019

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

Главная идея - определить, скрывается пользователь во время сёрфинга в сети или нет, и по возможности узнать его реальный IP адрес. Есть несколько интересных фишек, которые в принципе я нигде не встречал (двусторонний пинг, сопоставление пар DNS leak/ISP).

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

Заголовки 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Утечка DNS

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

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

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

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

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

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

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

Ранее мы описывали достаточно шикарный способ утечки вашего реального 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

Открытые порты 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

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

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

Утечка DNS

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

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

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

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

07 Sep 2016 | Автор: anchous |

В последнее время неоднократно приходится сталкиваться с вопросами людей, как им повысить анонимность, чтобы конечный сайт, к которому обращается клиент через прокси или VPN, не видел их реальный IP адрес.

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

Причем многие новички полагают, что если чекалки, вроде _https://whoer.net/ или _https://2ip.ru/privacy/ видят реальный IP, скрытый за прокси, то это проблема анонимности прокси.

Возможно я кого то разочарую, но в данной проблеме чаще всего виноват не прокси сервер.

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

Единственное, чем можно повысить анонимность прокси, использовать для сервера нестандартные исходящие порты, т.к при проверки приватности чекаются открытые порты клиентского IP (в данном случае прокси) и если видят стандартные 80, 8080, 1080 и т.д, то раcценивают это – как практически 100% вероятность подмены IP адреса с помощью прокси.

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

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

Также я не буду особо вдаваться в технические аспекты того или иного протекания IP (IP leak) в браузере, т.ч если хотите технических подробностей, то гугл вам в помощь.

Большая часть настроек, разве кроме части закрытия протекания DNS, делается в тонких настройках браузера Firefox, куда можно попасть, если ввести в адресную строку about:config

Начну с двух наиболее критических дырок, роняющих приватность ниже плинтуса, т.к через них реальный IP адрес протекает гарантировано. И все попытки скрыть реальный IP адрес от обнаружения, обречены на провал.

Это протекание через Adobe Flash и WebRTC. Первый является сторонним плагином, а второй встроенная во все браузеры технология, предназначенная для общения бродилок peer-to-peer и шпарящая в обход прокси.

Adobe Flash
Плагину ShockWave Flash в принципе лучше сказать запускаться по требованию: Основное меню FF -> Дополнения -> Расширения а также изменить значение параметра в настройках FF
plugin.state.flash = 0

WebRTC
Здесь мы либо просто блокируем технологию
media.peerconnection.enabled = false
либо говорим ей логиниться по дефолтному маршруту
media.peerconnection.ice.default_address_only = true
но не знаю как это должно отрабатывать на проксях, т.ч для гарантированной подмены IP я предпочитаю закрывать все.

Для Google Chrome существует плагин WebRTC Block или WebRTC Leak Prevent (оно также есть и для Opera). Для FF не нашел, но особо и не искал, т.к по мне достаточно заблокировать сам движок.

Также можно заморочиться с добавлением в систему дополнительного интерфейса, с нужным IP. В виндовой машине это будет Microsoft Loopback Adapter. Но там есть мутотень, что каждый раз, при смене IP прокси, придется менять и айпи адрес нашего виртуального интерфейса, а также его маршрутизацию наружу. Так что этим стоит загоняться только если у вас с избытком свободного времени и не подошли вышеописанные варианты.

JavaScript и ActiveX
Эти надстройки также подвержены протечкам IP, т.ч их желательно закрыть с помощью дополнения NoScript. Оно будет не бесполезно и в мирное время, т.к позволит предотвратить XSS атаки от злодейских сайтов и попыток напихать всякое зверье в процессе браузинга.

Отключаем геолокацию через браузер
geo.enabled = false

Отключаем фичу предупреждения о вредоносных сайтах Google Safe Browsing
browser.safebrowsing.enabled = false
browser.safebrowsing.downloads.enabled = false
browser.safebrowsing.malware.enabled = false

Отключаем отправку телеметрии и отчетов производительности
datareporting.healthreport.service.enabled = false
datareporting.healthreport.uploadEnabled = false
toolkit.telemetry.unified = false
toolkit.telemetry.enabled = false

Отключаем Encrypted Media Extensions (DRM)
media.eme.enabled = false
media.gmp-eme-adobe.enabled = false

Отключаем возможность FF логиниться без спроса к сторонним сервакам Telefonica
loop.enabled = false

Отключаем отслеживание статей и видосов через сторонний сервис Pocket
browser.pocket.enabled = false

Отключаем передачу текста, который мы вводим в окно поиска
browser.search.suggest.enabled = false

Отключаем передачу параметров соединения с сетью
dom.network.enabled = false

Все это и много другое, можно также отрубить с помощью отдельного . И/Или можно поставить HTTP UserAgent cleaner, который позволяет отключать Ajax и WebRTC для определенных доменов, что несомнено лучше чем для всех. Плюс затрудняет идентификацию через другие каналы.

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

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

Вариантов сокрытия своего DNS от сдачи врагам, несколько.

Наиболее простой и безболезненный – это заменить автоматически выданные DNS сервера вашего провайдера на публичные:
Google DNS 8.8.8.8 и 8.8.4.4
OpenDNS 208.67.222.222 и 208.67.222.220

но т.к к примеру Google вместо 8.8.8.8 светит ближаший DNS, то например для рунета будет показываться финский 74.125.46.10 или любой другой из этой же (или 74.125.74.Х) сеток, что может поставить в тупик. Поэтому надежней выбрать какой нить наиболее близкий к нужной стране из

Вдобавок к этому варианту можно закрыть доступ в браузере FF, чтобы он передавал запросы только через прокси (при работе с SOCKS прокси) и поставить запрет на преварительное разрешение доменных имен (например при просмотре страницы с исходящими ссылками), которые также могут пойти в обход прокси
network.proxy.socks_remote_dns = true
network.dns.disablePrefetch = true

Также можно запретить технологию Teredo, созданную для подключения к хостам IPv6 через чистую сеть IPv4. Для этого надо вызвать DOS-PROMT: Win + R -> cmd после чего выполнить в консоли команду
netsh interface teredo set state disabled
если понадобится включить Teredo, то в дос-промте выполняем
netsh interface teredo set state type=default
Либо же просто аппаратными средствами, вроде Proxyfier, перенаправить весь трафик по умолчанию через прокси.

Тут надо заметить, что в VPN сетях OpenVPN выше версии v2.3.9 проблема протечки DNS решена введение нового параметра конфига block-outside-dns

Также можно доставить плагин Modify Headers для корректуры фингеров агента, дабы выдавать то, что нужно конечному сайту, хотя по большому счету – этот раздел ни на что не влияет, кроме как на приступы паранойи у серфера.

Либо же настроить руками в конфиге Mozilla

general.appname.override = Netscape
general.description.override = Mozilla
general.appversion.override = 5.0 (Windows)
general.oscpu.override = Windows NT 6.1
general.platform.override = Win32
general.useragent.override = Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20130730 Firefox/25.0
general.productSub.override = 20100101
general.buildID.override = 20100101
browser.startup.homepage_override.buildID = 20100101

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

Всем привет! Недавно, благодаря одному человеку, наткнулся на сервис 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.