Come vengono compromessi davvero i siti, e come non essere il bersaglio facile.
Nella sicurezza, la causa presunta è di solito «non c'è niente che non va». Ecco come vengono compromessi davvero i siti, perché la cima di quella lista è prevenibile, e come si dimostra dall'esterno che una correzione ha chiuso la porta.
In questo articolo 4 sezioni
- Nella sicurezza, la causa presunta è «non c'è niente che non va». La maggior parte delle persone non sa di essere stata violata.
- Il nostro monitoraggio e i nostri feed di threat intelligence sono collegati in modo da aprire il ticket, quindi il primo messaggio è di solito il nostro. Accorgersene per primi è il lavoro.
- I siti vengono compromessi in modi noiosi. Software non aggiornato e cose lasciate aperte per sbaglio guidano la lista, ed entrambi sono esattamente ciò che un audit prima del go-live e il patching continuo intercettano.
- Trovare la violazione è solo metà. Quando ne chiudiamo una, dimostriamo che la porta è chiusa riattaccando da un indirizzo di cui non ci fidiamo. Se riusciamo ancora a raggiungerla, non è risolta.
C'è un segnale in ogni chiamata di sicurezza. La causa presunta dal cliente è di solito la peggiore che esista: non c'è niente che non va. Non hanno chiamato perché qualcosa sembrava strano. Hanno chiamato perché glielo abbiamo detto noi. Quando una violazione diventa visibile a chi possiede il sito, di solito è già avvenuta.
Nella sicurezza, la causa presunta è «non c'è niente che non va»
“quote: Nella sicurezza, la causa presunta dal cliente è di solito «non c'è niente che non va». Non sapevano di essere stati violati. attribution: EUROVPS SECURITY”
Questa è tutta la differenza. Non che le violazioni non avvengano. Avvengono, su ogni piattaforma, a ogni tipo di sito. La differenza è chi la vede per primo: un livello di rilevamento che osserva le firme di una compromissione, o un feed di threat intelligence che segnala traffico che non dovrebbe esistere, mentre la dashboard del sito stesso è ancora verde. Il nostro monitoraggio e quei feed sono collegati in modo da aprire il ticket, ed è per questo che il primo messaggio è di solito il nostro.
Come vengono compromessi davvero i siti
Togliete la versione da film e i modi in cui i siti vengono compromessi davvero sono noiosi, e si ripetono. Ecco la classifica, dal più comune in giù. Niente in cima a questa lista è ingegnoso.
Software non aggiornato o a fine vita
La via d'ingresso più comune, con ampio margine. Un'applicazione con una vulnerabilità pubblicamente nota, esposta a internet, anni indietro con le patch. Esposta a internet e anni indietro con le patch è tutto ciò che serve. L'exploit è pronto sullo scaffale. Nessuna ingegnosità richiesta.
Qualcosa lasciato aperto per sbaglio
Nessun exploit necessario. La porta era semplicemente aperta. Un data store in ascolto su ogni interfaccia di rete senza autenticazione. Un file di configurazione o di debug leggibile da tutti. Un CMS che espone i propri nomi utente attraverso un'API aperta. Un sottodominio di staging dimenticato che risponde ancora. Nessuno ha forzato l'ingresso. Sono entrati camminando.
L'origin raggiungibile dietro il CDN
Il sito sta dietro un CDN, ma il server reale risponde ancora direttamente se riuscite a trovarlo, e il suo indirizzo spesso sta nel DNS di posta del dominio stesso. La porta principale è sorvegliata mentre quella sul retro è tenuta aperta.
Brute force di credenziali senza difesa a Layer 7
Una pagina di login senza nulla davanti a livello applicativo, martellata finché qualcosa non cede. Un firewall Layer 3/4 lo lascia passare dritto: per un filtro di porte, sembra traffico normale verso una porta che deve restare aperta.
Credenziali deboli, riutilizzate o esposte, senza MFA
Una password trapelata altrove, riutilizzata qui, senza un secondo fattore che la renda inutile. La serratura era a posto. La chiave era già stata copiata.
Spam in uscita da un account già compromesso
Spesso il primo segno esterno di una violazione già avvenuta. L'account non è il bersaglio. È la rampa di lancio, e lo spam è il fumo, non il fuoco.
Phishing e social engineering
Il livello umano. Nessun bug software coinvolto. Qualcuno è stato semplicemente convinto a consegnare le chiavi.
Guardate i primi due. Software non aggiornato e cose lasciate aperte per sbaglio. Nessuno dei due è un attacco ingegnoso. Entrambi sono esattamente ciò che un audit disciplinato prima del go-live e il patching continuo intercettano prima che qualcuno provi la maniglia. È tutto il caso a favore della managed security. La maggior parte delle intrusioni non sono scassi. Sono ingressi a piedi. E l'ingresso a piedi è prevenibile.
Accorgersene per primi è il lavoro. Dimostrare che è chiusa è la differenza.
Trovare la violazione è metà del lavoro. La metà che quasi nessuno fa è dimostrare che la correzione ha davvero tenuto. Quando chiudiamo una compromissione, non prendiamo per buona la parola della dashboard che la porta è chiusa. Riattacchiamo l'origin come farebbe un attaccante: da una macchina in un altro dei nostri datacenter, su un'uscita che il firewall non è mai stato istruito a considerare fidata. Se il nostro stesso scanner riesce ancora a raggiungerlo, non è risolto. Solo quando la porta è chiusa dall'esterno, da un indirizzo di cui non ci fidiamo, la dichiariamo chiusa.
“quote: Il lavoro non è solo correggere la violazione. È accorgersene per primi, e poi dimostrare dall'esterno che la porta è chiusa. attribution: EUROVPS SECURITY”
Quel metodo, riattaccare il proprio origin da un punto di osservazione non fidato e confermare ciò che un attaccante vedrebbe davvero, è una disciplina a sé e ha il suo articolo. Dimostriamo dall'esterno che è chiusa percorre l'intero playbook.
Sette modi per non essere il bersaglio facile
Niente in cima a quella classifica richiede un attaccante geniale. Il che significa che la maggior parte è prevenibile non essendo il bersaglio facile. Sette abitudini, nell'ordine in cui ripagano.
Aggiornate o ritirate
Se è esposto a internet e non manutenuto, è un rischio. Aggiornatelo o spegnetelo. Non c'è una terza opzione che finisca bene.
Date per scontato che l'origin verrà trovato
Vincolatelo agli intervalli IP del CDN così che solo il CDN possa raggiungerlo, e smettete di far trapelare il suo indirizzo nel vostro DNS di posta. Un origin nascosto non è nascosto se il vostro stesso DNS lo annuncia.
Un firewall L3/4 non è un WAF
Il filtraggio delle porte non legge le richieste. Brute force, injection e abusi a livello applicativo passano tutti su porte che dovete lasciare aperte. Vi serve una difesa che ispezioni il Layer 7.
Verificate prima di dichiarare finito
«Funziona» non è «è chiuso». Controllate cosa è esposto, cosa è leggibile da tutti, cosa è ancora in ascolto sull'internet pubblico, prima del go-live, non dopo che arriva l'avviso.
Date per scontato che le credenziali trapelino. Rendetele inutili fuori dalla whitelist.
MFA ovunque, e vincolate i percorsi sensibili a indirizzi noti. Una password rubata non dovrebbe aprire nulla da sola.
Sorvegliate il sorvegliante
Un monitoraggio che diventa cieco e continua a riportare verde è peggio di nessun monitoraggio, perché compra una falsa calma. Confermate che il rilevatore riesca davvero a vedere.
Dimostrate la correzione dall'esterno
L'unico test che conta è il punto di vista dell'attaccante. Riattaccate da un indirizzo di cui non vi fidate e confermate che la porta è chiusa.
Risposte dirette
Come vengono hackerati davvero i siti web su managed hosting?+
Per lo più in due modi noiosi. Software non aggiornato o a fine vita con una vulnerabilità pubblicamente nota, esposto a internet, e cose lasciate aperte per sbaglio: un data store senza autenticazione, un file di configurazione leggibile da tutti, un sottodominio di staging dimenticato. Gli exploit ingegnosi sono molto più in basso nella lista. La maggior parte delle intrusioni sono ingressi a piedi.
Come farei anche solo a sapere se il mio sito è stato violato?+
Spesso non lo sapreste, ed è questo il punto. Il nostro monitoraggio e i nostri feed di threat intelligence sono collegati in modo da aprire il ticket, quindi il primo messaggio su una compromissione è di solito il nostro. La causa presunta dal lato del cliente è di solito «non c'è niente che non va». Spam in uscita o un avviso da terzi è spesso il primo segno esterno, e a quel punto è già avvenuta.
Il mio server è sicuro se ha un firewall?+
Un firewall a Layer 3/4 filtra porte; non legge le richieste. Brute force di credenziali, injection e abusi a livello applicativo viaggiano tutti su porte che dovete lasciare aperte, quindi gli sembrano traffico normale. Un firewall non è un WAF. Fermarli richiede una difesa che ispezioni il Layer 7.
Gli attaccanti possono trovare il mio server origin se è dietro un CDN?+
Spesso sì. Il CDN aiuta solo se l'origin non può essere raggiunto direttamente, e l'indirizzo reale dell'origin spesso trapela nel DNS di posta del dominio stesso. Vincolate l'origin agli intervalli IP del CDN e smettete di annunciarlo nel DNS, altrimenti la porta principale sorvegliata ha quella sul retro tenuta aperta.
Su managed hosting, chi è responsabile del patching delle mie applicazioni?+
La piattaforma e l'applicazione sono lavori diversi, e il divario tra i due è dove i siti vengono compromessi. Noi teniamo la piattaforma indurita e facciamo l'audit prima del go-live. Ma un'applicazione a fine vita con una vulnerabilità nota è un rischio condiviso. Il valore managed è che un audit disciplinato prima del go-live e il patching continuo intercettano la maggior parte prima che qualcuno provi la maniglia.
Non siete sicuri di cosa sia esposto? Chiedete prima che lo scopra qualcun altro.
Portatelo a un ingegnere, non a una coda di ticket. Controlliamo cosa è raggiungibile dall'esterno, vi diciamo chiaramente cosa chiudere, e poi dimostriamo che è chiuso.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere