netstat pokazuje port nasłuchujący bez pid, ale lsof tego nie robi

To pytanie jest podobne do otwartego portu sieciowego, ale nie dołączono żadnego procesu?

Próbowałem już wszystkiego, sprawdziłem logi itp. I nic nie mogę znaleźć.

Mój netstat pokazuje port nasłuchiwania TCP i port UDP bez pid. Kiedy szukam tych portów, nic się nie pojawia.

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

Następujące polecenia nic nie wyświetlają:

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

Po ponownym uruchomieniu są tam te same „dwa” połączenia, z wyjątkiem nowych numerów portów:

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

I jeszcze raz polecenia lsof i utrwalacza nic nie pokazują.

Jakieś pomysły, czym one są? Czy powinienem się nimi martwić?

Z dostarczonych danych powiedziałbym, że jest to związane z niektórymi podłączeniami NFS lub czymś używającym RPC.

możesz sprawdzić rpcinfo -pza pomocą portów, które mogą być używane przez niektóre usługi związane z RPC.

Oto jak to wygląda w moim systemie

# 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

Niektóre procesy / pidy są dostępne tylko do rootowania. Próbować

sudo netstat -antlp

powinien zwrócić pid każdego otwartego portu, który nie jest w stanie TIME_WAIT

Na podstawie podpowiedzi @ user202173 i innych udało mi się użyć następujących elementów, aby wyśledzić proces będący właścicielem portu, nawet jeśli jest on wymieniony jako -netstat.

Oto moja sytuacja wyjściowa. sudo netstatpokazuje port z PID / Program z -. lsof -inic nie pokazuje.

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

Teraz chodźmy na ryby. Najpierw zdobądźmy i-węzeł dodając -edo naszego netstatpołączenia.

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

Następnie użyj, lsofaby przywiązać proces do tego i-węzła.

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

Teraz znamy identyfikator procesu, dzięki czemu możemy spojrzeć na proces. I niestety jest to proces nieczynny. A jego PPID wynosi 1, więc nie możemy zabić jego rodzica (zobacz Jak mogę zabić proces, którego rodzicem jest init? ). Teoretycznie init może w końcu to wyczyścić, ale miałem już dość czekania i zrestartowałem się.

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

Nie wiem, co to konkretnie, ale moduły jądra (na przykład NFS) nie mają PID do powiązania z tymi gniazdami. Poszukaj czegoś podejrzanego w lsmod.

Nie wiem, czy to może być przydatne. Miałem ten sam problem i to, co zrobiłem, to: Po pierwsze, wywołałem netstat z opcjami -a (wszystkie) i -e (rozszerzone). Dzięki tej drugiej opcji widzę i-węzeł powiązany z używanym portem. Następnie zadzwoniłem do lsof | grep z uzyskanym numerem i-węzła i otrzymałem PID procesu związanego z tym i-węzłem. To zadziałało w moim przypadku.

Czy jest jakiś ruch przychodzący lub wychodzący z tego portu, sprawdź, czy za pomocą tcpdump -vv -x s 1500 port 37398 -w trace.outZapisuje przechwytywanie w pliku trace.out, możesz następnie otworzyć go za pomocą wireshark lub tcpdump -vv port 37398zobaczyć, co się dzieje bezpośrednio.

Spróbuj telnet do tego portu, użyj netcat dla gniazda udp, może otrzymasz jakiś baner, który pomaga.

Pobierz rkhunter i sprawdź, czy w systemie nie ma backdoora.

Porównaj skrót md5 programu lsof / netstat z hasłem z nośnika instalacyjnego, zakładając, że pliki nie są aktualizowane.