Como Detetar e Bloquear Tentativas de Acesso a Ficheiros de Backup
Introdução
Recentemente, durante a análise rotineira dos logs do servidor, deparei-me com uma entrada que ilustra perfeitamente um dos vetores de ataque mais comuns (e perigosos) na web:
a tentativa de acesso a ficheiros de backup.
Neste artigo, vou analisar em detalhe esta tentativa de ataque, explicar porque representa um risco crítico de segurança e mostrar como podemos implementar mecanismos de deteção com Wazuh e proteção com ModSecurity.
A Entrada de Log Maliciosa
Vamos começar por examinar a entrada que acionou os nossos alertas de segurança:
xxx.xxx.xxx.xxx - - [27/Jan/2026:11:13:10 +0000] "GET /wwwroot.bak HTTP/1.1" 404 98749 "https://xxx-xxx.com/wwwroot.bak" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.201 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
À primeira vista, pode parecer apenas mais uma entrada num oceano de logs.
No entanto, uma análise cuidadosa revela várias red flags críticas que identificam esta como uma tentativa de ataque deliberada.
Análise Técnica: Porque é Malicioso?
1. O Alvo: Ficheiros de Backup Expostos
O elemento mais crítico desta tentativa de ataque é o caminho solicitado: /wwwroot.bak
Ficheiros de backup são um dos alvos mais apetecíveis para atacantes porque frequentemente contêm:
- Código-fonte completo da aplicação incluindo lógica de negócio sensível
- Credenciais hardcoded como passwords de bases de dados, chaves API e tokens de autenticação
- Informação sobre a estrutura da aplicação que facilita outros ataques
- Dados sensíveis que não deveriam estar acessíveis publicamente
- Vulnerabilidades conhecidas em versões antigas do código
Extensões comuns de ficheiros de backup que os atacantes procuram:
.bak, .backup, .old, .orig, .copy.zip, .tar.gz, .rar, .7z.sql, .sql.gz, .dump~, .swp, .tmp
2. User-Agent Spoofing: Disfarçado de Googlebot
Outro indicador claro de atividade maliciosa é o User-Agent utilizado:
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/124.0.6367.201 Mobile Safari/537.36
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)
O atacante está a tentar fazer-se passar pelo Googlebot, o crawler oficial do Google. Esta é uma técnica comum chamada User-Agent Spoofing com vários objetivos:
- Evitar bloqueios automáticos: Muitos sistemas confiam em User-Agents legítimos
- Contornar rate limiting: Bots de motores de busca geralmente têm limites mais elevados
- Reduzir suspeitas: Administradores podem ignorar pedidos aparentemente do Google
- Explorar whitelists: Alguns sistemas permitem acesso privilegiado a crawlers conhecidos
Como verificar se é realmente o Googlebot: O Googlebot legítimo faz reverse DNS lookup para googlebot.com ou google.com. Pedidos do IP xxx.xxx.xxx.xxx nunca seriam do Google real.
3. Padrão de Reconhecimento Automatizado
Analisando o contexto mais amplo (embora não visível nesta entrada específica), este tipo de pedido faz parte de um scanning automatizado onde o atacante:
- Identifica websites potencialmente vulneráveis
- Testa múltiplos caminhos de ficheiros de backup comuns
- Procura por respostas que indiquem a existência de ficheiros (mesmo 403 Forbidden é útil)
- Faz download de qualquer ficheiro encontrado para análise offline
4. O Código 404: Será que Estamos Seguros?
Neste caso, o servidor respondeu com 404 Not Found, o que é positivo – o ficheiro não existe ou não está acessível.
No entanto, isto não significa que estamos completamente seguros:
- O atacante pode estar a testar centenas ou milhares de variações
- Outros ficheiros de backup podem existir com nomes diferentes
- A tentativa em si revela que o site está a ser ativamente alvo de reconhecimento
- Múltiplas tentativas podem indicar uma campanha mais ampla de ataque
Deteção com Wazuh SIEM
Agora que compreendemos a anatomia do ataque, vamos implementar regras de deteção no Wazuh para identificar automaticamente estas tentativas.
Regra personalizada hipotética para Ficheiros de Backup
Adicione esta regra ao ficheiro /var/ossec/etc/rules/local_rules.xml:
<group name="web,attack,">
<!-- Deteção de tentativas de acesso a ficheiros de backup -->
<rule id="100200" level="10">
<if_sid>31101</if_sid>
<regex type="pcre2">(?i)\.bak|\.backup|\.old|\.orig|\.copy|\.tmp|\.swp|~|\.sql|\.tar\.gz|\.zip</regex>
<description>Tentativa de acesso a ficheiro de backup detetada</description>
<mitre>
<id>T1083</id>
<id>T1530</id>
</mitre>
</rule>
<!-- Severidade elevada se múltiplas tentativas do mesmo IP -->
<rule id="100201" level="12" frequency="5" timeframe="300">
<if_matched_sid>100200</if_matched_sid>
<same_source_ip />
<description>Múltiplas tentativas de acesso a ficheiros de backup do mesmo IP: $(srcip)</description>
<mitre>
<id>T1083</id>
<id>T1530</id>
</mitre>
</rule>
<!-- User-Agent Spoofing detetado -->
<rule id="100202" level="8">
<if_sid>31101</if_sid>
<regex type="pcre2">(?i)Googlebot|bingbot|slurp</regex>
<not_group>known_crawler_ips</not_group>
<description>Possível User-Agent Spoofing detetado: $(http_user_agent)</description>
<mitre>
<id>T1036</id>
</mitre>
</rule>
<!-- Combinação: Backup file + Spoofed User-Agent -->
<rule id="100203" level="14">
<if_sid>100200</if_sid>
<regex type="pcre2">(?i)Googlebot|bingbot|slurp</regex>
<description>CRÍTICO: Tentativa de acesso a backup com User-Agent falsificado</description>
<mitre>
<id>T1083</id>
<id>T1530</id>
<id>T1036</id>
</mitre>
</rule>
</group>
Configuração de Alertas e Respostas Ativas
Configure respostas ativas para bloquear automaticamente IPs suspeitos:
<!-- Em /var/ossec/etc/ossec.conf -->
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>100201,100203</rules_id>
<timeout>1800</timeout> <!-- 30 minutos -->
</active-response>
Dashboard Kibana para Monitorização
Crie visualizações no Kibana para monitorizar:
- Mapa de calor geográfico de tentativas de acesso a backups
- Timeline de tentativas por hora/dia
- Top 10 IPs mais agressivos
- Top 10 ficheiros mais procurados
- Correlação entre User-Agents e padrões de ataque
Proteção com ModSecurity WAF
Enquanto o Wazuh nos ajuda a detetar ataques, o ModSecurity permite-nos prevenir ativamente estas tentativas antes que cheguem à aplicação.
Regras personalizadas hipotéticas ModSecurity
Crie o ficheiro /etc/modsecurity/custom_rules.conf:
# =====================================
# Proteção contra Acesso a Ficheiros de Backup
# =====================================
# Bloqueio de extensões de ficheiros de backup
SecRule REQUEST_URI "@rx (?i)\.(bak|backup|old|orig|copy|tmp|swp|save|~)$" \
"id:1000200,\
phase:1,\
block,\
t:none,\
msg:'Tentativa de acesso a ficheiro de backup bloqueada',\
logdata:'URI: %{REQUEST_URI}, IP: %{REMOTE_ADDR}',\
tag:'attack-backup-files',\
tag:'OWASP_CRS/WEB_ATTACK/FILE_ACCESS',\
severity:'CRITICAL',\
setvar:'tx.anomaly_score_pl1=+5',\
setvar:'ip.backup_file_attempts=+1'"
# Bloqueio de ficheiros SQL comprimidos
SecRule REQUEST_URI "@rx (?i)\.(sql|sql\.gz|sql\.zip|sql\.bz2|dump)$" \
"id:1000201,\
phase:1,\
block,\
t:none,\
msg:'Tentativa de acesso a ficheiro SQL bloqueada',\
logdata:'URI: %{REQUEST_URI}, IP: %{REMOTE_ADDR}',\
tag:'attack-database-dump',\
severity:'CRITICAL',\
setvar:'tx.anomaly_score_pl1=+5',\
setvar:'ip.sql_file_attempts=+1'"
# Bloqueio de ficheiros comprimidos suspeitos na raiz
SecRule REQUEST_URI "@rx (?i)^/[^/]*\.(zip|tar|tar\.gz|tgz|rar|7z)$" \
"id:1000202,\
phase:1,\
block,\
t:none,\
msg:'Tentativa de acesso a arquivo comprimido na raiz bloqueada',\
logdata:'URI: %{REQUEST_URI}, IP: %{REMOTE_ADDR}',\
tag:'attack-archive-files',\
severity:'WARNING',\
setvar:'tx.anomaly_score_pl1=+3',\
setvar:'ip.archive_attempts=+1'"
# =====================================
# Deteção de User-Agent Spoofing
# =====================================
# Bloqueio de crawlers falsos do Google
SecRule REQUEST_HEADERS:User-Agent "@rx (?i)googlebot" \
"id:1000203,\
phase:1,\
chain,\
t:none,\
msg:'User-Agent Googlebot falsificado detetado',\
logdata:'User-Agent: %{REQUEST_HEADERS.User-Agent}, IP: %{REMOTE_ADDR}',\
tag:'attack-user-agent-spoofing'"
SecRule REMOTE_ADDR "!@ipMatchFromFile /etc/modsecurity/google-crawlers.txt" \
"t:none,\
block,\
severity:'WARNING',\
setvar:'tx.anomaly_score_pl1=+4',\
setvar:'ip.spoofing_attempts=+1'"
# =====================================
# Rate Limiting Baseado em Comportamento Suspeito
# =====================================
# Bloqueio temporário após múltiplas tentativas
SecRule IP:backup_file_attempts "@ge 3" \
"id:1000204,\
phase:1,\
block,\
t:none,\
msg:'IP bloqueado temporariamente: múltiplas tentativas de acesso a backups',\
logdata:'Total de tentativas: %{IP.backup_file_attempts}, IP: %{REMOTE_ADDR}',\
tag:'attack-rate-limit',\
severity:'ERROR',\
expirevar:'ip.backup_file_attempts=600'"
# =====================================
# Logging Avançado para Análise Forense
# =====================================
# Log detalhado de todas as tentativas suspeitas
SecRule IP:backup_file_attempts "@ge 1" \
"id:1000205,\
phase:5,\
pass,\
t:none,\
nolog,\
setvar:'tx.outbound_anomaly_score=+0'"
Criar Lista de IPs Legítimos do Google
# Obter IPs reais do Googlebot
curl -s https://developers.google.com/search/apis/ipranges/googlebot.json | \
jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' > \
/etc/modsecurity/google-crawlers.txt
# Adicionar IPs do Bing (opcional)
echo "20.168.0.0/16" >> /etc/modsecurity/google-crawlers.txt
echo "40.77.167.0/24" >> /etc/modsecurity/google-crawlers.txt
Configuração de Resposta Personalizada
Edite /etc/modsecurity/modsecurity.conf:
# Ação para pedidos bloqueados
SecDefaultAction "phase:1,log,auditlog,deny,status:403"
# Resposta HTML customizada
ErrorDocument 403 "<!DOCTYPE html><html><head><title>Acesso Negado</title></head><body><h1>403 Forbidden</h1><p>O seu pedido foi bloqueado pelo nosso sistema de segurança.</p><p>Ref ID: %{UNIQUE_ID}</p></body></html>"
Boas Práticas de Prevenção
Além da deteção e bloqueio ativo, é crucial implementar medidas preventivas:
1. Gestão Segura de Ficheiros de Backup
# NUNCA fazer isto:
cp -r /var/www/html /var/www/html.bak
# Fazer isto em vez disso:
# Backup fora do webroot
mkdir -p /backup/websites
tar -czf /backup/websites/site-$(date +%Y%m%d-%H%M%S).tar.gz \
-C /var/www html \
--exclude='*.log' \
--exclude='cache/*'
# Proteger com permissões adequadas
chmod 600 /backup/websites/*.tar.gz
chown root:root /backup/websites/*.tar.gz
2. Configuração do Servidor Web
Apache (.htaccess):
# Bloquear acesso a ficheiros de backup
<FilesMatch "\.(bak|backup|old|orig|copy|tmp|swp|save|~|sql|gz|zip|tar)$">
Require all denied
</FilesMatch>
# Bloquear acesso a ficheiros ocultos
<FilesMatch "^\.">
Require all denied
</FilesMatch>
Nginx:
# Bloquear ficheiros de backup
location ~* \.(bak|backup|old|orig|copy|tmp|swp|save|~|sql|gz|zip|tar)$ {
deny all;
return 404;
}
# Bloquear ficheiros ocultos
location ~ /\. {
deny all;
return 404;
}
3. Automação com Scripts de Segurança
Crie um script de auditoria /usr/local/bin/check-backup-files.sh:
#!/bin/bash
# Script para detetar ficheiros de backup no webroot
WEBROOT="/var/www/html"
ALERT_EMAIL="security@exemplo.com"
# Procurar por ficheiros de backup
FINDINGS=$(find "$WEBROOT" -type f \( \
-name "*.bak" -o \
-name "*.backup" -o \
-name "*.old" -o \
-name "*.orig" -o \
-name "*.copy" -o \
-name "*.tmp" -o \
-name "*.swp" -o \
-name "*~" -o \
-name "*.sql" -o \
-name "*.sql.gz" \
\) 2>/dev/null)
if [ -n "$FINDINGS" ]; then
echo "⚠️ ALERTA: Ficheiros de backup encontrados no webroot!" | \
mail -s "Alerta de Segurança: Ficheiros de Backup Expostos" "$ALERT_EMAIL" <<EOF
Os seguintes ficheiros de backup foram encontrados no webroot:
$FINDINGS
Ação recomendada: Remover ou mover estes ficheiros imediatamente.
EOF
fi
Agende com cron:
# Verificar diariamente às 02:00
0 2 * * * /usr/local/bin/check-backup-files.sh
4. Monitorização de File Integrity (FIM)
Configure o Wazuh FIM para alertar sobre criação de ficheiros suspeitos:
<!-- Em /var/ossec/etc/ossec.conf -->
<syscheck>
<directories check_all="yes" realtime="yes">/var/www/html</directories>
<!-- Alertar sobre ficheiros de backup -->
<ignore type="sregex">\.bak$</ignore>
<ignore type="sregex">\.backup$</ignore>
<ignore type="sregex">\.old$</ignore>
<ignore type="sregex">\.sql$</ignore>
<alert_new_files>yes</alert_new_files>
</syscheck>
Conclusão e Recomendações
A tentativa de acesso a ficheiros de backup que analisámos pode parecer inofensiva à primeira vista, mas representa um vetor de ataque sério que pode levar a:
- Exposição de código-fonte e propriedade intelectual
- Fuga de credenciais e chaves API
- Comprometimento completo da aplicação
- Exfiltração de dados sensíveis
Checklist de Segurança:
✅ Implementar regras Wazuh para deteção pro-ativa
✅ Configurar ModSecurity para bloqueio em tempo real
✅ Auditar webroot regularmente para ficheiros expostos
✅ Criar backups seguros fora do webroot
✅ Configurar alertas para tentativas de acesso suspeitas
✅ Validar User-Agents contra listas de IPs conhecidos
✅ Implementar rate limiting para prevenir scanning automatizado
✅ Manter logs centralizados para análise forense
Recursos Adicionais:
Nota de Segurança: Os IPs e domínios mencionados neste artigo foram mascarados ou alterados para fins de privacidade. As configurações apresentadas devem ser adaptadas ao seu ambiente específico antes da implementação em produção.
Sobre o Autor: Este artigo faz parte da série sobre segurança de infraestrutura e monitorização com SIEM. Para mais conteúdo técnico sobre cibersegurança, siga o blog.
Última atualização: Janeiro 2026
