Что значит игнорировать прокси

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

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

Источник

Настройка прокси игнорировать все локальные адреса [дубликаты]

На этот вопрос уже есть ответ:

Я пытаюсь обойти прокси для всех адресов, которые являются адресами локальной сети. Такие как http: // test / и http: // mymachine / и http: // itsmachine /

Есть ли легкий способ сделать это?

4 ответа

Я столкнулся с этой проблемой. в моем случае у меня Ubuntu 14.04, и я нашел решение здесь

Вы можете установить dconf-editor и открыть dconf-editor -> system -> proxy с помощью этого редактора, а затем добавить свои хосты в ignore-hosts на этом окно и все.

Как настройки прокси устанавливаются в среде Ubuntu gnome.

Эти методы не являются полным доказательством и могут нарушить конфигурацию системы. Заставить сеть вести себя нежелательным образом. Делайте это только если вы понимаете, как это влияет на разные части системы.

Здесь вы можете установить некоторые настройки прокси. Но для игнорирования хостов вам нужно будет установить это еще где.

Команда env относится к вышеуказанному файлу, но многие программы и системные утилиты вносят изменения в среду. Более подробную информацию можно найти здесь, прочитайте это, прежде чем вносить изменения. https://help.ubuntu.com/community/EnvironmentVariables

просто измените это на

Нам нужно добавить список ранее установить no_proxy, поэтому мы добавляем его обратно в конец строки. Это применимо только к сеансу терминала, в котором выполняется команда, и не будет применяться к общесистемной системе чтения справочной документации сообщества для внесения постоянных изменений.

Чтобы внести изменения в среду gnome, вы можете использовать gconftool. Прежде чем пытаться внести изменения, прочтите следующее руководство.
http://library.gnome.org/admin/system-admin-guide/stable/gconf-0.html.en

[1120 ] Следующий файл

/ .conf / system / http-proxy /% gconf.xml. Будет изменена следующей командой. Я не уверен, как установить тип списка с помощью gconftool. Мои попытки закончились удалением всех предыдущих настроек.

Я уверен, что это лучший способ сделать это !!
Безопасный способ сделать это. получите текущее содержимое / system / http_proxy / ignore_hosts

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

Источник

Как прокси применяют в информационной безопасности: 6 практических сценариев использования

Прокси-серверы обычно используются в качестве «прокладки» между клиентом и веб-сайтом или онлайн-сервисов. Направление трафика через прокси помогает пользователям скрывать свое реальное местоположение и IP-адрес. При этом, прокси используют и компании (см. обратные прокси) для решения множества задач от повышения уровня информационной безопасности, до выполнения анонимных задач и контроля использования интернета сотрудниками.

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

Сокрытие информации от взломщиков

К примеру, часто такие прокси используют как SSL-шлюз. В таком случае компания может отвечать на внешние HTTP-запросы не боясь раскрыть структуру своей сети. Выступая в качестве медиатора между внешними клиентами и бэкендом внутренней сети, прокси могут скрывать реальной устройство инфраструктуры компании. Без прокси запросы отправлялись бы непосредственно серверам, а те отвечали бы на них – это могло бы дать злоумышленникам информацию об устройстве сети и возможных слабых местах в ее защите.

Еще один тип прокси, полезных для задач безопасности – резидентные прокси. По сути – это адреса выданные пользователям реальным интернет-провайдером из определенного города, области или штата. Обычно эти адреса выдают владельцам жилья, они отмечаются в базах данных региональных интернет-регистров (RIR). При правильном использовании запросы с таких адресов невозможно отличить от обращений реального пользователя.

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

Мы в Infatica предоставляем как раз такой сервис ротируемых резидентных прокси – и многие наши заказчики используют его именно для обеспечения безопасности своей инфраструктуры.

Шифрование и расшифровка трафика

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

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

Это несет целый ряд плюсов. Например, вам не нужно будет устанавливать сертификаты безопасности на бэкенд-серверы. Кроме того, у вас будет лишь одна точка, в которой нужно настраивать SSL/TLS. Кроме того, поскольку серверам внутри сети не нужно производить ресурсоемкие операции расшифровки контента, нагрузка на них ощутимо снижается.

Мониторинг и оптимизация затрат на защиту

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

Кроме того, если все находящиеся за файрволлом серверы сначала отправляют трафик на прокси-сервер на периметре, то защитив его, общий уровень безопасности вырастет (а иначе надо было бы выделять ресурсы на защиту всех серверов).

Контроль доступа

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

Заключение

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

Источник

Проксируем и спасаем

ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте.

В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!

К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».

Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.

Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?

У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера. Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.

В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.

Дальше нужно создать секцию server, вот как она выглядит

Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.

Объявляем корневой локейшин, указываем путь до его хранилища — root /var/www/6pm; затем используем try_files. Это очень важная директива nginx, которая позволяет организовать локальное хранилище для загруженных файлов. Директива сначала проверяет нет ли файла с именем $uri и если не находит его — переходит в именованный локейшин @ static

$uri — переменная nginx, которая содержит путь из HTTP запроса

Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы

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

include ‘6pm.conf’ — логика модуля substitutions.

proxy_cookie_domain — новая функция, которая появилась в nginx версии 1.1.15, без этой директивы приходилось делать так. Больше не нужно ломать голову, прописываете одну строчку и куки просто начинают работать.

proxy_set_header Accept-Encoding «»; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.

proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect — многие сайты используют редиректы для своих нужд, каждый редирект нужно отловить и перехватить здесь, иначе запрос и клиент уйдет за пределы нашего уютного доменчика.

Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:

Меняем коды google analytics:

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

Меняем все прямые ссылки на новые.

Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:

Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.

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

Итак, мы перекинули сайт на новый IP адрес и новый домен. Это было простой задачей. Можно ли запроксировать сайт не в новый домен, а в поддиректорию существующего? Это сделать можно, но возникают сложности. Для начала вспомним какие бывают html ссылки:

1. Абсолютные ссылки вида «www.example.com/some/path»
2. Ссылки относительно корня сайта вида «/some/path»
3. Относительные ссылки вида «some/path»

С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией
С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.

Настоящая сложность возникает с п.2. из-за того что мы должны изменить кучу ссылок вида /. на /subdomain/. . Если сделать это в лоб, то сайт скорее всего полностью перестанет работать, ибо такая замена сломает множество конструкций использующих слеш, что испортит почти все скрипты javascript.

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

Вернемся к нашему пациенту:

Конфигурация сервера претерпела некоторые изменения.

Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.

proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.

rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.

Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.

Посмотрим на логику трансформации:

Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)
Во-вторых, начинаем аккуратно находить и заменять разные типы ссылок относительно корня. Нам попался средней сложности сайт, в котором часть скриптов содержат такие пути.

К сожалению, мне не удалось до конца написать фильтр для случая поддиректории. Я не дошел до преобразования динамических запросов скриптов корзины с покупками, хотя не сомневаюсь что это решаемо. Просто моих знаний в Javascript не достаточно чтобы выполнить необходимую отладку, буду рад советам как запустить корзину покупок, которая сейчас в упомянутом примере не работает.

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

Источник