Dokumentation
TurnKey Linux Appliances hinter einem Reverse Proxy
A Reverse-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-Proxy-P Ein Server, der zwischen einem oder mehreren "echten" Servern, die den gewünschten Inhalt bedienen, und einem anderen Netzwerk, oft dem Internet, sitzt. hohe Verfügbarkeit (z. B. Server umfallen, wenn Ihr Hauptserver abstürzt) und/oder eine Möglichkeit, mehrere Server über eine einzige (normalerweise öffentliche) IP zu hosten, oft einschließlich SSL/TLS-Terminierung. Die Nutzung einer einzelnen IP zum Hosten mehrerer Server ist beim "Self Hosting" ziemlich üblich (wie viele TurnKey-Benutzer).
Das Netzwerk-Setup sieht ein bisschen so aus:
backend server 1
/
internet/external network <-> reverse proxy <-> backend server 2
\
backend server 3
Kontext und Überblick
Es gibt eine Vielzahl von zweckgebundenen Reverse-Proxys, und gängige Webserver wie Apache, Nginx und LigHTTPd können alle so konfiguriert werden, dass sie als Reverse-Proxy fungieren. Daher versucht dieser Beitrag keine Softwareempfehlung zu geben und deckt auch nicht erschöpfend die softwarespezifische Konfiguration ab. Wenn es config erwähnt, wird es in der Regel auf Apache und / oder Nginx - als die beliebtesten Webserver beschränkt sein. Es wird einige spezifische Konfigurationen für begrenzte Anwendungsfälle berühren, aber im Allgemeinen einen höheren Blick auf das allgemeine Netzwerkdesign und die Überlegungen werfen. Der Hauptzweck dieser Seite ist es, die verschiedenen Verbindungsoptionen zwischen dem Reverse-Proxy und den Backend-Servern zu untersuchen und zu erklären. Es wird sich in erster Linie auf die Konfiguration / Gestaltung der Verbindung zwischen dem Reverse-Proxy und den Backend-Servern konzentrieren.
Historisch gesehen ist der Standardweg, einen Reverse-Proxy zu konfigurieren, TLS / SSL (dh https) Terminierung am Reverse-Proxy zu tun und nur Vanilla http (dh) zu verwenden. unverschlüsselter, "Klartext"-Verkehr zwischen dem Reverse-Proxy- und Backend-Server. Das funktioniert gut und wenn das Backend-Netzwerk von potenziell bösartigen Akteuren oder kompromittierten Geräten isoliert ist, kann es auch sicher genug sein.
Heutzutage wird diese Art von Einrichtung jedoch im Allgemeinen als unsicher angesehen. Das liegt daran, dass die Verwendung von einfachem http alles ermöglicht, was Zugriff auf das Netzwerk hat, um den Netzwerkverkehr zu überwachen und sensible Daten wie Passwörter abzufangen. Auch da es keinen Mechanismus gibt, um die Identität eines Servers über http zu bestätigen, ist ein MITM Angriff ist trivial.
Daher wird im Allgemeinen empfohlen, die https-Kommunikation zwischen Ihrem Reverse-Proxy und Ihren Backend-Servern zu verwenden. Aber auch das kann auf verschiedene Arten konfiguriert werden, jede bietet ihre eigenen Vor- und Nachteile. Hoffentlich werden alle wichtigen und gemeinsamen erwähnt, aber dies wird keine erschöpfende Liste sein.
Die Optionen
Alle Optionen machen Kompromisse zwischen Sicherheit und Aufwand erforderlich. Ich habe bereits einen allgemeinen und höheren Überblick über die Optionen gegeben, aber lassen Sie uns ein bisschen spezifischer werden und sie ein bisschen mehr aufschlüsseln. Hier sind die allgemeinen Optionen, die ich sehe, in einer vagen Reihenfolge von weniger sicher bis mehr (einige der Rankings sind umstritten). Wir werden dann in jeden ein wenig mehr notieren Aufwand erforderlich tauchen.
- http - unverschlüsselt, einfach http
- https - selbstsigniertes Zertifikat; cert ignoriert durch Reverse Proxy
- https - self signed cert & CA; cert verifiziert durch Reverse Proxy
- https - "richtige" CA unterzeichnet Wildcard-Zertifikat; cert verifiziert durch Reverse Proxy
- https - "richtige" CA unterzeichnet spezifisches Zertifikat; cert verifiziert durch Reverse Proxy
http - unverschlüsselt, einfach http
Wie oben erwähnt, ist dies der historische "Standard" eingerichtet, der nach seiner Konfiguration im Allgemeinen "funktioniert" und dies auch weiterhin "für immer" ohne jeglichen Eingriff. Es war einmal auch super einfach einzurichten; da die meisten server oft out of the box entworfen wurden, um über http zu hosten.
Da der Datenverkehr jedoch unverschlüsselt übertragen wird, könnte jeder bösartige Akteur/Gerät im selben Netzwerk wie der Backend-Server leicht den Datenverkehr abfangen (z.B. .steal Passwörter, etc, vielleicht schlimmer. Auch da es keine Validierung gibt, dass der Backend-Server, so dass MITM-Angriffe trivial.
In Bezug auf den Aufwand, wenn Sie alle Ihre eigenen Server von Grund auf neu erstellen, dann erfordert dies wahrscheinlich den geringsten Aufwand. Obwohl, wenn Sie TurnKey verwenden, hängt es von der spezifischen Appliance. Viele unserer Appliances umleiten zu https, zumindest für die Anmeldung (um das Risiko von Passwort-Snooping zu reduzieren). Viele von ihnen müssen auch in der Lage sein, sich über eine bestimmte voreingestellte Domain zu verbinden, so dass sie zu dieser umleiten werden FQDN Standardmäßig wird die Domain-Umleitung wahrscheinlich kein Problem sein und im Allgemeinen wird Ihr Reverse-Proxy nur eine Verbindung über die Domain zulassen, so dass dies kein Problem sein sollte. Die Umleitung von http zu https (wenn nur http-Verbindung unterstützt wird) führt jedoch zu Problemen.
Zusammenfassend, obwohl es keine besonders sichere Einrichtung ist, denke ich, dass Sie allen Personen und Geräten vertrauen, die sich mit dem Netzwerk verbinden können, in dem sich die Backend-Server befinden. Das ist eine völlig legitime Konfiguration.
Wie man
Damit dieses Setup mit einem TurnKey-Backend-Server (oder einem anderen Server, der http zu https umleitet) funktioniert, müssen Sie die https-Umleitung deaktivieren. In der Apache-Konfiguration suchen Sie nach Zeilen, die mit "Rewrite" oder "Redirect" im virtuellen Host Port 80 beginnen. In Nginx, wieder für Umleitungen in der virtuellen Server-Konfiguration Port 80 suchen; suchen Sie nach Zeilen, die "return 30x" (wobei x Zahl ist) oder "redirect" beginnen.
https - selbstsigniertes Zertifikat; cert ignoriert durch Reverse Proxy
Mit dieser Option werden Ihre Backend-Server über den Reverse-Proxy über https aufgerufen, aber sie verwenden nur selbst signierte Zertifikate (diejenigen, die in Ihrem Web beängstigend sind). Dieses Konfigurationsmodell ist ein Sicherheitsupgrade, da es bedeutet, dass der Datenverkehr verschlüsselt ist, so dass das Schnüffeln blockiert ist. Da es jedoch keine Validierung gibt, dass der Backend-Server das ist, was Sie denken, sind MITM-Angriffe immer noch praktikabel (und so einfach wie bei einfachem http).
Diese Option erfordert ein wenig mehr Arbeit an Ihrer Reverse-Proxy-Konfiguration und es besteht die Möglichkeit, dass einige spezifische Reverse-Proxy-Software diesen Ansatz möglicherweise nicht unterstützt. Allerdings sollten die meisten Reverse Proxies diese Option unterstützen, alle wichtigen Webserver tun dies sicherlich. Wenn Sie TurnKey als Backend-Server verwenden, sollte dies keinen Aufwand auf Ihrem Backend-Server erfordern und "nur funktionieren" - obwohl Sie bei einer Umleitung zur Domain müssen sicherstellen, dass Sie das nicht auch am Schriftende tun - das kann eine rekursive Redirect-Schleife verursachen.
Wie man
Alle Konfigurationen, die für diese Arbeit erforderlich sind, müssen auf dem Reverse-Proxy durchgeführt werden. AFAIK Nginx ist standardmäßig für dieses Verhalten - d.h. Es ignoriert die Tatsache, dass Zertifikate selbst signierte Zertifikate sind und sich trotzdem verbinden. Richtlinie Docs.
Apache benötigt einige zusätzliche Konfigurationen. Ich werde nicht auf Einzelheiten eingehen, aber es wird eine Verwendung erfordern. SSLProxy*-Richtlinien, wie z.B. SSLProxyCheckPeerCN und SSLProxyCheckPeerName.
https - self signed cert & CA; cert verifiziert durch Reverse Proxy
Diese Option ist ein weiteres Sicherheitsupgrade, da über die vorherige Option hinaus auch eine Validierung erfolgt. Der Nachteil ist, dass es ein wenig zusätzlichen Aufwand erfordert, da Sie einen CA-Schlüssel (Zertifizierungsbehörde) generieren und selbst signierte Zertifikate (re) generieren müssen, die von Ihrem CA-Schlüssel signiert sind. Der CA (public) Schlüssel muss auch auf dem Reverse Proxy gespeichert werden.
Die Risiken sind, dass, wenn der CA private Schlüssel von einem böswilligen Akteur gefunden werden kann, dann können sie auch ihre eigenen Zertifikate generieren, die mit Ihrem Reverse-Proxy funktionieren. Dies kann dadurch gemindert werden, dass die erforderlichen Zertifikate woanders generiert und gespeichert werden (z. B. ein dritter Server) und kein Zugriff auf den privaten CA-Schlüssel erlaubt wird. Eine weitere Abschwächung besteht darin, sicherzustellen, dass das Entsperren des CA-Schlüsselpaares auch eine Passphrase erfordert. Dann müsste ein Angreifer auch die Passphrase kennen und Zugriff auf den privaten Schlüssel haben. Mit diesen Abschwächungen ist diese Option wahrscheinlich so sicher, wie Sie bekommen können. Da Sie die CA kontrollieren, können Zertifikate extrem langlebig sein, wenn Sie möchten (was bedeutet, dass sie selten aktualisiert werden müssen). Oder Sie könnten den dritten Server so einrichten, dass aktualisierte Zertifikate automatisch auf den Backend-Server übertragen werden (obwohl der Wert einer Passphrase reduziert wird).
Wie man
Ich weiß, dass diese Option sowohl für Apache als auch für Nginx verfügbar ist. Leider habe ich nicht die spezifischen Anweisungen erforderlich handlich, aber sie werden mit ziemlicher Sicherheit enthalten "ssl" und wahrscheinlich "ca" (und wahrscheinlich "proxy) in ihrem Namen (n). Wie oben erwähnt, authentifiziert Nginx keine Zertifikate standardmäßig, Sie möchten dies aktivieren.
https - "richtige" CA unterzeichnet Wildcard-Zertifikat; cert verifiziert durch Reverse Proxy
Ein "Wildcard"-Zertifikat ist ein spezielles TLS/SSL-Zertifikat, das für mehrere Subdomains gültig ist. ein Platzhalterzertifikat für *.example.com wäre gültig für www.example.com, docs.example.com und blog.example.com (etc.). Die Verwendung von Platzhalter-Zertifikaten auf Ihren Backend-Servern hat ein ähnliches Sicherheitsprofil wie die unmittelbaren oben und unten genannten Optionen, obwohl die Vildation eher generisch als spezifisch ist. Während das Zertifikat validiert wird, können Sie nicht sicher sein, mit welchem Backend-Server Sie sich verbinden. Es sollte immer noch ziemlich sicher sein, obwohl, wenn ein Angreifer Zugriff auf einen Ihrer Backend-Server erhält, könnten sie das Wildcard-Zertifikat stehlen und es verwenden, um ein anderes zu machen Server/Dienst "gültig".
Wie man
Neben einem Mechanismus, der neue Zertifikate nach ihrer Aktualisierung erhält und verteilt, sollte keine zusätzliche Konfiguration erforderlich sein. Obwohl, wie ich oben erwähnt habe, authentifiziert Nginx keine Zertifikate standardmäßig, also sollten Sie das aktivieren.
https - "richtige" CA unterzeichnet spezifisches Zertifikat; cert verifiziert durch Reverse Proxy
In der heutigen Zeit, wo wir Dienstleistungen wie Let's EncryptIMO ist die einfachste und beste Option. Sie erhalten die Vorteile eines Reverse-Proxys, mit der Sicherheit eines "standalone" Servers mit seinem eigenen legitimen CA-signierten Zertifikat. Dies ist eine besonders gute Option, wenn die Möglichkeit besteht, dass dieser Server direkt öffentlich gestellt wird. Sie könnten direkten öffentlichen Zugang mit null Änderungen zulassen und es sollte "einfach funktionieren" (und trotzdem sicher sein).
Da Ihr Backend-Server über ein eigenes, von CA signiertes Zertifikat verfügt, sind die https-Verbindungen gültig und sollten "einfach funktionieren". Sie erhalten dann auch die zusätzliche Sicherheit einer vollständig authentifizierten verschlüsselten Verbindung für "kostenlos".
Wie man
Für TurnKey Backend-Server können Sie nutzen Confconsole Advanced Menü um ein "richtiges" Let's Encrypt-Zertifikat zu erhalten. Die standardmäßige (HTTP-01) Validierung erfordert auch den Zugriff auf Port 80, aber das sollte nicht zu viel zusätzliche Konfiguration auf Ihrem Reverse-Proxy erfordern. Die Validierung der Domänenautorität kann auch über DNS (DNS-01) erfolgen, was eine alternative Option ist (die auch DNS-01 unterstützt), obwohl IMO HTTP einfacher ist.