Bancos de dados: superfície de ataque e hardening

Por que bancos vazam

• Exposição direta (porta 5432/3306/27017/6379 na internet).
• Credenciais default ou hardcoded em repositório público.
• SQL Injection clássica e blind, em código sem prepared statements.
• Backups em S3 público ou snapshots compartilhados acidentalmente.
• Replicação mal configurada (logical replication sem ACL).

Reconhecimento

# Descobrir bancos expostos no escopo autorizado
nmap -sV -p 1433,3306,5432,6379,27017,9200 --script="banner,*-info" alvo.tld

# Buscar credenciais em código público (autorizado / próprio)
trufflehog filesystem ./repo --only-verified

SQL Injection — o que sqlmap realmente faz

O sqlmap não 'mágica' — ele injeta marcadores, mede diferenças (booleano, tempo, erro, UNION) e infere o schema byte a byte. Saber isso ajuda a entender por que prepared statements eliminam a classe inteira.

# Teste assistido (escopo autorizado)
sqlmap -u "https://alvo.tld/item?id=1" --batch --risk=2 --level=3 \
       --technique=BEUST --dbs

Hardening por banco

PostgreSQL

• listen_addresses='localhost' a não ser que precise de rede; pg_hba.conf com 'scram-sha-256'.
• Roles por aplicação, REVOKE ALL em public schema, GRANT mínimo.
• Row Level Security para multi-tenant.
• Backups cifrados (pgbackrest + chave gerenciada).

MySQL / MariaDB

• bind-address=127.0.0.1, validate_password, sql_mode estrito.
• Usuários sem GRANT ALL; nunca usar 'root'@'%'.

MongoDB

• authorization enabled (não é default em versões antigas).
• TLS obrigatório, IP allowlist no Atlas, sem 0.0.0.0/0.

Redis

• requirepass + protected-mode yes, rename-command FLUSHALL '', sem expor à internet.
• Ataques de SSRF + Redis interno são clássicos — segmentar rede.