OWASP Docker Security Sheet: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(21 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Übersetzt aus dem Englischen=
== REGEL 0 – Host und Docker auf dem neuesten Stand halten ==
*https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
* Erklärung: Container teilen sich den Kernel mit dem Host. Kernel-Exploits im Container wirken direkt auf den Host.
* Risiko: Ein Angreifer kann über Schwachstellen wie „Dirty COW“ Root-Rechte auf dem Host erlangen. 
* Best Practice: Regelmäßige Updates von Docker Engine, Docker Machine und Linux-Kernel einspielen, Security Advisories abonnieren.


=Einführung=
== REGEL 1 – Docker-Daemon-Socket nicht freigeben ==
Docker ist die beliebteste Containerisierungstechnologie. Bei sachgemäßer Verwendung kann es das Sicherheitsniveau erhöhen (im Vergleich zum Ausführen von Anwendungen direkt auf dem Host). Andererseits können einige Fehlkonfigurationen dazu führen, dass das Sicherheitsniveau herabgestuft oder sogar neue Schwachstellen eingeführt werden.
* Erklärung: /var/run/docker.sock ist der Einstiegspunkt zur Docker-API – Besitzer = root.
* Risiko: Jeder mit Zugriff auf diesen Socket hat vollen Root-Zugriff auf den Host.
* Beispiel: Viele Images binden den Socket per „-v /var/run/docker.sock:/var/run/docker.sock“ ein → Privilege Escalation. 
* Best Practice: Socket niemals in Container mounten. Falls Remote-Zugriff nötig: TLS-gesicherter TCP-Socket mit Authentifizierung.


Das Ziel dieses Merkblatt ist es, eine benutzerfreundliche Liste mit häufigen Sicherheitsfehlern und bewährten Praktiken bereitzustellen, die Ihnen helfen, Ihre Docker-Container zu sichern.
== REGEL 2 – Benutzer festlegen ==
* Erklärung: Standardmäßig läuft der Container-Prozess als root. 
* Risiko: Kompromittierte Container-Prozesse können mit Root-Rechten auf Host-Ressourcen zugreifen. 
* Best Practice: 
** Im Dockerfile mit „USER“ setzen. 
** User Namespaces aktivieren (–userns-remap). 
** In Kubernetes runAsNonRoot verwenden.


=Regeln=
== REGEL 3 – Fähigkeiten beschränken ==
==REGEL 0 – Host und Docker auf dem neuesten Stand halten==
* Erklärung: Linux Capabilities sind granulare Root-Rechte (z. B. CHOWN, NET_ADMIN). 
Um bekannte, Container-Escape-Schwachstellen zu verhindern, die in der Regel mit einer Eskalation auf Root-/Administratorrechte enden, ist das Patchen von Docker Engine und Docker Machine von entscheidender Bedeutung.
* Risiko: Container mit „--privileged“ oder unnötigen Capabilities können Kernel-Operationen durchführen. 
* Best Practice: 
** Standardmäßig „--cap-drop all“ setzen, nur benötigte hinzufügen. 
** Niemals „--privileged“ nutzen. 
** In Kubernetes: capabilities im SecurityContext definieren.


Außerdem teilen sich Container (im Gegensatz zu virtuellen Maschinen) den Kernel mit dem Host, daher treffen Kernel-Exploits, die innerhalb des Containers ausgeführt werden, direkt auf den Host-Kernel. Zum Beispiel führt ein Exploit zur Ausweitung von Kernel-Privilegien ( wie Dirty COW ), der in einem gut isolierten Container ausgeführt wird, zu Root-Zugriff auf einen Host.
== REGEL 4 – no-new-privileges setzen ==
* Erklärung: Verhindert, dass Prozesse durch setuid/setgid zusätzliche Rechte erlangen. 
* Risiko: Ohne dieses Flag können Programme Rechte-Eskalation durchführen. 
* Best Practice: Container mit „--security-opt=no-new-privileges“ starten, in Kubernetes allowPrivilegeEscalation=false.


==REGEL #1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container)==
== REGEL 5 – Inter-Container-Kommunikation deaktivieren ==
Docker-Socket /var/run/docker.sock ist der UNIX-Socket, auf den Docker lauscht. Dies ist der primäre Einstiegspunkt für die Docker-API. Der Besitzer dieses Sockets ist root. Jemandem Zugriff darauf zu gewähren, entspricht dem uneingeschränkten Root-Zugriff auf Ihren Host.
* Erklärung: Standardmäßig können Container über das docker0-Bridge-Netzwerk miteinander kommunizieren.
* Risiko: Kompromittierter Container kann andere Container angreifen oder scannen.
* Best Practice: Docker mit „--icc=false“ starten, Kommunikation nur explizit erlauben. In Kubernetes: NetworkPolicies nutzen.


Aktivieren Sie den TCP- Docker-Daemon-Socket nicht. Wenn Sie einen Docker-Daemon mit -H tcp://0.0.0.0:XXXoder ähnlichem ausführen, stellen Sie unverschlüsselten und nicht authentifizierten direkten Zugriff auf den Docker-Daemon bereit. Wenn Sie dies wirklich, wirklich tun müssen, sollten Sie es sichern. Überprüfen Sie anhand der offiziellen Docker-Dokumentation, wie das geht .
== REGEL 6 – Linux-Sicherheitsmodule nutzen ==
* Erklärung: Seccomp, AppArmor, SELinux beschränken Systemaufrufe und Zugriffe von Prozessen.
* Risiko: Ohne Profile können Container auf kritische Kernel-Funktionen zugreifen.
* Best Practice: Standardprofile nicht deaktivieren, eigene Policies erstellen und strikt einsetzen.


Machen Sie /var/run/docker.sock nicht für andere Container verfügbar . Wenn Sie Ihr Docker-Image mit -v /var/run/docker.sock://var/run/docker.sockoder ähnlichem ausführen , sollten Sie es ändern. Denken Sie daran, dass das Mounten des Sockets schreibgeschützt keine Lösung ist, sondern nur die Ausnutzung erschwert. Äquivalent in der docker-compose-Datei ist etwa so:
== REGEL 7 – Ressourcen begrenzen ==
* Erklärung: Container können sonst unbeschränkt CPU, RAM, File-Deskriptoren nutzen.
* Risiko: DoS-Angriffe möglich, Host wird überlastet.
* Best Practice: Ressourcenlimits per „--memory“, „--cpu-shares“, „--ulimit“ setzen. In Kubernetes: Resource Limits definieren. 


<syntaxhighlight lang="json">
== REGEL 8 – Dateisysteme schreibgeschützt mounten ==
volumes:
* Erklärung: Container-Filesystem standardmäßig beschreibbar. 
- "/var/run/docker.sock:/var/run/docker.sock"
* Risiko: Malware kann Dateien manipulieren, Persistenz aufbauen. 
</syntaxhighlight>
* Best Practice: 
** „--read-only“ nutzen. 
** Schreibrechte nur für explizite tmpfs-Mounts.
** Volumes mit „:ro“ oder „readonly“ einbinden.


==REGEL #2 – Legen Sie einen Benutzer fest==
== REGEL 9 – Statische Analysetools einsetzen ==
Die Konfiguration des Containers für die Verwendung eines nicht privilegierten Benutzers ist der beste Weg, um Angriffe auf eine Rechteausweitung zu verhindern. Dies kann auf drei verschiedene Arten wie folgt erreicht werden:
* Erklärung: Container-Images können bekannte CVEs enthalten. 
* Risiko: Deployment von Images mit kritischen Sicherheitslücken. 
* Best Practice: 
** Tools wie Trivy, Clair, Anchore, Snyk oder Grype nutzen.
** In CI/CD-Pipeline integrieren. 


Während der Laufzeit mit -uOption des docker runBefehls zB:
== REGEL 10 – Logging konfigurieren ==
* Erklärung: Docker loggt standardmäßig auf „info“-Level. 
* Risiko: Wichtige Ereignisse fehlen oder Debug-Level erzeugt unnötige Datenmengen. 
* Best Practice: 
** Mindestens „info“-Level aktivieren. 
** Zentrale Log-Sammlung über ELK, Loki oder SIEM. 


docker run -u 4000 alpine
== REGEL 11 – Dockerfile absichern ==
Während der Bauzeit. Einfach Benutzer in Dockerfile hinzufügen und verwenden. Beispielsweise:
* Erklärung: Schlechte Praktiken im Dockerfile führen zu unsicheren Images.
<syntaxhighlight>
* Risiko: Root-User, ungepatchte Basis-Images, Curl-Bashing, unfixierte Versionen.
FROM alpine
* Best Practice:
RUN groupadd -r myuser && useradd -r -g myuser myuser
** Immer „USER“ definieren.
<HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>
** Basis-Images versionieren.
USER myuser
** COPY statt ADD verwenden.
</syntaxhighlight>
** Dockerfile mit Lintern prüfen (z. B. hadolint).
Aktivieren Sie die Unterstützung von Benutzernamensräumen ( --userns-remap=default) im Docker-Daemon
Weitere Informationen zu diesem Thema finden Sie in der offiziellen Docker-Dokumentation
 
In Kubernetes kann dies im Sicherheitskontext mithilfe eines runAsNonRootFelds konfiguriert werden , z. B.:
 
 
kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          runAsNonRoot: true
          ...
Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .
 
==REGEL #3 – Beschränken Sie die Fähigkeiten (Gewähre nur bestimmte Fähigkeiten, die von einem Container benötigt werden)==
Die Linux-Kernel-Fähigkeiten sind eine Reihe von Privilegien, die von Privilegierten verwendet werden können. Docker wird standardmäßig nur mit einer Teilmenge der Funktionen ausgeführt. Sie können es ändern und einige Funktionen löschen (mit --cap-drop), um Ihre Docker-Container zu härten, oder --cap-addbei Bedarf einige Funktionen hinzufügen (mit ). Denken Sie daran, keine Container mit dem --privilegedFlag auszuführen - dies fügt dem Container ALLE Linux-Kernel-Funktionen hinzu.
 
Die sicherste Einrichtung besteht darin, alle Funktionen zu löschen --cap-drop allund dann nur die erforderlichen hinzuzufügen. Beispielsweise:
 
 
docker run --cap-drop all --cap-add CHOWN alpine
Und denken Sie daran: Führen Sie keine Container mit dem Flag --privileged aus !!!
 
In Kubernetes kann dies im Sicherheitskontext mit einem capabilitiesFeld konfiguriert werden , z. B.:
 
 
kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          capabilities:
            drop:
              - all
            add:
              - CHOWN
          ...
Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .
 
==REGEL #4 – Füge das Flag „no-new-privileges“ hinzu==
Führen Sie Ihre Docker-Images immer mit --security-opt=no-new-privilegesaus, um zu verhindern, dass Berechtigungen setuidoder setgidBinärdateien eskalieren .
 
In Kubernetes kann dies im Sicherheitskontext mithilfe eines allowPrivilegeEscalationFelds konfiguriert werden , z. B.:
 
 
kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          allowPrivilegeEscalation: false
          ...
Als Kubernetes-Cluster-Administrator können Sie die Kubernetes-Dokumentation zur Konfiguration mit Pod-Sicherheitsrichtlinien verwenden .
 
==REGEL #5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false)==
Standardmäßig inter-Behälter - Kommunikation (ICC) ist aktiviert - es bedeutet , dass alle Behälter miteinander (unter Verwendung sprechen können docker0überbrückte Netzwerk ). Dies kann deaktiviert werden, indem der Docker-Daemon mit --icc=falseFlag ausgeführt wird. Wenn icc deaktiviert ist (icc=false), muss mit der Option --link=CONTAINER_NAME_or_ID:ALIAS mitgeteilt werden, welche Container kommunizieren können. Weitere Informationen finden Sie in der Docker-Dokumentation - Containerkommunikation
 
In Kubernetes können Netzwerkrichtlinien dafür verwendet werden.
 
==REGEL #6 – Linux-Sicherheitsmodul verwenden (seccomp, AppArmor oder SELinux)==
Deaktivieren Sie zunächst nicht das Standardsicherheitsprofil!
 
Ziehen Sie die Verwendung von Sicherheitsprofilen wie seccomp oder AppArmor in Betracht .
 
Anweisungen dazu in Kubernetes finden Sie in der Dokumentation zum Sicherheitskontext und in der Kubernetes-API-Dokumentation
 
==REGEL #7 – Ressourcen begrenzen (Speicher, CPU, Dateideskriptoren, Prozesse, Neustarts)==
Der beste Weg, um DoS-Angriffe zu vermeiden, besteht darin, die Ressourcen zu begrenzen. Sie können Speicher , CPU , maximale Anzahl von Neustarts ( --restart=on-failure:<number_of_restarts>), maximale Anzahl von Dateideskriptoren ( --ulimit nofile=<number>) und maximale Anzahl von Prozessen ( --ulimit nproc=<number>) begrenzen .
 
Weitere Informationen zu ulimits finden Sie in der Dokumentation
 
Sie können dies auch in Kubernetes tun: Zuweisen von Speicherressourcen zu Containern und Pods , Zuweisen von CPU-Ressourcen zu Containern und Pods und Zuweisen von erweiterten Ressourcen zu einem Container
 
==REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen==
Führen Sie Container mit einem schreibgeschützten Dateisystem mit --read-onlyFlag aus. Beispielsweise:
 
 
docker run --read-only alpine sh -c 'echo "whatever" > /tmp'
Wenn eine Anwendung in einem Container vorübergehend etwas speichern muss, kombinieren Sie --read-onlyFlag mit --tmpfswie folgt:
 
 
docker run --read-only --tmpfs /tmp alpine sh -c 'echo "whatever" > /tmp/file'
Äquivalent in der docker-compose-Datei ist:
 
 
version: "3"
services:
  alpine:
    image: alpine
    read_only: true
Äquivalent in Kubernetes im Sicherheitskontext ist:
 
 
kind: ...
apiVersion: ...
metadata:
  name: ...
spec:
  ...
  containers:
  - name: ...
    image: ....
    securityContext:
          ...
          readOnlyRootFilesystem: true
          ...
Wenn das Volume nur zum Lesen gemountet ist, mounten Sie es außerdem schreibgeschützt. Dies kann durch Anhängen :roan Folgendes erfolgen -v:
 
 
docker run -v volume-name:/path/in/container:ro alpine
Oder mit --mountOption:
 
 
docker run --mount source=volume-name,destination=/path/in/container,readonly alpine
==REGEL 9 – Verwenden Sie statische Analysetools==
Um Container mit bekannten Schwachstellen zu erkennen, scannen Sie Bilder mit statischen Analysetools.
 
Kostenlos
Clair
Wissenswertes
Kommerziell
Snyk (Open Source und kostenlose Option verfügbar)
Anker (Open Source und kostenlose Option verfügbar)
MicroScanner von Aqua Security (kostenlose Option für eine begrenzte Anzahl von Scans verfügbar)
JFrog XRay
Qualys
So erkennen Sie Fehlkonfigurationen in Kubernetes:
 
kubeaudit
kubesec.io
Kube-Bank
So erkennen Sie Fehlkonfigurationen in Docker:
 
inspec.io
dev-sec.io
==REGEL #10 - Setzen Sie die Protokollierungsebene auf mindestens INFO==
Standardmäßig ist der Docker-Daemon so konfiguriert, dass er einen Basis-Logging-Level von 'info' hat, und wenn dies nicht der Fall ist: Setzen Sie den Docker-Daemon-Log-Level auf 'info'. Begründung: Durch das Einrichten einer geeigneten Protokollebene wird der Docker-Daemon so konfiguriert, dass Ereignisse protokolliert werden, die Sie später überprüfen möchten. Eine Basisprotokollebene von 'info' und höher würde alle Protokolle außer den Debug-Protokollen erfassen. Solange dies nicht erforderlich ist, sollten Sie den Docker-Daemon nicht auf der Protokollebene 'debug' ausführen.
 
So konfigurieren Sie die Protokollebene in docker-compose:
 
 
docker-compose --log-level info up
Regel #11 – Lint das Dockerfile zur Build-Zeit¶
Viele Probleme können verhindert werden, indem Sie beim Schreiben des Dockerfiles einige Best Practices befolgen. Das Hinzufügen eines Sicherheits-Linters als Schritt in der Build-Pipeline kann viel dazu beitragen, weitere Kopfschmerzen zu vermeiden. Einige Punkte, die es wert sind, überprüft zu werden, sind:
 
Stellen Sie sicher, dass eine USERAnweisung angegeben ist
Stellen Sie sicher, dass die Basis-Image-Version angepinnt ist
Stellen Sie sicher, dass die Versionen der Betriebssystempakete angeheftet sind
Vermeiden Sie die Verwendung von ADDzugunsten vonCOPY
Vermeiden Sie Curl-Bashing in RUNDirektiven
Verweise:
 
Docker-Baselines auf DevSec
Verwenden Sie die Docker-Befehlszeile
Überblick über docker-compose CLI
Logging-Treiber konfigurieren
Protokolle für einen Container oder Dienst anzeigen
Bewährte Vorgehensweisen für Dockerfile-Sicherheit
Ähnliche Projekte¶
OWASP Docker Top 10
 
BisherigeDeserialisierung
NächsterDotNet-Sicherheit
=Links=
https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
 
©Copyright 2021 - CheatSheets Series Team - Dieses Werk ist lizenziert unter einer Creative Commons Attribution 3.0 Unported License .
Hergestellt mit Material für MkDocs

Aktuelle Version vom 14. September 2025, 08:32 Uhr

REGEL 0 – Host und Docker auf dem neuesten Stand halten

  • Erklärung: Container teilen sich den Kernel mit dem Host. Kernel-Exploits im Container wirken direkt auf den Host.
  • Risiko: Ein Angreifer kann über Schwachstellen wie „Dirty COW“ Root-Rechte auf dem Host erlangen.
  • Best Practice: Regelmäßige Updates von Docker Engine, Docker Machine und Linux-Kernel einspielen, Security Advisories abonnieren.

REGEL 1 – Docker-Daemon-Socket nicht freigeben

  • Erklärung: /var/run/docker.sock ist der Einstiegspunkt zur Docker-API – Besitzer = root.
  • Risiko: Jeder mit Zugriff auf diesen Socket hat vollen Root-Zugriff auf den Host.
  • Beispiel: Viele Images binden den Socket per „-v /var/run/docker.sock:/var/run/docker.sock“ ein → Privilege Escalation.
  • Best Practice: Socket niemals in Container mounten. Falls Remote-Zugriff nötig: TLS-gesicherter TCP-Socket mit Authentifizierung.

REGEL 2 – Benutzer festlegen

  • Erklärung: Standardmäßig läuft der Container-Prozess als root.
  • Risiko: Kompromittierte Container-Prozesse können mit Root-Rechten auf Host-Ressourcen zugreifen.
  • Best Practice:
    • Im Dockerfile mit „USER“ setzen.
    • User Namespaces aktivieren (–userns-remap).
    • In Kubernetes runAsNonRoot verwenden.

REGEL 3 – Fähigkeiten beschränken

  • Erklärung: Linux Capabilities sind granulare Root-Rechte (z. B. CHOWN, NET_ADMIN).
  • Risiko: Container mit „--privileged“ oder unnötigen Capabilities können Kernel-Operationen durchführen.
  • Best Practice:
    • Standardmäßig „--cap-drop all“ setzen, nur benötigte hinzufügen.
    • Niemals „--privileged“ nutzen.
    • In Kubernetes: capabilities im SecurityContext definieren.

REGEL 4 – no-new-privileges setzen

  • Erklärung: Verhindert, dass Prozesse durch setuid/setgid zusätzliche Rechte erlangen.
  • Risiko: Ohne dieses Flag können Programme Rechte-Eskalation durchführen.
  • Best Practice: Container mit „--security-opt=no-new-privileges“ starten, in Kubernetes allowPrivilegeEscalation=false.

REGEL 5 – Inter-Container-Kommunikation deaktivieren

  • Erklärung: Standardmäßig können Container über das docker0-Bridge-Netzwerk miteinander kommunizieren.
  • Risiko: Kompromittierter Container kann andere Container angreifen oder scannen.
  • Best Practice: Docker mit „--icc=false“ starten, Kommunikation nur explizit erlauben. In Kubernetes: NetworkPolicies nutzen.

REGEL 6 – Linux-Sicherheitsmodule nutzen

  • Erklärung: Seccomp, AppArmor, SELinux beschränken Systemaufrufe und Zugriffe von Prozessen.
  • Risiko: Ohne Profile können Container auf kritische Kernel-Funktionen zugreifen.
  • Best Practice: Standardprofile nicht deaktivieren, eigene Policies erstellen und strikt einsetzen.

REGEL 7 – Ressourcen begrenzen

  • Erklärung: Container können sonst unbeschränkt CPU, RAM, File-Deskriptoren nutzen.
  • Risiko: DoS-Angriffe möglich, Host wird überlastet.
  • Best Practice: Ressourcenlimits per „--memory“, „--cpu-shares“, „--ulimit“ setzen. In Kubernetes: Resource Limits definieren.

REGEL 8 – Dateisysteme schreibgeschützt mounten

  • Erklärung: Container-Filesystem standardmäßig beschreibbar.
  • Risiko: Malware kann Dateien manipulieren, Persistenz aufbauen.
  • Best Practice:
    • „--read-only“ nutzen.
    • Schreibrechte nur für explizite tmpfs-Mounts.
    • Volumes mit „:ro“ oder „readonly“ einbinden.

REGEL 9 – Statische Analysetools einsetzen

  • Erklärung: Container-Images können bekannte CVEs enthalten.
  • Risiko: Deployment von Images mit kritischen Sicherheitslücken.
  • Best Practice:
    • Tools wie Trivy, Clair, Anchore, Snyk oder Grype nutzen.
    • In CI/CD-Pipeline integrieren.

REGEL 10 – Logging konfigurieren

  • Erklärung: Docker loggt standardmäßig auf „info“-Level.
  • Risiko: Wichtige Ereignisse fehlen oder Debug-Level erzeugt unnötige Datenmengen.
  • Best Practice:
    • Mindestens „info“-Level aktivieren.
    • Zentrale Log-Sammlung über ELK, Loki oder SIEM.

REGEL 11 – Dockerfile absichern

  • Erklärung: Schlechte Praktiken im Dockerfile führen zu unsicheren Images.
  • Risiko: Root-User, ungepatchte Basis-Images, Curl-Bashing, unfixierte Versionen.
  • Best Practice:
    • Immer „USER“ definieren.
    • Basis-Images versionieren.
    • COPY statt ADD verwenden.
    • Dockerfile mit Lintern prüfen (z. B. hadolint).
Abgerufen von „https://wiki.ixheim.de/index.php?title=OWASP_Docker_Security_Sheet&oldid=64639“