Назад | Перейти на главную страницу

Обратный прокси - это должен быть другой стек технологий?

Получил скептический вопрос о настройке обратного прокси, которую я рассматриваю.

В настоящее время у меня есть пара серверов приложений с балансировкой нагрузки в DMZ (S1, S2 на рисунке ниже). Они принимают входящие запросы от внешних клиентов. Они также подключаются к внутренним сетевым ресурсам (например, к серверу БД, брокеру сообщений)

Настройка DMZ довольно стандартна: два межсетевых экрана - внутренний и внешний. Внешний брандмауэр разрешает только внешние запросы к определенным ресурсам сервера на определенных портах. Брандмауэр, обращенный к внутренней стороне, позволяет серверам DMZ только открывать указанные подключения к внутренним сетевым ресурсам (например, серверу БД, брокеру сообщений)

Теперь у меня есть архитектурное предложение, в котором говорится, что эта установка небезопасна. Предложение призывает к перемещению двух серверов DMZ во внутреннюю сеть. В DMZ они будут заменены сервером «обратного прокси» («RP» на рисунке ниже). RP принимает входящие запросы и передает их S1 / S2. Ключевым моментом здесь являются внутренние серверы. положить начало сетевое подключение к «обратному прокси-серверу» в DMZ.

Итак, это:

 [EXTERNAL]       [DMZ]        [INTERNAL]

 Client -->  ||    S1/S2    || --> DB,MQ

... заменяется этим:

 [EXTERNAL]       [DMZ]        [INTERNAL]

 Client -->  ||      RP     || <-- S1/S2 --> DB,MQ

RP по сути является урезанной версией S1 / S2 (тот же стек технологий). Он передает внешний запрос на S1 / S2 через постоянное соединение, инициированное S1 / S2.

Мой вопрос: Учитывая, что технологический стек для RP идентичен S1 / S2 (та же технология, меньше кода) - как новая установка обеспечивает значительную дополнительную защиту?

Не дойдут ли атаки приложений до S1 / S2 без помех? В частности, если вы поставите под угрозу RP, вы также можете скомпрометировать S1 / S2. Не ухудшит ли это профиль риска (поскольку S1 / S2 теперь находятся во внутренней сети)?


Добавляем некоторую информацию и расширяем пункт выше:

  1. Балансировщик нагрузки (LB) в этой настройке по существу прозрачен (т.е. RP не является LB). По разным причинам LB не может каким-либо образом прерывать входящие запросы.

  2. Лично я очень скептически относится к безопасности RP добавляет. Мое рассуждение: если RP каким-то образом полностью скомпрометирован (например, переполнение буфера / шелл-код), его легко проехать через соединение с S1 / S2 во внутренней сети (не имеет значения, кто инициирует соединение - он там), а затем аналогичный эксплойт на S1 / S2 (благодаря аналогичной технологии). Теперь проблема усугубляется, потому что скомпрометированные S1 / S2 теперь находятся в уязвимом месте (то есть во внутренней сети), а не в DMZ.

Во-первых, большинство балансировщиков нагрузки работают как обратные прокси. википедия f5 devcentral. Однако существуют различия в защите, связанные с архитектурой балансировщиков нагрузки (или обратных прокси). Примечание: в дальнейшем я буду использовать термины «балансировщики нагрузки» (LB) и «обратный прокси» (RP) как взаимозаменяемые.

LB обеспечивает дополнительную безопасность, выступая в качестве посредника для всех коммуникаций. Большинство LB корпоративного уровня действуют как прокси уровня 7. Для веб-трафика клиентский HTTP-сеанс полностью завершается на LB, и LB повторно устанавливает HTTP-соединение на стороне сервера с сервером. При принудительном завершении уровня 7 (l7) вся полезная нагрузка может быть просмотрена, очищена и отправлена ​​обратно на сервер в чистом виде и оптимизирована. Во многих случаях LB также реализует брандмауэр веб-приложений в качестве дополнительного модуля для дальнейшей проверки трафика на наличие аномальных шаблонов перед отправкой трафика обратно на веб-сервер.

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

Возвращаясь к вашей модели, если RP = LB, то с точки зрения архитектуры предлагаемая архитектура добавляет дополнительную сложность, чем текущая модель. Однако главное здесь в предлагаемой модели: S1 / S2 инициирует исходящее соединение с DMZ. Злоумышленник может скомпрометировать RP, но не сможет установить новый сеанс обратно на S1 / S2 или во внутреннюю сеть. Однако, если в S1 / S2 или DB, MQ есть слабые места приложения, злоумышленник может предвидеть туннель обратно в сеть для доступа к S1 / S2. Кроме того, поскольку «RP» использует тот же стек технологий, что и S1 / S2, любая слабость в S1 / S2, вероятно, будет существовать и в «RP». Однако, если «RP» невозможно взломать, то предлагаемая модель повышает уровень безопасности, так как сетевые стеки S1 / S2 защищены, и атака должна сначала быть нацелена на стек приложения.

Хотя можно утверждать, что значение безопасности, которое эта модель добавляет (если злоумышленник нарушает dmz / int fw, у него есть открытый доступ к интрасети, и эта модель не защищает от обычной атаки с подводной рыбалкой), такая модель может быть более приемлемой для парень комплаенс, чем нет. Это особенно актуально для соответствия требованиям PCI, где любая система, имеющая доступ к среде CHD, также входит в сферу действия. В приведенном выше случае вся DMZ может входить в область действия, но если вы установите исходящее соединение из среды CHD, то в область будет добавлен только «RP». Хотя я не имею в виду, что это так, я видел, как архитекторы подходили к сокращению объема PCI таким образом.

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

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

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