Что такое reverse proxy
Поделиться
doctor Brain
мир глазами веб-разработчика
Реверсивный прокси-сервер
Что такое реверсивный прокси-сервер и для чего он нужен
время чтения 2 мин.
Для начала, поговорим о прокси-сервере (proxy).
Такая технология имеет несколько полезных применений. Различные компании и организации используют прокси-серверы для фильтрации соединений, обеспечения безопасности подключений и логирования трафика. Без использования прокси-сервера клиенты не могут подключиться к внешней сети. Кроме того, прокси-серверы часто бывают полезны для обеспечения конфиденциальности подключений и обхода ограничений, установленных на уровне правительств разных стран.
В отличие от простого прокси-сервера реверсивный прокси-сервер (reverse proxy) настраивается на уровне серверного оборудования. Реверсивный прокси-сервер абсолютно прозрачен для пользователей, которые обычно даже не догадываются о его существовании. Тем не менее, реверсивный прокси-сервер выполняет очень важную работу, фильтруя запросы и отправляя их на обработку соответствующим сервисам.
Nginx обычно является основным обработчиком запросов, перенаправляющим соответствующие запросы: например, связывая определенные каталоги или URL-адреса с конкретными службами.
Так же, можно встретиться с несколькими различными Node.js-приложениями, выполняющими совершенно различные задачи. При это пользователи соответствующих сервисов даже не догадываются о наличии таких служб.
Помимо функции маршрутизации, из-за которой реверсивные прокси-серверы так популярны у веб-разработчиков, реверсивные прокси-серверы могут выполнять и другие задачи, в том числе:
и это далеко не все возможности реверсивных прокси-серверов.
Как APT используют обратные прокси-серверы для Nmap-сканирования внутренних сетей
Поскольку обратные прокси-серверы могут обходить ограничения брандмауэра на входящий трафик, злоумышленники, планирующие APT, используют их для pivot-атак на защищенные среды. К примеру, не так давно жертвой такой атаки стала корпоративная сеть федерального агентства. Злоумышленники использовали модификацию Invoke-SocksProxy — скрипта с открытым исходным кодом для работы с обратными прокси, который можно найти на GitHub. Вот что пишет по этому поводу Агентство по кибербезопасности и инфраструктуре (СISA): Злоумышленник установил Persistence и C2 в сети жертвы через постоянный туннель SSH/обратный прокси-сервер SOCKS… Скрипт PowerShell [Invoke-SocksProxy.ps1] создал обратный прокси-сервер SMB SOCKS, который разрешил устанавливать соединения между управляемым злоумышленником VPS… и файловым сервером организации, выбранной в качестве жертвы… Invoke-SocksProxy.ps1 создает обратный прокси-сервер между локальным устройством и инфраструктурой хакера…
Что такое обратный прокси-сервер?
Злоумышленники могут использовать прокси-сервер для направления сетевого трафика между системами или выступать посредником в передаче данных по сети. чтобы не позволить напрямую подключиться к своей инфраструктуре. Злоумышленники используют эти типы прокси-серверов для управления инфраструктурой C2 [или] для уменьшения количества одновременных исходящих сетевых подключений… Злоумышленники могут объединить несколько прокси-серверов в цепочку, чтобы тщательнее замаскировать источник вредоносного трафика…
Настройка атаки
Топология сети включает несколько локально подключенных устройств (172.16.0.1/24). Для простоты понимания предположим, что злоумышленник установил обратную оболочку на хосте A (172.16.0.3) с вредоносным документом Word (см. ниже). При таком уровне компрометации система Kali злоумышленника не может напрямую взаимодействовать с серверами SMB и HTTP. Его цель — обнаружить службы на 172.16.0.1/24 при использовании хоста A в качестве прокси.
В данном примере скомпрометированный хост подключается к виртуальному выделенному серверу (VPS) злоумышленника с помощью прослушивания через утилиту Netcat по TCP/4444 (как показано ниже). Соединение Netcat должно оставаться открытым — это будет важно на более позднем этапе.
В Kali запускаем новый терминал и подключаемся по SSH к VPS. С помощью команды su получаем оболочку с привилегиями root.
Используя приведенную ниже команду, копируем наш архив Invoke-SocksProxy. В нем два файла: ReverseSocksProxyHandler.py и Invoke-SocksProxy.ps1.
root@vps > cd /opt; git clone https://github.com/tokyoneon/Invoke-SocksProxy
Скрипт ReverseSocksProxyHandler.py откроет порты 443 и 1337. Порт 443 будет принимать входящие соединения от хоста A. Порт 1337 будет работать как порт прокси-сервера, настроенный с помощью proxychains в Kali. При выполнении появится следующий результат. Терминал всё время атаки должен оставаться открытым.
root@vps> cd /opt /Invoke-SocksProxy;./ReverseSocksProxyHandler.py
Скрипт Invoke-SocksProxy.ps1 должен быть запущен на скомпрометированном хосте. Повторно запускаем новый терминал в Kali и подключаемся по SSH к VPS. В Invoke-SocksProxy.ps1 меняем жестко запрограммированный адрес VPS в Invoke-SocksProxy.ps1 и размещаем его на HTTP-сервере (например, Apache, Nginx или http.server).
В Kali устанавливаем proxychains4 и редактируем файл /etc/proxychains4.conf. В конце файла конфигурации прописываем адрес VPS и порт 1337.
Вот и всё, атака подготовлена. С помощью ReverseSocksProxyHandler и Invoke-SocksProxy, запущенных на VPS и хосте A, можно атаковать внутреннюю сеть через прокси.
Прокси Nmap и Crackmapexec с Proxychains
При использовании Nmap с Proxychains нужно помнить о некоторых ограничениях. Например, у Nmap не получится обнаружить хост — утилита не сможет выполнить «пингование» (ICMP) через SOCKS5. Несмотря на это, обнаруживать службы и порты она будет по-прежнему эффективно (хотя и не так быстро, поскольку нужно будет полностью сканировать TCP).
Нижеописанная команда Nmap выполнит сканирование с использованием TCP-соединений (-sT), не обнаруживая при этом хосты (-Pn) и не выполняя разрешение DNS имен (-n). Эти аргументы необходимы для использования Nmap с Proxychains. Обратите внимание на SMB-сервер на 172.16.0.4:445 и HTTP-сервер на 172.16.0.115:80.
Чтобы просмотреть общие ресурсы на скомпрометированном сервере SMB, используем приведенную ниже команду crackmapexec, вставив обнаруженный пароль. Обратите внимание на общий ресурс «Private» с разрешениями на чтение и запись.
Чтобы получить доступ к его содержимому, используем команду smbclient для просмотра желаемого каталога (в данном случае «/Private»). Обратите внимание на файл credentials.txt в общей папке. В smbclient используем команду get, чтобы получить файл и сохранить его локально в Kali.
Точно так же аналогичные команды proxychains предоставляют доступ к HTTP-серверам. Однако в Firefox есть встроенные функции, благодаря которым удобнее взаимодействовать с прокси.
Открываем Firefox в Kali, переходим в меню: Настройки > Параметры сети > Настроить и настраиваем IP-адрес и порт VPS в разделе SOCKS Host (узел SOCKS) (как показано ниже). Нажимаем ОК, чтобы сохранить конфигурацию.
Затем открываем новую вкладку и заходим на любой HTTP-сервер во внутренней сети (например, 172.16.0.115:80).
Судя по журналам HTTP-сервера на 172.16.0.115, запросы, исходят от 172.16.0.3 (хост A), то есть скомпрометированного хоста.
Обнаружение и минимизация рисков
Анализируйте сетевые данные на предмет нетипичных или аномальных потоков данных. Например, клиенты отправляют значительно больше данных, чем получают от серверов, которые обычно взаимодействуют друг с другом редко либо не должны этого делать вообще. Подозрительно, когда сеть использует процессы, которые обычно не связаны с ней или никогда ранее не наблюдались. Анализируйте содержимое пакетов, чтобы обнаружить соединения, которые не соответствуют предполагаемым правилам, существующим для протокола используемого порта.
Фильтрация сетевого трафика: трафик в известные анонимные сети и инфраструктуру управления и контроля можно заблокировать с помощью черных и белых сетевых списков. Следует отметить, что такого рода блокировку можно обойти с помощью других методов, например, метода прикрытия доменом (Domain Fronting).
Предотвращение вторжений в сеть: сдерживать активность на сетевом уровне помогут системы обнаружения и предотвращения вторжений в сеть, которые определяют трафик конкретных вредоносных программ с помощью сетевых сигнатур. C2 Уникальные индикаторы часто используют в протоколах сигнатуры, которые могут быть основаны на конкретном протоколе C2 конкретного злоумышленника или инструмента. Такие сигнатуры, вероятно, будут различаться для разных семейств и версий вредоносных программ. Возможно, злоумышленники со временем изменят сигнатуры инструментов C2 или построят протоколы таким образом, чтобы избежать обнаружения обычными защитными инструментами.
Проверка SSL/TLS: если есть возможность изучать трафик HTTPS, можно проверить, нет ли в собранных данных подключений, которые напоминают прикрытие доменом.
Для дополнительной информации, CISA рекомендует организациям применять следующие методы:
Использовать многофакторную аутентификацию, особенно для привилегированных учетных записей;
Использовать отдельные административные учетные записи на отдельных административных рабочих станциях;
Применять принципы наименьших привилегий для доступа к данным;
Защищать RDP и другие решения удаленного доступа с помощью многофакторной аутентификации и jump-сервера;
Внедрять и поддерживать средства защиты на всех конечных точках;
Пробы и ошибки при выборе HTTP Reverse Proxy
Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.
Сначала микросервис был мал и выполнял следующие функции:
По мере роста сервиса стали всплывать разного рода проблемы. Разные поставщики выдвигают свои правила работы: кто-то ограничивает максимальное количество соединений, кто-то ограничивает клиентов белыми списками.
В итоге нам предстояло решить следующие задачи:
Схема была простой: делался запрос в наш новый Proxy Server на Nginx с доменом вида
соответствовал адресу партнера. Из map брался адрес и делался proxy_pass на этот адрес.
А вот как выглядит “ snippet.d/upstreams_map ”:
Тут у нас сам server<> :
Все классно, все работает. Можно на этом закончить статью, если бы не один нюанс.
Добавляем еще один map для парсинга схемы:
И создаем upstreams с именами тегов:
Сам сервер немного видоизменяем, чтобы учитывать схему и вместо адреса использовать имя апстрима:
На этот раз точно можно заканчивать статью и идти пить чай. Или нет?
Ведь пока мы пьем чай, у кого-то из поставщиков может под тем же доменом измениться IP адрес или группа адресов (привет, Амазон), тем самым один из поставщиков может отвалиться в самый разгар нашего чаепития.
Ну что же, как быть? Есть у Nginx интересный нюанс: во время reload он может отрезолвить сервера внутри upstream в новые адреса и пустить трафик на них. В целом, тоже решение. Закидываем в cron reload nginx раз в 5 минут и продолжаем пить чай.
Но все же это показалось мне так себе решением, поэтому я стал косо посматривать в сторону Haproxy.
Отлично! Теперь осталось дело за настройками.
Вот краткий пример конфигурации для Haproxy:
Кажется, что на этот раз все работает как нужно. Вот только чем мне не нравится Haproxy, так это сложностью описания конфигураций. Нужно настрочить довольно много текста, чтобы добавить один работающий апстрим. Но лень – двигатель прогресса: если не хочется писать одно и то же, напиши генератор.
Теперь все, что нам нужно, это добавить новый хост в nginx_map, запустить генератор и получить готовый haproxy конфиг.
На сегодня, пожалуй, все. Данная статья относится скорее к вводной и была посвящена проблеме выбора решения и его интеграции в текущее окружение.
В следующей статье я расскажу подробнее о том, какие подводные камни нам встречались при использовании Haproxy, какие метрики оказалось полезно мониторить и что точно стоит оптимизировать в системе, чтобы выжать максимум производительности из серверов.
Разница между обратным и прямым прокси
Если вы новичок в мире прокси, вы, должно быть, сталкивались с двумя терминами — обратный прокси и прямой прокси. На самом деле это не одно и то же понятие. Я видел, как люди ошибочно принимали одно за другое, и это проистекает из того факта, что они на самом деле не понимают обоих.
Именно поэтому я написал эту статью; чтобы узнать, что отличает обратный прокси от прямого и как они выполняют одну и ту же функцию в разных средах. Перед этим давайте посмотрим, что собой представляет каждый из них.
Определение обратного и прямого прокси
Я знаю, вам может быть интересно, зачем поднимать этот вопрос; это потому, что вам должно быть дано четкое определение прокси. Большинство людей рассматривают прокси как сервер, через который клиенты отправляют свои веб-запросы на веб-сайты.
Что ж, это еще не все, что касается прокси. В отличие от большинства наших статей, мы должны перейти к более техническим аспектам и переопределить прокси для вас. Прокси-сервер — это просто сервер, действующий в зависимости от поведения другого компьютера, который может быть клиентом или сервером. Это означает, что помимо вас как клиента, которому нужны прокси-серверы, чтобы прятаться, веб-сервер, с которого вы запрашиваете ресурсы, также может скрываться за прокси.
Что такое прямой прокси?
Когда вы слышите, как люди упоминают слово «прокси» в веб-технологиях, на самом деле они имеют в виду прямые прокси. Прямые прокси — это типы прокси, которые клиенты используют для сокрытия своих IP-адресов и сохранения анонимности при работе в Интернете.
Что они делают, так это пересылают запросы, отправляемые через них, на соответствующие веб-серверы, и когда ответ им возвращается, они отправляют его вам. В зависимости от уровня анонимности веб-сервер, с которого вы запрашиваете ресурсы, не будет знать, что вы инициировали запрос. Но Forward Proxy знает и вас, и веб-сервер, с которого вы запрашиваете содержимое.
Как работает прямой прокси
При подключении к прокси-серверу ваше устройство отправляет обычный запрос, как если бы прокси-сервер не существовал, но оно будет перенаправлять все свои запросы через этот прокси-сервер, и прокси будет принимать запросы и перенаправлять их через свой собственный IP-адрес, и если он запутан (анонимен), он скроет ваш IP-адрес и заменит его своим собственным адресом.
Лучший пример того, как прямой прокси-сервер может вам помочь, — это обход сетевой блокировки. Если ваша сеть блокирует Instagram, вы можете решить проблему блокировки с помощью прокси https://proxy-seller.ru/russian-proxy. Вы подключитесь к прокси-серверу вместо сервисов Instagram и будете получать информацию без предупреждения брандмауэра.
Что такое обратный прокси?
Хотя вышеперечисленное применимо только к клиентам, некоторые прокси также были разработаны для обеспечения конфиденциальности веб-серверов. Позвольте мне рассказать вам кое-что. Не только вам нужна конфиденциальность; веб-серверам это нужно, потому что они не знают, заслуживаете ли вы доверия или нет. Однако некоторые существуют по другим причинам.
Обратный прокси-сервер — это прокси-сервер, который принимает веб-запросы от имени веб-серверов. После получения запроса, основываясь на его конфигурации, он определяет, заслуживает ли запрос перенаправления на реальный сервер или нет.
При наличии обратного прокси-сервера вряд ли удастся напрямую поразить реальный сервер — это потому, что только IP-адрес обратного прокси является общедоступным. Это создает определенный уровень конфиденциальности для серверов.
Как работает обратный прокси
По сути, веб-сервером может быть один сервер или их набор, но они не подключаются напрямую к Интернету. Вместо этого они подключаются к обратному прокси. Этот обратный прокси-сервер действует как веб-сервер. Вы как веб-браузер подключаетесь к сайту и просто видите прокси; вы не видите ни одного из серверов, стоящих за ним. Прокси-сервер притворяется веб-сервером, выполняя такие функции, как скрытие настоящего IP-адреса сервера.
Обратный или Прямой прокси
Глядя на приведенные выше определения, вы можете увидеть, что эти два термина не совпадают и, по сути, совершенно разные. На всякий случай, если вы не заметили разницы, в этом разделе мы подробно обсудим различия между ними.
Структурная позиция
Самая важная отличительная черта как обратных прокси-серверов, так и их аналогов прямых прокси — это их структурное положение во всем сочетании отправки и получения ответа. Для прокси-серверов Forward они являются клиентскими и обеспечивают клиентскую анонимность для вашего ПК. Прямые прокси — это ваш шлюз в Интернет, и они могут изменять ваши запросы до того, как они попадут на веб-сайт, который вы собираетесь посетить. Чтобы вы могли использовать прокси-сервер пересылки, вам необходимо настроить их на своей стороне — на стороне клиента.
Для обратных прокси они ориентированы на сервер и обеспечивают анонимность на стороне сервера. Они служат шлюзом к веб-серверу, с которым вы собираетесь взаимодействовать. Так же, как вы не хотите, чтобы веб-серверы знали ваш реальный IP-адрес, некоторые организации также не хотят, чтобы вы знали о существовании их фактических серверов; Итак, они устанавливают прокси-сервер, который действует как их настоящий сервер. Но когда поступают запросы, он направляет их на настоящий сервер.
Область применения
Структурное расположение двух типов прокси сделало их область применения различной. Хотя оба могут блокировать умеренный трафик пользователей и оба являются шлюзами, их приложения различаются. Каковы же тогда варианты использования каждого из них?
Для форвардных прокси вариант их использования довольно прост и известен многим пользователям Интернета.
Сама идея предоставления IP-адреса и конфиденциальности местоположения открывает множество областей, в которых используются прокси-серверы. Прямые прокси полезны в области защиты бренда и проверки рекламы. Они также полезны при поисковой оптимизации, сканировании и парсинге в Интернете, а также при игре в онлайн-игры, социальные средствами автоматизации медиа, и многими другими.
Для обратных прокси их использование не известно широкой публике, за исключением тех, кто знаком с серверными технологиями.
Одним из наиболее важных применений обратных прокси является то, что они используются для балансировки нагрузки. Они распределяют входящие веб-запросы на группу веб-серверов, выполняющих одну и ту же функцию — это позволяет веб-сайту с высоким трафиком быстро отвечать на отправленные им запросы. Помимо этого, они используются для кеширования, что в конечном итоге приводит к более быстрому отклику и экономии полосы пропускания. Они также используются по соображениям безопасности, чтобы обеспечить некоторую форму оболочки для реальных серверов, чтобы было трудно атаковать их напрямую.
Вывод
Глядя на вышеизложенное, вы увидите, что, хотя все они имеют слово «прокси» в своих именах, на самом деле это не одно и то же. У них обоих есть свое уникальное использование, основанное на их позиции в цикле запроса-ответа. Однако важно знать, что каждый из них модерирует ваш трафик и может либо заблокировать ваши запросы, либо разрешить их.
Перерастая reverse proxy — технология удаленной защиты и оптимизации сайтов без изменения А-записей DNS
За последний месяц средняя нагрузка на интернет ресурсы сильно выросла из-за повсеместного перехода на дистанционную работу и обучение (как именно читайте в нашем материале «Пандемия и трафик — взгляд со стороны оператора связи». Особым спросом пользуются онлайн кинотеатры и игры, платформы для онлайн обучения, сервисы по заказу доставки еды. В таких условиях потенциальный экономический ущерб от недоступности ресурса, в том числе из-за DDoS-атак, особенно высок. Какое решение выбрать для защиты своего проекта?
В материале вас ждут:
Скорее всего, первое решение, которое вам попадется, будет основано на технологии reverse proxy со сменой A-записей DNS. Поэтому сначала мы рассмотрим принцип работы технологии, ее возможности (если вы хорошо знакомы с reverse proxy — смело пропускайте эти два подраздела) и ограничения, связанные с доставкой трафика (это пропускать не стоит). Затем мы покажем, как эти ограничения можно обойти на примере реального кейса. В конце мы дадим несколько общих рекомендаций по организации защиты интернет ресурса.
Reverse proxy — принцип работы
Здесь мы рассмотрим reverse proxy, как средство доставки трафика. Схема ее работы всем хорошо знакома, но не упомянуть ее здесь просто нельзя.
Reverse proxy — возможности
Какие возможности предоставляют решения работающие через reverse proxy со сменой А-записей?
Reverse proxy — ограничения
У данной технологии есть ряд подводных камней, о которых не очень-то принято говорить. К ее ограничениям можно отнести:
Недостатки решений по защите от DDoS-атак на базе “классической” Reverse Proxy начинают ощущаться, по мере того как растущий проект упирается во все большее число ограничений технологии. Какие технические решения способны нивелировать или значительно снизить риски недоступности сайта из-за перечисленных недостатков? — читайте ниже.
Перерастая reverse proxy
Давайте рассмотрим проблему на реальном примере из нашей практики. В прошлом году к нам обратился крупный клиент, с конкретным списком требований к услугам по защите. Мы не можем раскрыть название компании по понятным причинам, а вот потребности клиента — пожалуйста:
Услуги вроде защищенного хостинга, виртуальных и выделенных серверов позволяют защититься от атак на уровнях L3-L7 OSI, но требуют переезда и означают использование единственного провайдера защиты. Что делать?
Защита от DDoS внутри сети с защищаемыми сервисами
Установка фильтрующего оборудования в своей сети позволяет защитить сервисы на уровнях L3-L7 OSI и свободно управлять правилами фильтрации. Вы несете существенные капитальные (CaPex) и операционные расходы (OpEx), выбирая такое решение. Это расходы на:
Даже для крупных компаний, такое решение часто является экономически нецелесообразным, не говоря о среднем и малом бизнесе. Нашему клиенту оно также не подошло.
Проксирование без смены А-записей.
Чтобы удовлетворить потребности таких клиентов, мы разработали технологию перехвата веб-трафика и реализовали ее в рамках услуги удаленной защиты без смены А-записей. В основе решения лежит принцип: Все соединения между АС клиента и публичными сетями должны быть защищены. Клиент передает нам анонсы своих IP адресов/сетей по BGP, а мы анонсируем их в Интернет.
Весь трафик, предназначенный защищаемым ресурсам, проходит через нашу сеть. Клиент может оставить несколько резервных подключений и использовать их в случае непредвиденных обстоятельств, сняв анонсы с сети DDoS-GUARD. В штатном режиме мы советуем использовать только наши подключения для выхода в сеть Интренет, чтобы мы могли гарантировать защиту клиентских сервисов.
На схеме ниже показано, как организована обработка трафика в нашей сети на примере веб-трафика.
Заключение
Теперь давайте проверим удовлетворяет ли разработанное DDoS-GUARD решение списку требований из раздела «Перерастая reverse proxy».
Общие рекомендации по организации защиты вашего проекта: