Tutoriais de VPS
Não exponha os bancos de dados do VPS diretamente à internet (2026): como tornar o acesso remoto ao MySQL, PostgreSQL e Redis seguro
Muitos incidentes em VPS não são causados por erros no código da aplicação, mas por MySQL, PostgreSQL e Redis abertos diretamente à internet. Este artigo explica por que você não deve expor 3306/5432/6379 e aborda métodos de acesso remoto mais seguros, como túneis SSH, VPN, redes privadas e listas de permissões.
Um amigo, por conveniência, alterou o bind-address do MySQL para 0.0.0.0 e depois liberou a porta 3306 no firewall. O motivo era simples: conectar pelo Navicat local era fácil.
No começo era mesmo prático, até que um dia a CPU disparou e apareceram várias conexões estranhas no banco de dados. Ele verificou os logs e descobriu que a porta 3306 já estava sendo escaneada há muito tempo. A senha não foi quebrada, mas vinha sofrendo ataques de força bruta contínuos por dias.
O Redis é ainda mais assustador. Um Redis sem senha e exposto diretamente à internet é basicamente esperar para ser escaneado. Muitos daqueles incidentes que vemos na internet, com tarefas agendadas sendo escritas, mineradores instalados ou bancos apagados, vêm exatamente disso.
Então este artigo defende um único princípio: banco de dados não é site. Não o exponha diretamente à internet só para facilitar conexões remotas.
Primeiro a conclusão: portas de banco de dados não deveriam ficar abertas para toda a internet por padrão
As portas comuns de bancos de dados incluem:
- MySQL / MariaDB: 3306
- PostgreSQL: 5432
- Redis: 6379
- MongoDB: 27017
- Elasticsearch: 9200
Se essas portas estiverem expostas à internet, serão escaneadas rapidamente. Não é "alguém pode escanear", é que quase certamente alguém vai escanear.
A abordagem correta é:
- Aplicação e banco de dados no mesmo VPS: o banco escuta no
127.0.0.1local - Aplicação e banco de dados na mesma rede privada: permitir acesso apenas de IPs privados
- Gerenciamento temporário a partir do computador local: usar um túnel SSH
- Gerenciamento de longo prazo por várias pessoas: usar VPN ou bastion host
- Acesso público obrigatório: permitir apenas uma lista de IPs fixos e habilitar senhas fortes e TLS
Não considere "conecta" como configuração bem-sucedida. Para acesso remoto ao banco de dados, pergunte primeiro: quem pode conectar, de onde, está criptografado e como conter o dano se algo der errado.
Muitos tutoriais dizem: altere o bind-address na configuração do MySQL de 127.0.0.1 para 0.0.0.0, libere a 3306 e pronto, você consegue conectar remotamente.
Tecnicamente está correto, mas do ponto de vista de segurança é perigoso.
0.0.0.0 significa escutar em todas as interfaces de rede. Se o firewall também estiver aberto, qualquer IP público pode tentar se conectar a essa porta do banco de dados.
Você pode verificar as portas em escuta com:
ss -lntp | grep -E '3306|5432|6379|27017|9200'
Se você vir:
0.0.0.0:3306
0.0.0.0:6379
fique atento. A menos que você tenha certeza absoluta de que o firewall só permite IPs confiáveis, isso é exposição pública.
O padrão mais seguro é:
127.0.0.1:3306
127.0.0.1:5432
127.0.0.1:6379
Quando a aplicação e o banco de dados estão no mesmo VPS, escutar localmente já basta. Aplicações Nginx, PHP, Node e Python podem se conectar a partir da própria máquina; o banco de dados não precisa ficar aberto à internet.
Se você só quer gerenciar o banco de dados do seu computador local com Navicat, DataGrip ou TablePlus, a forma mais simples e segura é um túnel SSH.
Por exemplo, se o MySQL está no 127.0.0.1:3306 local do VPS, execute localmente:
ssh -L 3307:127.0.0.1:3306 root@你的服务器IP
Depois conecte sua ferramenta de banco de dados local a:
127.0.0.1:3307
Os dados na verdade trafegam pelo canal criptografado SSH, e a porta do banco de dados não fica exposta à internet.
O PostgreSQL é parecido:
ssh -L 5433:127.0.0.1:5432 root@你的服务器IP
O Redis também funciona:
ssh -L 6380:127.0.0.1:6379 root@你的服务器IP
Esse truque serve para gerenciamento pessoal, diagnóstico temporário e edições ocasionais de dados. A desvantagem é que você não consegue conectar quando o túnel cai, mas isso na verdade é bom: a porta se fecha naturalmente quando você não está usando.
Se várias pessoas da equipe precisam acessar o banco de dados, não é recomendável que todo mundo se conecte diretamente à porta pública do banco.
Uma abordagem mais robusta é:
- Montar uma rede privada com WireGuard / Tailscale / ZeroTier
- Fazer o banco de dados escutar apenas no endereço privado da VPN
- Permitir que apenas a sub-rede da VPN acesse a porta do banco de dados
- Dar a cada pessoa sua própria identidade e permissões de VPN
Por exemplo, o servidor de banco de dados tem um IP privado do WireGuard:
10.8.0.2
Os servidores de aplicação ou computadores de desenvolvimento acessam pela VPN:
10.8.0.2:3306
Nem o security group público nem o firewall do sistema abrem a 3306. A porta do banco de dados não pode ser escaneada de fora, então o risco é muito menor.
Se você usa vários VPS do mesmo provedor de nuvem, também pode usar uma rede privada/VPC. Permita apenas que IPs privados acessem a porta do banco de dados; não a abra à internet.
Alguns cenários realmente exigem acesso público, como um sistema de terceiros que puxa dados de um IP fixo, ou um IP de saída de escritório fixo.
Nesse caso, não permita 0.0.0.0/0; permita apenas IPs de origem fixos.
Exemplo com UFW:
ufw allow from 你的办公公网IP to any port 3306 proto tcp
ufw deny 3306/tcp
ufw status numbered
iptables segue a mesma ideia: primeiro permitir IPs confiáveis, depois rejeitar outras origens.
O mesmo vale para os security groups da nuvem: coloque como origem o seu IP fixo, não Anywhere.
Ao mesmo tempo, também faça o seguinte:
- Senhas fortes, sem credenciais fracas
- Proibir login remoto root no banco de dados
- Criar uma conta separada com privilégio mínimo para o negócio
- Habilitar TLS/SSL (especialmente pela internet)
- Revisar periodicamente os logs de falha de login
- Os backups precisam ser restauráveis
Uma lista de permissões não é bala de prata, mas é muito melhor do que ficar aberto para toda a internet.
O Redis é uma grande zona de desastre.
Muita gente pensa que o Redis é só cache e que, se for apagado, é só gerar de novo. Mas, uma vez exposto, o risco não é só perda de dados: ele também pode ser usado para gravar tarefas maliciosas, escrever arquivos via replicação master-slave ou servir de trampolim para mineração.
No mínimo, o Redis deve fazer:
bind 127.0.0.1
protected-mode yes
requirepass 一个足够强的密码
Se precisar dar acesso remoto às aplicações, prefira a rede privada ou a VPN; não abra a 6379 diretamente à internet.
Verifique se o Redis está escutando na internet:
ss -lntp | grep 6379
Se você vir 0.0.0.0:6379, não hesite: recolha imediatamente para local ou rede privada.
Se você descobrir que uma porta de banco de dados ficou pública por um tempo, não basta fechar a porta e dar o assunto por encerrado.
Recomenda-se fazer o seguinte, em ordem:
- Fechar imediatamente o acesso público no firewall/security group
- Preservar os logs; não apagá-los de imediato
- Verificar os usuários e permissões do banco de dados
- Alterar todas as senhas do banco de dados
- Verificar se há contas, bancos e tabelas desconhecidos
- Verificar tarefas agendadas do sistema, chaves SSH e processos suspeitos
- Comparar dados críticos com backups confiáveis
- Se o Redis/MongoDB já rodou nu, tratar como incidente de invasão
No MySQL, você pode verificar os usuários:
SELECT user, host FROM mysql.user;
No PostgreSQL, verifique os roles:
\du
No Redis, é preciso verificar a configuração, os dados, as tarefas agendadas e o nível do sistema. O impacto de um Redis nu pode ir além do próprio Redis.
Verifique as portas em escuta no VPS:
ss -lntp | grep -E '3306|5432|6379|27017|9200'
Verifique do seu computador local se as portas estão acessíveis:
nmap -Pn -p 3306,5432,6379,27017,9200 你的服务器IP
Se o seu computador local consegue escanear essas portas como abertas e você não configurou uma lista de permissões, então elas estão basicamente acessíveis publicamente.
Depois verifique o firewall:
ufw status verbose
iptables -L -n -v
Também verifique o security group no console do provedor de nuvem. Muita gente só fecha o firewall do sistema e esquece o firewall da nuvem; outros endurecem o security group da nuvem, mas o serviço no sistema continua escutando na internet. Verifique os dois lados.
Aqui vai uma tabela simples:
| Cenário | Solução recomendada |
|---|---|
| Aplicação local conecta ao banco local | Escutar em 127.0.0.1 |
| Gerenciamento ocasional a partir do computador local | Túnel SSH |
| Gerenciamento de equipe a longo prazo | WireGuard / Tailscale / ZeroTier |
| Comunicação interna entre vários VPS | Rede privada / VPC |
| Acesso de terceiros com IP fixo | Lista de permissões pública + TLS + privilégio mínimo |
| Cache Redis | Local ou rede privada; evitar internet se possível |
| Diagnóstico temporário | Lista de permissões temporária, remover imediatamente após o uso |
Se você não sabe qual escolher, use o túnel SSH por padrão. Simples, seguro e suficiente.
Depois de implantar um banco de dados em um VPS novo, eu verifico assim:
- MySQL/PostgreSQL/Redis escutam apenas em local ou rede privada
- O firewall evita abrir 3306/5432/6379 para toda a internet
- O security group da nuvem não tem regras de entrada Anywhere
- O login remoto root/admin no banco de dados está desabilitado
- Foi criada uma conta com privilégio mínimo para o negócio
- Há senhas fortes ou autenticação por chave
- É necessário TLS/SSL
- Os backups e os testes de restauração estão configurados
- Você sabe onde consultar os logs
- Você registrou quem pode acessar o banco de dados
No acesso remoto a bancos de dados, conveniência e segurança costumam entrar em conflito. Meu conselho é: se puder evitar a internet, evite; se puder usar um túnel, use; se puder usar uma rede privada, use.
Quando o acesso público for realmente necessário, também não exponha o banco de dados como um serviço web comum. Portas web podem ficar voltadas aos usuários; portas de banco de dados devem ficar voltadas apenas às máquinas e pessoas em que você confia.