Come dimostriamo che la porta è chiusa prima del go-live.
Prima del go-live dimostriamo che la porta è chiusa: attacchiamo il vostro vero origin da una macchina fuori rete che il firewall non ha mai autorizzato, e vediamo ciò che vede un estraneo. Una porta chiusa risponde connection refused, non una pagina di login.
In questo articolo 7 sezioni
- Prima di ogni go-live, e dopo ogni modifica all'edge, facciamo una sola domanda: cosa vede davvero un estraneo su internet? Rispondiamo da una macchina in un altro dei nostri datacenter, su un egress che il nostro stesso firewall non è mai stato istruito ad autorizzare.
- Troviamo il vero origin nel modo in cui lo farebbe un attaccante (di solito trapela nel DNS di posta del dominio stesso), puntiamo ogni strumento sull'origin nudo invece che sul CDN, e rieseguiamo l'intera batteria.
- Scansioniamo tutte le 65.535 porte da quel punto di osservazione fuori rete, così possiamo dire in modo affermativo cosa è chiuso. La correzione duratura blocca l'origin agli intervalli pubblicati del CDN, sostenuta da un vero WAF Layer 7 e da block-list condivise.
- Poi non prendiamo la correzione sulla fiducia. Riattacchiamo l'origin nudo dall'esterno, e una porta chiusa risponde connection refused, non una pagina di login. Questa è una prova, non una promessa.
Il modo più comune in cui finisce un lavoro di hardening è che qualcuno cambia un'impostazione, ricarica la pagina, vede quello che si aspettava e va avanti. Questo è patch-and-hope. Dimostra il sintomo che avete guardato; non dimostra nulla sulla porta. Quello che segue è il metodo che i nostri ingegneri eseguono invece, prima di ogni go-live e dopo ogni modifica all'edge. Ha una sola regola di governo: ogni controllo viene eseguito dall'esterno, da un punto di osservazione che non riceve alcuna fiducia speciale, perché l'unica domanda che conta è cosa può davvero raggiungere un estraneo su internet. La prima metà di questo potreste eseguirla contro il vostro sito stasera. Il motivo per affidarla a noi è chi esegue l'intera batteria, e da dove.
L'unica domanda che conta: cosa vede davvero un estraneo?
Eseguiamo la scansione da una macchina dedicata in un altro dei nostri datacenter, su un IP di egress che il nostro stesso firewall non è mai stato istruito ad autorizzare. Non riceve nessuna voce in allow-list, nessuna eccezione, nessuna cortesia. Vede esattamente quello che vede internet.
Funziona solo se il punto di osservazione è reale e fuori dal vostro perimetro di fiducia, ed è per questo che è una macchina in un altro dei nostri datacenter, sul nostro AS, non uno scanner a noleggio. È lo stesso motivo per cui possedere la rete conta in assoluto. Di più in non possedete la vostra rete.
Da quel punto di osservazione, tre cose smettono di essere affermazioni e diventano misurazioni. Se il vostro CDN è davvero davanti al vostro origin. Se le porte che credete chiuse sono chiuse. E, dopo una correzione, se la porta che avete appena chiuso è davvero chiusa. Il resto di questo è come leggiamo ciascuna.
Trovate il vero origin come farebbe un attaccante
L'origin di solito trapela nel DNS di posta del dominio stesso, perché il record SPF che autorizza la vostra posta nomina proprio l'host che la invia. Una volta noto il vero origin, puntate l'hostname direttamente su di esso, così ogni strumento colpisce l'origin nudo invece del CDN, e rieseguite l'intera batteria contro di esso.
# the origin usually leaks in the domain's own mail DNS
scanner$ dig +short TXT origin.example # the SPF record often names the sending host
scanner$ dig +short MX origin.example
# pin the hostname straight to the origin so nothing touches the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/
# now re-run the full battery against the naked origin, not the edge
scanner$ <scan battery> --target <origin-ip>Il punto che questo dimostra è semplice. Se l'origin risponde alla scansione puntata allo stesso modo dell'hostname pubblico, servendo le stesse pagine, lo stesso form di login, allora il CDN e il WAF davanti a esso vengono aggirati. Ogni richiesta che un attaccante vuole inviare può passargli intorno.
Scansionate ogni porta, poi dite cosa è chiuso
Dal punto di osservazione fuori rete scansioniamo tutte le 65.535 porte.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>Una scansione a superficie completa non è solo un sì/no su ogni porta. Cosa risponde, e come, prende le impronte della macchina. Tre indizi ricorrono.
a mismatched TLS cert on a production subnet -> a forgotten host, fingerprinted
an absurdly low firewall hit-count -> traffic isn't flowing the way you think
a DNS server answering REFUSED -> good: you are not an open resolverUn firewall non è un WAF
Il brute force sui login è invisibile a Layer 3/4, quindi la difesa vive all'edge, a Layer 7.
Rate-limit all'edge, dove stanno i login.
Contate i login falliti per sorgente al livello HTTP, l'unico posto dove sono visibili, e bandite una sorgente che supera la soglia. Il firewall non ha mai visto l'attacco; l'edge non vede altro.
Escalation alla subnet dopo due strike.
Un singolo indirizzo bandito si ruota banalmente. Dopo un secondo strike dallo stesso vicinato, il ban si allarga alla subnet colpevole, così l'attaccante non può semplicemente spostarsi di un IP.
Diciamo la parte scomoda ad alta voce: un ban di subnet può colpire un utente legittimo che ha sbagliato la password due volte da un indirizzo condiviso, un NAT aziendale, un campus, un bar. È un costo reale, non un errore di arrotondamento. Quindi la regola viene consegnata con una valvola di sfogo documentata per gli IP condivisi, non come un muro permanente.
La correzione duratura: bloccate l'origin al CDN, poi riattaccatelo
La correzione è mettere l'origin dietro firewall verso gli intervalli pubblicati del CDN. Poi la stessa sonda puntata, dalla stessa macchina non autorizzata:
# BEFORE: pin the naked origin, it serves the login page around the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
HTTP/1.1 200 OK # the origin answered. the CDN was bypassed.
# AFTER: origin firewalled to accept only the CDN's published ranges
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
curl: (7) Failed to connect to <origin-ip> port 443: Connection refusedDietro il blocco dell'origin sta il vero WAF Layer 7, la cosa che ispeziona le richieste che il CDN inoltra davvero, e una block-list condivisa: un attaccante sorpreso a sondare un cliente viene bandito su tutti, così la ricognizione che mappa un sito paga un pedaggio su ogni altro.
Cosa correggiamo noi, e cosa vi restituiamo
Quando l'audit trova qualcosa, il lavoro si divide in due colonne. Una è nostra, e la facciamo nella stessa sessione: hardening all'edge dell'infrastruttura, subito. L'altra è nella vostra applicazione, e noi non tocchiamo il vostro codice. Vi consegniamo il reperto esatto, e nel frattempo lo schermiamo così non siete esposti mentre lo correggete.
| Cosa correggiamo nella stessa sessione | Cosa vi consegniamo da correggere (schermato nel frattempo) |
|---|---|
| Bloccare l'origin agli intervalli pubblicati del CDN | Aggiornare o rimuovere il plugin, il CMS o l'app vulnerabile |
| Mettere in piedi la difesa brute-force Layer 7 all'edge | Ruotare le credenziali condivise o predefinite |
| Mettere dietro firewall i data store esposti verso la rete privata | Abilitare la MFA sugli account che contano |
| Eliminare le fughe di informazioni sul web server | Correggere l'esposizione a livello applicativo nel vostro codice |
Poi riattacchiamo, e dimostriamo che è chiusa
Ogni correzione qui sopra finisce allo stesso modo: torniamo alla macchina che il firewall non è mai stato istruito ad autorizzare, rieseguiamo la batteria che ha trovato il problema, e confermiamo che la stessa misurazione ora torna chiusa. Il pin sull'origin restituisce connection refused. La porta che rispondeva è buia. Il reperto che vi abbiamo consegnato, una volta che lo chiudete, rifiuta anche noi.
La stessa postura, puntata sulla domanda se controlliamo persino la rete su cui viaggia il vostro traffico, è in non possedete la vostra rete.
Risposte dirette
Come dimostrate che una correzione di sicurezza ha davvero funzionato?+
Non ci fidiamo della patch. Riattacchiamo il vero origin da una macchina su un egress che il nostro firewall non è mai stato istruito ad autorizzare, così vede quello che vede internet. Se la porta è chiusa, una scansione puntata dell'origin nudo risponde connection refused, non una pagina di login. In quel caso, è una prova, non una promessa.
Come può un attaccante aggirare un CDN o un WAF e colpire direttamente l'origin?+
L'origin di solito trapela nel DNS di posta del dominio stesso, perché il record SPF che autorizza la vostra posta nomina l'host che la invia. Con il vero indirizzo dell'origin, puntate l'hostname direttamente su di esso così ogni strumento colpisce l'origin nudo invece del CDN. Se l'origin risponde come l'hostname pubblico, il CDN e il WAF vengono aggirati: sono efficaci solo se l'origin è bloccato su di essi. La correzione duratura è mettere l'origin dietro firewall per accettare traffico solo dagli intervalli pubblicati del CDN, dopodiché la stessa sonda ottiene connection refused.
Come verificate che una porta sia davvero chiusa dall'esterno?+
Scansionate tutte le 65.535 porte da un punto di osservazione fuori rete, non le poche comuni, così potete affermare che tutto ciò che non intendevate esporre è chiuso. Una scansione completa fa emergere anche indizi: un certificato TLS non corrispondente prende le impronte di un host dimenticato, un conteggio di hit del firewall assurdamente basso significa che il traffico non scorre come pensate, e un server DNS che risponde REFUSED conferma che non siete un open resolver.
Cosa correggete voi, e cosa dobbiamo correggere noi?+
Nella stessa sessione facciamo hardening all'edge dell'infrastruttura: blocchiamo l'origin agli intervalli del CDN, mettiamo in piedi la difesa brute-force all'edge, mettiamo dietro firewall i data store esposti verso la rete privata ed eliminiamo le fughe di informazioni sul web server. Poi vi consegniamo il reperto esatto e lo schermiamo nel frattempo: aggiornare o rimuovere il plugin/CMS/app vulnerabile, ruotare le credenziali condivise o predefinite, abilitare la MFA e correggere l'esposizione applicativa nel vostro codice.
Non chiuderemo semplicemente il ticket. Dimostreremo che la porta è chiusa.
Parlate con un ingegnere che riattacca il vostro origin da una macchina che non abbiamo mai messo in allow-list, e vi mostra il connection refused che prova che la porta è chiusa.
Parla con un ingegnereSe volete la postura sotto a tutto questo, inizia con il possedere la rete da cui siete difesi: non possedete la vostra rete.
Siete 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