3
Pfsense Firewall Option "Enable Packet Log" + HaProxy
Hallo,
ich wollte mal fragen ob es rechtlich bedenklich ist folgendes zu machen:
Eine Topologie die in etwa so aussieht:
Users Webbrowser -> --Internet--:443 SSL Terminierung auf Pfsense Firewall mit SSL Offloading und Suricata Packet PCAP LOG (Plaintext Port 80)-- Apache Server (port 80 http)
Also nochmal zusammengefasst ich habe eine Pfsense Firewall wo SSL Offloading gemacht wird das heißt alle SSL Certs liegen auf der Pfsense und der Apache ist als Backendserver mit Port 80 nur erreichbar. Nebenbei läuft noch Suricata als Intrusion Prevention System was PCAP Files von der Backendverbindung zwischen Pfsense und Apache speichert und das im Plaintext. Das heißt ich sehe wenn sich da ein User auf meinem Apache anmeldet seinen Usernamen und sein Passwort und alles was er in dem Zeitraum geklickt und geschrieben hat.
Kennt sich da jemand mit der Rechtslage aus? Wie muss ich die User informieren? Hintergrund die Pfsense kann meines Wissens nach den Traffic nicht auf Angriffe prüfen wenn der Traffic verschlüsselt ist deshalb unverschlüsseltes Backend.
ich wollte mal fragen ob es rechtlich bedenklich ist folgendes zu machen:
Eine Topologie die in etwa so aussieht:
Users Webbrowser -> --Internet--:443 SSL Terminierung auf Pfsense Firewall mit SSL Offloading und Suricata Packet PCAP LOG (Plaintext Port 80)-- Apache Server (port 80 http)
Also nochmal zusammengefasst ich habe eine Pfsense Firewall wo SSL Offloading gemacht wird das heißt alle SSL Certs liegen auf der Pfsense und der Apache ist als Backendserver mit Port 80 nur erreichbar. Nebenbei läuft noch Suricata als Intrusion Prevention System was PCAP Files von der Backendverbindung zwischen Pfsense und Apache speichert und das im Plaintext. Das heißt ich sehe wenn sich da ein User auf meinem Apache anmeldet seinen Usernamen und sein Passwort und alles was er in dem Zeitraum geklickt und geschrieben hat.
Kennt sich da jemand mit der Rechtslage aus? Wie muss ich die User informieren? Hintergrund die Pfsense kann meines Wissens nach den Traffic nicht auf Angriffe prüfen wenn der Traffic verschlüsselt ist deshalb unverschlüsseltes Backend.
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: 8048903936
Url: https://administrator.de/contentid/8048903936
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
3 Kommentare
Neuester Kommentar
Moin,
Spaß bei Seite... frage deinen Anwalt deines Vertrauens. Rechtsberatungen gibt es in Foren nicht.
Gruß,
Dani
Wie muss ich die User informieren? Hintergrund die Pfsense kann meines Wissens nach den Traffic nicht auf Angriffe prüfen wenn der Traffic verschlüsselt ist deshalb unverschlüsseltes Backend.
die Verbindung wird doch an der PfSense bzw. HAProxy terminiert und dann wird eine neue Verbindung aufgebaut. Von daher müsste das möglich sein. Weil im Grund so auch jede Web Application Firewall (WAF) arbeitet.Kennt sich da jemand mit der Rechtslage aus?
Ja, unsere Juristen. Spaß bei Seite... frage deinen Anwalt deines Vertrauens. Rechtsberatungen gibt es in Foren nicht.Gruß,
Dani
1
Ja ich verstehs nicht weil ich habe in Suricata IPS noch nie Port 443 auf der Liste gesehen und wenn ich PHP LFI und RFI, XSS und SQL Injections mit 443 teste passiert nichts obwohl am WAN Interface suricate läuft und Lets Encrypt Zertifikate auf der Pfsense eingespielt sind. Erst wie ich im Backend auf Port 80 und SSL Offloading aktiviert habe hat Suricata die Dinge erkannt.
Moin,
der Ablauf sollte doch pfSense -> HaProxy -> IPS -> Backend Webserver sein. Details findest du hier:
https://forum.netgate.com/topic/125012/haproxy-ssl-termination-snort/5
https://forum.netgate.com/topic/150389/begginner-needs-help-with-suricat ...
Gruß,
Dani
der Ablauf sollte doch pfSense -> HaProxy -> IPS -> Backend Webserver sein. Details findest du hier:
https://forum.netgate.com/topic/125012/haproxy-ssl-termination-snort/5
https://forum.netgate.com/topic/150389/begginner-needs-help-with-suricat ...
Erst wie ich im Backend auf Port 80 und SSL Offloading
Das entspricht auch den Rahmenbedingungen: https://www.haproxy.com/blog/haproxy-ssl-terminationGruß,
Dani
1
