Определение туннеля двусторонний пинг обнаружен windows

Вы пытаетесь максимально замаскировать свой VPN или proxy? Тогда вам наверняка необходимо убрать определение туннеля (двусторонний пинг).
Перейдём к ознакомлению:
В гайде повествуется об отключении определения туннеля на OC Linux и Windows.

Запускаем ssh, переходим на сервер и логинимся под root пользователем

Переходим к редактированию настроек ufw c помощью nano: nano /etc/ufw/before.rules

Добавляем новую строку и сохраняем результат:

# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type source-quench -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

4. Перезапускаем фаервол ufw

ufw disable && ufw enable

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

Изменено 24 декабря, 2022 пользователем TrustMeBro

Скорректированы правила для таблицы. Теперь точно работает. Проверено на Ubuntu 22.04

Отключение двухстороннего пинга

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

В этой краткой, но полезной заметке, я расскажу, как отключить ответ на ICMP пинг на Linux и Windows.

Что такое двухсторонний пинг?

Двусторонний пинг позволяет определить, что сервер находится в сети, отправляя ICMP-запросы и получая ответы. Отключив ответы на ICMP, вы можете скрыть туннель и сделать ваш VPN или proxy менее заметным.

Шаги для отключения двухстороннего пинга на Linux

1. Подключение к серверу

Подключитесь к вашему серверу через ssh и войдите под пользователем root:

ssh root@your-server-ip

2. Редактирование настроек фаервола UFW

Для начала нужно отредактировать правила фаервола ufw. Откройте файл конфигурации before.rules с помощью редактора nano:

nano /etc/ufw/before.rules

3. Добавление правил блокировки ICMP

Добавьте следующие строки в файл, чтобы блокировать различные типы ICMP-запросов:

# Disable ICMP ping responses
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type source-quench -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

Эти правила отключат различные типы ICMP-запросов, включая echo-request, который используется для стандартных ping-запросов.

4. Перезапуск UFW

После внесения изменений перезапустите фаервол UFW, чтобы правила вступили в силу:

ufw disable && ufw enable

5. Проверка

Теперь ваш сервер не должен отправлять ICMP-ответы, что делает его менее заметным для тех, кто пытается “пропинговать” ваш туннель.

Можно зайти на сайт 2ip.io и проверить уровень анонимности.

Важные замечания

• Ограничения: Отключение ICMP-пинга может затруднить диагностику проблем с сетью, так как ping-запросы используются для проверки доступности сервера.
• Альтернатива: Если полное отключение ICMP не подходит, можно рассмотреть частичное ограничение, блокируя только определённые типы ICMP-запросов.

Заключение

Отключение двустороннего пинга — это простой и эффективный способ повысить анонимность вашего сервера, туннеля VPN или proxy. Однако будьте внимательны при изменении настроек сети, так как это может повлиять на доступность сервера для мониторинга и диагностики.

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

Вот более подробное обновление к статье, с объяснением и инструкциями по разрешению ICMP echo-request только для конкретного IP-адреса, и дополнительные рекомендации для работы с Uptime Kuma:

Обновление: Разрешение ICMP echo-request для конкретного IP

Недавно ко мне обратились с ситуацией, когда на сервере, где пинг был отключен для повышения анонимности, также работал мониторинг через Uptime Kuma. Конечно, для мониторинга нужен доступ через ICMP, но разрешить пинг для всех было не лучшим вариантом. Вот как я решил проблему, разрешив ICMP echo-request только для конкретного IP.

1. Разрешение ICMP echo-request от IP Uptime Kuma

Сначала я открыл доступ для ICMP-запросов от определённого IP-адреса, с которого приходит мониторинг. Например, если IP Uptime Kuma – 1.2.3.4:

sudo iptables -A INPUT -p icmp --icmp-type echo-request -s 1.2.3.4 -j ACCEPT

2. Блокировка всех остальных ICMP-запросов

Для защиты сервера я также заблокировал все остальные ICMP-запросы от других IP:

sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

3. Дополнительные ICMP для мониторинга

Некоторые системы мониторинга, такие как Uptime Kuma, могут использовать другие типы ICMP-запросов для диагностики, поэтому я разрешил еще пару важных типов запросов:

# Разрешить Destination Unreachable от конкретного IP
sudo iptables -A INPUT -p icmp --icmp-type destination-unreachable -s 1.2.3.4 -j ACCEPT

# Разрешить Time Exceeded от конкретного IP
sudo iptables -A INPUT -p icmp --icmp-type time-exceeded -s 1.2.3.4 -j ACCEPT

Это помогло сохранить функциональность мониторинга, не открывая ICMP для всего интернета.

4. Сохранение настроек iptables

После настройки я сохранил правила iptables, чтобы они применялись после перезагрузки:

sudo iptables-save | sudo tee /etc/iptables/rules.v4

Теперь мониторинг от Uptime Kuma работает, а сервер остается защищённым от нежелательных ICMP-запросов.

Определение туннеля двусторонний пинг обнаружен как исправить? – Памятка по настройке компьютерной техники

Если вы читаете эту статью, значит у вас есть желание добиться 100% анонимности в сети. Нас часто спрашивают, как добиться заветных Ваша анонимность: 100% на [whoer.net](https://whoer.net/). Покажем на примере, что нужно делать, чтобы обеспечить 100% анонимность в сети…

Повышаем анонимность за прокси: скрытие ip адреса от утечки

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

В последнее время неоднократно приходится сталкиваться с вопросами людей, как им повысить анонимность, чтобы конечный сайт, к которому обращается клиент через прокси или 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 провайдера, точно также отвечают на пинг.

Далее я буду говорить только о Firefox, ибо с Chrome не работаю и не имею ни малейшего желания разбираться как он работает, ибо достаточно того, что он сливает все данные гуглю.

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

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

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

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

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

Все это и много другое, можно также отрубить с помощью отдельного плагина Firefox Privacy Settings. И/Или можно поставить 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.Х) сеток, что может поставить в тупик. Поэтому надежней выбрать какой нить наиболее близкий к нужной стране из 134к публичных DNS по всему миру

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

Тут надо заметить, что в 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

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

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

Rating: 4.6/10 (76 votes cast)

Источник

Чек-лист проверки анонимности сёрфинга

Несколько дней назад на хабре проскочила заметка об определении пользователей 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

Отдается веб страничка? Отлично! На данный момент мы умеем определять 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 сливает частные данные, которые подрывают на корню всё анонимность серфинга.

Источник

Определение туннеля двусторонний пинг обнаружен как исправить? – Памятка по настройке компьютерной техники

Если вы читаете эту статью, значит у вас есть желание добиться 100% анонимности в сети. Нас часто спрашивают, как добиться заветных Ваша анонимность: 100% на [whoer.net](https://whoer.net/). Покажем на примере, что нужно делать, чтобы обеспечить 100% анонимность в сети…

Повышаем анонимность за прокси: скрытие ip адреса от утечки

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

В последнее время неоднократно приходится сталкиваться с вопросами людей, как им повысить анонимность, чтобы конечный сайт, к которому обращается клиент через прокси или 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 провайдера, точно также отвечают на пинг.

Далее я буду говорить только о Firefox, ибо с Chrome не работаю и не имею ни малейшего желания разбираться как он работает, ибо достаточно того, что он сливает все данные гуглю.

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

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

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

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

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

Все это и много другое, можно также отрубить с помощью отдельного плагина Firefox Privacy Settings. И/Или можно поставить 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.Х) сеток, что может поставить в тупик. Поэтому надежней выбрать какой нить наиболее близкий к нужной стране из 134к публичных DNS по всему миру

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

Тут надо заметить, что в 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

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

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

Rating: 4.6/10 (76 votes cast)

Источник

Как убрать определение туннеля (двусторонний пинг) в VPN?

Вы пытаетесь максимально замаскировать свой VPN или прокси? Тогда вам наверняка необходимо убрать «Определение туннеля (двусторонний пинг)».

ICMP, Internet Control Message Protocol — доступно говоря, позволяет выполнить ping, на доступность сервера. Если вы за анонимность, то необходимо запретить ICMP трафик к своему VPN серверу или «определение туннеля (двусторонний пинг)».

Как запретить ICMP трафик?

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

Debian/Ubuntu:

4. Перезапускаем фаервол ufw
ufw disable && ufw enable
5. Сервер больше не должен отправлять ICMP трафик, а значит вам удалось скрыть двусторонний пинг!

Самый простой способ блокировать команду ping в системах Linux — это добавить правило в iptables, как будет показано в приведенном ниже примере. Iptables является частью ядра Linux netfilter и, как правило, устанавливается по умолчанию в большинстве Linux-сред.

Другим общепринятым методом блокировки ICMP-сообщений в системе Linux является добавление ниже приведенной переменной ядра, которая «выведет из строя» все пакеты ping.

Чтобы сделать это правило постоянным, добавьте следующую строку в файл /etc/sysctl.conf и затем примените правило с помощью команды sysctl.

В дистрибутиве CentOS или Red Hat Enterprise Linux, использующем интерфейс Firewalld для управления правилами iptables, добавьте нижеприведенное правило для удаления сообщений ping.

—remove-icmp-block удалит разрешение, а так как по умолчанию все запрещено то пинга не будет.
Если у вас по умолчанию все разрешено всем, тогда нужно ставить правило —add-icmp-block.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник