netstat mostra una porta di ascolto senza pid ma lsof no

Questa domanda è simile alla porta di rete aperta, ma nessun processo collegato?

Ho provato di tutto da lì, ho rivisto i log, ecc ... e non riesco a trovare nulla.

Il mio netstat mostra una porta di ascolto TCP e una porta UDP senza pid. Quando cerco lsof per quelle porte non viene visualizzato nulla.

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:*                           - 

I seguenti comandi non visualizzano nulla:

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

Dopo il riavvio, quelle "stesse" due connessioni sono presenti tranne che con i nuovi numeri di 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 ancora una volta, i comandi lsof e fuser non mostrano nulla.

Qualche idea di cosa siano? Dovrei essere preoccupato per loro?

Dai dati che hai fornito direi che è correlato ad alcuni montaggi NFS o qualcosa che utilizza RPC.

è possibile verificare con le rpcinfo -pporte che potrebbero essere utilizzate da alcuni dei servizi correlati RPC.

Ecco come appare sul mio 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

Alcuni processi / pid sono disponibili solo per il root. Provare

sudo netstat -antlp

dovrebbe restituire il pid di ogni porta aperta che non si trova in uno stato TIME_WAIT

Sulla base del suggerimento di @ user202173 e altri, sono stato in grado di utilizzare quanto segue per rintracciare il processo che possiede una porta anche quando è elencato come -in netstat.

Ecco la mia situazione iniziale. sudo netstatmostra la porta con PID / Programma di -. lsof -inon mostra nulla.

$ 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
$

Ora andiamo a pescare. Per prima cosa otteniamo l'inode aggiungendo -ealla nostra netstatchiamata.

$ 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           -

Uso successivo lsofper associare il processo a quell'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)

Ora conosciamo l'id del processo in modo da poter esaminare il processo. E purtroppo è un processo defunto. E il suo PPID è 1, quindi non possiamo neanche uccidere il suo genitore (vedi Come posso uccidere un processo il cui genitore è init? ). In teoria init potrebbe eventualmente risolverlo, ma mi sono stancato di aspettare e riavviato.

$ 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>

Non so cosa siano nello specifico, ma i moduli del kernel (ad esempio NFS) non hanno un PID da associare a questi socket. Cerca qualcosa di sospetto in lsmod.

Non so se questo può essere utile. Ho avuto lo stesso problema e quello che ho fatto è il seguente: in primo luogo, ho chiamato netstat con le opzioni -a (tutte) e -e (estese). Con quest'ultima opzione posso vedere l'Inode associato alla porta utilizzata. Quindi, ho chiamato lsof | grep con il numero di inode ottenuto e ho ottenuto il PID del processo associato a quell'inode. Nel mio caso ha funzionato.

C'è traffico proveniente da questa porta, controlla che con tcpdump -vv -x s 1500 port 37398 -w trace.outSalva la tua acquisizione nel file trace.out sia possibile aprirlo con WireShark o tcpdump -vv port 37398vedere cosa succede direttamente.

Prova a telnet su quella porta, usa netcat per il socket udp, forse otterrai una sorta di banner che aiuta.

Ottieni rkhunter e controlla il tuo sistema per una backdoor.

Confronta l'hash md5 di lsof / netstat con quello del tuo media di installazione, assumendo i file dove non si aggiorna.