Como Monitorizar uma Porta TCP (e Quando Alertar Quando Uma Está Aberta)

A monitorização de portas é dois trabalhos num só. Por vezes quer saber que um serviço está à escuta, como uma base de dados ou um relé SMTP. Outras vezes quer saber que uma porta se mantém bloqueada pela firewall, como o SSH numa instância virada para a Internet. A mesma sonda responde a ambas as perguntas, mas alerta em resultados opostos. Este guia cobre quando usar cada modo, sobre o que alertar e as portas que apanham as pessoas desprevenidas.

Como funciona realmente um monitor de portas TCP

Um monitor de portas TCP abre um socket para o destino na porta escolhida e aguarda a conclusão do handshake de três vias. Se o handshake for bem-sucedido, a porta está aberta. Se a ligação for recusada, a porta está fechada. Se a ligação expirar, algo entre o sondador e o seu anfitrião está a descartar o pacote, normalmente uma firewall.

A sonda não fala um protocolo por cima do socket. Não negoceia TLS, não troca banners SSH nem executa uma consulta à base de dados. Apenas lhe diz se a porta responde. Para verificações de saúde a nível de aplicação, precisa de uma verificação HTTP ou personalizada por cima.

Quando quer a porta ABERTA

Use a monitorização de portas como sonda de saúde de serviço quando não conseguir fazer facilmente uma verificação HTTP. Surgem cinco casos comuns.

• Servidores de base de dados na porta 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Se o ouvinte falhar, todos os serviços dependentes ficam inoperacionais, mas não pode executar uma sonda HTTP.
• Relés SMTP na porta 25 ou 587. As verificações de banner SMTP detetam falhas do ouvinte que os pontos de saúde internos não apanham.
• Servidores de jogos e outros protocolos TCP personalizados que não falam HTTP.
• Balanceadores de carga internos que expõem uma porta de saúde não-HTTP a serviços a montante.
• Pontos de extremidade VPN em portas UDP-mas-também-TCP como a 443 para OpenVPN-TCP e WireGuard.

Quando quer a porta FECHADA

A monitorização invertida de portas é uma proteção de segurança. Define o monitor para alertar quando a porta passa a estar aberta, porque nunca deveria estar aberta a partir da Internet pública. O padrão apanha as coisas que correm mal durante uma semana normal de alterações de infraestrutura.

Alguém abre temporariamente uma regra de firewall para depuração e esquece-se de a reverter. Um serviço Kubernetes recebe um tipo LoadBalancer por acidente. Uma nova instância recebe o grupo de segurança errado. Uma alteração de módulo Terraform expõe uma porta que era suposto ser interna. Em todos os casos, o monitor invertido de portas apanha a exposição dentro de um intervalo de verificação.

As portas de alto valor para monitorizar de forma invertida neste momento

Cinco portas merecem que configure uma verificação invertida para qualquer anfitrião virado para a Internet que não as deva estar a expor.

• 22 (SSH) em servidores de aplicação de produção. O acesso exclusivo via bastion é a norma, e uma porta SSH acidentalmente aberta aparece nos registos de varrimento em massa em poucas horas.
• 3306 (MySQL) e 5432 (Postgres). As portas públicas de base de dados são responsáveis por uma parte significativa dos ataques de credential stuffing.
• 6379 (Redis). Um Redis aberto sem autenticação é uma das configurações incorretas mais exploradas na indústria.
• 27017 (MongoDB). A mesma história do Redis. Configuração predefinida, sem autenticação, porta pública equivale a perda de dados.
• 9200 (Elasticsearch). Clusters abertos são raspados, minerados e sequestrados em horas.

Limiares de alerta para monitorização de portas

A saúde do serviço (porta deve estar ABERTA) pede o mesmo padrão de limiar que o HTTP: alertar após 3 falhas consecutivas, suprimir oscilações curtas. Pequenas falhas de rede que fecham uma única sonda são ruído.

A segurança (porta deve estar FECHADA) quer o oposto. Alertar na primeira deteção. Uma porta SSH ou Redis acidentalmente aberta é um evento de alerta máximo. Os bots estão a varrer a Internet pública constantemente, e a janela entre exposição e comprometimento numa porta bem conhecida mede-se em minutos.

Uma lista de verificação inicial para monitorização de portas de segurança

Para cada IP virado para a Internet que a sua equipa opera, configure monitores invertidos nas portas 22, 3306, 5432, 6379 e 27017 num intervalo de 60 segundos. Encaminhe os alertas para o seu canal de segurança separadamente dos alertas de saúde do serviço. Uma vez por trimestre, execute um varrimento real de portas contra os seus próprios IPs como controlo. O custo é pequeno, a cobertura é ampla e os modos de falha que apanha são catastróficos.