Defaults.Exposed › Correções › CDN / WAF e alojamento

Como corrigir CDN / WAF e alojamento

Duas leituras da canalização por trás do seu site: se está protegido por um escudo (uma CDN com um Web Application Firewall, como a Cloudflare) que filtra ataques e absorve picos de tráfego, e um mapa de quem realmente gere o seu DNS, o seu site e o seu e-mail. Ambas são informativas na nossa pontuação — não movem a sua nota — mas descrevem quão exposto está o seu servidor de origem a ataques e falhas, e quão emaranhados estão os seus fornecedores. Um escudo à frente e um conjunto de fornecedores sensatamente repartido é o que os negócios resilientes parecem.

O essencial para o seu negócio: Um site sem escudo à frente recebe cada ataque e cada pico de tráfego diretamente no servidor de origem — por isso uma enxurrada de bots, uma onda no dia de lançamento ou um único ataque automatizado pode deitá-lo offline durante horas, e a recuperação é consigo. Pôr uma CDN/WAF à frente (há nível gratuito) filtra a esmagadora maioria dos ataques automatizados, absorve as ondas e acelera o site em todo o mundo — normalmente o trabalho de uma tarde para o seu responsável de TI, sem custo de licença. Separadamente, se o seu DNS, site e e-mail vivem todos com um só fornecedor, uma única falha ou violação aí deita toda a sua presença online abaixo de uma vez; conhecer o seu mapa de fornecedores é a primeira coisa de que precisa num incidente. Nenhuma verificação muda a sua nota — mas ambas descrevem exposição real a inatividade, vendas perdidas e uma recuperação lenta e dolorosa.

Quanto isto lhe pode custar

• Uma rajada de tráfego de bots ou um pequeno DDoS atinge o seu servidor sem escudo na manhã de uma grande promoção — o site rasteja ou cai, os clientes recebem erros no checkout e perde as vendas do dia enquanto o seu alojamento se atrapalha. Uma CDN/WAF à frente tê-lo-ia absorvido.
• O seu DNS, site e e-mail correm todos por um só fornecedor; esse fornecedor tem uma falha e o seu site, o seu sistema de marcações E o seu e-mail apagam-se todos no mesmo instante — nem sequer consegue enviar «estamos cientes do problema» porque a caixa de correio também está em baixo.
• Um ataque automatizado sonda o seu site toda a noite — scripts de injeção de SQL e de adivinhação de inícios de sessão a martelar a sua origem diretamente porque não há camada de firewall para os filtrar — e só fica a saber quando algo parte. Um WAF bloqueia o grosso desse ruído antes de chegar ao seu código.
• Um incidente atinge-o e ninguém consegue responder à pergunta básica «a quem ligamos sequer?» — o site está no mesmo alojamento que o e-mail? Quem gere o DNS? As horas escoam-se só a mapear a canalização enquanto o site continua em baixo.
• A equipa de TI de um potencial cliente analisa-o antes de assinar e vê um servidor de origem nu, sem CDN/WAF, e um cabeçalho de versão de servidor a anunciar exatamente que software (e versão) corre — um pequeno sinal de «esta gente não endureceu o básico» no pior momento possível.

Por que importa. Ambas as verificações aqui são informativas na nossa metodologia — estão registadas com zero pontos e nunca mudam a sua nota — porque descrevem a sua infraestrutura em vez de testarem um controlo de segurança aprovado/reprovado. Trazemo-las à tona porque mapeiam exposição real do negócio. Um site sem CDN/WAF recebe cada ataque e pico de tráfego na origem diretamente, sem filtragem e sem absorção de ondas; adicionar uma (o nível gratuito da Cloudflare é o caminho comum) é uma das melhorias de resiliência de maior alavancagem e menor custo que uma pequena empresa pode fazer. E um mapa de fornecedores claro — saber se o seu DNS, web e e-mail estão repartidos ou empilhados num só fornecedor — é a primeira coisa de que precisa quando algo corre mal e a diferença entre um incidente contido e um apagão total.

O que é isto, em palavras simples

Todos os sites correm num servidor algalgures. A pergunta que esta página responde é: o que está entre a internet aberta e esse servidor — e quem gere, de facto, as peças da sua presença online?

Há duas partes:

1. CDN / WAF — o escudo à frente. Uma CDN (Content Delivery Network) é uma rede global que fica à frente do seu site, serve o seu conteúdo depressa a visitantes em qualquer lado e absorve ondas de tráfego. Um WAF (Web Application Firewall) é um filtro que inspeciona os pedidos recebidos e bloqueia os maliciosos antes de chegarem ao seu servidor. Os serviços populares (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri e outros) juntam-nos. Olhamos para as respostas do seu site e reportamos se conseguimos ver um escudo à frente — e notamos também que servidor web corre.

2. Mapa de alojamento / fornecedores — quem gere a sua canalização. Lemos os registos públicos que dizem quem trata do seu DNS (o diretório que transforma o seu domínio num endereço) e quem trata do seu e-mail. A partir disso conseguimos dizer se o seu DNS, site e e-mail estão repartidos por fornecedores (resiliente) ou empilhados num só (conveniente, mas um ponto único de falha).

O mais importante a saber à partida: na nossa pontuação, ambas são informativas. Não afetam a sua nota. Trazemo-las à tona porque descrevem quão exposto está o seu negócio a inatividade e ataques — que é uma pergunta diferente, e muito prática, em relação à nota.

O que isto lhe pode custar

Não são riscos abstratos — são as formas do dia a dia em que uma configuração sem escudo e emaranhada transforma um pequeno problema num mau dia.

• Deitado offline no dia que mais importa. O seu site fica no servidor de origem sem nada à frente. Na manhã de um lançamento ou de uma promoção, o tráfego dispara — ou atinge-o uma modesta enxurrada de bots — e o servidor não aguenta. As páginas expiram, o checkout dá erro e perde a receita do dia enquanto o seu alojamento apaga incêndios. Uma CDN absorve as ondas e um WAF filtra o tráfego-lixo; juntos são a diferença entre «dia movimentado» e «em baixo toda a manhã».

• Tudo se apaga de uma vez. O seu DNS, site e e-mail correm todos por um só fornecedor. Esse fornecedor tem uma falha (acontece a todos eles, eventualmente) e o seu site, o seu sistema de marcações e o seu e-mail desaparecem em simultâneo. Não consegue processar encomendas e nem sequer consegue enviar e-mail aos clientes a dizer que está ciente — porque a caixa de correio também está em baixo. Repartir os fornecedores significa que uma falha fica contida, não total.

• O seu código recebe cada ataque diretamente. Sem WAF, cada sonda automatizada — tentativas de injeção, adivinhação de inícios de sessão, analisadores de exploração conhecidos — atinge o código da sua aplicação sem filtragem. Está a apostar que o seu software é impecável e está totalmente corrigido, para sempre. Um WAF bloqueia a esmagadora maioria desse ruído automatizado antes de o alcançar, transformando «ataque de fundo constante» em «maioritariamente filtrado».

• Um incidente lento e em pânico porque ninguém tem o mapa. Algo parte e a primeira hora desperdiça-se em «espera, quem gere o nosso DNS? O e-mail está no mesmo alojamento? A quem ligamos?» Quando o seu mapa de fornecedores não é claro, cada incidente começa do zero. Conhecer o mapa à partida transforma uma correria num telefonema.

• Uma má primeira impressão para um comprador cuidadoso. A equipa de TI de um potencial cliente analisa-o antes de assinar e vê uma origem nua sem CDN/WAF — e um cabeçalho de servidor a anunciar abertamente o seu software exato e a sua versão. É um sinal pequeno, mas coloca-o na coluna «não endureceram o básico» exatamente no momento errado.

O que isto é, na realidade

CDN / WAF — a camada protetora

Quando um visitante (ou um atacante) pede o seu site, o pedido ou vai diretamente para o seu servidor de origem, ou pode ir primeiro por uma CDN/WAF. Se houver um escudo à frente, esse escudo pode:

• Filtrar pedidos maliciosos (a parte WAF): bloquear tentativas de injeção, ataques de bots e padrões de exploração conhecidos antes de chegarem ao seu código.
• Absorver tráfego (a parte CDN): servir conteúdo em cache de servidores perto de cada visitante e absorver ondas, para que um pico — legítimo ou hostil — não esmague a sua origem.
• Acelerar o site: o conteúdo entregue de um servidor de borda próximo carrega mais depressa para visitantes em todo o mundo.

Detetamos um escudo olhando para as impressões digitais que estes serviços deixam nos cabeçalhos de resposta do seu site — por exemplo, um cabeçalho cf-ray (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai) ou x-sucuri-id (Sucuri). Lemos também o cabeçalho Server para identificar o servidor web subjacente (nginx, Apache, IIS, LiteSpeed, Caddy, e por aí fora) e assinalamos qualquer cabeçalho X-Powered-By que esteja a partilhar a mais.

O que é «bom»: uma CDN/WAF detetada à frente da sua origem e um cabeçalho Server que não anuncia um número de versão específico.

Mapa de alojamento / fornecedores — as suas dependências de infraestrutura

O seu domínio aponta discretamente para vários serviços diferentes:

• DNS — o diretório que transforma aseuaempresa.com no endereço real do servidor. Lemos os seus registos de nameserver (NS) e reconhecemos fornecedores comuns (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode e registrars regionais, entre eles).
• E-mail — onde o seu correio é tratado. Lemos os seus registos MX e reconhecemos fornecedores comuns (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho e outros).

A partir disto conseguimos ver se estas responsabilidades estão repartidas por fornecedores (uma falha num não deita os outros abaixo) ou empilhadas num só fornecedor (conveniente, mas uma falha leva tudo).

O que é «bom»: no mínimo, o DNS num fornecedor dedicado e fiável em vez de agrupado na mesma conta de tudo o resto — para que o diretório do seu domínio não partilhe o destino do seu site e da sua caixa de entrada.

Como corrigir (gratuito, ~1 tarde)

Entregue isto ao seu responsável de TI ou programador web — a correção é gratuita. Pôr uma CDN/WAF à frente do seu site não custa nada nos níveis gratuitos comuns, e suprimir a versão do seu servidor é uma definição de uma linha. Não há licença a comprar. (As opções pagas aqui são apenas monitorização, acompanhamento de carteira e auditorias — nunca a correção em si.) A única decisão do proprietário é: sim, pôr um escudo à frente do site.

Como ambas as verificações são informativas, nada disto é classificado — mas uma CDN/WAF é uma das melhorias de resiliência de maior valor que uma pequena empresa pode fazer, por isso vale a pena.

1. Pôr uma CDN/WAF à frente do seu site

O caminho mais comum e gratuito é a Cloudflare:

1. Crie uma conta Cloudflare gratuita e adicione o seu domínio.
2. A Cloudflare lê os seus registos de DNS existentes; verifique se importaram corretamente.
3. Mude os nameservers do seu domínio (no seu registrar) para os dois que a Cloudflare lhe der. É este o interrutor que encaminha o tráfego pela Cloudflare.
4. Defina o modo SSL/TLS como Full (strict) para que a cifragem se mantenha de ponta a ponta entre visitante → Cloudflare → a sua origem. (Evite «Flexible», que deixa o último troço sem cifrar.)
5. A CDN e um WAF de base estão agora ativos. Pode afinar as regras de WAF mais tarde, mas os valores por omissão já filtram muito.

Outros caminhos, conforme a sua pilha:

• AWS CloudFront — crie uma distribuição a apontar para a sua origem; emparelhe com o AWS WAF para filtragem. Melhor se já estiver na AWS.
• Sucuri WAF — baseado em DNS, não exige alterações no seu servidor; bom se não puder tocar na origem.
• Fastly / Akamai — CDNs/WAFs de nível empresarial, normalmente para sites maiores ou de maior tráfego.

Depois de mudar, teste o site, confirme que o HTTPS funciona em todo o lado e vigie-o por um dia. Não guarde em cache de forma agressiva páginas que devam manter-se pessoais ou ao vivo (áreas com sessão iniciada, carrinhos, checkouts).

2. Pare de anunciar a versão do seu servidor

Quer adicione uma CDN ou não, suprima a versão que o seu servidor anuncia — é informação gratuita que está a entregar aos atacantes.

Nginx:

server_tokens off;

Apache (na configuração principal):

ServerTokens Prod
ServerSignature Off

Remova um cabeçalho X-Powered-By que partilhe a mais (p. ex. do PHP ou de uma framework de aplicação) ao nível do servidor ou da CDN — na Cloudflare pode retirá-lo com uma regra de transformação de cabeçalho de resposta.

3. Verifique a sanidade do seu mapa de fornecedores (opcional, ~10 minutos)

Veja onde o seu DNS, site e e-mail realmente vivem:

• Se os três estiverem numa só conta de fornecedor, pondere pelo menos mover o DNS para um fornecedor dedicado (o DNS da Cloudflare é gratuito e rápido). Essa única repartição faz com que o diretório do seu domínio sobreviva a uma falha de alojamento.
• Escreva o mapa — fornecedor de DNS, alojamento web, fornecedor de e-mail, registrar, e o contacto de início de sessão/apoio de cada um. Esta única página é a coisa mais útil que pode ter à frente durante um incidente.

Notas por plataforma

• Google Workspace / Microsoft 365: estes são os seus fornecedores de e-mail, não o seu site. Pôr uma CDN/WAF à frente do site não toca no e-mail, e vice-versa — são decisões separadas. (Ter o e-mail no Google/Microsoft e o site por trás da Cloudflare é uma configuração perfeitamente boa e deliberadamente repartida.)
• Construtores de sites geridos (Wix, Squarespace, Shopify): estes incluem a sua própria CDN e um nível de proteção WAF como parte da plataforma, por isso pode já estar protegido mesmo que a nossa verificação de cabeçalhos não nomeie um fornecedor. Normalmente não consegue adicionar a sua própria Cloudflare à frente; tudo bem — a plataforma trata disso.
• WordPress no seu próprio alojamento: candidato ideal para uma camada gratuita da Cloudflare à frente. Combine-a com a firewall de um plugin de segurança para regras ao nível da aplicação.

Erros comuns

• Correr uma origem nua «porque o site é pequeno». Os sites pequenos são atingidos pelos mesmos ataques automatizados e enxurradas de bots que os grandes — os bots não verificam primeiro a sua receita. O nível gratuito de CDN/WAF existe precisamente para sites pequenos; não o usar é deixar uma vitória fácil em cima da mesa.
• Usar o SSL «Flexible» da Cloudflare. Mostra um cadeado mas deixa a ligação entre a Cloudflare e a sua origem sem cifrar. Use sempre Full (strict) para que esteja cifrada de ponta a ponta.
• Guardar em cache as coisas erradas. Guardar em cache de forma agressiva páginas com sessão iniciada, carrinhos ou checkouts pode mostrar a um cliente o conteúdo de outro ou preços obsoletos. Guarde em cache o conteúdo estático; deixe as páginas personalizadas e transacionais sem cache.
• Empilhar tudo num só fornecedor sem se aperceber. A conveniência está bem se for uma escolha consciente — mas muitas empresas só descobrem que o DNS, web e e-mail partilham uma conta durante a falha que os deita aos três abaixo. Faça disso uma decisão, não uma descoberta.
• Deixar a versão do servidor à mostra. É um passo de endurecimento gratuito e de uma linha, fácil de esquecer. Desligue-o.

Uma nota sobre a nota

Para ser completamente claro: nenhuma destas verificações afeta a sua nota. Estão registadas na nossa metodologia como informativas, com zero pontos, e nunca o penalizamos por uma origem sem escudo ou por uma configuração de fornecedor único. Reportamo-las porque descrevem exposição real a inatividade, ataque e recuperação lenta de incidentes — e porque adicionar uma CDN/WAF gratuita é uma das melhorias de melhor valor que uma pequena empresa pode fazer. Se não fizer nada aqui, a sua nota fica inalterada. Se puser um escudo à frente do site e repartir o seu DNS, tornou o negócio significativamente mais resiliente de graça. É essa a forma certa de ler esta página: não um número a defender, mas uma melhoria de resiliência que vale a pena adotar.

Perguntas frequentes