Chương 8: Kiểm tra các trường của IP header

Chương 8. Kiểm tra các trường của IP header Đây là một trong hai chương kiểm tra các trường trong gói IP. Chương này tập trung vào các trường header của IP, nhưng ở chương tiếp theo xem xét các trường trong giao thức được gán vào header. Vậy chúng ta tiếp tục quá trình xem xét lưu lượng từ nhiều yếu tố khác nhau, chúng ta có thể thừa nhận một cái nhìn tổng quan khác để xem xét chức năng của các trường trong những header và tìm kiếm những giá trị thông thường và không bình thường trong các header đó. Nếu chúng ta biết rõ ý nghĩa của các trường và quen thuộc với các giá trị thông thường, chúng ta cần phải có kĩ năng để phát hiện kết quả thay đổi hoặc các giá trị có hại. Khi bạn bắt đầu xem xét đầu ra của NIDS hoặc thậm chí kết xuất đầu ra TCP trên một cơ sở thông thường, những kiến thức này tỏ ra rất có ích cho việc phát hiện vấn đề các gói tin hoặc nhận ra các tính chất của lưu lượng bất thường. Lưu lượng-traffic: Khối lượng các thông báo gởi qua một mạng truyền thông. Sự chèn vào và tránh các tấn công Trước khi chúng ta xem xét các trường cụ thể trong IP header, chúng ta sẽ đề cập đến các kiểu tấn công, chúng có thể ngăn chặn bởi khả năng của NIDS để phát hiện các hoạt động có hại. Như việc chúng ta kiểm tra các trường trong datagram, chúng ta sẽ chèn vào một cách hợp lý hoặc tránh các tấn công, chúng có thể thực hiện bằng việc thao tác với các giá trị của trường nào đó. Có một bài báo được viết vào năm 1998 được gọi: “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection”- (việc chèn, việc tránh và sự từ chối dich vụ: bỏ qua phát hiên xâm nhập mạng). Tác giả Thomas Ptacek và Timothy Newsham tranh luận các tấn công có thể tránh việc phát hiện bởi NIDS bằng việc sử dụng phương thức của việc gửi lưu lượng, đây sẽ là lí do giải thích sự khác nhau của các gói tin giữa NIDS và host đích. Bài báo này là một luận án xuất sắc của một thực tế khác đó có thể là nguyên nhân cho một NIDS không thích hợp cho việc phân tích khả năng lưu lượng có hại. Các tác giả đã bị kiểm soát bằng một vài thử nghiệm khác nhau bởi sự phản đối của NIDS để chứng minh lý luận của mình. Cùng với việc phủ nhận dịch vụ của NIDS, bài báo cơ bản tranh luận về các ý kiến của những tấn công cá nhân làm cho NIDS lúng túng. Đầu tiên được biết qua bài báo. Đây là nơi kẻ tấn công gửi lưu lượng tới một host đích. Gửi một hoặc nhiều gói tin được truy cập hoặc quan sát bởi NIDS, cho đến bây giờ nó chưa bao giờ tiếp cận được host đích; hoặc điều này có thì đích bị bỏ đi, nó coi là không hoàn hảo. Ý kiến cá nhân của các tác giả chỉ ra đánh giá lưu lượng khác nhau giữa NIDS và host đích hoặc thâm chí có thể quan sát lưu lượng khác nhau. Một cuộc tấn công thứ hai được biết là trốn tránh. Bao hàm ý kiến giống nhau của việc gửi lưu lượng tới một host đích. Mặc dù host đích quan sát cùng một lưu lượng như NIDS, nó xem xét kĩ lưỡng các gói tin khác nhau hơn NIDS. Có lẽ NIDS loại đi một hoặc nhiều gói tin, nhưng host đích thì chấp nhận chúng. Hơn nữa, NIDS và host đích quan sát lưu lượng khác nhau. Mặc dù giới hạn không được chấp nhận nêu ra một số ngữ nghĩa học đặc biệt khi được so sánh với các hoạt động của thiết bị lọc gói tin, nó là thuật ngữ chuyên ngành được sử dụng trong chính bài báo đó. Tránh tấn công thành công bởi vì NIDS không có khả năng phân tích các gói tin hoặc dữ liệu trong các gói như host đích làm, cho phép host đích quan sát một gói tin hoặc dữ liệu điều mà NIDS không làm được. Vấn đề chèn những tấn công Khảo sát về tấn công có thể của bài báo trong công việc như thế nào, chúng ta có một NIDS trên một mạng khác, ví dụ như DMZ đang tìm kiếm những chữ kí có thể đưa ra một vài vấn đề hoặc lưu lượng đáng chú ý. Một trong những chữ kí đó có thể để tìm kiếm lưu lượng tới telnet, TCP ở cổng 23, với một nội dung của REWT như một dấu hiệu của một số trương mục cổng sau tới telnet. Hiện nay, chúng ta có một kẻ tấn công vẫn còn chưa bị phát hiện trong các thiết bị một Troạn telnet trên một host đích và mong muốn hiện nay là nối máy để host đó sử dụng tài khoản REWT. Kẻ tấn công có thể thực hiên một vài cuộc thăm dò trên mạng chúng ta và quen thuộc về topology mạng và các hoat động hơn chúng ta biết. Điều này có thể xảy ra với kẻ tấn công để tránh các thông báo của NIDS nếu anh ta có thể làm cho NIDS chấp nhận một gói tin, ở host cuối cùng gói tin có thể không được chấp nhận hoặc không bao giờ quan sát được. Trong hình 8.1, kẻ tấn công gửi 3 gói tin khác nhau được trù định từ trước cho TCP cổng 23 của host đích, với mỗi một hoặc nhiều kí tự trong lượng chuyển đi. Nội dung đầu tiên là kí tự R, cả NIDS và host nhân cuối cùng xem xét và chấp nhận. thứ hai là kí tự O gửi đi thì có một TCP checksum lỗi. Checksums xác nhân tính hợp lệ toàn vẹn của gói tin và nếu chúng không hợp lệ thì gói tin bị hủy. Chúng ta nói về việc NIDS xem xét gói tin này, NIDS không được lập trình để xác nhận tính hợp lệ của TCP checksum, và mù quáng chấp nhận gói tin như một dòng kí tự hợp lệ đang được gửi tới host đích. Host đích nhận gói tin, nó xác nhận rằng TCP checksum là không hợp lệ , và hủy gói tin. Kẻ tấn công đã kiểm soát để chèn một kí tự, kí tự này là nguyên nhân NIDS bỏ qua để xác nhận một sự tấn công thực sự hoặc hành động chống lại của host cuối cùng. Kết thúc, gói tin thứ ba được gửi với một lượng là EWT thì cả NIDS và host đích đều nhận và xác nhận. Figure 8.1. A sample insertion attack. NIDS đã tập hợp lai dòng TCP và kết luận đó không phải là mối nguy hiểm bởi vì NIDS không có một chữ kí nào cho TCP cổng 23 với nội dung ROEWT. Lúc này, host đích tập hợp lại dòng này là REWT và thật tài tình một phiên telnet bắt đầu với một người dùng REWT không bị phát hiện bởi NIDS. Chú ý: Đây là một thảo luận được đơn giản hóa của tấn công này; số thứ tự của TCP cần phải đồng bộ hóa đúng đắn cho ? làm việc đúng cách. Tránh các tấn công Trong trường hợp tránh các tấn công được mô tả trong hình 8.2, host đích quan sát hoặc chấp nhận một gói tin mà NIDS loại bỏ. Trong trường hợp này, chúng ta vẫn xem xét một phiên telnet với người dùng REWT tới host đích. Nếu kẻ tấn công có thể gửi lưu lượng trong một dạng mà NIDS không chấp nhận một gói tin nhưng host đầu cuối chấp nhận nó, phát hiện ra vấn đề trốn tránh này. Figure 8.2. A sample evasion attack . Một viễn tưởng có thể cho các cuộc tấn công này là gửi dữ liệu trên các kết nối SYN. Mặc dù không điển hình cho các kết nối bình thường, gửi dữ liệu trên SYN là hợp lệ cho mỗi RFC 793. Các dữ liệu trên một kết nối SYN sau này nên được xem là một phần của dòng sau khi bắt tay ba bước đã được hoàn tất. Hãy nói rằng chúng tôi có một gói dữ liệu đầu tiên mà đến trên mạng với một gói SYN đã được trù định cho host mục tiêu TCP cổng 23 của chúng tôi. Nó có một tải trọng của R trong gói SYN. NIDS chỉ tìm kiếm tải trọng sau khi bắt tay ba bước đã được hoàn thành, do đó, nó bỏ hoàn toàn dữ liệu đó. Các host đích nhận gói tương tự và biết để lưu trữ R cho dòng sau khi bắt tay ba chiều được hoàn tất. Sau đó chúng tôi có các gói mà hoàn tất bắt tay ba bước, mỗi không có dữ liệu trong chúng, như mong đợi. Cuối cùng, chúng tôi có một gói dữ liệu bình thường với các kí tự EWT như là tải trọng được trù định trước cho mục tiêu host TCP cổng 23. Kết quả là NIDS tập hợp lại dòng TCP cho host đích cổng 23 với tải trọng đầy đủ EWT. Điều này không phù hợp bất kỳ chữ ký nó biết. Host đích, mặt khác, tập hợp lại dòng như REWT và vui vẻ bắt đầu phiên telnet Trojaned. Để tóm tắt các bài đề cập trước đó, có rất nhiều kỹ thuật có thể được sử dụng để chèn và tránh các cuộc tấn công chống lại một NIDS. Mặc dù các bài này không bao gồm các cuộc tấn công tầng ứng dụng như HTTP làm cho bối rối, chúng tôi thấy rằng các cuộc tấn công ứng dụng là một xu hướng phát triển trong tránh các tấn công. Rất nhiều các cuộc tấn công khác nhau là thành công chỉ vì các NIDS không thể dự đoán phản ứng của mỗi host đích có thể có của TCP / IP stack cho các cuộc tấn công khác nhau. Có rất nhiều mặt của TCP / IP stack khác nhau giữa các hệ điều hành. Mặc dù theo dõi rất nhiều thông tin này là khả thi cho NIDS, hiểu rằng khi bạn yêu cầu NIDS để thực hiện nhiều chức năng hơn và nhiệm vụ, các NIDS sẽ trở nên chậm hơn trong quá trình xử lý tất cả lưu lượng truy cập đến điểm mà nó có thể bắt đầu thả các gói dữ liệu. Cuối cùng, đó là một sự cân bằng chức năng và tốc độ, và tốc độ là một thành công hiện tại. Một cách để đối phó với khả năng trốn hoặc chèn các cuộc tấn công là cài đặt một máy chủ lưu trữ dựa trên IDS về tài nguyên đó có yêu cầu bảo hộ nhiều hơn hoặc kiểm soát. The host-based IDS thấy các gói tương tự mà host nhìn thấy, nhưng điều này như sức đề kháng của nó để trốn đi. Các host sẽ vẫn cần phải áp dụng mức độ hiểu biết để xử lý các ứng dụng dựa trên tránh các cuộc tấn công. Bài báo này được tìm thấy tại: www.robertgraham.com/mirror/Pta c e k -News h am- Eva s ion- 98.htm l . Các trường IP Header Hãy bắt đầu kiểm tra về các trường trong header IP. Mỗi trường sẽ được thảo luận về chức năng của nó, bất kỳ thông tin cần thiết về các giá trị bình thường và bất thường, khỏa sát trước có thể thu được từ kiểm tra các trường, và tránh hoặc chèn các tấn công có thể bằng cách sử dụng các trường. IP version number Chỉ có số phiên bản IP hợp lệ đang được sử dụng là 4 và 6, tương ứng cho IPv4 và IPv6. IPv4 là phổ biến nhất và thâm nhập khắp nơi cho đến nay. IPv6 chưa được sử dụng rộng rãi trong các mạng người dùng ở Bắc Mỹ, mặc dù nó đang dần được triển khai trong xương sống Internet. Nó cũng được sử dụng ở châu Âu và châu Á. Các trường của phiên bản IP phải được xác nhận bởi một host nhận và nếu không hợp lệ, datagram được bỏ đi và không có thông báo lỗi được gửi đến máy gửi. RFC 1121 chỉ ra rằng datagram phải được âm thầm bỏ đi nếu một giá trị không hợp lệ được phát hiện. Vì vậy, Thủ thuật một datagram với một phiên bản IP không hợp lệ sẽ không phục vụ mục đích khác hơn là để kiểm tra nếu host nhận tuân theo RFC. Ngoài ra, nếu một gói đến tại một router với một phiên bản IP không hợp lệ, cần loại bỏ âm thầm. Sử dụng như một phương tiện của việc chèn các tấn công là khá khó khăn, trừ khi kẻ tấn công là trên mạng giống như NIDS. Nếu đây là trường hợp và một loạt các gói dữ liệu được gửi đến host cuối cùng với một phiên bản IP không hợp lệ và một NIDS không vứt bỏ, đây là một cuộc tấn công chèn một cái gì đó NIDS chấp nhận mà các host đích hoặc router trung gian sau khi NIDS nên chắc chắn từ chối. Protocol number Bạn đã biết được rằng IP protocol number cho biết loại dịch vụ của IP header. Một danh sách tất cả các số giao thức hỗ trợ và tên gọi có thể được tìm thấy tại w ww . iana.org/ass i gnments/ p rotoco l -number s . Thuận tiện, sau này các phiên bản của nmap có khả năng quét một host cho việc lắng nghe các giao thức. Điều này được thực hiện bằng cách sử dụng tùy chọn-sO. Các host mục tiêu được quét cho tất cả 256 khả năng của giao thức. Các giao thức được lắng nghe khi không có thông điệp ICMP "giao thức không thể truy cập" được trả về. Các văn bản sau đây cho thấy một nmap quét giao thức đang hoạt động và việc trở lại đánh giá nmap: nmap –sO target Starting nmap V. 2.54BETA1 by fyodor@ins e cure.org ( www.insec u re.org/nmap/ ) Interesting protocols on myhost.net (192.168.5.5): (The 250 protocols scanned but not shown below are in state: closed) Protocol State Nam 1 open icmp 2 open icmp 6 open tcp 17 open udp Đây là một mẫu của lưu lượng mà giao thức khi quét sinh ra: 07:30:31.405513 scanner.net > target.com: ip-proto-124 0 (DF) 07:30:31.405581 scanner.net > target.com: ip-proto-100 0 (DF) 07:30:31.405647 scanner.net > target.com: ip-proto-166 0 (DF) 07:30:31.405899 target.com > scanner.net: icmp: target.com protocol 124 unreachable (DF) 07:30:31.788701 scanner.net > target.com: ip-proto-132 0 (DF) 07:30:32.119538 target.com > scanner.net: icmp: target.com protocol 166 unreachable (DF) 07:30:34.098715 scanner.net > target.com: ip-proto-236 0 (DF) 07:30:34.098782 scanner.net > target.com: ip-proto-129 0 (DF) 07:30:34.098849 scanner.net > target.com: ip-proto-229 0 (DF) 07:30:32.779583 target.com > scanner.net: icmp: target.com protocol 236 unreachable (DF) 07:30:34.099557 target.com > scanner.net: icmp: target.com protocol 109 unreachable (DF) Các nmap quét kiểm tra tất cả 256 loại giao thức khác nhau. Một host mà nhận được kiểu quét nên phản hồi với một thông điệp ICMP "giao thức không thể truy cập" đến bất kỳ giao thức mà nó không hỗ trợ. Mặc dù các giao thức hỗ trợ của host làm chú ý, một phần có thể có của sự thăm dò các kiểu scan này là host đang hoạt động. Đây là một loại quét tàng hình có thể không gây ra một sự xâm nhập-phát hiện hệ thống báo động. Tuy nhiên, nếu trang web có tuyên bố "no ip unreachables" trên cổng bên ngoài của gateway router, hay nếu nó chặn tất cả các ICMP đi ra, thông tin này không bị rò rỉ vào máy quét này. Trong trường hợp đó, quét là vô ích. Có một lỗ hổng trong logic được sử dụng bởi nmap để lắng nghe phân biệt các giao thức. Nmap thừa nhận rằng sự vắng mặt của thông báo ICMP “protocol unreachable” có nghĩa là giao thức được lắng nghe. Tuy vậy, điều kiện như trang web quét chặn thông điệp ICMP bên ngoài ngăn chặn các máy quét nmap từ việc khai thác những tin nhắn này. Có những điều kiện khác, chẳng hạn như các gói dữ liệu bị bỏ, mà cũng có thể là nguyên nhân mất các gói và ảnh hưởng sai tới nmap. Tuy nhiên, tác giả của nmap cố xem xét các tình huống như vậy. Nmap gửi các gói dữ liệu lặp lại cho mỗi giao thức để đối phó với vấn đề mất gói. Ngoài ra, nếu nmap không nhận được thông diệp ICMP “protocol unreachable” trở lại, nó không thùa nhận tất cả các giao thức được lắng nghe. Thay vào đó, nó một cách khôn ngoan giả định rằng lưu lượng đang được "lọc" và các báo cáo này. A Simple Bloody Analogy Nmap sử dụng triết lý sự vắng mặt của quá trình truyền thông là xác nhận của một điều kiện để xác định lắng nghe các giao thức. Nói cách khác, sự vắng mặt của thông báo " ICMP protocol unreachable " là xác nhận rằng các giao thức được lắng nghe. Như chúng ta đã thấy, có một số lỗi liên quan đến phương pháp này. Triết lý này nhắc tôi về tình hình thế giới thực của việc đi đến văn phòng bác sĩ thử máu. Bởi vì các bác sĩ và nhân viên là những người rất bận rộn, họ thường nói với bạn về tình trạng của bạn rằng họ sẽ không gọi cho bạn, trừ khi họ phát hiện ra một cái gì đó sai. Cơ bản họ cho bạn biết sự vắng mặt của việc gặp gỡ, việc thiếu một cuộc gọi điện thoại, là một xác nhận của tình trạng rằng bạn đang khỏe mạnh như một con ngựa. Tuy vậy, nếu bạn là ngay cả một chút cynical, bạn hiểu những vấn đề có thể với tình hình này. Tất cả các loại những thứ có thể đi sai như mất máu của bạn tại văn phòng bác sĩ trước khi nó được gửi đến một phòng thí nghiệm, mất máu của bạn trên đường vào hoặc từ các phòng thí nghiệm, hoặc thậm chí bị mất máu của bạn tại phòng thí nghiệm. Chỉ vì bạn không nghe từ các bác sĩ tốt không nhất thiết có nghĩa là mọi thứ đều hài lòng. Những vấn đề tương tự có thể bao quanh một gói tin. Một gói tin có thể bị mất trong quá trình truyền hoặc nó có thể bị rớt hoặc bị chặn tại nhiều điểm trong cuộc hành trình của nó. Nmap nỗ lực để đối phó với một số vấn đề, nhưng sự vắng mặt của truyền thông có thể không phải luôn luôn xác nhận một điều kiện. Differentiated Services Byte (Trước đây được biết đến như là Type of Service - The Prince of Fields) Có vẻ như là các loại cũ của Dịch vụ byte đã trải qua nhiều vòng thay đổi kể từ mới bát đầu sáng tạo của nó. Một trong những thay đổi trong RFC 2481 và hiện đang RFC 3.168 gọi là hai bit bậc thấp của các dịch vụ phân biệt byte sẽ được sử dụng cho Explicit Congestion Notification (ECN). Mục đích ở đây là một số router được trang bị để làm Random Early Detection (RED) hoặc hoạt động quản lý hàng đợi của khả năng mất gói. Khi tắc nghẽn nghiêm trọng, nó có thể là một router có thể thả các gói dữ liệu. RED nỗ lực để giảm thiểu tình trạng này bằng cách tính toán khả năng xảy ra tắc nghẽn trong hàng đợi đến một cổng router và đánh dấu các gói tin mà có thể đã được giảm xuống khi gặp tắc nghẽn. Có hai giá trị có thể có của các bit ECN để thông báo rằng host gửi là ECN-capable. Các bit ECN-capable Transport (ECT) thiết lập có thể là 01 hoặc 10 trong hai bit bậc thấp của các dịch vụ phân biệt byte trong Hình 8.3. Các cài đặt này chỉ ra rằng người gửi là ECN-aware. Nếu người gửi là ECN-aware, một router cố gắng sử dụng Red không để thả các gói dữ liệu, mà thay vào đó gửi nó với bit Congestion kinh nghiệm (CE) được kích hoạt, và tiếp nhận các phản ứng này.Các bit thiết lập cho Congestion Experienced là 1s trong cả hai bit ECN. Chúng ta sẽ thảo luận về phản ứng của người nhận chi tiết hơn khi chúng ta tìm hiểu các lĩnh vực giao thức TCP trong chương kế tiếp. Figure 8.3. The Differentiated Services byte and ECN. Cờ DF (Don't Fragment) Cờ DF là một trường trong header của IP được thiết lập khi không để xảy ra phân mảnh. Nếu một router phát hiện ra rằng một gói cần phải được phân mảnh, nhưng cờ DF được thiết lập, gói dữ liệu được giảm xuống và một thông điệp ICMP "unreachable - need Frag (MTU size)" được gửi đến host gửi. Hầu hết các router hiện nay bao gồm kích thước đơn vị truyền tải tối đa (MTU) của liên kết nhỏ hơn nó được yêu cầu phân mảnh. Phân mảnh đi kèm với một số chi phí phụ cần thiết, vì vậy bạn nên tránh nó hoàn toàn. Nếu một mảnh của chuỗi các đoạn không được phân phát, tất cả các mảnh phải gửi lại. Bởi vì điều này, khi một số chồng TCP / IP gửi dữ liệu, chúng gửi một gói dữ liệu điều tra đầu tiên với việc thiết lập cờ DF. Nếu gói đi từ nguồn đến đích mà không có bất kỳ lỗi ICMP, kích thước datagram của gói điều tra được chọn để sử dụng cho các gói tiếp theo. Nếu một thông báo ICMP được quay trở lại với một thông báo “unreachable error – need to frag” và các MTU được bao gồm, gói dữ liệu được thay đổi kích cỡ do đó phân mảnh không xảy ra. Giả đinh điều này là các trang web cho phép các thông báo ICMP đến. Một số hệ điều hành các chồng TCP / IP đặt cờ DF trên một số loại gói dữ liệu, và nmap sử dụng điều này là một trong những xét nghiệm để thử dấu vân tay của hệ điều hành. Ngoài ra, kẻ tấn công có thể sử dụng cờ DF như một phương tiện của việc chèn một tấn công. Điều này có nghĩa là NIDS phải có trên một mạng với một MTU lớn hơn so với các host đích cuối cùng. Trong trường hợp này, một hay nhiều packet trong một loạt những packet khác có thiết lập cờ DF. NIDS nhận được packet(s) và chấp nhận nó, nhưng host cuối không bao giờ nhận được packet(s) bởi vì phân mảnh được yêu cầu, nhưng cờ DF đã được thiết lập. Cờ MF(More Fragments) Cờ MF cho bạn biết rằng một hay nhiều mảnh theo sau đoạn hiên thời. Tất cả các đoạn trừ đoạn cuối cùng đều cần phải có cờ MF. Cách mà một host nhận phát hiện phân mảnh là cờ này được thiết lập hoặc trường offset của đoạn trong IP header được thiết lập là một giá trị khác không. Sử dụng bản đồ Incomplete Fragments Một kỹ thuật lập bản đồ là để cố gắng tìm ra thông báo ICMP IP “reassembly time exceeded " từ các host trên một mạng được quét. Điều này có thể được thực hiện bằng cách gửi một tập hợp không đầy đủ các đoạn tới các host đang được ánh xạ. Đối với điều này để làm việc đúng cách, các host đích đã được lắng nghe trên cổng nó được quét nếu lưu lượng là TCP hay UDP. Khi máy quét nhận được đoạn đầu tiên, nó đặt ra một bộ đếm. Nếu bộ đếm thời gian hết hạn và các host nhận đã không nhận được tất cả các đoạn, nó sẽ gửi lỗi ICMP "IP reassembly time exceeded " trở lại host gửi. Điều quan trọng cần lưu ý (theo RFC 792) mà lỗi ICMP “IP reassembly time exceeded” được xảy ra, đoạn đầu tiên không thể thiếu. Nếu không nhận đượcđoạn đầu tiên, các host nhận được các đoạn không bao giờ thiết lập bộ đếm thời gian. RFC 1122 khuyến cáo rằng các bộ đếm thời gian hết hạn từ 60 giây và 2 phút, mặc dù chúng ta sẽ thấy rằng không có trường hợp này. hping2 –S –p 139 –x win98 06:49:36.986218 verbo.2509 > win98.netbios-ssn: S 1980004944:1980004944(0) win 512 (frag 38912: 2 0@0+) 06:50:41.636506 win98 > verbo: icmp: ip reassembly time exceeded hping2 –S –p 21 –x linux 11:56:04.064978 verbo.2450 > linux.ftp: S 1198423806:1198423806(0) win 512 (frag 39067:20@0+) 11:56:34.056813 linux > verbo: icmp: ip reassembly time exceeded [tos 0xc0] Hping2 là phần mềm miễn phí được sử dụng để tạo ra các loại lưu lượng khác nhau. Hping2 lần đầu tiên thực hiện với tùy chọn -S để gửi một gói tin với một SYN, một cổng đích 139,-p 139, và tùy chọn-x để thiết lập cờ More Fragment. Một gói dữ liệu được gửi đến máy chủ lưu trữ đích win98, mà bạn có thể đoán là một máy chủ Windows 98 lắng nghe trên cổng 139 TCP. Đoạn được gửi thực sự là toàn bộ các byte -20 header và một byte 20 - TCP header của gói SYN. Không có dữ liệu để gửi, nhưng host nhận không có cách để biết điều này vì cờ MF được thiết lập. Bạn có thể thấy rằng cờ MF được thiết lập bằng cách nhìn vào + ở ngay trước đầu ra của kết xuất TCP. Host Windows mất khoảng một phút và năm giây thời gian chờ ghép các đoạn lại. Đó là khi bạn nhìn thấy thông báo ICMP "IP reassembly time exceeded " trả về. Các thử nghiệm Hping2 tiếp theo được cố gắng trên hệ điều hành Linux (kernel 2.2) một host đang lắng nghe trên cổng FPT. Các host Linux mất khoảng ba mươi giây thời gian chờ trên đoạn không đầy đủ được gửi đến cổng đích 21. IP numbers Số IP là trường 32-bit. IP number nguồn nằm ở vị trí thứ 12 trong 15 byte offset của IP header; số IP đích có vị trí thứ 16 trong 19 byte offset của IP header. Một số giá trị IP source bất thường vào mạng của bạn là gì? Nếu bạn thấy một số IP vào mạng của bạn mà có mục đích là từ mạng của bạn, có một vấn đề. Nhiều khả năng, ai đó đã thay đổi gói này và là giả mạo một địa chỉ IP trong phạm vi của bạn. Một thiết bị lọc gói nên tránh lưu lượng này. Ngoài ra, bạn không bao giờ nên xem các IP source đến từ địa chỉ loopback 127.0.0.1, cũng không phải bạn sẽ thấy bất kỳ IP source rơi trong quyền cấp phát số hiệu Internet (IANA) thuộc số mạng private được định nghĩa trong RFC 1918. Các phạm vi địa chỉ này chỉ có thể được tìm thấy tại www.iana.org/assignments/ipv4-address. Dự định sử dụng của họ là chỉ dành cho mạng nội bộ địa phương. Đến mức mà lưu lượng còn lại trên mạng của bạn cần có một số IP source phản ánh không gian địa chỉ mạng của bạn. Nếu bạn thấy một số IP đến từ bên trong mạng của bạn có một số IP của một không gian địa chỉ khác, đó là hoặc bị giả mạo hoặc có vấn đề lỗi cấu hình với một host bên trong mạng của bạn. Trong cả hai trường hợp, lưu lượng này không nên được phép rời khỏi mạng của bạn. Điều này ngăn cản các host trong mạng của bạn tham gia phân phối của các cuộc tấn công từ chối dịch vụ vì người tham gia hoặc host zombie thường sử dụng số IP source giả mạo để mà họ không thể được định vị. Các loại khác của quét sử dụng bẫy-decoy hoặc giả mạo IP source như một màn khói-smokescreen. Bởi không công nhân lưu lượng bên ngoài mà không phải là một phần của không gian địa chỉ của bạn, những quét máy quét sẽ không có hiệu quả tốt. Nên bạn cũng không bao giờ nhìn thấy một IP nguồn với địa chỉ loopback 127.0.0.1 trên mạng của bạn vì nó xác định host địa phương. Và, bạn không bao giờ nên cho phép IP source trong dãy địa chỉ riêng để lại trên mạng của bạn. Cuối cùng, bạn không nên cho phép lưu lượng với một địa chỉ IP đích broadcast vào hoặc ra khỏi mạng của bạn. Như vậy địa chỉ đích thường được sử dụng cho bản đồ nhanh các mạng khác hoặc sử dụng chúng như là các trang web khuếch đại Smurf. IP Identification Number Giá trị nhận dạng IP được tìm thấy trong byte 4 và 5 offset của IP header . Đối với mỗi datagram mới có một host gửi, nó phải tạo ra một số chỉ IP ID duy nhất. Giá trị này thông thường tăng lên 1, mặc dù một số sử dụng tăng một trị số của 256, cho mỗi datagram mới được gửi bởi host này. Giá trị duy nhất này được yêu cầu trong trường hợp datagram trở nên phân mảnh. Tất cả các mảnh từ datagram này chia sẻ cùng một số IP ID. Điều này cũng được gọi là số ID phân mảnh. Nó là số được sử dụng bởi các host nhận để Lắp ráp lại tất cả các mảnh liên kết với một datagram thông thường. Phạm vi cho IP ID có giá trị từ 1 đến 65.535 vì đây là một trường 16-bit. Thông thường, bạn không thấy số IP ID có giá trị bằng 0. Khi giá trị IP ID đạt tới giá trị tối đa là 65.535, nó cần bọc quanh và bắt đầu lại. IP nguồn khác nhau điều khiển lưu lượng truy cập vào mạng của bạn nên biểu lộ một niên đại khác nhau của các giá trị IP ID. Vì vậy, nếu bạn thấy IP nguồn "bị cáo buộc- alleged " khác nhau gửi lưu lượng truy cập vào mạng của bạn và chúng xuất hiện để có một niên đại của trị số tăng số IP ID, NÓ có thể là các IP nguồn đang bị giả mạo. Cũng như với bất kì một trường nào khác hoặc giá trị trong IP datagram, giá trị này có thể được "thay đổi-crafted" để làm cho nó vô nghĩa. Ví dụ, nếu một kẻ tấn công sử dụng một công cụ mà gửi tất cả các gói dữ liệu với ID IP giống hệt nhau, họ sẽ không cung cấp giá trị pháp lý có ý nghĩa về host của kẻ tấn công. Tùy chọn -vv của kết xuất TCP có thể được sử dụng để hiển thị số IP ID cùng với giá trị time-to-live (TTL). Time-to-live (TTL) TTL là giá trị 8-bit được thiết lập bởi máy gửi datagram. Ban đầu giá trị TTL tùy thuộc vào chồng TCP/IP khác nhau được sử dụng, thí dụ bạn có thể thấy trong Bảng 8,1 đã thu được tại project.honeynet.org/papers/finger/traces. Như chúng ta đã thảo luận, TTL này sẽ giảm đi 1 , khi gói tin đi qua 1 router. Khi router nào nhận gói tin thấy TTL đạt tới 0 gói này sẽ bị loại và gửi trả lại một thông báo ICMP " time exceeded in-transit" lại cho người gửi. Đây là giải pháp nhằm ngăn chặn tình trạng lặp vòng vô hạn của gói tin trên mạng. Điều này có thể được sử dụng bởi có thể chèn một cuộc tấn công nếu NIDS nhìn thấy các packet, nhưng các TTL là đủ thấp để hết hiệu lực bởi một router trước khi nó tới host mục tiêu. [...]... của các trường và các giá trị có thể được tìm thấy trong IP header Đây là kiến thức có giá trị khi kiểm tra các gói dữ liệu cho các giá trị bất thường Công nhận giá trị đột biến có thể không giải thích về mục đích của các gói tin này, nhưng nó phải hướng sự chú ý của bạn đến packet Từ đó, có lẽ nó có thể để xác định bản chất của lưu lượng Chương 9 Kiểm tra các trường giao thức nhúng của header Chương. .. để chia dữ liệu đang được kiểm tra thành các trường 16-bit Mỗi trường 16 bit thực hiện bù 1 và tất cả giá trị bù 1 này được thêm vào Giá trị cuối cùng được tính toán là checksum IP checksum được tìm thấy trong các byte 10 và 11 của offset của IP header IP checksum bao gồm tất cả các trường chỉ trong IP header Checksum này không giống với các checksum mà được tính cho các trường protocol nhúng bởi nó... ý của chúng ta tới các trường chiều dài trong gói Trước tiên, hãy nhìn vào tổng chiều dài IP datagram trong các byte offset in đậm thứ 2 và 3 của IP header Bạn sẽ thấy độ dài của IP datagram là 0x28 hoặc 40-byte Độ dài IP header được tìm thấy trong nibble in đậm bậc thấp của byte offset 0 của IP header Như chúng ta đã biết, giá trị này bằng 5 đại diện cho một IP header 20-byte Các trường giao thức trong... để chia dữ liệu đang được kiểm tra thành các trường 16-bit Mỗi trường 16 bit thực hiện bù 1 và tất cả giá trị bù 1 này được thêm vào Giá trị cuối cùng được tính toán là checksum IP checksum được tìm thấy trong các byte 10 và 11 của offset của IP header IP checksum bao gồm tất cả các trường chỉ trong IP header Checksum này không giống với các checksum mà được tính cho các trường protocol nhúng bởi nó... đó là các giao thức bậc cao hoặc các ứng dụng sẽ phát hiện và đối phó với vấn đề này Công thức cho checksum IP header được sử dụng cho tất cả các checksum được xác nhận là tốt đầu tiên, chúng ta chia IP header thành các trường 16 bit Bởi vì độ dài của IP header luôn luôn là bội số của 4 byte, chúng ta không phải lo lắng về các trường mở rộng mà không rơi vào ranh giới 16 bit Sau khi tất cả các trường. .. đó là các giao thức bậc cao hoặc các ứng dụng sẽ phát hiện và đối phó với vấn đề này Công thức cho checksum IP header được sử dụng cho tất cả các checksum được xác nhận là tốt đầu tiên, chúng ta chia IP header thành các trường 16 bit Bởi vì độ dài của IP header luôn luôn là bội số của 4 byte, chúng ta không phải lo lắng về các trường mở rộng mà không rơi vào ranh giới 16 bit Sau khi tất cả các trường. .. thứ hai này thảo luận việc kiểm tra các trường trong các header sau IP header, tên là TCP, UDP và ICMP Như chúng tôi đã phát hiện ra trong chương trước, nó là bắt buộc mà bất cứ ai thực hiện phân tích biểu diễn lưu lượng truy cập được quen thuộc với mục đích của các trường và các giá trị dự kiến Đây là cách duy nhất để đưa ra các giá trị bất thường và có thể là một sự phản ánh của một số hoạt động có... kháng, lớp IP của router nào đó sửa đooir sai lạc IP đích là 1.2.3.5 IP Checksum được sử dụng tính toán IP đích bị hỏng IP checksum là hợp lệ vì vậy packet tiếp tục trên hướng tới đích sai với IP là 1.2.3.5 Giả định rằng IP 1.2.3.5 tồn tại Các gói bị hỏng đến IP đích sai Lớp IP xác nhận tính hợp lệ của checksum và nó là đúng bởi vì IP đích 1.2.3.5 được sử dụng trong IP checksum computation của router... bạn có thể thêm các giá trị hex của các trường 16 bit và sau đó lấy bù 1 và kết quả checksum phải tính như vậy IP checksum được kiểm tra và tính toán lại cho mỗi hop trên đườn từ nguồn tới đích Các router trung gian xác nhận tính hợp lệ của IP checksum, và nếu nó là đúng thì giá trị TTL được tăng lên 1 checksum của IP header phải được tính toán lại để phản ánh sự thay đổi trong IP header Hãy nhớ rằng... bạn có thể thêm các giá trị hex của các trường 16 bit và sau đó lấy bù 1 và kết quả checksum phải tính như vậy IP checksum được kiểm tra và tính toán lại cho mỗi hop trên đườn từ nguồn tới đích Các router trung gian xác nhận tính hợp lệ của IP checksum, và nếu nó là đúng thì giá trị TTL được tăng lên 1 checksum của IP header phải được tính toán lại để phản ánh sự thay đổi trong IP header Hãy nhớ rằng . Chương 8. Kiểm tra các trường của IP header Đây là một trong hai chương kiểm tra các trường trong gói IP. Chương này tập trung vào các trường header của. Các trường IP Header Hãy bắt đầu kiểm tra về các trường trong header IP. Mỗi trường sẽ được thảo luận về chức năng của nó, bất kỳ thông tin cần thiết về các