netstat zeigt einen Listening-Port ohne pid an, lsof jedoch nicht

Diese Frage ist ähnlich wie Netzwerkanschluss offen, aber kein Prozess angeschlossen?

Ich habe von dort aus alles ausprobiert, die Protokolle überprüft usw. und kann nichts finden.

Mein Netstat zeigt einen TCP-Listening-Port und einen UDP-Port ohne PID. Wenn ich lsof nach diesen Ports suche, passiert nichts.

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

Die folgenden Befehle zeigen nichts an:

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

Nach dem Neustart sind diese "gleichen" zwei Verbindungen vorhanden, außer mit neuen Portnummern:

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

Und wieder zeigen die Befehle lsof und fuser nichts an.

Irgendwelche Ideen, was sie sind? Sollte ich mir Sorgen um sie machen?

Aus den von Ihnen angegebenen Daten geht hervor, dass sie mit einigen NFS-Bereitstellungen oder mit RPC zusammenhängen.

Sie können bei rpcinfo -pnach Ports suchen, die möglicherweise von einigen RPC-bezogenen Diensten verwendet werden.

So sieht es auf meinem System aus

# 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

Einige Prozesse / Pids sind nur für root verfügbar. Versuchen

sudo netstat -antlp

Es sollte die PID jedes offenen Ports zurückgeben, der sich nicht in einem TIME_WAIT-Status befindet

Basierend auf dem Hinweis von @ user202173 und anderen konnte ich das Folgende verwenden, um den Prozess aufzuspüren, der einen Port besitzt, selbst wenn er wie -in netstat aufgeführt ist.

Hier war meine Ausgangssituation. sudo netstatzeigt Port mit PID / Programm von -. lsof -izeigt nichts.

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

Jetzt lass uns fischen gehen. Lassen Sie uns zuerst die Inode durch Hinzufügen -ezu unserem netstatAnruf erhalten.

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

Verwenden Sie Next lsof, um den Prozess an diesen Inode anzuhängen.

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

Jetzt kennen wir die Prozess-ID, damit wir uns den Prozess ansehen können. Und leider ist es ein nicht mehr laufender Prozess. Die PPID ist 1, daher können wir auch die übergeordnete Instanz nicht beenden (siehe Wie kann ich einen Prozess beenden, dessen übergeordnete Instanz init ist? ). Theoretisch könnte init irgendwann aufräumen, aber ich hatte es satt zu warten und wurde neu gestartet.

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

Ich weiß nicht genau, was das ist, aber Kernelmodule (z. B. NFS) haben keine PID, die diesen Sockets zugeordnet werden kann. Suchen Sie nach etwas Verdächtigem in lsmod.

Ich weiß nicht, ob das nützlich sein kann. Ich hatte das gleiche Problem und habe Folgendes getan: Zuerst habe ich netstat mit den Optionen -a (alle) und -e (erweitert) aufgerufen. Mit der letzteren Option kann ich den Inode sehen, der dem verwendeten Port zugeordnet ist. Dann rief ich lsof | grep mit der erhaltenen Inode-Nummer auf und erhielt die PID des Prozesses, der dieser Inode zugeordnet ist. Das hat in meinem Fall funktioniert.

Kommt oder geht Datenverkehr von diesem Port aus, überprüfen Sie, tcpdump -vv -x s 1500 port 37398 -w trace.outob Sie das Capture in der Datei trace.out mit Wireshark speichern oder tcpdump -vv port 37398direkt anzeigen können, was gerade passiert.

Versuchen Sie, per Telnet auf diesen Port zuzugreifen. Verwenden Sie Netcat für den UDP-Socket. Vielleicht erhalten Sie eine Art Banner, das hilft.

Holen Sie sich rkhunter und überprüfen Sie Ihr System auf eine Hintertür.

Vergleichen Sie den md5-Hash von lsof / netstat mit dem von Ihrem Installationsmedium, vorausgesetzt, die Dateien wurden nicht aktualisiert.