Verificar portas abertas no Linux: ss, netstat, lsof, nmap

Verificar portas abertas com o ss, o padrão moderno

Toda porta aberta em um sistema Linux existe porque algum processo pediu ao kernel para escutar nela. A ferramenta que mostra esses sockets hoje é o ss (socket statistics), parte do conjunto iproute2 instalado em todas as distribuições modernas. Um único comando cobre a maioria das situações:

sudo ss -tulpn

Cada opção faz uma coisa:

• -t: inclui sockets TCP
• -u: inclui sockets UDP
• -l: mostra apenas os sockets em escuta (remova-a para ver também as conexões estabelecidas)
• -p: mostra o processo proprietário de cada socket; é por isso que você quer o sudo, pois sem ele só vê os seus próprios processos
• -n: saída numérica, que imprime :22 em vez de :ssh e dispensa as consultas DNS inversas, o que também deixa o comando mais rápido

Uma linha típica da saída se parece com esta:

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

A coluna Local Address é a que importa para a segurança. 0.0.0.0:22 significa que o socket aceita conexões em todas as interfaces IPv4, [::]:22 é o equivalente IPv6, e 127.0.0.1:5432 significa que o serviço responde apenas no loopback e não pode ser alcançado pela rede.

Algumas variações que vale a pena memorizar:

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

O netstat ainda funciona, mas é legado

Milhões de tutoriais ainda dizem netstat -tulpn, e as opções correspondem uma a uma ao comando ss acima, então a memória muscular serve nos dois sentidos. A diferença está por baixo do capô: o netstat pertence ao pacote net-tools, em modo de manutenção, e lê arquivos em /proc, enquanto o ss consulta o kernel diretamente via netlink, o que é visivelmente mais rápido em máquinas com milhares de sockets.

A maioria das distribuições atuais já não inclui o net-tools por padrão. Se você precisar dele mesmo assim:

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

Não há razão para instalá-lo em um servidor novo. Trate o netstat como alternativa de compatibilidade para sistemas antigos que você herda, e use o ss em todo o resto.

lsof: as portas pela ótica dos processos

No Linux tudo é um arquivo, inclusive os sockets de rede, então o lsof (list open files) também serve como inspetor de portas. Ele brilha quando você já raciocina em termos de processos, e não de portas:

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

-P e -n desativam a resolução de nomes de porta e de host, a mesma ideia do -n em ss -tulpn. A terceira forma é a do dia a dia: aponte-a para uma porta e você obtém o nome do comando, o PID, o usuário e o descritor de arquivo em uma tabela legível. Ao contrário do ss, o lsof também lista as conexões estabelecidas de cada processo ao lado dos seus ouvintes, o que ajuda quando você quer saber quem está falando com um serviço agora, e não apenas que o serviço existe.

nmap: estar em escuta não é o mesmo que estar acessível

Tudo até aqui responde a uma pergunta: o que está em escuta nesta máquina. Outra pergunta importa mais para a segurança: o que realmente pode ser alcançado de fora. As duas listas raramente são idênticas, porque firewalls locais, filtragem no nível do provedor e vínculos apenas em loopback criam lacunas entre elas. É também por isso que escanear a si mesmo de dentro prova pouco: nmap localhost passa pela interface de loopback, ignora completamente as regras do seu firewall externo e reporta tranquilamente serviços que nenhum atacante conseguiria alcançar.

Execute o escaneamento de outra máquina, apontando para o IP público do servidor:

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

O nmap informa três estados que vale entender: open significa que um serviço respondeu, closed significa que o pacote chegou mas nada escuta ali, e filtered significa que o pacote foi descartado em silêncio, quase sempre por um firewall. Uma porta que o ss mostra como LISTEN mas que um nmap remoto reporta como filtered é exatamente a aparência de um firewall funcionando. Uma regra vale sem exceção: escaneie apenas hosts que sejam seus ou que você esteja explicitamente autorizado a testar.

Descobrir exatamente qual processo detém uma porta

Suponha que algo esteja ocupando a porta 8080 e sua aplicação não consiga se vincular. Três caminhos levam ao PID:

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

O fuser é o mais compacto: imprime o PID, e -v acrescenta o usuário e o nome do comando. Ele pode até encerrar o culpado diretamente com fuser -k 8080/tcp, mas isso envia um sinal sem nenhuma limpeza no nível do serviço, então trate-o como último recurso. Com um PID em mãos, ps -fp PID mostra a linha de comando completa, e systemctl status PID indica qual unidade systemd o iniciou.

Quando você não tem ferramenta nenhuma (em uma imagem de contêiner enxuta, por exemplo), a tabela do próprio kernel está sempre lá: cat /proc/net/tcp. As portas aparecem em hexadecimal (0016 é a 22) e o estado 0A significa LISTEN. Essa tabela bruta é justamente o dado que as outras ferramentas leem e formatam para você.

Tudo que vincula um socket aparece nessas listagens da mesma forma, seja um banco de dados ou uma pilha de proxy. Um inbound do V2Ray, por exemplo, é apenas mais um ouvinte na porta que você configurou, como explicamos no nosso guia do protocolo V2Ray.

Fechar uma porta aberta: kill ou firewall

Uma porta está aberta porque um processo escuta nela, o que lhe dá duas alavancas distintas: remover o ouvinte ou bloquear o acesso. Elas não são intercambiáveis e, em qualquer coisa importante, normalmente convém acionar as duas.

A correção limpa é parar e desativar o serviço proprietário do socket. Matar o PID parece mais rápido, mas raramente resolve: o systemd reinicia automaticamente os serviços supervisionados, e a porta volta antes de você rodar o ss de novo. Reserve o kill para processos que você iniciou manualmente. Para ver o que está rodando e desligar o que não é necessário, nosso guia sobre listar serviços com o systemctl cobre esse fluxo de ponta a ponta.

sudo systemctl stop cups
sudo systemctl disable cups

O firewall cuida da segunda alavanca. No Ubuntu, autorize o SSH antes de ativar o ufw, ou você se trancará fora da máquina:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Nos sistemas da família RHEL, a zona padrão do firewalld já descarta o tráfego não solicitado; remova o que você tiver aberto antes com firewall-cmd --permanent --remove-port=8080/tcp seguido de firewall-cmd --reload. Uma coisa que não é solução: mudar um serviço para uma porta fora do padrão. Isso o esconde dos escaneamentos mais preguiçosos e reduz o ruído nos logs, mas nmap -p- encontra a nova porta em minutos. Obscuridade não é segurança — feche a porta ou proteja-a com firewall.

Uma auditoria de portas em cinco minutos para um servidor novo

No primeiro login em uma máquina recém-provisionada, faça o inventário com sudo ss -tulpn. Uma instalação mínima e limpa deve mostrar muito pouco: sshd na 22 e, nas distribuições que usam systemd-resolved, um stub DNS em 127.0.0.53:53. Qualquer outra coisa merece explicação. Depois siga esta lista de verificação:

1. Identifique cada ouvinte por nome de processo e PID; desative qualquer serviço que você não pediu.
2. Questione todo vínculo em 0.0.0.0 ou [::]: bancos de dados e painéis de administração pertencem a 127.0.0.1, a menos que realmente sirvam a rede.
3. Reconheça as portas comuns de imediato: 22 SSH, 80/443 web, 3306 MySQL, 5432 PostgreSQL, 6379 Redis. A porta 3389 é a de área de trabalho remota. No Linux significa que o xrdp está rodando, e as regras de exposição e blindagem dessa porta são o tema do nosso guia da porta RDP 3389.
4. Escaneie o IP público da sua própria máquina com nmap -p- e compare o resultado com a lista do ss; cada divergência é ou um firewall fazendo seu trabalho ou um vínculo em loopback.
5. Termine com um firewall de negação por padrão que autorize apenas as portas que você escolheu expor de forma consciente.

Aqui está a caixa de ferramentas inteira, uma linha para cada:

Os comandos só se tornam reflexo em uma máquina onde você tem root de verdade e nada de importante pode quebrar. Um VPS Linux da rdp.monster lhe dá exatamente esse laboratório: acesso administrativo total, CPU e RAM dedicados, banda ilimitada (fair-use), sem KYC, e o servidor fica online cerca de 10 segundos após a confirmação do pagamento, rápido o bastante para rodar seu primeiro ss -tulpn antes que o café esfrie.

Perguntas frequentes

Preciso de root para verificar as portas abertas no Linux?

Não para listar as portas, sim para ver qual processo as detém.

Qualquer usuário pode executar ss -tuln ou ler /proc/net/tcp, então a lista das portas em escuta nunca fica oculta. O limite está na opção -p: sem root, ss, lsof e fuser só revelam processos do seu próprio usuário, e os outros sockets aparecem com a coluna de processo vazia. Com o nmap, o escaneamento SYN padrão (-sS) exige root; a alternativa sem privilégios é o connect scan (-sT), que funciona bem, mas é um pouco mais ruidoso.

Como verificar se uma porta específica está aberta em um servidor remoto?

Use o netcat: nc -zv host porta dá uma resposta imediata.

nc -zv example.com 443 tenta uma conexão TCP e informa sucesso ou falha sem enviar dados. Se o netcat não estiver disponível, o próprio Bash resolve: timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. Ambos apenas provam que algo aceitou a conexão: nada dizem sobre qual serviço respondeu nem se ele está saudável. Para UDP não há teste rápido confiável, porque uma porta silenciosa pode estar aberta ou filtrada; ali use nmap -sU.

Por que o ss mostra uma porta em escuta mas não consigo conectar de fora?

O socket está vinculado ao loopback ou um firewall está descartando o tráfego.

Verifique primeiro a coluna Local Address: 127.0.0.1:PORT ou [::1]:PORT significa que o serviço aceita apenas conexões locais, o que é deliberado e comum em bancos de dados. Se estiver vinculado a 0.0.0.0, os pacotes estão sendo filtrados em algum ponto do caminho: um firewall local como ufw, firewalld ou nftables puro, ou a filtragem de borda do seu provedor. Um escaneamento nmap externo que reporta a porta como filtered confirma um firewall; closed significa que o tráfego chega mas nada escuta naquela interface.

Quais portas devem estar abertas em um servidor Linux novo?

Uma: SSH. Qualquer outra coisa em uma instalação limpa merece explicação.

Uma instalação mínima de Debian, Ubuntu ou Rocky deve expor à rede apenas o sshd na porta 22. Um resolvedor DNS stub em 127.0.0.53:53 (systemd-resolved) é normal e inacessível de fora. Imagens de nuvem às vezes acrescentam um agente ou um daemon de monitoramento. Identifique cada ouvinte com ss -tulpn e desative tudo que você não pediu. Todo serviço que você instalar depois deve escutar por padrão no loopback, a menos que precise realmente servir a rede, com o firewall autorizando somente o que é público.