netstat montre un port d'écoute sans pid mais lsof ne le fait pas

Cette question est similaire au port réseau ouvert, mais aucun processus n'est attaché?

J'ai tout essayé à partir de là, j'ai examiné les journaux, etc ... et je ne trouve rien.

Mon netstat montre un port d'écoute TCP et un port UDP sans pid. Lorsque je recherche lsof pour ces ports, rien ne se produit.

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

Les commandes suivantes n'affichent rien:

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

Après le redémarrage, ces "mêmes" deux connexions sont là sauf avec de nouveaux numéros de port:

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

Et encore une fois, les commandes lsof et fuser ne montrent rien.

Des idées ce qu'elles sont? Dois-je m'en préoccuper?

D'après les données que vous avez fournies, je dirais que cela est lié à certains montages NFS ou à quelque chose utilisant RPC.

vous pouvez vérifier avec les rpcinfo -pports qui pourraient être utilisés par certains services liés à RPC.

Voici à quoi cela ressemble sur mon système

# 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

Certains processus / pids ne sont disponibles que pour root. Essayer

sudo netstat -antlp

il doit renvoyer le pid de chaque port ouvert qui n'est pas dans un état TIME_WAIT

Sur la base de l'indice de @ user202173 et d'autres, j'ai pu utiliser ce qui suit pour retrouver le processus qui possède un port même lorsqu'il est répertorié comme -dans netstat.

Voici ma situation de départ. sudo netstatmontre le port avec PID / Programme de -. lsof -ine montre rien.

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

Maintenant, allons pêcher. Commençons par obtenir l'inode en ajoutant -eà notre netstatappel.

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

Utilisez ensuite lsofpour obtenir le processus attaché à cet 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)

Maintenant, nous connaissons l'identifiant du processus afin que nous puissions examiner le processus. Et malheureusement, c'est un processus défunt. Et son PPID est 1 donc nous ne pouvons pas non plus tuer son parent (voir Comment puis-je tuer un processus dont le parent est init? ). En théorie, init pourrait éventuellement le nettoyer, mais je me suis lassé d'attendre et j'ai redémarré.

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

Je ne sais pas ce que ce sont spécifiquement, mais les modules du noyau (NFS par exemple) n'ont pas de PID à associer à ces sockets. Recherchez quelque chose de suspect dans lsmod.

Je ne sais pas si cela peut être utile. J'ai eu le même problème et ce que j'ai fait est le suivant: Tout d'abord, j'ai appelé netstat avec les options -a (tout) et -e (étendu). Avec cette dernière option, je peux voir l'inode associé au port utilisé. Ensuite, j'ai appelé lsof | grep avec le numéro d'inode obtenu et j'ai obtenu le PID du processus associé à cet inode. Cela a fonctionné dans mon cas.

Y a-t-il du trafic en provenance ou à destination de ce port, vérifiez qu'avec tcpdump -vv -x s 1500 port 37398 -w trace.outSauvegarde votre capture dans le fichier trace.out vous pouvez ensuite l'ouvrir avec wirehark ou tcpdump -vv port 37398et voir ce qui se passe directement.

Essayez de telnet sur ce port, utilisez netcat pour le socket udp, vous obtiendrez peut-être une sorte de bannière qui vous aidera.

Obtenez rkhunter et vérifiez votre système pour une porte dérobée.

Comparez le hachage md5 de lsof / netstat avec celui de votre support d'installation, en supposant que les fichiers ne sont pas mis à jour.