Анонимная анонимность: борьба с утечками IP в браузерах, ОС, VPN
Привет коллеги
! Давненько не писал! А давайте поговорим о мифической анонимности в сети. За последние несколько лет, мне на глаза попадалось несколько сценариев деанонимизации пользователя и я брал их себе на вооружение. Эти сценарии и опишу в текущей заметке. Мы рассмотрим случаи утечки реального IP и трафика при работе через VPN, соксы, прокси сервера и то, как можно от этого защититься. А вообще я любитель Tails'а и TOR'а .
Утечка VPN трафика и IP при обрыве соединения.
Одна из главных проблем в работе с частными виртуальными сетями – это утечка трафика. По-другому говоря, тот трафик, который должен был быть передан через VPN соединение в анонимном виде, попадает в открытый доступ. Данный сценарий не следствие проблем с клиентом или сервером. На самом деле всё гораздо интереснее. Самый банальный вариант – это обрыв VPN-соединения. К примеру, решил прочекать лист SSH или FTP акков, запустил сканер, отошёл по своим делам на несколько минут, приходишь, а соединение внезапно разорвано. Но чекер/сканер при этом продолжает функционировать, и работа идёт уже с твоего реального адреса.
Что делать в этом случае?
Чтобы избежать утечки трафика и реального IP, сохранив свою анонимность, в ситуациях, когда VPN-соединение внезапно разорвалось, попробуйте:
1. Заставить весь трафик идти через VPN, удалив default gateway, т.к. при падении впн весь компрометирующий нас трафик пойдет именно через него:
route delete 0.0.0.0 192.168.1.1 // удаляем default gateway
route add 83.170.76.128 mask 255.255.255.255 192.168.1.1 metric 1
2. Воспользоваться утилитой VPNetMon http://vpnetmon.webs.com, которая поможет отследить состояние впн соединения и как только оно пропадёт, мгновенно, завершить указанные пользователем программы, например, веб-браузеры, ssh- e-mail- ftp- чекеры, виртуалки, торрент-клиенты.
3. Также можно воспользоваться утилитой VPNCheck http://www.guavi.com/vpncheck_free.html, которая в зависимости от настроек может полностью отключить сетевую карту, обрезав всю связь с внешним миром) или завершить нужные процессы.
Утечка 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 https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=rtadvd, SI6 Networks’ IPv6 Toolkit https://www.si6networks.com/research/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-трафика.
Утечка трафика в браузере через WebRTC.
Все дело заключается в том, что все современные браузеры содержат вредоносную технологию WebRTC. И она по умолчанию уже включена. Что это такое?
WebRTC https://ru.wikipedia.org/wiki/WebRTC – это проект с открытым кодом, предназначающийся для отправки данных потоком между браузерами или иными приложениями разработанных по технологии точка-точка. WebRTC внедрен в Google Chrome с 17, Opera с 12 и Firefox с 18 версиях.
Опасность кроется в том, что в случае использования данного протокола виден ваш настоящий IP адрес, несмотря на то, что вы используете VPN, TOR, socks, proxy.
Справочка! WebRTC НЕ представляет большой угрозы для тех кто за NATом, роутером сидит, т.е. для большинства, но внутренний IP засветится в любом случае.
Как провериться и излечиться?
Проверяемся здесь:
https://www.browserleaks.com/webrtc
или здесь https://diafygi.github.io/webrtc-ips/.
- если вы сейчас используете VPN соединение и у Вас включён WebRTC, отобразиться два IP адреса, первый IP – вашего VPN, второй – сетевой карты. Если отключен WebRTC, то будет отображаться только один IP.
Далее защищаемся.
В браузере Firefox вводите About: config, находите параметр media.peerconnection.enabled и выставляете значение FALSE.
Для Google Chrome скачиваем расширение WebRTC Block и дополняете его плагином WebRTC Control.
Для Android Google Chrome в адресную строку кидаем “chrome://flags/#disable-webrtc” и жмем "Отключение WebRTC Android"
После проведения всех работ, проверяем качество устранения проблемы на сайте http://whoer.net/extended
А ещё удаляем с корнями Flash и Java!
В случае с этими технологиями нора ещё более глубока, нежели в предыдущих примерах, разбираться не будем, а просто выкорчёвываем эти сорняки с корнем ради себя любимых! Проверить утечку данных через Flash можно через сайт https://2ip.ru/privacy/ и аналогичный сервис http://ip-check.info/.
Итожим господа.
Так уж сложилось, что при упоминании VPN, Socks, TOR сразу же возникает мысль о безопасности и анонимности данных. Пользователи применяют VPN в случаях, когда хотят скрыть свое реальное местоположение или скрыть свой трафик от «глаз» провайдера. Но на деле получается, что передаваемый трафик довольно легко распознать, а иногда он передается вообще в открытую, по невнимательности самого пользователя. Так что не стоит расслабляться, следите за безопасностью и анонимностью своих соединений, контролируйте свою “анонимность”.
И спасибо, если дочитали эту писанину!
Привет коллеги
! Давненько не писал! А давайте поговорим о мифической анонимности в сети. За последние несколько лет, мне на глаза попадалось несколько сценариев деанонимизации пользователя и я брал их себе на вооружение. Эти сценарии и опишу в текущей заметке. Мы рассмотрим случаи утечки реального IP и трафика при работе через VPN, соксы, прокси сервера и то, как можно от этого защититься. А вообще я любитель Tails'а и TOR'а .Утечка VPN трафика и IP при обрыве соединения.
Одна из главных проблем в работе с частными виртуальными сетями – это утечка трафика. По-другому говоря, тот трафик, который должен был быть передан через VPN соединение в анонимном виде, попадает в открытый доступ. Данный сценарий не следствие проблем с клиентом или сервером. На самом деле всё гораздо интереснее. Самый банальный вариант – это обрыв VPN-соединения. К примеру, решил прочекать лист SSH или FTP акков, запустил сканер, отошёл по своим делам на несколько минут, приходишь, а соединение внезапно разорвано. Но чекер/сканер при этом продолжает функционировать, и работа идёт уже с твоего реального адреса.
Что делать в этом случае?
Чтобы избежать утечки трафика и реального IP, сохранив свою анонимность, в ситуациях, когда VPN-соединение внезапно разорвалось, попробуйте:
1. Заставить весь трафик идти через VPN, удалив default gateway, т.к. при падении впн весь компрометирующий нас трафик пойдет именно через него:
route delete 0.0.0.0 192.168.1.1 // удаляем default gateway
route add 83.170.76.128 mask 255.255.255.255 192.168.1.1 metric 1
2. Воспользоваться утилитой VPNetMon http://vpnetmon.webs.com, которая поможет отследить состояние впн соединения и как только оно пропадёт, мгновенно, завершить указанные пользователем программы, например, веб-браузеры, ssh- e-mail- ftp- чекеры, виртуалки, торрент-клиенты.
3. Также можно воспользоваться утилитой VPNCheck http://www.guavi.com/vpncheck_free.html, которая в зависимости от настроек может полностью отключить сетевую карту, обрезав всю связь с внешним миром) или завершить нужные процессы.
Утечка 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 https://www.gsp.com/cgi-bin/man.cgi?section=8&topic=rtadvd, SI6 Networks’ IPv6 Toolkit https://www.si6networks.com/research/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-трафика.
Утечка трафика в браузере через WebRTC.
Все дело заключается в том, что все современные браузеры содержат вредоносную технологию WebRTC. И она по умолчанию уже включена. Что это такое?
WebRTC https://ru.wikipedia.org/wiki/WebRTC – это проект с открытым кодом, предназначающийся для отправки данных потоком между браузерами или иными приложениями разработанных по технологии точка-точка. WebRTC внедрен в Google Chrome с 17, Opera с 12 и Firefox с 18 версиях.
Опасность кроется в том, что в случае использования данного протокола виден ваш настоящий IP адрес, несмотря на то, что вы используете VPN, TOR, socks, proxy.
Справочка! WebRTC НЕ представляет большой угрозы для тех кто за NATом, роутером сидит, т.е. для большинства, но внутренний IP засветится в любом случае.
Как провериться и излечиться?
Проверяемся здесь:
https://www.browserleaks.com/webrtc
или здесь https://diafygi.github.io/webrtc-ips/.
- если вы сейчас используете VPN соединение и у Вас включён WebRTC, отобразиться два IP адреса, первый IP – вашего VPN, второй – сетевой карты. Если отключен WebRTC, то будет отображаться только один IP.
Далее защищаемся.
В браузере Firefox вводите About: config, находите параметр media.peerconnection.enabled и выставляете значение FALSE.
Для Google Chrome скачиваем расширение WebRTC Block и дополняете его плагином WebRTC Control.
Для Android Google Chrome в адресную строку кидаем “chrome://flags/#disable-webrtc” и жмем "Отключение WebRTC Android"
После проведения всех работ, проверяем качество устранения проблемы на сайте http://whoer.net/extended
А ещё удаляем с корнями Flash и Java!
В случае с этими технологиями нора ещё более глубока, нежели в предыдущих примерах, разбираться не будем, а просто выкорчёвываем эти сорняки с корнем ради себя любимых! Проверить утечку данных через Flash можно через сайт https://2ip.ru/privacy/ и аналогичный сервис http://ip-check.info/.
Итожим господа.
Так уж сложилось, что при упоминании VPN, Socks, TOR сразу же возникает мысль о безопасности и анонимности данных. Пользователи применяют VPN в случаях, когда хотят скрыть свое реальное местоположение или скрыть свой трафик от «глаз» провайдера. Но на деле получается, что передаваемый трафик довольно легко распознать, а иногда он передается вообще в открытую, по невнимательности самого пользователя. Так что не стоит расслабляться, следите за безопасностью и анонимностью своих соединений, контролируйте свою “анонимность”.
И спасибо, если дочитали эту писанину!
