Archiv der Kategorie: Netzwerk

Wlan mit Zertifikaten: Migration auf neuen Server

Es gibt verschiedene Möglichkeiten, wie sich ein Client an einem WLAN Accesspoint authentifizieren kann. Wir haben es so umgesetzt, dass die Laptops ein Zertifikat erhalten, mit dem sie sich an einem Radiusserver ausweisen müssen, damit sie Zugang ins Netzwerk erhalten.

wlan mit radius

  1. Der Laptop bekommt über eine Gruppenrichtlinie ein Zertifikat vom Zertifikatserver. Dazu muss der Laptop über ein Kabel am Netzwerk angeschlossen sein (z.B. beim Neuaufsetzen).
  2. Der Laptop stellt eine Verbindung mit dem Accesspoint her und weist sich mit seinem Zertifikat aus.
  3. Der Accesspoint gibt die Anfrage mit dem Zertifikat an den Radiusserver weiter. Dieser heisst bei einem Windowsserver NPS und muss nicht auf dem gleichen Server wie die PKI laufen.
  4. Der Radiusserver bestätigt dem Accesspoint die Gültigkeit des Zertifikates. Nun kann der Laptop eine Verbindung ins Netzwerk herstellen.

Diese Lösung hat diverse Vorteile. Zum einen lässt sie sich zentral verwalten. Ein weiterer Vorteil ist, dass niemand ein Passwort eingeben muss, dass vergessen oder weitergegeben werden kann. Ausserdem gilt diese Lösung als sehr sicher.

Migration Zertifikatserver

Wie man eine bestehende CA (Certificate Authority) migriert, wird auf dieser Technet Seite beschrieben. Auf dem Blog von Rachfahl findet man eine bebilderte Schritt-für-Schritt Anleitung. Dabei sollte der neue Server den gleichen Namen wie der alte haben. Ausserdem sollte der alte Server entfernt werden, bevor der neue eingesetzt wird. Wenn sich ein Problem ergeben sollte, ist der Rückweg versperrt. Auf dem Blog von Rachfahl wird die alte Zertifizierungsstelle zwar erst entfernt, nachdem die neue aufgesetzt wird, aber dies entspricht nicht dem empfohlenen Vorgehen gemäss der Technet Seite. Wenn man nach der Installation der neuen Zertifizierungsstelle die alte entfernt, könnte dies zu Problemen im Active Directory führen. Wie man die Einträge der CA im Active Directory findet, ist hier beschrieben. So habe ich mich aus diversen Überlegungen dazu entschieden, einen neuen Zertifikatserver aufzusetzen und den alten gar nicht zu migrieren.

Neuer Zertifikatserver

Gemäss diesem Technet-Blog-Beitrag spricht nichts dagegen, zwei PKI’s parallel zu betreiben. Aus den oben angetönten Gründen habe ich mich für diesen Weg entschieden. So habe ich also einen weiteren Server in der Domäne erstellt (diesmal kein Domänencontroller).

Dazu muss man eine neue Rolle hinzufügen.

image

image

image

Hier kann man die Zertifikatsdienste auswählen und muss diese dann auch noch bestätigen.

image

Nach diversen Klicks auf “Weiter” habe ich als Rollen “Zertifizierungsstelle” und “Zertifizierungsstellen-Webregistrierung” ausgewählt.

image

image

Nach erfolgter Installation wird im Servermanager angezeigt, dass man die Zertifikatsdienste noch konfigurieren muss.

image

image

image

Als Installationstyp wählt man Unternehmenszertifizierungsstelle und danach Stammzertifizierungsstelle. Dies genügt für unsere Zwecke. Wer sich dafür interessiert, wie man eine deutlich komplexere Struktur (multi-tier hierarchy) einsetzt findet in diesem Technetblog einen guten Einstieg.

image

image

image

image

Beim Namen für die Zertifizierungsstelle wird ein Name vorgeschlagen. Diesen kann man ändern, was ich aber nicht gemacht habe.

image

Bei der Gültigkeitsdauer habe ich grosszügig 10 Jahre genommen. So bekommen wir sicher keine Probleme bis zum nächsten Serverwechsel.

image

Nach ein paar “Weiter” Klicks ist die Konfiguration beendet.

image

Zertifikate automatisch verteilen

Die Zertifikate lassen sich automatisch über eine Gruppenrichtlinie verteilen.

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Automatische Registrierung

image

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Zertifikatdienstclient – Zertifikatregistrierungsrichtlinie

image

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Richtlinien für öffentliche Schlüssel –> Einstellungen der automatischen Zertifikatanforderung

Hier ein Zertifikat auswählen, das automatisch verteilt werden soll.

image

Tipp: Wenn man eine eigens erstellte Vorlage verwenden möchte (statt der Standardvorlage Computer), muss man die Schemaversion der Vorlage von 2 auf 1 ändern. Dazu kann man ADSI-Edit verwenden.

image

WLAN Profile verteilen

Da wir keine Passwörter eingeben, sondern uns mit einem Computerzertifikat authentifizieren wollen, verwenden wir ein PEAP-TLS Verbindungsprofil, das wir über eine Gruppenrichtlinie verteilen.

Computerkonfiguration –> Richtlinien –> Windows-Einstellungen –> Sicherheitseinstellungen –> Drahtlosnetzwerkrichtlinien (IEEE 802.11)

Durch einen Rechtsklick kann man eine neue Richtlinie hinzufügen.

image

Nun kann man der Richtlinie einen Namen geben und ein Infrastrukturprofil hinzufügen.

image

Hier kann man für ein Profil die entsprechenden SSID Namen hinzufügen.

image

Als Sicherheitsmethoden wird bereits WPA2-Enterprise mit AES Verschlüsselung vorgeschlagen, was im Moment die beste Sicherheit bietet.

Bei “Authentifizierungsmodus” wählt man “Computerauthentifizierung”. Ansonsten verliert der Computer die Verbindung, sobald sich jemand anmeldet. Dies könnte man umgehen, indem man auch Zertifikate für die Benutzer verteilen würde, was aber für unseren Einsatz nicht wirklich etwas bringt.

Bei “Netzwerkauthentifizierungsmethode” wählt man “Microsoft: Smartcard- oder anderes Zertifikat”. Durch einen Klick auf “Eigenschaften” kann man das Zertifikat angeben. Hier kann man einfach den Vorschlag “Zertifikat auf diesem Computer verwenden” akzeptieren. Unten muss man noch die Stammzertifizierungsstelle auswählen.

image

Radius Server konfigurieren

Die Clients bekommen nun also automatisch über eine Gruppenrichtlinie ein Zertifikat von der Zertifizierungsstelle (CA) und die passenden WLAN Einstellungen. Nun muss noch der Radiusserver (bei Microsoft Netzwerkrichtlinienserver NPS) konfiguriert werden. Dieser meldet den Accesspoints ob der Client eine Verbindung herstellen darf oder nicht (vgl. Grafik ganz oben).

Um NPS zu installieren, muss man über den Servermanager eine neue Rolle Netzwerkrichtlinien- und Zugriffsdienste hinzufügen.

image

image

image

Auf dem Radiusserver muss man nun die Clients (Accesspoints oder die Managementstation für die AP’s) hinzufügen und eine Richtlinie erstellen.

Um einen Client hinzuzufügen, macht man einen Rechtsklick auf “RADIUS-Clients” und wählt “Neu”.

image

Nun kann man Anzeigename, IP-Adresse und den gemeinsamen geheimen Schlüssel eintragen. Selbstverständlich muss man auf der Accesspoint-Seite die IP dieses Servers eingeben (resp. in meinem Fall anpassen) und den gleichen Schlüssel eintragen.

image

Mit einer Richtlinie kann man angeben, welche Voraussetzungen erfüllt sein müssen, damit der Radiusserver das OK für die Verbindung gibt. Man kann die Richtlinien manuell erstellen oder über den Szenario Assistenten erstellen lassen. Dazu wählt man bei “Erste Schritte” bei Standardkonfiguration “Radius-Server für drahtlose oder verkabelte 802.1X-Verbindungen” aus und klickt auf “802.1X konfigurieren”.

image

Im ersten Fenster wählt man “Sichere Drahtlosverbindungen” und gibt einen Namen für die Richtlinien.

image

Im nächsten Fenster könnten man die Radius-Clients hinzufügen. Einen habe ich schon vorher manuell hinzugefügt (vgl. oben).

image

Bei der Authentifizierungsmethode wählt man “Microsoft: Smartcard- oder anderes Zertifikat”

image

Nun kann man noch Benutzergruppen angeben. Dies habe ich nicht gemacht. Alle Computer mit gültigem Zertifikat dürfen sich bei uns über WLAN am Netzwerk anmelden, unabhängig vom angemeldeten Benutzer.

image

Auch Datenverkehrssteuerelemente werden in unserem Fall nicht benötigt.

image

Und so werden nun eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie erstellt, die man manuell überprüfen kann.

image

Wichtig ist nun noch, dass man die Radius-Clients auch so umstellt, dass sie sich mit dem neuen Radiusserver verbinden.

Zusätzliche Aufgaben bei einer Ablösung eines alten Servers

So wie das oben beschrieben ist, kann man WLAN mit Zertifikaten neu aufsetzen. Wenn man aber wie ich einen alten Server ohne Unterbruch der WLAN Verbindungen ablösen möchte, gibt es noch ein paar Dinge, die man beachten sollte.

Zertifikat des Radiusservers

Wir haben bei der Verteilung der WLAN-Profile über Gruppenrichtlinien angegeben, dass die Identität des Servers über dessen Zertifikat überprüft werden soll. Wenn wir nun den Radiusserver wechseln, weist sich der neue mit dem neuen Zertifikat aus, was vom Client nicht automatisch akzeptiert wird. Daher muss man beim WLAN Profil beide Server als vertrauenswürdige Stammzertifizierungsstellen angeben.

image

Damit der Client diese Änderung bei den Gruppenrichtlinien erfährt, muss er einmal am Netzwerk gestartet werden. Dies bedeutet, dass man einen Zeitpunkt festlegen und dies den Mitarbeitern mitteilen muss, bis zu dem alle Laptops einmal gestartet werden müssen. Falls ein Laptop in dieser Zeit nicht gestartet wurde, kann er danach nicht mehr automatisch eine Verbindung mit dem Netzwerk herstellen. Am einfachsten startet man ihn dann einmal mit eingestecktem Netzwerkkabel, damit er die Einstellung erhält und danach auch wieder automatisch eine Verbindung über WLAN herstellt.

Zertifikate der Clients

Da die beiden Zertifizierungsstellen (CA’s) im Active Directory eingetragen sind, vertrauen sie einander und auch den Zertifikaten voneinander. So spielt es also keine Rolle, von welcher Zertifizierungsstelle das Zertifikat des Clients ausgestellt wurde.

Solange die alte CA auch noch vorhanden ist, können beide Zertifikate ausliefern. Es kann aber nur eine CA Zertifikate ausliefern, die auch die entsprechende Zertifikatvorlage besitzt. Um die alte CA davon abzuhalten, neue Zertifikate auszuliefern, kann man also einfach die entsprechende Vorlage auf der alten CA löschen (in meinem Fall war das die Vorlage “Computer”).

image

Besser wäre eine duplizierte Vorlage, wie ich sie neu verwende. Dazu dupliziert man bei den Zertifikatvorlagen die Vorlage Computer.

image

 

Der neuen Vorlage habe ich den Namen “ComputerzertifikatWLAN” gegeben.

image

Wenn man nun nur bei der lokalen Zertifizierungsstelle des neuen Servers die Vorlage aktiviert, liefert auch nur dieser Zertifikate dieser Vorlage aus.

image

image

Sobald also alle Zertifikatvorlagen von der alten Zertifizierungsstelle gelöscht sind werden die Zertifikate von der neuen Zertifizierungsstelle ausgestellt. Wenn auf der neuen Zertifizierungsstelle die neu erstellte Vorlage die einzige für die Clientauthentifizierung ist, bekommen nun alle Clients ein solches Zertifikat, sobald sie ein neues anfordern.

Die alten Zertifikate bleiben aber bestehen, bis sie ablaufen, bei mir wäre das ein Jahr. Sinnvoll wäre es also, wenn die Clients schon vor Ablauf des Zertifikats ein neues beziehen, damit man den alten Server deinstallieren kann.

Die Zertifikate vom Computer kann man in einer Mangement Konsole (MMC) ansehen (mmc –> Datei –> Snap-In hinzufügen/entfernen –> Zertifikate –> Computerkonto) oder unter Windows 8 certlm.msc starten.

Wenn man einen Rechtsklick unter “Zertifikate (Lokaler Computer)” –> “Eigene Zertifikate” –> “Zertifikate” macht, kann man “Alle Aufgaben” –> “Neues Zertifikat anfordern…” auswählen und sich ein neues Zertifikat ausstellen lassen.

image

image

Man kann dies automatisieren, indem man bei den Zertifikatvorlagen die gewünschte auswählt und über einen Rechtsklick “Alle Zertifikatinhaber erneut registrieren” lässt.

image

Dies funktioniert aber leider nur mit duplizierten Vorlagen, die von mir damals verwendete Standard-Vorlage “Computer” lässt dies nicht zu.

Man kann auch mit dem Befehl “certreq” erreichen, dass ein neues Zertifikat von den Clients bezogen wird:

certreq -q -enroll -machine ComputerzertifikatWLAN

Diesen Befehl könnte man z.B. als renewcertificate.bat abspeichern und über SCCM an alle Clients verteilen. Windows 7 bringt aber eine Meldung wegen fehlender Berechtigung (obwohl die Berechtigung über den Weg mit der graphischen MMC ausreicht und der gleiche Befehl unter Windows 8 problemlos funktioniert).

Wenn man eine neue Vorlage erstellt und diese über die automatische Zertifikatanforderung verteilt, wird diese beim nächsten Start bezogen. So bekommen alle Computer schnell ein Zertifikat vom neuen Server. Somit kann demnächst der alte Server deinstalliert werden…

Ausgehende Ports auf der Firewall testen

Eine unserer Primarschulen plant ein Radioprojekt mit PowerUp Radio. Neben einer UKW Übertragung gibt’s auch einen Livestream auf der Webseite. Um das zu realisieren, werden gemäss Anfrage die TCP Ports 80, 81 und 5901 benötigt (NACHTRAG: Neu sind es die Ports 8000, 8001 und 5901). Diese müssen auf der Firewall geöffnet werden. Unser Problem ist, dass nach unserer Firewall auch noch die Firewall der Swisscom vom Projekt “Schulen ans Netz” steht.

Auf unserer Firewall (Sophos UTM) habe ich zwei “Service Definitions” und eine Gruppe für die beiden benötigten Ports erstellt.

image

Danach kann man eine Firewall Regel für die beiden Protokolle nach aussen erstellen.

image

Wenn man den Zugang nun testen möchte, benötigt man einen Server im Internet, den man auf diesen Ports ansprechen kann. Die Seite http://portquiz.net/ bietet so einen Service an. Man kann mit Telnet einen gewünschten Port ansprechen.

image

Bei einem Verbindungsfehler kann man auf der Firewall überprüfen, ob sie die Anfrage blockt.

image

In diesem Fall lässt die Firewall die Anfrage auf die IP von portquiz.net mit Port 5901 aber durch. Trotzdem wird die Verbindung nicht aufgebaut. Dies muss also an der Firewall der Swisscom liegen.

Wir haben zwei Zugänge ins Internet. Auf der einen Seite den Zugang über den Contentfilter von der Swisscom und auf der anderen Seite eine öffentliche IP von der Swisscom, um unsere Server zu veröffentlichen. Bei beiden hat es eine Firewall der Swisscom, die nur von den Kantonsverantwortlichen als eigentlicher Kunde konfiguriert werden kann.

Mit unserer Firewall kann man mit sogenannten Multipath Rules bestimmen, welcher Verkehr über welchen Zugang abgewickelt werden soll.

image

So konnte ich verifizieren, dass beim Zugang über die öffentliche IP sowohl Port 81 als auch Port 5901 von der Swisscom Firewall geblockt wird. Beim Zugang über den Contentfilter der Swisscom kommt Port 5901 durch, aber Port 81 wird geblockt.

Hier sieht man, wie sich Telnet auf dem Port 5901 verbindet und statt einer Fehlermeldung ein schwarzes Fenster angezeigt wird.

image

Jetzt muss ich also bei den Kantonsverantwortlichen ansuchen, dass sie mir den anderen Port auch noch öffnen. Schliesslich wollen wir ein erfolgreiches Projekt mit PowerUp.

Tablets: Technische Überlegungen

Wir haben bei uns eine Arbeitsgruppe Tablets, die die verschiedenen Aspekte einer 1:1 Ausstattung der Schüler/-innen ausleuchten und bis 2015 (Budget 2016) eine Empfehlung zu Handen des Schulrates machen soll (vgl. auch diesen Beitrag).

An einer weiteren Sitzung ging es darum, aufzuzeigen, was aus technischer Sicht zu beachten ist. Eine grössere Einführung hat Auswirkungen auf Netzwerk, Support etc. Die folgenden Gedanken haben keinen Anspruch auf Vollständigkeit, sondern sind das, was ich mir als Input für diese Sitzung für eine Schule unserer Grösse zurechtgelegt habe…

3 Strategien
Meiner Meinung gibt es 3 Strategien für eine 1:1 Ausstattung mit Tablets oder ähnlichen Geräten:

BYOD

  • BYOD steht für Bring your own device, Schüler/-innen bringen also ihr eigenes Gerät von zuhause mit in die Schule.
  • Die Schule stellt Geräte für Schüler/-innen, die keines zur Verfügung haben. Hier stellt sich die Frage, für wie viele Prozent der Schüler/-innen dies der Fall ist. Es ist schwierig, hier eine Schätzung zu machen, ich würde mal von 25% ausgehen.

Schule: iOS, Android, Win RT

  • Diese Geräte wurden entwickelt für den Privatgebrauch.
  • Mit den bei uns vorhandenen Möglichkeiten lassen sie sich NICHT zentral verwalten.
  • Die Geräte sind aber eingeschränkt verwaltbar mit zusätzlich zu kaufenden MDM (Mobile Device Management) Lösungen.

Schule: Win Pro

  • Solche Geräte sind durch bei uns vorhandene Lösungen wie SCCM und Gruppenrichtlinien verwaltbar.

Netzwerk
Es gibt grundsätzliche Auswirkungen auf unser Netzwerk, unabhängig von der eingesetzten Technik. Es ist zum Beispiel absehbar, dass der Internetzugang nicht genügen wird. Aber auch die Verbindungen zwischen den Schulhäusern kommen natürlich verstärkt unter Last.

Wir haben 11 angemietete Glasfaserleitungen zwischen den einzelnen Standorten, zwei weitere Standorte sind über eine Funkbrücke angebunden und zusätzlich 3 Kindergärten mit eigenem Internetzugang, die per VPN angebunden sind. Total stehen in diesem Netzwerk jetzt schon etwas über 350 Geräte.

Der Internetzugang steht beim Serverstandort und läuft im Moment mit 20Mbit/s up and down über Glas, was jetzt schon sehr wenig ist. Im Moment warten wir aber noch ab, was die Swisscom mit ihrem Gratisanschluss für die Schulen plant. Wahrscheinlich müssen wir in Zukunft für den Internetanschluss wieder bezahlen um eine genügend grosse Bandbreite zu erhalten.

Die Glasfaserleitungen funktionieren mit 1Gbit/s und kommen natürlich auch verstärkt unter Last, wenn weitere Geräte ins Netz kommen. Zum Teil sind noch Switches im Einsatz, die älter als 10 Jahre sind.

BYOD

  • Muss über ein Netzwerk laufen, dass vom internen Servernetz getrennt ist. Die internen Dienste wie Noten, Mail, Fileserver müssen funktionieren. Ungewartete Geräte haben in so einem grossen Netzwerk nichts verloren.

Schule: iOs, Android, WinRT

  • Auch diese Geräte lassen sich nicht vollständig zentral verwalten und gehören daher auch nicht ins interne Netzwerk, sondern müssen von diesem getrennt werden. Dies ist aber, wie auch bei BYOD, kein Problem. Wir haben die Möglichkeit, ein Wlan Netzwerk unabhängig vom internen Netzwerk anzubieten. Unter Umständen kann es für die Schüler ein Nachteil sein, nicht auf den Server zugreifen zu können um beispielsweise Dateien auszutauschen oder auch für die Lehrperson, die keinen Zugang zum internen Netzwerk (Lehreroffice, Userhome,…) hat. Dateien können aber über z.B. über einen Cloudspeicher ausgetauscht werden, dazu später aber noch mehr.

Schule: Win Pro

  • Windows Pro Tablets haben das gleiche Betriebssystem wie unsere Feststationen und Laptops (sobald wir auf Windows 8.1 gewechselt sind). Damit lassen sie sich auch genau gleich wie die bisherigen Geräte mit bereits vorhandenen Möglichkeiten zentral verwalten und können daher wie die bisherigen Geräte im internen Netzwerk betrieben werden. Damit besteht auch ein Zugang zu internen Ressourcen wie Dateien (oder Lehreroffice für die Lehrpersonen) oder auch Druckern. Trotzdem müsste wohl zusätzlich eine Möglichkeit geschaffen werden, von ausserhalb auf die Daten zugreifen zu können, wie oben erwähnt z.B. über einen Cloudspeicher.

Netzwerklast
Bei einer 1:1 Ausstattung werden wir deutlich mehr Netzwerklast haben. Wenn z.B. also eine ganze Klasse eine Audiodatei vom Internet herunterlädt, um sie im eigenen Tempo anzuhören oder wenn alle einen Youtubeclip ansehen, um z.B. Hörverständnisfragen im Englisch zu beantworten, bedeutet das auch mehr Bandbreite als wenn nur die Lehrperson diese Datei herunterlädt oder streamt. Einen Teil davon kann unser Proxy durch Zwischenspeicherung abdecken, aber es gibt auch Dateien, bei denen das nicht funktioniert oder die jeder einzelne in einen Cloudspeicher speichert oder herunterlädt.

Im Moment haben wir noch einen unterdimensionierten Internetzugang von der Swisscom, der dafür gratis ist. Voraussichtlich werden wir so oder so einen schnelleren benötigen. Der nächste Flaschenhals könnte dann irgendwann auch das interne Netzwerk sein. Die Schulhäuser sind mit Glasfaserleitungen verbunden, die maximal 1Gbit/s übertragen können. Je mehr Geräte im Netzwerk sind, desto mehr Geräte teilen sich auch diese Bandbreite. Über das gleiche Netzwerk läuft interner Netzwerkverkehr (Zugang zum Dateiserver, Zugang zum Mailserver, Zugang zu Lehreroffice, Verteilung von Software, …) und externer Verkehr zu Onlinespeicher etc.

BYOD
und
Schule: iOS, Android, Win RT

  • Jedes Update wird von jedem Gerät einzeln angefordert. 100 Geräte brauchen für ein Update also 100 mal so viel Daten wie ein Gerät.

Win Pro

  • Mit WSUS resp. SCCM hat Microsoft eine Möglichkeit implementiert, mit der Updates nur einmal auf einen Updateserver heruntergeladen werden müssen und von dort dann auf die einzelnen Geräte gelangen. Mit BITS werden Updates so verteilt, dass in Abhängigkeit von vorhandener Bandbreite das Tempo bestimmt wird.

Da wir unser WLAN mit einer Sophos UTM beim Internetzugang verwalten, können wir dort auch Quality of Services Regeln bestimmen, um auszuschliessen, dass z.B. keine Stellwerktests mehr funktionieren, weil alle iOS oder Android Geräte ein Update gleichzeitig herunterladen.

Laptops

BYOD

  • Wenn alle Schüler/-innen ein eigenes Gerät mitbringen, haben wir keine gemeinsame Grundausstattung. Dies bedeutet, dass wir weiterhin Laptops im Netzwerk benötigen, auf denen z.B. der Stellwerk-Test oder andere Seiten, die nicht auf allen Geräten laufen, funktioniert. Ausserdem setzen wir diverse Software ein, die nicht auf allen mobilen Geräten lauffähig ist, wie Logisch, envol und vieles mehr. Auch die PISA Tests in diesem Jahr laufen auf den vorhandenen Laptops, weil die Informatikzimmer zu wenig gleichzeitige Arbeitsplätze bieten. Andere Software wie das Tastaturschreiben scheitert dann allenfalls an der fehlenden Tastatur, auch wenn man noch eine passende App für alle verschiedenen Systeme finden würde. Im Moment könnte also auf die vorhandenen Laptops kaum verzichtet werden.

Schule: iOs, Android, WinRT

  • Auch bei diesen Geräten könnte aus den oben genannten Gründen im Moment noch nicht auf die Laptops verzichtet werden.

Schule: Win Pro

  • Auf Win Pro Geräten läuft neben den Apps aus dem Store auch alle andere Software, die wir bis jetzt einsetzen. Diese könnte durch die vorhandenen Abläufe auch auf diese neuen Geräte installiert werden. Allenfalls kommen aber noch Lizenzkosten hinzu, wenn Software auf so vielen weiteren Geräten installiert wird. Zumindest bei den Microsoft Programmen inkl. Office ist das aber nicht der Fall, weil da nicht mehr pro Gerät lizenziert wird, sondern pro «Vollzeitäquivalent» der Lehrkräfte.
    Noch ein Gedanke zu den Officeprodukten: Es wird zwar immer wieder betont, dass man nicht Produkte üben soll, sondern Strategien. Dies ist grundsätzlich auch richtig. Trotzdem ist es im Moment halt auch eine Tatsache, dass die Lehrbetriebe von unseren Schülerinnen und Schüler Grundkenntnisse in den Officeprodukten erwarten.

Im Moment ist es so, dass nur mit einem vollwertigen Laptopbetriebssystem auf die bestehenden Laptops verzichtet werden kann, bei unserem Windowsnetzwerk macht MacOS keinen Sinn, daher kommt nur Windows Pro in Frage. Bei Geräten mit iOS, Android oder auch Windows RT würden die bestehenden Laptops auch in Zukunft gebraucht.

Support

BYOD

  • Die meisten Geräte gehören den Schüler/-innen, somit wären sie auch für diese zuständig. Die Frage ist, wie viel Support zusätzlich überhaupt noch geleistet werden muss. Dann bleibt auch noch die Frage, wer diesen Support leistet. Grundsätzlich lassen sich die Geräte nur bedingt zentral managen, daher müsste wohl auch der Support dezentral ausgelegt werden (wenn es denn diesen überhaupt braucht).

Schule: iOs, Android, WinRT

  • Auch hier ist es so, dass man die Geräte nur bedingt zentral verwalten kann, sich also ein dezentraler Support anbieten würde.

Bei beiden Strategien könnte man allenfalls mit Mobile Device Management Lösungen wie AirWatch, MobileIron, Sophos Mobile Control oder Microsoft Intune bestimmte Dinge automatisieren, aber auf den ersten Blick scheint es eher um Dinge zu gehen, die bei uns nicht gleich stark von Bedeutung sind wie bei Firmen. Gleichzeitig kommen noch hohe Kosten hinzu, so dass man sich fragen muss, ob man nicht besser ganz darauf verzichtet. Diese und ähnliche Lösungen müsste man aber auf jeden Fall noch genauer ansehen.

Schule: Win Pro

  • Diese Geräte lassen sich mit Gruppenrichtlinien und SCCM vollständig verwalten. Damit verwalten wir im Moment 350 Geräte zentral. Sobald wir auch die Feststationen auf Windows 8.1 migriert haben, ist die Vorgehensweise die gleiche wie mit zusätzlichen Tablets, Convertibles oder…. unter Windows 8.1. Mit den gleichen Servern könnten, ohne zusätzliche Lizenzkosten, auch noch ein paar hundert weitere Geräte verwaltet werden.

Pädagogischer Support
Unabhängig vom Betriebssystem ist es sehr wichtig, pädagogischen Support zu leisten. Kurse, die Beispiele von Anwendungen etc. aufzeigen, können weiterhin auch zentral angeboten werden. Anwendersupport bei auftretenden Fragen muss aber vor Ort gelöst werden. Ob dann die Entlastung für die Supporter in den einzelnen Schulhäusern ausreicht, ist fraglich. Allenfalls müsste dieser zumindest in einer Einführungsphase ausgedehnt werden.

Apps / Software

BYOD

  • Die Schüler/-innen haben einen eigenen Account im entsprechenden Store. Bei kostenpflichtiger Software müsste ein Gutschein oder eine Gutschrift für die Software zur Verfügung gestellt werden.
    Mit einer Mobile Device Management Lösung könnte es allenfalls möglich sein, Software auch zentral zu kaufen und dann auf die Geräte zu verteilen (und dann nach Austritt auch wieder zu löschen um sie für einen anderen Account freizustellen). Wie teuer solche Lösungen sind, wie komfortabel die Bedienung ist und viele ähnliche Fragen, müssten zuerst geklärt und getestet werden. Erste kleinere Recherchen deuten auf hohe Kosten bei beschränktem Funktionsumfang hin.

Schule: iOS, Android, WinRT

  • Hier stellt sich die Frage, ob die Geräte durch die Schüler/-innen gewartet werden oder durch die Lehrperson oder durch einen Supporter vor Ort.
    Wie bei BYOD stellt sich auch hier die Frage nach einer MDM Lösung und deren Kosten und Möglichkeiten. So weit ich weiss, bietet z.B. Apple noch keine Volumenlizenzen in der Schweiz an. Ausserdem bietet der Apple eigene Konfigurator nur die Möglichkeit 30 Geräte zu verwalten, ausser es hätte sich in letzter Zeit da etwas geändert. Auch hier stellen sich also noch viele Fragen, die geklärt werden müssten. In unserem Pilotprojekt mit iPads wird alles von der Lehrkraft bewältigt.

Schule: Win Pro

  • Die Verwaltung ist die gleiche, wie bei den bereits vorhandenen Geräten.
    Es bleiben aber noch offene Fragen bezüglich Windows Store Apps, die sich nicht gleich verteilen lassen, wie andere Windows Anwendungen. Diese offenen Fragen müssen aber auch beim Upgrade der vorhandenen 350 Clients geklärt werden.
    Bei diesen Geräten kann auch alle andere Software verwendet werden, für die wir im Moment noch die Laptops einsetzen. Lernsoftware, Programmiersoftware z.B. für den Robotikkurs mit Lego Mindstorms, Officeanwendungen, Bildbearbeitung, Internetseiten mit Flash oder Java, Tastatursoftware, …. Es kann jederzeit ein USB Stick eingesteckt werden oder eine Filmkamera im Lager oder eine USB Tastatur fürs Tastaturschreiben oder…

Beamer
Um das Bild der mobilen Geräte auf den Beamer zu bringen, sollte dieser nach Möglichkeit einen zweiten Anschluss haben, am besten einen HDMI Anschluss. Ansonsten müsste man Umstecken oder nach einer technischen Lösung suchen, die zwischen zwei Eingängen umschalten kann.

BYOD

  • Um die Inhalte der Geräte auf einen Beamer zu bekommen, benötigt man sowohl ein Miracast fähiges Gerät als auch einen Apple TV. Diese erstellen ein neues Wlan, mit dem sich die Geräte verbinden können und über das der Bildschirminhalt dann übertragen wird.

Schule: iOs, Android, WinRT

  • Hier kann man sich auf eines der beiden Geräte beschränken

Schule: Win Pro

  • Hier kann man sich auf eines der beiden Geräte beschränken

Stift
Sollen die Schüler/-innen auf dem Tablet auch von Hand schreiben (nicht nur mit der eingeblendeten Tastatur) oder zeichnen, gibt es grosse Unterschiede in der Bedienung. Bei manchen Tablets muss man einen Stift verwenden, der einen Finger nachahmt (kapazitiv), bei anderen ist eine Stifterkennung z.B. über eine Lösung von Wacom (Digitizer) eingebaut. Diese sind genauer, können Druckstufen erkennen und man kann die Handballen auflegen. Das Schreiben ist viel ähnlicher zum «analogen Schreiben» als mit kapazitiven Stiften. Es gibt Android Tablets und Windows Tablets mit Digitizern, aber keine iOS Geräte.

Verwaltung

BYOD

  • Wenn ein Exchange Konto eingerichtet wird, können z.B. Kennwortrichtlinien durchgesetzt werden, was für Firmen wichtig sein könnte, bei uns aber nicht wirklich.
    Mit zusätzlichen MDM Lösungen ist weiteres möglich, müsste aber noch genauer abgeklärt werden. Die Frage ist, ob das überhaupt notwendig ist.

Schule: iOs, Android, WinRT

  • Bei iOS gibt’s den Konfigurator (max. 30 Clients), oder die Server App von MacOS. Ansonsten müsste wie oben auch auf externe Lösungen (MDM) zurückgegriffen werden. Auch hier stellt sich die Frage, ob die Schüler/-innen ihr Gerät nicht besser selber verwalten sollten.

Schule: Win Pro

  • Mit SCCM verwalten wir unsere Windows Clients bisher. Mit dem gleichen Produkt werden andernorts erfolgreich tausende bis zehntausende Clients verwaltet. Die Apps aus dem AppStore werden aber anders verwaltet. Dazu kann man z.B. Windows Intune verwenden. Hier habe ich noch keine Erfahrung, da wir immer noch Windows 7 auf unseren Clients einsetzen. Dieses Problem müssen wir aber auch für die bestehenden 350 Clients angehen.

Die Frage ist also auch, wie weit die Geräte verwaltet werden müssen. Wenn jeder Schüler und jede Schülerin sein Gerät selber verwaltet und das Netzwerk von den internen Ressourcen getrennt ist, könnte man wahrscheinlich ganz auf eine Verwaltung verzichten. Es bleiben dann aber immer noch Fragen. Wer verwaltet (wie) die Geräte der Schüler/-innen, die kein eigenes Gerät mitbringen? Wlan Passwörter, Mail Einrichtung, Apps installieren etc. müsste durch die Schüler/-innen erledigt werden. Dies sollte aber eigentlich kein Problem darstellen, auch hier wird gelernt.

Cloud
Diese Überlegungen treffen auf alle Lösungen zu. Um auch ausserhalb des Netzwerks auf Daten zuzugreifen, muss eine Dateiablage von ausserhalb zugänglich sein. Die Datenschützer der Schweiz empfehlen Schulen aus datenschutzrechtlichen Gründen auf Dienste wie Dropbox zu verzichten. Es gibt mehrere Möglichkeiten.

  1. Wir setzen uns über diese Empfehlung hinweg, wie das im Moment viele andere Schulen und unser Pilotprojekt auch machen.
  2. Wir evaluieren einen Cloudanbieter, der den empfohlenen Datenschutzansprüchen genügt. Hier kann es wieder Probleme geben, dass dieser Anbieter nicht einfach über Apps erreicht werden kann. Dropbox wird von den meisten Apps als Speicherort angeboten.
  3. Wir setzen den Schweizer Bildungsserver Educanet2 ein. Da gibt es im Moment eine kostenpflichtige App für iOS und sonst den Zugang über die Weboberfläche oder Webweaver für Windows (nicht touchoptimiert).
  4. Wir setzen selber einen Speicherplatz auf, der von aussen erreicht werden kann. Entweder bei uns vor Ort, oder bei einem Hosting Provider. Dazu könnte man z.B. OwnCloud verwenden, allenfalls auch Sharepoint.
  5. Wir arbeiten mit einer Remotedesktoplösung. Die Schülerinnen und Schüler verbinden sich über ein Remotedesktopgateway mit dem Server und haben so von überall her Zugriff auf ihre Dateien im internen Netzwerk. So würden die Daten unser Netzwerk auch nicht verlassen. Es gibt neben Windows sowohl für Android als auch für iOS einen Remotedesktopclient der auch eine Verbindung von aussen über ein Remotedesktopgateway herstellen kann.

BYOD

  • Es ist darauf zu achten, dass für alle Plattformen ein Weg zum Onlinespeicher vorhanden ist. Im internen Netzwerk kann nicht auf die Dateifreigaben der Schulserver zugegriffen werden (vgl. Netzwerk).

Schule: iOs, Android, WinRT

  • Es muss nur darauf geachtet werden, dass für die gewählte Plattform ein Weg zum Onlinespeicher vorhanden ist. Im internen Netzwerk kann nicht auf die Dateifreigaben der Schulserver zugegriffen werden (vgl. Netzwerk).

Schule: Win Pro

  • Im internen Netzwerk können die normalen Dateifreigaben verwendet werden. Durch das vorhandene Dateisystem können Dateien auch lokal gespeichert werden, damit man diese zuhause bearbeiten kann. Für Zugang von zuhause könnte trotzdem ein Clouddienst oder Remotedesktop eingesetzt werden.

Rechtliches
Auch rechtlich gibt es noch einige offene Fragen. Dies sind nur ein paar wenige Gedanken:

  • Wer haftet, wenn das Gerät kaputt geht. Diese Frage stellt sich bei den privaten Geräten, als auch bei denjenigen, die die Schule zusätzlich oder ausschliesslich zur Verfügung stellt.
  • Wer haftet, wenn durch das schulische Netzwerk private Geräte mit Malware infiziert werden?
  • Ist die Schule verantwortlich für die Inhalte auf den Geräten? In der Schule betreiben wir einen Contentfilter, zuhause ist das schwieriger. Können solche Fragen durch Benutzerreglemente gelöst werden?
  • ……….

Fazit

Wie oben erwähnt sind diese Gedanken ohne Anspruch auf Vollständigkeit. Ich meine aber, es sei mir an unserer Arbeitsgruppensitzung gelungen, mit diesen Punkten aufzuzeigen, dass es nicht damit getan ist, einfach ein paar Geräte zu kaufen, sondern dass bei einer grösseren Einführung vieles beachtet werden muss.

image

Es gibt verschiedene Hürden (Lehrpersonen, Finanzen, Schulrat, Eltern,…), unter diesen eben auch die Technik. Im Moment haben wir 350 Geräte im Netzwerk, wenn wir mit 1:1 Ausstattung arbeiten würden, kämen doch ein paar dazu (je nachdem, ab welcher Stufe man beginnen möchte – wir haben im Moment nur schon knapp 450 Oberstufenschüler/-innen).

Nichts ist schwerer vorauszusagen als die Zukunft. Aber im Moment sieht es so aus, als ob 1:1 Ausstattung die Zukunft sein wird – früher oder später. Eine gute Planung kann helfen, auftretende Probleme vorherzusehen, aber im Moment ändert sich alles so schnell, dass es sogar schwierig ist, gut zu planen…

Apple Mail Problem mit Exchange Reverse Proxy

Wir haben unseren ISA Server durch eine Sophos UTM ersetzt. Statt den Exchangeserver über die Firewall direkt ins Internet zu stellen, kann die Sophos UTM als Reverse Proxy auftreten, der die Anfragen aus dem Internet entgegen nimmt und dann an Exchange im internen Netzwerk weitergibt. ISA konnte dies auch und war mit ein Grund, wieso wir vorher ISA eingesetzt haben.

Sophos macht Werbung damit, dass sich die UTM als Ersatz für TMG (Nachfolger von ISA) eignen würde:
image

Im Zusammenhang mit Exchange hat auch alles gut ausgesehen, die Einrichtung war einfach, das Forum gibt schnell und kompetent Antwort, Outlook Web Access, Outlook Anywhere und ActiveSync funktionieren ohne Probleme.

Leider gibt es doch ein Problem. Wir haben einige Lehrkräfte, die sich von zuhause mit ihrem Mac auf den Exchangeserver verbinden. Wenn eine Lehrkraft über Apple Mail eine Mail verschickt, kann es vorkommen (nur manchmal), dass die Absenderadresse vertauscht wird. Das grösste Problem dabei ist, dass der vertauschte Absender die Mail unter seinen gesendeten Objekten findet, was natürlich ein absolutes No-Go ist. Wenn plötzlich Mails von anderen gelesen werden können, ist das Vertrauen in das schuleigene Mailsystem schnell dahin.

Ich habe dann recherchiert und eine Anfrage an das Sophos Forum gestellt. Auf den Technet Seiten von Microsoft bin ich dann auf ein ähnliches Problem gestossen. Auch da war das Problem der Reverse Proxy, aber als Reverse Proxy wurde ein Apache Webserver eingesetzt. Daher konnte ich den dort beschriebenen Workaround nicht bei uns einsetzen. Hier muss ich warten, bis Sophos das gelöst hat. Bei einem so grossen Problem kann ich aber nicht einfach abwarten. Also musste ich eine andere “Lösung” des Problems suchen.

Der einzig sinnvolle Weg im Moment war, die Kommunikation mit Apple Mail zu unterbinden. Wir bieten ja auch noch Outlook Web Access und ActiveSync für unsere Lehrpersonen an, um die Mails von zuhause zu bearbeiten. Dazu kommt sogar noch ein Zugang über einen Remotedesktopserver, um von zuhause aus zu arbeiten, was auch mit der neuen MacOS App funktioniert. Apple Mail kommuniziert mit Exchange über EWS und nicht über Mapi wie bei Outlook Anywhere. EWS wird aber auch sonst benötigt und kann nicht einfach deaktiviert werden. Mit set-organizationconfig lässt sich ab Exchange 2010 SP1 der Zugang zu EWS detaillierter konfigurieren. Leider funktioniert das unter Exchange 2007 noch nicht. Da musste ich noch was anderes suchen. Microsoft hat im Technet einen Artikel “Using URL Rewrite to block certain clients from Exchange” veröffentlicht. Damit kann man erreichen, dass der IIS, der die Seiten für den Exchangeserver ausliefert, für gewisse Bedingungen eine Fehlermeldung statt der Seite ausliefert. 

Nach der Installation vom URL Rewrite Module 2.0 findet man im IIS Manager einen neuen Eintrag “URL Rewrite”. Weil Apple Mail ja auf EWS zugreift, muss man dieses Verzeichnis auswählen (ansonsten könnte man ja mit einem Mac z.B. auch nicht mehr auf Outlook Web Access kommen) und eine neue Anforderungsblockierungsregel hinzufügen. 

image

Unter Protokollierung findet man den Speicherort der Logfiles vom IIS. Standardmässig ist das %SystemDrive%\inetpub\logs\LogFiles. Dort sieht man, dass sich der User-Agent mal als Mac+OS+X und manchmal als Mac_OS_X zu erkennen gibt.
image

Somit kann man in der Anforderungsblockierungsregel den Zugriff aufgrund des Benutzer-Agent-Header blockieren, wenn er dem Muster *Mac* entspricht. Falls sich nun ein Mac mit Apple Mail mit dem Exchange Server verbinden möchte, bekommt er HTTP 403 als Antwort und kann sich somit nicht verbinden.

image

Im IIS Log findet man weiterhin die Anfragen von Apple Mail Clients, aber neu mit der Antwort 403.
image

Trotzdem hoffe ich natürlich, dass Sophos das Problem mit dem Reverse Proxy bald lösen kann.

Nachtrag
Gemäss diesem Forumsbeitrag arbeitet Sophos an einem Fix. “We are working on a fix. Mantis 27287: Outlook anywhere connection with WAF didn’t work for Mac Clients
At the moment, we do not support Outlook Anywhere connections for Mac clients”

Nachtrag 2
In diesem Forumsbeitrag gibt es noch weitere Informationen. Da wird auch bestätigt, dass es im Moment keine WAF Unterstützung für Mac gibt, unabhängig vom Client.

Access Control Lists (ACL) auf HP Switch

In grösseren Netzwerken sollte aus Performance- und Sicherheitsüberlegungen mit VLAN’s gearbeitet werden. Für einen ersten Überblick zu VLAN’s bietet sich der Blog Schulnetz.info von Edi Pfisterer an. Später wird man sich mit der Anleitung des eigenen Switches auseinandersetzen müssen, die dann aber oft viel technischer verfasst ist.

Hier habe ich bereits ein paar Befehle zusammengefasst, die ich immer mal wieder benötige. Neu kann unser Switch nun auch mit ACL’s umgehen. VLAN’s ohne ACL’s bringen (nur) mehr Performance, weil Broadcastverkehr eingeschränkt wird.
(Broadcasts sind Datenpakete, die ins ganze Netzwerk gesendet werden, weil nicht bekannt ist, an welcher Adresse sich der Empfänger befindet. Je mehr solcher Broadcasts durch das Netzwerk übermittelt werden, desto weniger “Platz” hat es auf der verwendeten Leitung für “Nutzverkehr”, das Netzwerk wird also langsamer).

Wenn Datenverkehr von VLAN zu VLAN übermittelt werden muss, spricht man von Routing. Häufig wird Routing benötigt, um z.B. auf das VLAN mit den Servern zu kommen. Mit eingestelltem Routing bringen VLAN’s also nur weniger Broadcastverkehr, aber keinen Sicherheitsgewinn. Dafür werden ACL’s benötigt, in denen angegeben werden kann, was genau von einem VLAN in das andere darf. Unser neuer Switch kann nun auch mit ACL’s umgehen. So gibt es Zugangspunkte in unserem Netzwerk, die aus Sicherheitsüberlegungen nicht von allen VLAN’s aus zugänglich sein sollten (wie z.B. die Hyper-V-Hosts oder die Verwaltungswebseiten von Servern und Storage, …). Trotzdem wäre es praktisch, wenn ich zur Verwaltung Zugang von meinem Rechner aus hätte und nicht einen Verwaltungsrechner nur für diesen Zweck einsetzen müsste.

Die folgenden Dinge treffen für unseren HP Switch zu. Bei anderen Herstellern muss man zu deren Dokumentation greifen.

Eine ACL (Access Control List) besteht aus einer oder mehreren ACE(s) (Access Control Entry). HP unterscheidet zwischen “standard ACLs” und “extended ACLs”. Bei den “standard ACLs” werden nur die “source addresses” (SA) betrachtet, also sind nur Regeln möglich, die den Verkehr VON xy regeln. Besser geeignet für meine Vorhaben sind die “extended ACLs”, die den Verkehr VON xy NACH uv regeln können.

image

(config)# ip access-list extended <name-str>
Mit diesem Befehl kann man eine extended ACL bearbeiten oder neu erstellen, falls es noch keine ACL mit diesem Namen gibt. Falls der <name-str> Leerzeichen enthält, muss man den Namen in einfache oder doppelte Anführungszeichen setzen. Die Namen dürfen aus 64 Zeichen (alphanumeric) bestehen.

(config-ext-nacl)# deny ip any host 192.168.1.15
Erstellt eine ACE die den Verkehr von allen Netzwerken zum Host 192.168.1.15 verhindert.
image

Um eine neue ACE in eine bereits bestehende Liste einzufügen, kann man einfach die gewünschte Zahl voranstellen, also z.B. 15 deny ip any host 192.168.1.15.

# show access-list
Zeigt eine Übersicht über die eingetragenen ACLs.

# show access-list config
Zeigt Konfigurationsdetails der eingetragenen ACLs an.

#show access-list vlan <vid>
Zeigt die ACLs an, die dem angegebenen VLAN zugeordnet sind.

# vlan <vid> ip access-group <identifier> <in out>
Ordnet eine ACL einem VLAN zu. Wenn man “no” dem Befehl voranstellt, wird die Zuordnung wieder gelöscht. <identifier> muss mit dem Namen (oder der Nummer) der ACL ersetzt werden.
image

Implicit Deny
Wenn eine ACL einem Port oder einem VLAN zugeordnet ist, werden alle nicht explizit erlaubten Fälle abgelehnt.
image

Konkret
Viel einfacher wäre es gewesen, alle Verwaltungsadressen in ein eigenes VLAN zu stecken, aber wie so oft ist man schlauer, wenn alles schon gemacht ist und eine Änderung aufwendig wird. Unsere Server sind im gleichen Subnetz/VLAN wie die Hyper-V-Hosts und die Verwaltungswebseiten von Storage/Hyper-V-Hosts. Also müssen alle Clients aus ihren VLANS Zugang zum Server-VLAN haben, aber nicht zu den einzelnen dieser Ausnahmen. Dies kann mit den ACLs erreicht werden.

Die ACL kann so angelegt werden:
ip access-list extended „Server out“
deny ip any host 192.168.13.25
deny ip any host 192.168.13.28
deny ip any host 192.168.13.35
deny ip any host 192.168.13.36
deny ip any host 192.168.13.50
deny ip any host 192.168.13.51
permit ip any any
exit

Nun muss die ACL noch dem entsprechenden Server VLAN zugewiesen werden
vlan 207 ip access-group “Server out” out

Probleme mit Webseite

Heute wurde mir von 3 Personen gemeldet, dass unsere Webseite nicht mehr funktioniere. Stattdessen kommt eine Seite, von der nicht klar ist, was denn der Zweck davon sein sollte (ausser allenfalls Malware zu verbreiten). 

 image

Zuhause ging es mir dann genau gleich. Statt unserer Seite www.schalt.ch kam eben die falsche Seite wie auf dem Bild oben. Man sah wie man weitergeleitet wurde und mein erster Gedanke war, dass die Website gehackt wurde und nun auf eine andere weiterleitet um eben z.B. Malware zu verbreiten.

Zuerst wird folgende Seite geladen:

image

In einem zweiten Schritt wird dann die Seite mit den vielen Zeichen unter “frame src” im oberen Bild geladen.

image

Bei einem zweiten Blick stellte ich dann fest, dass die Namensauflösung nicht korrekt funktioniert. Daher konnte ich wahrscheinlich bei einem erst oberflächlichen Blick mit Wireshark nichts entdecken, weil beim Öffnen der Seite im Browser schon eine falsche IP angesteuert wurde. Ein “nslookup www.schalt.ch” lieferte:

image

Der Client, von dem aus die Anfrage gemacht wurde, bekommt die DNS Antworten vom lokalen Router zuhause und dieser vom DNS Server meines Providers. Um zu überprüfen, ob die DNS Einträge grundsätzlich nicht mehr stimmen, habe ich dem Client eine manuelle Netzwerkeinstellung gegeben und als DNS Server einen von Google eingetragen (8.8.8.8). Nach einem “ipconfig /flushdns” stimmte auch die Namensauflösung wieder:

image

Komischerweise stimmte nun auch nach einem Zurückstellen (DNS vom Provider) die Namensauflösung wieder. Es scheint also nur ein temporäres Problem mit der Namensauflösung gewesen zu sein. Ich habe nun den Provider angefragt, ob sie ein Problem mit dem DNS gehabt hätten und werde voraussichtlich morgen eine Antwort erhalten.

Ich merke nun, dass ich mit meinem wenigen Wissen anstehe. Damit ich nichts vergesse, habe ich es hier niedergeschrieben. Vielleicht kann mir ja auch jemand, der diesen Blog liest, auf die Sprünge helfen.

Wurde der Webserver gehackt? Die Weiterleitung auf eine andere Seite würde dafür sprechen. Wie kann aber eine gehackte Seite meine DNS Auflösung zuhause beeinflussen? Angenommen, die Seite würde Malware verteilen, die z.B. die Hostsdatei anpasst oder etwas ähnliches… Da müsste der Virenscanner Alarm schlagen und wenn nicht, dürfte die Umstellung auf die Google (DNS) Server keinen Einfluss haben. Zur Sicherheit habe ich noch mit Virustotal unsere Seite überprüft. Es wurde aber nichts gefunden. Wie zuverlässig das ist, weiss ich aber auch nicht. Ich hoffe jetzt einfach, dass es nichts mit einer gehackten Webseite zu tun hat, werde dem aber sicher noch nachgehen.

image

Im Moment sagt mir ein Blick auf die Bäume, die mir die Sicht auf den Wald versperren, dass es ein Problem mit der DNS Auflösung meines Providers zusammenhängt. Sollten wirklich alle 3 anderen Personen, die das gleiche gemeldet haben, auch den gleichen Provider benutzen? Da das Problem bei mir zuhause nach einem Löschen des DNS Caches auf dem Router behoben war, würde sich dann das Problem von alleine lösen. Dagegen spricht, dass die “falsche” Seite auch mit “Schalt” beschriftet war und auch die komische Umleitung. Mal schauen, was ich morgen noch weiter herausfinde.

to be continued…

Nachtrag 1
Mein (Internetzugangs-)Provider zuhause hat bestätigt, dass sie ungültige DNS Records bei ihnen hatten und hat diese gelöscht und den Cache geleert. Da aber andere Personen mit anderen Zugangsprovidern auch auf die falsche Seite kamen, kann es nicht an meinem Provider liegen. Der Fehler muss “weiter oben” in der DNS Infrastruktur passiert sein. Somit ist aber zumindest klar, dass es sich eindeutig um ein DNS Problem handelt. (Vielen Dank an die schnelle und kompetente Antwort meines Providers).

Nachtrag 2
Ein Leser dieses Blogs hat mich auf einen Eintrag von Heise Security aufmerksam gemacht (vielen Dank an dieser Stelle):

Tausende Domains umgeleitet
Rund 5000 Domains wurden durch einen menschlichen Fehler und Abwehrmaßnahmen einer Distributed-Denial-of-Service-Attacke (DDoS) bei dem Domain-Anbieter Network Solutions auf falsche Webseiten umgeleitet. Davon war unter anderem LinkedIn betroffen.

Wenn man nun eine DNS Abfrage auf den Server 208.91.197.132 durchführt (z.B. mit nslookup http://www.schalt.ch 208.91.197.132 oder mit der Seite network-tools.com über Advanced Tool bei DNS Records) liefert der auch heute noch die falsche IP zurück.

image

Diese Einträge xyz.ztomy.com decken sich wieder mit dem Beitrag bei heise Security. Der Server 208.91.197.132 gibt sich als authoritative für http://www.schalt.ch aus. Wenn nun also ein Internetzugangsprovider die Daten von diesem Server in seinen DNS Cache übernimmt, bekommen alle Kunden die falsche Webseite ausgeliefert.

Auf der Webseite von confluence-networks.com (Inhaber von 208.91.197.132) findet sich dann auch ein entsprechender Hinweis:

image

Ich habe mich nun dort mal gemeldet. Hoffe, dass das Problem nun behoben wird…

Nachtrag 3
Scheinbar waren noch andere Kunden der Swisscom betroffen: http://www.inside-it.ch/articles/33469

Am Montagabend waren viele Schweizer Websites stundenlang unerreichbar. Wer zum Beispiel nzz.ch ansurfen wollte, landete auf der Website des Providers Network Solutions. (…)

In der Schweizer Internet-Szene ist man sich allerdings ziemlich sicher, wie inside-it.ch erfahren hat, dass Swisscom schlicht vergessen hat, die Rechnung für die Domain rechtzeitig zu bezahlen. Ein "Anfängerfehler", der aber auch schon anderen Grossunternehmen unterlaufen ist.

Nachtrag 4
Nun scheint es definitiv zu sein. Vgl. Kommentar bei http://www.nzz.ch/aktuell/digital/nzz-dns-1.18135806). Die Swisscom informiert auf ihrer Seite und spricht von einem “Missverständnis”.

image

CLI Befehle für ProCurve Switch

Hier ein paar Befehle, damit ich sie nicht immer wieder aus der Anleitung heraussuchen muss Zwinkerndes Smiley

# config
Wechselt in den “Konfigurationsmodus”. Dies wird auf der Konsole angezeigt.
image

# menu
Wechselt ins Menü.
image

# show ip
Zeigt die IP Adresse des Switches für die verschiedenen Vlans. (Kann auch über das Menü erreicht werden).

(config)# vlan 1 ip address 10.28.227.103/24
Erstellt eine IP Adresse für das vlan 1 (no vlan… statt vlan… löscht die Adresse).

# show vlan
Zeigt eine Auflistung aller Vlans mit ID, Name, Status,… an.

# show vlans 1
Zeigt die Port Informationen von Vlan 1 an.

(config)# vlan 1
(vlan-1)# ip helper-address < ip-addr >
IP-helper Adresse für ein vlan eintragen.

(config)# vlan 2  tagged a1-a5
Konfiguriert die Ports A1 bis A5 als tagged Ports für Vlan 2.

# show ip helper-address vlan 1
IP-helper Adresse(n) für ein vlan anzeigen lassen

# show mac-address
Zeigt die Ports der gefundenen Mac Adressen an.

(config)# vlan 1
(vlan-1)# ip forward-protocol udp <ip-address> <port-number>
Erlaubt dem Computer mit der Adresse <ip-address> Broadcasts auf Port <port-number> an Vlan 1durchzureichen. Dies kann z.B. hilfreich für WOL sein.

Default Gateway auf ProCurve Switch

Bei unserem ProCurve Switch von HP lässt sich ein Default Gateway auf dem Webinterface eintragen.

image

Auf der Konsole lässt sich das Default Gateway auch eintragen unter “menu” –> “Switch Configuration” –> “IP Configuration”. Dort wird das Gateway aber nur angezeigt, wenn Routing deaktiviert ist: “config” –> “no ip routing”. Um das Routing wieder zu aktivieren kann man einfach “config” –> “ip routing” eingeben.

Unabhängig davon, wie man das Default Gateway eingetragen hat, wird es vom Switch nicht korrekt benutzt. Um den Netzwerkverkehr an ein vorgeschaltetes Gateway weiterzuleiten, muss man manuell eine Route dazu eintragen.

“config” –> “ip route 0.0.0.0/0 <IP Adresse des Gateways>”

image

Firmware Update für Switch

Um ein Firmware Update auf unserem zentralen Switch ProCurve 4204vl durchzuführen, muss man zuerst die neue Firmware auf der HP ProCurve Homepage herunterladen.

Die empfohlene Möglichkeit, die neue Firmware zu installieren, ist auf den Switch über CLI (Command Line Interface) zuzugreifen, und vom Switch aus über TFTP die Firmware herunterzuladen. Dazu habe ich Tftp32 verwendet. Man kann die Zip Version herunterladen und das Programm direkt aus dem extrahierten Verzeichnis ohne Installation starten. 

image

Über “Browse” kann man das Verzeichnis, in dem die neue Firmware heruntergeladen und extrahiert wurde, auswählen und über TFTP freigeben.

Nun kann man über Telnet auf den Switch zugreifen. Ich verwende jeweils Putty, mit dem ich auch über SSH den Linuxserver verwalten kann.

Auf der Konsole kann man nun das Update herunterladen:
copy tftp flash <ip-adresse-tftp-server> <firmware-name>

image

image

Mit dem Befehl show flash lässt sich danach überprüfen, dass die richtige Version im Primary Image, das beim nächsten Neustart verwendet wird, angekommen ist.

image

Mit einem reload kann der Switch nun noch neu gestartet werden.