Hallo.
Ich frage mich nicht zum ersten Mal, ob man den Unifi-Controller selbst nicht so abschotten sollte, dass die Verwaltungsoberfläche von anderen Clients im WLAN nicht mehr über https (8443) / ssh (22) erreichbar ist. Das widerspricht natürlich der Idee, dass ein Captive-Portal / Voucher-System vom Controller ausgeliefert werden soll. Dennoch die Frage in die Runde:
Lasst ihr den Controller im gleichen Netzwerk wie die WLAN-Clients laufen oder trennt ihr beides und setzt eine zusätzliche Route, so dass sich der Controller z.B. im Servernetz befindet, während die WiFi-Geräte sich in einem anderen Netz tummeln? Einfacher ist natürlich ersteres – aber wird das auch so empfohlen?
Schönen Gruß,
Michael
Hallo Michael,
ohne
a. schon so weit zu sein und
b. das bisher in Gänze verstanden zu haben,
plane ich das so:
auf jeden Fall möchte ich das von Dir Genannte auch umsetzen!
Tut es das? Keine Ahnung.
Zumindest der Controller und die APs müssen aber ja im selben Netz sein. Ich bin mir noch nicht ganz sicher, ob das das Servernetz sein sollte, dort will ich eigentlich die APs nicht drin haben und ich präferiere daher derzeit unser Management-Netz. Dort kann ich den Controller und die APs dann remote managen und auch monitoren (ginge auch anders aber ok).
Klar benötigt der Unifi-Contoller dann eine Route in’s Servernetz, wenn er gegen das AD authentifizieren soll. Hab ich eingerichtet.
Die einzelnen WLANs (netzint-unifi-auth für Lehrer/Schüler, WPA2-PSK für schuleigene Geräte, Captive-Portal mit Vouchers für Gäste) werden dann weiteren, unterschiedlichen Netzen/VLANs zugeordnet. Wohin diese jeweils geroutet werden (Gäste direkt in’s Internet, Lehrer evtl. in’s pädagogische Netz, damit sie drucken und die Schulkonsole aufrufen können etc), muss ich mir auch noch genauer überlegen und das Routing einrichten.
Wie machen das Andere? Immer her mit ‚best practices‘!
Viele Grüße,
Jochen
Hallo!
Das Schöne bei Unifi: Die APs können in mehreren Netzen sein. Bei mir in Grün (untagged) und Blau (VLAN 20). Über Blau läuft das WLAN, dh. IP vom IPFire über DHCP, und die APs fragen dann in Grün beim Unifi-Controller nach, wer was darf. Dh. ein Nutzer im WLAN muss gar nicht den Unifi sehen (außer man will Captive Portal mit Vouchers für Gastzugänge). Aber da kann man ja in der Firewall ein dediziert kleines Loch bohren…
LG
Max
Guten Morgen,
bei Ueberlegungen bzgl. „Sicherheit“ sollte man aus meiner Sicht immer betrachten, was im Super-GAU passiert und das ist im paedagogischen Netz so gut wie ueberhaupt nichts, zumindest bei uns.
Wir bilden Fachinformatiker aus und da ist davon auszugehen, dass in jeder zweiten Klasse ein wirklich guter Hacker drinsitzt, der Rest ist technisch kaum in der Lage Systeme effektiv anzugreifen.
Was kann dieser Hacker machen?
- das System uebernehmen
- Daten von Lehrerhomes kopieren
- Sabotage von Diensten
…
Wenn ich anfange das Netz immer weiter zu segmentieren, Subnetze, VLANs, Firewalls,ACLs…mache ich das Netz unuebersichtlicher und schwerer zu warten.
Der Hacker schafft es trotzdem seine Privilegien zu eskalieren: Tastaturspion, Boot-Stick mit Veraendern der /etc/passwd bzw. shadow, ungesperrte Tastatur des Lehrers in der Pause nutzen, Lehrerpasswoerter, die aus Versehen auf dem Beamer erschienen sind nutzen und jede Menge andere Dinge, die in der Schule kaum in den Griff bekommen sind.
Soviel Sicherheit wie moeglich ist aus meiner Sicht kein sinnvoller Ansatz, der Anwendungsfall ist entscheidend.
Das Verwaltungsnetz hat ganz andere Anforderungen an Sicherheit wie das paedagogische, dort sollte man einen grossen Aufwand betreiben, im paedagogischen reicht eine einzige Sicherheitsluecke (regelmaessig gibt es fuer Linux Kernel-Exploits, so sicher wie das Amen in der Kirche, fuer Windows ist das Eskalieren von Priviligen sowieso kein Thema mehr, UAC ist schon immer kaputt.).
Ich wuerde mir keinen grossen Kopf machen bzgl. Unifi-Controller und in dort hinsetzen, wo ich einfach dran komme. Es ist wichtiger die Auswirkungen eines Super-GAUs gering zu halten, denn abwenden kann man ihn im schulischen Umfeld nicht wirklich - wenn einer will, dann kann er das.
Aber das ist Ansichtssache, Holger synct bei jedem Start um Bootsticks bzw.Veraenderungen am System zu verhindern, mir waeren diese zwei/drei Minuten zuviel, ich gehe aber immer davon aus, dass der Client uebernommen wurde, das bestimmt mein Handeln.
Wuerde also von einem Rechner im paedagogischen Netz z.B.kein Onlinebanking machen oder mich per root auf einem Mailserver draussen verbinden.
Gruss Harry
Hallo zusammen.
Ja, so etwas ähnliches habe ich mir auch schon gedacht. Ich denke, dass die allermeisten hier den Controller (bewusst oder unbewusst) im gleichen Netzwerk wie die WLAN-Clients haben.
Mittlerweile ich habe ich einen Einzeiler gefunden, wie man immerhin den unifi-Controller per eigener Firewall etwas abdichten kann, um z.B. ssh zu unterbinden. Vielleicht reicht so eine Maßnahme ja auch, bevor man sich an zusätzlichen Routen und der OPNSense-Firewall zu schaffen macht:
ufw reject from 172.16.0.0/21 port 22 to 172.16.16.253
ufw enable
ufw status numbered
{bei Bedarf auch: ufw delete 1 bzw ufw disable }… dabei ist der /21er Bereich bei uns der DHCP-Bereich für die WLAN-Clients und die .253 der Unifi-Controller im gleichen Netz.
ssh bekommt man so abgesichert. Aber der Zugriff via https:// muss imho ja weiterhin funktionieren, da natürlich ein CaptivePortal und ein Voucher-System vorhanden sein soll. Daher: Ob das wirklich zur Sicherheit beiträgt, sei mal dahingestellt…
Btw: Du schreibst, dass im Verwaltungsnetz viel schärfere Maßnahmen greifen sollten – da kommen aber andererseits auch viel weniger Leute hinein (was natürlich nichts heißen muss).
Übrigens sind wir ein „normales“ Gymnasium – der Anteil derer, die da richtig Ahnung haben und wirklich hacken könnten ist fast schon erschreckend gering…
Schöne Grüße,
Michael
Die dort anfallenden Daten sind wesentlich kritischer.
Noten der Schueler, Beurteilungen von Lehrern/Referendaren/… auf dem Netzlaufwerk der Schulleitung usw.usf.
Die Datenbank fuer das Zeugnisprogramm waere ja auch interessant. Bei uns liegt die „Wahrheit“ (Noten) noch in Akten, also so richtig mit Kugelschreiber usw. usf., die Datenbank wird daraus gefuettert.
Liegt die Wahrheit nur noch in der Datenbank, was in vielen Firmen bereits der Fall ist, dann wird das kritisch.
Firewallloesungen haben ja auch immer noch das Problem, dass Reverse-TCP-Verbindungen oft nicht erfasst werden, sind ja quasi der Normalzustand beim Surfen und das ist ja dann auch das Einfallstor bei einem Grossteil der (Windows-)Trojaner, Schadcode wird nachgeladen und baut eine Verbindung von Innen nach Aussen auf und offensichtlich tut das ja jaehrlich in Millionen von Faellen einwandfrei (aus der Sicht der Hacker). Dass hier einzig und alleine bei dem Betriebssystemhersteller (Microsoft) die Schuld zu suchen ist, ist ein anderes Thema und off topic.
Wie doof muss ein OS sein, dass ein Mailanhang (exe, js, vba…) Schadcode nachladen darf, diesen ausfuehren, die Festplatte nach bestimmten Datensaetzen durchsuchen und diese dann gleich noch zu tausenden verschluesseln und die Originale zu schreddern/ueberschreiben?
Alles ueber die API des Betriebssystems und ohne Nachfrage? Seltsamerweise wird das kaum reflektiert, Wellen von Verschluesselungstrojanern werden regelmaessig den boesen Russen/Chinesen/Hacker…zugeordnet und nicht dem unfaehigen Betriebssystemprogrammierern.
Diese Unfaehigkeit erstaunt irgendwie auch niemanden, selbst bei einem Tagesgewinn (!) von 129 Millionen Euro wird deren Faehigkeit nicht in Frage gestellt.Vielleicht sollte doch mal etwas davon ernsthaft in Sicherheit investiert werden, Schuldzuweisungen bringen bei Verbrechern naemlich nichts, eher bessere Schloesser.
https://orange.handelsblatt.com/artikel/50844
Gruss Harry
Edith: nochmal on topic, ich hab schon ernsthaft erwogen unser Wlan ohne Authentifizierung zu betreiben bzw. zumindest eine SSID deren Bandbreite ich zur Not begrenzen kann falls der Traffic zu hoch wird und keine „Unterrichtsnutzung“ mehr moeglich ist.
Bei einem offenen Netz gibt es irgendwie auch keinen Grund mehr sich auf den Controller zu hacken.