05 - Hosting, CDN, VPS e Infraestrutura Compartilhada
video: https://youtu.be/... no frontmatter da nota.Hosting, CDN, VPS e Infraestrutura Compartilhada
Nota da seção "06 - Análise de Infraestrutura" do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Classifica os tipos de hospedagem usados por adversários e organizações, explica por que a CDN dissolve a atribuição por IP e como diferenciar virtual hosts, SNI e DNS direto na prática.
Dialoga com as notas de Certificados TLS, de Domínios e Subdomínios e de Pivoting desta seção, e com a Pirâmide de Dor do capítulo 04.
1. Contexto e Posicionamento na Biblioteca
Todo indicador de rede que o analista produz termina, em algum momento, em um endereço IP ou em um ASN. A qualidade da análise depende, portanto, de entender o que fisicamente está naquele endereço: um servidor dedicado alugado por um operador, uma máquina virtual em nuvem que será destruída em horas, uma edge da CDN compartilhada por milhares de sites legítimos ou um servidor de hospedagem barata que acomoda duzentos domínios ao mesmo tempo. Ignorar essa camada produz os erros mais caros da inteligência tática: bloquear a edge da CDN inteira, atribuir uma campanha ao dono do IP errado ou declarar como pivô sólido uma relação que é acidental.
Esta nota classifica os modelos de hospedagem do ponto de vista do analista de CTI, detalha o efeito da CDN e do serverless sobre a atribuição, caracteriza o bulletproof hosting como categoria econômica e apresenta as técnicas que permitem diferenciar o que o IP bruto não diferencia. As técnicas descritas aqui alimentam diretamente o catálogo de pivôs da nota de Pivoting e Correlação de Infraestrutura e as decisões de bloqueio da resposta a incidentes.
2. Taxonomia de Hospedagem sob a Ótica do Analista
A classificação abaixo ordena os modelos de infraestrutura pelo que eles implicam para custo de rotação do adversário, densidade de vizinhança e valor de um IP como indicador. A regra geral que emerge da tabela é simples: quanto mais compartilhada a infraestrutura, menor o valor do IP como pivô e maior a necessidade de diferenciadores aplicacionais, como nome de host, certificado e conteúdo.
| Modelo | Característica central | Implicação para CTI | Vida útil típica |
|---|---|---|---|
| Servidor dedicado | Um operador controla o host inteiro | IP carrega mais sinal de atribuição | Meses a anos |
| VPS e nuvem (IaaS) | Máquina virtual em hipervisor compartilhado | IP de provedor grande tem reputação mista e rotação alta | Horas a semanas |
| Hospedagem compartilhada | Centenas de domínios por servidor, roteados por virtual host | IP quase inútil sozinho; exigir SNI e Host | Meses |
| CDN e proxy reverso | IP anycast compartilhado por milhares de sites | IP não identifica nada além da CDN | Contínuo |
| Serverless e funções | Endpoint efêmero atrás de plataforma | Indicador deve ser o domínio e o provedor, não o IP | Minutos a dias |
| Bulletproof hosting | Provedor tolerante a abuso e à aplicação da lei | O ASN e o intervalo de IP viram o indicador | Variável |
Dois efeitos atravessam a tabela. O primeiro é o custo de rotação: mudar de VPS custa alguns minutos e alguns dólares, então indicadores desse nível têm tempo de vida curto e exigem automação para acompanhar. O segundo é a reputação emprestada: adversários alugam deliberadamente na mesma nuvem que as vítimas, porque o tráfego para o mesmo provedor confunde triagem baseada em ASN e bloqueios grosseiros prejudicariam serviços legítimos.
O ciclo de vida da infraestrutura adversária completa a leitura da tabela. A maioria das campanhas segue o padrão de provisionamento barato, uso intenso por dias ou semanas e abandono, o que significa que o valor do indicador decai rápido e que a idade do ativo é um critério de priorização. Domínio registrado há seis horas com TLS ativo vale uma hipótese urgente de hunting; IP observado há três meses em nuvem provavelmente já não pertence ao mesmo operador. Por isso, toda entrada de infraestrutura na base de inteligência carrega data de primeira observação e data da última verificação, e regras de expiração derrubam indicadores de rede de nuvem em prazos de semanas, e não de anos.
3. CDN: Atribuição Dissolvida pelo Proxy Reverso
Uma rede de distribuição de conteúdo (CDN) opera como proxy reverso anycast: o cliente conecta no nó mais próximo, e o nó busca o conteúdo na origem. Do ponto de vista do adversário, isso entrega três vantagens gratuitas. A origem fica protegida de varredura direta e de ataques volumétricos, o tráfego ganha o endereço IP e a reputação de uma empresa grande e o TLS pode ser terminado na edge com certificado emitido em conjunto com a plataforma. O analista que resolver o domínio da campanha verá o IP de uma CDN legítima, e qualquer consulta a esse IP retornará centenas de sites inocentes no mesmo endereço.
O histórico do domain fronting ilustra tanto o poder quanto a vida curta dessas técnicas. A ideia era conectar no TLS com o SNI de um domínio benigno hospedado na mesma CDN e enviar no cabeçalho Host o domínio real da campanha, enganando inspeção de rede. Grandes provedores passaram a validar a concordância entre SNI e Host a partir de 2018, e a técnica praticamente morreu nas plataformas principais. O que sobreviveu é a versão vulgar do mesmo conceito: hospedar o phishing na CDN e contar com a relutância de quem bloqueia um intervalo de IP gigante. Detectar isso exige enriquecimento de reputação por domínio, e não por IP, e atenção a cabeçalhos de resposta que denunciam a origem, como falhas de configuração que vazam o CNAME real ou certificados cujo SAN menciona o host de origem.
Para operar bem diante de CDNs, o analista adota três hábitos permanentes. Primeiro, nunca trata o IP como indicador quando o reverse DNS ou a porta aberta identificam infraestrutura de CDN, e grava o ASN no registro do indicador. Segundo, busca a origem com técnicas de diferenciação descritas na seção 6, porque a origem é o que sobrevive ao bloqueio da edge. Terceiro, usa a CDN como fonte de inteligência em vez de obstáculo: o histórico de certificados, o fingerprint do servidor e os cabeçalhos HTTP da edge, quando comparados entre domínios suspeitos, revelam operadores que usam a mesma conta e o mesmo template.
A tabela abaixo separa os dois planos que convivem em toda análise com CDN, e a confusão entre eles é a origem da maioria dos falsos pivôs.
| Plano | O que se observa | O que vale registrar | O que não fazer |
|---|---|---|---|
| Edge da CDN | IP anycast, certificado da edge, cabeçalhos padrão da plataforma | Nome da CDN, ASN e SNI observado | Bloquear o IP, pivô por certificado da edge |
| Origem | Histórico de DNS passivo, vazamentos de CNAME, certificado com SAN da origem | IP real da origem com data de observação e ASN | Tratar a origem como permanente, expor a busca ao alvo |
4. Bulletproof Hosting como Categoria Econômica
Bulletproof hosting é o serviço que comercializa a tolerância ao abuso: o provedor ignora reclamações de spam e phishing, não coopera com pedidos de remoção de países comuns e garante uptime para conteúdo que hospedagens convencionais derrubariam em horas. A oferta historicamente se concentrou em jurisdições com cooperação fraca em crimes cibernéticos, e o mercado evoluiu de empresas fixas para redes efêmeras de revenda, nas quais a infraestrutura real é contratada em provedores neutros e revendida em camadas que dificultam o rastreio. Categorias inteiras de ameaça dependem desse nicho: ransomware de primeira linha, botnets de distribuição de phishing e fóruns de vazamento convivem nesses ASNs.
O sinal de inteligência mais produtivo aqui não é o IP individual, e sim o ASN e o intervalo. Autoridades financeiras internacionais sancionaram em julho de 2025 o provedor Aeza Group, associado à hospedagem de operações do ransomware BianLian, e listas públicas de ASNs com taxa de abuso anômala, mantidas por comunidades de filtragem, servem de enriquecimento. A ação analítica típica é tripla: registrar o ASN como contexto no observável, calibrar bloqueios para o domínio em vez do IP e usar a presença em bulletproof como fator de pontuação de risco em campanhas. A versão complementar do problema é o fast-flux, que gira registros A em janelas de minutos sobre um pool de hosts comprometidos; nesse cenário, o único indicador estável é o domínio e o nameserver.
5. Infraestrutura Compartilhada e Vizinhos Nocivos
A hospedagem compartilhada barata concentra em um único endereço, roteados pelo cabeçalho Host ou pelo SNI, dezenas a centenas de domínios de donos diferentes. Para o analista, esse modelo gera dois problemas simétricos. Na direção da atribuição, o IP não diz quase nada sobre o domínio, e declarar relação entre dois domínios porque compartilham o IP de uma hospedagem compartilhada é erro básico que desacredita o relatório. Na direção da reputação, um vizinho nocivo, como um site de phishing no mesmo servidor, arrasta a reputação do IP para baixo e contamina filtros, o que explica por que listas de bloqueio publicam reputação por domínio e por IP em separado.
A mesma lógica vale para nuvens públicas de VPS, embora em grau diferente: a densidade de vizinhança por IP é menor, mas a rotação é muito maior, e o atacante conta com a presunção de legitimidade que o provedor carrega. A disciplina que resolve os dois cenários é a mesma: enriquecer todo IP com ASN, com histórico de DNS passivo e com o conjunto de nomes que já resolveram para ele, e só então decidir se a co-residência é sinal de dono comum ou acidente de mercado.
Os efeitos concretos da vizinhança nociva aparecem em três registros que o analista deve conhecer.
- Listas de reputação por IP: quando um vizinho entra em lista de spam ou phishing, todo o endereço sofre, e serviços de e-mail passam a rejeitar mensagens de outros inquilinos do mesmo servidor.
- Contaminação por comprometimento: em hospedagem compartilhada, um site comprometido no mesmo host serve de base para o adversário alcançar os outros domínios do mesmo plano, o caso clássico de reinfecção recorrente em CMS desatualizado.
- Co-residência acidental em inteligência: dois domínios corporativos sem relação compartilham o IP e produzem correlações espúrias em grafo mal construído; o histórico de DNS passivo com janela de tempo é o que separa vizinhança simultânea de vizinhança sucessiva.
6. Técnicas de Diferenciação: Descobrir o Host Atrás do Endereço
Diferenciar o que vive no mesmo endereço é a habilidade prática central desta nota. As técnicas abaixo vão da mais barata à mais custosa, e o resultado útil costuma sair da combinação de três ou mais delas.
- Resolução reversa e DNS passivo: o registro PTR e o histórico de nomes que já resolveram para o IP revelam a intenção de configuração do operador; um endereço de hospedagem genérica tem PTR padrão do provedor, e um servidor dedicado a uma campanha costuma ter PTR coeso com os domínios.
- SNI e cabeçalho Host: conectar no IP com SNI e Host de cada domínio candidato devolve respostas distintas por virtual host; a diferença de certificado apresentado por SNI é o diferenciador mais confiável em HTTPS.
- Certificado TLS por SNI: coletar o certificado para cada nome suspeito no mesmo IP separa virtual hosts com precisão, porque o certificado é configurado por nome e revela o SAN completo de cada operador.
- Fingerprint de serviço HTTP: cabeçalhos de servidor, ordem de cabeçalhos, página de erro e favicon hash diferenciam aplicações distintas atrás do mesmo IP e alimentam o pivô de template descrito na nota de Pivoting.
- Portas e serviços não padrão: varredura autorizada de portas altas frequentemente encontra painéis de administração do adversário no mesmo host, porque C2 e painéis raramente usam só a 443.
A sequência de comandos abaixo executa o núcleo dessa diferenciação em um IP suspeito sob o qual três domínios da campanha resolvem.
# 1) Contexto de rede: ASN e organizacao do IP
whois -h whois.cymru.com " -v 203.0.113.77"
# 2) PTR e historico de nomes associados (DNS passivo)
dig +short -x 203.0.113.77
# 3) Diferenciacao por SNI: o certificado muda conforme o nome pedido
for host in portal-seguro.com.br login-empresa.net atendimento-sac.io; do
echo "== $host =="
echo | openssl s_client -connect 203.0.113.77:443 -servername "$host" 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName | head -n 4
done
# 4) Diferenciacao por Host em HTTP puro, quando existir servico na porta 80
curl -s -I -H "Host: portal-seguro.com.br" http://203.0.113.77/ | head -n 8
A leitura do resultado segue a lógica dos pivôs: certificados idênticos com SANs que se cruzam sugerem dono comum; certificados distintos com fingerprints HTTP iguais sugerem template compartilhado; respostas completamente independentes em cada SNI sugerem apenas co-residência acidental de hospedagem. Essa decisão é registrada no grafo com nível de confiança, como detalha a nota de Pivoting.
A tabela abaixo resume a robustez de cada técnica de diferenciação e o custo operacional de executá-la, para orientar a ordem de aplicação em uma investigação com tempo curto.
| Técnica | Robustez como pivô | Custo e risco | Observação |
|---|---|---|---|
| PTR e DNS passivo | Média | Baixo, consulta externa passiva | PTR pode ser padrão de provedor e dizer pouco |
| Certificado por SNI | Alta | Baixo, uma conexão TLS por nome | Exige conhecer os nomes candidatos |
| Fingerprint HTTP e favicon | Média a alta | Baixo, requisições normais | Favicon hash costuma atravessar troca de domínio |
| Varredura de portas | Média | Alto, ativa e detectável | Restringir a cenários com autorização clara |
| Histórico de WHOIS do IP | Média | Baixo | Pouco útil em nuvem com rotatividade alta |
7. Exemplo Analítico Encadeado
Considere o domínio de phishing saca-rembolso.com.br resolvido para 198.51.100.207. O whois de rede informa ASN de uma CDN, e a conexão direta devolve a edge da CDN, sem conteúdo relevante. O analista consulta o histórico de DNS passivo e observa que o domínio já resolveu, na semana do registro, para 203.0.113.77, um VPS que ainda responde. Nesse VPS, a coleta de certificado por SNI revela o mesmo endereço de chave pública em mais três domínios recém-registrados com marcas de bancos brasileiros, e o fingerprint HTTP mostra o mesmo template de phishing.
A cadeia fechou porque cada etapa trocou a pergunta certa: a CDN obrigou a busca pela origem, a origem permitiu a comparação por certificado, e o certificado permitiu o agrupamento. O produto final para os blocos de bloqueio são os quatro domínios e o fingerprint do template, e não os IPs da CDN nem, isoladamente, o IP do VPS, que pode ser trocado na madrugada seguinte. A reputação do ASN, se ele pertencer a um provedor tolerante, entra como contexto de priorização no relatório.
8. Erros Comuns e Pontos de Atenção
- Bloquear por IP de CDN: o bloqueio derruba milhares de sites legítimos e é revertido em horas; bloqueie por domínio, por SNI ou por regra de WAF.
- Pivô de IP sem checar o tipo de hospedagem: em compartilhada e em CDN a co-residência é acidente de mercado; confirme o modelo de infraestrutura antes de declarar relação.
- Confundir origem com edge: conteúdo obtido na edge reflete configuração da CDN, e a origem pode estar em outro país e em outro ASN; registre os dois planos separadamente.
- Ignorar a rotação: IP de VPS observado hoje pode não existir amanhã; indicadores de nuvem precisam de carimbo de tempo e de revalidação em cadência curta.
- Generalizar bulletproof: nem todo provedor tolerante hospeda ameaça, e a lista de ASNs envelhece; use como fator de risco, nunca como evidência de atribuição.
- Desconsiderar o fast-flux: quando o TTL do registro A é baixo e os IPs giram em pool, o pivô por IP colapsa e o domínio passa a ser o único indicador estável.
- Fechar o caso na edge: derrubar o perfil na CDN sem localizar a origem deixa o operador vivo; a origem, quando encontrada, sustenta contato com provedor e derrubada definitiva.
- Confundir reputação com evidência: taxa de abuso do ASN e nota de reputação são contexto de priorização; relatório de atribuição que cita nota de serviço comercial como prova técnica não sobrevive a revisão por pares.
- Ignorar o plano de servidorless: funções efêmeras atrás de plataformas de nuvem produzem IPs que duram minutos; nesse cenário, o indicador é o domínio da plataforma, o caminho da função e o fingerprint de resposta.
- Tratar o PTR como prova de dono: o registro PTR é configurável pelo próprio inquilino do IP, e adversários configuram PTR convincentes; use-o como pista de diferenciação, nunca como evidência isolada.
9. Integração com o Restante da Biblioteca
A classificação de hospedagem é pré-requisito para o catálogo de pivôs da nota de Pivoting e Correlação de Infraestrutura, porque a robustez de cada pivô depende do modelo de infraestrutura em que ele foi observado. A diferenciação por SNI e por certificado conecta esta nota à de Certificados TLS e Certificate Transparency, e a enumeração de domínios que apontam para cada endereço conecta à de Domínios e Subdomínios. No lado da ação, os bloqueios por domínio e as regras de WAF alinhadas a esta nota aparecem nos controles PRT.3 e INS.4 da seção 15, e a validação de reputação por ASN alimenta o enriquecimento do pipeline CTI.5.
A disciplina que esta nota deixa como herança operacional é o registro do plano de resolução: toda vez que um indicador de rede entra na base, o analista grava se o endereço observado é origem, edge de CDN ou host compartilhado, com ASN e carimbo de tempo. Essa metadata de cinco minutos é o que impede, meses depois, que o grafo da organização trate acidentes de mercado como laços de atribuição.
Essa metadata também é o que torna o enriquecimento reversível. Quando um provedor remaneja intervalos de IP, o que era origem da campanha em março vira endereço de outro inquilino em junho, e o histórico de resolução é a única defesa contra a acusação injusta no relatório posterior. O hábito de registrar o plano de resolução, o ASN e a data de observação em cada indicador de rede é, na prática, a política de qualidade de dados da análise de infraestrutura, e prepara o terreno para a nota de Pivoting, na qual cada aresta do grafo precisa carregar a fonte e a janela de tempo que a sustentam.