Portas Abertas no Seu Servidor: Como Verificar e Fechar o que Não Deveria Estar Exposto

Em 2022, um banco de dados MongoDB sem autenticação foi encontrado exposto na internet com 275 milhões de registros de cidadãos indianos — nomes, telefones, e-mails, histórico de empregos. A exposição não exigiu nenhum ataque sofisticado. A porta 27017 estava aberta para o mundo, sem senha. Qualquer um que soubesse onde olhar podia acessar.

Esse tipo de incidente não é exceção. É o resultado mais comum de servidores configurados sem atenção às portas expostas. MySQL na 3306, Redis na 6379, painéis de administração em portas não documentadas — cada serviço rodando com a porta acessível publicamente é uma superfície de ataque que não precisa existir.

O Que São Portas TCP e Para Que Servem

Quando um servidor recebe uma conexão de rede, o sistema operacional precisa saber qual serviço deve atender aquela conexão. As portas TCP resolvem esse problema: são números de 0 a 65535 que identificam serviços específicos rodando na mesma máquina.

Quando você acessa seusite.com, seu navegador se conecta ao IP do servidor na porta 443 (HTTPS). O servidor sabe que conexões nessa porta devem ser tratadas pelo servidor web. Se fosse a porta 25, seria o servidor de e-mail. Se fosse a porta 22, seria o SSH.

Portas abertas significam que há um processo escutando conexões naquele endereço. Uma porta aberta que não deveria estar acessível publicamente é uma vulnerabilidade — não hipotética, mas real e explorável.

As portas são divididas em três faixas:

Portas bem conhecidas (0–1023): reservadas para serviços padrão — HTTP (80), HTTPS (443), SSH (22), FTP (21)
Portas registradas (1024–49151): usadas por aplicações — MySQL (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017)
Portas dinâmicas (49152–65535): usadas temporariamente pelo sistema operacional para conexões de saída

Portas que Devem Estar Abertas vs. Portas Perigosas

Nem toda porta aberta é um problema. O desafio é saber distinguir o que é necessário do que é risco desnecessário.

Portas que devem estar acessíveis publicamente

Porta	Serviço	Motivo
80	HTTP	Redirecionamento para HTTPS e validação de certificados
443	HTTPS	Tráfego web criptografado
25 / 587 / 465	SMTP	Envio de e-mail (se o servidor for um MTA)

Portas que nunca deveriam estar expostas publicamente

Porta	Serviço	Risco
3306	MySQL/MariaDB	Acesso direto ao banco de dados — credenciais via brute force ou exploits
5432	PostgreSQL	Mesmo risco do MySQL, com histórico de vulnerabilidades de execução remota
6379	Redis	Sem autenticação por padrão em versões antigas; permite escrita arbitrária em arquivos do servidor
27017	MongoDB	Sem autenticação por padrão em instalações antigas; leitura/escrita irrestrita em bases de dados
11211	Memcached	Usado em ataques de amplificação DDoS; sem autenticação nativa
9200	Elasticsearch	API REST sem autenticação por padrão; expõe todos os dados indexados
22	SSH	Deve existir, mas restrito por IP ou substituído por VPN; nunca aberto para qualquer origem

A regra prática: bancos de dados, caches e serviços de infraestrutura não devem ter portas acessíveis pela internet pública. Eles devem ser alcançáveis apenas a partir da rede interna ou via VPN.

Como Verificar as Portas Abertas no Seu Servidor

Port Scanner Online do FlashMon

A forma mais rápida de verificar quais portas do seu servidor estão visíveis externamente é usar o Port Scanner do FlashMon. Diferentemente de ferramentas locais como nmap, o scanner do FlashMon testa a visibilidade das portas da perspectiva da internet — ou seja, o que um atacante externo enxergaria.

A ferramenta verifica 19 portas comuns e oferece três presets para acelerar a análise:

Web: portas 80, 443, 8080, 8443 — ideal para verificar servidores de aplicação
Email: portas 25, 110, 143, 465, 587, 993, 995 — para servidores de e-mail
Database: portas 3306, 5432, 6379, 27017, 9200 — as mais críticas do ponto de vista de segurança

O resultado mostra para cada porta:

Open: porta acessível — um serviço está respondendo
Closed: porta inacessível externamente — correto para serviços internos
Filtered: porta bloqueada por firewall, mas o IP ainda é visível

Para uso mais aprofundado em ambiente controlado e local, o nmap continua sendo a ferramenta de referência:

# Verificar as portas mais comuns
nmap -sV seuservidor.com

# Verificar todas as portas
nmap -p- seuservidor.com

# Verificar com detecção de serviço e versão
nmap -sV -sC -p 22,80,443,3306,6379,27017 seuservidor.com

Como Fechar Portas Desnecessárias

Identificou uma porta que não deveria estar aberta? O processo de fechamento depende de onde você está rodando o servidor.

Linux com iptables

O iptables é o firewall padrão em distribuições Linux mais antigas. Para bloquear acesso externo à porta 3306 (MySQL) mantendo acesso local:

# Bloquear acesso externo à porta 3306
iptables -A INPUT -p tcp --dport 3306 -j DROP

# Permitir apenas conexões do localhost (aplicação no mesmo servidor)
iptables -A INPUT -p tcp --dport 3306 -s 127.0.0.1 -j ACCEPT

# Salvar as regras (Ubuntu/Debian)
iptables-save > /etc/iptables/rules.v4

Linux com UFW (Ubuntu/Debian)

O UFW é uma interface simplificada sobre o iptables, mais comum em servidores modernos:

# Ativar o UFW
ufw enable

# Permitir apenas SSH, HTTP e HTTPS
ufw allow 22
ufw allow 80
ufw allow 443

# Bloquear tudo que não foi explicitamente permitido
ufw default deny incoming

# Verificar o status
ufw status verbose

Cloud: Security Groups (AWS, GCP, Azure)

Em ambientes de nuvem, o controle de portas é feito nos security groups ou firewall rules da plataforma — e essa camada de controle deve ser a primeira linha de defesa, independentemente do firewall do sistema operacional.

No console da AWS, por exemplo:

Acesse EC2 → Security Groups
Selecione o grupo associado à instância
Na aba "Inbound rules", remova qualquer regra que permita acesso a portas de banco de dados com source 0.0.0.0/0 (qualquer IP)
Substitua por regras que permitam acesso apenas do security group da aplicação ou de um IP específico de VPN

O mesmo princípio se aplica ao GCP (VPC Firewall Rules) e ao Azure (Network Security Groups).

Configurar o Serviço para Escutar Apenas em Localhost

Além do firewall, configure o próprio serviço para não escutar em interfaces públicas. Para o MySQL, no arquivo /etc/mysql/mysql.conf.d/mysqld.cnf:

bind-address = 127.0.0.1

Para o Redis, no /etc/redis/redis.conf:

bind 127.0.0.1 ::1

Essa configuração garante que, mesmo que o firewall seja mal configurado, o serviço não aceita conexões externas.

Verificação Complementar: Além das Portas

Fechar as portas certas é o passo mais importante, mas a postura de segurança de um servidor envolve outras camadas. Depois de confirmar que as portas de banco de dados estão fechadas, vale verificar:

Cabeçalhos de segurança HTTP: use o Security Headers do FlashMon para confirmar que seu servidor web está enviando Strict-Transport-Security, Content-Security-Policy e outros cabeçalhos que protegem contra ataques no lado do cliente
Certificado SSL: o SSL Checker do FlashMon verifica se o certificado está válido, se a cadeia de confiança está correta e se protocolos antigos (TLS 1.0, 1.1) foram desabilitados

Faça a Varredura Agora

A verificação de portas abertas é uma das auditorias de segurança mais simples e com maior impacto direto. Leva menos de um minuto, não requer instalação de software e revela imediatamente se você tem serviços expostos que não deveriam estar.

Verifique as portas abertas do seu servidor agora — é gratuito

Continue lendo

Depois das portas, feche a camada HTTP: o guia de headers de segurança e o verificador de headers cobrem o que o scanner não pega.
Valide sua configuração TLS com o verificador SSL.