Пример сценария: клиент в Интернете ( облако слева ) отправляет запрос на обратный прокси- сервер ( красный овал посередине ). Прокси проверяет запрос, определяет, что он действителен и не имеет запрошенного ресурса в собственном кэше. Затем он перенаправляет запрос на какой-то внутренний веб-сервер ( овал справа ). Внутренний сервер доставляет запрошенный ресурс обратно прокси-серверу, который, в свою очередь, доставляет его клиенту. Клиент в Интернете не знает о внутренней сети и не может определить, общается ли он с прокси-сервером или напрямую с веб-сервером.
В компьютерных сетях обратный прокси-сервер — это приложение, которое находится перед внутренними серверами и перенаправляет запросы клиентов (например, браузера) на эти серверы вместо того, чтобы клиент напрямую обращался к серверам. Обратные прокси помогают повысить масштабируемость, производительность, отказоустойчивость и безопасность. Ресурсы, возвращаемые клиенту, выглядят так, как если бы они были получены с самого веб-сервера. [1]
Крупные веб-сайты и сети доставки контента используют обратные прокси-серверы вместе с другими методами для балансировки нагрузки между внутренними серверами. Обратные прокси могут хранить кеш статического контента, что еще больше снижает нагрузку на эти внутренние серверы и внутреннюю сеть. Обратные прокси-серверы также часто добавляют такие функции, как сжатие или шифрование TLS, в канал связи между клиентом и обратным прокси-сервером. [2]
Обратные прокси-серверы обычно принадлежат веб-службе или управляются ею , и к ним имеют доступ клиенты из общедоступного Интернета. Напротив, прямой прокси-сервер обычно управляется клиентом (или его компанией), который ограничен частной внутренней сетью, за исключением того, что клиент может попросить прямой прокси получить ресурсы из общедоступного Интернета от имени клиента.
Обратные прокси-серверы реализованы в популярных веб-серверах с открытым исходным кодом , таких как Apache , Nginx и Caddy . Это программное обеспечение может проверять заголовки HTTP, что, например, позволяет ему представлять один IP-адрес в Интернете, одновременно передавая запросы на различные внутренние серверы на основе URL-адреса HTTP-запроса. Выделенные обратные прокси-серверы, такие как программное обеспечение с открытым исходным кодом HAProxy и Squid , используются некоторыми из крупнейших веб-сайтов в Интернете.
Использование
Обратные прокси могут скрыть существование и характеристики исходных серверов . Это может затруднить определение фактического местоположения исходного сервера/веб-сайта и, например, усложнить инициирование судебных исков, таких как удаление или блокирование доступа к веб-сайту, поскольку IP-адрес веб-сайта может быть не сразу очевиден. . Кроме того, обратный прокси-сервер может находиться в другой юрисдикции с другими юридическими требованиями, что еще больше усложняет процесс удаления.
Функции брандмауэра приложений могут защитить от распространенных веб-атак, таких как атака типа «отказ в обслуживании» (DoS) или распределенные атаки «отказ в обслуживании» (DDoS). Например , без обратного прокси-сервера удаление вредоносного ПО или инициирование удаления вредоносного ПО (одновременно противодействуя атаке) на собственном сайте может оказаться затруднительным.
Обратный прокси может распределять нагрузку от входящих запросов на несколько серверов, при этом каждый сервер поддерживает свою прикладную область. В случае веб-серверов с обратным проксированием обратному прокси-серверу, возможно, придется перезаписать URL-адрес в каждом входящем запросе, чтобы он соответствовал соответствующему внутреннему местоположению запрошенного ресурса.
Обратный прокси-сервер может снизить нагрузку на свои исходные серверы за счет кэширования статического и динамического контента , известного как веб-ускорение . Прокси-кеши такого типа часто могут удовлетворить значительное количество запросов веб-сайта, что значительно снижает нагрузку на исходный сервер(ы).
Обратный прокси-сервер может оптимизировать контент, сжимая его, чтобы ускорить загрузку.
С помощью метода, называемого «кормление с ложки» [3] , динамически генерируемая страница может быть создана целиком и передана обратному прокси-серверу, который затем может возвращать ее клиенту понемногу. Программа, генерирующая страницу, не должна оставаться открытой, что освобождает ресурсы сервера в течение возможного длительного времени, необходимого клиенту для завершения передачи.
Обратные прокси-серверы могут работать везде, где несколько веб-серверов должны быть доступны через один общедоступный IP-адрес. Веб-серверы прослушивают разные порты на одной машине с одним и тем же локальным IP-адресом или, возможно, на разных машинах с разными локальными IP-адресами. Обратный прокси-сервер анализирует каждый входящий запрос и доставляет его на нужный сервер в локальной сети .
Обратный прокси-сервер может добавить аутентификацию доступа к веб-серверу, который не имеет никакой аутентификации. [4] [5]
Риски
Обратный прокси-сервер может отслеживать все IP-адреса, отправляющие через него запросы, а также читать и изменять любой незашифрованный трафик. Таким образом, он может регистрировать пароли или внедрять вредоносное ПО, а также может сделать это в случае взлома или запуска злоумышленником.
Когда транзитный трафик зашифрован и обратному прокси-серверу необходимо фильтровать/кэшировать/сжимать или иным образом изменять или улучшать трафик, прокси-сервер сначала должен расшифровать и повторно зашифровать сообщения. Для этого требуется, чтобы прокси-сервер имел сертификат TLS и соответствующий ему закрытый ключ, что увеличивает количество систем, которые могут иметь доступ к незашифрованным данным, и делает их более ценной целью для злоумышленников.
Подавляющее большинство утечек внешних данных происходит либо тогда, когда хакерам удается злоупотребить существующим обратным прокси-сервером, который был намеренно развернут организацией, либо когда хакерам удается преобразовать существующий сервер с выходом в Интернет в обратный прокси-сервер. Скомпрометированные или преобразованные системы позволяют внешним злоумышленникам указать, куда они хотят перенаправить свои атаки, обеспечивая им доступ к внутренним сетям и системам.
Приложения, разработанные для внутреннего использования компании, обычно не соответствуют общедоступным стандартам и не обязательно предназначены для противостояния всем попыткам взлома. Когда организация разрешает внешний доступ к таким внутренним приложениям через обратный прокси-сервер, она может непреднамеренно увеличить свою поверхность атаки и пригласить хакеров.
Если обратный прокси-сервер не настроен для фильтрации атак или не получает ежедневных обновлений для поддержания своей базы данных сигнатур атак в актуальном состоянии, уязвимость нулевого дня может пройти незафильтрованной, что позволит злоумышленникам получить контроль над системами, которые за обратным прокси-сервером.
Если обратный прокси-сервер обслуживает множество разных доменов, его сбой (например, из-за неправильной настройки или DDoS-атаки) может вывести из строя все фронтальные домены. [6]
Обратные прокси-серверы также могут стать единой точкой отказа, если нет другого способа доступа к внутреннему серверу.
^ «Прямые и обратные прокси» . Фонд программного обеспечения Apache. Архивировано из оригинала 28 августа 2018 года . Проверено 26 августа 2018 г.
^ «Прокси-серверы и туннелирование». Веб-документы MDN . Архивировано из оригинала 26 ноября 2020 года . Проверено 6 декабря 2020 г.
^ "Запись в вики-кэше squid-cache о "SpoonFeeding"" . Франческо Чемолли. Архивировано из оригинала 25 января 2019 года . Проверено 9 февраля 2011 г.
^ «Можно ли добавить базовую аутентификацию доступа HTTP через HAProxy?». serverfault.com . Архивировано из оригинала 4 октября 2018 года . Проверено 27 апреля 2016 г.
^ Сервер, Caddy Web. «forward_auth (директива Caddyfile) — Документация Caddy». caddyserver.com . Проверено 22 мая 2022 г.
^ «Отключение Cloudflare выводит из строя основные сайты и сервисы, включая Discord» . финансы.yahoo.com . Архивировано из оригинала 22 июня 2020 года . Проверено 14 декабря 2020 г.
