Quem administra servidores vive a fazer as mesmas duas perguntas: que portos é que esta máquina tem abertos? e quem está ligado a quê neste momento? O comando ss responde a ambas em milissegundos, diretamente a partir do kernel. Seja para confirmar que um serviço arrancou, para investigar uma ligação suspeita ou para fazer o inventário da superfície de ataque de um servidor, é uma das ferramentas mais usadas no dia a dia de administração de sistemas e de cibersegurança.
A seguir percorremos as opções que realmente interessam e mostramos como usar o ss em cenários reais de segurança ofensiva e defensiva — com um simulador interativo para praticar sem sair da página.
O que faz o ss
O ss (socket statistics) lista os sockets do sistema: os pontos de comunicação que os processos usam para falar em rede (TCP, UDP) ou entre si (sockets Unix). Faz parte do pacote iproute2, presente por omissão em praticamente todas as distribuições modernas, e veio substituir o velho netstat. A diferença principal está na forma de recolher os dados: em vez de percorrer o /proc ficheiro a ficheiro, o ss comunica com o kernel através da interface netlink, o que o torna muito mais rápido em máquinas com milhares de ligações simultâneas.
A forma geral do comando combina opções, um filtro de estado e uma expressão de filtro sobre endereços e portos:
ss [opções] [state ESTADO] [expressão de filtro]
Um detalhe que apanha muita gente de surpresa: sem opções, o ss mostra apenas as ligações estabelecidas — nada do que está à escuta aparece. Para ver os portos abertos é preciso pedir explicitamente com -l (só à escuta) ou -a (tudo).
As opções que interessam
Escolher o protocolo e a família
-t/-u— restringem a sockets TCP ou UDP. Sem estas opções, ossmistura todos os protocolos.-x/-w— sockets Unix (comunicação local entre processos) e sockets raw.-4/-6— apenas IPv4 ou apenas IPv6. Útil para confirmar que um serviço escuta nas duas famílias — osshd, por exemplo, cria normalmente um socket para cada uma.
Escolher que sockets listar
-l— só os sockets à escuta. Responde à pergunta essencial: que portos tem esta máquina abertos?-a— todos: à escuta e ligados. Sem-lnem-a, só aparecem os estabelecidos.
Colunas e nível de detalhe
-n— mostra os portos em número (22em vez dessh) e não resolve nomes. Além de evitar ambiguidades, torna o comando muito mais rápido porque dispensa consultas DNS.-p— acrescenta o processo dono de cada socket (nome, PID e descritor). Requer privilégios de root para ver processos de outros utilizadores.-e— informação alargada, incluindo o inode do socket, que permite cruzar com olsofe com o/proc.-o— temporizadores da ligação: keepalive, retransmissões, contagem decrescente doTIME-WAIT.-m— memória usada por cada socket, buffer a buffer; bom para diagnosticar buffers cheios.-i— informação interna do TCP: janela de congestão, RTT, retransmissões.
A combinação mais usada na prática junta quase tudo isto num só comando, o clássico inventário de portos abertos:
ss -tulnp
Netid State Local Address:Port Process
tcp LISTEN 0.0.0.0:22 users:(("sshd",pid=911,fd=3))
tcp LISTEN 0.0.0.0:443 users:(("nginx",pid=1204,fd=6))
udp UNCONN 127.0.0.53:53 users:(("systemd-resolve",pid=640,fd=12))
Filtros de estado, porto e endereço
Onde o ss realmente brilha é na linguagem de filtros. Em vez de encadear vários utilitários de filtragem de texto, o filtro é feito pelo próprio comando:
state ESTADO— filtra por estado TCP:established,listening,time-wait,syn-recv,close-wait, entre outros.sport/dport— filtram pelo porto local ou remoto. A sintaxe usa dois pontos antes do número:sport = :22.src/dst— filtram pelo endereço local ou remoto, aceitando prefixos CIDR como10.0.0.0/8.and/or/not— combinam expressões para filtros compostos.
# Ligações estabelecidas ao SSH desta máquina
ss -tn state established sport = :22
# Tudo o que fala com um endereço remoto concreto
ss -tn dst 203.0.113.9
# Saídas HTTPS para fora de uma rede interna
ss -tn dport = :443 and not dst 10.0.0.0/8
Outros modos
-s— em vez da lista, apresenta um resumo estatístico por protocolo: totais de sockets TCP, UDP e RAW, ligações estabelecidas, órfãs e emtime-wait. Excelente primeiro olhar sobre uma máquina.-K— fecha à força os sockets que corresponderem ao filtro (requer suporte do kernel). Ferramenta de resposta a incidentes, a usar com muito cuidado.-E— fica em execução a mostrar sockets à medida que são destruídos, útil para observar o comportamento de um serviço em tempo real.
ss em cibersegurança
Inventário da superfície de ataque. O primeiro passo de qualquer hardening é saber o que está exposto. Um ss -tulnp mostra cada porto à escuta e o processo responsável. Tudo o que escuta em 0.0.0.0 está acessível a partir da rede; serviços que só precisam de acesso local — bases de dados, caches — devem escutar em 127.0.0.1. Encontrar um serviço de base de dados exposto em todas as interfaces é um clássico das auditorias.
Deteção de ataques de negação de serviço. O estado SYN-RECV corresponde a handshakes TCP a meio: o servidor recebeu o SYN e aguarda a confirmação. Meia dúzia é normal; milhares em simultâneo são a assinatura de um SYN flood. O comando ss -tn state syn-recv conta-os num instante e mostra as origens.
Caça a ligações suspeitas. Quando a análise de logs ou um alerta do SIEM entrega um IP suspeito, ss -tnp dst ENDEREÇO confirma imediatamente se existe uma ligação ativa a esse endereço e que processo a mantém. É também a forma mais rápida de detetar uma reverse shell: uma ligação estabelecida para o exterior mantida por um processo que não devia falar com a Internet.
Análise forense e resposta a incidentes. Com -e, o inode do socket permite cruzar a ligação com o lsof e o /proc, chegando ao executável e ao utilizador do processo. Em último recurso, ss -K termina os sockets de um atacante sem derrubar o serviço — depois de documentar tudo o que se observou.
Experimente no simulador interativo
A simulação abaixo recria uma máquina com 19 sockets fictícios — servidores à escuta, ligações estabelecidas, estados transitórios. No painel esquerdo vê todos os sockets que existem no kernel; no terminal à direita, os que sobrevivem às opções escolhidas. Clique nas opções (-t, -l, -n, -p, filtros de estado e de porto) para compor o seu próprio comando, use Demonstrar tudo para ver a sequência guiada completa, ou navegue passo a passo com Anterior e Seguinte. A nota por baixo dos botões explica o efeito de cada opção.
Erros comuns e boas práticas
- Esquecer o
-le concluir que «não há nada à escuta»: sem opções, osssó mostra ligações estabelecidas. - Correr sem
-nem investigações: a resolução de nomes atrasa o resultado e pode até avisar terceiros de que está a investigar (consultas DNS saem para a rede). Habitue-se ao-npor omissão. - Usar
-psem privilégios: sem root, a coluna do processo vem vazia para sockets de outros utilizadores — e a ausência não significa que o processo não exista. - Confundir
sportcomdport:sporté o porto local,dporto remoto. Para ver as ligações que a máquina fez para fora em HTTPS, o filtro certo édport = :443. - Estranhar o UDP sem
LISTEN: o UDP não estabelece ligação, por isso os serviços aparecem comoUNCONN— é o equivalente a estar à escuta. - Entrar em pânico com
TIME-WAIT: são ligações já fechadas à espera do temporizador do protocolo. Em grande número indicam ligações curtas em excesso, não um ataque. - Ignorar as colunas
Recv-Q/Send-Q: num socket à escuta,Send-Qé o tamanho do backlog eRecv-Qas ligações à espera deaccept(); valores encostados ao limite denunciam um serviço saturado.
Conclusão
O ss é a janela mais direta para a atividade de rede de um sistema Linux. Dominar meia dúzia de combinações — ss -tulnp para o inventário, state syn-recv para a deteção, dst para a caça a IPs — transforma minutos de investigação em segundos. Se gere utilizadores além de sockets, veja também o nosso artigo sobre o useradd.
Quer levar estas competências mais longe, ou precisa de apoio especializado em segurança e administração de sistemas? Conheça os serviços de formação e consultoria da HJFR no nosso catálogo de serviços — desenhamos percursos práticos para equipas técnicas e programas à medida para empresas.
Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.
