Checkliste¶
Check-Block-01: Ist Benutzer-/Gruppen-Besitz von Konfigurationsdateien auf root/cinder eingestellt?¶
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally, modifies or deletes any of the parameters or the file itself then it would cause severe availability issues resulting in a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to cinder. Additionally, the containing directory should have the same ownership to ensure that new files are owned correctly.
Führen Sie die folgenden Befehle aus:
$ stat -L -c "%U %G" /etc/cinder/cinder.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/api-paste.ini | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/policy.json | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/rootwrap.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder | egrep "root cinder"
Pass: Wenn Besitzer und Gruppenbesitz aller dieser Konfigurationsdateien auf root und cinder gesetzt sind. Die obigen Befehle zeigen die Ausgabe von root cinder.
Fail: Wenn die obigen Befehle keine Ausgabe zurückgeben, da die Besitzer und Gruppeneigentümer möglicherweise auf einen anderen Benutzer als root oder eine andere Gruppe als cinder eingestellt sind.
Check-Block-02: Sind strenge Berechtigungen für Konfigurationsdateien festgelegt?¶
Ähnlich wie bei der vorherigen Prüfung empfehlen wir die Einstellung von strengen Zugriffsberechtigungen für solche Konfigurationsdateien.
Führen Sie die folgenden Befehle aus:
$ stat -L -c "%a" /etc/cinder/cinder.conf
$ stat -L -c "%a" /etc/cinder/api-paste.ini
$ stat -L -c "%a" /etc/cinder/policy.json
$ stat -L -c "%a" /etc/cinder/rootwrap.conf
$ stat -L -c "%a" /etc/cinder
A broader restriction is also possible: if the containing directory is set to 750, the guarantee is made that newly created files inside this directory would have the desired permissions.
Pass: If permissions are set to 640 or stricter, or the containing directory is set to 750. The permissions of 640/750 translates into owner r/w, group r, and no rights to others i.e. „u=rw,g=r,o=“. Note that with Check-Block-01: Ist Benutzer-/Gruppen-Besitz von Konfigurationsdateien auf root/cinder eingestellt? and permissions set to 640, root has read/write access and cinder has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs.
$ getfacl --tabular -a /etc/cinder/cinder.conf
getfacl: Removing leading '/' from absolute path names
# file: etc/cinder/cinder.conf
USER root rw-
GROUP cinder r--
mask r--
other ---
Fail: Wenn die Berechtigungen nicht auf mindestens 640 festgelegt sind.
Check-Block-03: Wird Keystone für die Authentifizierung verwendet?¶
Bemerkung
Dieser Punkt ist nur gültig für die OpenStack Releases Rocky und früher da auth_strategy in Stein als veraltet erklärt wurde.
OpenStack unterstützt verschiedene Authentifizierungsstrategien wie noauth, keystone etc. Wenn die ‚noauth‘-Strategie verwendet wird, können die Benutzer mit OpenStack-Diensten ohne Authentifizierung interagieren. Dies könnte ein potentielles Risiko darstellen, da ein Angreifer einen unbefugten Zugriff auf die OpenStack-Komponenten erhalten könnte. So empfehlen wir dringend, dass alle Dienste mit Keystone mit ihren Servicekonten authentifiziert werden müssen.
Pass: Wenn der Wert des Parameters auth_strategy in der [DEFAULT] Sektion in /etc/cinder/cinder.conf auf keystone gesetzt ist.
Fail: Wenn der Wert des Parameters auth_strategy in der [DEFAULT] Sektion auf noauth gesetzt ist.
Check-Block-04: Ist TLS für die Authentifizierung aktiviert?¶
OpenStack Kompponenten kommunizieren miteinander über verschiedene Protokolle und die Kommunikation kann sensitive/vertrauliche Daten beinhalten. Ein Angreifer kann versuchen den Kanal abzuhören, um auf sensitive Informationen zuzugreifen. Daher müssen alle Komponenten untereinander Daten über ein gesichertes Kommunikationsprotokoll austauschen.
Pass: Wenn der Wert des Parameter www_authenticate_uri im [keystone_authtoken] Abschnitt in /etc/cinder/cinder.conf gesetzt ist zum Identity API Endpunkt startend mit https:// und der Wert des Parameter insecure im selben [keystone_authtoken] Abschnitt in der selben /etc/cinder/cinder.conf auf False gesetzt ist.
Fail: Wenn der Wert des Parameter authenticate_uri im [keystone_authtoken] Abschnitt in /etc/cinder/cinder.conf nicht gesetzt ist zum Identity API Endpunkt startend mit https:// und der Wert des Parameter insecure im selben [keystone_authtoken] Abschnitt in der selben /etc/cinder/cinder.conf auf True gesetzt ist.
Check-Block-05: Wird Cinder mit Nova über TLS kommunizieren?¶
OpenStack Kompponenten kommunizieren miteinander über verschiedene Protokolle und die Kommunikation kann sensitive/vertrauliche Daten beinhalten. Ein Angreifer kann versuchen den Kanal abzuhören, um auf sensitive Informationen zuzugreifen. Daher müssen alle Komponenten untereinander Daten über ein gesichertes Kommunikationsprotokoll austauschen.
Pass: Wert des Parameters nova_api_insecure in der [DEFAULT] Sektion in /etc/cinder/cinder.conf ist auf False gesetzt.
Fail: Der Wert des Parameters nova_api_insecure in der [DEFAULT] Sektion in /etc/cinder/cinder.conf ist auf True gesetzt.
Check-Block-06: Kommuniziert Cinder mit Glance über TLS?¶
Ähnlich wie bei der vorherigen Prüfung (Check-Block-05: Wird Cinder mit Nova über TLS kommunizieren?) empfehlen wir, dass alle Komponenten mit einem gesicherten Kommunikationsprotokoll miteinander kommunizieren.
Pass: Wenn der Wert des Parameter glance_api_insecure im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf auf False gesetzt ist und der Wert des Parameter glance_api_servers ist auf einen Wert startend mit https:// gesetzt.
Fail: Wenn der Wert des Parameter glance_api_insecure im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf auf True gesetzt ist und der Wert des Parameter glance_api_servers ist nicht auf einen Wert startend mit https:// gesetzt.
Check-Block-07: Ist der NAS-Betrieb in einer sicheren Umgebung?¶
Cinder unterstützt einen NFS-Treiber, der anders arbeitet als ein herkömmlicher Blockspeichertreiber. Der NFS-Treiber erlaubt nicht, dass eine Instanz auf Blockspeicher auf ein Speichergerät zugreift. Stattdessen werden Dateien auf einer NFS-Freigabe erstellt und auf Instanzen abgebildet, die ein Blockgerät emuliert. Cinder unterstützt die sichere Konfiguration für solche Dateien, indem es die Dateiberechtigungen steuert, wenn Cinder-Volumes erstellt werden. Die Cinder-Konfiguration kann auch steuern, ob Dateiverwendungen als Root-Benutzer oder der aktuelle OpenStack-Prozessbenutzer ausgeführt werden.
Pass: Wenn der Wert des Parameter nas_secure_file_permissions im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf ist gesetzt auf auto. Wenn es auf auto gesetzt ist, wird ein Check beim Start von Cinder gemacht, ob keine Cinder Datenträger mit der Option True existieren, und sicher Dateirechte gesetzt sind. Die Untersuchung auf existierende Datenträger wird die Option auf False setzen, und die derzeit unsichere Methode auf Behandlung der Dateirechte benutzen. Wenn der Wert des Parameter nas_secure_file_operations im [DEFAULT] Abschnitt in /etc/cinder/cinder.conf ist auf auto gesetzt. Wenn es auf „auto“ gesetzt ist, wird ein Check beim Start von Cinder, ob kein Datenträger mit der Option True existiert, sicher ist und NICHT unter root Benutzer läuft. Die Untersuchung auf existierende Datenträger wird die Option auf False setzen, und die derzeit unsichere Methode von laufenden Betrieb als root Benutzer benutzen. Für neue Installationen, wurde eine „Marker Datei“ geschrieben, sodass is written so dass nachfolgende Neustarts von Cinder wissen, was die ursprüngliche Bestimmung gewesen ist.
Fail: Wenn der Wert des Parameter nas_secure_file_permissions im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf ist auf False gesetzt und wenn der Wert des Parameter nas_secure_file_operations im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf ist auf False gesetzt.
Check-Block-08: Ist die maximale Größe für den Körper einer Anforderung auf Default gesetzt (114688)?¶
Wenn die maximale Körpergröße pro Anfrage nicht definiert ist, kann der Angreifer eine beliebige osapi-Anforderung von großer Größe erstellen, die den Dienst zum Absturz bringt und schließlich zu einem Denial Of Service-Angriff führt. Die Zuweisung des Maximalwertes stellt sicher, dass jede böswillige, überdimensionierte Anfrage gesperrt wird, um eine fortgesetzte Verfügbarkeit des Dienstes zu gewährleisten.
Pass: Wenn der Wert des Parameter osapi_max_request_body_size im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf ist auf 114688 gesetzt oder wenn der Wert des Parameter max_request_body_size unter dem [oslo_middleware] Abschnitt in der /etc/cinder/cinder.conf auf 114688 gesetzt ist.
Fail: Wenn der Wer des Parameter osapi_max_request_body_size im [DEFAULT] Abschnitt in der /etc/cinder/cinder.conf nicht auf 114688 gesetzt ist oder wenn der Wert des Parameter max_request_body_size unter dem [oslo_middleware] Abschnitt in der /etc/cinder/cinder.conf ist nicht auf 114688 gesetzt.
Check-Block-09: Ist die Volumenverschlüsselungsfunktion aktiviert?¶
Unverschlüsselte Datenträgerdaten machen Volumen-Hosting-Plattformen besonders hochwertige Ziele für Angreifer, da es dem Angreifer erlaubt, die Daten für viele verschiedene VMs zu lesen. Darüber hinaus könnte das physikalische Speichermedium gestohlen, wieder montiert und von einer anderen Maschine abgerufen werden. Das Verschlüsseln von Datenträgern verringert diese Risiken und bietet Verteidigungs-Vertiefung auf Volumen-Hosting-Plattformen. Block Storage (Cinder) ist in der Lage, Volume-Daten zu verschlüsseln, bevor es auf Festplatte geschrieben wird, und wir empfehlen, dass die Volume-Verschlüsselung Funktion aktiviert ist. Siehe Volume Encryption Abschnitt der Openstack-Cinder Konfigurationsdokumentation für Anweisungen.
Pass: Wenn 1) der Wert des Parameter backend im [key_manager] Abschnitt in der /etc/cinder/cinder.conf gesetzt ist, 2) der Wert des Parameter backend im [key_manager] Abschnitt in der``/etc/nova/nova.conf`` gesetzt ist, und 3) wenn die Instruktionen der Dokumentation entsprechend befolgt sind.
Um dies zu überprüfen, führen Sie diese Schritte aus, nachdem Sie das Volume-Verschlüsselungs-Setup abgeschlossen haben und den Datenträgertyp für LUKS erstellen, wie in der oben genannten Dokumentation beschrieben.
Erstellen einer VM:
$ openstack server create --image cirros-0.3.1-x86_64-disk --flavor m1.tiny TESTVM
Erstellen Sie ein verschlüsseltes Volume und fügen Sie es Ihrem VM hinzu:
$ openstack volume create --size 1 --type LUKS 'encrypted volume' $ openstack volume list $ openstack server add volume --device /dev/vdb TESTVM 'encrypted volume'
Auf der VM senden Sie einen Text an das neu angeschlossene Volume und synchronisieren Sie es:
# echo "Hello, world (encrypted /dev/vdb)" >> /dev/vdb # sync && sleep 2
Auf dem System Hosting Cinder Volume-Dienste, synchronisieren, um den I/O-Cache zu spülen, dann testen, um zu sehen, ob Ihre Zeichenfolge gefunden werden kann:
# sync && sleep 2 # strings /dev/stack-volumes/volume-* | grep "Hello"
Die Suche sollte nicht die Zeichenfolge zurückgeben, die in das verschlüsselte Volume geschrieben wurde.
Fail: Wenn 1) der Wert des Parameter backend im [key_manager] Abschnitt in der /etc/cinder/cinder.conf nicht gesetzt ist, 2) der Wert des Parameter backend unter [key_manager] in der /etc/nova/nova.conf nicht gesetzt ist, und 3) wenn die Instruktionen der Dokumentation nicht befolgt sind.
