Hallo, ich möchte einen reverse proxy aus Sicherheitsgründen vor eine selbst geschriebene Webapplikation setzen. Die Webapp wird per https aufgerufen. Ich habe noch nie einen reverse proxy aufgesetzt. Welchen könnt Ihr empfehlen (und warum) ? Danke. Bernd -- Bernd Lentes SystemAdministrator Institute of Metabolism and Cell Death Helmholtz Zentrum München Building 25 office 122 Bernd.lentes@helmholtz-munich.de +49 89 3187 1241 Helmholtz Zentrum München – Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstraße 1, D-85764 Neuherberg, https://www.helmholtz-munich.de Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias H. Tschöp, Dr. Michael Frieser | Aufsichtsratsvorsitzende: MinDir’in Prof. Dr. Veronika von Messling Registergericht: Amtsgericht München HRB 6466 | USt-IdNr. DE 129521671
Hallo Bernd, hallo zusammen, Am Montag, 15. April 2024, 15:41:56 MESZ schrieb Bernd Lentes:
ich möchte einen reverse proxy aus Sicherheitsgründen vor eine selbst geschriebene Webapplikation setzen.
Definiere "aus Sicherheitsgründen" ;-) - was genau willst Du erreichen? Hintergrund meiner Frage: standardmäßig reicht ein reverse proxy alle https-Requests durch - sprich: dadurch wird es erstmal nicht sicherer. Einen eindeutigen Sicherheitsgewinn gibt es immerhin (unter der Annahme, dass die Webapp auf einem eigenen Server oder VM läuft): andere Ports sind nicht mehr von außen erreichbar. Das bekommst Du mit einer Firewall aber auch. Evtl. hilft es auch, wenn Du kurz erzählst, wie die Webapp derzeit in den Webserver eingebunden ist.
In der openSUSE-Infrastruktur läuft (fast) alles hinter einem haproxy, der die Requests dann auf die jeweils zuständige VM verteilt (meistens anhand der Domain, teilweise auch anhand der URL). Läuft zuverlässig. Die Konfiguration für *.opensuse.org ist natürlich "etwas" komplexer, aber für kleinere Setups ist die Konfiguration recht einfach. Ob ich haproxy jetzt empfehle? Ich könnte natürlich "ja" sagen (und ich wüsste nichts, was dagegen spricht) - aber ohne zu wissen, was Du erreichen willst, ist so eine pauschale Antwort begrenzt hilfreich. Für ein paar Webapps, die nur über einen Socket erreicht werden können, haben wir übrigens auf der jeweiligen VM nginx im Einsatz. (Und auch sonst meistens nginx als "normalen" Webserver, wenn es nicht gute Gründe für einen anderen gibt.) Gruß Christian Boltz -- Lass es mich so sagen: GUIs? Wir haben keine. Davon aber zwei. [Ratti in suse-linux]
Christian Boltz schrieb:
Doch, wird es, jedenfalls dann, wenn auf dem Webserver wertvolle Daten gespeichert sind. Denn wenn ein Angreifer einen Buffer Overflow auslöst, kann er seinen Code erst mal nur auf dem Rerverse Proxy ausführen und eben nicht auf dem Webserver und da gibt es für ihn erst mal nichts zu "holen". (*) Unter Umständen hat er natürlich ein "Sprungbrett" für den Angriff auf den echten Server - aber der Aufwand für den Angriff wird halt deutlich größer und damit wird die Wahrscheinlichkeit für einen erfolgreichen Angriff schon geringer, und das ist es ja, worauf es in der IT-Sicherheit ankommt. Ganz verhindern kann man eh nichts, und oft reicht eben schon mal ein "nackter" Reverse Proxy. Noch besser ist natürlich ein Reverse Proxy mit Sicherheitsfunktionen, der bestimmte Requests abwehrt und gar nicht erst zum echten Server weiter leitet. Zu (*), bevor der Einwand kommt: Der private Key für die https-Verschlüsselung liegt natürlich auch auf dem Reverse Proxy. Ebenso könnte der Hacker die Reverse-Proxy-Funktionalität manipulieren, während er schon mal auf dem System drauf ist. Alles auch nicht schön, aber er hat noch keine Daten und auch hier ist eine weitere Hürde da, bis echte Anwender-Daten verloren gehen. Und einen geknackten Key kann man erneuern. Verloren geganges Vertrauen der Kunden durch einen Datenverlust nicht. Davon unbenommen ist die Frage, was man mit dem Reverse Proxy GENAU erreichen kann, wichtig. Ein Reverse Proxy um des Reverse Proxy willen macht keinen Sinn. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 16.04.24 um 08:03 schrieb Manfred Haertel, DB3HM:
Naja, ein Bufferoverflow im verwendeten Webserver dürfte deutlich seltener anzutreffen sein, als eine beliebige Sicherheitslücke in der Applikation selber. Und gegen letztere hilft ein **einfacher** RP halt nicht. Insofern ist ein RP schon eine Sicherheitsmaßnahme, aber keine, die ich sonderlich hoch bewerten würde. Viele GRüße Ulf
Ich würde gerne die Requests untersuchen. Bernd Helmholtz Zentrum München – Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstraße 1, D-85764 Neuherberg, https://www.helmholtz-munich.de Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias H. Tschöp, Dr. Michael Frieser | Aufsichtsratsvorsitzende: MinDir’in Prof. Dr. Veronika von Messling Registergericht: Amtsgericht München HRB 6466 | USt-IdNr. DE 129521671
Hallo Bernd, hallo zusammen, Am Montag, 15. April 2024, 15:41:56 MESZ schrieb Bernd Lentes:
ich möchte einen reverse proxy aus Sicherheitsgründen vor eine selbst geschriebene Webapplikation setzen.
Definiere "aus Sicherheitsgründen" ;-) - was genau willst Du erreichen? Hintergrund meiner Frage: standardmäßig reicht ein reverse proxy alle https-Requests durch - sprich: dadurch wird es erstmal nicht sicherer. Einen eindeutigen Sicherheitsgewinn gibt es immerhin (unter der Annahme, dass die Webapp auf einem eigenen Server oder VM läuft): andere Ports sind nicht mehr von außen erreichbar. Das bekommst Du mit einer Firewall aber auch. Evtl. hilft es auch, wenn Du kurz erzählst, wie die Webapp derzeit in den Webserver eingebunden ist.
In der openSUSE-Infrastruktur läuft (fast) alles hinter einem haproxy, der die Requests dann auf die jeweils zuständige VM verteilt (meistens anhand der Domain, teilweise auch anhand der URL). Läuft zuverlässig. Die Konfiguration für *.opensuse.org ist natürlich "etwas" komplexer, aber für kleinere Setups ist die Konfiguration recht einfach. Ob ich haproxy jetzt empfehle? Ich könnte natürlich "ja" sagen (und ich wüsste nichts, was dagegen spricht) - aber ohne zu wissen, was Du erreichen willst, ist so eine pauschale Antwort begrenzt hilfreich. Für ein paar Webapps, die nur über einen Socket erreicht werden können, haben wir übrigens auf der jeweiligen VM nginx im Einsatz. (Und auch sonst meistens nginx als "normalen" Webserver, wenn es nicht gute Gründe für einen anderen gibt.) Gruß Christian Boltz -- Lass es mich so sagen: GUIs? Wir haben keine. Davon aber zwei. [Ratti in suse-linux]
Christian Boltz schrieb:
Doch, wird es, jedenfalls dann, wenn auf dem Webserver wertvolle Daten gespeichert sind. Denn wenn ein Angreifer einen Buffer Overflow auslöst, kann er seinen Code erst mal nur auf dem Rerverse Proxy ausführen und eben nicht auf dem Webserver und da gibt es für ihn erst mal nichts zu "holen". (*) Unter Umständen hat er natürlich ein "Sprungbrett" für den Angriff auf den echten Server - aber der Aufwand für den Angriff wird halt deutlich größer und damit wird die Wahrscheinlichkeit für einen erfolgreichen Angriff schon geringer, und das ist es ja, worauf es in der IT-Sicherheit ankommt. Ganz verhindern kann man eh nichts, und oft reicht eben schon mal ein "nackter" Reverse Proxy. Noch besser ist natürlich ein Reverse Proxy mit Sicherheitsfunktionen, der bestimmte Requests abwehrt und gar nicht erst zum echten Server weiter leitet. Zu (*), bevor der Einwand kommt: Der private Key für die https-Verschlüsselung liegt natürlich auch auf dem Reverse Proxy. Ebenso könnte der Hacker die Reverse-Proxy-Funktionalität manipulieren, während er schon mal auf dem System drauf ist. Alles auch nicht schön, aber er hat noch keine Daten und auch hier ist eine weitere Hürde da, bis echte Anwender-Daten verloren gehen. Und einen geknackten Key kann man erneuern. Verloren geganges Vertrauen der Kunden durch einen Datenverlust nicht. Davon unbenommen ist die Frage, was man mit dem Reverse Proxy GENAU erreichen kann, wichtig. Ein Reverse Proxy um des Reverse Proxy willen macht keinen Sinn. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 16.04.24 um 08:03 schrieb Manfred Haertel, DB3HM:
Naja, ein Bufferoverflow im verwendeten Webserver dürfte deutlich seltener anzutreffen sein, als eine beliebige Sicherheitslücke in der Applikation selber. Und gegen letztere hilft ein **einfacher** RP halt nicht. Insofern ist ein RP schon eine Sicherheitsmaßnahme, aber keine, die ich sonderlich hoch bewerten würde. Viele GRüße Ulf
Ich würde gerne die Requests untersuchen. Bernd Helmholtz Zentrum München – Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstraße 1, D-85764 Neuherberg, https://www.helmholtz-munich.de Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias H. Tschöp, Dr. Michael Frieser | Aufsichtsratsvorsitzende: MinDir’in Prof. Dr. Veronika von Messling Registergericht: Amtsgericht München HRB 6466 | USt-IdNr. DE 129521671
participants (6)
-
Bernd Lentes -
Christian Boltz -
Manfred Haertel, DB3HM -
Ralf Prengel -
ulf Volmer -
Ulf Volmer