Archiv der Kategorie: Netzwerk

Benutzerprofile

Wir haben mit “roaming profiles” (wandernde Benutzerprofile) zu Windows XP Zeiten aufgehört, weil es immer wieder Probleme damit gab. Zum einen gab es zwar selten, aber immer mal wieder ein korruptes Profil, und zum anderen dauerte die Anmeldung extrem lange, wenn Benutzer grosse Dateien in ihrem Profil hatten.

Wenn sich ein Benutzer ohne wanderndes Profil zum ersten Mal an einem Computer anmeldet, wird eine Kopie des “default profile” für ihn angelegt. Änderungen die der Benutzer dann am Profil vornimmt, werden nur lokal gespeichert und sind bei einem anderen Computer nicht verfügbar. Die Benutzer sind entsprechend informiert und wissen, dass nur die Dateien auf den Netzlaufwerken wie z.B. das eigene Userhome gesichert werden. Dies hat sich auch durch die “Windows 7 Zeit” bewährt – viele Vorteile, ein paar wenige Nachteile.

Mit der Einführung von Windows 10 wollte ich das wieder einmal angehen. Vor allem, da das Einrichten des lokalen Profils doch einige Zeit dauert…

image

In einer schnellen virtuellen Maschine braucht die Ersteinrichtung des Profils 24 Sekunden, die zweite Anmeldung dann nur noch 2 Sekunden. Wenn man das auf 5-jährigen Laptops mit einer 5’400er Harddisk macht, dauert es entsprechend noch viel länger…

Also habe ich mich da mal ein wenig eingelesen. Aussagen wie diese lassen befürchten, dass wir auch die alten Probleme wieder bekommen:

“After using Roaming profiles for many years I think that „Best Practices“ are DON’T use them.”

User State Virtualization
Microsoft hat die “roaming profiles” seit den Windows XP Zeiten weiterentwickelt. Das Problem mit den zu grossen Profilen löst man am besten mit “folder redirection” (Ordnerumleitung). Die Kombination von “roaming profiles” und “folder redirection” nennt Microsoft ”User State Virtualization”. In diesem Technet Tutorial wird erklärt, was damit gemeint ist. Im zweiten Teil wird “folder redirection” genauer erklärt und im dritten die “roaming user profiles”.

image

User Experience Virtualization
Microsofts “User Experience Virtualization” (UE-V) gilt als Weiterentwicklung der “roaming profiles”. Gemäss diesem Blogbeitrag liegt der Vorteil darin, dass viel detaillierter entschieden werden kann, welche Teile der Userdaten wirklich wandern (roam). Microsoft sieht UE-V als Technik für grosse Umgebungen und verkauft es als Teil von MDOP (Microsoft Desktop Optimization Pack). MDOP ist nur für Software Assurance Kunden verfügbar. Mit unserer Schullizenz erfüllen wir das alles. Damit kommt UE-V für uns auch in Frage. Bei UE-V muss man einen Agent auf dem Windows Client installieren und konfigurieren. Bis jetzt habe ich aber noch nicht herausgefunden, ob bei der ersten Anmeldung dann nicht doch ein lokales Profil (vgl. oben) angelegt werden muss, das dann durch UE-V angepasst wird. Dann würde die Erstanmeldung auch lange wie bei lokalen Profilen dauern.

Was nehmen?
Als Schule haben wir andere Anforderungen als in einer Firma. Ein typisches Szenario ist, dass sich über 20 Schüler/-innen gleichzeitig in einem Raum mit nur einem Accesspoint über WLAN anmelden. Das Erstellen eines lokalen Profils aus dem lokalen “default profile” dauert Zeit (abhängig vom Client – CPU, Festplatte, …), benötigt aber keine WLAN Bandbreite. Roaming Profiles (optimiert durch folder redirection), werden vom und auf den Server kopiert. Wenn 20 Schüler/-innen je nur 100MB über WLAN holen, müssen 2 GB übers WLAN…

Ich kann im Moment also nicht sagen, wie ich das mit Windows 10 umsetze. Weiterhin nur lokale Profile, “roaming profiles” mit möglichst kleinen Profilen dank “folder redirection” und Profilausschlüssen oder doch “User Experience Virtualization”. Im Internet habe ich da keine abschliessende Antwort gefunden, bleibt wohl nichts anderes übrig, als eigene Tests durchzuführen.

Nachtrag
Nun habe ich einige Tests mit UE-V durchgeführt und bin nicht wirklich zufrieden. Für meine Tests habe ich unter Windows 10 den Sync Provider auf “none” gestellt. Scheinbar gibt es ein Problem mit den Offline Folders, das man lösen konnte, aber für meine Tests war “none” ausreichend (damit werden die Daten nicht lokal zwischengespeichert, sondern direkt in den SettingsStore auf dem Server geschrieben).

Problemlos funktioniert haben Änderungen am Bildschirmhintergrund und Einstellungen an Office Programmen (Word Autokorrektur und andere Einstellungen). Das Hauptproblem ist aber, dass immer zuerst ein lokales Profil erstellt werden muss, bevor UE-V Änderungen vornehmen kann. Die ganze Einrichtung (Bild 1 oben) dauert also mindestens so lange wie wenn man nur lokale Profile hätte. Ausserdem kam auch beim Start von Word auf einem neuen Computer erneut der Willkommensdialog und Outlook musste auch erneut eingerichtet werden (Einstellungen nach der Ersteinrichtung wurden dann aber problemlos synchronisiert).

UE-V ist also sicher eine schlanke, schnelle, einfach zu wartende Alternative zu Roaming Profiles, wenn Mitarbeiter immer an den gleichen Computern arbeiten. Sobald die Ersteinrichtung auf allen benutzten Computern abgeschlossen ist, funktioniert es schnell und problemlos. Unser Problem ist aber, dass die Schüler auf jedem neuen Computer (z.B. wenn sie einfach einen vom Laptopwagen nehmen) die Ersteinrichtung von Profil und Programmen abwarten müssten, bis UE-V die Synchronisation übernimmt. Also im Moment keine Alternative. Leider.

Nachtrag 2
Wir werden wieder wandernde Profile einsetzen. Das Vorgehen ist in diesem Beitrag dokumentiert.

Sophos UTM: Advanced Threat Protection

Die Sophos UTM bietet unter “Network Protection” –> “Advanced Threat Protection” eine Funktion an, mit der man das Netzwerk nach Malware überwachen kann. Dabei wird ausgenutzt, dass viele Malware eine Verbindung mit sogenannten “Command and Control” Servern aufnimmt, um Daten zu übermitteln oder neue Befehle entgegen zu nehmen. Wenn ein Computer versucht, eine Verbindung mit einem bekannten “Command and Control” Server aufzunehmen, wird die Verbindung geblockt und ein Alarm angezeigt (und per Mail verschickt).

image

Dies bietet neben einem lokal installierten Virenschutz auf den Clients eine weitere Barriere gegen Malware in einem Netzwerk. Genauere Informationen über den Vorfall erhält man, wenn man unter “Logging & Reporting” –> “View Log Files” –> “Advanced Threat Protection” –> “View” auswählt.

image

In dieser Datei wird angezeigt, welcher Client mit welchem Server Kontakt aufnehmen wollte. Dummerweise wird hier der DNS Server angezeigt.

image

Wenn die Malware eine Verbindung zu ihrem “Command and Control” Server über einen Domänennamen und nicht über eine fixe IP Adresse herstellen will, stellt der Computer zuerst eine DNS Anfrage an den DNS Server. Wenn dieser den Eintrag nicht selber liefern kann, stellt dieser eine weitere Anfrage an den externen DNS Server (häufig derjenige des Providers), um die entsprechende IP Adresse zu erhalten. Dies bedeutet also, dass auf der Firewall der DNS Server der erste ist, der eine Anfrage nach dem betroffenen DNS Namen resp. der IP auslöst. Dies ist meiner Meinung nach ein Fehlverhalten der UTM. Besser wäre es, wenn die DNS Abfrage zugelassen wäre (dies ist ja nur Verkehr mit dem vorgelagerten DNS Server) und erst der direkte Kontakt des Clients mit dem entsprechenden Server unterbunden würde. Dann könnte man im Logfile auch den Client identifizieren. Da ich nicht ganz sicher bin, habe ich eine Anfrage im Forum gestellt).

Da ich schon einmal so einen Vorfall hatte und wissen wollte, welches der betroffene Client ist, habe ich auf dem DNS Server Logging aktiviert. Weil das viel Last auf dem Server generiert, sollte man das nur zu Testzwecken aktivieren. Habe nun aber gesehen, dass es eine andere Möglichkeit gibt, die nicht so viel Last erzeugen sollte.

Auf jeden Fall findet man in den DNS Logs dann den Client, der die Anfrage ausgelöst hat, wenn man z.B. nach dem Domänennamen sucht (in meinem Fall cwporter).

image

Nun kann man diesen Client weiter überprüfen. Die beste ist wohl, den Client neu aufzusetzen, die zweitbeste, den Computer mit mehreren Virenscannern aus einer verlässlichen Umgebung zu testen und am Schluss kann man noch mit dem im Betriebssystem installierten Virenscanner einen Vollscan auslösen, was die unsicherste Methode ist.

Die Seite cwporter hat mit dem zweiten Weltkrieg zu tun.

image

Es ist also gut möglich, dass eine Lehrperson nur durch eine Internetrecherche auf diese Seite gekommen ist. Auch wenn auf dieser Seite ein “Command and Control” Server aktiv wäre (z.B. weil der Webserver gehackt wurde) wird der Alarm von der Sophos UTM reproduzierbar wieder ausgelöst, wenn man versucht, in einem Browser die Seite aufzurufen. Die UTM kann ja nicht entscheiden, ob eine Malware diesen Aufruf ausgelöst hat, oder ein Benutzer durch eine Internetrecherche. Es kann sich also genauso gut um eine sogenannte “false positive” Meldung handeln.

Auf jeden Fall handelt es sich bei Advanced Threat Protection um eine weitere sinnvolle Möglichkeit, sein Netzwerk gegen Malware zu schützen.

weitere VLANs

Wir haben in unserem Netzwerk 10 Standorte, die mit Glasfaser verbunden sind. Ausserdem sind noch zwei Standorte über eine WLAN Brücke und 3 Kindergärten über eine VPN Verbindung angebunden. An einzelnen Standorten gibt es noch zusätzliche Glasfaserleitungen z.B. zwischen Neubau und Altbau.

Bisher genügte es, das Netzwerk nur auf einem, nämlich dem Hauptswitch zu unterteilen (KISS Prinzip). Nun war es aber absehbar, dass uns bald die IP-Adressen in den einzelnen Subnetzen ausgehen. Es macht in dieser Grösse aber auch Sinn, den Broadcastverkehr weiter einzudämmen.

Da ich im Moment gerade drin bin und meist schnell vergesse, hier nur ein paar Stichworte als Gedankenstütze für ein anderes Mal anhand einer stark vereinfachten Skizze.

image

Ein Client aus dem Schulhaus B sollte mit den Servern kommunizieren können. Der Port, an dem der Client hängt muss ein Mitglied des VLAN 12 sein (untagged). Um das zu erreichen, muss man auf dem Switch im Schulhaus B (und auch Schulhaus A und Hauptswitch) das VLAN 12 erstellen und auf HP ProCurves danach dem Switch eine IP Adresse aus dem Subnetz zuteilen (im Beispiel 192.168.3.240):
#config
#vlan 12 ip address 192.168.3.240/24
#vlan 12 untagged 1-44

Die passenden Befehle findet man auch in diesem Beitrag.

Zwischen den einzelnen Switches verwende ich tagged Verbindungen, da nur so mehr als ein VLAN über eine Leitung geführt werden kann. Dabei müssen beide Endpunkte die gleiche “Technik” verwenden. Es muss also der Port 46 im Schulhaus A und der Port 45 im Schulhaus B ein “tagged” Mitglied von VLAN 12 sein (#vlan 12 tagged 45). Das gleiche trifft auch für die Verbindung zwischen Hauptswitch (#vlan 12 tagged 48) und dem Switch im Schulhaus A (#vlan 12 tagged 46) zu.

Bei meiner Umsetzung übernimmt der Hauptswitch das Routing, übersetzt also aus dem VLAN 12, das am Port 48 ankommt auf das VLAN 10, an dem die Server hängen.

Dann muss man noch schauen, dass der DHCP Server die einzelnen VLANs bedienen kann, also auf dem DHCP-Server die Bereiche anlegen und auf den Switches eine ip-helper Adresse eintragen. Wenn auf der Firewall ein Contentfilter arbeitet, muss man dem auch alle VLANs bekanntgeben. Die Adressen der Drucker müssen auch angepasst werden (sowohl bei der DHCP Reservierung als auch auf dem Druckserver wegen der neuen Adresse).  Damit man während der Arbeit die Verbindung zum Switch nicht verliert, sollte man die IP Adressen und das default Gateway des Switches im Auge behalten. Ansonsten muss man mit einem Laptop vor Ort auf den seriellen Anschluss des Switches zugreifen…

Die wichtigsten Befehle für die Umsetzung findet man hier und hier.

Wlan verbieten

Unsere Schullaptops verbinden sich mit einem WLAN Netzwerk, das mit dem internen Netzwerk verbunden ist und den Zugriff über einen Radiusserver und Zertifikate regelt. Daneben gibt es aber auch noch ein WLAN für die privaten Geräte von Lehrpersonen und Schüler/-innen mit dem man sich nach der Eingabe eines Tagespasswortes verbinden kann.

Nun gibt es aber Lehrpersonen oder Schüler/-innen, die die Schulgeräte mit dem WLAN für die Privatgeräte verbinden (wieso auch immer). Danach sind die Geräte nicht mehr mit den Servern verbunden, bekommen also keine Gruppenrichtlinien, Updates etc. Ausserdem können sich Benutzer, die kein lokales Profil haben (sich also noch nie an dem Gerät angemeldet haben), nicht anmelden.

Damit das nicht mehr passiert, kann man WLAN Netzwerke mit bestimmter SSID verweigern.

Dazu habe ich die bestehende WLAN Gruppenrichtlinie angepasst und unter “Computerkonfiguration” –> “Richtlinien” –> “Windows-Einstellungen” –> “Sicherheitseinstellungen” –> “Drahtlosnetzwerkrichtlinien (IEEE 802.11)” die Richtlinie angepasst.

image

image

image

Nun kann man die SSID eingeben und “Verweigern” auswählen.

image

Das richtige Netzwerk wird automatisch verbunden. Nach dieser Umstellung kann man sich aber auch manuell nicht mehr mit dem öffentlichen WLAN verbinden.

image

Content-Filter für SSL Seiten auf Sophos UTM einrichten

In diesem Beitrag habe ich beschrieben, dass wir neu auch https Verkehr scannen.

Um die https Filterung zu aktivieren, entfernt man unter “Web Protection” –> “Web Filtering” –> Registerkarte “HTTPS” das Häklein bei “Do not proxy HTTPS traffic in Transparent Mode” und wählt “Decrypt and scan”.

image

Damit wird nun der SSL Verkehr aufgebrochen und gescannt. Nun kann kann die SafeSearch Einstellungen der einzelnen Suchdienste erzwingen, indem man unter “Web Protection” –> “Web Filtering” –> Registerkarte “Policies” –> “Additional Options” die entsprechenden Häklein auswählt.

image

Damit wäre nun das Ziel erreicht. Eine entsprechende Bildersuche auf Google läuft nun dank SafeSearch ins Leere.

image

Wie in diesem Dokument beschrieben, reklamieren die Browser, dass das verwendete Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde.

image

Das Zertifikat findet sich unter “Web Protection” –> “Filtering Options” –> Registerkarte “HTTPS CAs” –> “Download”.

image

Das Zertifikat ohne privaten Schlüssel (.cer) kann nun über eine Gruppenrichtlinie auf alle Computer verteilt werden. Dazu importiert man das Zertifikat unter “Computerkonfiguration” –> “Richtlinien” –> “Windows-Einstellungen” –> “Sicherheitseinstellungen” –> “Richtlinien für öffentliche Schlüssel” –> “Vertrauenswürdige Stammzertifizierungsstellen”.

image

image

Danach funktioniert der Aufruf von https Seiten ohne Warnhinweis, da dem Zertifikat vertraut wird. Wenn man aber auf das Schloss in der Adresszeile klickt, sieht man, dass der Herausgeber des Zertifikats durch “Schule Altstaetten Proxy CA” ersetzt wurde.

image

Für die internen Computer ist also alles wie gewünscht umgesetzt. Ein Problem bleibt aber. Die privaten Geräte von Lehrpersonen und Schüler/-innen müssen das Zertifikat manuell auch installieren, wenn die Fehlermeldung nicht mehr kommen soll.

Sophos hat dafür die Domain fw-notify.net registriert, auf der aber nichts veröffentlicht ist. Die Sophos UTM besitzt aber diesen DNS Eintrag, der auf die UTM selber zeigt. Das Zertifikat ist so unter http://passthrough.fw-notify.net/cacert.pem erreichbar.

Da diese Seite nicht einfach zu merken ist, habe ich sie auf unserer Homepage verlinkt. Ausserdem habe ich den Hotspot so angepasst, dass man nach erfolgreicher Eingabe des Tagespassworts direkt auf diese Seite weitergeleitet wird.

image

Damit ist auch sichergestellt, dass alle, die unser WLAN benutzen, darauf hingewiesen wurden, dass SSL aufgebrochen wird.

Nachtrag
Das Zertifikat, das unter http://passthrough.fw-notify.net/cacert.pem erreichbar ist, kann unter Android nicht installiert werden. Daher muss für Android das Zertifikat anders abgespeichert werden. Dazu kann man das importierte Zertifikat unter Windows exportieren.

image

image

Das Zertifikat für Android muss man dann noch von .cer auf .crt umbenennen. So musste ich also zwei Zertifikate veröffentlichen, eines für Windows und iOS und ein anderes für Android.

Eine Anleitung für die verschiedenen Geräte findet sich hier.

Nachtrag 2
Der AppStore auf iPads funktioniert nach der Umstellung nicht mehr richtig. Ich habe unter “Filtering Options” –> “Exceptions” eine Ausnahme für “URL Filter” und “SSL scanning” für die Seiten von Apple und mzstatic (gehört zu Apple) erstellt. Danach funktioniert auch der AppStore wieder.

image

Content-Filter für SSL Seiten

Wir haben unseren Internetzugang von Swisscoms “Schulen ans Internet” Angebot auf einen lokalen Kabelnetzbetreiber gewechselt.

Damit sind wir auch selber zuständig für das vom Kanton verlangte “Web Content Screening”. Auch wenn einige Gründe gegen ein Aufbrechen des SSL Verkehrs sprechen (vgl. z.B. Blogbeitrag von Beat Döbeli), machen wir das nun auch.

MITMAweiss

  • Da der Kanton dies vorgibt, ist der Spielraum sehr klein. Wenn Schüler/-innen z.B. bei der Bildersuche von Google z.B. nach pornografischen Begriffen suchen, kommen sie definitiv auf Bilder, die zu den unerwünschten Inhalten gehören, die gemeint sind.
  • Auf den Computern in der Schule müssen nur Seiten aufgerufen werden, die einen schulischen Bezug haben. Wer den Personen, die Zugang zur Firewall haben, nicht traut, sollte private https Seiten nicht mehr in der Schule aufrufen.
  • Viele Seiten sind immer noch unverschlüsselt, dort kann jeder, der unterwegs Zugang zu dem Datenverkehr hat, mitlesen.
  • Die Daten liegen dem Serverbetreiber unverschlüsselt vor. Bei einer Google-Suche wertet Google alle gesuchten Daten aus und versucht ein Profil des Benutzers zu erstellen.
  • Wenn bei einem Mailprovider ein Spamfilter auf dem Server aktiviert ist, muss dieser auch alle Mails durchsuchen, um sie als Spam zu klassifizieren.

Trotz all dieser Gründe ist und bleibt es ein Eingriff in die Privatsphäre der Benutzer. Daher erscheint mir sehr wichtig, dass die Benutzer auf diesen Umstand hingewiesen werden. Wir haben daher auf unserer Homepage ein Dokument veröffentlicht, das auch technisch nicht so versierten Benutzern erklären soll, was denn da genau passiert.

Nachtrag
Hier ist beschrieben, wie man das mit einer Sophos UTM umsetzen kann.

Netzwerk testen mit iperf

Es gibt verschiedene Tools um den Netzwerkdurchsatz zu testen. Eine Zusammenstellung einiger Tools findet man z.B. hier.  Ich habe mich mal für das open-source Programm iperf entschlossen. Version 3 ist noch nicht verfügbar für Windows, daher verwende ich die Version 2, die man hier herunterladen kann.

Ein Computer muss als Server gestartet werden, der andere als Client. Der Server wird durch “iperf.exe –s” gestartet.

image

Mit “iperf –help” bekommt man die ganzen Parameter angezeigt, die man verändern könnte, wenn man z.B. den Server nicht mit den Standardwerten (TCP Port 5001, window size 64kb) starten möchte. 

image

Um den Client mit den Standardwerten zu starten, kann man “iperf –c “ip-adresse des Servers”” starten und bekommt dann die Bandbreite angezeigt.

image

Um nun z.B. Schwankungen auf den Grund zu gehen, könnte man ein Intervall (-i) während längerer Zeit (-t) testen. Also z.B. “iperf –c 10.11.1.100 –i 1 –t 60”. In der letzten Zeile wird dann der Schnitt angezeigt.

image

Man kann auch parallele Zugriffe simulieren, indem man den Parameter “-P” verwendet. Auch hier wird wieder in der letzten Zeile die Zusammenfassung angezeigt.

image

Mit iperf können auch udp Zugriffe getestet werden. Dazu muss der Server mit –s –u gestartet werden.

image

Auf der Clientseite muss der Parameter –u auch angegeben werden. Standardmässig wird die Bandbreite auf 1Mbit/s begrenzt, daher habe ich auch noch den Parameter –b 1000m angegeben.

image

Die Ausgabe im Bild oben bedeutet nun, dass 178 MBytes mit 149Mbit/sec verschickt wurden. Der Jitter beträgt 0.914ms und es gingen 0 Pakete verloren (0/126865).

Verbindung zwischen Sophos Accesspoints und Sophos UTM

Wir verwalten unsere Accesspoints von Sophos mit der Sophos UTM. Sobald ein Sophos Accesspoint am Netzwerk angeschlossen wird, versucht er Kontakt mit der Sophos UTM aufzunehmen. Dazu schickt er eine Anfrage an die Adresse 1.2.3.4 über den TCP Port 2712. Da die Adresse 1.2.3.4 im internen Netzwerk nicht existiert, wird sie durch die VLAN’s weiter nach “draussen” geroutet, bis beim Übergang zum Internet die Sophos UTM als Firewall und Gateway die Abfrage selber bearbeitet, statt weiter ins Internet zu leiten.

image
Quelle: http://www.sophos.com/de-de/support/knowledgebase/119131.aspx

Weiterlesen