Como faço para listar todos os sockets que estão abertos para máquinas remotas?

Question

Uma baunilha ss -l lista (na minha máquina atual) muitos sockets abertos, com vários tipos de Netid e muitos dos quais estão apenas escutando em localhost.

Como faço para obter uma lista de todos e apenas os soquetes através dos quais uma máquina remota pode possivelmente trocar dados com a máquina?

• Isso inclui TCP, UDP, qualquer outro protocolo de camada de transporte, soquetes RAW e outros que eu possa não estar ciente. (O ss está completo neste sentido?)

• Acredito que isso excluiria os sockets do UNIX (eles estão apenas no sistema de arquivos local, certo? ou dos sockets do UNIX podem agir remotamente, eles devem ser incluídos).

• Os ouvintes restritos ao localhost podem ser ignorados, mas não sei se há alguma limitação em termos de como o host local pode ser representado / mapeado.

O critério essencial é "qualquer socket que eu possa ser remotamente hackeado, se o processo de escuta permitir".

(lembro que os comandos ss de alguns anos atrás mostraram lote menos resultados do que recebo agora. Isso me faz pensar se algumas distribuições configuram ss para ocultar coisas por padrão. Eu estou procurando um ss ou comando utilitário semelhante que é tão portátil quanto possível, na medida em que não vai esconder nada só porque foi executado em um ambiente diferente. Além disso, do ponto de vista da segurança-teórica, nós Podemos supor para o modelo de ameaça que a máquina está totalmente sob nosso controle e está executando um software comum, não malicioso.)

Então, como listar todos e apenas os soquetes relevantes?

    

Answer 1

Na maioria dos ambientes, você esperaria ver soquetes tcp, udp, raw e de pacote, todos suportados por ss . Se ss suportar os protocolos necessários, você poderá usar ss -l | grep -vE '^(nl |u_) .

Lembre-se de que, se desejar informações sobre os programas de listagem ( -p ), será necessário executar ss (ou netstat ) com privilégios de root (sudo).

Quão abrangente é isso?

Apesar de ser anunciado como um substituto para o netstat, ss não tem suporte para mostrar os soquetes do UDPLite. (E quando essa resposta foi originalmente escrita, antes de 2017 , ss não era compatível com SCTP. netstat de suporte desde fevereiro de 2014 . Espera-se que o SCTP apareça especificamente dentro empresas telefônicas; fora desse contexto, o VOIP geralmente usa o udp.).

Infelizmente, se você procurar uma lista abrangente em man netstat , fica bastante confuso. Opções para sctp e udplite são mostradas na primeira linha, juntamente com tcp, udp e raw. Mais abaixo há o que parece ser uma lista abrangente de famílias de protocolo : [-4 | --inet] [-6 | --inet6] [--unix | -x] [--inet | - -ip | --tcpip] [--ax25] [--x25] [--rose] [--ash] [--bluetooth] [--ipx] [--netrom] [--ddp | --appletalk ] [--econet | --ec].

Embora netstat suporte udplite e sctp, ele não suporta o DCCP. O netstat também não suporta soquetes de pacotes (como soquetes brutos, mas incluindo cabeçalhos de nível de link), conforme selecionado por ss -l -0 . Em conclusão, eu odeio tudo, e eu provavelmente poderia ser menos pedante.

Existe um comando mais simples?

É lamentável sobre os soquetes de pacotes. Caso contrário, posso sugerir um comando netstat -l simples. netstat antecipa sua solicitação e divide a saída em "conexões da Internet", "soquetes de domínio UNIX" e "conexões Bluetooth". Você apenas olharia para a primeira seção. Não há seção para sockets netlink.

Suponha que você esteja preocupado apenas com os sockets tcp, udp, raw e packet. Para os três primeiros tipos de socket, você pode usar netstat -l -46 .

Soquetes de pacote são de uso comum. Então você também precisa treinar para executar ss -l -0 (ou ss -l --packet ).

Infelizmente isso deixa você com uma grande armadilha. O problema é que agora é tentador tentar combinar os dois comandos ...

Um aviso terrível

ss -l -046 parece atraente como uma resposta de comando único. No entanto, isso não é verdadeiro. ss -46 mostra apenas sockets IPv6. ss -64 mostra apenas sockets IPv4.

Eu sugiro sempre checar seus resultados. Aprenda o que esperar; passar por cada protocolo e ver se há algo faltando que deveria estar lá. Se você não tiver endereços IPv4 ou nenhum endereço IPv6, isso é muito suspeito. Você pode esperar que a maioria dos servidores tenha um serviço SSH atendendo em ambos. A maioria dos não servidores também deve mostrar pacotes ou soquetes brutos, devido ao uso do DHCP.

Se você não quiser interpretar a saída de dois comandos diferentes, uma alternativa seria substituir o comando netstat por ss -l -A inet . Isso é um pouco infeliz porque, quando você executa o netstat, a mesma opção excluiria os soquetes do ipv6. Eu consideraria esses pontos como deficiências de UI mais sérias em ss . Ou seja justificaria a preferência pelo tradicional netstat .

Um único comando que realmente funciona seria ss -l -A inet,packet . Mas se você estiver trabalhando de forma interativa, você pode usar ss -l | grep ... como sugeri na primeira seção. Este último é menos limpo, e o comando específico assume ss não suporta sockets bluetooth. No entanto, essa abordagem tem a grande vantagem de evitar todos os terríveis bugs de interface do usuário nas opções de seleção de ss .

Omitindo localhost

Desculpe, mas não há uma maneira específica de omitir soquetes vinculados ao host local. Use | grep -v no final. Tome cuidado se você usar a opção -p para netstat / ss. Eu incluiria o cólon no seu padrão, e. %código%. ss padroniza para endereços numéricos, o que significaria usar grep -v localhost: . Você pode verificar se nenhum dos seus processos será excluído acidentalmente, por exemplo, | grep -vE (127.0.0.1|::): .