Проверить себя на анонимность:

 отечественный ресурс

 частная разработка

BrowserLeaks.com — Web Browser Security Checklist for Identity Theft Protection - зарубежный ресурс

На данный момент собрано 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 сервисов, если это можно назвать решением.

12. Утечка через социальные сети (ВКонтакте, одноклассники, мой мир и т.п.)

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

Подробнее можно посмотреть документацию здесь vk.com/dev/openapi. Кнопка «Выход» после каждой сессии в общем то решает вопрос, но лучшая рекомендация — не использовать социальные сети

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 Block

Отключение 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, очень медленный.

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

замечательный ресурс p0f

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

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