netstat cho thấy một cổng nghe không có pid nhưng lsof thì không

Câu hỏi này tương tự như cổng mạng mở, nhưng không có quy trình kèm theo?

Tôi đã thử mọi thứ từ đó, xem lại nhật ký, v.v ... và không thể tìm thấy gì.

Netstat của tôi hiển thị cổng nghe TCP và cổng UDP không có pid. Khi tôi tìm kiếm lsof cho các cổng đó, không có gì xuất hiện.

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

Các lệnh sau không hiển thị gì:

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

Sau khi khởi động lại, hai kết nối "giống nhau" đó sẽ xuất hiện ngoại trừ số cổng mới:

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

Và một lần nữa, các lệnh lsof và fuser không hiển thị gì.

Bất kỳ ý tưởng họ là gì? Tôi có nên quan tâm đến họ?

Từ dữ liệu bạn cung cấp, tôi muốn nói rằng nó có liên quan đến một số gắn kết NFS hoặc một cái gì đó sử dụng RPC.

bạn có thể kiểm tra rpcinfo -pcác cổng có thể được sử dụng bởi một số dịch vụ liên quan đến RPC.

Đây là giao diện của hệ thống của tôi

# 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

Một số quy trình / pids chỉ có sẵn để root. Thử

sudo netstat -antlp

nó sẽ trả về giá trị của mỗi cổng mở không ở trạng thái TIME_WAIT

Dựa trên gợi ý từ @ user202173 và những người khác, tôi đã có thể sử dụng cách sau để theo dõi quá trình sở hữu một cổng ngay cả khi nó được liệt kê như -trong netstat.

Đây là tình huống bắt đầu của tôi. sudo netstathiển thị cổng với PID / Chương trình của -. lsof -icho thấy không có gì.

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

Bây giờ hãy đi câu cá. Trước tiên, hãy lấy inode bằng cách thêm -evào netstatcuộc gọi của chúng tôi .

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

Tiếp theo sử dụng lsofđể có được quá trình gắn liền với 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)

Bây giờ chúng tôi biết id quá trình để chúng tôi có thể xem xét quá trình. Và thật không may, đó là một quá trình không còn tồn tại. Và PPID của nó là 1 vì vậy chúng ta cũng không thể giết cha mẹ của nó (xem Làm thế nào tôi có thể giết một quá trình có cha mẹ là init? ). Về lý thuyết, init có thể sẽ dọn sạch nó, nhưng tôi cảm thấy mệt mỏi vì phải chờ đợi và khởi động lại.

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

Tôi không biết những thứ này cụ thể là gì, nhưng các mô-đun hạt nhân (ví dụ NFS) không có PID để liên kết với các ổ cắm này. Tìm kiếm một cái gì đó nghi ngờ trong lsmod.

Tôi không biết nếu điều này có thể hữu ích. Tôi có cùng một vấn đề và những gì tôi đã làm là như sau: Đầu tiên, tôi gọi netstat với các tùy chọn -a (tất cả) và -e (mở rộng). Với tùy chọn thứ hai, tôi có thể thấy Inode được liên kết với cổng được sử dụng. Sau đó, tôi đã gọi lsof | grep với số inode thu được và tôi đã nhận được quy trình PID liên quan đến inode đó. Điều đó đã làm việc trong trường hợp của tôi.

Có lưu lượng truy cập nào đến hoặc đi từ cổng này không, hãy kiểm tra xem với tcpdump -vv -x s 1500 port 37398 -w trace.outLưu bản ghi của bạn trong tệp theo dõi. Sau đó, bạn có thể mở nó bằng wireshark hoặc tcpdump -vv port 37398xem trực tiếp những gì đang diễn ra.

Cố gắng telnet đến cổng đó bằng netcat cho ổ cắm udp có thể bạn sẽ nhận được một số biểu ngữ giúp.

Nhận rkhunter và kiểm tra hệ thống của bạn cho một cửa hậu.

So sánh băm md5 của lsof / netstat với hàm băm từ phương tiện cài đặt của bạn, giả sử các tệp không cập nhật.