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


21

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?

Réponses:


11

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

1
Si vous rencontrez ce problème et que vous souhaitez forcer nlockmgr à utiliser des ports spécifiques, essayez cette solution: fclose.com/39625/fixing-ports-used-by-nfs-server .
Ryan Walls

13

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


2
tous les ports TCP ouverts uniquement avec cette commande. Les ports UDP ne seront pas affichés.
petrus

8

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>

1
Je recherche cette solution depuis des mois maintenant. merci pour ce jem
manish Prasad

Je cherche une solution comme celle-ci depuis des années. Merci! L'un des inconvénients ici est que si un client ou un serveur NFS est enlisé, alors lsof | awk 'NR==1 || /212698803/'(même avec lsof -Npour afficher NFS uniquement) peut être très lent à répondre et peut expirer. Un autre inconvénient est que l'inode peut changer pendant que vous dépannez cela.
Stefan Lasiewski

4

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.


lsmod ne renvoie rien. Ce serveur est un client NFS. C'est actuellement mon suspect n ° 1.
mhost

Cela expliquerait pourquoi les ports clients ont changé après une nouvelle instance du noyau.
andyortlieb

Vous n'auriez pas dû être rétrogradé car c'est une réponse tout à fait légitime. Cela m'a aidé à trouver un cas où les autres réponses (en utilisant rpcbind ou lsof) n'ont pas aidé. (Et oui, c'était NFS.) Merci!
Peter Hansen

Hmm, je me demande pourquoi il n'attribue pas de PID au client NFS juste pour que vous puissiez voir ce qui se passe ... Je suppose que cela nécessiterait d'avoir un thread de travail ou quelque chose?
SamB

3

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.


0

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.


J'ai essayé de netcat localement sur les deux ports et il n'affiche rien. Pour le port TCP, il se ferme si je tape quelque chose et que j'entre. L'UDP ne ferme que si j'appuie sur Ctrl + C. J'ai des iptables en place, et cela ne permet pas les connexions à ces ports, donc à moins qu'ils ne contournent les iptables, je ne peux pas imaginer que quelque chose se connecte à eux.
mhost

quel type de serveur est-ce DB, APP .. quel logiciel utilisez-vous?
Izac

Il s'agit d'un serveur Web exécutant Apache et à peu près rien d'autre que des choses comme Cron et Syslog.
mhost
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.