IP de origem atrás de um CDN: como se descobre e como o fecha

A porta da frente e a porta das traseiras

Um CDN ou uma cloud WAF fica à frente do servidor e trata do hostname. Aponte um scanner a esse hostname e o pedido vai para o edge: o TLS do edge, os headers do edge, os rate limits e as regras do edge. Um relatório verde é um relatório sobre o edge. A origem, o servidor real, não foi tocada por esse scan, e o que quer que exponha diretamente continua exposto a quem a alcance por endereço em vez de por nome.

Onde a origem se revela

O endereço raramente está bem escondido, porque o domínio publica-o para outros fins. O registo SPF é o caso comum. Uma política SPF que usa o mecanismo a autoriza o próprio registo A do domínio a enviar e-mail, e esse registo A é a origem atrás do CDN. O mecanismo mx aponta para os hosts de correio, que muitas vezes estão na mesma gama. Um ip4: literal escreve-o por extenso.

$ 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

Para lá do SPF: subdomínios que nunca foram colocados atrás do CDN (mail, ftp, um painel de controlo, staging, um host de origem a nu), que resolvem diretamente para o servidor. Os certificate transparency logs, que registam todos os certificados emitidos para um nome, incluindo o do host de origem. As bases de dados de passive DNS, que guardam o registo A de antes de o CDN ser introduzido. Os headers Received de qualquer e-mail que o web server envie, que nomeiam o host de onde partiu. E funcionalidades da aplicação que fazem o servidor ligar-se para fora a pedido, como pingbacks e testes de webhook, que mostram o endereço de ligação a quem recebe a chamada.

Fixe a origem e faça scan ao que um atacante faz scan

Assim que o endereço é conhecido, faça as ferramentas ignorar o CDN. O curl consegue fazê-lo por pedido. Os scanners que não conseguem recebem uma entrada no ficheiro hosts. Execute-o a partir de uma máquina que não esteja na sua própria rede nem em nenhuma allowlist em que a origem confie, porque um scan a partir de um endereço de confiança reporta o que os endereços de confiança veem.

# 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

Mantenha duas colunas no resultado. A coluna da infraestrutura: que portas respondem, que versões de TLS são aceites, se os banners oferecem nomes de software. A coluna da aplicação: endpoints sem autenticação que enumeram utilizadores, ficheiros de debug ou de log legíveis no web root, caminhos administrativos acessíveis sem segundo fator, componentes atrás da sua versão atual. Uma máquina endurecida a servir uma aplicação aberta não é um site seguro, e as duas colunas não se reduzem por média a um único veredicto.

Feche a origem ao CDN

A correção estrutural está na origem, não no edge. As portas web respondem apenas às gamas de endereços publicadas pelo CDN, com tudo o resto negado por omissão. Num host com 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

Dois detalhes decidem se isto aguenta. As gamas do CDN mudam, por isso o ficheiro é renovado a partir da lista publicada pelo CDN segundo um calendário e o ipset é recarregado com ele. E cada prefixo numa allow list é relido depois de carregado: um comprimento de prefixo com um carácter errado deixa entrar uma grande parte da internet e parece normal dentro do ficheiro.

As gamas de endereços são a primeira fechadura, não a única. A maioria dos CDN consegue autenticar os seus pulls para a origem com um certificado de cliente. Exija-o no web server, para que um pedido vindo de dentro de uma gama do CDN que não apresente o certificado continue a ser recusado. Depois remova as fugas que restam: um registo SPF que nomeie apenas os hosts que enviam e-mail, nenhum subdomínio sem proxy a apontar para a origem e, onde for prático, um novo endereço de origem assim que a fechadura estiver no lugar, porque o antigo fica no passive DNS indefinidamente.

Verifique a partir de fora

Volte a executar o scan fixado a partir do mesmo ponto não confiável. A origem recusa a ligação na 443, e o hostname continua a ser servido através do CDN. Repita após cada alteração às gamas ou à configuração do web server. Transformar isto numa verificação permanente em vez de uma ação pontual é o tema de prove que está fechado a partir de fora.

$ 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