IP di origin dietro una CDN: come trapela e come bloccarlo

La porta davanti e la porta sul retro

Una CDN o un WAF cloud sta davanti al server e gestisce l'hostname. Puntate uno scanner su quell'hostname e la richiesta va all'edge: il TLS dell'edge, gli header dell'edge, i rate limit e le regole dell'edge. Un report verde è un report sull'edge. L'origin, il server vero, non è stato toccato da quella scansione, e qualunque cosa esponga direttamente resta esposta a chiunque lo raggiunga per indirizzo invece che per nome.

Dove trapela l'origin

L'indirizzo è raramente ben nascosto, perché il dominio lo pubblica per altri scopi. Il record SPF è il caso più comune. Una policy SPF che usa il meccanismo a autorizza il record A del dominio stesso a inviare posta, e quel record A è l'origin dietro la CDN. Il meccanismo mx punta agli host di posta, che spesso stanno nello stesso range. Un ip4: letterale lo scrive per esteso.

$ dig +short TXT example.com
"v=spf1 a mx ip4:<address> include:_spf.<mail-provider> ~all"
$ dig +short MX example.com
$ dig +short A mail.example.com ftp.example.com staging.example.com origin.example.com

Oltre allo SPF: sottodomini che non sono mai stati messi dietro la CDN (mail, ftp, un pannello di controllo, staging, un host origin nudo), che risolvono direttamente al server. I certificate transparency log, che registrano ogni certificato emesso per un nome, compreso quello sull'host origin. I database di passive DNS, che conservano il record A di prima che la CDN fosse introdotta. Gli header Received di qualsiasi mail inviata dal web server, che nominano l'host da cui proviene. E le funzioni applicative che fanno connettere il server verso l'esterno su richiesta, come i pingback e i test dei webhook, che mostrano l'indirizzo di connessione a chiunque riceva la chiamata.

Fissate l'origin e scansionate ciò che scansiona un attaccante

Una volta noto l'indirizzo, fate in modo che gli strumenti ignorino la CDN. curl può farlo per singola richiesta; gli scanner che non lo permettono prendono una riga nel file hosts. Eseguitelo da una macchina che non sta sulla vostra rete e non sta in nessuna allowlist di cui l'origin si fida, perché una scansione da un indirizzo fidato riferisce ciò che vedono gli indirizzi fidati.

# per request, no hosts-file change
$ curl --resolve example.com:443:<address> -sI https://example.com/

# for tools without --resolve
$ echo "<address>  example.com" | sudo tee -a /etc/hosts

Tenete due colonne nel risultato. La colonna infrastruttura: quali porte rispondono, quali versioni TLS sono accettate, se i banner rivelano spontaneamente nomi di software. La colonna applicazione: endpoint non autenticati che enumerano gli utenti, file di debug o di log leggibili nella web root, percorsi amministrativi raggiungibili senza un secondo fattore, componenti indietro rispetto alla release corrente. Una macchina hardenizzata che serve un'applicazione aperta non è un sito sicuro, e le due colonne non si fanno confluire in un unico verdetto.

Bloccate l'origin sulla CDN

La correzione strutturale sta all'origin, non all'edge. Le porte web rispondono solo ai range di indirizzi pubblicati dalla CDN, con tutto il resto negato per default. Su un host con firewalld:

# load the CDN's published ranges into an ipset, then allow only them on 443
$ firewall-cmd --permanent --new-ipset=cdn-v4 --type=hash:net
$ firewall-cmd --permanent --ipset=cdn-v4 --add-entries-from-file=cdn-ranges-v4.txt
$ firewall-cmd --permanent --zone=public --remove-service=http
$ firewall-cmd --permanent --zone=public --remove-service=https
$ firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cdn-v4" port port="443" protocol="tcp" accept'
$ firewall-cmd --reload
$ firewall-cmd --ipset=cdn-v4 --get-entries

Due dettagli decidono se questo regge. I range della CDN cambiano, quindi il file viene aggiornato dalla lista pubblicata dalla CDN secondo un calendario e l'ipset ricaricato con esso. E ogni prefisso in una allow list viene riletto dopo il caricamento: una lunghezza di prefisso sbagliata di un carattere ammette una larga parte di internet e nel file sembra normale.

I range di indirizzi sono il primo blocco, non l'unico. La maggior parte delle CDN può autenticare i propri pull verso l'origin con un certificato client; richiedetelo sul web server, così una richiesta proveniente da un range della CDN che non presenta il certificato viene comunque rifiutata. Poi rimuovete le fughe che restano: un record SPF che nomina solo gli host che inviano posta, nessun sottodominio non proxato che punti all'origin e, dove è praticabile, un nuovo indirizzo di origin una volta che il blocco è in posizione, perché quello vecchio resta nel passive DNS a tempo indeterminato.

Verificate dall'esterno

Rieseguite la scansione fissata dallo stesso punto di osservazione non fidato. L'origin rifiuta la connessione sulla 443, e l'hostname continua a servire attraverso la CDN. Ripetete dopo ogni modifica ai range o alla configurazione del web server; trasformarlo in un controllo permanente invece che in un'operazione una tantum è l'argomento di dimostrate che è chiuso dall'esterno.

$ curl --resolve example.com:443:<address> -m 5 -sI https://example.com/ ; echo "exit $?"
exit 28
# a timeout (28) or a refused connection (7) is the correct answer from the locked origin