Quando convém um redirecionamento de portas e quando não convém

Publicado em 2026-09-12 por frfrand

Una guía corta para decidir entre abrir un puerto, poner un proxy inverso o levantar un túnel, y la pregunta que resuelve el noventa por ciento de los casos.

Quase sempre que alguém pergunta "como abro esta porta?", a resposta correta é "provavelmente não abra".

Não por paranoia. Porque abrir uma porta é uma decisão que custa pouco hoje e muito nos próximos anos, e há alternativas que resolvem o mesmo sem essa conta pendente.

A pergunta que organiza tudo

Antes de mexer no firewall, responda uma coisa:

Isso precisa estar disponível para o mundo, ou somente para você e sua equipe?

Se a resposta for "para o mundo", você precisa expor, e convém fazer bem. Se a resposta for "para nós", não abra nada: use um túnel.

Parece simples porque é. O problema é que na primeira vez que você precisar se conectar ao banco de casa, abrir a porta parece o mais rápido. E depois fica aberta.

O que acontece quando você abre uma porta

Não é uma metáfora: coloque um serviço novo em um IP público e veja os logs em duas horas.

Há redes inteiras dedicadas a escanear todo o espaço de endereços da Internet, o tempo todo. Eles não te escolheram: varrem tudo. Uma porta aberta aparece nas listas deles em minutos.

Isso não significa que vão entrar. Significa que a partir desse momento a segurança desse serviço depende inteiramente de quão bem configurado ele está, de sua versão, e de que você aplique os patches. Para sempre.

Para um servidor web isso é aceitável: é o trabalho dele. Para um banco de dados ou um painel de administração, quase nunca vale a pena.

Os três casos onde sim

Um serviço público de verdade. Um site, uma API consumida por terceiros, um servidor de e-mail. É a razão de existir dele.

Um protocolo que não é HTTP e precisa de acesso direto. Jogos, alguns sistemas de mensagens, dispositivos que não sabem fazer outra coisa.

Um webhook de entrada. Um serviço externo precisa bater na sua porta. Vale a pena esclarecer algo aqui: um webhook entra por HTTPS, então não é necessário abrir uma nova porta. Ele entra pela 443 que você já tem, e seu proxy reverso faz o roteamento.

E os casos onde quase nunca

Bancos de dados. PostgreSQL, MySQL, Redis, Mongo. Se sua aplicação vive no mesmo servidor, o banco não precisa sair para a rede de forma alguma. Se vive em outro servidor, use uma rede interna ou um túnel entre os dois.

Painéis de administração. phpMyAdmin, Adminer, o painel do seu framework. São alvos clássicos justamente porque muita gente os deixa abertos.

Qualquer coisa "temporária". Não existe porta temporária. Existe a porta que você abriu e não fechou.

A alternativa concreta

ssh -L 5432:localhost:5432 prod

Com isso, a porta 5432 do servidor aparece na sua máquina como se fosse local. Seu cliente se conecta ao localhost, o tráfego vai cifrado por SSH, e o servidor não tem nenhuma porta de banco de dados exposta.

Se a conexão cair quando você mudar de rede, o autossh a reconecta sozinho.

Y para uma equipe inteira, a versão escalada da mesma ideia é uma VPN ou uma rede tipo Tailscale: as máquinas se veem como se estivessem no mesmo escritório, sem que nenhuma tenha uma porta aberta para o mundo.

Se mesmo assim você precisar abrir

Três mínimos que mudam muito o risco:

• Limite por origem. Se entrar apenas o seu escritório, permita apenas esse endereço. A maioria dos firewalls permite isso em uma linha.
• Coloque algo na frente. Um proxy reverso com limite de requisições absorve a maior parte do ruído.
• Anote por que você abriu e quando revisar. Portas abertas sem dono são as que sobrevivem por anos.

No ArduMaker tudo começa fechado e se abre declarando, justamente para que abrir seja uma decisão e não um descuido. E para o interno há túneis entre VPS, assim o tráfego entre seus próprios servidores nunca sai para a Internet para voltar a entrar.