Como provamos que a porta está fechada antes do go-live.
Antes do go-live, provamos que a porta está fechada: atacamos a sua origem real a partir de uma máquina fora da rede em que a firewall nunca confiou, e vemos o que um desconhecido vê. Uma porta fechada responde connection refused, não uma página de login.
Neste artigo 7 secções
- Antes de qualquer go-live, e depois de qualquer alteração no edge, fazemos uma pergunta: o que vê realmente um desconhecido na internet? Respondemos-lhe a partir de uma máquina noutro datacenter nosso, num egress em que a nossa própria firewall nunca foi instruída a confiar.
- Encontramos a origem real como um atacante a encontraria (habitualmente revela-se no DNS de correio do próprio domínio), fixamos cada ferramenta à origem a nu em vez do CDN, e voltamos a correr a bateria completa.
- Varremos as 65.535 portas a partir desse ponto fora da rede, para podermos afirmar positivamente o que está fechado. A correção duradoura fecha a origem às gamas publicadas do CDN, com uma WAF real de Layer 7 e listas de bloqueio partilhadas por trás.
- E depois não aceitamos a correção de boa fé. Voltamos a atacar a origem a nu a partir de fora, e uma porta fechada responde connection refused, não uma página de login. Isso é prova, não uma promessa.
A forma mais comum de um trabalho de hardening terminar é alguém alterar uma definição, atualizar a página, ver o que esperava e seguir em frente. Isso é «patch e esperança». Prova o sintoma para que olhou. Não prova nada sobre a porta. O que se segue é o método que os nossos engenheiros correm em vez disso, antes de qualquer go-live e depois de qualquer alteração no edge. Tem uma regra que governa tudo: cada verificação corre a partir de fora, de um ponto que não recebe nenhuma confiança especial, porque a única pergunta que importa é o que um desconhecido na internet consegue realmente alcançar. A primeira metade disto podia corrê-la esta noite contra o seu próprio site. A razão para a entregar a nós é quem corre a bateria inteira, e de onde.
h2 (#stranger-sees): A única pergunta que importa: o que vê realmente um desconhecido?
Corremos o varrimento a partir de uma máquina dedicada noutro datacenter nosso, com um IP de egress em que a nossa própria firewall nunca foi instruída a confiar. Não tem entrada em nenhuma allow-list, nenhuma exceção, nenhuma cortesia. Vê exatamente o que a internet vê.
Isto só funciona se o ponto de observação for real e estiver fora da sua fronteira de confiança, e é por isso que é uma máquina noutro datacenter nosso, no nosso próprio AS, não um scanner alugado. É a mesma razão pela qual ter uma rede própria importa de todo. Mais sobre isso em a sua rede não lhe pertence.
A partir desse ponto, três coisas deixam de ser afirmações e passam a ser medições. Se o seu CDN está realmente à frente da sua origem. Se as portas que pensa fechadas estão fechadas. E, depois de uma correção, se a porta que acabou de fechar está mesmo fechada. O resto deste texto é como lemos cada uma.
h2 (#find-origin): Encontre a origem real como um atacante a encontraria
A origem revela-se habitualmente no DNS de correio do próprio domínio, porque o registo SPF que autoriza o seu e-mail nomeia o próprio host que o envia. Assim que a origem real é conhecida, fixa o hostname diretamente a ela, para que cada ferramenta bata na origem a nu em vez do CDN, e volta a correr a bateria completa contra ela.
# 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>O que isto prova é simples. Se a origem responde ao varrimento fixado da mesma forma que o hostname público responde, a servir as mesmas páginas, o mesmo formulário de login, então o CDN e a WAF à frente dela estão a ser contornados. Cada pedido que um atacante queira enviar pode passar ao lado deles.
h2 (#all-ports): Varra todas as portas, e depois diga o que está fechado
A partir do ponto fora da rede varremos as 65.535 portas.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>Um varrimento de superfície completa não é apenas um sim ou não para cada porta. O que responde, e como, dá a impressão digital da máquina. Três sinais repetem-se.
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 resolverh2 (#firewall-not-waf): Uma firewall não é uma WAF
A força bruta no login é invisível na Layer 3/4, por isso a defesa vive no edge, na Layer 7.
Rate limit no edge, onde estão os logins
: Conte as falhas de login por origem na camada HTTP, o único sítio onde são visíveis, e bloqueie uma origem que ultrapasse o limite. A firewall nunca viu o ataque. O edge não vê mais nada.
Escalar para a subnet após duas infrações
: Um único endereço bloqueado é trivialmente rodado. Após uma segunda infração vinda da mesma vizinhança, o bloqueio alarga-se à subnet em causa, para que o atacante não possa simplesmente saltar um IP para o lado.
Dizemos a parte desconfortável em voz alta: um bloqueio de subnet pode apanhar um utilizador legítimo que escreveu mal a palavra-passe duas vezes a partir de um endereço partilhado, um NAT empresarial, um campus, um café. Isso é um custo real, não um erro de arredondamento. Por isso a regra é entregue com uma válvula de escape documentada para IP partilhados, não como um muro permanente.
h2 (#durable-fix): A correção duradoura: feche a origem ao CDN, e depois volte a atacá-la
A correção é restringir por firewall a origem às gamas publicadas do CDN. Depois, a mesma sonda fixada, a partir da mesma máquina não confiável:
# 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 refusedPor trás do fecho da origem está a verdadeira WAF de Layer 7, aquela que inspeciona os pedidos que o CDN efetivamente encaminha, e uma lista de bloqueio partilhada: um atacante apanhado a sondar um cliente é bloqueado em todos eles, para que o reconhecimento que mapeia um site pague portagem em todos os outros.
h2 (#we-fix-you-fix): O que corrigimos nós, e o que lhe devolvemos
Quando a auditoria encontra algo, o trabalho divide-se em duas colunas. Uma é nossa, e fazemo-la na mesma sessão: reforçar no edge da infraestrutura, imediatamente. A outra está na sua aplicação, e não tocamos no seu código. Entregamos-lhe o achado exato, e protegemo-lo entretanto para que não fique exposto enquanto o corrige.
| O que corrigimos na mesma sessão | O que lhe entregamos para corrigir (protegido entretanto) |
|---|---|
| Fechar a origem às gamas publicadas do CDN | Atualizar ou remover o plugin, CMS ou aplicação vulnerável |
| Montar a defesa contra força bruta de Layer 7 no edge | Rodar credenciais partilhadas ou por omissão |
| Restringir por firewall os data stores expostos à rede privada | Ativar MFA nas contas que importam |
| Eliminar as fugas de informação no web server | Corrigir a exposição ao nível da aplicação no seu próprio código |
h2 (#re-attack): E depois voltamos a atacar, e provamos que está fechada
Cada correção acima termina da mesma forma: voltamos à máquina em que a firewall nunca foi instruída a confiar, voltamos a correr a bateria que encontrou o problema, e confirmamos que a mesma medição agora devolve fechado. A origem fixada devolve connection refused. A porta que respondia está às escuras. O achado que lhe entregámos, assim que o fecha, recusa-nos também a nós.
A mesma postura, apontada a se sequer controlamos a rede por onde o seu tráfego viaja, está em a sua rede não lhe pertence.
Respostas diretas
Como provam que uma correção de segurança funcionou realmente?+
Não confiamos no patch. Voltamos a atacar a origem real a partir de uma máquina num egress em que a nossa firewall nunca foi instruída a confiar, para que veja o que a internet vê. Se a porta está fechada, um varrimento fixado da origem a nu responde connection refused, não uma página de login. Nesse caso, é prova, não uma promessa.
Como pode um atacante contornar um CDN ou uma WAF e atingir a origem diretamente?+
A origem revela-se habitualmente no DNS de correio do próprio domínio, porque o registo SPF que autoriza o seu e-mail nomeia o host que o envia. Com o endereço real da origem, fixa-se o hostname diretamente a ela para que cada ferramenta bata na origem a nu em vez do CDN. Se a origem responde da mesma forma que o hostname público, o CDN e a WAF estão a ser contornados: só são eficazes se a origem estiver fechada a eles. A correção duradoura é a origem aceitar por firewall tráfego apenas das gamas publicadas do CDN, e depois disso a mesma sonda recebe connection refused.
Como verificam que uma porta está realmente fechada a partir de fora?+
Varrem-se as 65.535 portas a partir de um ponto fora da rede, não as poucas habituais, para se poder afirmar positivamente que tudo o que não se pretendia expor está fechado. Um varrimento completo revela também sinais: um certificado TLS que não corresponde identifica um host esquecido, uma contagem de hits na firewall absurdamente baixa significa que o tráfego não flui como pensa, e um servidor DNS a responder REFUSED confirma que não é um open resolver.
O que corrige a EuroVPS, e o que temos de corrigir nós próprios?+
Na mesma sessão reforçamos no edge da infraestrutura: fechamos a origem às gamas do CDN, montamos a defesa contra força bruta no edge, restringimos por firewall os data stores expostos à rede privada, e eliminamos as fugas de informação no web server. Depois entregamos-lhe o achado exato e protegemo-lo entretanto: atualizar ou remover o plugin, CMS ou aplicação vulnerável, rodar credenciais partilhadas ou por omissão, ativar MFA, e corrigir a exposição ao nível da aplicação no seu próprio código.
Não vamos simplesmente fechar o ticket. Vamos provar que a porta está fechada.
Fale com um engenheiro que volta a atacar a sua origem a partir de uma máquina que nunca colocámos em allow-list, e lhe mostra o connection refused que prova que a porta está fechada.
Fale com um engenheiroSe quer a postura que está por baixo de tudo isto, começa por ter a rede a partir da qual é defendido: a sua rede não lhe pertence.
Chegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro