Languages

Monday, May 17, 2021

Cloudflare, como fazer direito e não revelar seu ip real





Artigo original por Martin Hanic traduzido e adaptado por Leandro Trindade

Olá pessoal, estou trazendo aqui um artigo muito bom e direto que normalmente recomendo aos meus clientes na hora de configurarem seu Cloudflare. Chegou a um ponto em que vi que a utilidade e valor dele mereciam uma tradução digna para o português. Vale a pena a leitura.


Introdução


Se você está lendo essa publicação, você provavelmente é ou pretende ser um usuário da plataforma Cloudflare (ou uma CDN similar). Apenas para explicar brevemente a Cloudflare é uma CDN distribuída por todo o globo, o que faz com que suas páginas carreguem mais rápido e oferece proteções complexas de websites na forma de WAF e bloqueio de DDoS (ao esconder seu endereço IP real).

As dicas incluídas neste artigo não são voltadas apenas para usuários da Cloudflare, mas são dicas gerais de OPSEC (segurança de operação) para todas as soluções similares que dependem da confidencialidade de seus endereços de IP reais. Isso pois se um atacante conseguir encontrar seu endereço IP real, ele pode ultrapassar essa proteção e voltar os ataques a seu servidor diretamente.

O objetivo dessa publicação é mostrar o que precisa ser feito para se obter uma configuração segura e funcional, explicar porquê todas as contra-medidas são realmente necessárias através da demonstração dos ataques que elas mitigam de forma a não revelar seu IP de origem.

Passos recomendados pela Cloudflare


Após terminar a configuração de sua conta Cloudflare, você será apresentado ao seguinte guia: Primeiros passos recomendados para todos os usuários da Cloudflare.

A maior parte dele cobre todos os passos necessários para ter uma configuração funcional, mas ele contém dois importantes passos de segurança.

Lista branca de endeços IP da Cloudflare


Esse primeiro é o mais importante:

    Passo 1: Coloque em lista branca os endereços IP da Cloudflare

O título diz tudo. Simples e claro. No entanto, para pessoas que não são focadas em segurança, isso pode ser um pouco confuso, já que podem pensar no seguinte:

Coloque os endereços IP da Cloudflare em uma lista branca, pois se você tiver um firewall isso tornará possível que acessem seu site sem serem bloqueados ou colocados em uma lista negra.

Isso, porém, não é verdade. A verdadeira idéia por trás disso é:

Coloque os endereços IP da Cloudflare em uma lista branca e rejeite qualquer outra coisa!

Isso é para permitir acesso ao seu site apenas pela Cloudflare e evitar que o resto do mundo (Crawlers) acesse ele diretamente e veja que conteúdo é oferecido em um endereço IP específico/host.

E se eu não fizer? Como alguém pode me achar em uma rede mundial gigantesca?

[Ataque] Identificar o IP de um site usando o Shodan / Censys

A primeira coisa que um atacante irá fazer quando estiver buscando um servidor é consultar o Shodan ou o Censys, ambos são motores de busca para dispositivos conectados à internet. Isso usando uma busca simples como:

http.title:"Título do seu site"

Assim ele pode buscar todos os endereços IP de servidores que entreguem um site com esse título específico. Fácil. E ainda tem muito mais para procurar.

[Ataque] Identificar o IP de um site usando o Project Sonar

Imagine se fosse possível procurar a internet inteira por servidores escutando em portas comuns e depois coletar os dados da resposta HTTP (o site oferecido) de todos eles. Bom, é possível sim. E algumas pessoas fazem isso semanalmente e publicam os resultados online. Elas não são tão grandes como você deve pensar, um grupo de dados é de aproximadamente 60Gb comprimidos. Dê uma olhada:
Project Sonar HTTP
Project Sonar HTTPS

Então não apenas o atacante pode pesquisar o conjunto de dados pelo título do seu site para pegar o endereço IP do servidor, mas ele pode também pesquisar todos os dados históricos do período em que seu site ainda estava disponível publicamente.

Modo SSL e o certificado do servidor


Outra boa idéia é habilitar o SSL entre a Cloudflare e seu servidor de “origem”. Já que o LetsEncrypt existe, todos procuram pela opção completa: Full (strict).


Passo 4: Escolha um modo SSL. Uma resposta rápida para essa pergunta é: apenas escolha “Flexível” (Flexible) se o seu servidor web de origem não consegue aceitar conexões seguras (HTTPS). Escolha “completa” (Full) se você tem um certificado SSL auto assinado, e escolha completa rigorosa (Full strict) se você tem um certificado SSL válido emitido por uma autoridade certificadora.

Até mesmo a Cloudflare oferece a você certificados gratuitos para seu servidor de origem.


Use o CA de origem para gerar certificados para seus servidores de origem, usando wildcards para cada zona, de forma a manter os SANs no mínimo possível. Atualize a configuração de SSL de cada zona do modo “Flexível” ou “Completo” para modo “Rigoroso” (Strict), agora você terá um certificado CA de origem ou um CA público instalado protegendo todos os hosts dessa zona.

Mas tem uma pegadinha…

[Ataque] Identificar o IP de um website usando o certificado de origem da Cloudflare

Usar o certificado SSL de origem é uma solução boa e fácil, mas apenas se você fizer todas as outras coisas direito. Em uma situação em que configura seu webserver para servir um site neutro como VHOST padrão (para evitar ser identificado quando acessado via IP) mas seu provedor de hospedagem/ alcance de portas é pequeno e todos os outros servidores estão na mesma hospedagem, não é tão difícil checar o emissor do certificado em todos os IPs daquele alcance de IPs para determinar que hosts usam CloudFlare.

[Ataque] Identificar o IP de um website usando os logs de transparência de Certificado

Tenha em mente que, quando um certificado SSL é emitido, dados sobre ele são publicados nos Logs de Transparência de Certificados, isso é disponibilizado e buscável publicamente. Então se você emite um novo certificado para seu domínio (para ser usado pelo seu host de origem) ele é publicado e pode ser facilmente encontrado e os novos hostnames revelados. Basta dar uma olhada no cert.sh. Uma idéia bem melhor é utilizar um certificado do tipo wildcard.

Linhas guia gerais sobre segurança de websites

Se você leva segurança a sério, você provavelmente irá pesquisar por outros recursos com dicas de segurança, e você vai acabar esbarrando no seguinte blog da Cloudflare: General website security guidelines

Mesmo o título dizendo “linhas-guia gerais”, todas as dicas incluídas são muito importantes.

As seguintes linhas guias de segurança de websites são apropriadas para todos os clientes da Cloudflare.
Não limite a quantidade ou reduza a velocidade de requisições dos endereços IP da Cloudflare.
Certifique-se de que está vendo o endereço IP original de seus visitantes nos logs.
Remova todos os registros de DNS que não estiver usando.
Rode o email em um servidor/serviço separado.
Depois de mover o site para a Cloudflare, mude o endereço IP do servidor.
Use limitação de quantidade de requisições para prevenir ataques de Brute Force e DDoS de camada 7.
Cheque as configurações de firewall de aplicação (WAF) para evitar ataque dinâmicos.

Vamos dar uma olhada mais perto nos mais relacionados a esse tópico.

Remover todos os registros de DNS que não estão sendo usados


Se você está movendo seu domínio para um CDN, tenha em mente que o CDN irá agir como um DNS autoritativo apra o domínio, não há necessidade de manter a zona antiga do servidor (ou até mesmo o servidor/serviço DNS). Assim que a troca for completa, remova o domínio/zona de seu servidor DNS.

Lembre-se de remover os registros PTR (entradas de DNS reverso) para o endereço ip também.

[Ataque] Consultar servidores de DNS antigos

Uma das coisas que um atacante irá fazer durante sua busca pelo endereço IP de origem é procurar em todos os endereços IP conhecidos pelas portas 53/udp e 53/tcp para encontrar um servidor DNS. Se você não removeu os registros DNS antigos do seu servidor DNS e não alterou seu endereço IP de origem depois da troca para o Cloudflare, ou caso as entradas de DNS apontem para o endereço IP novo por conveniência, você acaba de vazar seu endereço IP de origem.

Lembre-se que uma busca similar será feita para buscas de DNS reverso de todos os seus endereços de IP (ou IPs dos seus hosts), apenas para verificar que eles não retornem o nome do seu servidor alvo (ou seus alias).

Rodar o email em um servidor/serviço separado

Não rode o seu servidor de email (ou outro serviço público) no mesmo servidor que seu servidor web. Além dos problemas com performance, e todas as boas práticas de infosec, é uma péssima idéia em temos de OPSEC. Tenha em mente que os registros MX (entradas DNS para entrega de email, apontando para seus servidores de email) não são repassados via proxy pela Cloudflare e estarão apontando para o IP real do seu servidor de email. Então se ele for o seu servidor web também, bom, isso é um problema.

Não se esqueça de revisar seus registros SPF também.

Você pode levar em consideração a possibilidade de mudar seu serviço de email para a nuvem também se possível (e desejável), e usar o Gmail por exemplo.

[Ataque] Identificar servidores com múltiplos propósitos

Como parte do processo de coleta de informações, um atacante irá (em um dos seus primeiros passos) checar o servidor de email relacionado a suas entradas DNS. Isso inclui:
registros MX – nomes / endereços IP dos seus servidores de email
registros TXT – contendo registros SPF com hostnames, endereços de IP ou alcances de IP de servidores de email “autoritativos”

Armado com esse conhecimento um atacante irá realizar um portscan dos endereços de IP e ranges de IP para checar pela presença do servidor web alvo.

Após mover o site para o Cloudflare, mudar o(s) endereço(s) IP do(s) servidor(es)


Essa regra é a mais essencial e deve ser escrita com grandes letras vermelhas on topo de todas as recomendações.

DEPOIS DE MOVER O SEU SITE PARA A CLOUDFLARE, MUDE O(S) ENDEREÇO(S) IP DO SERVIDOR(ES).

Não faz nenhum sentido esconder um endereço de IP se ele é o mesmo IP antigo que você usou por anos e que é publicamente conhecido. Então depois de configurar a proteção do CDN, mude o IP, ou melhor ainda, mude o host também. Se você quer melhorar mais ainda, coloque um balanceador de carga baseado em nuvem (como o Amazon ELB) na frente, apenas para ter mais uma camada de proteção.

[Ataque] Buscar dados históricos de DNS/HTTP

Não é uma grande revelação que todos os dados na internet são arquivados de um jeito ou de outro. Apenas para lembrar o meme É impossível deletar coisas da internet. Isso é válido para entradas DNS também. Além dos serviços online que podem ser usados para buscar dados históricos de DNS, como por exemplo o SecurityTrails, um atacante pode simplesmente baixar todos os conjuntos de dados históricos do Project Sonar e buscar dentro deles.

Você precisa fazer mais

Pode parecer que já são muitas contra-medidas a fazer só para esconder seu endereço de IP, mas você ainda precisa fazer mais. Ainda existem outros métodos (ou canais) pelos quais um IP pode vazar. E ainda tem mais ataques dos quais você precisa estar atento.

Domínios alternativos para seus servidores


É uma boa prática usar um domínio alternativo para seus servidores de testes (isso se você realmente precisa deles públicos), ou apenas para sua conveniência, poder acessar seus servidores de produção de forma direta. Aqui vão algumas dicas que você deve manter em mente:
Escolha um nome de domínio que não seja relacionado a você ou seu domínio principal: Se seu domínio é exemplo.com, não escolha exemplo-dev.com, uma vez que isso pode acabar revelado por uma busca textual em bancos de dados de DNS, ou nos logs de transparência de certificados. Ao invés disso, escolha algo completamente não relacionado como dominiodoido.wtf.
Use um serviço de registro proxy para seu domínio: Não use o nome da sua empresa ou detalhes de contato para ele, uma vez que ele pode ser usado para identificar o domínio principal. Ao invés disso use um serviço de registrador terceirizado (proxy-registrant). Não use uma pequena empresa local como registrador (uma vez que isso torna mais fácil de enumerar todos os registros) para todos os seus domínios.
Use um certificado SSL gratuito: Use o LetsEncrypt, ou um serviço similar, para obter um certificado SSL válido. O objetivo é não ter ele ligado à sua empresa.
Domínio principal não resolvível: não adicione um registro DNS para o domínio em si, apenas para subdomínios/hosts. Isso é apenas para manter a ilusão de que o domínio não está sendo utilizado, ex: dominiodoido.wtf has no A record.

VHOST Padrão


Pelo bem do anonimato, é uma boa prática configurar o VHOST padrão do servidor web para algo que não seja relacionado com sua empresa/site. Uma boa idéia é usar o placeholder genérico, como o It works! do Apache.

O motivo é servir essa página no lugar da sua página protegida, quando acessada via um endereço de IP e não um host válido (cabeçalho host). Desta forma você não acabará indexado por scanners que acessam endereços de IP ao invés de nomes de host, e isso torna as coisas um pouco mais difíceis para atacantes buscando a sua página em um grupo de endereços IP.

Vazamento de aplicação web por comunicações externas (OOB)


Lembre-se que ainda é possível revelar o verdadeiro endereço de IP do seu servidor através de comunicações externas (Out-Of-Band). Esse é o motivo pelo qual um servidor web, e outras partes da aplicação como o BD, não devem ser autorizados a iniciar conexões com a internet. Regras de firewall restritivas (lista branca) deve ser estabelecidas de forma a negar qualquer comunicação externa (que não seja relacionada com requisições HTTP recebidas). Vamos dar uma olhada em alguns exemplos.

[Ataque] OOB via XXE


Se sua aplicação processa requisições XML ou documentos, não realiza a sanitização de entrada bem e o seu parser de XML não está devidamente configurado, um atacante pode usar essa funcionalidade para forçar o servidor a carregar uma entidade externa ( XXE ) ou um DTD remoto. Neste caso, o servidor web realizaria uma requisição para um servidor controlado pelo atacante via HTTP(s)(ou FTP, SMB, GOPHER,..) revelando seu endereço de IP.

Mesmo que conexões de saída sejam proibidas pelo seu firewall, resolver o nome do host a partir da requisição pode ser o suficiente para revelar o IP (como descrito abaixo).

Tenha em mente que alguns parsers de JSON suportam XML também, e podem ser capazes de lidar com requisições XML mesmo que você não as use.

[Ataque] OOB via SSRF


Os mesmos resultados descritos na sessão acima também podem ser obtidos se um atacante conseguir persuadir a aplicação a realizar uma requisição modificando um parâmetro controlado pelo usuário, que seja usado como uma URI ( SSRF ) ou nome de arquivo ( RFI ) pela aplicação.

É bom mencionar que o impacto desses ataques (XXE, SSRF, RFI) é bem mais sério do que a possibilidade de vazar os endereços IP do servidor.

[Ataque] OOB via DNS


Se o servidor web tem a capacidade de realizar queries DNS diretamente (ex: esteja rodando um servidor de cache DNS local), e o atacante seja capaz de forçar o servidor a realizar uma requisição em um servidor DNS sob seu controle, os IPs do servidor serão revelados.

Lembre-se que mesmo que sua aplicação web não tenha nenhuma funcionalidade que possa ser usada de forma maliciosa dessa forma, alguns frameworks de aplicação realizam checagens automaticamente em background. Por exemplo, resolvendo o conteúdo do cabeçalho HTTP X-Forwarded-For.

[Ataque] OOB via MAIL


Se sua aplicação é capaz de enviar e-mails (diretamente ou através de um servidor SMTP externo), o que provavelmente é se ela realiza cadastro de usuários, lembre-se de verificar o conteúdo dos cabeçalhos de email, de forma a se certificar que o endereço de IP real do remetente (servidor) não esteja incluído.

[Ataque] OOB via APIs públicas


Usando o VirusTotal para verificar arquivos enviados para sua aplicação web? Tenha em mente que a URL submetida e nomes de DNS resolvidos são armazenados no banco de dados deles. Você pode consultar no VirusTotal informações sobre um domínio ou IP.

Procurar dentro de serviços públicos por requisições vindas de seu domínio “oculto” pode revelar o verdadeiro IP do seu servidor.

[Ataque] Erros de aplicação


Erros em uma aplicação web e API devem ser apenas genéricos, não revelando nenhuma informação sensível, como os endereços IP do servidor (ou hostname alternativo). Bom, algumas vezes eles não são, e erros como Não foi possível conectar com host/IP. ou Não foi possível processar requisição para o host/IP. podem ser tudo o que um atacante está procurando (no momento).

[Ataque] Vazamentos históricos


Não existe 100% seguro. Esse é o motivo para haverem vazamentos históricos (e parciais) de bancos de dados antigos da Cloudflare. Um deles deu origem ao Crimeflare. Use ele para buscar o seu domínio por vazamentos antigos.

[Ataque] Enumeração de domínios


Essa checklist é simples:
  1. Pegue todos os domínios possíveis pertencendo à empresa ou indivíduo alvo
  2. Obtenha todos os hostnames existentes e subdomínios em todos os domínios
  3. Obtenha todos os endereços IP associados com esses hostnames
  4. Pegue registros PTR para os IPs
  5. Pegue todos os ASN/ Blocos de IP pertencentes à empresa alvo
  6. Pegue a listagem de hospedagens que a empresa alvo está usando
  7. Analise
  8. Repita
Esses são os primeiros passos que qualquer atacante irá fazer. Não apenas uma vez mas em diversas, diversas iterações incluindo todas as informações obtidas na rodada anterior. O objetivo é obter o máximo de informações possível que possam ajudar em todos os outros ataques.

Nossa, isso parece muito trabalhoso, e chato.

De fato é, mas este é o motivo porquê ferramentas como Sublist3r ou OWASP Amass existem.

Conclusão


Espero que este “pequeno” POST tenha sido útil para você, e possa ter feito notar quais passos devem ser tomados para ter um setup realmente funcional, além de ter explicado alguns ataques que podem levar ao vazamento do seu IP original.

Mas existem tantos! Como posso checar tudo isso?

Não se preocupe, podemos te ajudar com isso 😋: https://citadelo.com

Fonte: https://citadelo.com/en/blog/cloudflare-how-to-do-it-right-and-do-not-reveal-your-real-ip/
Posted by at No comments:
Labels: , , ,
Subscribe to: Posts (Atom)