Wazuh SCA einrichten und CIS-Ergebnisse richtig bewerten

Aktuelle Pakete sind nur ein Teil eines abgesicherten Servers. Auch die Konfiguration kann unnötige Risiken schaffen: Passwortanmeldung über SSH, zu großzügige Zugriffsrechte oder eine fehlende Auditierung. Wazuh prüft solche Einstellungen mit Security Configuration Assessment, kurz SCA.

Dabei wird eine Policy mit festgelegten Prüfungen auf dem Agenten ausgewertet. Für viele Betriebssysteme liefert Wazuh passende Profile mit. Das Ergebnis hilft mir, konkrete Änderungen zu planen. Die Prozentzahl allein genügt jedoch nicht: Erst der Policy-Name und der einzelne Prüfpunkt sagen, was wirklich geprüft wurde.

Was ist SCA überhaupt?

SCA steht für Security Configuration Assessment, auf Deutsch etwa „Bewertung der Sicherheitskonfiguration“. Die Idee ist einfach: Eine Checkliste legt fest, wie ein sicher eingerichtetes System aussehen sollte. Wazuh geht diese Liste auf jedem überwachten Rechner regelmäßig durch und meldet, welche Punkte erfüllt sind und welche nicht. Man kann es sich wie eine TÜV-Prüfung für die Einstellungen eines Servers vorstellen.

Typische Prüfpunkte sind zum Beispiel:

• Ist die direkte Anmeldung als root per SSH verboten?
• Ist die Passwortanmeldung per SSH abgeschaltet?
• Haben Dateien wie /etc/shadow die richtigen Zugriffsrechte?
• Läuft die Protokollierung mit auditd?

Jeder Punkt endet als bestanden, fehlgeschlagen oder nicht anwendbar. Daraus errechnet Wazuh einen Prozentwert. Die Checklisten heißen Policies. Viele davon basieren auf den Benchmarks des Center for Internet Security, kurz CIS, einem verbreiteten Standard für die Härtung von Betriebssystemen.

Wichtig: SCA prüft nur, es repariert nichts. Und es ist etwas anderes als die Schwachstellenerkennung:

Ein vollständig aktualisierter Server kann also trotzdem schlecht abschneiden, etwa wenn SSH noch Passwörter annimmt.

Zuerst die vorhandene Policy ansehen

Öffne beim betreffenden Agenten die SCA-Ansicht. Prüfe den Namen der Policy, die letzte Ausführung und die Zahl bestandener, fehlgeschlagener und nicht anwendbarer Prüfungen. Vergleiche die Policy mit der tatsächlichen Distribution und Version.

Auf einem Linux-Agenten liegen mitgelieferte Policies üblicherweise unter /var/ossec/ruleset/sca. Dort sollte man eigene Dateien nicht als dauerhafte Anpassung speichern, weil Paketinstallationen und Updates diese Verzeichnisse ersetzen können. SCA-Konfiguration

Die Liste verfügbarer Policies ist ein eigener Prüfpunkt. Ein unterstützter Agent und eine unterstützte CVE-Erkennung sind nicht automatisch gleichbedeutend mit einem passenden CIS-Profil.

Was ein fehlgeschlagener Check bedeutet

Ein Check besteht aus einer Bedingung, einer Erklärung und häufig einer Handlungsempfehlung. Er beschreibt eine konkrete Abweichung von der Policy. Daraus folgt noch nicht, dass du jeden Vorschlag ungeprüft auf jeden Server anwenden solltest.

Ein Backup-System, ein öffentlich erreichbarer Webserver und eine Entwicklungs-VM brauchen zum Teil unterschiedliche Einstellungen. Bei SSH teste ich zunächst den vorgesehenen Schlüsselzugang in einer zweiten Sitzung. Erst danach ändere ich Einstellungen, die mich andernfalls aussperren könnten.

Ich arbeite die Ergebnisse deshalb einzeln durch: Ist die Prüfung anwendbar? Stimmt ihr Ergebnis mit der effektiven Konfiguration überein? Welche Änderung ist sinnvoll? Wie prüfe ich sie, und welcher Rückweg bleibt? Nach einer Änderung lasse ich die Policy erneut auswerten.

Eine eigene kleine Linux-Policy verwenden

Für meine Ubuntu-26-Systeme habe ich ergänzende eigene Prüfungen eingerichtet. Sie ersetzen kein vollständiges CIS-Profil. Im Dashboard steht deshalb ausdrücklich, dass es sich um eine eigene Linux-Basisprüfung handelt.

Zum Einstieg habe ich eine kleine Policy linux-ssh-basis.yml geschrieben. Sie prüft zwei effektive SSH-Einstellungen auf Ubuntu beziehungsweise Debian mit OpenSSH. Beide Prüfungen lesen nur die Ausgabe von /usr/sbin/sshd -T; sie verändern keine Konfiguration. Sie benötigen einen funktionierenden OpenSSH-Server und passende Ausführungsrechte.

policy:
  id: "mytech_ssh_basis_v1"
  file: "linux-ssh-basis.yml"
  name: "mytech-home SSH Basis · 2 Prüfungen · kein CIS Benchmark"
  description: "Lokale Leseprüfungen für Ubuntu/Debian mit OpenSSH. Allgemeine sshd-Konfiguration; Match-Kontexte separat prüfen."
references:
  - https://documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/creating-custom-policies.html
checks:
  - id: 910001
    title: "Allgemeine SSH-Konfiguration verbietet Root-Anmeldung"
    description: "Liest die allgemeine effektive Konfiguration mit sshd -T."
    rationale: "Administrative Anmeldung über ein eigenes Konto erleichtert die Zuordnung."
    remediation: "Schlüsselzugang und sudo zuerst prüfen; PermitRootLogin gezielt konfigurieren, Match-Blöcke berücksichtigen."
    condition: all
    rules:
      - 'c:/usr/sbin/sshd -T -> r:^permitrootlogin no$'
  - id: 910002
    title: "Allgemeine SSH-Konfiguration deaktiviert Passwortanmeldung"
    description: "Prüft PasswordAuthentication; weitere Authentifizierungsarten müssen separat betrachtet werden."
    rationale: "Vermeidet einfache Passwortanmeldung auf einem für Schlüsselzugang eingerichteten Server."
    remediation: "Zuerst Schlüsselzugang in zweiter Sitzung testen. Passwort- und Keyboard-Interactive-Verfahren passend zum Zugangskonzept prüfen."
    condition: all
    rules:
      - 'c:/usr/sbin/sshd -T -> r:^passwordauthentication no$'

Lege die Datei auf dem Testagenten unter /var/ossec/etc/sca/linux-ssh-basis.yml ab. Füge in den vorhandenen SCA-Block seiner /var/ossec/etc/ossec.conf die Policy ein:

<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <policies>
    <policy>etc/sca/linux-ssh-basis.yml</policy>
  </policies>
</sca>

Ergänze vorhandene Policies, statt sie unbemerkt zu ersetzen. Starte den Agenten neu und kontrolliere anschließend ossec.log sowie den neuen SCA-Bericht. Die Syntax für eigene Policies beschreibt Wazuh.

Die Prüfung mit sshd -T betrachtet hier die allgemeine effektive Konfiguration. Benutzer- oder adressabhängige Match-Regeln brauchen zusätzliche Prüfungen mit dem jeweiligen Kontext. Ein bestandener allgemeiner Check beweist nicht, dass jede mögliche SSH-Verbindung identisch behandelt wird.

Zentral verteilen oder lokal installieren?

Bei wenigen Rechnern lässt sich eine geprüfte Policy über deinen vorhandenen Administrationsweg verteilen. Für eine zentrale Verteilung über Wazuh müssen zusätzliche Voraussetzungen beachtet werden. Insbesondere können Policies mit Befehlen eine Freigabe für remote bereitgestellte SCA-Kommandos erfordern.

Diese Freigabe erlaubt dem Manager entsprechende Befehle auf dem Agenten auszuführen. Das ist eine bewusste Vertrauensentscheidung und keine Einstellung, die ich beiläufig für alle Systeme einschalte. Die kleine Policy aus diesem Artikel ist für eine lokale Installation gedacht. Beginne auf einem Testagenten und prüfe den Inhalt selbst, bevor du sie breiter verteilst.

Zwei Prozentzahlen können etwas anderes messen

Eine eigene Policy mit 14 bestandenen von 14 Prüfungen würde 100 Prozent erreichen. Das bedeutet nicht, dass der Server einen umfangreichen CIS-Benchmark vollständig erfüllt. Es bedeutet nur, dass diese 14 Prüfungen bestanden wurden.

In meiner Installation trenne ich deshalb mitgelieferte Profile und eigene Ergänzungen. Ein Durchschnitt über verschiedene Profile ist für mich keine belastbare Rangliste „sicherster Server“. Aussagekräftiger sind dieselbe Policy auf vergleichbaren Systemen und die Entwicklung ihrer konkreten Prüfpunkte.

Dateiintegrität ergänzt die Konfigurationsprüfung

SCA bewertet Einstellungen. File Integrity Monitoring meldet Veränderungen an überwachten Dateien. Ich überwache damit ausgewählte kritische Konfigurationspfade, beispielsweise SSH-Einstellungen. Ein Dateisystem komplett ohne Größenplanung zu erfassen erzeugt dagegen schnell unnötige Last und stößt an Grenzen.

Ein kleiner zusätzlicher syscheck-Abschnitt sieht so aus:

<!-- Verzeichnisse in einen bestehenden syscheck-Abschnitt integrieren.
     Nur Pfade aufnehmen, die auf dem Agenten existieren.
     Dieser Ausschnitt ist keine vollständige ossec.conf. -->
<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <directories realtime="yes" check_all="yes" report_changes="no">/etc/ssh</directories>
  <directories realtime="yes" check_all="yes" report_changes="no">/etc/sudoers.d</directories>
</syscheck>

In einer bestehenden Agentenkonfiguration ergänzt du dessen Verzeichniseinträge in den bereits vorhandenen Abschnitt. report_changes bleibt deaktiviert: Ich möchte keine Passwort- oder Schlüsselwerte aus Konfigurationsdateien als Dateidiff in den Logs verteilen. FIM-Grundeinstellungen

Bei meinem größeren Webserver musste die Dateigrenze an den tatsächlich erfassten Bestand angepasst werden. Diese Einstellung lässt sich nicht sinnvoll pauschal aus einem fremden Homelab übernehmen. Kontrolliere Last, Dateizahl und Modulmeldungen auf deinem eigenen System.

SCA und FIM werden damit nachvollziehbare Werkzeuge: Die eine Ansicht beantwortet, welche Konfiguration von der Policy abweicht; die andere, was sich seit der letzten Erfassung geändert hat. Ein Paketupdate ersetzt beide Aufgaben nicht.