Linux / Comando ss: consultar portas em escuta e conexões

O comando ss mostra sockets, portas em escuta e estados de conexões no Linux. Ele ajuda a descobrir em qual endereço um serviço recebe conexões e qual processo usa um socket. Uma porta visível localmente não comprova que o serviço esteja acessível de outra máquina.

Sockets, protocolos e seleção da consulta

Um socket é uma extremidade de comunicação gerenciada pelo sistema operacional. Os exemplos abaixo tratam do Protocolo de Controle de Transmissão (TCP) e do Protocolo de Datagrama do Usuário (UDP). TCP mantém estados de conexão; UDP transporta datagramas sem o estabelecimento de conexão equivalente ao de TCP.

Sem opções, ss normalmente mostra sockets não ouvintes com conexões estabelecidas; não é a consulta adequada para inventariar servidores em escuta. Use -l para selecionar os sockets em escuta, -t para TCP e -u para UDP. A opção -p acrescenta informações de processos, sujeitas às permissões e à visibilidade do ambiente.

Sintaxe e implementação instalada

ss [opções] [filtro]

Os colchetes descrevem a sintaxe e não devem ser digitados literalmente. Consulte man ss, ss --help e ss --version no sistema em que fará o diagnóstico. As opções apresentadas seguem o ss do iproute2; a presença e o formato de campos adicionais podem variar.

Consultar portas em escuta e filtrar conexões

Portas TCP em escuta, com números de porta:

ss -ltn

A combinação reúne -l, -t e -n. Procure o endereço e a porta locais do serviço esperado. Uma linha em LISTEN indica um socket TCP esperando conexões; não indica que já existe um cliente conectado nem que a aplicação responderá corretamente.

Portas TCP e UDP e os processos associados:

sudo ss -ltnup

Esse exemplo combina a seleção de TCP e UDP com -p. Use a autorização administrativa apenas se ela for necessária para enxergar informações de outros usuários. Um campo de processo vazio não prova que a porta esteja livre: confira permissões, contexto de rede e a informação disponível no momento. Para investigar somente TCP e processos, a forma ss -ltnp pode ser suficiente.

Em UDP, uma entrada pode aparecer como UNCONN, sem representar falha do serviço. Até uma associação de destino feita por um socket UDP não constitui uma negociação TCP nem comprova comunicação com o outro lado. A distinção é descrita no manual do protocolo UDP no Linux.

Filtrar sockets TCP pela porta 22 em uma das extremidades:

ss -tn '( sport = :22 or dport = :22 )'

sport compara a porta de origem e dport a de destino; na visão do socket local, correspondem às portas local e do par, respectivamente. O operador or aceita qualquer uma das condições. As aspas simples fazem o shell passar a expressão agrupada para ss. A porta numérica 22 é um exemplo, não uma prova de qual aplicação está usando o socket.

Essa consulta não inclui automaticamente sockets em escuta, pois não usa -l nem -a. Compare o filtro e o estado procurado antes de concluir que o serviço parou. Uma saída vazia pode refletir ausência de correspondências ou uma falha; leia também o erro e o status do comando.

No Bash 5.3.9 do Git para Windows usado nesta verificação, ss não estava instalado. A versão e as consultas sem sudo retornaram 127 por comando inexistente. As quatro formas de comando do texto passaram apenas por análise de sintaxe do Bash, incluindo o filtro entre aspas. Não houve execução de sudo, abertura de um servidor de teste nem validação de sockets em Linux nativo.

Interpretar a linha de um socket TCP em escuta

Para ler os campos da consulta TCP em escuta, considere novamente:

ss -ltn

Trecho ilustrativo de saída; endereços, espaçamento e limites de fila dependem do ambiente. Não é uma captura do teste em Windows:

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128    0.0.0.0:22         0.0.0.0:*

• State: LISTEN identifica o socket TCP em escuta.
• Recv-Q e Send-Q: nesse socket em LISTEN, os valores representam, respectivamente, o número de conexões à espera de aceitação pela aplicação e o limite da fila, chamado backlog. O exemplo mostra 0 e 128; não são contadores de bytes transferidos nem uma medida da velocidade da rede.
• Local Address:Port: 0.0.0.0:22 é a associação à porta 22 em todos os endereços IPv4 locais do contexto de rede correspondente.
• Peer Address:Port: o curinga nesse socket em escuta não identifica um cliente específico. Não o interprete como uma conexão já estabelecida com um endereço remoto.

O manual de diagnóstico de sockets distingue os campos de fila de sockets em escuta dos de outros estados. O manual de listen explica a fila de conexões concluídas que aguardam aceitação pela aplicação. O valor 128 da ilustração não deve ser tratado como limite padrão de todo servidor.

Uma associação somente a 127.0.0.1:porta usa loopback e não recebe diretamente conexões pela interface externa. Um proxy ou túnel pode oferecer outro caminho até esse serviço, o que exige examinar a configuração completa. Já 0.0.0.0 não ignora firewall, roteamento ou regras de segurança da nuvem. Essas propriedades dos endereços são descritas no manual de IPv4 no Linux.

IPv4 e IPv6 precisam ser considerados separadamente. As opções -4 e -6 permitem restringir a família; uma linha IPv4 com 0.0.0.0 não comprova que exista um socket IPv6. Em contêineres e namespaces de rede, confirme também se a consulta foi feita no contexto que contém o serviço.

Opções principais de ss

O manual de ss do iproute2 documenta as opções, os estados e a sintaxe de filtros. Uma listagem é um retrato do momento: um processo pode encerrar ou um socket pode desaparecer entre a consulta e a ação seguinte.

Investigar uma porta visível que não aceita acesso externo

1. Confira protocolo, família e endereço local. Compare TCP ou UDP, IPv4 ou IPv6, loopback ou endereço da interface. Confirme o host e o namespace em que o serviço funciona.
2. Identifique o processo responsável. Use a informação permitida por -p e confira o serviço e sua configuração antes de parar qualquer processo para liberar uma porta. Não conclua que um nome ou número de processo observado antes ainda representa a mesma situação.
3. Examine o caminho até o serviço. Confira interfaces e rotas com ip, firewall, redirecionamentos e regras de segurança da infraestrutura. Uma associação a 0.0.0.0 não abre essas regras automaticamente.
4. Valide a partir do cliente relevante. Um teste local e um acesso vindo de outra máquina percorrem caminhos diferentes. Quando a conexão de transporte funcionar, verifique também a resposta da aplicação; ter um socket não comprova saúde do serviço.

Pergunta frequente

Por que a porta aparece em ss, mas não consigo acessá-la de fora?

Confirme o protocolo, a família de endereço e se o socket está associado a loopback ou à interface esperada. Depois, examine rotas, firewall, redirecionamentos e regras de segurança da nuvem e teste pelo cliente relevante. Ss mostra sockets locais; ele não certifica que todo o caminho externo esteja liberado.