Fokusartikel

So behalten Sie die Fernwartungszugänge Ihrer Dienstleister im Griff

Das Konto heißt Wartung, das Kennwort kennt die halbe Belegschaft des Dienstleisters, und abgelaufen ist es noch nie. Irgendwo im Netz läuft dazu ein Fernwartungswerkzeug, das vor sechs Jahren installiert […]

Andreas Hessel

15.10.2026 · 8 Min Lesezeit

Das Konto heißt Wartung, das Kennwort kennt die halbe Belegschaft des Dienstleisters, und abgelaufen ist es noch nie. Irgendwo im Netz läuft dazu ein Fernwartungswerkzeug, das vor sechs Jahren installiert wurde und seitdem jeden hereinlässt, der die richtige ID kennt. Kommt Ihnen bekannt vor? Wie Sie diese Zugänge in sechs Schritten unter Kontrolle bringen, ohne den Dienstleistern die Arbeit unmöglich zu machen, zeigt dieser Beitrag.

Das Problem mit der offenen Hintertür

Dienstleisterzugänge sind die bequemste Tür in Ihr Netz. Sie sind legitim, sie sind oft privilegiert, und sie fallen im Protokoll nicht auf, weil sie dort hingehören. Angreifer wissen das. Beim Angriff auf die Fernwartungssoftware Kaseya VSA im Juli 2021 haben Kriminelle über die Werkzeuge von IT-Dienstleistern die Systeme von deren Kunden verschlüsselt, weltweit rund 1.500 Unternehmen. Die meisten wurden nicht über eigene Lücken getroffen. Sie hatten einen Dienstleister.

In der Praxis sehe ich immer wieder dieselben vier Muster. Konten ohne Ablaufdatum, die Jahre nach dem letzten Einsatz noch aktiv sind. Sammelkonten, hinter denen fünf Techniker stecken, von denen zwei die Firma längst verlassen haben. Fernwartungsagenten mit unbeaufsichtigtem Zugriff, die niemand mehr auf dem Schirm hat. Und ein Vertragsende, das im Einkauf bearbeitet wird, ohne dass die IT davon erfährt.

Das Ziel in 4 Regeln

Am Ende dieses Beitrags gelten in Ihrem Haus vier Regeln. Kein Dienstleisterzugang ohne Ablaufdatum. Kein Direktzugang auf Produktivsysteme, sondern nur über eine kontrollierte Schleuse. Keine Sitzung ohne Protokoll. Und kein Vertragsende ohne Entzug aller Zugänge. Dazu kommt eine Grundregel, die alles andere erst prüfbar macht. Jeder Techniker bekommt ein persönliches Konto, Sammelkonten gibt es nicht mehr.

Das klingt nach viel Aufwand. Mit Bordmitteln und einer kostenlosen Schleuse schaffen Sie es in wenigen Tagen. Die Befehle in diesem Beitrag gehen von einem Active Directory mit einer eigenen Organisationseinheit für externe Konten und von Linux-Servern mit OpenSSH aus. Passen Sie Namen und Pfade an Ihre Umgebung an.

Schritt 1: Bestandsaufnahme der Konten und Werkzeuge

Beginnen Sie mit der Frage, welche externen Konten überhaupt existieren. Im Active Directory listet der folgende Befehl alle Konten der OU für Externe mit letzter Anmeldung und Ablaufdatum auf.

Get-ADUser -Filter * -SearchBase "OU=Extern,DC=firma,DC=local" `
  -Properties LastLogonDate, AccountExpirationDate, Enabled, Description |
  Select-Object SamAccountName, Enabled, LastLogonDate, AccountExpirationDate, Description |
  Sort-Object LastLogonDate | Export-Csv extern_konten.csv -NoTypeInformation -Encoding UTF8

Externe Konten liegen erfahrungsgemäß nicht nur dort, wo sie hingehören. Suchen Sie deshalb zusätzlich nach allen Konten, die seit 90 Tagen nicht mehr benutzt wurden, und prüfen Sie jeden Treffer einzeln.

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Select-Object SamAccountName, LastLogonDate, DistinguishedName

Auf Linux-Servern zeigen Ihnen zwei Befehle die lokalen Benutzer und deren letzte Anmeldung. Je nach Distribution heißt das zweite Werkzeug inzwischen lastlog2.

awk -F: '$3 >= 1000 && $3 < 65534 {print $1}' /etc/passwd
lastlog -b 90

Dann die Werkzeuge. Fernwartungsagenten finden Sie auf Windows-Systemen am schnellsten über ihre Dienste. Der Befehl lässt sich per Remoting oder über Ihre Softwareverteilung auf alle Clients und Server ausrollen.

Get-Service | Where-Object { $_.DisplayName -match 'TeamViewer|AnyDesk|RustDesk|Splashtop|ConnectWise|ScreenConnect|NinjaRMM|Kaseya|Datto' } |
  Select-Object MachineName, Name, DisplayName, Status, StartType

Das Ergebnis ist eine Tabelle, die Sie mit der Dienstleisterliste abgleichen. Jedes Konto und jedes Werkzeug braucht einen benannten Dienstleister und einen Zweck. Was keinen hat, wird deaktiviert. Wer sich beschwert, hat sich damit gemeldet.

Schritt 2: Jedes Konto bekommt ein Ablaufdatum

Ein Konto ohne Ablaufdatum ist eine Einladung auf unbestimmte Zeit. Setzen Sie für jedes externe Konto ein Datum, das spätestens am Vertragsende liegt, besser früher mit Verlängerung auf Antrag.

Set-ADAccountExpiration -Identity ext.mueller.hersteller -DateTime "2026-12-31 18:00"

Mit einem zweiten Befehl sehen Sie jederzeit, welche Konten in den nächsten vierzehn Tagen ablaufen. Das ist Ihre Wiedervorlage.

Search-ADAccount -AccountExpiring -TimeSpan 14.00:00:00 |
  Select-Object SamAccountName, AccountExpirationDate

Unter Linux setzen Sie das Ablaufdatum mit „usermod“ und prüfen es mit „chage“.

sudo usermod -e 2026-12-31 wartung.mueller
sudo chage -l wartung.mueller

Bei dieser Gelegenheit lösen Sie die Sammelkonten auf. Jeder Techniker des Dienstleisters bekommt ein eigenes Konto nach einem festen Namensschema, etwa ext, Firma und Name. Das erhöht den Verwaltungsaufwand minimal und macht jede Anmeldung einer Person zuordenbar.

Schritt 3: Zugang nur auf Anforderung

Die meisten Dienstleister brauchen ihren Zugang an wenigen Tagen im Jahr. Trotzdem ist er an 365 Tagen offen. Drehen Sie das um. Das Konto bleibt deaktiviert und wird erst auf ein Ticket hin für den vereinbarten Zeitraum freigeschaltet.

Enable-ADAccount -Identity ext.mueller.hersteller
# nach Abschluss der Arbeiten
Disable-ADAccount -Identity ext.mueller.hersteller

Eleganter geht es mit zeitlich befristeten Gruppenmitgliedschaften. Das Konto bleibt aktiv, die Berechtigung für die Fernwartung hängt aber an einer Gruppe, deren Mitgliedschaft nach acht Stunden automatisch endet.

Add-ADGroupMember -Identity "GG-Fernwartung-Abrechnung" -Members ext.mueller.hersteller `
  -MemberTimeToLive (New-TimeSpan -Hours 8)

Diese Funktion setzt das optionale Feature Privileged Access Management im Active Directory voraus. Dafür braucht Ihr Forest die Funktionsebene Windows Server 2016, und das Feature lässt sich nach dem Aktivieren nicht mehr abschalten. Klären Sie das vorher mit dem Verantwortlichen für Ihr Verzeichnis.

Für die Fernwartungswerkzeuge gilt dasselbe Prinzip. Schalten Sie den unbeaufsichtigten Zugriff ab. Der Dienstleister verbindet sich dann nur, wenn ein Mitarbeiter im Haus die Sitzung aktiv bestätigt. Das kostet eine Minute pro Einsatz und schließt die gefährlichste Tür im ganzen Netz.

Schritt 4: Eine Schleuse statt vieler Türen

Dienstleister sollten Ihre Produktivsysteme nie direkt erreichen. Sie melden sich an einer Schleuse an, und nur diese Schleuse darf sich mit den Zielsystemen verbinden. Die Firewall erzwingt das.

Eine kostenlose und bewährte Lösung ist Apache Guacamole. Das ist ein Open-Source-Gateway, das RDP-, SSH- und VNC-Verbindungen im Browser bereitstellt. Der Dienstleister braucht keinen Client und bekommt keine Netzwerkverbindung in Ihr Netz, sondern nur ein Bild im Browser. Mit der TOTP-Erweiterung erzwingen Sie eine Zwei-Faktor-Anmeldung. Und Guacamole kann jede Sitzung aufzeichnen. Dafür setzen Sie in der Verbindungskonfiguration drei Parameter. Der Dateiname enthält dann Datum, Uhrzeit und den angemeldeten Benutzer.

recording-path         = /var/lib/guacamole/recordings
create-recording-path  = true
recording-name         = ${GUAC_DATE}-${GUAC_TIME}-${GUAC_USERNAME}

Die Aufzeichnungen lassen sich mit dem mitgelieferten Werkzeug guacenc in Videos umwandeln, falls Sie einen Vorfall nachvollziehen müssen. Wer Microsoft bevorzugt, erreicht Ähnliches mit einem Remotedesktopgateway und der NPS-Erweiterung für die Mehrfaktoranmeldung über Entra ID. Eine Sitzungsaufzeichnung bringt diese Variante allerdings nicht mit.

Für Linux-Server, auf die Dienstleister per SSH zugreifen, begrenzen Sie in der sshd_config, was diese Konten dürfen. Legen Sie alle externen Konten in eine Gruppe und setzen Sie für diese Gruppe eigene Regeln.

LogLevel VERBOSE

Match Group dienstleister
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no
    AllowAgentForwarding no

LogLevel VERBOSE sorgt dafür, dass im Protokoll steht, mit welchem Schlüssel sich jemand angemeldet hat. Die Einträge unter Match verhindern, dass ein Dienstleister die SSH-Verbindung als Tunnel in Ihr übriges Netz nutzt.

Schritt 5: Protokollieren und hinschauen

Ein Protokoll, das niemand liest, schützt nicht. Planen Sie deshalb einmal im Monat 15 Minuten für einen Blick auf die Anmeldungen externer Konten ein. Unter Windows helfen Ihnen die Ereignisse 4624 für erfolgreiche Anmeldungen, 4625 für Fehlversuche, 4720 für neu angelegte und 4738 für geänderte Konten. Der folgende Befehl zeigt alle Anmeldungen externer Konten der letzten 30 Tage mit Anmeldetyp. Typ 10 steht für eine Remotedesktopsitzung.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-30)} |
  Where-Object { $_.Properties[5].Value -like 'ext.*' } |
  Select-Object TimeCreated,
    @{n='Konto';e={$_.Properties[5].Value}},
    @{n='Typ';e={$_.Properties[8].Value}},
    @{n='Quelle';e={$_.Properties[18].Value}}

Führen Sie den Befehl auf den Domänencontrollern und auf den Zielsystemen aus, denn Anmeldungen am Server werden dort protokolliert. Unter Linux liefert das Journal die SSH-Anmeldungen. Der Dienst heißt je nach Distribution ssh oder sshd.

journalctl -u ssh --since "30 days ago" | grep -E "Accepted|Failed"

Achten Sie auf drei Auffälligkeiten: Anmeldungen außerhalb der vereinbarten Einsatzzeiten, Anmeldungen ohne zugehöriges Ticket und Anmeldungen von unerwarteten Quelladressen. Jede davon ist einen Anruf beim Dienstleister wert.

Schritt 6: Das Vertragsende ist ein Sicherheitsereignis

Die meisten verwaisten Zugänge entstehen nicht aus Nachlässigkeit, sondern aus einer Lücke im Ablauf. Der Einkauf kündigt, die IT erfährt nichts. Schließen Sie diese Lücke mit einer einfachen Vereinbarung. Jede Kündigung und jedes Vertragsende eines Dienstleisters mit technischem Zugang gehen als Ticket an die IT. Das Ticket wird erst geschlossen, wenn alle folgenden Punkte erledigt sind.

  1. Alle persönlichen Konten des Dienstleisters sind deaktiviert. Löschen Sie sie erst nach 30 Tagen, damit ein Vorfall noch nachvollziehbar bleibt.
  2. Die Kennwörter aller Dienst- und Administratorkonten, die der Dienstleister kannte, sind geändert.
  3. VPN-Zugänge und Zertifikate sind widerrufen, die Konten in der Schleuse gelöscht.
  4. Fernwartungsagenten, die nur dieser Dienstleister genutzt hat, sind deinstalliert.
  5. SSH-Schlüssel des Dienstleisters sind aus allen authorized_keys-Dateien entfernt.
  6. Firewallregeln und Portfreigaben für den Dienstleister sind entfernt.

Für Punkt fünf hilft ein einfacher Suchbefehl, sofern die Schlüssel mit einem Kommentar versehen sind, der den Dienstleister erkennen lässt. Verlangen Sie das künftig bei jeder Schlüsselübergabe.

sudo grep -Hn "firma-mueller" /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

Ergebnis und Kontrolle

Woran erkennen Sie, dass Sie fertig sind? An vier Prüfungen, die jeweils weniger als eine Minute dauern.

Der folgende Befehl liefert kein Ergebnis mehr, weil jedes externe Konto ein Ablaufdatum hat.

Get-ADUser -Filter * -SearchBase "OU=Extern,DC=firma,DC=local" -Properties AccountExpirationDate |
  Where-Object { -not $_.AccountExpirationDate } | Select-Object SamAccountName

Die Dienstabfrage aus Schritt 1 findet nur noch Fernwartungswerkzeuge, die in Ihrer Liste stehen, und keines davon erlaubt unbeaufsichtigten Zugriff.

Jede Dienstleistersitzung der letzten 30 Tage findet sich als Aufzeichnung in der Schleuse wieder.

Und die Stichprobe besteht. Nehmen Sie den letzten Dienstleister, dessen Vertrag geendet hat, und prüfen Sie die sechs Punkte aus Schritt 6. Sind alle erledigt, funktioniert Ihr Ablauf. Fehlt einer, wissen Sie, wo Sie nachbessern.

Mein Tipp. Fangen Sie nicht mit allen Dienstleistern gleichzeitig an. Nehmen Sie die drei mit dem tiefsten Zugriff auf Ihre kritischsten Systeme. Wenn diese drei sauber laufen, haben Sie das größte Risiko erledigt und gleichzeitig ein Muster, das Sie auf alle anderen übertragen können.

Weiterlesen

Welche Dienstleister Sie zuerst angehen sollten, entscheidet die Kritikalität der Prozesse, die sie tragen. Den Hintergrund liefert der Kommentar „Warum Ihre Dienstleisterliste noch kein Risikomanagement ist“ aus Ausgabe 21, die Grundlage der Beitrag „In 6 Schritten zur belastbaren Business-Impact-Analyse“ aus Ausgabe 20.

Wie Sie die Wiederherstellung Ihrer Systeme nach einem Vorfall proben, falls doch einmal ein Zugang missbraucht wird, zeigt der Beitrag zum Wiederanlauftest aus Ausgabe 20.

Wie hat Ihnen dieser Artikel gefallen?

0
0

201
3
513
Andreas Hessel ist Vorstand der GRC Consulting AG und berät seit über dreißig Jahren Unternehmen der Finanzbranche und den Mittelstand in Informationssicherheit, Datenschutz, Risikomanagement und KI-Governance. Seine Erfahrung als Datenschutzbeauftragter, […]