netstat mostra uma porta de escuta sem pid mas lsof não

Question

Esta pergunta é similar a Porta de rede aberta, mas nenhum processo anexado?

Eu tentei de tudo, analisei os logs, etc ... e não consigo encontrar nada.

Meu netstat mostra uma porta de escuta TCP e uma porta UDP sem um pid. Quando eu procuro lsof para essas portas, nada aparece.

netstat -lntup
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:44231           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:55234           0.0.0.0:*                           - 

Os seguintes comandos não exibem nada:

lsof | grep 44231
lsof | greo 55234
fuser -n tcp 44231
fuser -n udp 55234

Após a reinicialização, essas "mesmas" duas conexões estão lá, exceto com novos números de porta:

netstat -lntup
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:45082           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:37398           0.0.0.0:*                           - 

E mais uma vez, os comandos lsof e fuser não mostram nada.

Alguma idéia do que são? Eu deveria estar preocupado com eles?

    

Answer 1

Dos dados que você forneceu, eu diria que está relacionado a algumas montagens do NFS ou algo usando RPC.

você pode verificar com rpcinfo -p as portas que podem ser usadas por alguns serviços relacionados a RPC.

Aqui está como fica no meu sistema

# netstat -nlp | awk '{if ($NF == "-")print $0}'
tcp        0      0 0.0.0.0:55349           0.0.0.0:*               LISTEN      -               
udp        0      0 0.0.0.0:18049           0.0.0.0:*                           - 

# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  10249  status
    100024    1   tcp  10249  status
    100021    1   udp  18049  nlockmgr
    100021    3   udp  18049  nlockmgr
    100021    4   udp  18049  nlockmgr
    100021    1   tcp  55349  nlockmgr
    100021    3   tcp  55349  nlockmgr
    100021    4   tcp  55349  nlockmgr

    

Answer 2

Alguns processos / pids só estão disponíveis para root. Experimente

sudo netstat -antlp

ele deve retornar o pid de todas as portas abertas que não estão em um estado TIME_WAIT

    

Answer 3

Eu não sei o que são especificamente, mas os módulos do kernel (NFS, por exemplo) não têm um PID para associar a esses soquetes. Procure por algo suspeito em lsmod.

    

Answer 4

Com base na sugestão de @ user202173 e outros, pude usar o seguinte para rastrear o processo que possui uma porta mesmo quando ela está listada como - in netstat.

Aqui estava minha situação inicial. sudo netstat mostra a porta com PID / Programa de - . lsof -i não mostra nada.

$ sudo netstat -ltpna | awk 'NR==2 || /:8785/'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 :::8785                 :::*                    LISTEN      -
tcp6       1      0 ::1:8785                ::1:45518               CLOSE_WAIT  -
$ sudo lsof -i :8785
$

Agora vamos pescar. Primeiro vamos pegar o inode adicionando -e à nossa netstat call.

$ sudo netstat -ltpnae | awk 'NR==2 || /:8785/'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp6       0      0 :::8785                 :::*                    LISTEN      199179     212698803   -
tcp6       1      0 ::1:8785                ::1:45518               CLOSE_WAIT  0          0           -

Em seguida, use lsof para obter o processo anexado a esse inode.

$ sudo lsof | awk 'NR==1 || /212698803/'
COMMAND      PID    TID                USER   FD      TYPE             DEVICE   SIZE/OFF       NODE NAME
envelope_ 145661 145766               drees   15u     IPv6          212698803        0t0        TCP *:8785 (LISTEN)

Agora sabemos o ID do processo para podermos ver o processo. E infelizmente é um processo extinto. E seu PPID é 1, então não podemos matar seu pai também (veja Como eu posso matar um processo cujo pai é init? ). Em teoria, o init pode eventualmente limpá-lo, mas cansei de esperar e reinicializei.

$ ps -lf -p 145661
F S UID         PID   PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
0 Z drees    145661      1  2  80   0 -     0 exit   May01 ?        00:40:10 [envelope] <defunct>

    

Answer 5

Eu não sei se isso pode ser útil. Eu tive o mesmo problema e o que fiz foi o seguinte: Primeiro, chamei netstat com opções -a (all) e -e (extended). Com a última opção, posso ver o Inode associado à porta usada. Então, eu chamei lsof | grep com o número de inode obtido e recebi o PID de processo associado a esse inode. Isso funcionou no meu caso.

    

Answer 6

Existe algum tráfego vindo ou vindo dessa porta, verifique se com tcpdump -vv -x s 1500 port 37398 -w trace.out Salva sua captura no arquivo trace.out, você pode abri-lo com wireshark ou tcpdump -vv port 37398 e ver o que está acontecendo diretamente.

Tente fazer telnet para essa porta usando o netcat para o soquete udp, talvez você tenha algum tipo de banner que ajude.

Pegue o rkhunter e verifique seu sistema em busca de um backdoor.

Compare o hash md5 do lsof / netstat com o da sua mídia de instalação, assumindo que os arquivos não sejam updatet.