Segurança de Sites: Como os Sites São Hackeados e Como Impedir Isso

Por que até sites pequenos são atacados

Vamos começar com a crença que ouvimos em quase toda primeira reunião: "Quem se importaria conosco? Temos cinco páginas e recebemos três consultas por semana." Parece razoável. É também exatamente por isso que sites assim são comprometidos com mais frequência.

Ninguém escolheu você. A grande maioria dos ataques contra pequenas e médias empresas não é pessoal. O software faz o trabalho: ele pega listas de domínios e endereços IP, percorre um por um e testa cada um por dezenas de vulnerabilidades conhecidas. O bot não tem ideia se você é uma clínica dentária ou um estúdio de cerâmica. Ele lê uma string de versão na resposta do servidor, verifica sua lista e avança se não houver correspondência. Se houver uma correspondência, ele começa a trabalhar.

É o equivalente a andar por uma rua puxando as maçanetas dos carros. Ninguém escolheu seu carro. O seu estava apenas destrancado.

Quanto Vale Mesmo um Site de Brochura

Um atacante quase nunca quer machucar você especificamente. Um site comprometido tem um valor de mercado, e isso vem de várias coisas ao mesmo tempo:

• Equidade de links. Links ocultos ou seções inteiras ocultas sobre cassinos, empréstimos ou farmácias são silenciosamente injetados em suas páginas. Você não os vê. Os motores de busca veem.
• Tráfego. Seus visitantes são redirecionados para outro lugar — mas nem todos. Muitas vezes, apenas usuários móveis, apenas aqueles que chegam da busca, e apenas uma vez por dia por pessoa. É exatamente por isso que você pode visitar seu próprio site do seu próprio laptop por meses e não notar nada.
• Recursos do servidor. Seu hospedagem se torna um nó para enviar spam, minerar ou atacar outros sites.
• Dados. Um banco de dados de consultas, números de telefone, endereços e e-mails é um produto com compradores. Mesmo que tudo o que você tenha seja "apenas um formulário de contato".
• Extorsão. Arquivos são criptografados ou deletados, e você é convidado a pagar pelo retorno deles.

O que leva à conclusão que muda como todo esse tópico é percebido: a segurança do site não é sobre se defender contra um gênio de capuz. É higiene que o move para fora da piscina de alvos fáceis. Um bot não gastará tempo em um site bem mantido enquanto mil negligenciados estão ao lado.

Como os proprietários geralmente descobrem

Os sintomas quase nunca vêm de você. Seu host envia um e-mail sobre atividade suspeita. O Google Search Console sinaliza um aviso. Um cliente liga para dizer que seu navegador está gritando com ele. O e-mail da empresa de repente vai parar na pasta de spam de todos. O tráfego de busca cai sem explicação. Se alguma dessas coisas aconteceu, você descobriu tarde — mas tarde não é o mesmo que tarde demais.

Como os sites realmente são comprometidos

Esqueça os filmes. Na realidade, quase toda a violação de pequenas empresas remonta a uma lista curta e notavelmente entediante. Limpamos dezenas de sites infectados, e o ponto de entrada quase sempre foi um desses.

CMS desatualizado e Plugins Acima de Tudo

Este é o vencedor absoluto. WordPress, Joomla, OpenCart — as plataformas em si não são inerentemente vulneráveis. O ecossistema é o problema: um plugin de galeria atualizado pela última vez em 2021, um tema comprado em um marketplace cujo autor se afastou há anos, um módulo de formulário que um contratado instalou e esqueceu.

Entenda a mecânica aqui, porque elas são contra-intuitivas. Quando uma vulnerabilidade é encontrada em um plugin, ela é publicada. É assim que a indústria funciona, e está correto. Mas a partir desse momento, uma corrida começa: o desenvolvedor envia uma correção, e bots de escaneamento recebem a impressão digital da versão vulnerável em poucas horas. Um site que atualiza uma vez por ano não está nessa corrida de forma alguma.

Senhas fracas, e muito pior, reutilizadas

Uma senha como Admin2024! parece forte — letra maiúscula, dígitos, um ponto de exclamação. Está em todos os dicionários de quebra. Mas esse não é o verdadeiro dano. O verdadeiro dano é a mesma senha no seu painel de hospedagem, no seu admin do site, no seu e-mail, e em algum serviço que foi violado há dois anos. O vazamento de outra pessoa se torna seu login, e tecnicamente nenhum "hacking" acontece. O atacante simplesmente digita um nome de usuário e uma senha.

Credenciais Roubadas de um Laptop de Funcionário

O clássico que ninguém suspeita. Credenciais FTP salvas em um gerenciador de arquivos no laptop de um designer são lidas por malware comum. O site é "hackeado" através de um login legítimo. O sinal revelador: você limpa tudo minuciosamente e a infecção volta em dois dias.

Formulários Desprotegidos e Endpoints Abertos

Todo lugar onde seu site aceita entrada externa — um formulário de contato, busca no site, upload de arquivo, um endpoint de API — é uma porta. Quando a entrada é aceita sem verificar seu tipo, tamanho e conteúdo, a porta funciona em ambas as direções. O upload de arquivos merece um medo especial: permitir que alguém coloque algo em seu servidor que o servidor depois executa é essencialmente entregar as chaves.

Arquivos Deixados no Raiz da Web

O assassino silencioso, e o encontramos constantemente. Vivendo na pasta pública: backup.zip da agência anterior, dump.sql com o banco de dados completo, um .git pasta contendo todo o histórico do projeto com senhas em commits antigos, um test.php, um info.php, uma cópia de configuração chamada config.php.bak. Cada um desses é baixável por qualquer um que adivinhe a URL. E bots não adivinham — eles carregam listas dos nomes usuais e os verificam em segundos.

Uma palavra especificamente sobre .bak e .antigo extensões: o servidor não executa isso como código, ele serve como texto simples. Isso significa que entrega sua senha de banco de dados diretamente ao navegador.

Projetos Esquecidos e Abandonados

Uma antiga página de campanha em um subdomínio. Uma cópia de teste criada há dois anos e nunca removida. Um fórum que ninguém usa. Elas nunca são atualizadas porque ninguém se lembra que existem. E geralmente ficam na mesma conta de hospedagem — então comprometer uma página de destino esquecida entrega os arquivos do seu site principal. Abrimos cada auditoria com "o que mais vive nesta conta?", e a resposta regularmente surpreende o proprietário mais do que qualquer um.

HTTPS e SSL: Não é mais um debate

Se você não tem HTTPS, pare de ler e conserte isso primeiro. Em 2026, um site sem criptografia não é economia. É uma falha.

O Que Um Certificado SSL Realmente Faz

Sem HTTPS, os dados viajam entre o navegador do seu visitante e seu servidor em texto simples. Qualquer um posicionado ao longo desse caminho pode lê-los e alterá-los: o proprietário do Wi-Fi do café, um ISP, equipamentos em uma rede intermediária. Lê-los significa ler senhas e conteúdos de formulários. Alterá-los significa que eles podem reescrever sua página ou injetar seus próprios anúncios nela, e seu visitante ficará certo de que veio de você.

Um certificado SSL resolve dois problemas de uma vez. Ele criptografa o canal e prova que o domínio pertence a quem o está servindo. O segundo é tão importante quanto o primeiro: sem identidade, a criptografia é inútil, porque você pode estar criptografando um canal para um fraudador.

Os Detalhes Que Importam Mais Do Que o Certificado Em Si

Os certificados são gratuitos e automáticos agora — Let's Encrypt resolveu essa questão para todos. Portanto, os erros não são mais sobre "ter um ou não". Eles estão na configuração:

• Redirecionamentos. Cada solicitação HTTP deve redirecionar permanentemente para HTTPS. Caso contrário, a versão antiga simplesmente continua funcionando ao lado da nova.
• Conteúdo misto. A página carrega via HTTPS, mas puxa uma imagem, fonte ou script via HTTP. O navegador reclama e o cadeado desaparece. Trechos antigos de análises e widgets de terceiros são os culpados habituais.
• Renovação automática. Os certificados têm vida curta e são renovados por um robô. Quando o robô falha, você ouvirá sobre isso de clientes no pior dia possível. Monitore a data de expiração.
• URLs canônicas. Após mudar para HTTPS, certifique-se de que cada página tenha um endereço em vez de quatro variações com e sem www.

O que o HTTPS não faz

Aqui vive uma concepção errônea perigosa. O cadeado não significa que o site é seguro. Significa exatamente uma coisa: o canal para o servidor está criptografado. Um site comprometido cheio de código malicioso funciona felizmente sobre HTTPS com o cadeado intacto. Sites de phishing também têm certificados — eles são emitidos gratuitamente e automaticamente para todos. O HTTPS é uma fundação, não um telhado.

Para sites que lidam com dinheiro, a barra é muito mais alta. A criptografia do canal é o ingresso de entrada; depois disso vêm a verificação de assinatura de webhook, operações idempotentes e separação rigorosa de acesso. Nós passamos por essa maquinaria em detalhes usando o gateway de pagamento Payora, onde a segurança da transação supera todos os outros recursos na construção.

Cabeçalhos de Segurança: A Defesa Silenciosa Que Ninguém Ativa

Os cabeçalhos de segurança são instruções que seu servidor envia ao navegador junto com a página. O ponto é que os navegadores são confiáveis por padrão: eles executarão qualquer script que encontrarem em sua página e exibirão sua página dentro da janela de outra pessoa, se solicitado. Os cabeçalhos são como você diz ao navegador: "não faça isso comigo."

Sua grande virtude é que são gratuitos, configurados uma vez e aplicados do lado do visitante sem sobrecarregar seu servidor. Seu grande problema é que estão ausentes por padrão em quase todos os lugares.

Content-Security-Policy (CSP)

O mais poderoso e o mais temperamental. É uma lista de permissões: onde esta página pode carregar scripts, estilos, imagens e fontes. Se um atacante conseguir injetar um script estrangeiro em sua página, o navegador simplesmente se recusa a executá-lo, porque a fonte não está na lista. Na prática, o CSP transforma uma comprometimento bem-sucedido em um fracasso.

Um aviso honesto: apressar o CSP quebrará seu site. O caminho certo é primeiro o modo apenas de relatório, coletar as violações e depois apertar. Em um site com uma dúzia de widgets de terceiros, isso é vários dias de trabalho, não dez minutos.

Strict-Transport-Security (HSTS)

Diz ao navegador: este domínio é apenas HTTPS, lembre-se disso por um ano. Ele fecha a lacuna entre alguém digitando um endereço sem um prefixo e o redirecionamento sendo acionado. Essa lacuna é precisamente onde a interceptação acontece. Ative-o apenas quando estiver confiante de que o HTTPS funciona em todos os lugares e permanentemente — reverter a decisão é lento.

X-Frame-Options

Impede que seu site seja incorporado em um quadro na página de outra pessoa. Defende contra um truque simples e desagradável: uma camada invisível colocada sobre seu verdadeiro botão, de modo que o clique do usuário vá para algum lugar que ele nunca pretendia. Para qualquer site com uma conta de cliente ou um checkout, este é obrigatório.

X-Content-Type-Options

Uma linha, sem configuração. Isso proíbe o navegador de adivinhar o tipo de um arquivo em relação ao que o servidor declarou. Sem isso, uma imagem carregada pode, sob as condições certas, ser interpretada como um script e executada.

Política de Referenciador

Controla quais informações sobre o seu site o navegador passa quando um visitante clica para sair. Sem isso, a URL completa da página — incluindo parâmetros como um token de redefinição de senha ou um identificador interno — vai para a análise de outra pessoa. Isso não é um hack. É um vazamento: silencioso e contínuo.

Política de Permissões

Desliga o que seu site claramente não precisa: câmera, microfone, geolocalização, sensores. A regra é simples — qualquer coisa não utilizada deve estar desligada.

Qualquer scanner online público avaliará seus cabeçalhos em um minuto, e o resultado geralmente é desanimador. Para nós, os cabeçalhos são parte da construção base de cada projeto — parte do desenvolvimento em si, não um extra pago adicionado depois.

Atualizações e Código de Terceiros: Disciplina Acima de Heroísmo

O conselho é chato: mantenha as coisas atualizadas. O problema é que é o único conselho que todos já ouviram e quase ninguém segue. Vamos ver por que — e como fazer isso funcionar.

Por que as Atualizações São Postergadas

Não é preguiça. É medo. Uma atualização uma vez quebrou o layout, ou o carrinho parou de funcionar, e o botão "atualizar" tem sido evitado desde então. O medo é racional: atualizações realmente podem quebrar coisas, especialmente quando um site é montado a partir de plugins que foram hackeados diretamente em seu código-fonte.

Mas faça as contas. O risco de um layout quebrado custa uma hora. O risco de uma violação custa uma restauração, uma limpeza, conversas constrangedoras com clientes e meses de recuperação de classificações de busca. O segundo risco é uma ordem de magnitude mais caro.

Como Atualizar Sem Pânico

1. Faça um backup antes, não depois. Backup completo: arquivos e banco de dados. Nunca pule esta etapa, sem exceções.
2. Mantenha uma cópia de teste. Um ambiente separado, fechado para motores de busca e estranhos, onde as atualizações são testadas antes de serem publicadas. Em qualquer projeto sério, isso não é opcional.
3. Separe o crítico do rotineiro. Atualizações de segurança vão imediatamente. As menores em um cronograma. Saltos de versão maiores são seu próprio projeto com um plano.
4. Verifique as coisas importantes depois. Envie um formulário, faça um pagamento, faça login em uma conta, veja em um telefone. Três minutos de verificação manual economizam semanas.

Auditoria do Código de Outras Pessoas

Uma vez por trimestre, abra sua lista de plugins e faça duas perguntas. Primeiro: isso é usado de alguma forma? Um plugin instalado "apenas por precaução" é um buraco sem função. E note que um plugin desativado ainda está no sistema de arquivos e pode ainda ser vulnerável — então coisas não utilizadas devem ser deletadas, não desligadas.

Segundo: o autor está vivo? Se a última atualização foi há três anos e a descrição diz que é compatível com uma versão que está há muito obsoleta, isso é código abandonado. Não ficará mais seguro por conta própria. Encontre um substituto com calma, com antecedência, em vez de na noite após um comprometimento.

E a regra que vale a pena emoldurar na parede: quanto menos código de terceiros em seu site, menor sua superfície de ataque. Cada plugin é um estranho a quem você concedeu silenciosamente acesso ao seu servidor.

Higiene de Acesso e Hospedagem: Vitórias Maiores Que Código

A causa mais comum de um comprometimento no mundo real não é uma exploração inteligente. É o acesso disperso. É também onde a ordem é restaurada mais rapidamente e por quase nenhum custo.

Menor Privilégio

Cada pessoa e cada processo deve ter exatamente os direitos que seu trabalho exige e não um pouco mais. Um gerente de conteúdo não precisa de direitos de administrador; ele precisa publicar artigos. Um contratado que edita uma página não precisa do banco de dados. Um script que lê um catálogo não precisa de acesso de gravação.

Abra sua lista de usuários administradores agora mesmo. Em auditorias, encontramos rotineiramente contas ativas pertencentes a pessoas que saíram, uma agência com a qual você se separou há um ano, e um usuário misterioso chamado admin2 que ninguém consegue explicar. Esse último não é um descuido — é um sintoma.

Uma Conta Por Pessoa

Um login compartilhado de admin com a senha em um thread de chat significa que ninguém é responsável. Quando algo acontece, o log diz "admin logado", o que não diz nada. Contas individuais lhe oferecem duas coisas: um histórico legível de quem fez o quê, e a capacidade de revogar o acesso de uma pessoa sem mudar as senhas de toda a empresa.

Autenticação de Dois Fatores

Se você implementar exatamente um item de todo este artigo, que seja este. A 2FA torna uma senha roubada inútil. Cada tentativa de força bruta e cada violação de terceiros para de funcionar contra você, porque a senha sozinha não é mais suficiente. Ative em todos os lugares onde existe: painel de hospedagem, registrador de domínio, admin do site, e-mail, Cloudflare, GitHub.

Uma palavra especial sobre o registrador de domínio. É o ponto de falha mais subestimado em toda a pilha. Perder o controle do seu domínio é pior do que perder seu site: um site é restaurado a partir do backup em uma hora, enquanto um domínio pode levar meses de tickets de suporte — se voltar.

Chaves SSH em vez de Senhas, e Sem FTP

Uma senha pode ser adivinhada ou retirada de um laptop. Uma chave não pode ser adivinhada em um prazo útil. A configuração leva quinze minutos uma vez, após o que o login por senha no servidor é desativado completamente.

Separadamente: abandone o FTP simples. Ele envia seu nome de usuário e senha em texto claro, como se fosse 1998. Use apenas SFTP ou SSH. Se seu host oferece FTP como o método principal, isso diz algo sobre o host.

Um Gerenciador de Senhas em vez de Memória

Nenhum humano consegue lembrar quarenta senhas complexas distintas, que é exatamente o motivo pelo qual as reutilizam. Um gerenciador de senhas elimina o problema completamente: ele gera uma senha única por serviço, as armazena criptografadas e permite que você entregue credenciais a um colega sem colá-las em um mensageiro. Custa uma quantia irrisória e previne uma catástrofe.

Formulários, Spam e Limitação de Taxa

O formulário de contato é a parte mais acessível do seu site. Está aberto a todos, funciona sem login e fica lá esperando por dados. Não é de se admirar que receba o maior abuso.

Por que CAPTCHA Não É a Resposta

CAPTCHA captura scripts primitivos e irrita humanos reais. O tráfego de spam moderno consegue passar por ele, seja tecnicamente ou através de serviços de resolução onde pessoas reais respondem captchas por frações de centavo. Enquanto isso, isso prejudica a conversão de forma mensurável: alguns clientes genuínos simplesmente desistem das letras distorcidas e saem.

A abordagem que funciona é em camadas e invisível para o visitante:

• Honeypot. Um campo oculto que um humano nunca vê ou preenche, e um bot preenche automaticamente. Preenchido significa descartado. Simples, gratuito, eficaz contra a maior parte.
• Verificações de tempo. Um formulário enviado meio segundo após o carregamento da página não foi preenchido por uma pessoa.
• Limitação de taxa. Não mais do que algumas submissões de um único endereço em uma determinada janela. Este é o mecanismo chave, e o mesmo protege sua página de login contra tentativas de adivinhação de senhas.
• Pontuação invisível. Sistemas modernos avaliam o comportamento e apenas desafiam solicitações que parecem suspeitas. Um cliente real não vê nada disso.

Validação do Lado do Servidor É Não Negociável

Validação elegante de campos no navegador é uma conveniência para os usuários, não uma defesa. Dados que chegam ao seu servidor podem ser enviados sem nunca tocar na sua página. Portanto, tudo é verificado novamente do lado do servidor: tipo, comprimento, formato, valores permitidos. A regra é simples e universal: entrada do mundo exterior nunca é confiável, mesmo que seu próprio script a tenha validado há um momento.

Uploads de Arquivos São Um Problema à Parte

Se um visitante pode fazer upload de um arquivo, comporte-se como se estivesse enviando algo hostil. Verifique o tipo de conteúdo real, não a extensão no nome. Renomeie o arquivo você mesmo. Limite o tamanho. E, mais importante, armazene os uploads em um lugar onde o servidor fisicamente não executará código — idealmente em um armazenamento separado completamente.

Limitação de Taxa Vai Além de Formulários

O mesmo mecanismo pertence aos seus endpoints de API, busca no site, redefinição de senha e qualquer operação cara. Sem isso, um bot persistente derruba seu servidor através da repetição pura. Isso é mais importante onde o dinheiro está envolvido: em projetos de pagamento, sempre limitamos a velocidade com que as transações podem ser criadas — nossa peça sobre aceitação de pagamentos em cripto explica por que isso protege sua contabilidade tanto quanto seu servidor.

Backups: A Única Apólice de Seguro Que Sempre Compensa

Claramente: backups importam mais do que tudo neste artigo. Cada outra medida reduz a probabilidade de desastre. Backups decidem como o desastre termina — uma noite desagradável ou um negócio fechado.

A Regra 3-2-1

Um clássico inventado muito antes de nós e ainda imbatível:

• 3 cópias dos seus dados: a ativa e duas backups.
• 2 mídias ou plataformas diferentes — não coloque tudo em uma única cesta.
• 1 cópia fora do site, fisicamente e administrativamente separada do servidor.

Esse último ponto é onde a maioria das configurações colapsa. Um backup sentado no mesmo servidor, ou na mesma conta de hospedagem, não é um backup. Um invasor que entra o deleta primeiro — esse é um passo padrão, não um floreio. Ransomware o criptografa junto com tudo o mais. E se o host falhar, ele também falha.

Um Backup Não Testado Não É um Backup

Aqui está a parte que dói. Continuamos vendo a mesma cena: backups rodaram fielmente por dois anos, e no dia que importa, os arquivos se revelam corrompidos. Ou contêm arquivos, mas sem banco de dados. Ou o banco de dados está lá, mas a exportação estragou a codificação e o texto é pontos de interrogação. Ou o arquivo tem 40 kilobytes porque o script falhou na primeira pasta e o e-mail de erro foi para uma caixa de entrada que ninguém lê.

A conclusão: restaurações devem ser ensaiadas. Uma vez por trimestre, implemente uma cópia em um ambiente de teste e verifique-a. O site carrega? O banco de dados está lá? As imagens estão presentes? Os pedidos aparecem? É a única maneira de aprender a verdade sobre seus backups com antecedência, em vez de durante uma catástrofe.

Retenção Vence Frequência

Um backup diário com três dias de retenção é inútil contra uma infecção silenciosa. O código malicioso muitas vezes fica dormente por meses. Quando você o encontra, todas as três cópias já estão infectadas. Mantenha a profundidade: diário por duas semanas, semanal por alguns meses, mensal por um ano. O espaço em disco é incomparavelmente mais barato do que um site sem nada para restaurar.

O que Fazer Backup

Arquivos e banco de dados são óbvios. O que é esquecido é tudo o mais: configuração do servidor, regras do servidor web, trabalhos agendados, configurações de DNS, e-mail. Um bom parâmetro é a pergunta: "se a empresa de hospedagem desaparecesse amanhã, quanto tempo levaria para uma reconstrução completa em outro lugar?" Se você não tiver uma resposta, seu backup está incompleto.

Monitoramento e Logs: Veja Antes Que Seu Cliente Veja

Compromissos raramente são barulhentos. Muito mais frequentemente são silenciosos, e esse é o ponto: quanto mais tempo você não perceber, mais tempo o ativo gera dinheiro para quem o tomou. Portanto, o trabalho de monitoramento não é "pegar um hacker". É encurtar a lacuna entre o evento e você saber sobre ele.

O Conjunto Mínimo

• Monitoramento de uptime.Uma verificação de disponibilidade a cada minuto com um alerta. Serviços básicos são gratuitos e levam dez minutos para configurar.
• Monitoramento de integridade de arquivos.O sistema registra o estado dos seus arquivos e informa quando algo muda. Ninguém tocou no código, mas dois arquivos mudaram às 3 da manhã — isso é uma conversa.
• Expiração de SSL e domínio.Alertas com antecedência, não depois. Um renovação de domínio esquecida dói mais do que a maioria dos hacks.
• Google Search Console.Gratuito e obrigatório. Os motores de busca muitas vezes detectam uma infecção antes do proprietário, e eles dirão isso claramente na seção de segurança.
• Escaneamento externo de malware.Verificações regulares do exterior capturam o que apenas um visitante vê: redirecionamentos, scripts injetados, conteúdo trocado.

Logs: Entediante, e Onde a Verdade Mora

Os logs do servidor web registram cada solicitação ao seu site. Em um dia calmo, ninguém os quer. No dia de um incidente, eles são sua única fonte de fatos: quando, de onde, o que exatamente foi solicitado, e o que o servidor respondeu.

Duas coisas valem a pena fazer com antecedência, porque não podem ser feitas retroativamente. Primeiro, confirme que os logs estão realmente sendo escritos e mantidos por pelo menos um mês. Em muitas configurações, eles são truncados após 24 horas, e não há nada mais para investigar. Segundo, ative o registro de login de administrador — bem-sucedido e falhado. Um aumento nas falhas é a adivinhação de senha acontecendo ao vivo, e você pode responder antes que tenha sucesso.

O que Procurar

Você não precisa ser um analista para perceber o óbvio. Pedidos de arquivos que você não tem e nunca teve. Pedidos administrativos às 3 da manhã de um país onde você não emprega ninguém. Um endereço fazendo centenas de pedidos em um minuto. Um aumento de respostas de erro onde não havia nenhuma antes. Nenhum desses é prova por si só, mas cada um é um motivo para olhar mais de perto.

Incluímos monitoramento básico em cada projeto que apoiamos após o lançamento — exemplos desse trabalho estão em nosso portfólio. A lição não é glamourosa: um site que ninguém assiste eventualmente produzirá uma surpresa, e a surpresa sempre custa mais do que a vigilância.

WAF e CDN: O Que a Cloudflare Faz e Não Faz

Cloudflare e serviços semelhantes são uma camada genuinamente útil, que é exatamente o motivo pelo qual tanta mitologia os cerca. Vamos ser honestos sobre onde está o valor e onde a ilusão começa.

O que Eles São

Uma CDN coloca uma rede de nós em todo o mundo entre seu visitante e seu servidor. Arquivos estáticos são servidos do nó mais próximo — o site fica mais rápido e seu servidor é aliviado. Um WAF (firewall de aplicação web) é um filtro que inspeciona pedidos de entrada e descarta aqueles com formato de ataque antes que cheguem ao seu código.

O Verdadeiro Valor

• Absorvendo DDoS. Tráfego indesejado quebra na rede do provedor em vez de no seu servidor. Uma pequena empresa não sobreviverá a esse ataque sozinha.
• Escondendo seu IP real do servidor. Ataques diretos se tornam mais difíceis quando o alvo não é visível.
• Filtragem de bots. Uma grande parte do ruído de varredura é descartada automaticamente, e seus logs se tornam legíveis da noite para o dia.
• Patching virtual. Uma regra de WAF pode manter uma nova vulnerabilidade fechada enquanto você prepara uma atualização adequada. Isso é tempo emprestado, não uma solução.
• Velocidade. Um efeito colateral agradável que tanto visitantes quanto motores de busca notam.

O que Eles Não Farão

Agora a parte desconfortável. Um WAF não vai te salvar quando:

• Sua senha foi roubada. Um login com credenciais válidas é um pedido legítimo. O filtro o aprova, e está certo.
• Seu IP real já é conhecido e seu servidor aceita conexões diretamente, contornando o filtro. Esta é uma configuração incorreta extremamente comum: seu servidor deve aceitar tráfego apenas da rede do provedor.
• A falha está na sua própria lógica de negócios. Se seu código permite que um usuário busque o pedido de outro usuário mudando um número, isso é um pedido perfeitamente bem formado do ponto de vista do WAF.
• Código malicioso está já dentro. O filtro observa a porta da frente, não o que está acontecendo dentro da casa.
• A criptografia está configurada para "flexível". Então, o trecho do Cloudflare até seu servidor viaja em texto claro enquanto seu visitante vê um cadeado e assume que tudo está bem. Isso é uma imitação perigosa de segurança — use o modo estrito com validação de certificado.

Em resumo: um WAF e CDN são uma excelente cerca de perímetro. Uma cerca é inútil quando a chave está debaixo do tapete e uma janela do andar térreo está aberta. Ela complementa a higiene. Não a substitui.

O Que Fazer Se Você Já Estiver Comprometido

Mantenha a calma. O pânico custa mais do que o próprio hack: em um pânico, as pessoas deletam exatamente as coisas que uma investigação precisa. O procedimento está bem estabelecido. Siga-o.

1. Isolar

Coloque o site atrás de uma página de manutenção retornando um status 503. Isso protege os visitantes de infecções e informa aos motores de busca que a interrupção é temporária e não terminal. Não delete nada ainda.

2. Preserve a Evidência

Contraproducente, mas crítico. Faça uma cópia completa do site infectado mais o último mês de logs antesde qualquer limpeza. Se você restaurar a partir do backup sem identificar o ponto de entrada, você será comprometido novamente da mesma forma, geralmente dentro de uma semana. Essa cópia é sua única chance de entender como eles entraram.

3. Rode Todas as Credenciais

Todas elas, sem exceções, sem "aquela definitivamente não poderia ter vazado". Hospedagem, SSH, banco de dados, cada usuário administrador, FTP, registrador de domínio, e-mail, serviços conectados. Ative a 2FA em todos os lugares onde estava faltando enquanto você está lá. Um aviso que as pessoas perdem: faça isso de um computador limpo. Se o laptop estiver infectado, suas novas senhas vazarão exatamente como as antigas.

4. Encontre o Ponto de Entrada

Comece com arquivos modificados na data da infecção — a trilha mais rápida que existe. Pesquise os logs para ver qual solicitação chegou pouco antes do primeiro arquivo estrangeiro aparecer. Verifique tudo na conta de hospedagem, incluindo subdomínios esquecidos. Verifique os computadores de todos com acesso. Até que o ponto de entrada seja encontrado, o incidente não está fechado.

5. Reconstruir

A melhor rota é uma reinstalação limpa: CMS fresco, plugins frescos de fontes oficiais, e apenas seu conteúdo e banco de dados retirados do backup — com o banco de dados verificado primeiro, porque o código também é injetado lá, geralmente em templates e configurações. Limpar manualmente arquivos infectados é uma loteria: perca um único arquivo e tudo volta.

6. Feche o Buraco e Recupere Sua Reputação

Corrija a causa que você identificou, ou você simplesmente reiniciou o relógio. Então: solicite uma revisão no Google Search Console, verifique os registros de e-mail do seu domínio (um site comprometido provavelmente estava enviando spam, e seu domínio pode já estar em listas de bloqueio), e confirme que não há administradores desconhecidos restantes no banco de dados.

Uma nota honesta: se seu site aceita pagamentos ou armazena dados pessoais de clientes, improvisar é a escolha errada. Você quer alguém que já tenha feito isso antes — entre em contato. Nós lidamos com incidentes como esses, e mais importante, explicamos depois exatamente o que deu errado e como garantir que não ocorra novamente.

Uma Lista de Verificação de Segurança Prática

Vamos comprimir tudo o que foi dito acima em uma lista que você pode começar hoje. Está ordenada por efeito relativo ao esforço — comece pelo topo.

Hoje, em Uma Noite

1. Ative 2FA para hospedagem, seu registrador de domínio, e-mail e o administrador do site.
2. Verifique HTTPS funciona em todos os lugares e todos os redirecionamentos HTTP para ele.
3. Abra sua lista de usuários administradores e remova todos que não deveriam estar lá: ex-funcionários, antigos contratados, contas que ninguém reconhece.
4. Verifique a raiz da web por arquivos soltos: arquivos de backup, dumps de banco de dados, uma .git pasta, cópias de configuração, scripts de teste.
5. Confirme que os backups existem e não estão armazenados no mesmo servidor.
6. Conecte o site ao Google Search Console e leia a seção de segurança.

Esta Semana

1. Configure um gerenciador de senhas e substitua cada senha reutilizada por uma única.
2. Atualize o CMS e todos os plugins, após fazer um backup completo.
3. Exclua plugins e temas não utilizados — exclua, não desative.
4. Configure cabeçalhos de segurança: comece com X-Content-Type-Options, X-Frame-Options e Referrer-Policy, que são seguros para habilitar imediatamente.
5. Desative FTP e mude para chaves SSH.
6. Adicione monitoramento de uptime e alertas para expiração de SSL e domínio.
7. Limite a taxa de tentativas de login no painel de administração.

Este Mês

1. Teste uma restauração em um ambiente de teste — realmente implante e veja.
2. Coloque um CDN e WAF na frente, e feche o acesso direto ao servidor para que nada contorne o filtro.
3. Implemente CSP, começando no modo apenas de relatório.
4. Audite tudo na conta de hospedagem: subdomínios, cópias de teste, páginas de destino esquecidas. Exclua o que não é necessário.
5. Configure monitoramento de integridade de arquivos.
6. Revise permissões de arquivos e pastas, removendo o acesso de gravação sempre que não for necessário.

Em Repetição, Para Que Você Nunca Precise Deste Artigo Novamente

• Semanalmente: atualizações de segurança, uma olhada no log de login.
• Mensal:verifique backups, revise usuários, examine os logs.
• Trimestral:teste a restauração, audite plugins, gire senhas de chave.
• Anual:auditoria completa, reconsidere quem tem acesso e por quê.

Um último pensamento para levar com você. Segurança não é um estado que você alcança e esquece; é um hábito, como trancar a porta do escritório. Ninguém pode garantir proteção absoluta, e qualquer um que prometer isso está te enganando. Mas a diferença entre um site onde esta lista é cumprida e um site onde nada disso é feito é a diferença entre "alguém tentou e não conseguiu" e "estamos na terceira semana de recuperação de nossos dados".

FAQ