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

Некоторые процессы / pids доступны только для root. Пытаться

sudo netstat -antlp

он должен возвращать pid каждого открытого порта, который не находится в состоянии 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
$

Теперь пойдем на рыбалку. Сначала давайте получим индекс, добавив -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чтобы привязать процесс к этому индоду.

$ 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 с полученным номером инода и получил PID процесса, связанного с этим инодом. Это сработало в моем случае.

Есть ли какой-либо трафик, приходящий или уходящий с этого порта, проверьте, что с помощью команды « tcpdump -vv -x s 1500 port 37398 -w trace.outСохранение» в файле trace.out вы можете открыть его с помощью wireshark или tcpdump -vv port 37398посмотреть, что происходит напрямую.

Попробуйте подключиться к этому порту через telnet, используйте netcat для сокета udp, возможно, вы получите какой-то баннер, который поможет.

Получите rkhunter и проверьте вашу систему на наличие черного хода.

Сравните хэш md5 команды lsof / netstat с хешем с установочного носителя, если файлы не обновлены.