Xem mẫu
- 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
nguon tai.lieu . vn