SLES 16 härten und prüfen: OpenSCAP, CIS-Einordnung und SUSE Multi-Linux Manager

Dieser Lab-Beitrag schließt eine praktische Lücke in der SUSE-Reihe: Er bleibt nicht bei der Installation von SLES 16 stehen, sondern zeigt, wie sich ein verwalteter SLES-16-Server verhält, wenn OpenSCAP-Inhalte, Hardening-Profile, Remediation und SUSE Multi-Linux Manager Lifecycle-Channels zusammenkommen.

Die wichtigste Einordnung ist bewusst sauber formuliert: CIS veröffentlicht einen Benchmark für SUSE Linux Enterprise 16. Das in diesem Lab installierte SUSE-Paket scap-security-guide stellt für SLE 16 aber ANSSI-, HIPAA-, PCI-DSS- und Basisprofile bereit, kein direkt nutzbares CIS-Level-2-Profil. Deshalb dokumentiert dieser Beitrag einen ANSSI-BP-028-high-Lauf und erklärt, wie CIS Level 2 fachlich korrekt behandelt werden muss.

Warum CIS, OpenSCAP und Hardening wichtig sind

CIS Benchmarks sind hersteller- und community-gepflegte Sicherheitsbaselines. Sie übersetzen typische Hardening-Fragen in konkrete Prüfpunkte: Passwortregeln, SSH-Verhalten, sudo-Einschränkungen, Dateirechte, Audit-Regeln, Kernel-Parameter und Logging. In der Praxis sind sie hilfreich, weil Security, Audit und Betrieb über dieselbe technische Baseline sprechen können und nicht über unscharfe Bauchgefühle.

OpenSCAP ist Werkzeuging für maschinenlesbare SCAP-Inhalte. Mit oscap lässt sich ein System prüfen, ein HTML-Report erzeugen und je nach Profil Remediation als Bash- oder Ansible-Variante generieren. Damit wird Hardening wiederholbar: erst messen, dann gezielt ändern, danach erneut scannen und Ausnahmen dokumentieren.

SUSE Multi-Linux Manager ergänzt die betriebliche Ebene dazu. Pakete, Profile, Remediation-Läufe und Nachweise liegen nicht auf einer isolierten Testmaschine, sondern im gleichen Lifecycle-, Proxy- und Channel-Modell, über das auch produktive Server versorgt werden. Deshalb prüft dieser Beitrag zuerst Manager und Channel-Pfad, bevor es um Scores geht.

Begriffe kompakt

Lab-Aufbau

Verwendete Systeme

mlm01.example.test

Der SLES-16-Client war über den Proxy erreichbar, im SUSE Multi-Linux Manager registriert und einem produktiven Lifecycle-Channel zugeordnet. Genau das ist für eine Kundenumgebung wichtig: Compliance muss über denselben Paket- und Proxy-Pfad funktionieren wie der normale Betrieb.

Channel-Readiness vor dem Hardening

Der erste Test war kein OpenSCAP-Scan, sondern die Paketverfügbarkeit am verwalteten Client. Eine Hardening-Anleitung hilft wenig, wenn Scanner und Security Guide im zugewiesenen Lifecycle-Channel fehlen.

zypper refresh
zypper se -s openscap scap-security-guide
rpm -q openscap openscap-utils libopenscap33 scap-security-guide

Im Lab hat der dem Client zugewiesene Produktiv-Channel nicht alle OpenSCAP-Pakete sichtbar gemacht, obwohl der Manager diese Pakete bereits in anderen synchronisierten SLES-16-Channels hatte. Das ist ein realistisches Lifecycle-Management-Problem: geklonte Channels können zu eng oder veraltet sein. Vor flächigen Scans muss die Channel-Zusammenstellung stimmen.

Paket-Readiness

Verfügbare SLES-16-Profile prüfen

oscap info /usr/share/xml/scap/ssg/content/ssg-sle16-ds.xml

Profil-Ergebnis

Baseline-Audit durchführen

mkdir -p /root/openscap-evidence/sles16-hardening-20261006
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --results /root/openscap-evidence/sles16-hardening-20261006/anssi-high-results.xml \
  --report /root/openscap-evidence/sles16-hardening-20261006/anssi-high-report.html \
  /usr/share/xml/scap/ssg/content/ssg-sle16-ds.xml

sles16-client01.example.test

Baseline-Ergebnis

Remediation kontrolliert vorbereiten

Vor der Remediation wurde die VM gesnapshottet. Bei hohen Hardening-Profilen ist das Pflicht. Partitionierung, sudo, Audit, PAM, SSH und Kernel-Parameter können Zugriff und Betrieb sofort verändern.

virsh snapshot-create-as \
  --domain sles16-client01 \
  --name before-openscap-anssi-high-20261006 \
  --description "Before SLES16 OpenSCAP ANSSI high remediation evidence run" \
  --disk-only --atomic --no-metadata

oscap xccdf generate fix --fix-type bash \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --output anssi-high-remediation.sh \
  anssi-high-results.xml

oscap xccdf generate fix --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --output anssi-high-remediation.yml \
  anssi-high-results.xml

Das Remediation-Skript lief durch, zeigte aber genau die Grenzen, die man in echten Umgebungen kennen muss: einzelne Pakete waren über den zugewiesenen Channel nicht erneut installierbar, eine SSSD-PAM-Remediation fehlte, und sudo wurde mit requiretty, noexec, use_pty und umask deutlich härter konfiguriert. Deshalb gehört Remediation in ein getestetes Wartungsfenster und nicht in einen blinden Einzeiler.

sles16-client01.example.test

Vorher und nachher

Was das für CIS Level 2 bedeutet

Ein ANSSI-high-Scan darf nicht in CIS Level 2 umbenannt werden. Wenn ein Kunde CIS Level 2 für SLES 16 verlangt, ist der saubere Weg: CIS-SLE-16-Benchmark-Inhalte beschaffen, mit CIS-CAT Pro oder einem validierten Tailoring-Workflow prüfen, lokale Ausnahmen dokumentieren und die Nachweise an die konkrete Benchmark-Version binden.

Technische Abnahme

Checkliste für produktive Systeme

Für Produktion gilt: Channel-Inhalte prüfen, Backup oder Snapshot erstellen, Baseline-Scan ausführen, Remediation lesen, Wartungsfenster planen, Änderungen anwenden, erneut scannen, Ausnahmen dokumentieren und erst danach entscheiden, ob das System für den jeweiligen Workload ausreichend gehärtet ist.