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.