mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 09:27:32 +00:00
Translated ['linux-hardening/privilege-escalation/docker-security/README
This commit is contained in:
Translator
parent
0bd62c4896
commit
33a385486b
1 changed files with 40 additions and 40 deletions
|
|
@ -10,11 +10,11 @@ Andere Möglichkeiten, HackTricks zu unterstützen:
|
|||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
|
||||
|
||||
</details>
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mithilfe der weltweit **fortschrittlichsten Community-Tools** **Workflows** einfach zu erstellen und zu **automatisieren**.\
|
||||
|
|
@ -42,7 +42,7 @@ Jedoch wird das Freigeben des Docker-Daemons über HTTP aufgrund von Sicherheits
|
|||
1. Der Client überprüft die Identität des Servers.
|
||||
2. Sowohl der Client als auch der Server authentifizieren gegenseitig die Identität des anderen.
|
||||
|
||||
Zur Bestätigung der Identität eines Servers werden Zertifikate verwendet. Für detaillierte Beispiele beider Methoden siehe [**diesen Leitfaden**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
Zur Bestätigung der Identität eines Servers werden Zertifikate verwendet. Für detaillierte Beispiele beider Methoden siehe [**diese Anleitung**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
|
||||
### Sicherheit von Container-Images
|
||||
|
||||
|
|
@ -52,15 +52,15 @@ Container-Images können in privaten oder öffentlichen Repositories gespeichert
|
|||
* [**Docker Registry**](https://github.com/docker/distribution): Ein Open-Source-Projekt, das Benutzern ermöglicht, ihr eigenes Register zu hosten.
|
||||
* [**Docker Trusted Registry**](https://www.docker.com/docker-trusted-registry): Das kommerzielle Registrierungsangebot von Docker mit rollenbasierter Benutzerauthentifizierung und Integration mit LDAP-Verzeichnisdiensten.
|
||||
|
||||
### Bildscannen
|
||||
### Bildanalyse
|
||||
|
||||
Container können **Sicherheitslücken** aufweisen, entweder aufgrund des Basisimages oder der auf dem Basisimage installierten Software. Docker arbeitet an einem Projekt namens **Nautilus**, das Sicherheitsscans von Containern durchführt und die Sicherheitslücken auflistet. Nautilus funktioniert, indem es jedes Container-Image-Layer mit dem Sicherheitslücken-Repository vergleicht, um Sicherheitslücken zu identifizieren.
|
||||
Container können **Sicherheitslücken** aufweisen, entweder aufgrund des Basisimages oder der darauf installierten Software. Docker arbeitet an einem Projekt namens **Nautilus**, das Sicherheitsscans von Containern durchführt und die Sicherheitslücken auflistet. Nautilus funktioniert, indem es jedes Container-Image-Layer mit dem Schwachstellen-Repository vergleicht, um Sicherheitslücken zu identifizieren.
|
||||
|
||||
Für weitere [**Informationen lesen Sie dies**](https://docs.docker.com/engine/scan/).
|
||||
|
||||
* **`docker scan`**
|
||||
|
||||
Der Befehl **`docker scan`** ermöglicht es Ihnen, vorhandene Docker-Images mithilfe des Bildnamens oder der ID zu scannen. Führen Sie beispielsweise den folgenden Befehl aus, um das Bild hello-world zu scannen:
|
||||
Der Befehl **`docker scan`** ermöglicht es Ihnen, vorhandene Docker-Images mithilfe des Bildnamens oder der ID zu scannen. Führen Sie beispielsweise den folgenden Befehl aus, um das Image hello-world zu scannen:
|
||||
```bash
|
||||
docker scan hello-world
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ Note that we do not currently have vulnerability data for your image.
|
|||
```
|
||||
* [**`trivy`**](https://github.com/aquasecurity/trivy)
|
||||
```bash
|
||||
trivy -q -f json <ontainer_name>:<tag>
|
||||
trivy -q -f json <container_name>:<tag>
|
||||
```
|
||||
* [**`snyk`**](https://docs.snyk.io/snyk-cli/getting-started-with-the-cli)
|
||||
```bash
|
||||
|
|
@ -93,9 +93,9 @@ clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5
|
|||
Die Signierung von Docker-Images gewährleistet die Sicherheit und Integrität von Images, die in Containern verwendet werden. Hier ist eine zusammengefasste Erklärung:
|
||||
|
||||
- **Docker Content Trust** nutzt das Notary-Projekt, basierend auf dem The Update Framework (TUF), zur Verwaltung der Image-Signierung. Weitere Informationen finden Sie unter [Notary](https://github.com/docker/notary) und [TUF](https://theupdateframework.github.io).
|
||||
- Um Docker Content Trust zu aktivieren, setzen Sie `export DOCKER_CONTENT_TRUST=1`. Diese Funktion ist standardmäßig in Docker Version 1.10 und höher deaktiviert.
|
||||
- Um Docker Content Trust zu aktivieren, setzen Sie `export DOCKER_CONTENT_TRUST=1`. Diese Funktion ist in Docker Version 1.10 und später standardmäßig deaktiviert.
|
||||
- Mit dieser Funktion können nur signierte Images heruntergeladen werden. Das Initiieren des ersten Image-Push erfordert das Festlegen von Passphrasen für die Root- und Tagging-Schlüssel, wobei Docker auch Yubikey zur Verbesserung der Sicherheit unterstützt. Weitere Details finden Sie [hier](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
|
||||
- Der Versuch, ein nicht signiertes Image mit aktiviertem Content Trust herunterzuladen, führt zu einem "Keine Vertrauensdaten für latest" Fehler.
|
||||
- Der Versuch, ein nicht signiertes Image mit aktiviertem Content Trust herunterzuladen, führt zu einem Fehler "Keine Vertrauensdaten für latest".
|
||||
- Für Image-Pushes nach dem ersten fordert Docker die Passphrase des Repository-Schlüssels an, um das Image zu signieren.
|
||||
|
||||
Um Ihre privaten Schlüssel zu sichern, verwenden Sie den Befehl:
|
||||
|
|
@ -110,12 +110,12 @@ Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,ca
|
|||
|
||||
**Seccomp**
|
||||
|
||||
Es ist standardmäßig in Docker aktiviert. Es hilft, die Syscalls, die der Prozess aufrufen kann, noch weiter zu **beschränken**.\
|
||||
Es ist standardmäßig in Docker aktiviert. Es hilft, die Syscalls weiter zu **beschränken**, die der Prozess aufrufen kann.\
|
||||
Das **Standard-Docker-Seccomp-Profil** finden Sie unter [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
|
||||
|
||||
**AppArmor**
|
||||
|
||||
Docker hat eine Vorlage, die Sie aktivieren können: [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
|
||||
Docker verfügt über eine Vorlage, die Sie aktivieren können: [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
|
||||
|
||||
Dies ermöglicht die Reduzierung von Fähigkeiten, Syscalls, Zugriff auf Dateien und Ordner...
|
||||
|
||||
|
|
@ -123,7 +123,7 @@ Dies ermöglicht die Reduzierung von Fähigkeiten, Syscalls, Zugriff auf Dateien
|
|||
|
||||
### Namespaces
|
||||
|
||||
**Namespaces** sind ein Feature des Linux-Kernels, das **Kernelressourcen partitioniert**, sodass eine Gruppe von **Prozessen** einen Satz von **Ressourcen sieht**, während eine **andere** Gruppe von **Prozessen** einen **anderen** Satz von Ressourcen sieht. Das Feature funktioniert, indem für einen Satz von Ressourcen und Prozessen der gleiche Namespace vorhanden ist, aber diese Namespaces beziehen sich auf unterschiedliche Ressourcen. Ressourcen können in mehreren Bereichen existieren.
|
||||
**Namespaces** sind eine Funktion des Linux-Kernels, die **Kernelressourcen partitioniert**, sodass eine Gruppe von **Prozessen** einen Satz von **Ressourcen sieht**, während eine **andere** Gruppe von **Prozessen** einen **anderen** Satz von Ressourcen sieht. Die Funktion funktioniert, indem für einen Satz von Ressourcen und Prozessen dasselbe Namespace vorhanden ist, aber diese Namespaces beziehen sich auf unterschiedliche Ressourcen. Ressourcen können in mehreren Bereichen existieren.
|
||||
|
||||
Docker verwendet die folgenden Linux-Kernel-Namespaces, um die Isolierung von Containern zu erreichen:
|
||||
|
||||
|
|
@ -141,8 +141,8 @@ Für **weitere Informationen zu den Namespaces** besuchen Sie die folgende Seite
|
|||
|
||||
### cgroups
|
||||
|
||||
Das Linux-Kernel-Feature **cgroups** bietet die Möglichkeit, Ressourcen wie CPU, Speicher, IO, Netzwerkbandbreite unter einer Gruppe von Prozessen zu **beschränken**. Docker ermöglicht die Erstellung von Containern unter Verwendung des cgroup-Features, das eine Ressourcensteuerung für den spezifischen Container ermöglicht.\
|
||||
Im Folgenden wird ein Container erstellt, dessen Benutzerspeicher auf 500 MB begrenzt ist, der Kernelspeicher auf 50 MB begrenzt ist, die CPU-Anteile auf 512, die Blkioweight auf 400. Der CPU-Anteil ist ein Verhältnis, das die CPU-Nutzung des Containers steuert. Er hat einen Standardwert von 1024 und einen Bereich zwischen 0 und 1024. Wenn drei Container den gleichen CPU-Anteil von 1024 haben, kann jeder Container bei CPU-Ressourcenkonflikten bis zu 33 % der CPU nutzen. blkio-weight ist ein Verhältnis, das die IO des Containers steuert. Es hat einen Standardwert von 500 und einen Bereich zwischen 10 und 1000.
|
||||
Das Linux-Kernel-Feature **cgroups** bietet die Möglichkeit, Ressourcen wie CPU, Speicher, IO, Netzwerkbandbreite unter einer Gruppe von Prozessen zu **beschränken**. Docker ermöglicht die Erstellung von Containern unter Verwendung der cgroup-Funktion, die eine Ressourcensteuerung für den spezifischen Container ermöglicht.\
|
||||
Im Folgenden wird ein Container erstellt, dessen Benutzerspeicher auf 500m begrenzt ist, der Kernelspeicher auf 50m begrenzt ist, der CPU-Anteil auf 512, und das Blkioweight auf 400. Der CPU-Anteil ist ein Verhältnis, das die CPU-Nutzung des Containers steuert. Er hat einen Standardwert von 1024 und einen Bereich zwischen 0 und 1024. Wenn drei Container den gleichen CPU-Anteil von 1024 haben, kann jeder Container bis zu 33 % der CPU bei CPU-Ressourcenkonflikten nutzen. blkio-weight ist ein Verhältnis, das die IO des Containers steuert. Er hat einen Standardwert von 500 und einen Bereich zwischen 10 und 1000.
|
||||
```
|
||||
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
|
||||
```
|
||||
|
|
@ -160,7 +160,7 @@ Für weitere Informationen siehe:
|
|||
|
||||
### Berechtigungen
|
||||
|
||||
Berechtigungen ermöglichen eine genauere Kontrolle über die Berechtigungen, die für den Root-Benutzer zugelassen werden können. Docker verwendet das Linux-Kernel-Berechtigungsmerkmal, um die Operationen zu begrenzen, die innerhalb eines Containers durchgeführt werden können, unabhängig vom Benutzertyp.
|
||||
Berechtigungen ermöglichen eine genauere Kontrolle über die Berechtigungen, die für den Root-Benutzer zugelassen werden können. Docker verwendet das Linux-Kernel-Berechtigungsmerkmal, um die Operationen zu beschränken, die innerhalb eines Containers durchgeführt werden können, unabhängig vom Benutzertyp.
|
||||
|
||||
Wenn ein Docker-Container ausgeführt wird, verwirft der Prozess sensible Berechtigungen, die der Prozess verwenden könnte, um aus der Isolation auszubrechen. Dies soll sicherstellen, dass der Prozess keine sensiblen Aktionen ausführen und ausbrechen kann:
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ Wenn ein Docker-Container ausgeführt wird, verwirft der Prozess sensible Berech
|
|||
|
||||
### Seccomp in Docker
|
||||
|
||||
Dies ist eine Sicherheitsfunktion, die es Docker ermöglicht, die Syscalls zu begrenzen, die innerhalb des Containers verwendet werden können:
|
||||
Dies ist eine Sicherheitsfunktion, die Docker ermöglicht, die Systemaufrufe zu beschränken, die innerhalb des Containers verwendet werden können:
|
||||
|
||||
{% content-ref url="seccomp.md" %}
|
||||
[seccomp.md](seccomp.md)
|
||||
|
|
@ -186,11 +186,11 @@ AppArmor ist eine Kernel-Erweiterung, um Container auf eine begrenzte Menge von
|
|||
|
||||
### SELinux in Docker
|
||||
|
||||
* **Beschriftungssystem**: SELinux weist jedem Prozess und jedem Dateisystemobjekt ein eindeutiges Label zu.
|
||||
* **Richtliniendurchsetzung**: Es setzt Sicherheitsrichtlinien durch, die definieren, welche Aktionen ein Prozesslabel auf andere Labels im System ausführen kann.
|
||||
* **Container-Prozesslabels**: Wenn Container-Engines Containerprozesse initiieren, wird ihnen in der Regel ein eingeschränktes SELinux-Label zugewiesen, üblicherweise `container_t`.
|
||||
* **Dateibeschriftung innerhalb von Containern**: Dateien innerhalb des Containers sind normalerweise als `container_file_t` gekennzeichnet.
|
||||
* **Richtlinienregeln**: Die SELinux-Richtlinie stellt hauptsächlich sicher, dass Prozesse mit dem Label `container_t` nur mit Dateien interagieren (lesen, schreiben, ausführen) können, die als `container_file_t` gekennzeichnet sind.
|
||||
- **Beschriftungssystem**: SELinux weist jedem Prozess und jedem Dateisystemobjekt ein eindeutiges Label zu.
|
||||
- **Richtliniendurchsetzung**: Es setzt Sicherheitsrichtlinien durch, die definieren, welche Aktionen ein Prozesslabel auf anderen Labels im System ausführen kann.
|
||||
- **Container-Prozess-Labels**: Wenn Container-Engines Containerprozesse initiieren, werden ihnen in der Regel eingeschränkte SELinux-Labels zugewiesen, üblicherweise `container_t`.
|
||||
- **Dateibeschriftung innerhalb von Containern**: Dateien innerhalb des Containers sind normalerweise als `container_file_t` gekennzeichnet.
|
||||
- **Richtlinienregeln**: Die SELinux-Richtlinie stellt hauptsächlich sicher, dass Prozesse mit dem Label `container_t` nur mit Dateien interagieren können (lesen, schreiben, ausführen), die als `container_file_t` gekennzeichnet sind.
|
||||
|
||||
Dieser Mechanismus stellt sicher, dass selbst wenn ein Prozess innerhalb eines Containers kompromittiert ist, er nur mit Objekten interagieren kann, die über die entsprechenden Labels verfügen, was das potenzielle Schadensausmaß solcher Kompromittierungen erheblich einschränkt.
|
||||
|
||||
|
|
@ -200,10 +200,10 @@ Dieser Mechanismus stellt sicher, dass selbst wenn ein Prozess innerhalb eines C
|
|||
|
||||
### AuthZ & AuthN
|
||||
|
||||
In Docker spielt ein Autorisierungsplugin eine entscheidende Rolle für die Sicherheit, indem es entscheidet, ob Anfragen an den Docker-Dämon zugelassen oder blockiert werden sollen. Diese Entscheidung wird durch die Prüfung von zwei Schlüsselkontexten getroffen:
|
||||
In Docker spielt ein Autorisierungsplugin eine entscheidende Rolle für die Sicherheit, indem es entscheidet, ob Anfragen an den Docker-Daemon zugelassen oder blockiert werden sollen. Diese Entscheidung wird durch die Prüfung von zwei Schlüsselkontexten getroffen:
|
||||
|
||||
* **Authentifizierungskontext**: Dies umfasst umfassende Informationen über den Benutzer, wie wer sie sind und wie sie sich authentifiziert haben.
|
||||
* **Befehlskontext**: Dies umfasst alle relevanten Daten, die mit der gestellten Anfrage zusammenhängen.
|
||||
- **Authentifizierungskontext**: Dies umfasst umfassende Informationen über den Benutzer, wie wer sie sind und wie sie sich authentifiziert haben.
|
||||
- **Befehlskontext**: Dies umfasst alle relevanten Daten, die mit der gestellten Anfrage zusammenhängen.
|
||||
|
||||
Diese Kontexte helfen sicherzustellen, dass nur legitime Anfragen von authentifizierten Benutzern verarbeitet werden, was die Sicherheit der Docker-Operationen erhöht.
|
||||
|
||||
|
|
@ -213,9 +213,9 @@ Diese Kontexte helfen sicherzustellen, dass nur legitime Anfragen von authentifi
|
|||
|
||||
## DoS aus einem Container
|
||||
|
||||
Wenn Sie die Ressourcen, die ein Container verwenden kann, nicht ordnungsgemäß begrenzen, könnte ein kompromittierter Container den Host, auf dem er läuft, DoS-angreifen.
|
||||
Wenn Sie die Ressourcen, die ein Container verwenden kann, nicht ordnungsgemäß begrenzen, könnte ein kompromittierter Container den Host, auf dem er ausgeführt wird, DoS-angreifen.
|
||||
|
||||
* CPU-DoS
|
||||
- CPU-DoS
|
||||
```bash
|
||||
# stress-ng
|
||||
sudo apt-get install -y stress-ng && stress-ng --vm 1 --vm-bytes 1G --verify -t 5m
|
||||
|
|
@ -241,9 +241,9 @@ Auf der folgenden Seite können Sie lernen, **was das `--privileged`-Flag bedeut
|
|||
|
||||
#### no-new-privileges
|
||||
|
||||
Wenn Sie einen Container ausführen, in dem ein Angreifer Zugriff als Benutzer mit niedrigen Berechtigungen erhält. Wenn Sie eine **falsch konfigurierte SUID-Binärdatei** haben, kann der Angreifer sie missbrauchen und **Berechtigungen innerhalb** des Containers **eskaliert**, was es ihm ermöglichen könnte, daraus zu entkommen.
|
||||
Wenn Sie einen Container ausführen, in dem ein Angreifer Zugriff als Benutzer mit niedrigen Rechten erhält. Wenn Sie eine **falsch konfigurierte SUID-Binärdatei** haben, könnte der Angreifer sie missbrauchen und **Berechtigungen innerhalb** des Containers **eskaliert**, was es ihm ermöglichen könnte, daraus zu entkommen.
|
||||
|
||||
Das Ausführen des Containers mit der Option **`no-new-privileges`** aktiviert verhindert diese Art von Berechtigungserweiterung.
|
||||
Das Ausführen des Containers mit der Option **`no-new-privileges`** aktiviert wird **diese Art von Berechtigungserweiterung verhindern**.
|
||||
```
|
||||
docker run -it --security-opt=no-new-privileges:true nonewpriv
|
||||
```
|
||||
|
|
@ -272,11 +272,11 @@ Es ist entscheidend, Geheimnisse nicht direkt in Docker-Images einzubetten oder
|
|||
|
||||
**Docker-Volumes** sind eine sicherere Alternative, die empfohlen wird, um auf sensible Informationen zuzugreifen. Sie können als temporäres Dateisystem im Speicher genutzt werden, um die Risiken im Zusammenhang mit `docker inspect` und Logging zu mindern. Allerdings können Root-Benutzer und solche mit `exec`-Zugriff auf den Container immer noch auf die Geheimnisse zugreifen.
|
||||
|
||||
**Docker-Secrets** bieten eine noch sicherere Methode zur Handhabung sensibler Informationen. Für Fälle, in denen während der Image-Build-Phase Geheimnisse benötigt werden, bietet **BuildKit** eine effiziente Lösung mit Unterstützung für Build-Zeit-Geheimnisse, die die Build-Geschwindigkeit verbessern und zusätzliche Funktionen bereitstellen.
|
||||
**Docker-Secrets** bieten eine noch sicherere Methode zur Handhabung sensibler Informationen. Für Fälle, in denen während der Image-Build-Phase Geheimnisse erforderlich sind, bietet **BuildKit** eine effiziente Lösung mit Unterstützung für Build-Zeit-Geheimnisse, die die Build-Geschwindigkeit verbessern und zusätzliche Funktionen bereitstellen.
|
||||
|
||||
Um BuildKit zu nutzen, kann es auf drei Arten aktiviert werden:
|
||||
|
||||
1. Durch eine Umgebungsvariable: `export DOCKER_BUILDKIT=1`
|
||||
1. Über eine Umgebungsvariable: `export DOCKER_BUILDKIT=1`
|
||||
2. Durch Voranstellen von Befehlen: `DOCKER_BUILDKIT=1 docker build .`
|
||||
3. Durch die Aktivierung als Standard in der Docker-Konfiguration: `{ "features": { "buildkit": true } }`, gefolgt von einem Neustart von Docker.
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ BuildKit ermöglicht die Verwendung von Build-Zeit-Geheimnissen mit der `--secre
|
|||
```bash
|
||||
docker build --secret my_key=my_value ,src=path/to/my_secret_file .
|
||||
```
|
||||
Für benötigte Geheimnisse in einem laufenden Container bieten **Docker Compose und Kubernetes** robuste Lösungen. Docker Compose verwendet einen `secrets`-Schlüssel in der Service-Definition zur Spezifizierung von Geheimdateien, wie im folgenden Beispiel einer `docker-compose.yml` gezeigt:
|
||||
Für benötigte Geheimnisse in einem laufenden Container bieten **Docker Compose und Kubernetes** robuste Lösungen. Docker Compose verwendet einen `secrets`-Schlüssel in der Service-Definition zur Angabe von Geheimdateien, wie im Beispiel einer `docker-compose.yml` gezeigt:
|
||||
```yaml
|
||||
version: "3.7"
|
||||
services:
|
||||
|
|
@ -303,7 +303,7 @@ In Kubernetes-Umgebungen werden Secrets nativ unterstützt und können mit Tools
|
|||
|
||||
### gVisor
|
||||
|
||||
**gVisor** ist ein Anwendungskernel, der in Go geschrieben ist und einen erheblichen Teil der Linux-Systemoberfläche implementiert. Es enthält einen [Open Container Initiative (OCI)](https://www.opencontainers.org)-Laufzeitumgebung namens `runsc`, die eine **Isolierungsgrenze zwischen der Anwendung und dem Host-Kernel** bereitstellt. Die `runsc`-Laufzeitumgebung integriert sich mit Docker und Kubernetes und ermöglicht es, Sandbox-Container einfach auszuführen.
|
||||
**gVisor** ist ein Anwendungskernel, der in Go geschrieben ist und einen erheblichen Teil der Linux-Systemoberfläche implementiert. Es enthält einen [Open Container Initiative (OCI)](https://www.opencontainers.org)-Laufzeitnamens `runsc`, der eine **Isolierungsgrenze zwischen der Anwendung und dem Host-Kernel** bereitstellt. Die `runsc`-Laufzeit integriert sich mit Docker und Kubernetes und macht es einfach, Sandbox-Container auszuführen.
|
||||
|
||||
{% embed url="https://github.com/google/gvisor" %}
|
||||
|
||||
|
|
@ -315,19 +315,19 @@ In Kubernetes-Umgebungen werden Secrets nativ unterstützt und können mit Tools
|
|||
|
||||
### Zusammenfassungstipps
|
||||
|
||||
* Verwenden Sie nicht das `--privileged`-Flag oder binden Sie einen **Docker-Socket innerhalb des Containers** ein. Der Docker-Socket ermöglicht das Starten von Containern und ist daher ein einfacher Weg, um die volle Kontrolle über den Host zu übernehmen, beispielsweise durch das Ausführen eines weiteren Containers mit dem `--privileged`-Flag.
|
||||
* Verwenden Sie nicht das `--privileged`-Flag oder binden Sie einen **Docker-Socket innerhalb des Containers** ein. Der Docker-Socket ermöglicht das Starten von Containern und ist daher ein einfacher Weg, um die volle Kontrolle über den Host zu übernehmen, beispielsweise durch Ausführen eines anderen Containers mit dem `--privileged`-Flag.
|
||||
* Führen Sie nicht als Root innerhalb des Containers aus. Verwenden Sie einen **anderen Benutzer** und **Benutzernamensräume**. Der Root im Container ist derselbe wie auf dem Host, es sei denn, er wird mit Benutzernamensräumen neu zugeordnet. Er wird nur leicht durch Linux-Namespaces, Fähigkeiten und cgroups eingeschränkt.
|
||||
* **Verwerfen Sie alle Fähigkeiten** (`--cap-drop=all`) und aktivieren Sie nur diejenigen, die erforderlich sind (`--cap-add=...`). Viele Workloads benötigen keine Fähigkeiten, und das Hinzufügen erhöht den Umfang eines potenziellen Angriffs.
|
||||
* **Verwerfen Sie alle Fähigkeiten** (`--cap-drop=all`) und aktivieren Sie nur die erforderlichen (`--cap-add=...`). Viele Workloads benötigen keine Fähigkeiten, und das Hinzufügen erhöht den Umfang eines potenziellen Angriffs.
|
||||
* Verwenden Sie die Sicherheitsoption **"no-new-privileges"**, um zu verhindern, dass Prozesse mehr Berechtigungen erlangen, beispielsweise durch suid-Binärdateien.
|
||||
* **Begrenzen Sie die Ressourcen, die dem Container zur Verfügung stehen**. Ressourcenbeschränkungen können die Maschine vor Denial-of-Service-Angriffen schützen.
|
||||
* Passen Sie **Seccomp**, **AppArmor** (oder SELinux)-Profile an, um die Aktionen und Systemaufrufe, die für den Container verfügbar sind, auf das erforderliche Minimum zu beschränken.
|
||||
* Passen Sie **seccomp**, **AppArmor** (oder SELinux)-Profile an, um die Aktionen und Systemaufrufe, die für den Container verfügbar sind, auf das erforderliche Minimum zu beschränken.
|
||||
* Verwenden Sie **offizielle Docker-Images** und verlangen Sie Signaturen oder erstellen Sie eigene Images basierend darauf. Vererben oder verwenden Sie keine mit Hintertüren versehenen Images. Speichern Sie auch Root-Schlüssel und Passphrasen an einem sicheren Ort. Docker plant, Schlüssel mit UCP zu verwalten.
|
||||
* **Erstellen Sie regelmäßig** Ihre Images neu, um Sicherheitspatches auf dem Host und den Images anzuwenden.
|
||||
* Verwalten Sie Ihre **Secrets klug**, damit es für den Angreifer schwierig ist, darauf zuzugreifen.
|
||||
* Wenn Sie den Docker-Daemon freigeben, verwenden Sie HTTPS mit Client- und Serverauthentifizierung.
|
||||
* Verwenden Sie in Ihrem Dockerfile **COPY anstelle von ADD**. ADD extrahiert automatisch komprimierte Dateien und kann Dateien von URLs kopieren. COPY hat diese Fähigkeiten nicht. Vermeiden Sie nach Möglichkeit die Verwendung von ADD, um nicht anfällig für Angriffe über Remote-URLs und Zip-Dateien zu sein.
|
||||
* Verwenden Sie in Ihrem Dockerfile **COPY anstelle von ADD**. ADD extrahiert automatisch komprimierte Dateien und kann Dateien von URLs kopieren. COPY verfügt nicht über diese Funktionen. Vermeiden Sie nach Möglichkeit die Verwendung von ADD, um nicht anfällig für Angriffe über Remote-URLs und Zip-Dateien zu sein.
|
||||
* Verwenden Sie **getrennte Container für jeden Mikrodienst**.
|
||||
* **Fügen Sie kein SSH** in den Container ein, "docker exec" kann verwendet werden, um eine SSH-Verbindung zum Container herzustellen.
|
||||
* **Fügen Sie kein ssh** in den Container ein, "docker exec" kann verwendet werden, um eine Verbindung zum Container herzustellen.
|
||||
* Verwenden Sie **kleinere** Container-Images
|
||||
|
||||
## Docker Ausbruch / Privilege Escalation
|
||||
|
|
@ -349,7 +349,7 @@ Wenn Sie Zugriff auf den Docker-Socket haben oder Zugriff auf einen Benutzer in
|
|||
## Absicherung von Docker
|
||||
|
||||
* Das Tool [**docker-bench-security**](https://github.com/docker/docker-bench-security) ist ein Skript, das Dutzende gängiger Best Practices für das Bereitstellen von Docker-Containern in der Produktion überprüft. Die Tests sind alle automatisiert und basieren auf dem [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
|
||||
Sie müssen das Tool auf dem Host ausführen, auf dem Docker ausgeführt wird, oder in einem Container mit ausreichenden Berechtigungen. Erfahren Sie, **wie Sie es in der README ausführen können:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
|
||||
Sie müssen das Tool auf dem Host ausführen, der Docker ausführt, oder in einem Container mit ausreichenden Berechtigungen. Erfahren Sie, **wie Sie es in der README ausführen:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
|
@ -370,7 +370,7 @@ Sie müssen das Tool auf dem Host ausführen, auf dem Docker ausgeführt wird, o
|
|||
<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos Workflows zu erstellen und zu automatisieren, die von den weltweit **fortschrittlichsten Community-Tools** unterstützt werden.\
|
||||
Verwenden Sie [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), um mühelos Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.\
|
||||
Erhalten Sie noch heute Zugriff:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
|
@ -384,4 +384,4 @@ Andere Möglichkeiten, HackTricks zu unterstützen:
|
|||
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
|
||||
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
|
||||
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.
|
||||
|
|
|
|||
Loading…
Reference in a new issue