Jein, per VPN alle Services in grün… das geht über Dateizugriffe uU weit hinaus, meine ich?!
Remote Drucken wäre noch ein Aspekt. Aber ob das die Mühen (bei Vielen) wert ist?
Hallo Michael,
… ich weiß schon, was VPN ist und kann.
Du hast nun aber trotzdem keine weiteren Services genannt: was bleibt den noch übrig außer Dateizugriffen? Druckersteuerung? Nutzung des Proxys? …
… also mir fällt nix ein, was die Kollegen da von Zuhause aus bedienen können wollen würden was so wichtig ist, dass sie sich ein VPN installieren.
LG
Holger
Hallo Jochen,
warum sollten den die Lehrer von Zuhause aus drucken können?
Wer sortiert den dann den Blätterwald in der Druckerablage am nächsten Morgen?
LG
Holger
Hallo Holger,
hatten ein paar wenige Kollegen vor einiger Zeit mal gemacht. Gab nie Probleme, wurde aber auch nicht exzessiv genutzt.
LG,
Jochen
… das überrascht mich nicht 
Drucken wäre schon ein Argument. Aber auch der Zugriff auf irgendwelche Schüler-/Klassenlisten wären über VPN → grün relativ einfach machbar. Aber vermutlich ist das für die Mehrheit der Kollegen nicht soooo wichtig…
Hallo,
jetzt läuft’s, aber zu Beginn der Pandemie hätte ich mir manchmal gewünscht. dass die Lehrer von zu Hause aus Zugriff auf die Schuko haben, um die Passwörter ihrer Schüler selbst zu managen.
Viele Grüße
Wilfried
Hi. Ja, das sehe ich auch so: der Zugriff auf das WebUI ist tatsächlich nicht ganz zu unterschätzen, denn dann könnten die KuK zB auch von zu Hause aus schon mal Projekte anlegen und mit SuS füllen…
Viele Grüße
Michael
Hallo!
Die Webui kann man auch ohne VPN von außen erreichbar machen. Wem ein exponieren per Portweiterleitung Bauchschmerzen bereitet (ich gehöre dazu), der kann das über einen Webserver mit Reverse Proxy lösen.
Viele Grüße
Micha
1 „Gefällt mir“
Hallo.
Den Unterschied musst du mir nochmal erklären: Wenn das WebUI eigentlich nicht dafür gemacht ist, direkt im Internet exponiert zu sein – ist es dann nicht egal, ob da noch ein Reverse Proxy davor ist oder nicht?? Ich kann nicht abschätzen, was im schlimmsten Fall passieren könnte, wenn jemand mit dem WebUI irgendwelchen Blödsinn macht … wäre aber vielleicht nicht schlecht, diesen Fall hier zu diskutieren?
Übrigens: Die beiden Funktionen, die jeder Kollege imho unbedingt von zu Hause erreichen sollte, sind über die Landingpage von @dorian gut abgefangen: Ändern der eigenen eMail-Adresse und Ändern des eigenen Passworts. Daher ist die Dringlichkeit für „alle“ vermutlich künftig tatsächlich nicht mehr so hoch.
Viele Grüße,
Michael
Hallo!
Der Reverse Proxy sollte jedenfalls nicht im grünen Netz stehen. Bei mir steht er in der DMZ. Umgesetzt ist er mittels eines Apache, welcher ja regelmäßig Sicherheitsupdates bekommt. Ein Angreifer müsste zunächst den Server mit dem Reverse Proxy knacken und sich dann über die Webui hermachen. Besser als eine komplettes Portforwarding ins grüne Netz.
Als ich den reverse proxy eingerichtet habe, gab es die Landingpage noch nicht. Sicher eine gute Alternative.
VG
Micha
… bei mir läuft HAProxy als rev.Proxy direkt auf der OPNSense … ich weiß aber nicht, was der bessere/sicherere Weg ist.
Das nimmt sich wahrscheinlich nicht viel. Wenn die OPNSense regelmäßig ihre Sicherheitsupdates bekommt, ist das auch nicht anders. Mir war nur wichtig, die OPNSense möglichst schlank zu halten. Dafür hab ich eine VM extra.
VG
Micha
Hi,
Ich glaube, ihr wiegt euch da in einer Sicherheit, die ihr nicht habt. Ein Reverseproxy schützt von sich aus höchstens gegen Sicherheitslücken auf Protokollebene. Gegen Sicherheitslücken auf Anwendungsebene, also in der WebUI selbst, aber nicht. Zum Beispiel würde ein Reverseproxy gegen keine der hier angesprochen Probleme helfen.
Allerdings weiß ich nich, ob die Probleme in dem Artikel uns in der WebUI überhaupt betreffen, er ist ja auch schon relativ alt.
Ich habe deshalb bei mir in dem Reverseproxy nochmal eine HTTP Basic Authentication dazischen geschaltet, über die sich nur global-admins anmelden können. Das liegt nich an der WebUI, sondern daran, dass ich generell Bauchschmerzen damit habe, den Domänencontroller überhaupt direkt nach außen zu öffnen, denn ohne den funktioniert fast nix im Netz…
VG, Dorian
… das meinte ich ja oben als ich fragte:
Ok, damit meinst du nun aber nicht die Erreichbarkeit des AD über Port 636/3269, nehme ich an, sondern nur den Fall, dass andere Services wie z.B. das WebUI direkt ins Internet durchgereicht werden, ja?
Doch, ich meine alles. Auch diese Ports habe ich nur für die IP unseres externen bbb servers freigegeben.
Vielleicht bin ich da auch ein bisschen paranoid, aber ich will einfach verhindern, dass irgendein Trottel mit ner Ddos Attacke unser komplettes Netz lahmlegt …
VG, Dorian
OK, aber irgendwas muss ich hier schon freigegeben, da hier mehrere Dienste auf das AD zugreifen müssen… die sind nicht alle intern bei uns gehostet… 
Klar, aber du kannst ja bei der Portfreigabe auf bestimmte Quellnetze beschränken. Ich hab da für ldaps eben die IP unseres bbb Servers eingetragen.
VG, Dorian
Hallo,
eben: man gibt den Zugriff auf den LDAP von einem externen Gerät aus frei: also einem „Webserver“ (nextcloud, moodle, wiki … ).
Der darf dann beim LDAP anfragen: „Hey, ich hab da sel usernamen mit jenem Passwort: paßt das?“ und zurück kommt ein Ja oder Nein.
Der Zugriff ist nur lesend: würde man „in modole“ sein Passwort ändern können, dann wäre das zwar irgend wie bequem, aber das will ich nicht: der Zugriff soll ja sehr restriktiv sein.
Der Unterschied ist halt: es steht ein Server draußen und der darf sehr eingeschränkt fragen.
Das ist ein großer Unterschied zu: der Server steht drinnen (wie die WebUI oder eine Nextclodu in grün …)
LG
Holger
Ja, schon klar, allerdings darf das AD doch eh nur mit richtigen credentials ausgelesen werden. Soooo viel kann dann ein externer „Angreifer“ doch gar nicht anstellen? OK DDoS von mir aus… Aber sonst?