Tôi đoán lý do là đoạn IP thứ hai là không phải với tiêu đề UDP (tôi nghĩ rằng nó là như nhau cho TCP), vì vậy libpcap không thể nắm bắt chúng bằng cách sử dụng bộ lọc hiện cổng udp 20000.
Vâng, đó là chính xác.
Bạn có thể thử udp port 20000 or (ip[6:2] & 0x1fff) != 0
, sẽ thu thập các gói đến hoặc từ cổng 20000 và các đoạn IP khác với đoạn đầu tiên; đó không phải là lý tưởng, nhưng tất cả những gì bạn có thể làm với các bộ lọc libpcap, vì cơ chế bộ lọc mà nó sử dụng (là một phần của hạt nhân OS) không duy trì bất kỳ lịch sử nào giữa các gói, và do đó không có cách nào để biết rằng IP ID được cho là một phần của cùng một phân đoạn như một gói khác có cùng ID IP, độ lệch mảnh 0 và tiêu đề UDP với cổng 20000.
(Cũng lưu ý rằng ít nhất một số phiên bản Linux sẽ truyền các mảnh của một gói dữ liệu IP theo thứ tự đảo ngược - để cho phép người nhận xem đoạn cuối cùng trước tiên, và do đó có thể thường xuyên ước tính chính xác kích thước của gói đã được tập hợp lại. Điều đó sẽ làm cho thậm chí nhiều hơn khó khăn để nắm bắt tất cả các mảnh của gói IP với một bộ lọc kiểm tra các trường trong tiêu đề TCP hoặc UDP.)
Nguồn
2013-11-07 12:18:12
Nếu gói UDP bị phân mảnh và các mảnh không xác định nguồn/đích của chúng, thì làm thế nào trong tên của lỗ hổng của Zeus chúng có được chuyển đến máy chủ và ứng dụng thích hợp không? –
Đoạn thứ hai là với tiêu đề IP nhưng không có tiêu đề UDP. Ngăn xếp IP/TCP sẽ lắp ráp đoạn IP thứ nhất và thứ hai trước khi nó cung cấp toàn bộ gói UDP cho ứng dụng. Nhưng có vẻ như với tôi rằng libpcap không thể nhận ra đoạn IP thứ hai. – misteryes
Làm thế nào một ngăn xếp tcp/ip biết rằng đoạn thứ hai thuộc cùng một ổ cắm giống như ổ đĩa đầu tiên không có tiêu đề UDP? Có lẽ bạn sẽ phải tự mình tái cấu trúc - điều này thực sự không quá khó khăn. –