Linux Containers e Sicurezza

Fulvio Carrus Solution Architect / Business-e S.p.A. #redhatosd

Linux Containers: Sicurezza e Scenari di Attacco

l l Containers – questi [s]conosciuti Virtualizzazione – le differenze l Sicurezza – a che punto siamo l l Attacchi – un possibile scenario Scalabilità – le soluzioni

Linux Containers: questi [s]conosciuti l Tecnologia per l’isolamento dei processi su Linux l Isolamento avviene tramite Namespacing e CGroups l Processi girano su Kernel del sistema ospitante l Docker : il motore di gestione l Docker Hub: una fonte inesauribile di Immagini SW l Una realtà in formidabile crescita

Virtualizzazione: le differenze LXC App Librerie LXC App Librerie Kernel Hardware VM App Librerie Kernel App Librerie VM Hypervisor Hardware App Librerie Kernel App Librerie

Virtualizzazione: le differenze, in sicurezza l Processi e Kernel: maggiore superficie di attacco l SELinux aiuta a proteggere sistema e altri container l Servono accorgimenti nel riuso di codice e nel patching l Servono accorgimenti nell’assegnazione di risorse l In ogni caso Containers e Virtualizzazione coesistono

Sicurezza: a che punto siamo ?

l Qual è la provenienza del Software ?

l Contiene vulnerabilità conosciute ?

l Con quali privilegi di esecuzione ?

l E se un processo viene compromesso?

Provenienza del Software : il Docker Hub l In molti sistemi Linux è il repository di default l È fonte di Software caricato da chiunque l Fin troppo semplice da utilizzare l SW non verificato, non certificato, potenzialmente vulnerabile

Provenienza del Software : come esserne certi l Implementare un proprio repository l contiene solo Software testato e validato l sottoposto a controllo accessi l Affidarsi ad un Vendor che garantisca i contenuti l Red Hat Container Registry in RHEL 7, RHEL Atomic Host

Vulnerabilità conosciute: scansione container l Strumenti che scansionano, ma non risolvono l È necessario ricostruire l’intera immagine l Tempi biblici e sforzi enormi

Vulnerabilità conosciute: come far fronte l Ridurre l’effort di rebuild con i giusti strumenti l tramite l’utilizzo dei Dockerfile l mantenimento delle Immagini a più livelli l Basarsi su immagini fornite da un Vendor l Immagini sul RH Container Registry riportano sempre gli ultimi advisory di sicurezza e bugfix

Privilegi di esecuzione: compromissione l Processi girano come root l scelta di default quando si lancia un container, se non diversamente previsto l Senza limitazioni, un processo può l esaurire le risorse dell’host l sfruttarne eventuali vulnerabilità

Privilegi di esecuzione: come far fronte l Utilizzare utenza non privilegiata l direttive RUN useradd e USER nel Dockerfile l Non disabilitare SELinux sul sistema Host l Aiuta a proteggere il Kernel e gli altri container l Stimare e limitare le risorse per il container

Attacchi: uno scenario possibile l Situazione client-server sfruttabile per Denial of Service l l Un demone contenente memory leaks Un client ”malvagio” che tenti di esaurire le risorse l Un demone containerizzato e limitato in risorse, può l Allocare RAM fino a tale limite e non oltre l Occupare solo la share di CPU assegnata l Fallire ( crashare ) ed eventualmente essere riavviato da Docker

Attacchi: uno scenario possibile – il demone

for (;;) { len_inet = sizeof adr_clnt; c = accept(s, (struct sockaddr *)&adr_clnt, &len_inet); if ( c == -1 ) bail("accept(2)"); if ( (PID = fork()) == -1 ) { /* Tentativo fork fallito */ close(c); continue; } else if ( PID > 0 ) { /* Sono il processo PADRE */ char *buffer = (char *)malloc(leakSize*sizeof(char)); memset(buffer,0,leakSize*sizeof(char)); close(c); continue; } else { /* Sono il Processo FIGLIO, che servirà il client*/ while ( fgets(buf,sizeof buf,rx) ) rpn_process(tx,buf); fclose(tx); shutdown(fileno(rx),SHUT_RDWR); fclose(rx); exit(0); }

Simulazione di Memory Leak Succube della chiusura lato client

Attacchi: uno scenario possibile – la strategia EvilClient LeakedSrv WEB (httpd) FTP (vsftpd) RHEL 7.2

Servizi nativamente attivi sul sistema LXC LeakedSrv LXC WEB (httpd) LXC FTP (vsftpd) RHEL 7.2

Servizi containerizzati e limitati

Scalabilità: quando un Host non basta l Tracciatura dei container in esecuzione l Necessaria una mappatura container:host l Variare il numero di container velocemente l Informare immediatamente il load balancer l Serve un governatore di container

Scalabilità: Kubernetes [

κυβερνήτης

] l Piattaforma di automatizzazione deploy, scaling e gestione Containers su più Nodi l Controllers: garantisce lo status e il numero di Container l Services: fornisce entrypoint, bilancia su più Containers l Sviluppato ed utilizzato da Google l Insieme a Docker, è la tecnologia alla base della PaaS Red Hat OpenShift v3

Grazie

Fulvio Carrus Solution Architect / Business-e S.p.A.

#redhatosd