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

Chia sẻ: Doan Thi Nhan | Ngày: | Loại File: DOC | Số trang:73

Thêm vào BST

Báo xấu

335
lượt xem 75
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Đâ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 đó....

Chủ đề:

Bình luận(1) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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 cac thông bao gởi qua môt mang 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/Ptacek-Newsham- Evasion- 98.html. 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 www.iana.org/assignments/protocol-numbers. 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@insecure.org ( www.insecure.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:20@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. Table 8.1. Initial TTL Values by Operating Syste OS Version Platform TTL Windows 9x/NT Intel 32 AIX 4.3.x IBM/RS6000 60 AIX 4.2.x IBM/RS6000 60 Cisco 11.2 7507 60 IRIX 6.x SGI 60 Linux 2.2.x Intel 64 OpenBSD 2.x Intel 64 Solaris 8 Intel/Sparc 64 Windows 9x/NT Intel 128 Windows 2000 Intel 128 Cisco 12.0 2514 255 Solaris 2.x Intel/Sparc 255 Điều gì nếu bạn muốn thử nghiệm để xem có một packet từ IP nguồn cho biết nó có từ đâu? Bạn có thể xem xét TTL đến, việc ước tính TTL ban đầu bằng việc sử dụng Bảng 8.1, và trừ đi TTL đến từ các TTL ban đầu để cung cấp cho bạn tổng số bước truyền cho các packet đến mạng của bạn. Sau đó, traceroute có thể được thực thi để xem nếu số lượng các bước truyền quay về tới IP nguồn được đưa ra xấp xỉ số bước truyền ban đầu được đưa vào mạng của bạn. Nó có thể là tuyến đường quay lại của IP nguồn được đưa ra có thể là khác với con đường đưa đến mạng của bạn vì những động thái của định tuyến, nhưng họ thường làm có số bước truyền(hop) gần, giả sử mà không có router chính hoặc các vấn đề lưu lượng trên đường đi. Rất có thể là, nếu bạn có IP nguồn khác nhau đồng thời vào mạng của bạn, họ có các giá trị TTL đến khác nhau. Nếu bạn thấy IP nguồn khác nhau vào mạng của bạn cùng một lúc, cùng làm một tác vụ, với TTL đến giống hệt nhau thì IP nguồn có thể bị giả mạo. Hãy nhận biết rằng một số chương trình quét thừa nhận ngẫu nhiên hóa giá trị TTL ban đầu chỉ là để loại bỏ dấu vết của datagram gốc. Nhìn vào ID IP và các giá trị TTL cùng với việc phát hiên giả mạo.
Xem xét kết quả sau đây: 07:31:57.250000 somewhere.de > 192.168.104.255: icmp: echo request (ttl 246, id 5134) 07:34:18.090000 somewhere.jp > 192.168.104.255: icmp: echo request (ttl 246, id 5137) 07:35:19.450000 somewhere.ca > 192.168.104.255: icmp: echo request (ttl 246, id 5141) Điều này cho thấy lưu lượng từ ba xác nhận IP nguồn khác nhau cho cùng một IP đích ít để ý. Các nhãn thời gian trong vòng vài phút của nhau, và niên đại của các giá trị nhận dạng IP là giá trị kiểm tra. Điều gì là lạ về các giá trị nhận dạng IP, và tại sao một người có thể gửi lưu lượng như này? Lợi ích khi giá trị xác minh IP trùng khớp ngẫu nhiên từ ba nguồn khác nhau được đưa ra tới cùng một IP đích -192.168.104.255 là gì? Mạng con cụ thể 192.168.104 không có các host đang hoạt động, do đó, điều này làm cho lưu lượng truy cập nhiều hơn đáng ngờ. Mặc dù điều này có thể là một sự trùng hợp rất lớn, có nhiều khả năng rằng một ai đó trên một host đã được gửi ICMP echo request (ping) đến địa chỉ nội bộ 192.168.104.255 không thường xuyên. Nhớ lại rằng giá trị nhận dạng IP là một trường 16-bit với một loạt các giá trị từ 1 đến 65.535. Sự tạo thành nhóm của các giá trị giữa 5.134 và 5.141 là cao không cho ba nguồn duy nhất. Nó dường như cũng là host đặc biệt không hoạt động (có lẽ là một máy đơn) gửi các gói dữ liệu, xem xét bằng việc tăng từng giá trị nhỏ trong giá trị nhận dạng IP lên vài phút. Điều này giả định rằng các số nhận dạng IP chưa bị thay đổi. Như với nhiều lưu lượng bất thường thấy trên mạng, những gì là nhiều dễ dàng hơn để tìm hiểu lý do tại sao. Có lẽ đây là một sự cố gắng ánh xạ với một trong hai nguồn thực và nguồn giả. Điều này phát ra một hiệu ứng màn khói-smokescreen; thậm chí nếu chúng ta chú ý điều này, rất có thể là chúng ta sẽ không thể xác định IP nguồn thực bằng bất cứ cách nào. Hãy kiểm tra lưu lượng giống nhau này, nhưng bây giờ chúng ta hãy xem xét nó trong mẫu các giá trị TTL. Thật kì cục, tất cả các giá trị TTL đến giống hệt nhau. Điều này có xu hướng để xác nhận sự suy đoán rằng tất cả ba gói dữ liệu có nguồn gốc từ cùng một host. Cơ hội để các IP nguồn khác nhau gửi lưu lượng truy cập vào mạng của chúng ta có thể xảy ra (không có mưmu mẹo-uncrafted) TTL ban đầu là 255 và mỗi lần đếm đến 9 hop và tất cả họ đã quan tâm đến các địa chỉ IP giống nhau tại cùng một khoảng thời gian như nhau là gì? Sử dụng tùy chọn-vv của TCPdump có thể cho chúng ta thêm hai trường khác của hiện thị mà có thể hỗ trợ trong việc xác định nếu khả nghi lưu lựơng đã giả mạo. Khi lưu lượng truy cập này đã được phát hiện trên mạng, traceroutes đã được thực thi lại để các IP nguồn được đưa ra trong việc thử để xác định xem IP nguồn là thật hay giả. Dưới đây là các kết quả của traceroutes: traceroute somewhere.de arriving TTL: 246
probable initial TTL: 255
expected hop count back: 9 actual hop count back: 13 traceroute somewhere.jp arriving TTL: 246 probable initial TTL: 255 expected hop count back: 9 actual hop count back: 13 traceroute somewhere.ca arriving TTL: 246 probable initial TTL: 255 expected hop count back: 9 actual hop count back: 12 Thí dụ này sử dụng traceroutes không thuyết phục lắm. Mỗi một trong ba IP nguồn khác nhau đã có khoảng 12 hoặc 13 hop trở lại từ mạng mà nhờ vào bộ cảm biến các gói. Tuy nhiên, nó cung cấp một ví dụ về cơ học được sử dụng để thử xác minh tính xác thực của IP nguồn. Số hop trả về từ traceroute thì gần với số hop dự kiến. Tuy vậy, bằng cách sử dụng các giá trị nhận dạng IP kết hợp với những kết quả này thì các IP nguồn có thể là giả mạo. Một số hop trả về tới IP nguồn có nhiều thay đổi từ số hop dự kiến sẽ là một dấu hiệu tốt rằng IP nguồn đã bị giả mạo. Ngoài ra, nếu số hop thực tế trả về thỏa mãn ba IP nguồn khác nhau về căn bản không giống nhau nhiều theo từng hop, điều này cũng sẽ là một chỉ báo tốt hơn về giả mạo. Có một số khó khăn liên quan đến sử dụng traceroute về pháp lý. Đầu tiên, bạn có thể không có quyền dùng traceroutes đến hoặc từ mạng của bạn bởi vì khối router / firewall của ICMP traffic, thông báo cụ thể time exceeded in-transit" and "port unreachable". Thứ hai, lưu ý rằng traceroute đến một địa chỉ IP thực có thể không như mong muốn bởi vì nó có khả năng có thể giải đáp sự quan tâm của bạn trong một trang web. IP Checksums Checksums được sử dụng để bảo đảm rằng dữ liệu truyền không bị lỗi từ nguồn tới đích. Thuật toán được sử dụng cho giao thức TCP / IP là để 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 xác nhận tính hợp lý trong đường dẫn từ nguồn tới đích. Các checksum protocol nhúng như: TCP, UDP và ICMP được xác nhận chỉ bởi host đích. IP checksum được xác nhận khi qua mỗi router khi nó đi qua từ nguồn tới đích và cuối cùng được xác nhận là tốt bởi host đích.
Nếu checksum được tính toán không phù hợp với checksum được tìm thấy trong datagram, datagram sẽ được âm thầm bỏ đi. Thử không thực hiện thông báo một vấn đề tới host source. Tưởng tượng rằ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 được tách ra, chúng ta lấy phần bù 1 của mỗi trường. Thao tác này đơn giản là lật bit. Tất cả các giá trị phần bù 1 riêng này được thêm vào để hình thành checksum. Ví dụ: 4 5 0 0 Hex Representation 0100 0101 0000 0000 Binary Representation 1011 1010 1111 1111 1's Complement Trong đầu ra trước đó, bạn nhìn thấy 16 bit đầu tiên của một khởi tạo rất phổ biến của IP header. Mỗi giá trị hex đại diện cho 4 bit nhị phân và mỗi giá trị của các bit nhị phân này được lật. Nó trở thành giá trị bù 1. Thao tác này được giao hoán bởi vì 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 checksum này chỉ xác nhận các trường trong IP header, không phải là phần còn lại của datagram mà gồm có header của giao thức nhúng và dữ liệu. Lý do cho việc kiểm tra IP checksum cho từng hop tạo ý thức khi bạn nghĩ về nó. Tưởng tượng trường hợp xấu nhất là khi IP đích đã hỏng. Nó àm cho không có ý thức để chuyển một packet khi nó đã bị hỏng bởi vì sự sửa đổi có thể làm sai lạc ý định của packet. 4500 003c 4500 = 0100 0101 0000 0000 1011 1010 1111 1111 003c = 0000 0000 0011 1100 1111 1111 1100 0011 1011 1010 1100 0010 003c 4500 4500 = 0100 0101 0000 0000 1011 1010 1111 1111 1011 1010 1100 0010
Xem xét đầu ra trên. Chúng ta trao đổi hai trường 16 bit đầu tiên (4500 003c) trong IP header. Checksum được tính toán theo trình tự chính xác của các trường 16 bit này là: 1011 1010 1100 0010 (không kèm theo các bit phần cao). Nhưng nếu chúng ta đảo ngược các trường và tính checksum, nó là chính xác như nhau. Một datagram với các trường 16 bit được tráo đổi là một datagram khác hoàn toàn về ý nghĩa và vấn đề giải quyết khi các trường được tráo đổi. Vì vậy, đây là hạn chế của việc sử dụng cách tính toán này. Tại sao không sử dụng một thuật toán phức tạp và đáng tin cậy hơn cho checksum? Việc tính toán này được thực hiện cho từng packet mà một router tiếp nhận. Thuật toán đơn giản và nhanh hơn về thời gian tính toán. Thuật toán checksum là một thuật toán nhanh và thường đáng tin cậy, và việc trao đổi hoàn toàn của các trường 16 bit là hiếm khi xảy ra. Đọc thêm về các IP checksum và nhìn vào RFC 1071. Tóm lược Hãy tóm tắt một số ý tưởng cần được chuyển tải trong chương này. Đầu tiên, mặc dù NIDS của bạn là một công cụ cần thiết để giảm thiểu rủi ro, nó không phải là một liều thuốc để phát hiện tất cả lưu lượng truy cập có hại. Một trong những lý do này là chèn và tránh các cuộc tấn công có thể là nguyên nhân để NIDS sai trong việc rà soát lưu lượng mạng. Có rất nhiều cuộc tấn công khác nhau mà có thể được sử dụng và nó chỉ đơn giản là không thể cho một NIDS biết làm thế nào để mọi host mục tiêu khác nhau trên mạng sẽ phản ứng với một packet. Một NIDS không thể biết được sắc thái thực hiện của riêng từng host của chồng giao thức TCP/ IP. Đồng thời, các NIDS là không nhận thức được sự khác biệt topo mạng có thể được sử dụng trong một số các cuộc tấn công như các gói dữ liệu với số TTL thấp rằng sẽ không bao giờ đến được host mục tiêu. Việc sử dụng host-based IDS có thể được sử dụng để củng cố bảo mật được cung cấp bởi NIDS. Một nhà phân tích hiểu biết cần phải nhận thức của các kiể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 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ó hại. Bởi vì đây là một chủ đề khá rộng rãi, chương các trường địa chỉ trong từng giao cụ thể. Hy vọng rằng, đây sẽ là phần dành riêng cho khối kiến thức về quản lý các giao thức. TCP Quay lại trong Chương 2, "Giới thiệu về tcpdump và TCP," chúng tôi đã thảo luận rằng TCP là một giao thức đáng tin cậy. Điều này có nghĩa rằng TCP giám sát việc trao đổi dữ liệu và biết được khi có một vấn đề có thể bằng cách sử dụng các trường như sequence and acknowledgement numbers sắp xếp và theo dõi dữ liệu được trao đổi. TCP header có nhiều trường hơn UDP và ICMP vì TCP cầu duy trì trạng thái và luồng điều khiển tối ưu giữa người gửi và người nhận. Chúng ta sẽ xem xét các trường này và các trường khác trong bối cảnh sử dụng bình thường và bất thường. Port Các trường port là hai trường 16 bit tách rời trong IP header, một cho port nguồn( offset thuộc byte 0 và 1 từ TCP header) và một cho port đích (offset của byte 2 và 3 từ TCP header).
Phạm vi giá trị hợp lệ từ 1 tới 65535. việc sử dụng port 0 là bất thường và được xem là dấu hiệu duy nhất của việc đặt không đúng cổng. Khi một host nguồn mong muốn kết nối tới một host đích, không lâu port nguồn điển hình được chọn trong dải các cổng lớn hơn 1023. đối với mỗi kết nối mới mà các host cố gắng để không phải thử lại, không lâu sau thì một cổng khác cũng cần được lựa chọn. Khái niệm về TCP retries hoặc retransmission sẽ được diễn tả sau trong chương này trong phần “Retransmissions”. Trong một máy quét tương lai, bạn sẽ có khả năng nhìn thấy giá trị cổng nguồn tăng lên bằng 1 cho mỗi kết nối mới. Một trong những dấu hiệu lộ ra của một máy nmap SYN quét để tìm các cổng TCP mở là một cổng nguồn tĩnh được tiếp tục dùng trên nhiều kết nối TCP mới. Ví dụ: nmap –sS sparky 09:40:43.964215 verbo.47247 > sparky.1548: S 2401927088:2401927088(0) win 2048 09:40:43.964412 verbo.47247 > sparky.24: S 2401927088:2401927088(0) win 2048 09:40:43.964465 verbo.47247 > sparky.1547: S 2401927088:2401927088(0) win 2048 09:40:43.964553 verbo.47247 > sparky.2564: S 2401927088:2401927088(0) win 2048 09:40:43.964604 verbo.47247 > sparky.1484: S 2401927088:2401927088(0) win 2048 09:40:43.964642 verbo.47247 > sparky.1460: S 2401927088:2401927088(0) win 2048 09:40:43.964695 verbo.47247 > sparky.628: S 2401927088:2401927088(0) win 2048 09:40:43.964748 verbo.47247 > sparky.1112: S 2401927088:2401927088(0) win 2048 Mặc dù chúng ta sẽ mong đợi cổng nguồn của máy quét để chuyển đổi cho từng kết nối SYN mới tới các cổng mới của host mục tiêu, số cổng nguồn không đổi là 47247. Ngược lại, khi nhìn vào động thái mặc định được đưa ra bởi công cụ quét khác là hping2. Tùy chọn –s của kping2 thực hiện một kiểu khác của quét SYN. Nó tăng trị số cổng nguồn như mong đợi, nhưng nó cố gắng mở cổng mục tiêu là cổng đích 0. Mục đích của kiểu quét này rõ ràng không phải là để tìm một cổng listening. Kiểu quét này được sử dụng để xem một response RESET nếu host còn tồn tại, bởi vì không nên có các host nghe tại cổng 0. Đây là đầu ra từ hping2: hping2 –S sparky 09:44:13.882207 verbo.1788 > sparky.0: S 1553132317:1553132317(0) win 512 09:44:14.876837 verbo.1789 > sparky.0: S 1894028093:1894028093(0) win 512 09:44:15.876836 verbo.1790 > sparky.0: S 2032501562:2032501562(0) win 512 09:44:16.876832 verbo.1791 > sparky.0: S 851202745:851202745(0) win 512
TCP Checksums Như đã đề cập trước đây, các giao thức nhúng có các checksum hợp lý. Các gói này bao gồm header nhúng và dữ liệu tương ứng của giao thức TCP, UDP và ICMP. Không giống như IP checksum, đây là các checksum end-to-end được tính toán bởi nguồn và được xác nhận chỉ bởi host đích. TCP checksum đã được chọn làm đại diện cho các checksum của giao thức nhúng. UDP không yêu cầu tính toán một checksum như IP, TCP và ICMP. Tuy nhiên nó được đề cập cao. The checksums nhúng cho các giao thức TCP và UDP được tính bằng cách sử dụng một pseudo-header ngoài các tiêu đề giao thức nhúng và dữ liệu. A pseudo-header bao gồm 12 byte của dữ liệu được miêu tả trong hình 9.1: nguồn và IP đích, các 8-bit, giao thức tìm thấy trong các tiêu đề IP, và lặp lại một chiều dài của giao thức nhúng (đây là tiêu đề giao thức chiều dài cộng với số của byte dữ liệu).Các zero-pad lĩnh vực tìm thấy trong các byte 8 bù đắp được sử dụng để pad 8-bit, giao thức lĩnh vực đến 16 bit, vì checksums được thực hiện trên 16-bit của khối dữ liệu. Các checksum của giao thức nhúng cho TCP và UDP được tính toán sử dụng như một header giả trong việc header và dữ liệu cho giao thức nhúng. Một pseudo-header (header giả) bao gồm 12 byte dữ liệu được mô tả trong hình 9.1: IP đích và nguồn, 8 bit protocol được tìm thấy trong IP header, và một bản sao độ dài của giao thức nhúng (đây là độ dài protocol header cộng với số byte dữ liệu). Tường zero-pad được tìm thấy offset byte thứ 8 được sử dụng để đệm 8 bit của trường protocol trong 16 bit vì các checksum được thực hiện trên khối 16 bit dữ liệu. Figure 9.1. TCP checksum pseudo-header fields. Tại sao là pseudo-header lại cần thiết? Đây là một kiểm tra kép được sử dụng bởi các host nhận để xác nhận rằng các lớp IP không phải vô tình không chấp nhận một datagram tư trước cho host khác hoặc là IP đã không phải vô tình cố gắng để cung cấp cho TCP một datagram là giao thức khác. Nếu có một số sủa đổi làm sai sót xảy ra trong đường truyền, các xác nhận của IP checksum có thể hoặc không thể phát hiện ra điều này, nhưng một số trường từ IP header được bao gồm trong quá trình tính toán pseudo-header checksum để giúp bảo vệ chống lại điều này.
Chúng ta hãy xem xét một ví dụ rất cụ thể như thế nào pseudo-header việc bảo vệ chống phân phối các gói tin đến không đúng host. Hình 9.2 được cung cấp để trợ giúp trong quá trình Visualizing. Giả định rằng chúng ta có một host gửi một packet đến IP đích 1.2.3.4. Chúng ta sẽ sử dụng giao thức TCP như mootj giao thức nhúng, nhưng nó thực sự không quan trọng nếu tầng vận chuyển là TCP hay UDP, bởi vì cả hai đều sử dụng pseudo-header. Checksum của tầng transport bao gồm các trường pseudo-header trong các checksum computation. Do vậy, cho IP đích một giá trị là 1.2.3.4 được sử dụng trong TCP checksum computation. Figure 9.2. Pseudo-header checksum protection. Trên đường đi của packet từ host gửi, gói đi qua một router , bạn nhớ rằng phải xác nhận IP checksum trước khi chuyển tiếp nó. Giả sử router xác nhận IPchecksum, tăng trị số TTL, và sau đó cần tính toán lại IP checksum mới. Đối với một số lý do bất khả 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 sai.Gói này được đẩy lên tầng transport nơi TCP sử dụng trường pseudo- header trong việc xác nhận checksum. Tuy nhiên, việc xác nhận TCP checksum sử dụng IP đích 1.2.3.5 trong gói IP header bị hỏng để đối chiếu xác nhận lại với checksum của gói TCP thực tế. Tuy nhiên, điều này không phù hợp với checksum TCP pseudo-header từ host gửi là 1.2.3.4 được sử dụng như là IP đích trong checksum của pseudo-header. Host 1.2.3.5 sau đó loại bỏ packet vì checksum của giao thức nhúng không khớp với checksum tính toán được thực hiện bởi host đích. A Cry for Help Trong khi đọc bài viết về mục đích của pseudo-header, nó làm cho tôi có cảm giác hoàn hảo rằng nó được sử dụng như là một kiểm tra bổ sung để đảm bảo rằng packet không được gửi đến nhầm host hay giao thức. Tuy vậy, đối với cuộc sống của tôi, tôi không thể hình dung điều này đã được thực hiên như thế nào. Tôi hỏi một số đồng nghiệp, nhưng họ cũng được chia