Como funciona esta verificação
O Scanaris pede nove nomes de ficheiro que as pessoas usam vezes sem conta para guardar cópias de segurança na raiz do site: backup.zip, backup.tar.gz, website.zip, www.zip, public_html.zip, site.zip, database.sql, dump.sql e db.sql. Para cada um confirma que a resposta é um ficheiro real e não a página genérica do teu site: olha para o tipo de conteúdo e, no caso dos despejos SQL, para se o texto parece SQL. Todos os achados são de severidade crítica, porque um ficheiro assim contém ou o código completo do site ou a base de dados inteira.
Porque importa
Um backup.zip acessível é o teu projeto completo: código, configuração, as chaves que houvesse nos ficheiros e, muitas vezes, uma cópia da base de dados lá dentro. Um dump.sql é a base de dados tal e qual: utilizadores, emails, palavras-passe cifradas (que se podem atacar sem pressa), encomendas, mensagens. Não é precisa nenhuma técnica: é um download. E os scanners automáticos testam exatamente estes nomes contra todos os domínios que encontram, por isso "ninguém conhece o URL" não é uma proteção.
Porque acontece
Por comodidade num mau momento: antes de uma migração ou de uma atualização comprime-se a pasta do site "por precaução" e deixa-se ali mesmo. Ou um plugin de cópias de segurança escreve numa pasta pública. Ou uma exportação da base de dados é guardada junto ao código para a passar a alguém. Num servidor que serve a raiz do projeto, qualquer ficheiro que caia ali é público no instante.
Como corrigir
- Apaga o ficheiro agora e age como se tivesse sido descarregado: roda todas as chaves e palavras-passe que continha e, se havia dados pessoais, pondera a obrigação de notificar.
- Move as cópias para fora do diretório público. As cópias de segurança vão para um armazenamento à parte (um bucket privado, outro servidor), nunca para uma pasta que o servidor web sirva.
- Configura a ferramenta de cópias para escrever fora da raiz web. Os plugins do WordPress costumam permitir escolher a pasta ou enviar para um serviço externo.
- Bloqueia as extensões no servidor como segunda barreira. Em nginx:
location ~* \.(zip|tar|gz|sql|bak)$ { deny all; }. Em Apache, umFilesMatchequivalente comRequire all denied. Se ofereces legitimamente downloads comprimidos, limita-os a uma pasta concreta. - Revê os registos de acesso à procura de pedidos com 200 a estes nomes: dir-te-ão se alguém chegou antes.
Confirma que está corrigido
for p in backup.zip backup.tar.gz website.zip www.zip public_html.zip site.zip database.sql dump.sql db.sql; do
printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://oteudominio.com/$p"
done
O esperado é 404 ou 403. Um 200 com text/html numa aplicação de página única é o seu HTML genérico; um 200 com application/zip, application/octet-stream ou text/plain é o ficheiro real.
Perguntas frequentes
A minha cópia tem um nome que ninguém adivinharia.
As ferramentas de ataque testam milhares de nomes e combinações com o domínio, a data e palavras como "old" ou "bak". Um nome raro reduz o risco mas não o elimina; a solução é que não esteja numa pasta pública.
E se o ficheiro estiver protegido com palavra-passe?
Um ZIP com palavra-passe descarrega-se na mesma e ataca-se sem limite de tentativas no computador do atacante. Continua a ser um achado crítico.
O check só olha para a raiz. E as subpastas?
Correto, estes nove nomes testam-se na raiz. As listagens de diretório abertas, que outro check mede, são a forma habitual de encontrar cópias em subpastas; fechá-las e bloquear as extensões cobre o resto.