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.
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 sẻ sự nhầm lẫn
của tôi khi nó đã đua ra một ví dụ. Tôi đã kết thúc bằng ghi nhận tác giả và chuyên gia TCP / IP,
Doug Comer, người đã chia sẻ những ví dụ về một router nhầm địa chỉ IP đích. Tôi đã mở rộng
nhiều nhờ ông Comer cho việc xóa bỏ những rắc rối.
TCP Sequence Numbers

Các sequence number được sử dụng để nhận dạng các byte đầu của từng TCp segment được
gửi. Đây là một cách để theo dõi tất cả các TCP data được gửi và nhận được trong một TCP stream.
Hầu hết mỗi lần, có nhiều dữ liệu có thể được gửi trong một segment của gói TCP. Hoặc, một số
dịch vụ như rlogin có thể gửi một kí tự tại một thời điểm trên một TCP stream yêu cầu nhiều stream
trong phiên làm việc. Bởi vì TCP là một giao thức tin cậy, chúng ta phải có một cơ chế vào tài
khoản cho các dữ liệu được gửi và nhận. Một phần, mà được thực hiện bằng cách sử dụng các
sequence number của TCP.
Các sequence number không được lặp đi lặp lại trừ khi thử lại cùng một kết nối nếu một kết
nối ban đầu không thành công và người gửi nhận được gói không có lỗi từ người nhânnj dự định
hoặc một số loại thiết bị lọc gói. Sequence number đầu tiên (ISN) được sử dụng để chuyển đổi dữ
liệu giữa host nhận và host gửi trong giao thức TCP. Mỗi host trong quá trình chuyển đổi lựa chọn
một sequence number đầu tiên duy nhất khi gửi kết nối SYN đầu tiên tới máy khác.
Phương pháp sử dụng các chồng giao thức TCP/IP lựa chọn sequence number đầu tiên cho
chúng được kiểm tra bởi nmap để hỗ trợ cho việc lấy dấu tay của hệ điều hành. Có một file đến
nmap, các nmap-os-fingerprint có một danh sách rất nhiều các hệ điều hành với các phiên bản khác
nhau. Nmap thực hiện đưa một tập các kiểm tra lại một host mục tiêu. Nmap có thể phân loại một
hệ điều hành cụ thể bằng việc xem các giá trị trong các phản hồi tới các tác động bình thường và
không bình thường khác được gửi bằng việc quét một host với các giá trị dự định.
Các thử nghiệm đầu tiên thực hiện bởi một OS fingerprinting nmap scan là một trong số
nghiên cứu ISN được tạo ra bởi một host đang nhận từ máy gửi kết nối tới một cổng đang lắng
nghe. Sự khác nhau của TCP / IP stack sử dụng các phương pháp khác nhau để tạo ra ISN. Một số
hệ điều hành cũ hơn được sử dụng tăng một trị số dự đoán cho ISN cho mỗi kết nối mới.
Nhưng ai đó xem và sniffing có thể dự đoán và cướp một kết nối đang sử dụng thông tin này,
như đã được thực hiện trong cuộc tấn công Mitnick khét tiếng. Các hệ điều hành khác có thời gian
phụ thuộc vào thuật toán tăng giá trị dự định ISN lên dựa trên sự thay đổi thời gian đã đưa ra. Điều
này, quá không an toàn. Thuật toán an toàn nhất cho quá trình tạo ra ISN là một sự ngẫu nhiên
không thể đoán trước.
Tuy một mẩu thông tin nhỏ nhưng lý thú, SYN mà chúng ta đề cập đến như là cờ để bắt đầu
một kết nối TCP thực sự là rút ngắn cho sự đồng bộ hóa các sequence number. Thực hiện sau đây
của nmap đang sử dụng OS fingerprint scan tùy chọn (-O) cho thấy các cổng mở, sequence number

của TCP khó dự đoán và được phỏng đoán cho hệ điều hành.
nmap –O sparky
(The 1495 ports scanned but not shown below are in state: closed) Port
State Service
23/tcp open telnet
25/tcp open smtp
111/tcp open sunrpc
513/tcp open login
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
TCP Sequence Prediction: Class=random positive increments
Difficulty=46112 (Worthy challenge)
Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7
Sử dụng lệnh nmap –O để quét host Solaris sparky và xác định OS phát hiện ra rằng sự tạo ra
ISN là dựa trên một thuật toán sử dụng “tăng một trị số ngẫu nhiên tin cậy”. Và nó thông báo rằng
một sequence number của TCP dự định sẽ là “yêu cầu thích hợp”. sparky là một host Solaris 2.7 và
nó xuất hiện để không bị gian lận để ai đó đoán ra một TCP sequence mới dựa trên sequence trước
đó hoặc dựa trên thời gian.
Acknowledgement Numbers
Phương pháp mà TCP sử dụng để bảo đảm rằng dữ liệu nhận được là thông qua một xác nhận.
Các host nhận thiết lập cờ xác nhận và số xác nhận , nó được dung để xác nhận rằng host nhận đã
nhận được dữ liệu thực sự. số xác nhận được gửi bởi host nhận thực tế tương ứng với TCP sequence
number tiếp theo dự kiến sẽ nhận được.
Bởi vì một kết nối SYN dùng một sequence number, và bởi vì giá trị xác nhận là một trong
nhiều sequence number này, một số xác nhận hợp lệ phải lớn hơn 0. Khả năng này hiếm có. Có thể
sử dụng tất cả các 2000000000 cộng với TCP sequence numbers sẵn có với trường 32-bit mà nó
được lưu trữ ở đó. Nếu có khă năng, TCP sequence number sau được gửi là số lớn nhất cho phép
32-bit, , các host nhận bọc xung quanh và thừa nhận rằng sequence number dự kiến tiếp theo là 0.
Đây là một sự cố ít xảy ra.
Nmap có thể cố gắng để xác định host tồn tại bằng cách gửi đến một host từ xa một kết nối

TCP với việc thiết lập một cờ ACK để gửi đi. Phương thức này của host xác minh là nhiều thành
công hơn khi ping tới host bởi vì nhiều trang web bây giờ chặn các yêu cầu ICMP báo hiệu lại. Tuy
vậy, một router mà không duy trì trạng thái có thể cho phép giao thông “được tạo sẵn” trong đó cờ
ACK được thiết lập. Các đáp ứng mong đợi để các ACK được gửi đi là một RESET từ các host từ
xa, mà thực tế chỉ ra rằng các host từ xa vẫn hoạt động bất kể cổng quét đang lắng nghe. Phiên bản
hiện tại của nmap có một chữ ký bị lộ vì cờ ACK được thiết lập, nhưng số xác nhận là 0, được hiển
thị trong kết xuất sau đây.
verbo.52776 > win98.netbios-ssn: . ack 0 win 4096 <wscale 10,nop,mss
265,timestamp 1061109567[|tcp]>
TCP Flags
Các cờ TCP được dùng để chỉ ra chức năng của một kết nối TCP hoặc một phiên. Cờ SYN
bắt đầu một phiên và cờ FIN kết thúc một phiên. Một RESET được sử dụng để hủy bỏ một phiên.
Cờ ACK được thiết lập để cho biết một xác nhận dữ liệu của người nhận. Cờ ACK được thiết lập
trên tất cả các gói dữ liệu sau khi SYN đầu tiên. Cờ PUSH thường được sử dụng để báo cho host
gửi để viết tất cả các dữ liệu đệm của nó để gửi đến host đích và cho host đích để đẩy nó lên đến
tầngTCP. Trên thực tế có thể gửi dữ liệu mà không cần thiết lập cờ PUSH khi tất cả dữ liệu trong
bộ đệm gửi không phải là hoàn toàn rỗng. Cuối cùng, cờ URGENT được sử dụng để chỉ ra rằng dữ
liệu có độ ưu tiên cao nhất.
Cờ TCP có nhiều kết hợp hợp lệ khac nhau. Và cũng có rất nhiều kết hợp không hợp lệ khác
nhau được sử dụng cho các mục đích khác nhau. Gần đây trong tiến triển của NIDS, có nhiều
nghiên cứu về lưu lượng chỉ cho SYN đầu tiên. Máy quét nhận ra điều này và sẽ gửi một kết hợp
SYN / FIN mà có thể dưa ra một đáp trả từ một host. Các chồng TCP/IP của các hệ điều hành khác
nhau đáp trả một cách khác nhau để thiết lập cờ đột biến, do đó điều này được sử dụng để thử tới
fingerprint cảu hệ điều hành. Chúng ta sẽ xem xét một số trong những tình huống mà kết hợp flag
hợp lệ và không hợp lệ có thể xảy ra trong một vài phần tiếp theo.
TCP Corruption
Chỉ vì bạn nhìn thấy các kết hợp cờ TCP đột biến, nó không nhất thiết là một dấu hiệu của
hành vi có hại. Các gói dữ liệu có thể bị lỗi, và nó có thể giả tạo cờ TCP được thiết lập sau khi một
số loại lỗi trong phần TCP của gói. Nhìn vào gói sau đã nhận được trên một NIDS Shadow. Đây là
một Napster được cố gắng kết nối lại trong ngày khi Napster là một phương pháp tự do và hợp lệ

của Việt trao đổi MP3s:
host.home.com.1310 > napster.com.6699: SRP [bad hdr length] (DF)
Có hai bất mà đứng ra xem xét bản ghi. Đầu tiên là các thiết lập cờ đột biến của SRP, nghĩa
là cả ba cờ SYN, RESET, PUSH và được thiết lập đồng thời. Dấu hiệu tiếp theo là chú ý của
TCPdump bad hdr length.
Một bad hdr length là một lỗi được tạo ra bởi TCPdump khi chỉ định độ dài TCP header lớn
hơn độ dài TCP segment thực tế (header và data). Vì không có trường trong IP datagram chứa giá
trị chiều dài TCP header (header và data), TCPdump tính giá trị này bằng cách sử dụng các trường
nó không có. Nó trừ độ IP header từ tổng chiều dài IP datagram. Đối với các gói dữ liệu định dạng
đúng, điều này phản ánh đúng chiều dài TCP segment. Một trong những kiểm tra tính hợp lệ thực
hiện bởi TCPdump là để kiểm tra nếu chỉ định của gói TCP header chiều dài lớn hơn chiều dài TCP
được tính toán segment. Nếu so sánh này là đúng, có cái gì đó chắc chắn sai với chiều dài của một
trường, và đó là khi lỗi bad hdr length được hiển thị.
Nó sẽ trở nên rõ ràng tại sao TCPdump tin vào điều này bằng cách kiểm tra kết xuất đầu ra
hex sau. Thứ nhất, IP header được nằm trong các dấu ngoặc và TCP header nằm trong dấu lớn hơn
và dấu nhỏ hơn:
[4500 0028 8974 4000 7406 a9c5 1804 ee22
80f4 4c7b] <051e 1a2b 0000 029d 9efe a721
a7ae 5010 2058 ac31 0047 0050>
Bây giờ hãy quay sang chú ý 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 byte offset thứ 9 của IP header đã được in đậm để làm nổi bật
giao thức nhúng. Bởi vì chúng ta tìm ra 06 trong trường đó, chúng ta biết một TCP header sau.
Chiều dài tính toán của TCP segment khi đó là 40-20, cho chúng ta 20 byte cho TCP header va data.
Điều này là đủ chỗ cho một TCP header không có các tùy chọn và không có dữ liệu thí dụ có thể
được tìm thấy trên một SYN attempt đơn giản.
Tuy vậy, trong độ dài của TCP header, chúng ta tìm thấy một chiều dài 0xa trong phần in

đậm nibble bậc cao của byte offset thứ 12, nó chỉ ra một TCP header 40-byte sau khi chúng ta nhân
nó với 4 để chuyển đổi các từ 32-bit thành các byte .
Note: Một nửa byte 8 bit (4 bit) đôi khi còn được gọi là nibble (gặm). Nibble còn được gọi là
semioctet (nửa octet) trong ngữ cảnh mạng máy tính và viễn thông cũng như bởi một số tổ chức tiêu
chuẩn.
Cách sử dụng các trường này, bạn có biết tại sao TCPdump tạo ra những lỗi
bad hdr length
?
Đây là một datagram với tổng chiều dài là 40, trong đó có một 20-byte độ dài của IP header, Cho
đến nay TCP header tuyên bố được 40 byte. Chúng ta cần một IP datagram có chiều dài tối thiểu là
60 byte để chứa dữ liệu này nếu thực sự không có sai sót.
Có thể là gói tin này đã bị hỏng và checksum là không hợp lệ không? Hãy nhớ rằng, nếu điều
này liên quan đến sự gian lận trong các gói trong TCP header hoặc data, host duy nhất mà sẽ phát
hiện ra là host đích. Bộ cảm biến NIDS thường không xác nhận một TCP checksum.
Dưới đây là những gì chúng ta có thể suy luận về gói tin này. Khả năng là IP header của gói
tin là tốt bởi vì router liền trước không hủy bỏ nó. Router có nghĩa vụ phải xác minh các IP
checksum và âm thầm hủy bỏ nó với những checksum không đúng. Hiện tại, trước khi đạt đến host
đích và có IP checksum đã được xác nhận, nó đi qua bộ cảm biến nơi mà ICPdump tìm thấy một vấn
đề với nó. Có thể là router đã sửa đổi IP header sau khi checksum được tính toán, nhưng header
khác xuất hiện bình thường.
Tại thời điểm này, chúng ta không biết nếu gói tin bị hủy bỏ ngẫu nhiên hay cố tình vì bất cứ
lí do gì. Chỉ có thể dung cách khác để xác minh vấn đề mất gói tin là tự tính toán checksum của gói
tin là hợp lệ trên bộ cảm biến hoặc xem xét host nhận phản ứng lại như thế nào (napster.com). Vấn
đề của việc tìm kiếm phản ứng của napster.com như thế nào khi mà checksum không hợp lệ, chúng
ta sẽ không thấy phản ứng. Tuy nhiên, nếu checksum hợp lệ, sự kết hợp bất thường này của các cờ
có thể không đưa ra một phản ứng trả lời. Nếu chúng ta không quan sát một phản ứng không chắc
xảy ra từ napster.com (nhiều khả năng là một RESET), điều này có nghĩa rằng checksum là hợp lệ
và gói tin không bị hủy bỏ trên tuyến đường từ nguồn tới đích. Điều này có nghĩa là gói tin có
nhiều khả năng bị thay đổi bởi một giá trị đột biến tại nguồn. Rất có khả năng các trường 16-bit đã
bị đổi chỗ hoàn toàn xảy ra dẫn đến làm hỏng gói tin, nhưng sẽ không có biểu hiện của nó trong

checksum.
Vern Paxson, người sáng tạo của IDS được gọi là Bro, nói chuyện về giao thông mạng ông
đã gán cho là “crud-khó chịu” trong bài báo “Bro: một hệ thống phát hiện thâm nhập mạng trong
Real-time”. Khái niệm crud của ông là “các lỗi thi hành không có hại” mà tạo ra các bệnh lý về
kiểu giao thông mạng mà giống như các cuộc tấn công chính hãng. Ông trích dẫn ví dụ về một
chồng TCP/IP không đúng tiêu chuẩn mà thông thường thiết lập các cờ URG trên một SYN và
những chồng giao thức khác thiết lập cờ DF trên các đoạn giao thông mạng. Mặc dù việc này không
giống với vấn đề sai lạc gói tin, điểm quan trọng cần nhớ không phải là tất cả giao thông mạng bất
thường bạn đưa ra là có hại. Nó có thể ở xa với số lượng rất nhỏ có thể do sai lạc hoặc crud.
ECN flag Bits
Cho đến gần đây, hai bit cao của byte TCP đã được biết đến như là các bit để dành. Chúng
không có mục đích, và giá trị đặt trong các bit phải là 0. Tuy nhiên, khi có công cụ như nmap,
nó đã được phát hiện ra rằng các bit có thể được sử dụng để giúp cho việc lấy dấu vân một hệ
điều hành từ xa. Không giống hệ điều hành chồng giao thức TCP/IP mà hệ điều hành sẽ trả lời
khi các bit đã được thiết lập.
Một số sẽ thiết lập lại các bit bằng 0, và một số khác thì vẫn giữ giá trị hiện tại. Do đó, một
số hiểu biết sâu có khả năng được tạo từ hệ điều hành các host từ xa của chồng TCP/IP. Điều này có
thể không đủ để thông báo cho máy quét của hệ điều hành, nhưng sử dụng kết hợp với một số xét
nghiệm khác, hệ điều hành có thể được phỏng đoán với một xác suất cao.
Hãy nhớ lại khi chúng ta đã thảo luận phân biệt về các dịch vụ byte trong Chương 8, "Kiểm
tra các trường IP Header" chúng ta giới thiệu một mục đích mới cho hai bit thấp được biết đến như
Explicit Congestion Notification (ECN)? Mục đích cho một router để có thể thông báo cho một
người gửi rằng có tắc nghẽn trong mạng và giảm tốc độ gửi.
Làm thế nào đều trên không xảy ra? Hiện nay, như được thảo luận trong RFC ECN 3.168,
vận chuyển duy nhất có khả năng phản ứng lại để thông báo tắc nghẽn là TCP. Vì vậy, TCP phải
được chuẩn bị để đối phó với việc này. RFC cung cấp bằng cách sử dụng hai bit cao của byte cờ
TCP (xem hình 9,3) như các trường cho ECN. Bit ở bên phải của bit cao được gọi là bit ECN-echo.
Bit này được bật khi TCP nhận được một gói mà các bit đã trải qua tắc nghẽn đặt tại các byte dịch
vụ khác biệt của IP header. Điều này có nghĩa là cả hai điểm cuối của cuộc đàm thoại TCP là ECN-
capable, được xác định trong thời gian bắt tay ba bước.

Figure 9.3. The ECN bits of the TCP flag byte.
Nếu TCP thiết lập bit ECN-echo, mục đích là để thông báo cho người gửi giảm tốc độ mà tại
đó nó đang gửi dữ liệu vì có tắc nghẽn giữa người gửi và người nhận. Khi xác nhận được một TCP
segment với bit ECN-echo được thiết lập, người gửi giảm cửa sổ tắc nghẽn của nó, kích thước của
bộ đệm gửi giảm đi một nửa. Sau khi nó phản ứng theo cách này, nó mở bit Window Congestion
Reduce (CWR) để thông báo cho phía bên kia của cuộc đàm thoại khắc phục hậu quả hành động để
giảm tắc nghẽn đã xảy ra. Bit này được tìm thấy trong bit cao của byte TCP flag.
Mặc dù cơ chế này sẽ giúp giảm số lượng các gói dữ liệu bị bỏ, nó dự đoán rằng nhiều NIDS
hiện tại sẽ bắt đầu báo động trên các cờ byte flag TCP mới đang được sử dụng. Ngay bây giờ, hầu
hết sử dụng các bit chỉ nhằm mục đích quét. Ngoài ra, một số thiết bị lọc gói sẽ không cho phép gửi
đến các TCP segment với thiết lập các bit này. Vì vậy, nhiều tuỳ biến sẽ phải được thực hiện để
ECN mở đầu trôi chảy và phân biệt nó với các máy quét lừa đảo.
Operating System Fingerprinting(Nhận dạng OS)
Khi nmap được đặt trong chế độ nhận dạng OS với tùy chọn -O, nó gửi kết hợp kết quả thay
đổi của một số cờ khi một cổng mở được phát hiện. Nhìn vào đầu ra sau từ hệ điều hành từ xa nmap
quét:
nmap –O win98
20:33:16.409759 verbo.47322 > win98.netbios-ssn: SFP 861966446:861966446(0)
win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
20:33:16.410387 win98.netbios-ssn > verbo.47322: S 49904150:49904150(0) ack
861966447 win 8215 <mss 1460> (DF)
nmap –O sparky
20:37:00.738412 verbo.50107 > sparky.echo: SFP 2326441544:2326441544(0) win
2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
nmap –O linux
20:44:50.370158 verbo.42318 > linux.ftp: SFP 1749165064:1749165064(0) win
1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
Trong lần quét đầu tiên của một host Window 98, kết quả thay đổi tổ hợp của cờ
SYN/FIN/PUSH/URG được gửi tới Wimdow cổng 139. Đây là cổng dịch vụ của một phiên
NetBIOS, và host Window lắng nghe trên cổng này. Tuy nhiên, ngạc nhiên là nó trả lời với một xác

nhận! cách xử lý này không phải là những gì chúng ta mong muốn.
Trong lần hai nmap quét, giống như kĩ thuật gửi kết quả thay đổi tổ hợp của các cờ
SYN/FIN/PUSH/URG tới một cổng Solaris đang lắng nghe và không có trả lời nào được đưa ra.
Tổ hợp của các cờ giống nhau được gửi tới cổng nghe Linux fpt trong lần quét thứ ba và không có
trả lời nào được nhận. Đây là cách xử lý theo mong muốn mà tuân theo thông số kĩ thuật RFC. Tuy
vậy, bạn có thể xem cách kiểm tra này có thể được dùng để phân biệt các host Windows từ tất cả
các cổng khác.
Như một phân tích mới, thường thì rất khó để phân biệt giữa những hành vi có hại xuất hiện
và các chồng giao thức TCP/IP không phù hợp với thông số kĩ thuật RFC. Thật khó để hiểu được ý
định khi mà trả lời không như mong đợi. Nhiều lần, thậm chí một nhà phân tích kinh nghiệm cũng
không biết nếu sự thiết lập cờ TCP bất thường là một dấu hiệu của một số chồng TCP/IP không dễ
điều khiển hoặc ai đó đưa lên với ý định không tốt.
Retransmissions (Sự truyền lại)
Điều gì nếu cố gắng một kết nối TCP ban đầu, nhưng các host cố gắng kết nối không nhận
được phản hồi từ các host đích? Một host đích có thể không trả lời bởi vì kết nối không tới được
hoặc có thể không tồn tại. Một router có thể cố gắng phát một thông điệp ICMP về host đích
không thể truy cập được, nhưng nếu router đã im lặng phát thông báo không thể kết nối, máy gửi
sẽ không bao giờ biết rằng có một vấn đề. Một host đích có thể đặt sau một số kiểu thiết bị lọc gói
mà các khối kết nối bên trong, nhưng vẫn âm thầm hủy bỏ kết nối mà không cần thông báo cho
host gửi.
Cũng có thể là host đích trả lời xác thực (SYN / ACK) hay không xác thực (RESET / ACK),
nhưng một số lý do host gửi không nhận được các trả lời này.
Cố gắng bổ sung hoặc truyền lại được thực hiện để liên hệ với host trong những tình huống
như thế này. Số lượng truyền lại và khoảng thời gian mà sự truyền lại đang cố gắng thay đổi theo
giao thức TCP/IP. Cuối cùng, host gửi dừng các cố gắng kết nối.
Làm thế nào bạn có thể phân biệt retransmissions hoặc retries từ tách biệt các kết nối TCP
mới tới một host đích? Các cổng nguồn vẫn như cũ, và số thứ tự TCP không thay đổi cho các