Главная идея — определить, скрывается пользователь во время сёрфинга в сети или нет, и по возможности узнать его реальный 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 сливает частные данные, которые подрывают на корню всё анонимность серфинга.
Подробнее можно посмотреть документацию здесь vk.com/dev/openapi. Кнопка «Выход» после каждой сессии в общем то решает вопрос, но лучшая рекомендация — не входить :)
Спасибо за внимание!
Комментарии (37)
la0
26.07.2015 16:42+1Кстати гуглоDNS вроде как как-то обозначают клиента через расширения eDNS. Особо глубоко не копал, но если кто-то копал, прокомментируйте пожалуйста.
AEP
26.07.2015 17:13+6Есть еще пример спорного срабатывания.
Пользователь купил SIM-карту DataSIM от LeFrenchMobile и поехал с ней в Финляндию (что не является надуманным примером — роуминг дешевый по всей Европе). Итог: IP определяется как французский, NAT делается во Франции, ping отличается (из-за сотового соединения), временная зона отличается на один час. Т.е. два пункта, по которым можно сделать вывод о наличии средств анонимизации, есть.
Но вопрос, является ли SIM-ка в роуминге средством анонимизации, для меня не является однозначным. Но это точно не VPN и не прокси.
inkvizitor68sl
26.07.2015 18:16Определение web proxy (JS метод) — обнаружен 2ip.ru
И красный палец вниз.
Это к чему)?
(никаких web-proxy нет, конечно).
alexkuzko
26.07.2015 18:55Интересно что если не включать Flash, то нет утечки адреса через него, но проверка на двухсторонний ping проваливается.
А если включить Flash, то реальный адрес утекает (вот же какая засада!), зато проверка на двухсторонний ping проходит — зеленая.
Это фишка или баг?
madflux Автор
26.07.2015 19:25Случайность скорее всего. Двусторонний пинг это рулетка, сейчас нашел, следующий раз по другому маршруту уже нет. Воспроизвести такое поведение не удалось, на тестовой машине «палит» и flash и ping одновременно.
sergiks
26.07.2015 23:12-1ВКонтакт без явного действия пользователя не позволит идентифицировать оного: нужно либо нажать кнопку в виджете, либо когда-то раньше уже установвить ВК-приложение злодеев (дать ему разрешение на идентификацию себя). Есть пока еще несколько сервисов социального фишинга, но они эксплуатируют уязвимости браузеров, закрытые в свежих версиях.
u_story
26.07.2015 23:16+1Интересно, а можно как-нибудь спалить работу через чужой терминальный сервер?
toper
27.07.2015 06:04VPN через домашний роутер и корпоративный прокси не спалил, а флеш конечно зло ((
kacang
27.07.2015 06:26При переключении на VPN нужно не забывать переводить системное время, менять время в браузере, либо работать с русскими прокси.
Дружья, подскажите как поменять время в лисе, и только в лисе, нo не во всей системе? Мой гугл-фу слабый, т.к. сам найти не смог
dbanet
27.07.2015 07:25+1set/export TZ=...
firefox
?
Вообще, удивлён, что нет такого расширения.
burjui
27.07.2015 12:43Можно записать ещё короче, при этом зона установится только для запускаемого процесса, а не для сессии шелла:
$ TZ='GST-10' firefoxdbanet
27.07.2015 16:21Я выразил идею.
В конкретном случае, на конкретной платформе, с конкретным командным интерпретатором, графической оболочкой, сборкой лисы и т. д. можно вообще много чего.
Хочу верить, что на хабре все в состоянии локально сменить переменную окружения наиболее удобным и подходящим для их платформы и ситуации способом.burjui
27.07.2015 23:39-1Извините, что отвлёк своим бесполезным советом Вас и всех хабравчан от подготовки к экзамену по bash.
piva
27.07.2015 14:30+1Статьи по этой тематике интересны, но есть вопрос.
Нет ли возможности такую функцию проверки анонимности прицепить на веб-сервер или форум написанный на php?
HoverHell
29.07.2015 12:42Единственный способ защититься — запретить ICMP трафик к своему VPN серверу.
А также ICMP исходящий и все исходящие connection refused и пользоваться только скрытыми/прикрытыми udp-сервисами (которые без верного пакета аутентификации не отвечают)? Зело сложное дело.
С другой стороны в тут может быть куча false positives из-за мобильных пользователей.HoverHell
30.07.2015 09:01А ещё, даже если VPN-сервер не отвечает ни на что, можно достаточно точно прикинуть расстояние до него traceroute'ом, т.к. предпоследний hop обычно недалеко от последнего.
Так что способ, хотя и слишком сложный для online-использования, не предполагает возможности принципиально защититься.
AEP
Как я понимаю, проверка с ping работает, только если есть NAT на стороне VPN-провайдера.
madflux Автор
VPN сервер должен уметь откликаться на пинг, а что это: роутер, точка доступа или машина пользователя, уже не так важно. Ведь дальше маршрут идёт как правило не очень далеко, и на конечный результат не сильно влияет.
AEP
Еще как влияет.
Рассматриваем для определенности случай, когда пользователь в России, VPN-провайдер в Финляндии, а проверялка в Швеции.
Случай 1: провайдер NAT'ит. Те выдает клиенту «серый» адрес. В этом случае пинги от проверялки до видимого внешнего адреса пользователя идут из Швеции в Финляндию, т.е. близко, а запрос пустой страницы от пользователя идет из России через Финляндию в Швецию, т.е. далеко. Проверка срабатывает.
Случай 2: провайдер дает клиенту белый IP. В этом случае пинги от проверялки до этого IP идут пользователю — т.е. из Швеции через Финляндию на «финский» IP в Россию. Запрос пустой страницы идет, как и раньше, из России через Финляндию в Швецию, т.е. точно так же далеко. Проверялка утверждает, что VPN по критерию с пингом обнаружить не удалось.
madflux Автор
Все верно, в таком случае мы ничего не найдем.
anatolikus
Извиняюсь, что не по теме.
Ваш сервис, кроме прочего, проверяет актуальность версии браузера. Мне для написания расширения необходимо оперативно получать номер последней версии Google Chrome. Не могли бы вы подсказать, где можно его брать? Пока я нашел выход — парсить страничку googlechromereleases.blogspot.com/search/label/Stable%20updates. Всего пара строк, но не хватает изящества.
Буду благодарен за подсказку.
kacang
A как работает выдавание белого IP? С натом все понятно, у самого так настроено. Не могу представить как будет выглядеть vpn подсеть когда адреса наружние.
AEP
Выглядит все так.
У организации есть большая подсеть белых адресов (скажем, 192.0.2.0/24) для раздачи клиентам. Еще нужен один белый адрес (скажем, 198.51.100.2) из другой подсети.
Вешаем на сервер на eth0 адрес 198.51.100.2. На вышестоящем маршрутизаторе прописываем маршрут до 192.0.2.0/24 через 198.51.100.2, и распространяем его (через BGP) по всему интернету. Или это сделает за нас вышестоящий провайдер.
На сервере делаем --dev tun --topology subnet. На tap0 при этом OpenVPN повесит адрес 192.0.2.1/24 и будет выдавать IP из этой подсети клиентам.
Клиентам говорим, чтобы подсоединялись к 198.51.100.2.
Все!
kacang
Спасибо за хорошее объяснение! А можно сделать так же, но для белых адресов использовать ipv6?
AEP
Да, если есть IPv6-подсеть для клиентов и не входящий в нее IPv6-адрес.
kacang
Я имел в виду смешанную конструкцию: клиенты заходять на публичный ipv4 а выходят в ipv6. Обусловенно это тем что на VPS-ках обычно есть один ipv4 и ipv6/64.
AEP
Т.е. второй подсети IPv6 нет? Она вообще-то нужна, чтобы через адрес из нее проходил маршрут к подсети для клиентов. В примере выше про IPv4 использование этого адреса еще и как для входящих соединений VPN-сервера — это совпадение.
Без нее можно выкрутиться, но будет очень костыльно. Гуглить в сторону odhcpd из OpenWRT.
ValdikSS
Есть два пути решения проблемы:
1) Выделять клиентам подсеть меньше выданной /64. Отлично работает с tun (когда сам адрес не получает ОС, а настраивается через OpenVPN, например). Я выдаю адреса из /96. Конфликта маршрутов в этом случае нет.
2) Использовать NDP Proxy. Либо писать свои up-down скрипты, либо использовать ndppd.
cc: kacang
AEP
odhcpd порекомендован именно как альтернатива ndppd
ValdikSS
С ним тоже получится, да.
kacang
Метод номер 1 выглядит как то что надо! Буду пробовать. Спасибо ValdikSS и AEP!