Un cluster costantemente dinamico di istanze di breve durata riduce la superficie di attacco?

Question

Un cluster costantemente dinamico di istanze di breve durata riduce la superficie di attacco?

#1 da (1 voti)

0

L'idea delle 4

L'idea generale è che ogni istanza che viene lanciata sul mio cluster è precaricata con uno "script suicidio" che dopo un Time To Live preimpostato (per esempio, 27 minuti) avvia un'istanza sostitutiva e termina automaticamente.

Il risultato è un cluster in continua evoluzione in cui non esiste alcun indirizzo IP più lungo del TTL di una determinata istanza.

Non ho una comprensione dei vettori di attacco o della teoria della superficie di attacco come sono sicuro che molti di voi facciano, ma questo tipo di approccio sembra offrire alcuni vantaggi interessanti.

Ecco cosa posso pensare

Riduci i tentativi di intrusione complessivi per istanza: la breve durata di ciascun IP ridurrebbe il tempo disponibile per qualsiasi tentativo di intrusione. Una volta che viene trovato un IP di destinazione, l'autore dell'attacco ha solo il TTL prima che la finestra si chiuda, riducendo così il numero complessivo di tentativi, riducendo così la probabilità complessiva di un attacco riuscito.
Frequenti aggiornamenti di sicurezza: le istanze gestiscono i loro aggiornamenti di sicurezza all'avvio, il che significa che non saranno mai più di 27 minuti non aggiornati con le patch di sicurezza.
Elimina il livello di distribuzione: se gestisci la distribuzione delle app all'avvio, cosa che farei, automatizzerebbe ulteriormente il processo ovviando alla necessità di Githooks o Dockerhubhooks, nel bene e nel male.

A quick thought experiment would also reveal that if you reduce the TTL down to a point where any given instance only has time to handle starting itself up, handling a handful of requests (the 'suicide script' could also be triggered after a certain number of requests have been handled, like say, 27), and then it goes down it seems to me that it would greatly increase the difficulty of an attack. If the attack requires more than 27 requests then the attacker would never be able to complete all the steps needed to succeed.

Quindi penso che siano interessanti, buone cose. Ci sono ovviamente molti più fattori da prendere in considerazione, non ultimo l'impatto che questo potrebbe avere sul modo in cui le richieste vengono gestite dal router, e se il provider di cloud lo consentirebbe anche considerando il carico aggiuntivo della CPU che potrebbe mettere su il loro sistema.

Ridurrebbe la superficie di attacco per i seguenti vettori di attacco?

Tenta di compromettere open-ssl
Scansione porte
HTTP / HTTPS che sta ascoltando su 80 e 443 su ogni istanza

Vale la pena notare che le applicazioni su ogni istanza sarebbero app effimere, lo storage di sessione è un cluster Mongo remoto (in esecuzione nella stessa area AWS) e Nginx verrebbe utilizzato su ogni istanza per gestire il routing del traffico verso IP corretto: porta di ogni app installata sull'istanza, motivo per cui 80 e 443 devono essere aperti.

Grazie in anticipo per qualsiasi informazione tu voglia condividere.

attack-prevention attack-vector

posta AJB 18.01.2015 - 02:50

fonte

1 risposta

Leggi altre domande sui tag attack-prevention attack-vector

Modello di crittografia a due fattori [chiuso] Alla ricerca di un modo per crittografare / decodificare i dati utilizzando una chiave generata che funziona in Windows e Linux

score 1 · Accepted Answer

Does a constantly dynamic cluster of short-lived instances reduce attack surface?

Riduci la superficie d'attacco?

Non penso che lo faccia in modo significativo. Non ti consentirebbe necessariamente di eseguire meno servizi o meno servizi esposti a potenziali aggressori. La superficie esposta complessiva del tuo sistema rimane la stessa.

Riduci la minaccia?

Anche io non la penso così, non riduce necessariamente il numero di vulnerabilità che potrebbero esistere nel tuo sistema o il numero di potenziali aggressori che sono motivati e in grado di sfruttare il tuo sistema. Potrebbe ridurre leggermente la minaccia se ciò potrebbe portare il software vulnerabile ad essere aggiornato più rapidamente, ma ciò potrebbe anche essere ottenuto senza sostituire l'istanza.

Riduci il rischio?

Sì, penso che lo farebbe - la domanda è di quanto. Stai rendendo più difficile per un utente malintenzionato sfruttare il tuo sistema e quindi ridurre le possibilità che riescano, ma non stai fondamentalmente rimuovendo alcun vettore di attacco.

Lo considero un po 'come un sistema di prevenzione delle intrusioni (IPS) che generalmente tenta di bloccare le richieste sospette. In tal caso, stai riducendo la possibilità che un utente malintenzionato abbia successo perché deve prima eludere l'IPS, ma in realtà non stai rimuovendo alcuna vulnerabilità dal tuo sistema.

Inoltre, ci sono alcuni vettori di attacco che non sarebbero affatto interessati da questo:

Iniezioni SQL - Potrebbe essere sfruttato a prescindere dall'istanza servita alla richiesta
DDoS rispetto a una richiesta di calcolo dispendioso fornita tramite il tuo servizio di bilanciamento del carico
Codice malevolo memorizzato nell'infrastruttura condivisa - es. il tuo DB

the attacker would never be able to complete all the steps needed to succeed

Ciò sarebbe valido se si potesse garantire che una vulnerabilità non possa essere sfruttata in 27 minuti, altrimenti l'efficacia varierà notevolmente tra i vettori di attacco. Alcuni attacchi potrebbero essere facilmente orchestrati in meno di un minuto.

Ad esempio, nella vita reale le serrature temporizzate funzionano perché se si sa che la polizia arriverà in 20 minuti ma la cassastrong non può essere aperta per 30 minuti. A meno che tu non sia in grado di ricreare questo scenario, non credo che eventuali vulnerabilità siano eliminate.

Attempts to compromise open-ssl

Dubito che si presume che tutte le tue istanze stiano utilizzando una versione vulnerabile. Forse se ci vuole più di 27 minuti per sfruttare.

Port Scanning

No, tutte le tue istanze presumibilmente avranno le stesse porte aperte e servizi attivi. Quando un'istanza diventa offline, potrebbero semplicemente continuare la scansione su un'altra istanza da cui erano stati interrotti.

HTTP/HTTPS which is listening on 80 and 443 on each instance

Esiste un'enorme varietà di exploit che potrebbero essere forniti su HTTP, ma in generale non penso che farebbe molta differenza. In genere, i sistemi con carico bilanciato sono progettati per offrire la stessa risposta da ogni istanza, quindi se un'iniezione SQL può essere eseguita su un'istanza, quasi sicuramente funzionerà contro un'altra.