что такое http proxy в marketapp
Что такое Proxy и где найти бесплатный — рассказываем простым языком
Proxy (прокси) — переводится как «представитель» или «доверенное лицо». Поэтому прокси-сервер или прокси-узел – это промежуточный сервер в Сети, который выполняет посреднические функции между пользователем и серверами, которые являются для него целевыми.
Для более доступного понимания функций прокси, я приведу такую аналогию: для того чтобы попасть, например, в операционную врачи проходят специальные процедуры по дезинфекции. Причем, проходят они эти процедуры как до, так и после операции. Так вот прокси-узел выполняет такие же самые дезинфицирующие функции в Сети, когда все исходящие от пользователя и входящие сетевые запросы не напрямую передаются, а осуществляются с помощью «посредника».
Рис. 1. Схема работы прокси
При этом «посредник» может менять все данные, которые могут быть определены по адресу IP, что имеет пользователь. А это как страна, где он находится, так и регион, а также другие его данные. Поэтому прокси-сервер может поменять IP на другой адрес, который выбирает сам пользователь.
Нужен ли прокси для простого пользователя?
Несмотря на то, что появление прокси было связано с потребностью в «посредниках» для профессиональных или для серьезных пользователей Сети, представителям массовой интернет аудитории этот сервис также может быть интересным и полезным:
Какие бывают прокси?
В отличие от схемы на Рис.1. теперь прокси-узлы не являются физическим оборудованием, а служат предоставляемой услугой. Иначе говоря, пользователь имеет возможность зайти на специальные ресурсы и выбрать как бесплатный (открытый), так и купить (закрытый) подходящий вариант сервиса прокси. Причем, открытые или бесплатные прокси, как правило, не могут гарантировать достаточной степени защищенности, да и скоростные характеристики у них желают лучшего из-за массового наплыва пользователей.
Что касается закрытых и соответственно платных прокси услуг, то они обладают и надежной защитой, и надлежащей быстротой. Помимо этого, они имеют дополнительные опции по уровню анонимности и могут быть, как прозрачными и анонимными, так и элитными, а также они могут быть персональными и коллективными. При этом они могут быть целевыми, как по странам, так и по социальным сетям, а также для парсинга поисковиков, для игровых ресурсов и для других целевых направлений.
Именно таким ресурсом сервиса является Proxy-Sale.Com, который я рекомендую, как для обычных пользователей сети, так и для профессионалов, как для покупки персональных, так для выбора бесплатных прокси.
Помимо этого, proxy sale предоставляет индивидуальные прокси, которые имеют в своем активе высокоскоростную и стабильную работу, круглосуточную техподдержку, а также есть возможность аренды адресов IP крупнейших мировых провайдеров.
Защищённые прокси — практичная альтернатива VPN
В интернете есть достаточное количество информации по теме шифрования и защиты трафика от вмешательств, однако сложился некоторый перекос в сторону различных VPN-технологий. Возможно, отчасти он вызван статьями VPN-сервисов, которые так или иначе утверждают о строгом превосходстве VPN-решений перед прокси. При этом многие решения тех же VPN-провайдеров, не смотря на маркетинговое позиционирование в качестве VPN, технически являются прокси.
На практике прокси больше подходят для повседневной защиты веб-трафика, не создавая при этом неудобств в виде заметной потери скорости и неизбирательности туннелирования. То есть при использовании хорошего прокси не стоит необходимость его отключать для комфортного пользования интернетом.
В этой статье расказано о преимуществах защищённого прокси перед VPN и предложены различные реализации, готовые к использованию.
В чём различие между VPN и прокси?
VPN — это общее название технологий для объединения внутренних сетей на уровне сетевых пакетов или кадров через соединение, установленное поверх другой сети (чаще всего публичной).
Прокси — это серверное приложение, осуществляющее соединения или запросы от своего имени и сетевого адреса в пользу подключившегося к нему клиента, пересылая в результате ему все полученные данные.
VPN осуществляет пересылку полезной нагрузки, находящейся на третьем или втором уровне сетевой модели OSI. Прокси осуществляют пересылку полезной нагрузки между четвёртым и седьмым уровнями сетевой модели OSI включительно.
И VPN, и прокси могут иметь или не иметь шифрования между клиентом и сервером. Обе технологии пригодны для того, чтобы направить трафик пользователя через доверенный сервер, применяя шифрование по пути до него. Однако, подключение через прокси делает это более прямолинейным способом, не привнося дополнительную инкапсуляцию сетевых пакетов, серые адреса самой VPN сети и изменения таблицы маршрутизации, которые привносит VPN просто лишь для того, чтобы сетевой стек системы пользователя направил трафик через нужный сервер.
Преимущества прокси
Требования к прокси
Выбирая для себя реализацию защищённого прокси-сервера, я отметил несколько критериев, которым она должна удовлетворять:
Особенности obfs4
В спецификации протокола obfs4 есть места, которые вызывают вопросы. В рукопожатии со стороны клиента используется номер часа от начала эпохи UNIX, который потом участвует в HMAC-подписи. Сервер, принимая такой пакет от клиента проверяет его, подставляя номер часа по своему времени. Если всё верно, то отвечает своей частью рукопожатия. Для борьбы с разбросом часов сервер должен ещё проверять предыдущий и следующий час.
Зная такое характерное поведение, можно проверить сервер на границе следующего и послеследующего часа, воспроизведя одно из прошлых записанных рукопожатий со стороны клиента. Если сервер перестанет отвечать своей частью рукопожатия в это самое время, то это достаточное основание, чтобы судить, что сервер обслуживает протокол obfs4.
Судя по всему, автор со временем осознал эту проблему и в коде obfs4 реализована защита от обнаружения через воспроизведение. В спецификации она нигде не описана.
Однако, такая защита наоборот упрощает работу по блокировке протокола: сетевому фильтру достаточно в случае сомнений задержать отправку рукопожатия от клиента, перехватив её, а затем отправить сообщение с рукопожатием первым. Таким образом он спровоцирует защиту от воспроизведения уже против клиента, вынуждая сам сервер блокировать клиента.
Следующий момент, вызывающий сомнения это формат «кадра» с данными. Выглядит он следующий образом:
Первые два байта каждого кадра это длина пакета, гаммированная с ключом, который вычисляется от предыдущих ключей. Как он вычисляется ключ не столь важно, главное, что настоящая длина пакета подвергается операции побитового исключающего ИЛИ каким-то ключом. Это значит, что можно инвертировать бит в этой части данных и подмена не будет сразу замечена. Если инвертировать младший значащий бит этого поля, то длина кадра станет либо на единицу меньше истинной, либо на единицу больше. В первом случае это приведёт к сбросу соединения через небольшое случайное время из-за ошибки распаковки NaCl secretbox.
Второй случай более интересный: сервер будет ждать ещё один байт для того, чтобы начать распаковку криптобокса. Получив ещё ровно один байт он также сбросит соединение из-за ошибки распаковки криптобокса. Это поведение можно считать специфичным для obfs4 и можно судить, что мы с высокой вероятностью имеем дело с ним. Таким образом, удачно разрушив одно из соединений клиента, можно с примерно 50%-ным шансом обнаружить obfs4.
Конечно, определение границ одного кадра в потоке тоже может представлять непростую задачу, но нет чётких гарантий, что нерешаемую. В случае обмена короткими сообщениями границы одного кадра могут совпасть с границами TCP-сегмента.
Ну и последняя особенность заключается в том, что сам по себе протокол внешне не похож ни на один из общепринятых. Он спроектирован с предположением, что DPI играет по правилам и незнакомые протоколы просто не трогает. Суровая реальность может показать, что это не так.
По всем этим соображениям я воздержался от использования obfs4.
TLS и SSH в качестве криптографического транспорта
Разумно было бы воспользоваться стандартными защищёнными сетевыми протоколами вроде TLS или SSH для обёртывания соединений с прокси. Действительно, к таким протоколам обычно не возникает претензий со стороны DPI, потому что ими может быть зашифрован легетимный трафик. Что же касается активных проб со стороны DPI, этот вопрос можно решить в частном порядке, в зависимости от конкретного протокола прокси.
Ниже будут представлены несколько готовых решений на базе этих протоколов, пригодных для повседневной постоянной защиты трафика.
SOCKS5 внутри SSH
Вариант с использованием функции dynamic port forwarding у OpenSSH рассматривался выше, но он имеет большие проблемы со скоростью. Единственный способ избавиться от мультиплексирования соединений — это использовать альтернативную реализацию клиента SSH, который обеспечивал бы каждое проксируемое соединение отдельной SSH-сессией.
Я проделал такую работу и реализовал его: Rapid SSH Proxy. Эта реализация обеспечивает каждое проксируемое соединение отдельной SSH-сессией, поддерживая пул подготовленных SSH-сессий для удовлетворения поступающих запросов подключения с минимальной задержкой.
Следует особо отметить ключевую особенность: никакого стороннего ПО не нужно устанавливать на сервер — rsp работает как ssh-клиент с обычным сервером OpenSSH. Сервером может быть любая unix-подобная операционная система, а так же Windows и Windows Server (в новых версиях OpenSSH теперь доступен в компонентах системы).
Приведу сравнение скорости через сервер в США:
SOCKS5 внутри TLS
В случае с TLS очевидным решением было бы использовать stunnel или аналогичную TLS-обёртку для TCP-соединений с SOCKS5-сервером. Это действительно вполне хорошо работает, но возникает следующая проблема: рукопожатие TLS для каждого нового соединения занимает дополнительное время и появляется заметная на глаз задержка при установлении новых соединений из браузера. Это несколько ухудшает комфорт при веб-серфинге.
Для того, чтобы скрыть эту задержку, я подготовил специализированную замену stunnel на клиенте, которая поддерживает пул уже установленных, готовых к запросу TLS-соединений. Даже целых два — первый из них послужил прототипом:
HTTP-прокси внутри TLS aka HTTPS-прокси
Есть небольшая путаница в отношении сочетания слов «HTTPS» и «прокси». Есть два понимания такого словосочетания:
Примечательно, что ни в одном браузере нет простой возможности задать в настройках HTTPS-прокси через пользовательский интерфейс (то поле HTTPS-прокси, которое там есть, как раз относится к первому случаю). Но это не представляет собой большой трудности.
Поперебирав различные готовые варианты, я решил написать свой HTTP(S) прокси-сервер: dumbproxy.
Ключевой особенностью получившегося решения является то, что современные браузеры (Firefox и семейство Chrome, включая новый MS Edge) могут работать с ним без какого-либо дополнительного ПО на клиенте (см. руководство по настройке клиентов).
Следует отметить особенности реализации в отношении противодействия активным пробам со стороны DPI. HTTP-прокси легко распознать, подключившись к нему и осуществив попытку какого-либо запроса стороннего ресурса. Если прокси имеет авторизацию, то по стандарту он должен отвергнуть запрос с кодом 407, специфичным именно для HTTP-прокси, и предложить возможную схему для авторизации. Если прокси работает без авторизации, то он выполнит запрос, чем так же себя выдаст. Есть как минимум два способа решения этой проблемы (и оба они реализованы в dumbproxy).
Первый способ заключается в том, чтобы использовать аутентификацию клиентов по сертификатам ещё на этапе TLS-рукопожатия. Это самый стойкий метод, и это действительно корректная причина, по которой любой обычный веб-сервер мог бы отвергнуть клиента.
Второй способ заключается в том, чтобы скрыть от неавторизованных клиентов код ответа 407, возвращая вместо него любой другой ответ с ошибкой. Это вызывает другую проблему: браузеры не смогут понять, что для прокси требуется авторизация. Даже если браузер имеет сохранённый логин и пароль для этого прокси, ответ 407 важен для определения схемы авторизации, по которой эти учётные данные должны быть отправлены (Basic, Digest и т. д.). Для этого нужно позволить прокси генерировать ответ 407 на секретный запрос, чтобы браузер мог запомнить схему авторизации. В качестве такого секретного запроса используется настраиваемый секретный домен (не обязательно реально существующий). По умолчанию этот режим выключен. Подробности можно посмотреть в разделе об аутентификации.
Заключение
Я пользуюсь этими решениями уже один год и в итоге они мне полностью заменили VPN, вместе с этим сняв все проблемы, с которыми сопряжено его использование.
Надеюсь, что эта статья добавит к арсеналу читателей новые подходы к защите трафика и будет им полезной.
Что такое VPN, Proxy, Tor? Разбор
Анонимность и конфиденциальность — это прекрасные понятия. Но в последнее время создается ощущение, что в сети оба понятия стили недостижимыми. Поэтому даже я, совсем не параноик периодически задумываюсь об инструментах, таких как VPN, Proxy и Tor. Вы наверняка слышали эти слова, а может быть даже регулярно пользуйтесь пользуетесь этими технологиями для сохранения анонимности, обхода блокировок, просмотра американского Netflix или банально для доступа к корпоративной сети.
Proxy
Среди троицы — VPN, Proxy, Tor — самая простая технология — это именно Proxy. С неё и начнём.
Proxy переводится с английского, как представитель, уполномоченный, посредник. Иными словами, прокси-сервер — это сервер-посредник.
Технология работает также просто как и звучит. Представьте, что ваш трафик в сети — это чемодан. Вы хотите доставить этот чемодан по определенному адресу, но не хотели бы делать это сами, раскрывая свое местоположение и имя. Поэтому вы нанимаете посредника, который сам доставит чемодан по нужному адресу не раскрывая вашу личность и настоящий адрес. Просто и удобно. Более того такие посредники достаточно многофункциональны и пригодятся не только для банального обеспечения конфиденциальности в сети:
Типы Proxy
Во-первых, сама по себе технология очень ограниченная. Прокси-серверы узкоспециализированы, поэтому на каждый тип интернет-соединения нужен свой тип прокси-сервера.
Например, для FTP-соединения (File Transfer Protocol) нужен FTP-прокси. Для HTTP и HTTPS также два отдельных HTTP- и HTTPS-прокси сервера.
Это серьёзное ограничение, поэтому еще есть отдельный тип прокси-серверов SOCKS-прокси.
Эта вариация протокола умеет работать с разными типами трафика. Но она работает медленнее, поэтому также подходит не для всех.
Безопасность Proxy
Но это половина беды. Все виды прокси объединяет главная, ключевая проблема — проблемы с безопасностью.
Потому как прокси-сервера дополнительно никак не шифруют трафик. То есть HTTP трафик вообще не будет никак шифроваться. А HTTPS будет зашифрован также как и при обычном интернет соединении: при помощи SSL-шифрования. А это огромная проблема. И чтобы представить масштаб трагедии, давайте вспомним аналогию с чемоданом.
Пользоваться прокси-сервером — это всё равно что передавать данные посреднику в чемодане без пароля. Делать такое можно только в случае если 100% доверяете посреднику. И конечно же стоит остерегаться бесплатных прокси-серверов с сомнительной репутацией. Ведь воспользоваться непроверенным бесплатным прокси, это все равно, что доверить доставить мешок бесплатному курьеру по объявлению на автобусной остановке.
Как же здорово, что во время блокировки Telegram мы все дружно пользовались проверенными надежными прокси. Так ведь?
Но есть технология, которая обладает большинством достоинств прокси и лишена большинства недостатков — это VPN или Virtual Private Network — виртуальная частная сеть.
Изначально эта технология задумывалась не как средство анонимизации трафика. Ее задачей было удаленно объединять компьютеры в единую сеть. Например, для доступа к локальной сети головного офиса из регионального филиала или из дома.
Принцип работы VPN похож на прокси. Трафик точно также, прежде чем попасть в интернет, сначала попадает на промежуточный сервер. Это с одной стороны позволяет вам, например, получить доступ к заблокированным ресурсам. Потому как для интернет провайдера, вы направляете запрос на VPN сервер, а не на запрещенный сайт.
С другой стороны, это позволяет вам сохранить анонимность, так как сайт, на который вы попали думает, что запрос пришел с IP-адреса VPN-сервера, а не вашего. Но прокси-серверы, делают по сути тоже самое, так в чем же тогда разница?
Ключевое отличие VPN от Proxy — это сквозное шифрование. Весь трафик проходящий через VPN-сервер защищен на всём пути от точки входа до точки выхода. А всё потому, что при включенном VPN между вашим устройством и VPN-сервером создается зашифрованный канал связи, который защищает все данные от хакерских атак.
Опять же если сравнивать с прокси, в первом случае мы передаем открытый чемодан с информацией посреднику, которого либо могут в любой момент обокрасть, либо он сам украдет данные. В случае VPN мы передаем данные по закрытому туннелю проникнуть в который крайне сложно. Более того VPN работает со всеми типами данных и шифрует вообще весь трафик со всех приложений, а не только трафик вашего браузера.
При этом в отличии от прокси, для работы VPN на вашем устройстве обязательно должен быть установлен VPN-клиент в виде отдельного приложения или расширения браузера.
Впрочем, поставить приложение для рядового пользователя куда проще, чем копаться в настройках прокси где-то в настройках браузера.
Бесплатные VPN-сервисы
Получается, что VPN во всем лучше прокси? Не всегда.
Дело в том, что не все VPN-сервисы одинаково полезны. Как и в случае с прокси, бесплатные VPN-сервисы не раз были пойманы в слежке за пользователями и продаже их данных.
Например, VPN-сервис Betternet, который насчитывал 38 миллионов пользователей использовал целых 14 библиотек для слежки за пользователями.
А сервис Hola продавал IP-адреса бесплатных пользователей злоумышленникам. То есть преступники могли использовать ваш IP-адрес для своих делишек.
SHADOWSOCKS
С другой стороны, не все прокси-сервисы плохие. Например, существует особый тип прокси, который называется Shadowsocks. По сути, это SOCKS-прокси на стероидах.
Тут есть и мощное шифрование, и скрытие трафика, и возможность обходить различные блокировки. Есть клиенты как для компьютера, так и для смартфона, позволяющие оставаться под защитой постоянно. А создана эта штука была нашим дружественным братским китайским народом с целью обхода великого китайского файерволла.
Отсюда и несколько приятных особенностей Shadowsocks. Например, для элегантного обхода блокировок, он умеет выборочно маскировать трафик. Вы сами выбираете что прятать, а что нет.
Например, находитесь вы в Китае и хотите проверь почту на Gmail, или свят-свят — посмотреть YouTube. Благодаря Shadowsocks, вы сможете сделать и это, и одновременно посещать сайты, доступные только из Китая.
В свою очередь, VPN-сервисы зашифровывают весь трафик, поэтому открыть сайты, доступные только в Китае, вы уже не сможете.
Но это не значит, что Shadowsocks лучше VPN. В отличие от VPN-сервисов, Shadowsocks не создан для защиты конфиденциальности и анонимности пользователя. При использовании Shadowsocks пакеты данных остаются без шифрования. Это сделано специально, чтобы ваши данные были больше похожи на обычный HTTPS-трафик и не вызывали подозрений. Поэтому Shadowsocks подходит только для обхода блокировок? но никак не для безопасности или подключения к корпоративной сети. В этом плане VPN — вне конкуренции. С поправкой на то, что пользоваться нужно только проверенными сервисами с хорошей репутацией.
И, наконец, самый хардкорный способ анонимизации в сети — Tor. Что это и правда ли, что Tor такой безопасный?
Tor расшифровывается как The Onion Router и он использует так называемую луковую маршрутизацию. Твои данные — это сердцевина луковицы, а их защита — слои вокруг. Что это значит?
Для анонимизации Tor, также как прокси и VPN, пропускает трафик через промежуточные серверы. Но Только в случае с Tor их не один, а три, и называется они узлами.
А вот теперь смотрите, ваш трафик проходит через три узла:
Во-первых, чтобы скрыть ваш IP-адрес. Каждый узел знает IP-адрес только узла, который стоит в цепочке перед. Поэтому пока ваш трафик дойдет до третьего узла, исходный IP потеяется.
Во-вторых, ваш трафик обернут в три слоя защиты. Поэтому первый и второй узел не видят вашего трафика, они только снимают слои защиты как, как кожуру с луковицы, а вот достает сердцевину и отправляет запрос в интернет только третий выходной узел.
Эти узлы разворачивают сами пользователи сети на своих компах. Чем больше пользователей, тем безопасней и тем быстрее работает сеть.
А доступ к сети осуществляется через специальный браузер Tor Browser, основанный на Firefox. Его улучшили дополнениями, запрещающими сайтам следить за тобой. Например браузер умеет отличать все скрипты на сайтах, фактически запрещая собирать любые данные пользователя, или заставляет сайты принудительно использовать шифрование. Звучит очень безопасно, но на практике, это не так.
Во-первых, Tor очень не любят правоохранительные органы, а сам факт использования Tor легко отследить. Поэтому, просто используя Tor Browser, вы уже можете привлечь лишнее внимание. Иными словами лучше использовать Tor в связке с VPN.
Во-вторых, владельцы выходных узлов очень рискуют. Ведь именно они несут ответственность за все действия, которые совершают пользователи сети.
В-третьих, те же владельцы выходных узлов видят весь ваш трафик, а значит они могут отследить вас по косвенным признакам. Именно поэтому выходные узлы больше всего любят создавать сотрудники правоохранительных органов.
Более того, из-за многослойного шифрования сеть Tor работает очень медленно, половина сайтов прост отказывается корректно работать через Tor Browser.
Итоги
Что в сухом остатке? Если вы беспокоитесь за свою безопасность в сети, то самым оптимальным способом защиты будет VPN. Но не забывайте, что использовать надо только надежные VPN-сервисы с хорошей репутацией. Часто информацию о надёжности того или иного сервиса можно найти в интернете, в специальных статьях. Также помните, что хороший VPN может стоить денег, вернее его создатели могут брать за его использования какую-либо сумму. Ведь бесплатный сыр бывает только в мышеловке.
Анализ HTTP-трафика с Mitmproxy
В практике веб-разработчика нередко возникают ситуации, когда требуется отследить и проанализировать трафик приложений, общающихся с сервером по протоколу HTTP (в качестве примера можно привести тестирование приложений для мобильных устройств или HTTP API).
Инструменты, традиционно используемые для прослушивания трафика (tshark, о котором мы уже писали, а также ngrep и tcpdump) для этой цели подходят плохо: функциональность для работы с протоколом HTTP у них ограничена.
Для анализа HTTP-трафика существует более специализированное, простое и эффективное решение. Знакомьтесь: mitmproxy. На русском языке подробных публикаций о нем почти нет. В этой статье мы поделимся своим опытом работы с mitmproxy и надеемся, что и вам он окажется полезным.
Общая информация
Само название mitmproxy происходит от аббревиатуры MITM, что означает man in the middle, или «человек посередине». Так называется метод компрометации канала связи, в котором взломщик подключается к каналу передачи между двумя контрагентами и вмешивается в протокол передачи, просматривая, удаляя и искажая информацию. mitmproxy работает похожим образом: он используется в качестве прокси-сервера, регистрируя весь HTTP-трафик. Как и любой прокси-сервер, в некоторых случаях mitmproxy может видоизменять как запросы пользователя, так и ответы на них.
Рассмотрим принципы и особенности mitmproxy более подробно.
Как это работает
В случае с незашифрованными HTTP-соединениями все просто: mitmproxy принимает соединение от клиента (например, от браузера на мобильном устройстве), отображает информацию о нем на консоли (или сохраняет в текстовый файл), а затем возвращает клиенту ответ от получателя запроса.
Mitmproxy можно использовать и для перехвата защищенного HTTPS-трафика. При запуске mitmproxy или mitmdump в директории
/.mitmproxy создается набор файлов CA, на основе которых генерируются подменные сертификаты. Естественно, что браузер будет эти сертификаты определять как подозрительные, выдавая при каждой попытке установить SSL-соединение с помощью mitmproxy соответствующее предупреждение.
Чтобы этого предупреждения не было, можно добавить сертификат от mitmproxy в список сертификатов, используемых браузером (с подробными инструкциями можно ознакомиться здесь).
При выполнении этих двух условий клиент делает вывод о том, что устанавливаемое соединение является безопасным.
Mitmproxy может перехватывать и защищенный HTTPS-трафик. Процедура перехвата состоит из следующих шагов:
Более наглядно процесс перехвата защищенного трафика можно представить в виде следующей графической схемы:
Зачем это нужно
Само название mitmproxy происходит от названия одного из самых распространенных видов атак. Даже официальная документация к продукту изобилует такими словами, как «атака», «перехват» и подобными. Все это наводит на мысли о том, что этот инструмент может выступать в качестве орудия взлома. Конечно, mitmproxy (как и все продукты с аналогичным набором функций — так называемые сниферы) вполне может быть использован для нелегальных целей, но мы по вполне понятным причинам обсуждать это не будем и сосредоточимся на легальных вариантах использования.
Mitmproxy можно использовать, во-первых, для тестирования и отладки веб-приложений. С его помощью можно получать подробную информацию о том, какие запросы делает приложение и какие ответы оно получает. Также mitproxy может помочь в изучении особенностей функционирования некоторых REST API, в особенности плохо документированнных и использующих закрытые (и зачастую- очень подозрительные) технологии.
Во-вторых, Mitmproxy может работать в режиме прозрачного прокси с перехватом трафика, а это значит, что его можно использовать для анализа сетевой активности подозрительных приложений.
Тестируем Mitmproxy
Установка
Сегодня mitmproxy включен в репозитории linux-систем и может быть установлен при помощи стандартного менеджера пакетов:
Можно также установить его другими способами:
Первый запуск
Посмотрим на конкретных примерах, как работает mitmproxy. Откроем браузер (в нашем случае это Firefox) и в настройках (меню «Настройки» → «Сеть» → «Соединение») и в разделе «Ручная настройка сервиса прокси» укажем в качестве прокси-сервера машину, на которой установлен mitmproxy.
Теперь подключимся к серверу, на которому установлен mitmproxy, по ssh и выполним следующую команду:
Консоль после этого будет выглядеть так:
Чтобы выйти из этого режима, нужно нажать клавишу q. Получить справку можно, нажав комбинацию клавиш, обозначающую вопросительный знак (?).
Теперь откроем в браузере любой сайт — например, ya.ru. Все запросы к этому сайту будут выводиться на консоль:
Перемещаться по списку запросов можно, нажимая на клавиши со стрелками. Вернуться в основное окно можно, нажав на клавишу q. Чтобы просмотреть подробную информацию о некотором запросе, нужно подвести к нему курсор и нажать на клавишу Enter:
В поле Request отображается подробная информация о запросе (запрашиваемый хост, ПО, с помощью которого осуществлялся запрос, передаваемые заголовки), а в поле Response — информация о полученном ответе.
Переключаться между этими полями можно при помощи клавиши Tab. Вернуться к списку запросов можно, нажав на клавишу q.
Запросы и ответы на них можно изменять. Для этого нужно использовать так называемые фильтры перехвата (interception filters). Чтобы ввести фильтр, нужно нажать на клавишу i. Введем в качестве фильтра, например, ya.ru Все запросы, содержащие этот адрес, будут перехватываться. Перехваченные запросы в списке будут подсвечиваться оранжевым цветом:
Такие запросы не будут обрабатываться, если мы их не примем. Чтобы принять запрос, нужно подвести к нему курсор и нажать на клавишу а, а чтобы принять все перехваченные запросы — на клавишу A.
Более подробную информацию о запросе можно просмотреть, подведя к нему курсор и нажав на клавишу E (E- первая буква в английском слове event — «событие»). Будет открыт лог событий, который имели место при обработке этого запроса:
И запросы, и ответы можно редактировать. Функция редактирования может оказаться полезной при тестировании: можно, например, смоделировать определенную ситуацию и увидеть, как будет вести себя приложение, получив от сервера определенный ответ.
Подведём курсор к интересующему нас запросу, подведём к нему курсор и нажмём на клавишу Enter. Затем подведём курсор к полю Request и нажмём на клавишу E (первая буква в слове edit — редактировать). В нижней части консоли появится меню редактирования:
Изменить можно как запрос целиком (клавиша Q), так и его отдельные параметры: путь (клавиша P), URL (U), заголовок (H), форму (F), тело ® и метод (M).
Аналогичным образом осуществляется редактирование ответа. Отредактировать можно его код (клавиша C), сообщение (M), заголовки (H) и тело ®.
Дополнительные функции
Аутентификация на прокси-сервере
В mitmproxy можно активировать режим аутентификации пользователей перед использованием прокси. Заголовки аутентификации из запросов удаляются и на вышестоящие серверы на передаются. На сегодняшний день поддерживается только базовая HTTP-аутентификация. Настройка аутентификации осуществляется при помощи следующих опций:
Привязка cookies
Функция привязки cookies (sticky cookies) полезна при работе с сервисами, требующими авторизации. Достаточно авторизоваться на таком сервисе один раз, и mitmproxy будет автоматически добавлять соответствующий cookie к каждому запросу. После этого все запросы будут передаваться на сервер без повторной авторизации.
Режим привязки cookies активируется так:
Режим reverse proxy
В этом режиме все запросы отсылаются к вышестоящему серверу. Mitmproxy в данном случае можно использовать в качестве временной прослойки, наблюдая и перехватывая запросы.
Режим reverse proxy активируется при помощи команды:
Функция anticache
Mitmproxy может убирать из запроса заголовки if-modified-since и if-none-match. Благодаря этому всегда можно просмотреть полный ответ от сервера, даже если браузер сообщает, что запрашиваемый документ есть в кэше.
Активируется эта функция при помощи следующей команды:
Воспроизведение клиентских запросов
Функция воспроизведения клиентских запросов (client side replay) позволяет воспроизводить запросы из сохраненных ранее HTTP-диалогов. Запросы исполняются один за другим: отправив один запрос, mitmproxy ждет ответа от сервера, и только потом приступает к следующему. Поэтому поведение клиента может отличаться от записанного в сохраненный диалог, в котором некоторые запросы могли выполняться одновременно.
Воспроизвести клиентские запросы можно при помощи команды:
Mitmdump
Как уже было сказано выше, Mitmdump представляет собой утилиту, работающая точно так же, как и tcpdump, только для протокола HTTP. Она перехватывает весь HTTP-трафик и записывает информацию о нем в отдельный текстовый файл.
Чтобы начать работу с mitmdump, нужно запустить mitmproxy в режиме прокси-сервера, а затем выполнить следующую команду:
Сохраненную информацию можно отфильтровать при помощи регулярных выражений, а затем сохранить в новый файл:
В приведенном примере mitmdump отбирает из файла 1 запросы, соответствующие определенному критерию (в нашем случае — POST-запросы), и записывает их в файл 2.
Mitmdump может считать уже сохраненную информацию о клиентских запросах из файла, воспроизвести эти запросы повторно, а результаты сохранить в новый файл:
Эта функция может оказаться полезной при тестировании некоторых веб-приложений.
Заключение
В этой статье мы дали краткий обзор возможностей mitmproxy. Для желающих узнать больше приводим несколько ссылок: