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

21

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ć?

mhost
źródło

Odpowiedzi:

11

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
Hrvoje Špoljar
źródło
1
Jeśli masz ten problem i chcesz zmusić nlockmgr do używania określonych portów, wypróbuj to rozwiązanie: fclose.com/39625/fixing-ports-used-by-nfs-server .
Ryan Walls,
13

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

użytkownik1389651
źródło
2
wszystkie otwarte porty TCP tylko za pomocą tego polecenia. Porty UDP nie będą wyświetlane.
petrus
8

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>
studgeek
źródło
1
Od miesięcy szukam tego rozwiązania. dziękuję za ten jem
męski Prasad
Od lat szukam takiego rozwiązania. Dziękuję Ci! Jedną z wad tutaj jest to, że jeśli klient lub serwer NFS jest ugrzęznięty, wówczas lsof | awk 'NR==1 || /212698803/'(nawet przy lsof -Npokazaniu tylko NFS) może bardzo wolno reagować i może upłynąć limit czasu. Innym minusem jest to, że i-węzeł może się zmienić podczas rozwiązywania tego problemu.
Stefan Lasiewski
4

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.

andyortlieb
źródło
lsmod nic nie zwraca. Ten serwer jest klientem NFS. To obecnie mój podejrzany nr 1.
mhost
To by wyjaśniało, dlaczego porty klienta zmieniły się po nowej instancji jądra.
andyortlieb,
Nie powinieneś był być lekceważony, ponieważ jest to całkowicie uzasadniona odpowiedź. Pomogło mi to znaleźć przypadek, w którym inne odpowiedzi (użycie rpcbind lub lsof) nie pomogły. (I tak, to był NFS.) Dzięki!
Peter Hansen
Hmm, zastanawiam się, dlaczego nie przypisuje PID do klienta NFS, żebyś mógł zobaczyć, co jest grane ... Myślę, że wymagałoby to wątku roboczego lub czegoś takiego?
SamB
3

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.

użytkownik202173
źródło
0

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.

Izac
źródło
Próbowałem lokalnie netcat do obu portów i nic nie wyświetla. Dla portu tcp zamyka się, jeśli coś wpisuję, a następnie wpisuję. Jeden UDP zamyka się tylko po naciśnięciu Ctrl + C. Mam iptables na swoim miejscu i nie pozwala to na połączenia z tymi portami, więc jeśli nie omijają iptables, nie mogę sobie wyobrazić, że coś się z nimi łączy.
mhost
jakiego rodzaju serwera to DB, APP .. z jakiego oprogramowania korzystasz?
Izac
Jest to serwer WWW z uruchomionym Apache i praktycznie niczym innym jak cron i syslog.
mhost