Zugriff auf OPNsense Web GUI über WAN nach Installation automatisch aktiv ()

[_Alchemist_]

Hallo zusammen,

ich habe heute mal wieder OPNsense installiert und DynDNS eingerichtet.
Dabei ist mir aufgefallen dass ich mit der WAN IP im Browser direkt auf die Web Oberfläche komme!!!

Unter "System: Settings: Administration" --> "Listen Interfaces" stand "All (recommended)" drinnen.
Ich habe es auf "LAN" gestellt und habe die Warnung, dass man sich ausschließen kann, akzeptiert.

Ich dachte standardmäßig ist das in OPNsense wegen Sicherheit deaktiviert??? Ist das normal?
Bei der Installation habe ich nur den NIC von "WAN" und "LAN" vertauscht, sonst nichts.

Grüße

Edit

Fehlalarm, auf die WAN IP kann ich nur vom LAN aus zugreifen

[Patrick M. Hausen]

Wenn Du aus dem LAN auf die WAN-IP zugreiftt, geht das nicht über das WAN-Interface. Geht zum LAN rein (erlaubt), wird als lokal erkannt, fertig.

Du müsstest es also tatsächlich von außen testen, z.B. über's Smartphone.

[_Alchemist_]

Ach ja natürlich, Loopback ...
Mit dem Shartphone komme ich nicht drauf.

Danke für die Antwort

[JeGr]

> Unter "System: Settings: Administration" --> "Listen Interfaces" stand "All (recommended)" drinnen.
Ich habe es auf "LAN" gestellt und habe die Warnung, dass man sich ausschließen kann, akzeptiert.

Das heißt ja lediglich, dass der Webserver per se auf "all" hört und sich somit theoretisch von allen Interfaces die eine IP haben aus erreichen lässt. Ob das WIRKLICH geht, hängt ja dann an den Regeln und Default auf WAN ist block all, somit ist es auch standardmäßig kein Problem.

Die Option gibt es für die, die wirklich nochmal die Sicherheitsschraube anziehen und Dienste gezielt auf Interfaces binden wollen, damit diese eben ggf. nur auf dieser Schnittstelle hängen und sonst nirgends, egal wie die Regeln sind. Das ist aber nicht unbedingt eine Situation, die man direkt nach einer Neuinstallation haben will

[chemlud]

Die Option gibt es für die, die wirklich nochmal die Sicherheitsschraube anziehen und Dienste gezielt auf Interfaces binden wollen, damit diese eben ggf. nur auf dieser Schnittstelle hängen und sonst nirgends, egal wie die Regeln sind. Das ist aber nicht unbedingt eine Situation, die man direkt nach einer Neuinstallation haben will

Öhm, doch, egal welchen Schachfug irgendein Anfänger als FW-Regeln auf das WAN klatscht "damit das Inet funzt !elf1!!" sollte wenigstens KEIN Zugriff auf die GUI möglich sein. Das sollte doch ausser Diskussion stehen.

Und auch der Zugriff aus einem LAN auf die GUI über die WAN-Adresse ist einigermassen überraschend, wenn man den Zugriff über FW-Regeln auf dem LAN z.B. auf einige ausgewählte Hosts beschränkt hat.

IMHO WAN gehört nicht in den default für die GUI...

[JeGr]

Du wirst immer einen Kompromiss eingehen müssen was Default Konfiguration angeht und damit Leute haben die anecken (wollen) wegen zu laschen oder (für sie) unverständlichen Defaults. Der Standard ist eben aktuell IMHO das Prinzip der geringsten Überraschung und das ist das Verhalten wie es andere Kisten auch haben.

Dass man die WAN IP via LAN erreichen kann ist aber recht normal (kann ich zumindest bei anderen Produkten mit Default pass any auf LAN problemlos nachvollziehen) und ist kaum überraschend - ich sitze ja schließlich auf "trusted" Seite. Warum sollte ich dann nicht auf alle Adressen des Geräts kommen?

IMHO ist das "LAN" für mich immer noch "falsch" benannt. Ich habe da schon länger dafür plädiert (egal wo) statt LAN einfach "MGMT" als Default auszurollen, denn gerade ein "pass any" und eine "anti-lockout" Regel möchte ich ggf. auf dem LAN vielleicht nicht so gerne haben, auf einem Management Interface sind die aber durchaus hilfreich und nützlich und ich gehe auch in einem Management Netz absolut von trusted IPs/IP-Range aus. Ich denke wenn man LAN als erstes als MGMT umbenennt und dann das erste OPT als wirkliches LAN einrichtet, passen die meisten Defaults wesentlich besser als wenn man das Default-LAN als wirklich echtes LAN sieht.

just my 2c

[franco]

Puh, kontrovers.

Das Binden an Adressen ist fragiler als auf alle Adressen zu hören -- so einfach wie "Interface" anbinden ist das leider nicht, zumindest nicht wenn man die FW-Regeln nicht verwenden darf.

Die einzige vernünftige Lösung ist ein Loopback mit Port Forward, es sei denn man zählt NAT-Regeln zu FW-Regeln, die "irgendein Anfänger [...] [dahin]klatscht". Aber auch da ist es vorbei wenn die Firewall abgestellt wird.

Irgendwie kann man nicht alles haben.

Weitere Sonderfälle: kein LAN Port, nur WAN, etc.


Grüsse
Franco

[Patrick M. Hausen]

Kein WAN-Port, nur LAN ... hier 

[JeGr]

> Franco:
> Irgendwie kann man nicht alles haben.
> Weitere Sonderfälle: kein LAN Port, nur WAN, etc.

Exakt, oder eben wie @pmhausen

> nur LAN hier

auch so ein UseCase. Da irgendwas halbwegs sicheres zu bauen dass Default auch ja alles blockt und ganz sicher nur ganz bestimmte Zugriffe erlaubt damit niemand sonst auf die UI kommt... Eh, nicht ganz so einfach wie man sichs vorstellt.

Und dass Geräte OOTB auch noch nicht max-security haben ist eigentlich nicht unüblich.

[franco]

Nach etwas Überlegung stellt sich die Frage ob hier nicht einfach nur nach einem "Lockout" Mechanismus gefragt wird in Anlehnung an den "Anti-Lockout" der GUI/SSH? Das würde das hätte-sollte-müsste der Thematik doch erübrigen?



Grüsse
Franco

[lfirewall1243]

Das Gerät ist nach der Installation sicher und erreichbar - das zählt.

Wenn man danach eine Allow Any Regel auf dem WAN macht - logisch dass die Sicherheit darunter leidet.
Der Großteil der OPNsense User hat aber ein Grundverständnis dafür, somit sehe ich da bis auf Einzelfälle kein Problem.
Andernfalls müsste man zuerst die gewünschten Regeln im Installationsassistent konfigurieren sowie alle automatischen NAT Regeln.


Außerdem steht nirgends in den Docs eine WAN Rule ohne Grund zu erstellen.
Den Fall, dass sich jemand nicht mit dem System auskennt und die Docs nicht liest kann man leider nicht abdecken - meine Meinung

[JeGr]

Nach etwas Überlegung stellt sich die Frage ob hier nicht einfach nur nach einem "Lockout" Mechanismus gefragt wird in Anlehnung an den "Anti-Lockout" der GUI/SSH? Das würde das hätte-sollte-müsste der Thematik doch erübrigen?

Zudem: Gibt es nicht eh schon den Lockout Mechanismus, dass nach x-falschen Anfragen via SSH/Logins eine IP für eine Zeit geblockt wird (fail2ban like)? Das sichert ebenfalls nochmal ab. Und auf WAN "alles" aufmachen und dann noch default user/pass aktiv haben - nuuuun... gegen alles kann man keine Blockaden einbauen Irgendwann muss man auch selbst für eigene Doofheit haften