Sicurezza e resilienza di Architetture a Containers

Sicurezza e Resilienza di Architetture
basate su Linux Containers
Gianluca Magalotti
Business Developer / Business-e S.p.A.
#redhatosd

Agenda
 Containers: vanno ancora spiegati?
 Sicurezza: Cosa cambia, Come mi adeguo e Dove mi Fermo?
 Attacchi: un esempio pratico di resilienza

Linux Containers: vanno ancora spiegati?
I containers rappresentano un bluff, un’illusione per i
processi che ne fanno parte. Sono, però, e restano gruppi
di processi con specifici privilegi e restrizioni.

Linux Containers: Acceleratori dello sviluppo?

DevOps IoT
Microservices

Bello ma che effetto avranno sulle operations?
DevOps IoT
Microservices

E sulla Sicurezza?
DevOps IoT
Microservices

Sicurezza: Cosa Cambia?
Fonte: http://www.darkreading.com/endpoint/rethinking-application-security-with-microservices-architectures-/a/d-id/1325155

• Proliferazione Endpoints: Aumenta la superficie di attacco

• Perimetri non ben definiti e Indirizzi effimeri: tecniche consolidate (zoning,
VLAN) spesso non sono più utilizzabili

• Entropia e Mascheramento: il limite non è più il Datacenter, sorgente non
individuabile da appliances esterni

• Policies e proliferazione transazioni E-O: La semplicità nell’uso dei Containers
rende complessa la definizione di policies e la individuazione dei servizi.

• Policies e proliferazione transazioni E-O: La semplicità nell’uso dei Containers
rende complessa la definizione di policies e la individuazione dei servizi.
• Continuous Delivery & Integration: La sicurezza non è ancora «Agile»

Sicurezza: Come mi Adeguo?

• Scoprire e monitorare le comunicazioni tra servizi: Osservare o visualizzare il
traffico tra servizi, Service Discovery, pattern discovery.
• Segmentare e isolare applicazioni e servizi: rafforzare le policies a livello di
cluster/host su cui vengono eseguite le istanze del servizio.

• Cifratura: anche nelle transazioni E-O. Adottare tools di management e
disseminazione chiavi.

• Cifratura: anche nelle transazioni E-O. Adottare tools di management e
disseminazione chiavi.
• Automazione: Più complessità e Più routine = più errore umano. Tools di
Automazione riducono significativamente l’incidenza di questi errori.

Sicurezza: Dove mi fermo?
Non è possibile soffermarsi sul perimetro, si deve agire a livello
di cluster/host istanza del servizio:

 Sfruttare le caratteristiche dei Container (dockerfile e
stratificazione immagini)

 Sfruttare le caratteristiche dei Container (dockerfile e
stratificazione immagini)
 Partire da immagini certificate in repositories certificate

Attacchi: un Esempio Pratico di Resilienza
Situazione client-server sfruttabile per Denial of Service
 Un demone vulnerabile (memory leaks, fork bomb, saturazione risorse)
 Un client ”opportunamente scritto”, che le sfrutta

Attacchi: 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 per cui,
un numero sufficiente di richieste,
satura le porte del server
Fork illimitato. Possibilità di fork bomb

Attacchi: l’attaccante
using System; using System.Net.Sockets; using System.Threading;
namespace EvilClient
…
Client[] clients = new Client[numberOfRequests];
for (int i = 0; i < numberOfRequests; i++) {
clients[i] = new Client(serverAddr, serverPort, msgToSend, noQuit, closeConn);
}
/****************************************************************************/
serverStream = connect(60000);
sendData(serverStream,Msg);
receiveResponse(serverStream);
while (neverQuit){
Thread.Sleep(250);
if(closeConn) {
disconnect(serverStream);
serverStream = null;
serverStream = connect(60000); //ricrea la socket
}
sendData(serverStream,Msg);
}
Primo dialogo
Il server è succube della chiusura lato client,
quindi perché non stressarlo un po’?
Numero di thread definito

Scenario 1 – Attacco a VM
SERVER
HOST OS
Hypervisor
VM VM
S1S2S3
Attacchi: Dimostrazione

SERVER
Evil 1
°°°
HOST OS
Hypervisor
VM VM
Evil 2
Evil n
S1S2S3

Scenario 2 – Attacco a LxC
SERVER
HOST OS
SERVER
Evil 1
°°°
HOST OS
Hypervisor
VM VM
Evil 2
Evil n
S1S2S3
VM VM
S3 S2 S1
Hypervisor

Scenario 2 – Attacco a LxC
Evil 1
°°°
Evil 2
Evil n
SERVER
HOST OS
SERVER
Evil 1
°°°
HOST OS
Hypervisor
VM VM
Evil 2
Evil n
S1S2S3
VM VM
S3 S2 S1
Hypervisor

Grazie
Gianluca Magalotti
Business Developer/ Business-e S.p.A.
@Aniaclug
#redhatosd

Sicurezza e resilienza di Architetture a Containers

Recommandé

Recommandé

Contenu connexe

Similaire à Sicurezza e resilienza di Architetture a Containers

Similaire à Sicurezza e resilienza di Architetture a Containers (20)

Sicurezza e resilienza di Architetture a Containers