13
Unverschlüsselte Verbindung zwischen Reverse-Proxy und Webserver
Hallo zusammen,
ich hätte da folgendes Szenario:
Hier soll es erstmal nicht um die fehlende Segmentierung gehen. Dass das ein massives Risiko ist, ist uns bewusst und das Thema soll auch angegangen werden. Mir geht es mir um die Absicherung der Webanwendungen.
Ich würde zur einfacheren Verwaltung gern einen NGinX Reverse-Proxy nutzen. Ich hatte mir das wie folgt vorgestellt:
Hätten wir eine anständige Segmentierung, würde ich den Reverse-Proxy einfach als Edge-Server nutzen und hätte keine Schmerzen damit, dass der Datenverkehr innerhalb des Serversegments unverschlüsselt abläuft. Aber das ist bei uns ja nicht so. Soll bedeuten: Welche Hebel und Möglichkeiten hat ein Angreifer, Zugangsdaten aus dem Verkehr zwischen Webserver und Reverse-Proxy auszulesen und wie hoch ist das Risiko einzuschätzen? Sollte ich lieber gleich jeden Server gesondert absichern und den Plan verwerfen?
Vielen Dank schon einmal für Hilfe und Ideen.
Viele Grüße
Daniel
ich hätte da folgendes Szenario:
- Hausnetz besteht aus mehreren Subnetzen, die leider nicht durch eine FW voneinander getrennt sind. Routing übernehmen die Switche.
- Es gibt ein Client-Segment und ein Server-Segment, die jedoch wie oben geschrieben so gut wie nicht getrennt sind.
- Wir haben in unserem internen Netz einige Webanwendungen, die bisher nie SSL-verschlüsselt wurden, diese sollen nun abgesichert werden.
Hier soll es erstmal nicht um die fehlende Segmentierung gehen. Dass das ein massives Risiko ist, ist uns bewusst und das Thema soll auch angegangen werden. Mir geht es mir um die Absicherung der Webanwendungen.
Ich würde zur einfacheren Verwaltung gern einen NGinX Reverse-Proxy nutzen. Ich hatte mir das wie folgt vorgestellt:
- Auf dem NGinX sollen alle verschlüsselten Verbindungen terminieren.
- Die Webserver werden so konfiguriert, dass sie nur noch mit dem Reverse-Proxy sprechen dürfen und keine anderen Anfragen mehr beantworten.
- Die Verbindung zwischen Webserver und Reverse-Proxy ist unverschlüsselt.
Hätten wir eine anständige Segmentierung, würde ich den Reverse-Proxy einfach als Edge-Server nutzen und hätte keine Schmerzen damit, dass der Datenverkehr innerhalb des Serversegments unverschlüsselt abläuft. Aber das ist bei uns ja nicht so. Soll bedeuten: Welche Hebel und Möglichkeiten hat ein Angreifer, Zugangsdaten aus dem Verkehr zwischen Webserver und Reverse-Proxy auszulesen und wie hoch ist das Risiko einzuschätzen? Sollte ich lieber gleich jeden Server gesondert absichern und den Plan verwerfen?
Vielen Dank schon einmal für Hilfe und Ideen.
Viele Grüße
Daniel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 715484634
Url: https://administrator.de/contentid/715484634
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
13 Kommentare
Neuester Kommentar
Sofern jemand den Netzwerkverkehr mitlesen kann, kann der alles mitlesen.
Das erreicht man bei Switchen z.B. durch MAC-Flooding, sodass der zum Hub wird, da die MAC-Tabelle für die Ports voll sind.
Spricht etwas dagegen, den Verkehr zw. Proxy und Server zu verschlüsseln?
Ggf. auch hierfür einfach ein eigenes, abgekapseltes Netz nehmen, entweder per VLAN oder mit physikalischem Kabel.
Man kann lokal auf den Servern z.B. iptables mit ufw einrichten, bei Windows gibt es auch eine Firewall.
Das kann man vereinfachen, indem man den eigentlichen Webserver auf einen anderen Port legt und dann dem Reverse-Proxy sagt, dass er nur damit kommunizieren darf.
Dem Webserver sagt man das gleiche, nur umgekehrt.
Bedenke aber, dass du weiterhin per SPI-FW ausgehende Verbindungen für Updates erlauben musst.
Auch ICMP(v6) darf nicht vergessen werden.
Das erreicht man bei Switchen z.B. durch MAC-Flooding, sodass der zum Hub wird, da die MAC-Tabelle für die Ports voll sind.
Spricht etwas dagegen, den Verkehr zw. Proxy und Server zu verschlüsseln?
Ggf. auch hierfür einfach ein eigenes, abgekapseltes Netz nehmen, entweder per VLAN oder mit physikalischem Kabel.
Man kann lokal auf den Servern z.B. iptables mit ufw einrichten, bei Windows gibt es auch eine Firewall.
Das kann man vereinfachen, indem man den eigentlichen Webserver auf einen anderen Port legt und dann dem Reverse-Proxy sagt, dass er nur damit kommunizieren darf.
Dem Webserver sagt man das gleiche, nur umgekehrt.
Bedenke aber, dass du weiterhin per SPI-FW ausgehende Verbindungen für Updates erlauben musst.
Auch ICMP(v6) darf nicht vergessen werden.
Hi,
danke schonmal für den Input. Die Webanwendungen sind teilweise sehr heterogen, so dass ich den Verkehr nur sehr schwer physisch begrenzen kann. Die meisten Server sind zwar VMs, diese liegen jedoch teilweise auf unterschiedlichen Hosts, so dass ich den Transport über physische Kabel und Switche nicht ganz außen vor lassen kann.
Dass ich die Kommunikation auf den einzelnen Hosts über die Einstellungen sehr gut kanalisieren kann, ist mir bekannt. Aber das hilft ja nicht gegen das Auslesen des Datenverkehrs.
Generell sprichts nichts dagegen, den Verkehr zwischen Proxy und Webserver zu verschlüsseln. Dann fällt jedoch der Vorteil der vereinfachten Verwaltung weg. Im Gegenteil, dann muss ich die Verschlüsselung ja doppelt verwalten und dann spare ich mir den Proxy lieber. Es sei denn, es gibt eine einfache Möglichkeit, das hin zu bekommen.
danke schonmal für den Input. Die Webanwendungen sind teilweise sehr heterogen, so dass ich den Verkehr nur sehr schwer physisch begrenzen kann. Die meisten Server sind zwar VMs, diese liegen jedoch teilweise auf unterschiedlichen Hosts, so dass ich den Transport über physische Kabel und Switche nicht ganz außen vor lassen kann.
Dass ich die Kommunikation auf den einzelnen Hosts über die Einstellungen sehr gut kanalisieren kann, ist mir bekannt. Aber das hilft ja nicht gegen das Auslesen des Datenverkehrs.
Generell sprichts nichts dagegen, den Verkehr zwischen Proxy und Webserver zu verschlüsseln. Dann fällt jedoch der Vorteil der vereinfachten Verwaltung weg. Im Gegenteil, dann muss ich die Verschlüsselung ja doppelt verwalten und dann spare ich mir den Proxy lieber. Es sei denn, es gibt eine einfache Möglichkeit, das hin zu bekommen.
Warum hast du den Reverse-Proxy in Betrieb?
Der ReverseProxy hat keine zweite Netzwerkschnittstelle und man kann auch keine einbauen? Das schreit doch gerade danach. Dann würdest du die Applikation direkt an den RP anschließen und den RP ans Netz.
Genau das ist ja die Frage. Ich wollte ursprünglich die TLS-Terminierung vereinfachen und die heterogenen Webserver gegen Angriffe abschirmen, indem ich den Webserver nur noch für diesen einen Host öffne. Aber wenn das sowieso nichts bringt, außer mehr Aufwand, nehme ich den RP lieber vom Netz.
Am Ende müssen für mich die Vorteile überwiegen:
Sicherheitsgewinn + Vereinfachtes TLS-Management <-> Mehraufwand
Am Ende müssen für mich die Vorteile überwiegen:
Sicherheitsgewinn + Vereinfachtes TLS-Management <-> Mehraufwand
Hi, leider ist eine physische Abschottung der Kommunikation nicht möglich, wie oben schon geschrieben. Über irgend einen Switch läuft immer die unverschlüsselte Kommunikation zwischen RP und Webserver.
Können die Switche auf dem Weg VLAN-Tagging?
Dann kann man das in ein eigenes VLAN packen und hat es zumindest mal ein wenig abgeschottet.
Dann kann man das in ein eigenes VLAN packen und hat es zumindest mal ein wenig abgeschottet.
Nehm doch Docker dafür !?
Können Sie auf jeden Fall, ich scheue nur den Aufwand, da noch ein VLAN für hoch zu ziehen. Zumal es in dieses VLAN auch wieder eine Route geben müsste, damit wir die Webserver weiter konfigurieren können. Oder jeder Webserver bräuchte zwei NICs. Eine für den Webserver und eine für den Admin-Zugang. Oder wir müssten eine Leitung in die IT-Büros patchen... Alles halt sehr aufwändig. Da würde ich dann eher auf den RP verzichten.
Kannst Du das ein bisschen genauer ausführen? Mir ist noch nicht ganz klar, wie das helfen kann.
VG
VG
Nein, genau deswegen gibt es VLAN, du kannst sowohl am Switch als auch am PC einen Trunk-Port einrichten und dann das vorhandene Kabel nutzen, um 2 getrennte Netze zu haben.
Stimmt, den Trunk könnte ich auch einrichten. Wobei es für mich an einer VM keinen großen Unterschied macht, ob ich den vorhandene virtuellen NIC als Trunk konfiguriere oder ob ich eine zweite virtuelle NIC konfiguriere. Es würde schon die Sicherheit erhöhen, gefühlt bringt mir das alles ein gutes Stück zu viel Komplexität in die Konfiguration.
Hallo zusammen,
zunächst mal vielen Dank für alle die Ratschläge, sie haben mir sehr geholfen, eine Entscheidung zu treffen. Ich habe nun auf den betroffenen Servern einen lokalen Nginx installiert, so dass die SSL-Verschlüsselung direkt am Host terminiert. Das scheint mir bei all den oben genannten Alternativen einfach die praktikabelste Lösung zu sein.
Viele Grüße und danke nochmal.
Daniel
zunächst mal vielen Dank für alle die Ratschläge, sie haben mir sehr geholfen, eine Entscheidung zu treffen. Ich habe nun auf den betroffenen Servern einen lokalen Nginx installiert, so dass die SSL-Verschlüsselung direkt am Host terminiert. Das scheint mir bei all den oben genannten Alternativen einfach die praktikabelste Lösung zu sein.
Viele Grüße und danke nochmal.
Daniel
