HTTP-Anforderung nach Passieren der Firewall und des Loadbalancers

Question

Ich habe eine Firewall, dann einen LoadBalancer (IIS-ARR Load Balancer) und 2 IIS-Webserver. Die 2 IIS-Webserver befinden sich im LAN mit privaten IPs. Meine Website wird auf beiden Webservern gehostet. Meine eigentliche Herausforderung besteht darin, dass ich auf meiner Website ein Zahlungsgateway habe, und es funktioniert nur dann wie erwartet, wenn die Anfrage vom Websitenamen an die Website kommt (wiewww.abc.com) oder öffentliche statische IP, konfiguriert für den IIS-ARR-Load Balancer.

Ich habe 4 Fragen:

1. Wenn eine HTTP-Anfrage von einem der beiden Webserver bearbeitet wird, kommt die Anfrage dann vom Websitenamen/der öffentlichen statischen IP, die dem Load Balancer zugewiesen ist? Oder es wird die private IP des Webservers sein.

2. Ist das SSL-Offloading beim IIS-ARR-Load Balancer anfällig für Angriffe, da die HTTP-Anforderung im Klartext vom Load Balancer zum realen Server im LAN fließt?

3. Wo erstelle ich eine SSL-CSR-Anforderung für meine Website? Auf einem IIS-ARR-Server oder einem von zwei Webservern. Wie viele SSL-Zertifikate werden benötigt?

4. So behalten Sie https (SSL) während der gesamten Anfrage bei. Vom Client-Browser zur Firewall, dann zum Load Balancer und dann zum echten Server. (Ohne SSL-Offloading)

Answer 1

1. Der Client erwartet, dass die Antwort aus derselben SSL-Sitzung kommt wie die, die er seiner Meinung nach mit der externen Firewall-Adresse initiiert hat.

Der Client weiß nicht, ob die Firewall den TCP-Stream an ein anderes Gerät weiterleitet, beispielsweise einen SSL-terminierenden Load Balancer. Er weiß auch nicht, ob der Load Balancer die beendete SSL-Sitzung an einen internen Backend-Server weiterleitet (unabhängig davon, ob der Load Balancer die Daten in erneut verschlüsseltem HTTPS- oder unverschlüsseltem HTTP-Format an den Backend-Server weiterleitet). Der Client weiß lediglich, dass er irgendwie eine SSL-Sitzung mit einer IP-Adresse aufgebaut hat, die zufällig die externe IP einer Firewall ist.

Durch die Schichten von Firewall, Lastenausgleich und SSL-Terminierungen gelangt die Anfrage bis zu einem Backend-Server. Wenn das Backend jedoch die Antwort vorbereitet und der Backend-Server die IP-Adresse des Absenders betrachtet und dort die externe IP-Adresse des Clients sieht, antwortet er direkt an die IP-Adresse des Clients. Eine direkt vom Backend an den Client gesendete Antwort würde außerhalb der SSL-Sitzung empfangen werden, die der Client initiiert und über die er die Anfrage gesendet hat. Der Client erwartet eine solche Antwort natürlich nicht und wird sie ablehnen.

Um sicherzustellen, dass die Antwort über die vom Client initiierte SSL-Sitzung eintrifft, muss der Load Balancer die Anfrage optimieren, bevor er sie an den Backend-Server weiterleitet.

Es entschlüsselt zuerst die SSL-Sitzung des Clients und ändert dann die ursprüngliche Anforderung, sodass die Quell-IP-Adresse mit einer Quell-IP-Adresse überschrieben wird, die zum Load Balancer gehört, bevor die Anforderung an den Backend-Server gesendet wird.

Der Backend-Server geht nun davon aus, dass die Anforderung vom Load Balancer stammt, und sendet seine Antwort an den Load Balancer statt an den ursprünglichen Client.

Der Load Balancer ändert die Daten erneut, sodass die Antwort scheinbar vom Load Balancer und nicht vom Backend-Server kommt. Anschließend verschlüsselt der Load Balancer die Daten, sodass sie in derselben SSL-Sitzung liegen, die er mit dem Client eingerichtet hat, und sendet die Antwort direkt an den Client.

Der Client akzeptiert dies gerne und ist sich der tatsächlichen Netzwerkpfade, die zur Erstellung der Antwort verwendet werden, nicht bewusst.

Diese IP-Änderungen, die der Load Balancer vornimmt, nennt manQuell-NAT(SNAT) und sind allen Load Balancern gemeinsam, mit denen ich je gearbeitet habe.

Der Kürze halber habe ich nicht aufgenommendie Firewall-Übersetzungen zwischen öffentlichen und privaten Adressräumen. Ich schlage vor, diese Frage vollständig zu trennen, um das Umschreiben durch die Firewall nicht mit dem Umschreiben durch den Lastenausgleich zu verwechseln. Das Umschreiben der Firewall kann auf verschiedene Weise erfolgen und verdient eine eigene Frage, sobald die Wahl der Firewall-Marke entschieden oder eingegrenzt wurde. Bis dahin betrachten Sie es als Magie, die einfach in der Firewall passiert, wenn jedes eingehende oder ausgehende Paket sie durchläuft.

Eine einfache Möglichkeit zum Überprüfen einer korrekten Einrichtung wie oben beschrieben besteht darin, zunächst einen internen Client zu verwenden und unverschlüsselte HTTP-Sitzungen zwischen Client und Load Balancer sowie zwischen Load Balancer und Backend-Server(n) zu konfigurieren.

Mit einem Paket-Sniffer wieWiresharkAuf dem Client, dem Load Balancer und dem Backend kann man dann die Auswirkungen dieser Umschreibungen in der Praxis für jedes beliebige Anfrage-/Antwortpaar und für jeden der Netzwerkteile sehen.

Sobald das Setup funktioniert und der Prozess verstanden ist, kann man zuerst den Pfad vom Client zum Load Balancer und dann den Pfad vom Load Balancer zum Backend verschlüsseln. Dies ist ein Vorschlag, um die Lernkurve zu erleichtern und eine korrekte Endkonfiguration zu fördern.

Eine Einschränkung besteht in der Wahrnehmung der Anfragen durch den Backend-Server.

Unabhängig von der tatsächlichen Anzahl externer Clients sieht und protokolliert das Backend nur einen Client: die SNAT-Adresse des internen Load Balancers.

Dieses Dilemma entsteht dadurch, dass der Load Balancer die Anfragen per SNAT verarbeitet, und wird dadurch gelöst, dass der Load Balancer den Backend-Server über die tatsächliche externe IP-Adresse des Clients informiert. Da die Quell-IP der Anfrage selbst geändert wird, werden die Informationen zur tatsächlichen Client-IP-Adresse stattdessen an das Backend weitergegeben, indem ein HTTP-Header in die HTTP-Anfrage eingefügt wird.

Der Header kann jeden gültigen Namen haben, der noch nicht verwendet wird. Eine häufige Auswahl istX-WEITERGELEITET FÜR.

Damit dieser Fix funktioniert, muss der Load Balancer so konfiguriert werden, dass er einen solchen Header einfügt. Die zweite Voraussetzung ist, den Backend-Server über das Vorhandensein dieses Headers zu informieren. Die Konfiguration ist spezifisch für die Marken des Load Balancers und des Backend-Servers und lässt sich leicht googeln.Hierist beispielsweise, wie man ein Tomcat-Backend so konfiguriert, dass es von x-forwarded-for loggt. Es ist lange her, seit ich zuletzt ein ARR konfiguriert habe, und ich kann mich nicht erinnern, wie x-forwarded-for hinzugefügt wurde, aber ich erinnere mich, dass es einige Experimente und ein bisschen Googeln erforderte, bis es funktionierte.

2) Ja, da der Datenverkehr wie oben vorgeschlagen von einem Protokolldecoder wie Wireshark abgehört werden kann, gibt es einen Angriffsvektor.

Dies setzt voraus, dass ein Angreifer Zugriff auf den Netzwerkverkehr hat.

Wenn der Datenverkehr vom Load Balancer zum Backend im Klartext gesendet wird, ist die Fehlerbehebung bei Fehlkonfigurationen des Load Balancers oder des Backend-Servers einfacher, birgt jedoch das oben genannte Risiko.

Die Frage, wie diese Designentscheidung getroffen wird, ist eine lohnende Diskussion, die sowohl intern als auch mit allen externen Beteiligten geführt werden sollte.

3) Die CSR wird üblicherweise dort durchgeführt, wo SSL beendet wird.

Um den Datenverkehr vom Client zum Load Balancer zu verschlüsseln, erstellen Sie die CSR-Anforderung im Load Balancer.

Um den Datenverkehr vom Load Balancer zum Backend zu verschlüsseln, erstellen Sie die CSR auf dem Backend-Server.

Es gibt Möglichkeiten, sowohl ein signiertes Zertifikat als auch einen entsprechenden privaten Schlüssel als Paket zu exportieren, das auf einem anderen Server importiert werden kann. Dies ist nützlich, um einen Load Balancer-Cluster zu konfigurieren, bei dem alle Mitglieder dasselbe Zertifikat vorlegen sollen, oder um mehrere identische Backends zu konfigurieren, um die SSL-Konfiguration des Load Balancer-Clients zu vereinfachen (d. h. wenn der Load Balancer als SSL-Client für den Backend-Server fungiert, während er die HTTP-Daten neu verschlüsselt).

4) Entscheiden Sie, wo die Client-SSL-Terminierung erfolgen soll.

In einigen Firewalls ist es möglich, SSL zu beenden. Üblicher ist jedoch, den TCP-Stream einfach durch die Firewall an den Load Balancer weiterzuleiten, der dann die SSL-Sitzung des Clients beendet.

Es ist auch möglich, den Load Balancer reine TCP-Streams ausgleichen zu lassen, bei denen der Backend-Server SSL beendet. Dies ist ungewöhnlich und ich werde die Option hier nicht näher untersuchen.

Sobald das anfängliche SSL beendet wurde, entscheiden Sie, ob die Daten erneut verschlüsselt werden sollen, beispielsweise zwischen dem Load Balancer und dem nächsten Sprung. Der nächste Sprung kann ein Backend-Server oder ein anderer Load Balancer sein oder ...

Wiederholen Sie den Vorgang, bis Sie zu einem Schritt gelangen, bei dem die Daten im Klartext gesendet werden sollen, oder bis Sie den letzten Server in der Kette erreichen.

Das Beenden von SSL ist eine Voraussetzung für den Load Balancer, um beispielsweise einen HTTP-X-Forwarded-For-Header einfügen oder andere Dinge tun zu können, die Zugriff auf Klartextdaten erfordern. Daher ist es üblich, SSL vor dem Load Balancer oder auf dem Load Balancer oder beides zu beenden.

Es ist auch üblich, den Datenverkehr an die Backends sowohl verschlüsselt als auch unverschlüsselt zu senden. Es hängt einfach von den Umständen der Organisation und dem Zweck der gesendeten Daten ab.

SSL-Offloadingist lediglich ein Begriff, der einen Prozess beschreibt, bei dem ein technisches Gerät die SSL-Verschlüsselung/Entschlüsselung anstelle eines anderen Geräts durchführt.

Es kann sich um einen Load Balancer handeln, der SSL entschlüsselt und Klartext an ein Backend übergibt – das Backend wurde von SSL entlastet.

Es kann sich um einen Load Balancer mit speziellen Hardwareschaltkreisen handeln, die speziell für die SSL-Verschlüsselung/-Entschlüsselung vorgesehen sind – die CPU des Load Balancers wurde SSL-entlastet. Und so weiter …