У меня есть Firewall, LoadBalancer (балансировщик нагрузки IIS-ARR) и 2 веб-сервера IIS. 2 веб-сервера IIS будут в локальной сети с частными IP-адресами. Мой веб-сайт размещен на обоих веб-серверах. Моя реальная проблема в том, что у меня есть платежный шлюз на моем веб-сайте, и он будет работать так, как ожидается, только если запрос поступит на веб-сайт с имени веб-сайта (например,www.abc.com) или публичный статический IP-адрес, настроенный для балансировщика нагрузки IIS-ARR.
У меня 4 вопроса:
Когда http-запрос обрабатывается любым из 2 веб-серверов, запрос будет приходить с имени веб-сайта/публичного статического IP, назначенного балансировщику нагрузки. Или это будет частный IP веб-сервера.
Подвержена ли разгрузка SSL на балансировщике нагрузки IIS-ARR каким-либо атакам, поскольку http-запрос передается от балансировщика нагрузки к реальному серверу в открытом виде в локальной сети?
Где создать запрос SSL CSR для моего сайта. На сервере IIS-ARR или любом из двух WebServers. Сколько SSL-сертификатов требуется.
Как сохранить https (SSL) на протяжении всего запроса. От клиентского браузера до брандмауэра, затем балансировщика нагрузки, затем реального сервера. (Без SSL-разгрузки)
решение1
1. Клиент будет ожидать ответа из того же сеанса SSL, который, как он полагает, был инициирован с внешнего адреса брандмауэра.
Клиент не знает, передает ли брандмауэр поток tcp на другое устройство, например, балансировщик нагрузки ssl, завершающий сеанс. Он также не знает, передает ли балансировщик нагрузки завершенный сеанс ssl на внутренний сервер бэкэнда (независимо от того, передает ли балансировщик нагрузки данные на сервер бэкэнда в повторно зашифрованном https или незашифрованном http виде). Клиент просто знает, что он каким-то образом установил сеанс ssl с IP-адресом, который является внешним IP-адресом брандмауэра.
Через слои брандмауэра, балансировщика нагрузки и ssl-терминации запрос проходит весь путь до бэкенд-сервера. Однако, пока бэкенд готовит ответ, если бэкенд-сервер смотрит на IP-адрес отправителя и видит там внешний IP-адрес клиента, он ответит напрямую на IP-адрес клиента. Ответ, отправленный напрямую с бэкенда клиенту, будет получен вне сеанса ssl, который клиент инициировал и через который отправил запрос. Клиент, естественно, не ожидает такого ответа и отклонит его.
Таким образом, чтобы гарантировать, что ответ поступит через инициированный клиентом сеанс SSL, балансировщик нагрузки должен настроить запрос перед его передачей на внутренний сервер.
Сначала он расшифровывает сеанс SSL клиента, затем изменяет исходный запрос таким образом, чтобы исходный IP-адрес был перезаписан исходным IP-адресом, принадлежащим балансировщику нагрузки, перед отправкой запроса на внутренний сервер.
Теперь внутренний сервер считает, что запрос поступил от балансировщика нагрузки, и отправляет свой ответ балансировщику нагрузки, а не исходному клиенту.
Балансировщик нагрузки снова изменяет данные, так что ответ кажется пришедшим от балансировщика нагрузки, а не от внутреннего сервера. После этого балансировщик нагрузки шифрует данные, чтобы они находились в том же сеансе ssl, который он установил с клиентом, и продолжает отправлять ответ напрямую клиенту.
Клиент с радостью принимает это и не обращает внимания на реальные сетевые пути, используемые для получения ответа.
Эти изменения IP, выполняемые балансировщиком нагрузки, называютсяИсточник NAT(SNAT) и являются общими для всех балансировщиков нагрузки, с которыми я когда-либо работал.
Для краткости я не включилтрансляции межсетевого экрана между публичными и частными адресными пространствами. Я предлагаю полностью разделить этот вопрос, чтобы не путать перезапись, выполняемую брандмауэром, с перезаписью, выполняемой балансировщиком нагрузки. Это, поскольку перезапись брандмауэра может быть выполнена несколькими способами и заслуживает своего собственного вопроса, как только выбор бренда брандмауэра будет определен или сужен. До тех пор думайте об этом как о магии, которая просто происходит в брандмауэре, когда каждый входящий или исходящий пакет проходит через него.
Простым способом проверки правильности настройки, описанной выше, будет начать с использования внутреннего клиента и настройки незашифрованных http-сеансов между клиентом и балансировщиком нагрузки, а также между балансировщиком нагрузки и внутренним сервером(ами).
Использование анализатора пакетов, напримерWiresharkна клиенте, балансировщике нагрузки и бэкэнде можно затем увидеть эффект этих переписываний на практике для любой заданной пары запрос/ответ и для каждой из частей сети.
Как только настройка заработает и процесс будет понятен, можно сначала зашифровать путь от клиента к балансировщику нагрузки, а затем путь от балансировщика нагрузки к бэкенду. Это как предложение для облегчения кривой обучения и содействия правильной окончательной конфигурации.
Одно предостережение касается восприятия запросов внутренним сервером.
Независимо от фактического количества внешних клиентов, бэкэнд будет видеть и регистрировать только одного клиента: SNAT-адрес внутреннего балансировщика нагрузки.
Эта дилемма возникает, когда балансировщик нагрузки SNAT запросы, и решается, когда балансировщик нагрузки информирует бэкэнд-сервер о фактическом внешнем IP-адресе клиента. Поскольку сам исходный IP-адрес запроса изменяется, информация о реальном IP-адресе клиента вместо этого передается бэкэнду путем вставки http-заголовка в http-запрос.
Заголовок может иметь любое допустимое имя, которое еще не используется. Распространенный выбор:X-ПЕРЕСЫЛАН-ДЛЯ.
Настройка балансировщика нагрузки для вставки такого заголовка является первым требованием для работы этого исправления, второе требование — информирование бэкенд-сервера о наличии этого заголовка. Конфигурация специфична для брендов балансировщика нагрузки и бэкенд-сервера, что легко гуглится.Здесьнапример, как настроить бэкэнд tomcat для ведения журнала из x-forwarded-for. Прошло много времени с тех пор, как я последний раз настраивал ARR, и не могу вспомнить по памяти, как был добавлен x-forwarded-for, но припоминаю, что потребовалось некоторое время для экспериментов и немного гугления, чтобы добиться работы.
2) Да, поскольку трафик может быть перехвачен декодером протоколов, таким как Wireshark, как предполагалось выше, вектор атаки существует.
Это предполагает, что злоумышленник имеет доступ к сетевому трафику.
Если трафик от балансировщика нагрузки к бэкэнду отправляется в открытом виде, устранение неполадок, связанных с неправильной настройкой балансировщика нагрузки или бэкэнд-сервера, упрощается, но несет в себе вышеупомянутый риск.
То, как сделать этот выбор дизайна, — это предмет достойного обсуждения как внутри компании, так и с любыми внешними заинтересованными сторонами.
3) CSR обычно создается там, где заканчивается SSL.
Чтобы зашифровать трафик от клиента к балансировщику нагрузки, создайте запрос csr на балансировщике нагрузки.
Чтобы зашифровать трафик от балансировщика нагрузки к бэкэнд-серверу, создайте csr на бэкэнд-сервере.
Существуют способы экспорта как подписанного сертификата, так и соответствующего закрытого ключа в виде пакета, который можно импортировать на другой сервер. Это полезно для настройки кластера балансировщика нагрузки, где все члены должны представлять один и тот же сертификат, или для настройки нескольких идентичных бэкэндов для упрощения конфигурации ssl клиента балансировщика нагрузки (то есть, когда балансировщик нагрузки функционирует как ssl-клиент для бэкэнд-сервера, поскольку он повторно шифрует данные http).
4) Решите, где следует выполнить терминацию клиентского SSL.
В некоторых брандмауэрах можно завершить SSL, но более распространенным способом является простое перенаправление потока TCP через брандмауэр на балансировщик нагрузки, который затем завершает сеанс SSL клиента.
Также возможно, чтобы балансировщик нагрузки балансировал чистые потоки tcp, на которых сервер backend завершает ssl. Это необычно, и я не буду рассматривать этот вариант здесь.
После завершения первоначального ssl решите, следует ли повторно зашифровать данные, например, между балансировщиком нагрузки и следующим переходом. Следующий переход может быть внутренним сервером или другим балансировщиком нагрузки или...
Повторяйте до тех пор, пока данные не будут отправлены в открытом виде или пока вы не достигнете последнего сервера в цепочке.
Прерывание SSL является требованием для балансировщика нагрузки, чтобы иметь возможность, например, вставить заголовок http x-forwarded-for или выполнить другие действия, требующие доступа к открытым текстовым данным. Поэтому обычно прерывают SSL перед балансировщиком нагрузки, или на балансировщике нагрузки, или и то, и другое.
Также распространено как отправлять трафик на бэкэнды зашифрованным, так и отправлять его незашифрованным. Это просто зависит от обстоятельств организации и цели отправляемых данных.
SSL-разгрузка— это всего лишь термин, описывающий процесс, в котором одна часть технологии выполняет шифрование/дешифрование SSL вместо другой части технологии.
Это может быть балансировщик нагрузки, расшифровывающий SSL и передающий открытый текст на бэкэнд — бэкэнд был разгружен с помощью SSL.
Это может быть балансировщик нагрузки, имеющий специализированные аппаратные схемы, предназначенные для шифрования/дешифрования SSL - ЦП балансировщика нагрузки был разгружен SSL. И так далее...