Alte Clients

Ursprünglich wollte ich die Seite "Windows XP im LAN"  nennen aber Windows 7 ist ja auch schon ohne Support und die Zeit bleibt nicht stehen. Was bedeutet der Betrieb von alten Systemen in ihrem Netzwerk für das Gesamtsystem?

Diese Seite ist für alle die Leser, die Windows 2008, 2003, XP, 2000 oder älter betreiben müssen, weil darauf aufsetzende Dienste nicht für neuere Systeme verfügbar sein, z.B. 16bit Software, Hardware-Abhängigkeiten.

Das Dilemma

Software wird mittlerweile kontinuierlich weiter entwickelt und speziell Sicherheitslücken sehr schnell korrigiert.. Früher wurde alle paar Jahre (bei Steuersoftware natürlich jedes Jahr) vom Hersteller eine neue Version mit neuen oder verbesserten Funktionen bereitgestellt. Wir wissen alle, dass auch die Einnahmen aus dem Verkauf von neuen Produkten und entsprechender Updates eine Triebfeder war. Mittlerweile ist der Wechsel zu Abo-Modellen fast überall erfolgt und Sie bezahlen einfach die monatliche Nutzung. Für den Hersteller hat das den Vorteil, dass er nicht nur kontinuierliche Einnahmen zur weiteren Entwicklung hat, sondern die Nutzer auch einfacher die aktuellste Version einsetzen können. Viele kleine Update-Schritte sind auch von der Verwaltung einfacher als alle paar Jahre mal ein Major Update.

Beim Client-Betriebssystem war Microsoft bislang ja recht freizügig und so konnten Clients mit Windows 7 kostenfrei auf Windows 10 und Windows 11 aktualisieren, sofern die Hardware darunter mitgespielt. Aber für Windows Vista und früher und auch bei Servern gab des diese Option nicht und so gibt es in vielen Firmen eine Mischung verschiedener Server, die mehr oder minder gut miteinander harmonieren. Insbesondere die Windows Security Changes 2023 haben aufgezeigt, dass es immer mal wieder Updates und Patches gibt, bei denen ältere Systeme nicht mehr mitspielen können. Darauf sollten Sie entsprechend vorbereitet sein.

Es muss ihnen aber klar sein, dass alle IT-Systeme in ihrer Umgebung nur eine bestimmte Lebenszeit haben, denn Fehler in Software können die Funktion aber auch die Sicherheit beeinträchtigen. Daher sollten Sie auch in der Vergangenheit nie ein System ohne entsprechende Support- und Wartungsregelungen betrieben haben. Mit fehlenden Funktionserweiterungen können Sie sich vielleicht einige Jahre noch über die Zeit retten aber beim Thema Sicherheit hört der Spaß auf. Ich habe durchaus einige Kunden gehabt, die Produkte wie Exchange und Office bis zu 10 Jahre genutzt haben und damit natürlich zumindest auf dem Papier sehr günstig die Lizenz eingekauft haben. Das funktionierte aber auch nur solange, wie es noch Security Updates gab. Da ist Microsoft mit bis zu 5 Jahren Servicepacks und bis zu weiteren 5 Jahren Security Updates sogar mustergültig. Diverse Open Source-Produkte sind da kurzlebiger und es hilft ihnen auch nicht, wenn das Update ja nichts kostet, wenn Sie es nicht einspielen können. Und da spreche ich nicht nur von Treibern für IEEE488-Schnittstellen, seriellen Ports oder 16/32-bit Software.

Nur damit keine Zweifel aufkommen: Ein System, welches keine Security Updates mehr bekommt, darf nicht mehr im regulären Netzwerk betrieben werden. Nehmen Sie solche System nicht auf die leichte Schulter

Abschaltungen

Ich beschränkt mich auf dieser Seite auf mir bekannt gewordene Probleme mit Sicherheitsupdates und Patches, die ältere Systeme nicht mehr mitspielen lassen. Die Abhilfe ist übrigens nicht als Dauerlösung gedacht.

Update Beschreibung

DES/RC4/AES

Kerberos-Tickets werden kryptografisch geschützt. Die schwache DES-Funktion wurde schon mit Windows Vista/2008 abgeschaltet. Hingegen ist das mittlerweile ebenfalls als unsicher geltende RC4 auch mit Windows 2022 noch zugelassen. Allerdings ändert das Nov 2022 Update die Default-Einstellung aller gepatchten Systeme von RC4 auf AES. Alle neu ausgestelltem Kerberos Tickets nutzen AES, wenn dies nicht über die Einstellung "SupportedEncryptionType" am AD-Object des Ziel-Servers unterbunden ist. System, die mit AES statt RC4 nicht zurechtkommen, können keine Authentifizierung per Kerberos mehr durchführen.

PAC Signing (Nov 2022)

Mit dem Security Update Nov 2022 hat Microsoft den Fix für eine Lücke vorbereitet, bei der Angreifer ein Kerberos-Ticket unbemerkt ändern können. Das Update sorgt zuerst dafür, dass alle Clients PAC-Signing verwenden. Im Laufe des Jahres 2023 werden dann alle aktualisierten Server dann PAC-Signing erzwingen. Windows XP und älter bekommen diese Erweiterung nicht mehr, da es keine Updates mehr gibt. Sie können sich aber weiter per NTLM anmelden. Dazu müssen Sie aber auf Kerberos für diese Server quasi verzichten, was in einer gemischten Umgebung kaum möglich ist.

Temporär können Sie bis Okt 2023 auf den Server den Zwang abschalten. Danach stellen die DCS keine Kerberos-Tickets mehr aus, wenn das PAC nicht geprüft werden kann..

Hinweis: Es gab im Nov 2021 ein Update, damit auch noch Windows 2007/2008R32-Server mit PAC-Signing arbeiten können.

RPC Sealing

Ein zweiter Fix im gleichen Security Updates Nov 2022 sorgt dafür, dass RPC-Aufrufe "versiegelt" (Sealed) werden, um eine unerlaubte Veränderung zu erkennen und das Paket zu verwerfen. Auch dieses Updates aktiviert zuerst, dass alle Systeme die RPC-Pakete nun mittels "Sealing" schützen. Schon das kann einige alte Server verwirren, die damit nicht umgehen können. Für eine Übergangszeit können Sie RPC Sealing auf dem Client wieder abschalten aber maximal bis zum 11. Jul 2023. Dann ist RPC Sealing Pflicht.

Die Verzögerung der Installation wichtiger Security Updates kann ich nicht empfehlen. Hier müssen Sie also ran.

Domain Join-Schutz

Mit dem Update im Oktober 2022 wurde der Rejoin eines PCs unter Berücksichtigung eines bestehenden Computerkontos geändert. Vorher hat der Join ein bestehendes Computerkonto wiederverwertet, wenn das ausführende Konto die Rechte auf das Computerobjekt hatte. Nach dem Update muss der ausführende Benutzer auch der "Creator" des vorhandenen Computerkontos oder Domainadmin sein.

Wenn Sie also Computer mit dem gleichen Namen neu installieren oder z.B. ein Restore machen und das bestehende Computerkonto z.B. aufgrund der Berechtigungen weiter behalten wollen, dann muss das nun ein Domainadmin machen. Microsoft beschreibt in KB5020276 insgesamt vier Optionen, wie damit umzugehen ist. Die letzte Option ist eine temporäre Einstellung auf dem Client, der aufgenommen werden soll (RegKey NetJoinLegacyAccountReuse). Das bedeutet natürlich auch, dass der Schutz nicht auf dem DC oder der Domain aktiviert wurde, sondern vom Client abhängt.

Fehler beim Join können Sie z.B. im Eventlog des DC oder in der Datei "C:\Windows\Debug\netsetup.log" auf dem Client nachvollziehen.

SMB1

Windows XP nutzt für den Join in eine Domain das SMB1-Protokoll. SMB1 ist auch auf neueren Windows Servern im Grund verfügbar aber sollte aufgrund von Sicherheitslücken deaktiviert werden. SMB2 ist erst ab Windows Vista verfügbar und moderne Clients nutzen sogar schon SMB3. SMB1 ist ab Windows Server 2019 nicht mehr standardmäßig installiert. Damit entfällt auch der Dienst "Computer Browser". Windows auf Azure enthält keinen SMB1-Code mehr.

TLS 1.2

Die Verschlüsselung von Daten per SMTP, HTTP und anderer Internet-Protokolle ist natürlich auch nicht stehen geblieben. War früher noch SSL2, SSL3, TLS 1.0 möglich, können Sie heute davon ausgehen, dass alle Webserver und auch Browser sich auf TLS 1.2 einigen. Die ersten Browser warnen schon, wenn die ausgehandelte Verbindung schlechte ist und bald dürften auch Webserver keine schwächeren TLS-Versionen und Crypto-Verfahren mehr unterstützen. So ist erst ab Windows 2012 TLS 1.2 per Default aktiv und bei Windows 2008SP2 kann es manuell aktiviert werden. Alle vorherige Versionen sprechen kein TLS 1.2.

Das ist dann die nächste Herausforderung für solche alten Systeme, die damit nicht zurecht kommen. Sie können ja durchaus schwächere Verfahren nutzen oder sogar ganz auch Verschlüsselung verzichten, wenn Sie sowohl den Übertragungsweg als auch die Endpunkte gesichert haben. Ansonsten könnten z.B. IPSec oder ein VPN einsetzen.

LDAP Channel Binding

Diese Härtung hat schon im Jahr 2020 stattgefunden, dass z.B. einfache "SimpleBinds" gegen einen LDAP-Server ohne TLS z.B. nicht mehr möglich sind. Wenn einfache Skripte per LDAP Informationen abfragen wollten, dann mussten Sie nun sichere Verfahren nutzen. Es ist einfach ein hohes Risiko, wenn sich ein Prozess per LDAP über unsichere Methoden anmelden und jemand dies mitliest.

Es gibt Kunden, die in dem Umfeld dann solche Daten aus dem produktiven Active Directory in einen AD LDS/ADAM -Server übertragen und dieser von den unsicheren Programmen gefragt wird.

16 Bit Subsystem + Versionscheck

Wer heute noch 16bit-Programme starten muss, darf offiziell keine 64bit Windows-Version einsetzen, da dort nur noch das 32bit Subsystem vorhanden ist. Nur 32-bit Windows hat noch ein 16bit Subsystem. Das letzte Windows mit 32bit ist Windows 10, welches wohl 2025 ausläuft. Insofern wäre dies möglich, wenn solche alten Programme nicht auch einen "Versionscheck" der "DOS-Version" machen und damit auch Probleme machen.

Weitere

Die Liste wird fortgesetzt

Die Liste ist vermutlich nicht komplett und ich bin sicher, dass es auch zukünftig weiter Lücken in Windows, SMB, RPC, Kerberos, NETLOGON und anderen kritischen Diensten gibt, die von Microsoft durch Updates gestopft werden. Dabei kann und wird Microsoft natürlich nur die Versionen testen, die noch im Support sind. Alle anderen Windows Versionen oder andere Produkte "können" aber müssen nicht funktionieren und sie finden keine Vorwarnungen oder Informationen zu Problemen mit solch ungetesteten Systemen.

Man kann wirklich nicht mit gutem Gewissen sagen, dass "Out of Support"-Systeme problemlos und sicher so betrieben werden können.

Später Updates

Nur weil ein Betriebssystem nicht mehr offiziell supportet wird, kann Microsoft dennoch auch danach weiter Updates verteilen. Manchmal werden die Updates außer der Reihe als Download angeboten, weil Sie sehr kritisch sind und Microsoft vermutlich Schaden von Bestandkunden abwehren will oder immer noch tausende Privatrechner zum Risiko für das Internet werden können. Firmen können über eine gesonderte "Extended Security Updates"-Lizenz den Update-Zeitraum sogar noch verlängern.

So kann es sein, dass Sie im Internet durchaus Hinweise auf Updates für Betriebssysteme und Produkte finden, die aber nicht mehr der Allgemeinheit zur Verfügung gestellt werden. Es gibt aber auch hier Ausnahmen, z.B.

Die Herausforderung bei dessen Updates ist, dass sie nicht mehr über WSUS oder Windows Update verteilt werden und sie sich selbst darum kümmern müssen. Es ist z.B., gar nicht so einfach nach dem Ende von Windows XP nun eine Neuinstallation mit SP3 und allen danach damals noch verfügbaren Updates zu installieren. Es scheitert schon daran, dass Windows XP kein TLS 1.2 unterstützt und daher gar keine Verbindung mehr zu den Microsoft Diensten aufbauen kann.

Abgeschotteter Betrieb

Aber was machen wir dann mit Systemen, die auf so einem "unsupporteten" System basieren und nicht aktualisiert werden können? Ich kenne da einige System speziell in der Produktion, die schon Jahre oder Jahrzehnte arbeiten und nicht getauscht werden können, weil diese spezielle Hardware ansteuern, nur als 16Bit-Applikation verfügbar sind, der Hersteller keine Wartung mehr anbietet oder vielleicht gar nicht mehr existiert? Es gibt Stanzen und Pressen, die auf Jahrzehnte abgeschrieben und entsprechend auch betrieben werden. Selbst von der NASA hört man ab uns zu, dass Sie alte Hardware auf Flohmärkten oder anderen Plattformen als Ersatzteile nachkaufen sollen.

Raus aus dem Netz, Betrieb als Standalone-System oder in einem eigenen abgeschotteten Bereich.

Zum Glück kosten heute Switches mit VLAN-Support und sogar IP-Routing mit Accesslisten kein Vermögen mehr. Selbst in meinem Homeoffice haben ich einen "managed Switch (Siehe TP-Link T2600G-28TS (TL-SG3424)) mit 24 Ports und unter 160€, der sicher genug VLANs kann und als IPv45/IPv6-Router mit filtern dienen kann.

Ich habe zwar keine Windows XP Clients mehr, aber durchaus einige IoT-Geräte, die zwar jünger aber damit nicht sicherer sind. Sie werden alle in ein eigenes Subnetz verschoben und können nur mit sich oder zusammengehörende Systemen sprechen. Sie sind aber erst einmal weder von extern erreichbar noch dürfen sie nach extern kommunizieren.

Für eine Firma kann das sogar bedeuten, dass Sie in so einem abgeschotteten vielleicht noch einen alten Windows Domain Controller als "Legacy Forest" betreiben, wenn mehrere alte Clients eine gemeinsame Benutzerdatenbank der Domain nutzen sollen. Wenn es für einen LegacyDC noch Updates gibt und diese die Funktion nicht stören, kann sollten diese installiert werden. aber irgendwann gibt es keine Windows Update oder Antivirus-Patterns mehr. Daher ist es um so wichtiger, dass diese Netzwerke wirklich segmentiert sind. Je mehr Systeme sich aber in einer gemeinsamen "Legacy"-Umgebung befinden, desto höher ist das Risiko. Wenn ein System einen Schupfen hat, sind alle anderen auch im Risiko. Denken Sie vielleicht über mehrere getrennte VLANs nach. Technisch ist dies auch eine Aufgabe für den Admin und den Umgang mit den Systemen.

Dennoch gibt es auch hier den Bedarf z.B. Betriebsdaten zu übertragen. Dabei scheiden natürlich alle Protokolle aus, die unsicher oder inkompatibel sind. Einen SMB1-zugriff aus diesem Netzwerk auf das reguläre Netzwerk wird nicht funktionieren, das die regulären Server SMB1 nicht mehr anbieten sollten und umgekehrt geht es entweder auch nicht mehr oder sie sollten es nicht zulassen, dass jemand auf so ein altes, ungepatchtes System von draußen zugreift.

Überlegen Sie sich also genau, wie der erforderliche Datenaustausch minimiert und damit abgesichert werden kann. Sie müssen sich genau die Richtung überlegen, wer die Verbindung initiieren kann und welches Protokoll genutzt werden kann. Wenn ihr System keine TLS 1.2/1.3 kann, dann ist zu prüfen, ob das produktive System als TLS 1.0 Client mitspielt oder Sie besser auf die Protokollverschlüsselung verzichten und die Verbindung zwischen den beiden Systemen per IPSec absichern. Protokolle wie RPC, SMB etc. sind aufgrund der dynamischen Ports weniger geeignet als "Single Port Protokolle" wie SMTP, SSH, HTTP, POP, IMAP oder notfalls auch passives FTP. Auch sollten Sie genau die IP-Adressen der Systeme als mögliches Filterkriterium einbeziehen.

Im Internet finden Sie sogar Beschreibungen, wie man mit Linux eine SMB1<->SMB3 Brücke baut. Das Linux kann auf der einen Seite per SMB1 für das Altgerät eine Dateifreigabe bereitstellen und die Zugriff auf der anderen Seite auf den SMB2/SMB3-Server  weitergeben. Allerdings ist da dann wirklich nur ein Dateiservice und erlaubt keine Domain Mitgliedschaft

Bei der Lösung mit so einer Brücke ist das Linux-System aber nicht als Netzwerk-Brücke mit dem Haus-LAN und dem SMB1-Isolier-LAN verbunden, sondern sollte komplett im isolierten VLAN stehen. In der Firewall zwischen dem Haus-LAN mit dem SMB2/3 Server muss dann nur das Linux-System ausgehend zugreifen können.

Wenn Sie noch "sicherer" sein wollen, dann kann auch ein USB-Shuttle, d.h. ein USB-Stick zum Datenaustausch genutzt werden, der immer beim Wechsel zwischen den Welten über eine Scan-Station laufen muss. Ich habe durchaus Firmen erlebt, die so einen PC an prominenter Stelle hatten. Jeder USB-Stick musste beim Wechsel zwischen Computer, auch aus dem Homeoffice einmal an die Station angeschlossen werden, die dann mit mehreren Virenscannern nach Malware gesucht und den gesamten Vorgang protokolliert hat. So waren Datenbewegungen nachvollziehbar. Es versteht sich von selbst dass der USB-Stick schnell und klein gewählt wurde. Wer allerdings noch mit 3,5" (1,44MB) Floppy-Laufwerken arbeiten muss, wird es immer schwerer haben passende Datenträger zu finden.

Letztlich ist es aber eine Individuelle, aufwändige Lösung, solche alten Systeme in einem separaten Bereich betriebsfähig zu halten.

Weitere Links