Manchmal gibt es Tage, an denen man einfach nicht viel erwartet. Nichts ist geplant, keine Besprechung stört, man geht einfach selig seiner Arbeit nach. Dies sind die Tage, an denen man üblicherweise in Dokumentationen schmökert, seinen Schreibtisch aufräumt oder nach einem neuen Virenscanner sucht, weil der Vertrag bald ausläuft.
Oder man setzt sich, wie mein Kollege Manfred,1 in den Kopf, endlich die Serverlandschaft zu aktualisieren, da Windows Server 2008 langsam aber sicher aus dem Support rutschte: Version 2012 war auserkoren und musste zeitnah her.
Zu der Zeit war ich relativ neu in der Behörde und hatte ein gutes Jahr die Verantwortung unter anderem für das VPN. Neben den technischen Aspekten betreute ich auch die Verwaltung der Smartcards und SIM-Karten. Für die Verwaltung des Domänennetzwerks war ich der zweite Mann. Ich war in die Pläne eingeweiht, die Ausführung oblag jedoch Manfred.
Da Manfred in der Vergangenheit gute Erfahrungen gesammelt hatte, wurden die meisten virtuellen Maschinen, darunter auch unsere Domain Controller, in place mit der neueren Version bespielt. Bis auf die Domain Controller hat das auch geklappt; der sekundäre Domain Controller hat das Upgrade jedoch nicht gut vertragen und produzierte seltsame Fehler, zudem schien laut Ereignisanzeige auch der DHCP-Service auf demselben System abzustürzen und wurde im Minutentakt neu gestartet.
Kein Problem, es wurden neue Domain Controller installiert, synchronisiert und die alten abgeschaltet. Eine Stunde später wurde noch die Domänenfunktionsebene hochgestuft und fertig.
Das war auch der ungefähre Augenblick, in dem sich der Helpdesk besorgt meldete und von mehreren Clients berichtete, die nicht mehr auf Dateien und Sharepoint zugreifen könnten, der Helpdesk konnte nichts ausrichten und die Tickets wurden an uns Admins eskaliert.
Der Verdacht ist natürlich schnell auf den Domain Controller und die dort installierten Dienste gefallen, aber ein ipconfig /renew zeitigte die erwarteten Resultate, mein Client hat sich ordnungsgemäß registriert, die händische Nachverfolgung auf den Servern und eine kurze Kontrolle mit Wireshark auf dem Client haben nichts merkwürdiges zutage gefördert.
Die Kundenrechner haben auch eine Adresse bezogen und tauchten zumindest in der Datenbank der DHCP-Services auf. Erst nachdem ich meinen Rechner wieder angesteckt hatte, war auch ich betroffen: Kein Dienst, weder Sharepoint, noch E-Mail, ja nichtmal Ping funktionierte mehr. Dank Wireshark erkannte ich schnell, dass DHCP-Anfragen zwar gesendet worden sind, aber keine anderen Pakete als DNS oder DHCP angekommen oder rausgegangen sind.
Das roch doch gewaltig nach der Firewall, die ich direkt als nächstes überprüfte. Ich stellte jedoch zu meiner Überraschung fest, dass die Windows-Firewall deaktiviert war. Stattdessen war eine Firewall installiert, welche zu der VPN-Software gehörte. In deren Einstellungen habe ich zunächst nichts bemerkenswertes entdeckt, es gab zwei Profile, wovon eines den Namen meiner Behörde trug, das andere trug den nichtssagenden Namen „Default“. Das letztere Profil war äußerst strikt ausgelegt und hat nur Verbindungen erlaubt, welche für den Aufbau eines Tunnels unerlässlich waren.
Hier kam ich dann langsam der Sache auf den Grund, denn ausgewählt war das Profil „Default.“ Das andere Profil sollte nämlich nur dann aktiviert werden, wenn der Client sich in einem freundlichen Netzwerk befände. Und dass wurde nicht erkannt.
Ich habe schnell die Kollegen vom Helpdesk darauf hingewiesen, dass kein Rechner neu gestartet werden darf. Wer betroffen war, solle über das VPN arbeiten.
Das dreiseitige Word-Dokument, welches unser VPN dokumentierte enthielt nichts über diese Funktionen, aber immerhin die Telefonnummer des Dienstleisters, der diese Lösung eingerichtet hat.
Eine kurze Rückfrage bei dem Dienstleister hat ergeben, dass für unsere Behörde offenbar eine Sicherheitsfunktion aktiviert worden war, mit der das Behördennetz erkannt werden sollte. Hierbei wurde leider nicht die vertrauenswürdige Anmeldung an einen Server als Kriterium genutzt, sondern es wurden die IP-Adressen für DHCP und DNS hinterlegt; ebenjene Dienste, die gerade abgeschaltet und durch neue Maschinen ersetzt worden sind.
An dieser Stelle haben Manfred und ich ernsthaft überlegt, die alten Domain Controller wieder anzuwerfen, doch diese waren bereits demoted, zudem würde diese Maßnahme im Zweifel nicht einmal helfen, schließlich gab es jetzt weitere Domain Controller mit aktuellen Daten und einer neuen Domänenfunktionsebene.
Nach einer kurzen Diskussion mit dem Dienstleister sind wir zu dem Ergebnis gekommen, dass die genutzte Funktion zu Erkennung des Domänennetzwerks nicht wirklich sicher ist und wir lieber die Client-Server-basierte Lösung verwenden wollten, die sogar schon lizensiert worden war. Da die Clients zumindest im VPN arbeiten konnten, gab es auch eine Möglichkeit, wie eine neue Konfiguration auf die Geräte aufgespielt werden konnte, ohne diese in die Hand zu nehmen.
Die Serverkomponenten waren flugs installiert und nach dem Rollout einer neuen VPN-Konfiguration konnten alle Computer wieder in das Netz, was leider nur für die Kollegen galt, die auch wirklich einen VPN-Zugang hatten. Bei allen anderen musste entweder ein Kollege mit Zugriff aushelfen, oder der Helpdesk, verstärkt durch zwei kleinlaute Admins, antreten.
Was uns damals gekniffen hatte, war die Tatsache, dass die VPN-Lösung schlecht, und die „Erkennung freundlicher Netzwerke“ nirgends, dokumentiert war. Alle Clients in der gesamten Behörde waren mit der Software bespielt und haben nur darauf gewartet, dass Änderungen am Netzwerk vorgenommen werden.
Nachdem die Clients wieder arbeiten konnten, ergab eine weitere Untersuchung der VPN-Lösung, dass die Firewall nicht nur auf meinem, sondern auf allen Clients deaktiviert war, und die Firewall der VPN-Lösung kannte in unserer Konfiguration nur zwei Zustände: Offen in freundlichen Netzen und nahezu vollständig geschlossen in fremden Netzen. Das bedeutete aber auch, dass alle Clients im lokalen Netzwerk nahezu ungeschützt waren.
Besonders schlimm war an dieser Stelle, dass die Software in dem vorgefundenen Zustand einfach ausgetrickst werden konnte: Hatten DNS und DHCP die korrekte IP, machte der Client alle Schotten auf.
Die Aufarbeitung dieses Zwischenfalls hat uns noch eine Weile beschäftigt.
- Der Name wurde geändert. ↩︎
