Docker Security
PreviousD-Bus Enumeration & Command Injection Privilege EscalationNextAbusing Docker Socket for Privilege Escalation
Last updated
Impara e pratica l'Hacking di AWS: HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking di GCP: HackTricks Training GCP Red Team Expert (GRTE)
Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:
Il motore Docker utilizza i Namespaces e Cgroups del kernel Linux per isolare i container, offrendo uno strato di sicurezza di base. Una protezione aggiuntiva è fornita tramite il dropping delle Capabilities, Seccomp, e SELinux/AppArmor, migliorando l'isolamento del container. Un plugin di autenticazione può limitare ulteriormente le azioni dell'utente.
Il motore Docker può essere accesso localmente tramite un socket Unix o remotamente utilizzando HTTP. Per l'accesso remoto, è essenziale utilizzare HTTPS e TLS per garantire riservatezza, integrità e autenticazione.
Il motore Docker, per impostazione predefinita, è in ascolto sul socket Unix a unix:///var/run/docker.sock. Nei sistemi Ubuntu, le opzioni di avvio di Docker sono definite in /etc/default/docker. Per abilitare l'accesso remoto all'API e al client Docker, esponi il demone Docker su un socket HTTP aggiungendo le seguenti impostazioni:
Tuttavia, esporre il demone Docker su HTTP non è consigliato a causa di preoccupazioni per la sicurezza. È consigliabile proteggere le connessioni utilizzando HTTPS. Ci sono due approcci principali per garantire la connessione:
Il client verifica l'identità del server.
Sia il client che il server si autenticano reciprocamente.
I certificati vengono utilizzati per confermare l'identità di un server. Per esempi dettagliati di entrambi i metodi, fare riferimento a questa guida.
Le immagini dei container possono essere memorizzate in repository privati o pubblici. Docker offre diverse opzioni di archiviazione per le immagini dei container:
Docker Hub: Un servizio di registro pubblico da Docker.
Docker Registry: Un progetto open-source che consente agli utenti di ospitare il proprio registro.
Docker Trusted Registry: Offerta commerciale di Docker, con autenticazione degli utenti basata sui ruoli e integrazione con servizi di directory LDAP.
I container possono presentare vulnerabilità di sicurezza a causa dell'immagine di base o del software installato sopra l'immagine di base. Docker sta lavorando a un progetto chiamato Nautilus che esegue la scansione di sicurezza dei container e elenca le vulnerabilità. Nautilus funziona confrontando ciascuno strato dell'immagine del container con il repository delle vulnerabilità per identificare falle di sicurezza.
Per ulteriori informazioni leggi questo.
docker scan
Il comando docker scan consente di eseguire la scansione delle immagini Docker esistenti utilizzando il nome o l'ID dell'immagine. Ad esempio, eseguire il seguente comando per eseguire la scansione dell'immagine hello-world:
La firma delle immagini Docker garantisce la sicurezza e l'integrità delle immagini utilizzate nei contenitori. Ecco una spiegazione sintetica:
Per attivare la fiducia nei contenuti di Docker, imposta export DOCKER_CONTENT_TRUST=1. Questa funzionalità è disattivata per impostazione predefinita nelle versioni di Docker dalla 1.10 in poi.
Con questa funzionalità abilitata, è possibile scaricare solo immagini firmate. Il push iniziale dell'immagine richiede di impostare passphrase per le chiavi di root e di tag, con Docker che supporta anche Yubikey per una sicurezza potenziata. Ulteriori dettagli possono essere trovati qui.
Tentare di scaricare un'immagine non firmata con la fiducia nei contenuti abilitata porta a un errore "Nessun dato di fiducia per l'ultima versione".
Per i push delle immagini successivi al primo, Docker richiede la passphrase della chiave del repository per firmare l'immagine.
Per eseguire il backup delle tue chiavi private, utilizza il comando:
Quando si passa da un host Docker all'altro, è necessario spostare le chiavi di root e del repository per mantenere le operazioni.
Usa Trickest per creare e automatizzare facilmente flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:
Namespaces sono una caratteristica del kernel Linux che partiziona le risorse del kernel in modo che un insieme di processi veda un insieme di risorse mentre un altro insieme di processi vede un diverso insieme di risorse. La funzionalità funziona avendo lo stesso namespace per un insieme di risorse e processi, ma quei namespace si riferiscono a risorse distinte. Le risorse possono esistere in più spazi.
Docker fa uso dei seguenti Namespaces del kernel Linux per ottenere l'isolamento dei Container:
namespace pid
namespace mount
namespace network
namespace ipc
namespace UTS
Per ulteriori informazioni sui namespaces controlla la seguente pagina:
NamespacesLa funzionalità del kernel Linux cgroups fornisce la capacità di limitare risorse come cpu, memoria, io, larghezza di banda di rete tra un insieme di processi. Docker consente di creare Container utilizzando la funzionalità cgroup che consente il controllo delle risorse per il Container specifico. Di seguito è riportato un Container creato con la memoria dello spazio utente limitata a 500m, la memoria del kernel limitata a 50m, la quota cpu a 512, il peso blkioweight a 400. La quota cpu è un rapporto che controlla l'utilizzo della CPU del Container. Ha un valore predefinito di 1024 e un intervallo tra 0 e 1024. Se tre Container hanno la stessa quota cpu di 1024, ogni Container può utilizzare fino al 33% della CPU in caso di contesa delle risorse della CPU. blkio-weight è un rapporto che controlla l'IO del Container. Ha un valore predefinito di 500 e un intervallo tra 10 e 1000.
Per ottenere il cgroup di un container puoi fare:
Per ulteriori informazioni controlla:
CGroupsLe capacità consentono un controllo più preciso delle capacità che possono essere consentite per l'utente root. Docker utilizza la funzionalità di capacità del kernel Linux per limitare le operazioni che possono essere eseguite all'interno di un contenitore indipendentemente dal tipo di utente.
Quando viene eseguito un contenitore Docker, il processo elimina le capacità sensibili che il processo potrebbe utilizzare per sfuggire all'isolamento. Questo tenta di garantire che il processo non sarà in grado di eseguire azioni sensibili e di sfuggire:
Linux CapabilitiesSi tratta di una funzionalità di sicurezza che consente a Docker di limitare le chiamate di sistema che possono essere utilizzate all'interno del contenitore:
SeccompAppArmor è un potenziamento del kernel per confinare i contenitori a un insieme limitato di risorse con profili per programma:
AppArmorSistema di etichettatura: SELinux assegna un'etichetta univoca a ogni processo e oggetto del filesystem.
Esecuzione delle policy: Applica le policy di sicurezza che definiscono quali azioni può compiere un'etichetta di processo su altre etichette all'interno del sistema.
Etichette dei processi del contenitore: Quando i motori dei contenitori avviano i processi del contenitore, vengono tipicamente assegnate loro un'etichetta SELinux confinata, comunemente container_t.
Etichettatura dei file all'interno dei contenitori: I file all'interno del contenitore sono di solito etichettati come container_file_t.
Regole di policy: La policy SELinux garantisce principalmente che i processi con l'etichetta container_t possano interagire (leggere, scrivere, eseguire) solo con file etichettati come container_file_t.
Questo meccanismo garantisce che anche se un processo all'interno di un contenitore viene compromesso, è confinato nell'interagire solo con oggetti che hanno le etichette corrispondenti, limitando significativamente i danni potenziali da tali compromissioni.
SELinuxIn Docker, un plugin di autorizzazione svolge un ruolo cruciale nella sicurezza decidendo se consentire o bloccare le richieste al demone Docker. Questa decisione viene presa esaminando due contesti chiave:
Contesto di autenticazione: Questo include informazioni dettagliate sull'utente, come chi sono e come si sono autenticati.
Contesto del comando: Questo comprende tutti i dati pertinenti relativi alla richiesta in corso.
Questi contesti contribuiscono a garantire che solo le richieste legittime da utenti autenticati vengano elaborate, migliorando la sicurezza delle operazioni di Docker.
AuthZ& AuthN - Docker Access Authorization PluginSe non si limitano correttamente le risorse che un contenitore può utilizzare, un contenitore compromesso potrebbe causare un DoS all'host in cui è in esecuzione.
DoS della CPU
Denial of Service della larghezza di banda
Nella seguente pagina puoi apprendere cosa implica il flag --privileged:
Se stai eseguendo un container in cui un attaccante riesce ad ottenere accesso come utente a basso privilegio. Se hai un binario suid mal configurato, l'attaccante potrebbe abusarne e escalare i privilegi all'interno del container. Ciò potrebbe consentirgli di evaderne.
Eseguire il container con l'opzione no-new-privileges abilitata impedirà questo tipo di escalation dei privilegi.
Per ulteriori opzioni --security-opt controlla: https://docs.docker.com/engine/reference/run/#security-configuration
È cruciale evitare di incorporare le password direttamente nelle immagini Docker o di utilizzare variabili d'ambiente, poiché questi metodi espongono le informazioni sensibili a chiunque abbia accesso al container tramite comandi come docker inspect o exec.
I volumi Docker sono un'alternativa più sicura, consigliata per accedere alle informazioni sensibili. Possono essere utilizzati come filesystem temporaneo in memoria, mitigando i rischi associati a docker inspect e al logging. Tuttavia, gli utenti root e coloro con accesso exec al container potrebbero comunque accedere alle password.
Le password Docker offrono un metodo ancora più sicuro per gestire le informazioni sensibili. Per le istanze che richiedono password durante la fase di build dell'immagine, BuildKit presenta una soluzione efficiente con il supporto per le password in fase di build, migliorando la velocità di build e fornendo funzionalità aggiuntive.
Per sfruttare BuildKit, può essere attivato in tre modi:
Attraverso una variabile d'ambiente: export DOCKER_BUILDKIT=1
Prefissando i comandi: DOCKER_BUILDKIT=1 docker build .
Abilitandolo per impostazione predefinita nella configurazione di Docker: { "features": { "buildkit": true } }, seguito da un riavvio di Docker.
BuildKit consente l'uso di password in fase di build con l'opzione --secret, garantendo che queste password non siano incluse nella cache di build dell'immagine o nell'immagine finale, utilizzando un comando come:
Per i segreti necessari in un container in esecuzione, Docker Compose e Kubernetes offrono soluzioni robuste. Docker Compose utilizza una chiave secrets nella definizione del servizio per specificare file segreti, come mostrato in un esempio di docker-compose.yml:
Questa configurazione consente l'uso di segreti durante l'avvio dei servizi con Docker Compose.
Negli ambienti Kubernetes, i segreti sono supportati nativamente e possono essere ulteriormente gestiti con strumenti come Helm-Secrets. I controlli degli accessi basati sui ruoli (RBAC) di Kubernetes migliorano la sicurezza della gestione dei segreti, simile a Docker Enterprise.
gVisor è un kernel dell'applicazione, scritto in Go, che implementa una parte sostanziale della superficie di sistema Linux. Include un runtime Open Container Initiative (OCI) chiamato runsc che fornisce un confine di isolamento tra l'applicazione e il kernel host. Il runtime runsc si integra con Docker e Kubernetes, rendendo semplice l'esecuzione di container sandbox.
Kata Containers è una comunità open source che lavora per costruire un runtime di container sicuro con macchine virtuali leggere che si comportano e si esibiscono come container, ma forniscono un'isolamento del carico di lavoro più forte utilizzando la tecnologia di virtualizzazione hardware come secondo livello di difesa.
Non utilizzare il flag --privileged o montare un socket Docker all'interno del container. Il socket Docker consente di avviare container, quindi è un modo semplice per assumere il pieno controllo dell'host, ad esempio, eseguendo un altro container con il flag --privileged.
Non eseguire come root all'interno del container. Utilizzare un utente diverso e spazi utente. Il root nel container è lo stesso dell'host a meno che non venga rimappato con spazi utente. È solo leggermente limitato principalmente da spazi dei nomi Linux, capacità e cgroups.
Eliminare tutte le capacità (--cap-drop=all) e abilitare solo quelle necessarie (--cap-add=...). Molti carichi di lavoro non necessitano di alcuna capacità e aggiungerle aumenta la portata di un potenziale attacco.
Utilizzare l'opzione di sicurezza "no-new-privileges" per impedire ai processi di acquisire più privilegi, ad esempio attraverso binari suid.
Limitare le risorse disponibili al container. I limiti delle risorse possono proteggere la macchina da attacchi di denial of service.
Utilizzare immagini docker ufficiali e richiedere firme o creare le proprie basate su di esse. Non ereditare o utilizzare immagini backdoored. Conservare anche le chiavi di root, passphrase in un luogo sicuro. Docker ha piani per gestire le chiavi con UCP.
Ricostruire regolarmente le tue immagini per applicare patch di sicurezza all'host e alle immagini.
Gestire i segreti saggiamente in modo che sia difficile per l'attaccante accedervi.
Se esponi il demone docker usa HTTPS con autenticazione client e server.
Nel tuo Dockerfile, preferisci COPY invece di ADD. ADD estrae automaticamente file zippati e può copiare file da URL. COPY non ha queste capacità. Quando possibile, evita di utilizzare ADD per non essere suscettibile ad attacchi attraverso URL remoti e file Zip.
Avere container separati per ogni microservizio.
Non inserire ssh all'interno del container, "docker exec" può essere utilizzato per ssh al container.
Avere immagini di container più piccole
Se sei all'interno di un container Docker o hai accesso a un utente nel gruppo docker, potresti provare a fuggire ed escalare i privilegi:
Docker Breakout / Privilege EscalationSe hai accesso al socket docker o hai accesso a un utente nel gruppo docker ma le tue azioni sono limitate da un plugin di autenticazione docker, controlla se puoi bypassarlo:
AuthZ& AuthN - Docker Access Authorization PluginLo strumento docker-bench-security è uno script che controlla decine di pratiche comuni per il rilascio di container Docker in produzione. I test sono tutti automatizzati e si basano sul CIS Docker Benchmark v1.3.1. È necessario eseguire lo strumento dall'host in esecuzione di Docker o da un container con sufficienti privilegi. Scopri come eseguirlo nel README: https://github.com/docker/docker-bench-security.
Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:
Impara e pratica l'hacking su AWS: HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)
