SMBv1 Abhaengigkeit Nachweis: Versuche und Dialekte prüfen

Ein Nachweis für eine SMBv1-Abhängigkeit sollte einen beobachteten Verbindungsversuch eines Clients mit einem Server, einem Arbeitsablauf und einem Verantwortlichen verknüpfen. Eine alte Betriebssystembezeichnung in Active Directory kann helfen, Untersuchungen zu priorisieren, belegt aber nicht, welchen SMB-Dialekt ein Gerät heute verwendet. Erstellen Sie vor dem Entfernen von SMBv1 eine Dokumentation, die Konfiguration, versuchte Nutzung, bestehende Verbindungen und Beobachtungslücken unterscheidet.

Dieser Leitfaden beschreibt einen Ablauf zur Überprüfung und Behebung in AD-Umgebungen. Die folgenden Befehle sind dokumentierte Beispiele, die ein autorisierter Windows-Administrator auf den vorgesehenen Systemen ausführen kann; für diesen Artikel wurden sie nicht in einer realen Domäne ausgeführt. Es wird keine Beispielausgabe als gemessenes Ergebnis dargestellt.

Was belegt eine SMBv1-Abhängigkeit?

Eine Abhängigkeit ist eine betriebliche Aussage: Ein benannter Geschäftsablauf benötigt weiterhin SMBv1, um abgeschlossen werden zu können. Diese Aussage braucht belastbarere Belege als ein Verzeichnisattribut, eine auf dem Datenträger installierte Komponente oder die Feststellung, dass ein Gerät alt ist. Behandeln Sie jeden dieser Punkte als Ausgangspunkt einer Untersuchung und halten Sie fest, welche Beobachtung die Aussage bestätigen oder abschwächen würde.

Die Prüfung sollte drei Fragen beantworten. Welche Server und Clients sind beteiligt? Welcher Vorgang muss erfolgreich sein? Welche Belege verknüpfen die Protokollbeobachtung mit diesem Vorgang? Kann der Verantwortliche diese Fragen nicht beantworten, bleibt die Abhängigkeit unbestätigt. Das macht die Entfernung nicht ungefährlich; es bedeutet, dass die Entscheidung einen Pilotversuch mit festgelegtem Umfang und weitere Datenerhebung erfordert.

Führen Sie eine Nachweisdokumentation mit getrennten Einträgen für Konfiguration, serverseitige Verbindungsversuche, clientseitige Momentaufnahmen und Ergebnisse der Arbeitsabläufe. Diese Trennung verhindert einen verbreiteten Fehler: Eine auf einem Desktop erfasste moderne Verbindung wird verwendet, um einen Befund zu einem anderen Gerät, einer anderen Identität oder einem nächtlichen Auftrag zu schließen.

Wie die Nachweise zusammenpassen

Beginnen Sie beim Arbeitsablauf statt mit einer umgebungsweiten Umschaltung. Bitten Sie den Dienstverantwortlichen, Ziele und aufrufende Systeme aufzulisten, einschließlich periodischer Aufgaben, die während eines interaktiven Tests möglicherweise nicht laufen. Dokumentieren Sie, welche Windows-Systeme Serveraudits oder Clientbeobachtungen liefern können und welche Geräte eine andere Erhebungsmethode benötigen. Eine Appliance, auf der die vorgeschlagenen Befehle nicht ausgeführt werden können, bleibt Teil der ungeklärten Systeme, bis ihr Verantwortlicher geeignete Nachweise liefert.

Wählen Sie ein Erfassungsfenster, das den relevanten Betriebszyklus einschließt. Ein täglicher Test im Vordergrund führt keinen monatlichen Export aus. Hier wird keine allgemeingültige Dauer vorgeschrieben: Der Verantwortliche muss das Fenster anhand des tatsächlichen Zeitplans sowie relevanter außergewöhnlicher Vorgänge oder Wiederherstellungsvorgänge begründen. Halten Sie Beginn und Ende, ausgeschlossene Arbeitsabläufe, fehlende Hosts und Unterbrechungen der Erfassung fest.

Bewahren Sie für jede Beobachtung den Quellhost und den Kontext auf, bevor Sie Schlussfolgerungen ziehen. Ein Zeitstempel allein reicht nicht aus, wenn sich Server- und Clientaufzeichnungen nicht demselben Ziel und Vorgang zuordnen lassen. Wo diese Verknüpfung nicht hergestellt werden kann, kennzeichnen Sie die Korrelation als ungeklärt, statt zeitliche Nähe als Beweis zu behandeln.

Erkennung: Konfiguration, Versuche und Verbindungen prüfen

Schritt 1: Windows-Komponente und Servereinstellung prüfen

Microsoft dokumentiert diese Prüfungen in seinem Leitfaden zur Verwaltung der SMB-Protokolle. Verwenden Sie die für das geprüfte Windows-System geeigneten Befehle und bewahren Sie ihre Ausgaben als getrennte Nachweise auf. Führen Sie die Befehle für optionale Features in einer PowerShell-Sitzung mit erhöhten Rechten aus, wie es der Learn-Leitfaden verlangt.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Der erste Befehl meldet den Zustand des optionalen Features; der zweite meldet die Einstellung des SMB-Servers. Dokumentieren Sie den zurückgegebenen Zustand und die Rolle des geprüften Hosts. Eine Servereinstellung beschreibt nicht jede ausgehende Verbindung dieses Hosts, und der Zustand eines Features belegt nicht, ob ein betrieblicher Vorgang es genutzt hat. Ist ein Befehl auf dem Ziel nicht verfügbar oder schlägt er fehl, bewahren Sie den Fehler auf und wählen Sie eine geeignete Prüfmethode, bevor Sie den Host als abgedeckt einstufen.

Verwenden Sie keinen historischen Standardwert, um eine fehlende Beobachtung zu ersetzen. Die Entscheidungsdokumentation sollte das tatsächliche Ergebnis des geprüften Systems, den Erfassungszeitpunkt und den Prüfer enthalten, der es interpretiert hat. Bewahren Sie die Ergebnisse vor der Änderung für den Vergleich nach der Behebung auf.

Schritt 2: Serverauditing aktivieren und Event 3000 aufbewahren

Für den genehmigten Serverumfang dokumentiert Microsoft diese Auditeinstellung:

Set-SmbServerConfiguration -AuditSmb1Access $true

Prüfen Sie die Einstellung:

Get-SmbServerConfiguration | Select AuditSmb1Access

Derselbe Learn-Leitfaden bezeichnet Event ID 3000 in Microsoft-Windows-SMBServer/Audit als Versuch eines Clients, nach Aktivierung des Auditings eine Verbindung über SMBv1 herzustellen. Bewahren Sie das Ereignis zusammen mit dem Nachweis des Auditzustands auf. Ein Event 3000 belegt weder einen erfolgreichen Freigabezugriff noch eine Ausnutzung oder ein vollständiges Abhängigkeitsinventar.

Ordnen Sie jeden Versuch einem Untersuchungseintrag zu. Verwenden Sie die tatsächlich im Ereignis verfügbaren Clientinformationen und ergänzendes Inventar, um einen Verantwortlichen zu identifizieren; erfinden Sie keine Clientidentität, wenn die Korrelation fehlt. Fragen Sie den Verantwortlichen, welcher Vorgang lief, und beschaffen Sie dessen Ergebnis. Klassifizieren Sie den Eintrag als zugeordneten Versuch, ungeklärten Versuch oder Arbeitsablauf, der weitere Beobachtung benötigt.

Auch ein erfolgloser Versuch verdient eine Erklärung, belegt aber nicht, dass der Arbeitsablauf SMBv1 für einen erfolgreichen Abschluss benötigt. Umgekehrt kann ein nie ausgeführter Arbeitsablauf nicht allein deshalb als unbedenklich gelten, weil das Serverprotokoll keine relevanten Einträge enthält.

Schritt 3: Verbindungen des aktiven Clients erfassen

Führen Sie die dokumentierte Clientprüfung aus, während der identifizierte Vorgang aktiv ist:

Get-SmbConnection

Microsofts Referenz zu Get-SmbConnection beschreibt bestehende Client-Server-Verbindungen und zeigt in ihren Beispielen das Feld Dialect. Die Zeilen unterscheiden sich nach Freigabe, Benutzeranmeldung und verwendeten Anmeldeinformationen. Bewahren Sie diesen Kontext auf, statt alle Zeilen zu einer einzigen Antwort für den Computer zusammenzufassen.

Fügen Sie die Momentaufnahme mit Erfassungszeit und tatsächlich zurückgegebenen Werten dem Eintrag des Arbeitsablaufs hinzu. Ein moderner Dialekt auf einer passenden Verbindung stützt den beobachteten Pfad zu diesem Zeitpunkt. Er entlastet keine anderen Freigaben, Identitäten, Geräte oder geplanten Ausführungen. Eine fehlende Zeile ist keine historische Aufzeichnung sämtlicher SMBv1-Aktivitäten; für den ungeklärten Pfad kann eine andere Beobachtungsmethode erforderlich sein.

Schritt 4: Nachweise vor der Entscheidung abgleichen

Vergleichen Sie Ereignis, Clientmomentaufnahme und Ergebnis des Arbeitsablaufs. Beziehen sie sich auf unterschiedliche aufrufende Systeme oder Vorgänge, führen Sie getrennte Einträge. Ist ein Versuch auf dem Server sichtbar, aber keine passende bestehende Verbindung erfasst, bewahren Sie beide Beobachtungen auf, ohne einen Erfolg oder Dialekt zu konstruieren.

Behebung: Abhängigkeit ersetzen und SMB2/3 erneut validieren (Remediation)

Schritt 1: Die Entscheidung zur Abhängigkeit prüfbar machen

Dokumentieren Sie für jeden betroffenen Arbeitsablauf, ob er eingestellt, aktualisiert oder auf ein Ersatzgerät beziehungsweise einen Ersatzdienst verlagert wird. Benennen Sie den Verantwortlichen, den geplanten Abschlusstermin, den genehmigten Pilotumfang und den Wiederherstellungsplan. Bleibt die Abhängigkeit ungeklärt, halten Sie genau fest, welche Beobachtung fehlt und wer sie beschafft.

Der Pilotversuch sollte die während der Erfassung entdeckten Client- und Serverpfade einschließen. Stützen Sie eine umgebungsweite Änderung nicht auf eine einzelne erfolgreiche Verbindung. Beziehen Sie die in der Planung identifizierten periodischen Vorgänge ein oder dokumentieren Sie, dass deren Validierung noch aussteht.

Schritt 2: Die genehmigte SMBv1-Änderung anwenden

Microsoft dokumentiert den folgenden Befehl zum Deaktivieren von SMBv1 auf der Serverkomponente:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Für das entsprechende optionale Windows-Feature lautet der dokumentierte Befehl:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Wählen Sie die zum Ziel und vorgesehenen Umfang passende Methode. Diese Änderungen sind keine austauschbaren Nachweise: Die Deaktivierung des Serverprotokolls und die Deaktivierung eines optionalen Features betreffen unterschiedliche Konfigurationsebenen. Der Learn-Leitfaden beschreibt einen Neustart für die Änderung des optionalen Features, während Set-SmbServerConfiguration keinen Neustart erfordert. Stimmen Sie die Auswirkungen eines Neustarts mit dem Verantwortlichen ab und bewahren Sie das zurückgegebene Ergebnis auf, statt den Abschluss der Änderung anzunehmen.

Scheitert die Kompatibilität, kehren Sie zur Dokumentation des Arbeitsablaufs und zum vorgesehenen Ersatz zurück. Eine Wiederherstellungsentscheidung sollte den konkret betroffenen Dienst und Verantwortlichen benennen; sie sollte nicht stillschweigend die Basisanforderungen für unbeteiligte Hosts neu definieren.

Schritt 3: Beobachtungen im geänderten Umfang wiederholen

Wiederholen Sie die passenden Feature- und Serverprüfungen und führen Sie anschließend die vorgesehenen Vorgänge aus. Erfassen Sie dabei Clientverbindungen und erhalten Sie die Serverauditabdeckung über das begründete Fenster hinweg. Vergleichen Sie die Aufzeichnungen vor und nach der Änderung anhand derselben Host-, Freigabe- und Arbeitsablaufkennungen.

Schließen Sie einen Abhängigkeitseintrag erst, wenn der Verantwortliche erklären kann, was sich geändert hat, und Nachweise liefert, dass der erforderliche Arbeitsablauf weiterhin auf dem vorgesehenen SMB2/3-Pfad funktioniert. Lassen Sie ungetestete periodische Vorgänge und nicht verfügbare Geräte offen. Ein Konfigurationsergebnis, ein erfolgreicher Geschäftstest und eine Verbindungsmomentaufnahme beantworten unterschiedliche Fragen; die Abschlussdokumentation braucht die relevante Kombination.

Dokumentieren Sie verbleibende Versuche nach der Änderung und untersuchen Sie die aufrufenden Systeme. Ihre Anwesenheit bedeutet nicht automatisch, dass ein Geschäftsablauf fehlgeschlagen ist, und ihre Abwesenheit belegt keine vollständige Abdeckung. Binden Sie die Interpretation an den ursprünglichen Auditumfang und das ursprüngliche Fenster.

Wie EtcSec dies erkennt

In der geprüften etc-collector-Implementierung ist COMPUTER_LEGACY_PROTOCOL ein verzeichnisbasiertes Triage-Signal. Seine Detect-Methode untersucht aktivierte Computerkonten. Zuerst prüft sie fünf Betriebssystemmuster ohne Berücksichtigung der Groß-/Kleinschreibung: Windows XP, Windows 2000, Windows NT, Server 2003 und Windows Vista. Bei einer Übereinstimmung wird der Computer zur Liste der betroffenen Systeme hinzugefügt und mit dem nächsten Computer fortgefahren.

Für Computer, die diesem Zweig nicht entsprechen, prüft der Detektor, ob SupportedEncryptionTypes ungleich null ist und keines der beiden AES-Bits in der Maske 0x18 gesetzt ist. Der Betriebssystemzweig hat Vorrang: Ein dort zugeordneter Computer erhöht nicht zusätzlich den Zähler für den Grund schwache Verschlüsselung. Die Methode gibt einen aggregierten Befund zurück, auch wenn die Anzahl betroffener Systeme null ist.

Der LDAP-Provider liest operatingSystem und msDS-SupportedEncryptionTypes in das Computermodell ein. Dies sind Verzeichnisattribute, keine Messungen des laufenden SMB-Verkehrs. Der Integer-Parser gibt bei einem fehlenden Wert null zurück und verwirft Konvertierungsfehler; sein Ergebnis bewahrt diese Fälle daher nicht als unterschiedliche Erhebungsergebnisse auf. Der Detektor überspringt einen Verschlüsselungswert von null; das belegt keine Nutzung moderner Protokolle.

Die Prüfung beobachtet weder einen SMB-Dialekt noch eine NTLM-Version, tatsächliche DES-/RC4-Nutzung, Event 3000 oder den Erfolg eines Geschäftsablaufs. Ein betroffener Computer erfordert weitere Untersuchung, und ein Zählerstand von null kann die Prüfung der SMBv1-Abhängigkeit nicht abschließen. Nutzen Sie den Befund, um den oben beschriebenen Nachweisablauf zu priorisieren.

Ist das Verschlüsselungsattribut der Grund, folgen Sie dem separaten Leitfaden zum Kerberos-RC4-Fallback zur Unterscheidung von Verzeichniseinstellungen und Ticketnachweisen. Wirft die Prüfung eine Frage zur Signierung auf, nutzen Sie den SMB-Signierungsleitfaden zu Signaturanforderungen und Relay-Risiken. Keine dieser Prüfungen ersetzt die hier erhobenen Nachweise für SMBv1-Versuche und -Abhängigkeiten.

Entscheidungsdokumentation und Primärquellen

Bewahren Sie vor Abschluss der Prüfung ausdrückliche Antworten auf diese Prüffragen auf:

1. Welche Server und Arbeitsabläufe wurden auditiert, und schloss das Fenster ihre periodischen Aufgaben ein?
2. Welche Event-3000-Versuche wurden einem Client und Verantwortlichen zugeordnet, und welches Ergebnis wurde für jeden Vorgang verifiziert?
3. Welche Abhängigkeit wurde entfernt oder ersetzt, und welche Nachweise validieren die erforderlichen SMB2/3-Arbeitsabläufe erneut?

Fügen Sie die ursprünglichen Konfigurationsergebnisse, das Auditfenster, Ereignisse, Clientmomentaufnahmen, Entscheidungen der Verantwortlichen und die Validierung nach der Änderung hinzu. Wo Nachweise fehlen, benennen Sie die Lücke und den nächsten Schritt. Dies ist eine vorgeschlagene Prüfmethode, keine Behauptung, dass irgendeine Domäne diese Prüfungen bestanden hat.

• Microsoft Learn: Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft Learn: Get-SmbConnection