Generiert SCAP-, Ansible-, Bash- und CEL-Sicherheitsinhalte zur Compliance-Bewertung und automatisierten Härtung von Linux-Hosts, Containern und Kubernetes.
Der Zweck dieses Projekts ist die Erstellung von Inhalten für Sicherheitsrichtlinien für verschiedene Plattformen — Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, SUSE Linux Enterprise Server (SLES),... — sowie für Produkte — Firefox,... Wir möchten das Schreiben neuer und die Pflege bestehender Sicherheitsinhalte in allen gängigen Formaten so einfach wie möglich machen.
„SCAP-Content" bezeichnet Dokumente in den Formaten XCCDF, OVAL und SCAP-Source-Data-Stream. Diese Dokumente können von verschiedenen Organisationen in unterschiedlichen Formen dargestellt werden, um deren Anforderungen an Sicherheitsautomatisierung und technische Umsetzung zu erfüllen. Für den allgemeinen Gebrauch empfehlen wir SCAP-Source-Data-Streams, da sie alle Daten enthalten, die Sie benötigen, um Maschinen zu bewerten und in Konformität zu bringen. Die Data Streams sind Teil unserer Release-ZIP-Archive.
„Ansible-Content" bezeichnet Ansible-Playbooks, die aus Sicherheitsprofilen generiert werden. Diese können sowohl im Check-Modus zur Bewertung der Konformität als auch im Run-Modus verwendet werden, um Maschinen in Konformität zu bringen. Wir veröffentlichen diese auf Ansible Galaxy sowie in Release-ZIP-Archiven.
„Bash-Fix-Dateien" beziehen sich auf Bash-Skripte, die aus Sicherheitsprofilen generiert werden. Sie sind dafür gedacht, auf Maschinen ausgeführt zu werden, um diese in Konformität zu bringen. Wir empfehlen die Verwendung anderer Formate, verstehen aber, dass Bash in einigen Bereitstellungsszenarien die einzige Option ist.
„CEL-Content" bezeichnet Konformitätsinhalte, die die Common Expression Language (CEL) für Kubernetes- und OpenShift-Plattformen verwenden. CEL-Content wird als YAML-Dateien generiert und ist für die native Bewertung von Kubernetes-Ressourcen über den compliance-operator konzipiert, ohne dass Shell-Zugriff auf die Knoten erforderlich ist. Dieses Format wird für Konformitätsprüfungen auf Plattformebene in Container-Orchestrierungssystemen verwendet.
Wir möchten, dass mehrere Organisationen Sicherheitsinhalte effizient entwickeln können. Durch die Nutzung des leistungsstarken Build-Systems dieses Projekts vermeiden wir so viel Redundanz wie möglich.
Das Build-System kombiniert die einfach zu bearbeitenden YAML-Regeldateien mit OVAL-Prüfungen, Ansible-Task-Snippets, Bash-Fixes und anderen Dateien. In jedem Schritt wird Templating bereitgestellt, um Boilerplate zu vermeiden. Sicherheitskennungen (CCE, NIST ID, STIG, ...) erscheinen in allen unseren Ausgabeformaten, stammen aber alle aus den YAML-Regeldateien.
Wir verstehen, dass Sie je nach den Anforderungen Ihrer Organisation möglicherweise ein bestimmtes Sicherheitsinhaltsformat verwenden müssen. Wir überlassen Ihnen die Wahl.
Wir verwenden ein an OpenControl angelehntes YAML-Regelformat für die Eingabe. Einmal schreiben und Sicherheitsinhalte in XCCDF, Ansible und anderen Formaten generieren.
title: 'Configure The Number of Allowed Simultaneous Requests'
description: |-
The <tt>MaxKeepAliveRequests</tt> directive should be set and configured to
<sub idref="var_max_keepalive_requests" /> or greater by setting the following
in <tt>/etc/httpd/conf/httpd.conf</tt>:
<pre>MaxKeepAliveRequests {{{ xccdf_value("var_max_keepalive_requests") }}}</pre>
rationale: |-
Resource exhaustion can occur when an unlimited number of concurrent requests
are allowed on a web site, facilitating a denial of service attack. Mitigating
this kind of attack will include limiting the number of concurrent HTTP/HTTPS
requests per IP address and may include, where feasible, limiting parameter
values associated with keepalive, (i.e., a parameter used to limit the amount of
time a connection may be inactive).
severity: medium
identifiers:
cce: "80551-5"
Unsere Sicherheitsinhalte können zum Scannen von Bare-Metal-Maschinen, virtuellen Maschinen, Images virtueller Maschinen (qcow2 und andere), Containern (einschließlich Docker) und Container-Images verwendet werden.
Wir verwenden Plattformprüfungen, um zu erkennen, ob wir einige der Regeln auswerten sollten oder nicht. Zum Beispiel: Separate Partitionsprüfungen ergeben auf Bare-Metal-Maschinen absolut Sinn, widersprechen jedoch den empfohlenen Vorgehensweisen bei Containern.
Die bevorzugte Installationsmethode ist über den Paketmanager Ihrer Distribution. Unter Red Hat Enterprise Linux und Fedora können Sie Folgendes verwenden:
yum install scap-security-guide
Unter Debian (sid) können Sie Folgendes verwenden:
apt install ssg-debian # for Debian guides
apt install ssg-debderived # for Debian-based distributions (e.g. Ubuntu) guides
apt install ssg-nondebian # for other distributions guides (RHEL, Fedora, etc.)
apt install ssg-applications # for application-oriented guides (Firefox, JBoss, etc.)
Laden Sie das vorgefertigte SSG-ZIP-Archiv von der Release-Seite herunter. Jede ZIP-Datei ist ein Archiv mit fertigen SCAP-Source-Data-Streams.
Wenn ComplianceAsCode nicht in Ihrer Distribution enthalten ist (es kann dort als Paket scap-security-guide vorhanden sein) oder wenn die enthaltene Version zu alt ist, müssen Sie den Content selbst erstellen und über make install installieren. Weitere Informationen finden Sie im Dokument Entwicklerhandbuch. Wir empfehlen außerdem, ein Issue im Bugtracker der jeweiligen Distribution zu eröffnen, um Interesse zu bekunden.