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

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

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

Мій 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 нічого не показують.

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

За наданими вами даними, я б сказав, що вони пов'язані з деякими кріпленнями 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

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

sudo netstat -antlp

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

На основі підказки від @ 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>

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

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

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

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

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

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