Làm cách nào tôi có thể xác định quá trình nào đang tạo lưu lượng UDP trên Linux?

Máy của tôi liên tục thực hiện yêu cầu giao thông udp dns. những gì tôi cần biết là PID của quá trình tạo lưu lượng này.

Cách thông thường trong kết nối TCP là sử dụng netstat / lsof và nhận quy trình liên quan tại pid.

Có phải UDP là kết nối là statele, vì vậy, khi tôi gọi netastat / lsof tôi chỉ có thể thấy nó nếu ổ cắm UDP được mở và nó đang gửi lưu lượng.

Tôi đã thử với lsof -i UDPvà với nestat -anpue, nhưng tôi không thể tìm thấy quy trình đang thực hiện yêu cầu đó bởi vì tôi cần gọi chính xác lsof / netstat khi lưu lượng udp được gửi, nếu tôi gọi lsof / netstat trước / sau khi datagram udp được gửi không thể xem ổ cắm UDP đã mở.

Gọi netstat / lsof chính xác khi gói 3/4 udp được gửi là KHÔNG THỂ.

Làm thế nào tôi có thể xác định quá trình khét tiếng? Tôi đã kiểm tra lưu lượng để cố gắng xác định PID được gửi từ nội dung của gói, nhưng không thể xác định lưu lượng truy cập từ bối cảnh của lưu lượng.

Bất cứ ai có thể giúp tôi?

Tôi đang root trên máy này FedORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Thứ tư ngày 7 tháng 7 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux

Kiểm toán Linux có thể giúp đỡ. Nó ít nhất sẽ xác định vị trí người dùng và quy trình thực hiện kết nối mạng datagram. Các gói UDP là datagram.

Đầu tiên, cài đặt auditdkhung trên nền tảng của bạn và đảm bảo auditctl -ltrả về một cái gì đó, ngay cả khi nó nói rằng không có quy tắc nào được xác định.

Sau đó, thêm một quy tắc để xem cuộc gọi hệ thống socket()và gắn thẻ để dễ dàng tìm kiếm sau ( -k). Tôi cần phải giả định rằng bạn đang ở trên một kiến trúc 64-bit, nhưng bạn có thể thay thế b32ở vị trí của b64bạn thì không.

auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

Bạn phải chọn qua các trang man và các tệp tiêu đề để xây dựng tệp này, nhưng những gì nó thu được về cơ bản là hệ thống này gọi : socket(PF_INET, SOCK_DGRAM|X, Y), trong đó tham số thứ ba không xác định nhưng thường là 0. PF_INETlà 2 và SOCK_DGRAMlà 2. Các kết nối TCP sẽ sử dụng SOCK_STREAMsẽ được đặt a1=1. ( SOCK_DGRAMtrong tham số thứ hai có thể được OR với SOCK_NONBLOCKhoặc SOCK_CLOEXEC, do đó &=so sánh.) -k SOCKETTừ khóa của chúng tôi chúng tôi muốn sử dụng khi tìm kiếm các dấu vết kiểm toán sau này. Nó có thể là bất cứ điều gì, nhưng tôi muốn giữ cho nó đơn giản.

Hãy để một vài phút trôi qua và xem xét các con đường kiểm toán. Tùy chọn, bạn có thể buộc một vài gói bằng cách đưa máy chủ ra khỏi mạng, điều này sẽ khiến việc tra cứu DNS xảy ra, sử dụng UDP, sẽ làm vấp phải cảnh báo kiểm toán của chúng tôi.

ausearch -i -ts today -k SOCKET

Và đầu ra tương tự như phần dưới đây sẽ xuất hiện. Tôi viết tắt nó để làm nổi bật những phần quan trọng

type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET

Trong đầu ra trên, chúng ta có thể thấy rằng pinglệnh gây ra ổ cắm được mở. Sau đó tôi có thể chạy strace -p 14510trên tiến trình, nếu nó vẫn đang chạy. Các ppid(cha mẹ quá trình ID) cũng được liệt kê trong trường hợp nó là một kịch bản mà đẻ đứa trẻ có vấn đề rất nhiều.

Bây giờ, nếu bạn có nhiều lưu lượng UDP, điều này sẽ không đủ tốt và bạn sẽ phải dùng đến OProfile hoặc SystemTap , cả hai đều vượt quá chuyên môn của tôi.

Điều này sẽ giúp thu hẹp mọi thứ trong trường hợp chung.

Khi bạn đã hoàn tất, hãy xóa quy tắc kiểm toán bằng cách sử dụng cùng một dòng bạn đã sử dụng để tạo quy tắc đó, chỉ thay thế -abằng -d.

auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

Bạn có thể sử dụng netstat, nhưng bạn cần các cờ phù hợp và nó chỉ hoạt động nếu quá trình gửi dữ liệu vẫn còn sống. Nó sẽ không tìm thấy dấu vết của một cái gì đó xuất hiện trong cuộc sống, gửi lưu lượng UDP, sau đó biến mất. Nó cũng đòi hỏi đặc quyền gốc địa phương. Mà nói:

Đây là tôi bắt đầu một ncat trên máy chủ cục bộ của mình, gửi lưu lượng UDP đến cổng 2345 trên máy (không tồn tại) 10.11.12.13:

[madhatta@risby]$ ncat -u 10.11.12.13 2345 < /dev/urandom

Đây là một số đầu ra tcpdump chứng minh rằng lưu lượng đang diễn ra:

[root@risby ~]# tcpdump -n -n port 2345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:41:32.391750 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.399723 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.401817 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.407051 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.413492 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.417417 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192

Đây là bit hữu ích , sử dụng netstat với cờ -a (để xem chi tiết cổng) và cờ -p để xem chi tiết ID quá trình. Đó là cờ -p yêu cầu quyền root:

[root@risby ~]# netstat -apn|grep -w 2345
udp        0      0 192.168.3.11:57550          10.11.12.13:2345            ESTABLISHED 9152/ncat     

Như bạn có thể thấy, pid 9152 được xem là có kết nối mở tới cổng 2345 trên máy chủ từ xa được chỉ định. Netstat cũng hữu ích chạy nó thông qua ps và cho tôi biết tên quá trình là ncat.

Hy vọng rằng đó là một số sử dụng.

Tôi đã có chính xác cùng một vấn đề và không may auditdlàm gì nhiều cho tôi.

Tôi đã có lưu lượng truy cập từ một số máy chủ của mình tới các địa chỉ DNS của Google 8.8.8.8và 8.8.4.4. Bây giờ, quản trị viên mạng của tôi bị OCD nhẹ và anh ấy muốn xóa tất cả lưu lượng không cần thiết vì chúng tôi có bộ đệm DNS thực tập. Anh ta muốn vô hiệu hóa cổng 53 cho mọi người ngoại trừ các máy chủ bộ đệm.

Vì vậy, sau khi thất bại với auditctl, tôi đào vào systemtap. Tôi đến với kịch bản sau đây:

# cat >> udp_detect_domain.stp <<EOF
probe udp.sendmsg {
  if ( dport == 53 && daddr == "8.8.8.8" ) {
    printf ("PID %5d (%s) sent UDP to %15s 53\n", pid(), execname(), daddr)
  }
}
EOF

Sau đó, chỉ cần chạy:

stap -v udp_detect_domain.stp

Đây là đầu ra mà tôi nhận được:

PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3506 (python) sent UDP to  8.8.8.8 53

Đó là nó! Sau khi thay đổi resolv.confcác PID đó đã không nhận các thay đổi.

Hi vọng điêu nay co ich :)

Đây là một tùy chọn systemtap, sử dụng các đầu dò netfilter có sẵn trong verson 1.8 trở lên. Xem thêm man probe::netfilter.ip.local_out.

# stap -e 'probe netfilter.ip.local_out {
  if (dport == 53) # or parametrize
      printf("%s[%d] %s:%d\n", execname(), pid(), daddr, dport)
}'
ping[24738] 192.168.1.10:53
ping[24738] 192.168.1.10:53
^C

Tôi sẽ sử dụng một trình thám thính mạng như tcpdump hoặc wireshark để xem các yêu cầu DNS. Nội dung của truy vấn có thể đưa ra ý tưởng về chương trình nào đang phát hành chúng.

Xin lưu ý rằng khi sử dụng autitctl, ví dụ nscd sử dụng một tham số hơi khác trong lệnh gọi hệ thống ổ cắm, khi thực hiện truy vấn DNS:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Vì vậy, để đảm bảo bạn bắt được những truy vấn đó ngoài những truy vấn đã được đề cập ở trên, bạn có thể thêm một bộ lọc bổ sung, có cùng tên nếu bạn muốn:

auditctl -a exit,always -F arch=b64 -F a0=2  -F a1=2050 -S socket -k SOCKET

Ở đây, năm 2050 là một chút HOẶC của SOCK_DGRAM (2) và SOCK_NONBLOCK (2048).

Sau đó, tìm kiếm sẽ tìm thấy cả hai bộ lọc có cùng khóa , SOCKET:

ausearch -i -ts today -k SOCKET

Các giá trị hex cho các hằng số socket tôi tìm thấy ở đây: https://golang.org/pkg/syscall/#pkg-constants

Vì tôi không có điểm danh tiếng để bình luận nên tôi đã thêm điều này.