Christian Boltz schrieb:
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.
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