4.5 Dienstabhängigkeiten untersuchen*

Betriebssystemwerkzeuge zeigen normalerweise nur die formal registrierten Abhängigkeiten. Externe Datenbanken, DNS-Server, APIs oder Netzwerkspeicher erscheinen dort häufig nicht.

Eine Anwendung kann beispielsweise folgende Kette besitzen:

Benutzer
  → Client
  → DNS
  → Netzwerk und Firewall
  → Loadbalancer
  → Reverse Proxy
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst
  → Netzwerkspeicher
  → externe API

Für jede Verbindung sollten folgende Informationen erfasst werden:

Praktische Dokumentationsform:

Beispiele:

• Eine Webanwendung kann ihre Startseite ohne Datenbank ausliefern, aber keine Benutzer anmelden.
• Ein Maildienst kann Nachrichten zwischenspeichern, obwohl das Zielsystem vorübergehend nicht erreichbar ist.
• Ein Cluster kann beim Ausfall einer Instanz weiterarbeiten.
• Ein Dienst kann starten, obwohl ein optionales Monitoring-Backend fehlt.
• Eine Anwendung kann nach dem Start weiterarbeiten, obwohl der Konfigurationsdienst später ausfällt.

Der Ausfall einer Abhängigkeit führt nicht immer zum vollständigen Dienststillstand. Teilfunktionen und verzögerte Fehler müssen deshalb ausdrücklich geprüft werden.

<DIENSTNAME> muss durch den internen Dienstnamen ersetzt werden.

Dienst und erforderliche Systemdienste anzeigen:

[RO] Get-Service -Name "<DIENSTNAME>" -RequiredServices

Nur die erforderlichen Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn |
    Select-Object Name, DisplayName, Status

Dienste anzeigen, die vom untersuchten Dienst abhängen:

[RO] Get-Service -Name "<DIENSTNAME>" -DependentServices

Abhängige Dienste übersichtlich anzeigen:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Dienst und beide Abhängigkeitsrichtungen erfassen:

[RO] $service = Get-Service -Name "<DIENSTNAME>"

$service | Select-Object Name, DisplayName, Status

"Benötigte Dienste:"
$service.ServicesDependedOn |
    Select-Object Name, DisplayName, Status

"Abhängige Dienste:"
$service.DependentServices |
    Select-Object Name, DisplayName, Status

Wichtig:

• ServicesDependedOn zeigt Dienste, die der untersuchte Dienst benötigt.
• DependentServices zeigt Dienste, die den untersuchten Dienst benötigen.
• Beide Richtungen sind vor einem Stopp oder Neustart relevant.
• Nicht jede funktionale Anwendungsabhängigkeit ist beim Service Control Manager registriert.

Konfiguration einschließlich eingetragener Abhängigkeiten anzeigen:

[RO][SENS] sc.exe qc "<DIENSTNAME>"

Relevant ist insbesondere der Abschnitt:

DEPENDENCIES

Direkt abhängige Dienste anzeigen:

[RO] sc.exe enumdepend "<DIENSTNAME>"

Erweiterte Dienstinformationen anzeigen:

[RO] sc.exe queryex "<DIENSTNAME>"

Interpretation:

sc.exe qc kann Programmpfade, Dienstkonten und interne Konfigurationsinformationen anzeigen. Die Ausgabe sollte deshalb als potenziell sensibel behandelt werden.

Benötigte Dienste samt Startart und Konto untersuchen:

[RO] $requiredServices = (Get-Service -Name "<DIENSTNAME>").ServicesDependedOn

foreach ($requiredService in $requiredServices) {
    Get-CimInstance Win32_Service `
        -Filter "Name='$($requiredService.Name)'" |
        Select-Object Name,
                      DisplayName,
                      State,
                      StartMode,
                      StartName,
                      ProcessId,
                      ExitCode
}

Mögliche Auffälligkeiten:

• erforderlicher Dienst ist beendet,
• erforderlicher Dienst ist deaktiviert,
• Dienst hängt in StartPending,
• Dienst läuft unter einem falschen Konto,
• Dienstprozess besitzt keine PID,
• Exitcode ist ungleich null,
• benötigter Dienst wird wiederholt neu gestartet,
• Abhängigkeitsdefinition enthält einen nicht mehr vorhandenen Dienst.

Ein laufender erforderlicher Dienst kann trotzdem funktional gestört sein. Nach dem Status müssen Listener, Protokoll und tatsächliche Funktion geprüft werden.

Direkte und indirekte Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Nur unmittelbare Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --plain \
  --no-pager \
  "<DIENST>"

Rückwärts gerichtete Abhängigkeiten anzeigen:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Abhängigkeiten und Reihenfolgenbeziehungen strukturiert anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=Requires,Wants,Requisite,BindsTo,PartOf,After,Before,Conflicts

Wirksame Unit-Konfiguration anzeigen:

[RO][FILE][SENS] systemctl cat "<DIENST>"

Status abhängiger Units prüfen:

[RO] systemctl --failed --no-pager

systemctl list-dependencies zeigt systemd-Units. Eine in der Anwendung konfigurierte Datenbank oder API wird nur dann sichtbar, wenn dafür ausdrücklich eine systemd-Beziehung definiert wurde.

Besonders wichtig:

Requires=  ist nicht dasselbe wie After=
Wants=     ist nicht dasselbe wie After=
After=     legt Reihenfolge fest, aber keine zwingende Anforderung
Before=    legt Reihenfolge fest, aber keine zwingende Anforderung

Beispiel:

[Unit]
Requires=postgresql.service
After=network-online.target postgresql.service

Mögliche Interpretation:

• Der Dienst besitzt eine starke Anforderung an postgresql.service.
• Er soll nach postgresql.service gestartet werden.
• Er soll außerdem nach network-online.target gestartet werden.
• Das Erreichen von network-online.target beweist nicht, dass eine bestimmte entfernte Datenbank tatsächlich erreichbar ist.

Für eine zuverlässige Bewertung müssen Anforderungs- und Reihenfolgedirektiven gemeinsam betrachtet werden.

Vorwärts gerichtete Frage:

Was benötigt dieser Dienst?

[RO] systemctl list-dependencies "<DIENST>" --no-pager

Rückwärts gerichtete Frage:

Welche Units benötigen diesen Dienst?

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

Nur Abhängigkeiten vor einem Neustart prüfen:

[RO] systemctl show "<DIENST>" \
  --property=RequiredBy,WantedBy,ConsistsOf,PartOf

Bewertung vor einer Maßnahme:

launchd besitzt laut Apple kein allgemeines ausdrückliches Abhängigkeitsmodell wie systemd. Dienstinteraktionen sollen möglichst über bedarfsgesteuerte IPC-Mechanismen gelöst werden.

Deshalb müssen mehrere Informationsquellen kombiniert werden.

Systemweiten Dienst anzeigen:

[RO] launchctl print "system/<LABEL>"

Benutzerbezogenen Dienst anzeigen:

[RO] launchctl print "gui/$(id -u)/<LABEL>"

Konfigurationsdatei eines bekannten Drittanbieterdienstes anzeigen:

[RO][FILE][SENS] plutil -p "/Library/LaunchDaemons/<LABEL>.plist"

Benutzerbezogenen LaunchAgent anzeigen:

[RO][FILE][SENS] plutil -p "$HOME/Library/LaunchAgents/<LABEL>.plist"

In der plist können unter anderem folgende Auslöser relevant sein:

Der Schlüssel OtherJobEnabled bildet keine harte, zuverlässige Dienstabhängigkeit wie ein allgemeines Abhängigkeitsmodell. Apple beschreibt solche Bedingungen als Hinweise und empfiehlt bedarfsgesteuerte IPC-Mechanismen.

Funktionale Abhängigkeiten können an folgenden Stellen dokumentiert oder konfiguriert sein:

• Herstellerdokumentation,
• Architekturdiagramm,
• Betriebshandbuch,
• Konfigurationsdatei,
• Umgebungsvariable,
• Dienststartparameter,
• Containerdefinition,
• Reverse-Proxy-Konfiguration,
• DNS-Eintrag,
• Zertifikatskonfiguration,
• Mount-Konfiguration,
• Secret- oder Credential-Verwaltung,
• Anwendungsprotokoll,
• Überwachungssystem,
• Quellcode oder Deploymentbeschreibung.

Typische Konfigurationsbegriffe:

host
hostname
server
endpoint
url
uri
database
db_host
connection_string
ldap
smtp
proxy
upstream
backend
api
mount
share
certificate
key
timeout
retry

Konfigurationsdateien und Umgebungsvariablen können Geheimnisse enthalten. Nicht wahllos nach Inhalten suchen oder vollständige Dateien in Tickets kopieren.

Bereits aufgebaute Verbindungen können Hinweise auf verwendete Backends liefern.

Windows:

[RO][SENS] Get-NetTCPConnection -OwningProcess <PID> |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State

Linux:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

macOS:

[RO][SENS][PRIV] sudo lsof -nP -a -p <PID> -i

Damit können Hinweise gefunden werden auf:

• Datenbankserver,
• Authentifizierungsserver,
• SMTP-Server,
• Proxys,
• externe APIs,
• Clusterknoten,
• Objekt- oder Netzwerkspeicher,
• Monitoring- und Protokollserver.

Einschränkungen:

• Nur aktuell geöffnete Verbindungen sind sichtbar.
• Kurzlebige Verbindungen können zwischen zwei Abfragen fehlen.
• Ein Ziel kann über einen Proxy vermittelt werden.
• IP-Adressen allein beweisen nicht die fachliche Funktion des Zielsystems.
• UDP-Kommunikation ist schwieriger zu bewerten.
• Eine aktuell fehlende Verbindung kann bei Leerlauf normal sein.

Wenn ein Dienst ein Backend über einen Namen anspricht, muss genau dieser Name aus dem Kontext des Dienstservers geprüft werden.

Zu prüfen:

• Wird der richtige Name verwendet?
• Wird die erwartete IP-Adresse geliefert?
• Existieren unerwartete alte Adressen?
• Gibt es unterschiedliche Ergebnisse auf Client und Server?
• Wird ein Suchsuffix benötigt?
• Verwendet die Anwendung einen vollständig qualifizierten Namen?
• Bevorzugt die Anwendung IPv6?
• Ist der DNS-Server aus dem Dienstkontext erreichbar?
• Wurde ein DNS-Eintrag kürzlich geändert?

Eine erfolgreiche DNS-Abfrage beweist nur die Namensauflösung. Der zurückgegebene Zielserver muss anschließend über das erforderliche Protokoll geprüft werden.

Windows:

[TEST] Test-NetConnection "<BACKEND>" -Port <PORT>

Linux:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

macOS:

[TEST] nc -vz -w 3 "<BACKEND>" <PORT>

Mögliche Ergebnisse:

Der Test muss vom tatsächlichen Anwendungsserver oder aus einem technisch gleichwertigen Netzwerkpfad erfolgen. Ein erfolgreicher Test vom Administrator-Client beweist nicht, dass der Dienstserver denselben Zugriff besitzt.

Nur Antwortheader eines HTTP- oder HTTPS-Endpunkts anfordern:

Ausführliche TLS- und Verbindungsdiagnose:

Zu prüfen:

• Wird die erwartete IP-Adresse verwendet?
• Ist der TCP-Verbindungsaufbau erfolgreich?
• Funktioniert der TLS-Handshake?
• Passt der Zertifikatsname?
• Welcher HTTP-Statuscode wird geliefert?
• Antwortet der erwartete Server?
• Erfolgt eine unerwartete Weiterleitung?
• Ist eine Authentifizierung erforderlich?
• Wie lange dauert die Antwort?

-v kann Header und andere sensible Informationen anzeigen. Zugangstoken oder Sitzungscookies dürfen nicht in die Befehlszeile oder Dokumentation übernommen werden.

Zu prüfen:

• Ist das Dateisystem eingehängt?
• Zeigt der Pfad auf das erwartete Ziel?
• Ist ausreichend Speicherplatz vorhanden?
• Sind unter Linux noch Inodes verfügbar?
• Ist das Dateisystem schreibgeschützt?
• Besitzt das Dienstkonto die erforderlichen Rechte?
• Ist ein Netzwerkmount nur scheinbar vorhanden, aber nicht erreichbar?
• Bestehen Dateisperren?
• Hat sich der Mountpfad geändert?
• Ist das Volume nach einem Neustart automatisch eingebunden worden?

Schreibtests verändern das Dateisystem und dürfen nur gezielt, mit freigegebenem Testpfad und anschließendem Aufräumen durchgeführt werden.

Falsche Systemzeit kann unter anderem folgende Funktionen beeinträchtigen:

• Kerberos-Authentifizierung,
• Zertifikatsprüfung,
• signierte Tokens,
• Protokollkorrelation,
• zeitgesteuerte Aufgaben,
• Datenbankreplikation,
• Clusterentscheidungen,
• Ablaufzeiten und Cache-Gültigkeit.

Prüfung:

• Stimmen Datum und Uhrzeit?
• Ist die richtige Zeitzone eingestellt?
• Ist die Zeitquelle erreichbar?
• Sind Client, Dienstserver und Backend ausreichend synchron?
• Stimmen Protokollzeitstempel tatsächlich überein?
• Verwendet eine Anwendung UTC, während eine andere lokale Zeit protokolliert?

Typische abhängige Identitätsdienste:

• Active Directory,
• LDAP oder LDAPS,
• Kerberos,
• RADIUS,
• lokale Benutzerverwaltung,
• OAuth- oder OpenID-Connect-Anbieter,
• SAML-Identitätsanbieter,
• Zertifikats- oder Smartcard-Infrastruktur.

Vor einer Anmeldeprüfung kontrollieren:

1. Wird der Identitätsserver korrekt aufgelöst?
2. Ist der erforderliche Port erreichbar?
3. Ist die Systemzeit synchron?
4. Ist das Dienstkonto aktiv?
5. Ist das Kennwort beziehungsweise Secret gültig?
6. Ist das Konto gesperrt?
7. Besitzt das Konto die erforderlichen Rechte?
8. Ist das Serverzertifikat gültig?
9. Funktioniert nur die Anmeldung nicht oder auch die gesamte Anwendung?
10. Sind alle Benutzer oder nur einzelne Konten betroffen?

Kennwörter, Tokens und private Schlüssel dürfen niemals in Diagnoseausgaben, Tickets oder BookStack-Beispiele kopiert werden.

Wenn mehrere Dienste gleichzeitig ausfallen, sollte nach einer gemeinsamen Komponente gesucht werden.

Vorgehen:

1. Betroffene Dienste auflisten
2. Zeitpunkt jedes Ausfalls vergleichen
3. Gemeinsame DNS-, Netzwerk- und Speicherpfade bestimmen
4. Gemeinsame Datenbanken und Identitätsdienste bestimmen
5. Gemeinsame Änderungen ermitteln
6. Gemeinsame Abhängigkeit direkt prüfen
7. Nach Wiederherstellung alle abhängigen Funktionen testen

Ein Dienst kann laut Betriebssystem gestartet worden sein, obwohl seine Funktion noch nicht vollständig bereitsteht.

Beispiel:

00:00 Datenbankprozess startet
00:02 Dienstverwaltung meldet „läuft“
00:05 Datenbank führt Wiederherstellung aus
00:40 Datenbank nimmt Anmeldungen an

Startet die Anwendung bereits bei Sekunde 3, kann ihre Verbindung fehlschlagen, obwohl der Datenbankdienst formal läuft.

Mögliche Lösungen innerhalb eines geplanten Änderungsverfahrens:

• geeignete Bereitschaftsprüfung,
• Wiederholungsversuche mit Begrenzung,
• zunehmende Wartezeiten zwischen Versuchen,
• sinnvoller Verbindungstimeout,
• korrekte systemd-Abhängigkeit,
• orchestrierte Healthchecks,
• Start erst nach erfolgreichem Backendtest,
• Warteschlange für vorübergehend nicht verarbeitbare Aufgaben.

Eine feste Wartezeit ist häufig weniger zuverlässig als eine echte Bereitschaftsprüfung.

Vor dem Neustart eines gemeinsam verwendeten Dienstes müssen die abhängigen Verbraucher bestimmt werden.

Windows:

[RO] (Get-Service -Name "<DIENSTNAME>").DependentServices |
    Select-Object Name, DisplayName, Status

Linux:

[RO] systemctl list-dependencies \
  --reverse \
  --no-pager \
  "<DIENST>"

macOS:

Da launchd kein allgemeines ausdrückliches Abhängigkeitsmodell besitzt, müssen zusätzlich geprüft werden:

• Herstellerdokumentation,
• aktive Netzwerkverbindungen,
• Konfigurationsdateien,
• Architekturübersicht,
• Monitoring,
• Anwendungsprotokolle,
• bekannte Verbraucher des Dienstes.

Freigabecheck:

[ ] Alle bekannten Verbraucher identifiziert
[ ] Aktive Sitzungen und Transaktionen geprüft
[ ] Cluster- oder Failover-Verhalten geprüft
[ ] Wiederverbindungsverhalten der Clients bekannt
[ ] Neustartreihenfolge festgelegt
[ ] Wartungsfenster beziehungsweise Freigabe vorhanden
[ ] Diagnoseinformationen vorab gesichert
[ ] Funktionstests für alle wichtigen Verbraucher vorbereitet
[ ] Rückfallmöglichkeit festgelegt

Empfohlene Reihenfolge:

1. Hauptfunktion und Fehlermeldung bestimmen.
2. Formale Dienstabhängigkeiten erfassen.
3. Architektur und funktionale Abhängigkeiten ergänzen.
4. Kritische und optionale Abhängigkeiten kennzeichnen.
5. Namen der Zielsysteme prüfen.
6. DNS-Auflösung prüfen.
7. Netzwerkport vom tatsächlichen Dienstserver prüfen.
8. TLS- und Zertifikatsprüfung durchführen.
9. Protokollspezifischen Funktionstest durchführen.
10. Authentifizierung mit einem freigegebenen Testkonto prüfen.
11. Speicher- und Ressourcenabhängigkeiten prüfen.
12. Zeitstempel der beteiligten Systeme vergleichen.
13. Protokolle auf Quelle und Ziel korrelieren.
14. Gemeinsame Abhängigkeiten anderer gestörter Dienste prüfen.
15. Erst nach gesicherter Ursache eine Änderung planen.

Prüfkette:

Name korrekt?
  ↓
DNS korrekt?
  ↓
Route vorhanden?
  ↓
Port erreichbar?
  ↓
TLS gültig?
  ↓
Protokoll antwortet?
  ↓
Authentifizierung erfolgreich?
  ↓
Berechtigung ausreichend?
  ↓
Fachliche Anfrage erfolgreich?

[ ] Hauptdienst eindeutig bestimmt
[ ] Formale Betriebssystem-Abhängigkeiten erfasst
[ ] Vorwärts gerichtete Abhängigkeiten geprüft
[ ] Rückwärts gerichtete Abhängigkeiten geprüft
[ ] Startreihenfolge getrennt von Anforderung bewertet
[ ] Kritische und optionale Abhängigkeiten unterschieden
[ ] Externe Datenbanken erfasst
[ ] DNS- und Zeitabhängigkeiten erfasst
[ ] Authentifizierungsdienste erfasst
[ ] Speicher- und Dateisystemabhängigkeiten erfasst
[ ] Proxys, Loadbalancer und APIs erfasst
[ ] Container-, Cluster- oder Cloud-Abhängigkeiten berücksichtigt
[ ] DNS-Auflösung vom Dienstserver geprüft
[ ] Zielport vom Dienstserver geprüft
[ ] TLS und Zertifikatsname geprüft
[ ] Protokollspezifischer Funktionstest durchgeführt
[ ] Gemeinsame Abhängigkeiten anderer Störungen geprüft
[ ] Protokollzeitstempel korreliert
[ ] Auswirkungen eines Neustarts bewertet
[ ] Keine Geheimnisse dokumentiert
[ ] Nächsten Diagnoseschritt festgelegt