stringtranslate.com

Обратный прокси

Прокси-сервер, соединяющий Интернет с внутренней сетью.
Пример сценария: Клиент в Интернете ( облако слева ) делает запрос обратному прокси- серверу ( красный овал посередине ). Прокси-сервер проверяет запрос, определяет, что он действителен и что в его собственном кэше нет запрошенного ресурса. Затем он пересылает запрос на какой-то внутренний веб-сервер ( овал справа ). Внутренний сервер доставляет запрошенный ресурс обратно прокси-серверу, который, в свою очередь, доставляет его клиенту. Клиент в Интернете не знает о внутренней сети и не может сказать, общается ли он с прокси-сервером или напрямую с веб-сервером.

В компьютерных сетях обратный прокси-сервер или суррогатный сервер — это прокси-сервер , который для любого клиента выглядит как обычный веб-сервер , но на самом деле действует просто как посредник, который пересылает запросы клиента на один или несколько обычных веб-серверов. [1] [2] Обратные прокси-серверы помогают повысить масштабируемость, производительность, устойчивость и безопасность, но они также несут в себе ряд рисков.

Компании, которые управляют веб-серверами, часто устанавливают обратные прокси-серверы для облегчения связи между браузером пользователя Интернета и веб-серверами . Важным преимуществом этого является то, что веб-серверы могут быть скрыты за брандмауэром во внутренней сети компании, и только обратный прокси-сервер должен быть напрямую открыт для Интернета. Обратные прокси-серверы реализованы в популярных веб-серверах с открытым исходным кодом , таких как Apache , Nginx и Caddy . Выделенные обратные прокси-серверы, такие как программное обеспечение с открытым исходным кодом HAProxy и Squid , используются некоторыми из крупнейших веб-сайтов в Интернете.

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

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

Использует

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

Обратные прокси-серверы могут проверять заголовки HTTP , что, например, позволяет им представлять один IP-адрес в Интернете, одновременно перенаправляя запросы на различные внутренние серверы на основе URL-адреса HTTP-запроса.

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

Функции брандмауэра приложений могут защищать от распространенных веб-атак, таких как атака типа «отказ в обслуживании» (DoS) или распределенная атака типа «отказ в обслуживании» (DDoS). Без обратного прокси-сервера удаление вредоносного ПО или инициирование демонтажа (одновременно отражая атаку) на собственном сайте, например, может быть затруднено.

В случае защищенных веб-сайтов веб-сервер может не выполнять шифрование TLS самостоятельно, а вместо этого перекладывать задачу на обратный прокси-сервер, который может быть оснащен аппаратным обеспечением для ускорения TLS . (См. Прокси-сервер завершения TLS .)

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

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

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

В технике, называемой "кормление с ложки", [4] динамически сгенерированная страница может быть создана целиком и передана обратному прокси-серверу, который затем может вернуть ее клиенту понемногу за раз. Программа, которая генерирует страницу, не должна оставаться открытой, тем самым освобождая ресурсы сервера в течение возможного продленного времени, необходимого клиенту для завершения передачи.

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

Обратные прокси-серверы могут выполнять A/B-тестирование и многовариантное тестирование, не требуя от кода приложения обработки логики того, какая версия передается клиенту.

Обратный прокси-сервер может добавить аутентификацию доступа к веб-серверу, на котором нет никакой аутентификации. [5] [6]

Риски

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

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

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

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

Использование обратного прокси-сервера третьей стороны (например, Cloudflare , Imperva ) передает всю триаду конфиденциальности, целостности и доступности в руки третьей стороны, которая управляет прокси-сервером.

Если обратный прокси-сервер обслуживает множество различных доменов , его сбой (например, из-за неправильной конфигурации или DDoS-атаки) может привести к отключению всех подключенных доменов. [7]

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

Смотрите также

Ссылки

  1. ^ "Прямые и обратные прокси". Apache Software Foundation. Архивировано из оригинала 28 августа 2018 года . Получено 26 августа 2018 года .
  2. ^ Риз, Уилл (сентябрь 2008 г.). «Nginx: высокопроизводительный веб-сервер и обратный прокси». Linux Journal (173).
  3. ^ "Прокси-серверы и туннелирование". MDN Web Docs . Архивировано из оригинала 26 ноября 2020 г. Получено 6 декабря 2020 г.
  4. ^ "squid-cache wiki entry on "SpoonFeeding"". Франческо Чемолли. Архивировано из оригинала 25 января 2019 года . Получено 9 февраля 2011 года .
  5. ^ "Возможно ли добавить базовую аутентификацию доступа HTTP через HAProxy?". serverfault.com . Архивировано из оригинала 4 октября 2018 г. . Получено 27 апреля 2016 г. .
  6. ^ "forward_auth (директива Caddyfile) - Документация Caddy". caddyserver.com . Получено 22 мая 2022 г. .
  7. ^ "Сбой Cloudflare выводит из строя основные сайты и сервисы, включая Discord". finance.yahoo.com . Архивировано из оригинала 22 июня 2020 г. . Получено 14 декабря 2020 г. .