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?
Neija, was heißt aber sonst? Ein DDoS auf den Domänencontroller ist auch nicht ohne… keiner kann sich mehr an irgendeinem Computer anmelden, keiner kommt mehr an seine Daten, du kommst nich mehr per ssh an den Server…
Ich denke, das ist schon ein Grund, der gut genug ist, oder nicht? Ich hatte das schonmal das ist ziemlich blöd, weil man keine Kontroller mehr hat …
Hi Dorian.
Ok – wird jetzt OT – aber mich interessiert dabei folgendes: Nehmen wir mal an, dass gerade ein DDOS-Angriff von div. Servern gegen meine IP-Adresse läuft … ist es dann nicht nahezu „egal“, ob die Anfragen direkt an der Firewall gedropped werden oder ob sie bis zum Server in grün durchgestellt werden? Ich bin nicht sicher, könnte mir aber vorstellen, dass in beiden Fällen nichts mehr geht; also auch keine Anmeldung an Diensten, die sich per LDAP anmelden müssen.
Im internen Netz sieht die Lage natürlich anders aus, wenn „nur“ die Firewall in die Knie gezwungen wird … aber von außen betrachtet??
Hast du da auch Erfahrungswerte?
Michael
Hi Michael,
Nicht mit lmn (ist schon länger her) aber es sieht folgendermaßen aus:
Wenn die Attacke gegen deinen LDAP Läuft, müssen bei jeder Anfrage Daten Verarbeitet werden. Jedes mal, wenn einer der ddos Server eine Anfrage schick, muss gescheckt werde, ob die gesendeten Zugangsdaten gültig sind, dann muss eine entsprechende Antwort geschickt werden. Das braucht Rechenleistung und das lässt deinen Server dann in die Knie gehen. Wennd ie Pakete einfach ander Firewall gedroppt werden, dann muss ja nichts verarbeitet werden, das ist also deutlich weniger rechenintensiv und dadurch auch viel robuster (genaue Zahlen kann ich da aber nicht sagen).
VG, Dorian
Klingt alles einleuchtend, bleibt trotzdem die Frage, ob man auch nur die Firewall damit in die Knie zwingen kann? Ausprobieren will ich das aber nicht