netstat показує порт прослуховування без pid, але lsof - ні


21

Це питання схоже на мережевий порт відкритий, але жодного процесу не додано?

Я спробував усе звідти, переглянув журнали тощо ... і нічого не можу знайти.

Мій netstat показує порт прослуховування TCP та порт UDP без pid. Коли я шукаю lsof для цих портів, нічого не з'являється.

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

Наступні команди нічого не відображають:

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

Після перезавантаження ці "ті самі" два з'єднання є, за винятком нових номерів портів:

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

І вкотре команди lsof та fuser нічого не показують.

Якісь ідеї, які вони? Чи варто їх турбувати?

Відповіді:


11

За наданими вами даними, я б сказав, що вони пов'язані з деякими кріпленнями NFS або чимось із використанням RPC.

Ви можете перевірити наявність rpcinfo -pпортів, які можуть використовуватися деякими службами RPC.

Ось як це виглядає в моїй системі

# 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
Якщо у вас є ця проблема і ви хочете змусити nlockmgr використовувати конкретні порти, спробуйте це рішення: fclose.com/39625/fixing-ports-used-by-nfs-server .
Ryan Walls

13

Деякі процеси / PID доступні лише для root. Спробуйте

sudo netstat -antlp

він повинен повернути під кожного відкритого порту, який не знаходиться в TIME_WAIT стані


2
кожен відкритий порт TCP тільки з цією командою. Порти UDP не відображатимуться.
petrus

8

На основі підказки від @ user202173 та інших я зміг використати наступне, щоб відстежити процес, яким належить порт, навіть коли він вказаний як -в netstat.

Тут була моя вихідна ситуація. sudo netstatпоказує порт з PID / Програмою -. lsof -iнічого не показує.

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

Тепер підемо на риболовлю. Спершу давайте отримаємо inode, додавши -eдо нашого netstatдзвінка.

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

Далі використовуйте, lsofщоб приєднати процес до цього 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)

Тепер ми знаємо ідентифікатор процесу, щоб ми могли подивитися на процес. І, на жаль, це неіснуючий процес. І його PPID дорівнює 1, тому ми також не можемо вбити його батька (див. Як я можу вбити процес, батько якого є init? ). Теоретично init може врешті-решт очистити його, але я втомився чекати і перезавантажився.

$ 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
Ми шукали це рішення вже місяцями. дякую за цей джем
маніакальний Прасад

Я шукав таке рішення протягом багатьох років. Дякую! Один з недоліків тут полягає в тому, що якщо клієнт або сервер NFS забився, то реагувати lsof | awk 'NR==1 || /212698803/'(навіть lsof -Nякщо показувати лише NFS) може дуже повільно реагувати, і він може затримати час. Ще один недолік полягає в тому, що вкладка може змінюватися під час усунення несправностей.
Стефан Ласевський

4

Я не знаю, що це конкретно, але модулі ядра (наприклад, NFS) не мають PID, який би асоціювався з цими сокетами. Шукайте щось підозріле у lsmod.


lsmod нічого не повертає. Цей сервер є клієнтом NFS. Наразі це мій підозрюваний №1.
март

Це пояснило б, чому клієнтські порти змінилися після нового примірника ядра.
andyortlieb

Вам не варто було б бути знятим, оскільки це абсолютно законна відповідь. Це допомогло мені знайти випадок, коли інші відповіді (за допомогою rpcbind або lsof) не допомогли. (І так, це був NFS.) Дякую!
Пітер Хансен

Хм, мені цікаво, чому він не призначає PID клієнту NFS, щоб ви могли побачити, що з цим ... Думаю, для цього потрібна робоча нитка чи щось таке?
СамБ

3

Я не знаю, чи це може бути корисно. У мене була така ж проблема, і я зробив наступне: По-перше, я зателефонував до netstat з опціями -a (всі) та -e (розширений). При останньому варіанті я бачу Inode, пов'язаний з використовуваним портом. Потім я зателефонував lsof | grep з отриманим номером inode, і я отримав PID процесу, пов'язаного з цим інодом. Це спрацювало в моєму випадку.


0

Чи є якийсь трафік, який надходить або йде з цього порту, переконайтеся, що за допомогою tcpdump -vv -x s 1500 port 37398 -w trace.outпрограми "Збереже ваше захоплення у файлі trace.out" ви можете відкрити його за допомогою проводки або tcpdump -vv port 37398побачити, що відбувається безпосередньо.

Спробуйте звернути телнет до цього порту, використовуючи netcat для сокета udp, можливо, ви отримаєте якийсь банер, який допомагає.

Отримайте rkhunter і перевірте систему на наявність задніх куточків.

Порівняйте хеш md5 lsof / netstat з файлом із встановленого носія, припустивши, що файли не оновлені.


Я намагався локально netcat до обох портів, і це нічого не відображає. Для порту tcp він закривається, якщо я щось набираю, а потім вводя. UDP один закривається, лише якщо натиснути Ctrl + C. У мене є iptables, і він не дозволяє з'єднатися з тими портами, тому, якщо вони не обходять iptables, я не можу уявити, що щось з ними з'єднується.
mhost

який сервер це DB, APP .. яке програмне забезпечення ви використовуєте?
Ізак

Це веб-сервер під управлінням apache і майже нічого іншого, крім речей, таких як cron та syslog.
март
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.