Supponiamo di essere un dev e di voler rafforzare il mio ambiente applicativo web. Se la mia applicazione non utilizza binari come sh, ls, find, echo, ecc. Dovrei semplicemente rimuoverli dalla mia immagine?
Supponiamo di essere un dev e di voler rafforzare il mio ambiente applicativo web. Se la mia applicazione non utilizza binari come sh, ls, find, echo, ecc. Dovrei semplicemente rimuoverli dalla mia immagine?
Potrebbe migliorare la sicurezza, ma è un modo molto strano di fare le cose.
Quello che stai suggerendo è di iniziare con un'immagine con il software "non necessario" installato e rimuovere alcune delle cose che non ti servono (bash, echo, ...). Questo non solo rischia di rompere le cose, ma aumenta anche le dimensioni del contenitore perché il livello base con gli strumenti non necessari è ancora spedito.
Un approccio migliore è iniziare con un'immagine minima. Non alpino, è ancora un sistema operativo completo. L'approccio più minimale consiste nell'utilizzare un'immagine di base che contenga solo il runtime di lingua richiesto, come ad esempio il google link . Per i binari statici, puoi persino iniziare con un'immagine vuota.
In questo modo ottieni un'immagine il più piccola possibile e non fornisce la "superficie di attacco" di bash.
Non dovresti rimuovere bash o qualsiasi eseguibile esistente nell'immagine di base. Un sacco di file eseguibili sono interconnessi e la rimozione di un eseguibile può causare il malfunzionamento di altri eseguibili apparentemente non correlati su alcuni casi d'angolo. Invece dovresti usare un'immagine di base che non contenga nulla di cui non hai realmente bisogno. alpine crea una fantastica immagine di base minimalista, del peso di 5 MB, contiene solo gli oggetti più utili e niente di più.
Se sai che la tua applicazione non usa alcun binario esterno o shell, o se sai esattamente quale binario esterno ti servirà, potresti prendere in considerazione la possibilità di compilarlo in un binario collegato staticamente e quindi di basare il tuo contenitore del scratch immagine.
La risposta è: dipende. La rimozione di bash e tutti gli altri interpreti riduce la superficie di attacco del contenitore. Lo stesso vale per es. compilatori, nc, wget, ...
La vera domanda è: è questo il modo migliore per spendere i soldi?
per es.
Un modo migliore per spendere i soldi potrebbe essere quello di indurire l'applicazione stessa investendo in altre misure di sicurezza come regolari test di penetrazione, monitoraggio della sicurezza, patching automatico, ...
Dipende da quanto stai seguendo la filosofia Container. Se non ne hai bisogno, dovresti evitare di usare qualsiasi cosa non strettamente necessaria. Dovresti definire e fare riferimento a tutto ciò che ti serve nel Dockerfile, e il punto di accesso di un server web dovrebbe essere l'apache (o qualsiasi altro server web che stai usando) binario stesso. Ma soprattutto, tenere in considerazione che molti binari (come ls, find, ecc.) Sono collegati al livello dell'immagine di base del contenitore, quindi non lasciarli intoccati o creare un'immagine di base più personalizzata. Qualsiasi immagine di base di ubuntu, debian, ecc. Avrà questi file binari e la manomissione dell'immagine di base non è raccomandata.
Sarebbe un approccio molto più sicuro per definire una rete isolata per database, o altre entità di backend, lasciando solo la porta che stai esponendo al mondo come superficie di attacco.
Ovviamente, è fondamentale rafforzare la macchina su ciò che stai containerizzando i tuoi servizi.
Non mi preoccuperei molto a causa di questi binari. Mi preoccuperei molto di più sulla protezione dell'accesso ai comandi Docker per evitare di richiamare questi binari durante il runtime del contenitore.
Volevo aggiungere altre risorse alle risposte finora. In generale, è considerata la migliore procedura per un'immagine di un contenitore del sistema operativo che sia la più semplice possibile. Rimuovere le shell non necessarie è solo l'inizio. Esistono più immagini del sistema operativo consolidate specifiche per una distribuzione sicura dei contenitori, ma ci sono anche molte altre cose da considerare, come i privilegi più bassi possibili, i file system di sola lettura e molto altro.
Questa pagina: link ha più link a molti buoni articoli. Il blog Red Hat di Dan Walsh è anche molto buono per informazioni di livello profondo. link
Questa pagina ha molto di più che è direttamente utile a questa domanda nel senso di pratiche ancora più utile della rimozione di applicazioni non necessarie: link
E qui c'è un sistema operativo rinforzato per contenitori. Full disclosure: non l'ho ancora usato, la nostra Systems Engineering ha lavorato con il mio team di sicurezza per creare un'immagine d'oro per noi sulla nostra implementazione cloud. È più che altro un esempio: link