Этот вопрос похож на Сетевой порт открыт, но процесс не подключен?
Я перепробовал все оттуда, просмотрел журналы и т. Д. И ничего не нашел.
Моя 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 ничего не показывают.
Есть идеи, что они есть? Стоит ли о них беспокоиться?
Некоторые процессы / идентификаторы доступны только для root. Пытаться
sudo netstat -antlp
он должен возвращать pid каждого открытого порта, который не находится в состоянии TIME_WAIT
Из предоставленных вами данных я бы сказал, что это связано с некоторыми монтировками 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
Основываясь на подсказке от @ 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 чтобы прикрепить процесс к этому 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 (расширенный). В последнем варианте я вижу индексный дескриптор, связанный с используемым портом. Затем я вызвал lsof | grep с полученным номером inode и получил PID процесса, связанного с этим inode. В моем случае это сработало.
Есть ли трафик, идущий или исходящий из этого порта, проверьте это с помощью tcpdump -vv -x s 1500 port 37398 -w trace.out Сохраняет ваш снимок в файле trace.out, который затем можно открыть с помощью wirehark или tcpdump -vv port 37398 и посмотреть, что происходит прямо.
Попробуйте подключиться к этому порту по telnet, используя netcat для сокета udp, возможно, вы получите какой-то баннер, который поможет.
Получите rkhunter и проверьте свою систему на наличие бэкдора.
Сравните хэш md5 lsof / netstat с хешем с вашего установочного носителя, предполагая, что файлы не обновляются.