Zugriff auf's GUI über WAN nur von bestimmten IP-Adressen

[cklahn]

Hallo Forum,

Unter Administration kann ich ja beim WebInterface einstellen, daß das WebInterface auf LAN und WAN hören soll. Das bedeutet natürlich, daß jeder aus dem Internet am Anmeldefenster landet.

Ich habe hier bei uns im Büro eine Opensense mit OPNcentral und bin mit zwei OPNsenses hierüber verbunden für zentrales Management.

Wenn ich auf den beiden entfernten OPNsenses den Zugriff auf das GUI auf LAN beschränke, funktioniert das zentrale Management nicht mehr. Kann man irgendwie definieren, daß Anfragen über meine feste externe IP trotzdem das GUI öffnen dürfen und daß das zentrale Mangement funktioniert, jeder andere aber nicht aus dem Internet an den Anmeldedialog kommt?

Grüsse

[Monviech (Cedrik)]

Hallo,

du lässt das Web GUI auf allen Interfaces hören (wichtig, da es ansonsten bei einem reboot zu Problemen mit der Bindung kommen kann. Wenn das Interface nicht verfügbar ist kann es sein dass die Webui nicht starten kann weil sie sich nicht binden kann).

Danach einfach auf dem WAN eine regel erstellen die als ziel "This Firewall" und den Webui Port hat. In der kann man als Source einen Alias einstellen der alle festen IPs enthält die auf die Webui zugreifen dürfen.

Diese Regel am besten ziemlich an den Anfang vom WAN Interface stellen. (Und natürlich im WAN keine Any Any Regeln haben...)

[chemlud]

Sauber Lösung: Einen Tunnel (Wireguard?) und dann vom LAN auf die GUI zugreifen. GUI am WAN ist schon sehr 80er...

Die IP von Paketen zu faken ist nicht gerade eine große Kunst.

[Monviech (Cedrik)]

Sauber Lösung: Einen Tunnel (Wireguard?) und dann vom LAN auf die GUI zugreifen. GUI am WAN ist schon sehr 80er...

Die IP von Paketen zu faken ist nicht gerade eine große Kunst.

Aber danach müssen sie auch noch das Passwort faken, das ist schon schwerer.

Außerdem kann man noch Crowdsec benutzen um Fail2Ban für Bruteforcer zu haben.

[meyergru]

Sauber Lösung: Einen Tunnel (Wireguard?) und dann vom LAN auf die GUI zugreifen. GUI am WAN ist schon sehr 80er...

Die IP von Paketen zu faken ist nicht gerade eine große Kunst.

Aber danach müssen sie auch noch das Passwort faken, das ist schon schwerer.

Außerdem kann man noch Crowdsec benutzen um Fail2Ban für Bruteforcer zu haben.

Wenn man die IP von Paketen fakt, bekommt aber jemand anders die Antwort, für Angriffe abgesehen von DOS-Attacken ist das kaum brauchbar.

Trotzdem ist es keine gute Idee, eine Mission-Critical Web-UI von außen zugreifbar zu machen, denn es kann immer sein, dass es eine Schwachstelle in der Web-Anwendung gibt, die es ermöglicht, ganz ohne Login irgendwas zu tun.

Ich denke dabei an so etwas: https://github.com/opnsense/core/commit/93e0d14748a4218c8eb11424624751caad39d10f

[Monviech (Cedrik)]

Man kann sie hinter zig zusätzlichen abgeschlossenen Türen verstecken, jede Tür kann eine eigene Schwachstelle haben. Je mehr Türen man verbindet, desto schwerer wird es.

Wenn man das ganze auf die Spitze treiben will:

Webui Zugriff über Reverse Proxy - Im Reverse Proxy Client Authentication mit Zertifikat machen + Basic Auth - IP Adressen beschränken - Dann noch IPsec (natürlich auch mit Client Zertifikat + Passwort + One Time Code) über Wireguard (+PSK ) weil nur IPsec nicht reicht, und darüber noch einen SSH Tunnel mit Private+Pubkey und Passwort. (Ob das noch geht, wird langsam knapp mit mtu xD)

(Das ist gerade natürlich nur als Scherz gemeint xD)

[meyergru]

Du hast schon Recht  , aberrrr:

Meine Erfahrung ist, dass ein VPN, das nur zu einem einzigen Spezialzweck gebaut ist, sicherheitstechnisch jeder noch so kleinen Webanwendung überlegen ist, die zumeist in vielen Schichten irgendwelche Schwachstellen haben kann. Von letzteren kann ich ein Lied singen, Internet-Homebanking lässt grüßen. Wenn Du schonmal Sylvester das Homebanking der ....bank hast abschalten lassen, weil das Scheunentor ganz weit offenstand, weißt Du Bescheid.

Das fängt bei PHP oder Python an, geht über Kommandozeilentools, die von dort aus ausgeführt werden, bis hin zu Javascipt-Bibilotheken (oder -Frameworks). Mein oben verlinktes Beispiel ist ja einschlägig... was könnte es schöneres geben für einen Angreifer als einen frei zugänglichen Coredump eines aufgerufenen Binaries?

Und das fällt natürlich erstmal nicht auf - wer denkt denn schon daran, dass die unter FreeBSD im aktuellen Verzeichnis abgelegt werden, also genau dort, wo die Skripte laufen?

[cklahn]

Hi,
vielen Dank für die vielen Posts ;-).

Ich habe das nun erstmal so gebaut, wie Monviech das im zweiten Post beschrieben hat. Das klappt so erstmal wunderbar. Zugriff aus dem Büro klappt, von zu Hause nicht, da ich hier eine andere IP habe.

Grundsätzlich gebe ich Recht, daß ein VPN sicherlich besser wäre und den Zugriff lediglich aus dem LAN zulasse. Aber dann klappt das mit OPNcentral ja nicht, da das ja über das WAN zugreift. Ergo müßte ich von meiner OPNsense zu jeder verwalteten OPNsense einen dauerhaften Tunnel aufgebaut haben. Frage, ob das so clever ist, falls mich einer hackt...