Những cuộc đối thoại với rookie - Phần 13

16. công cụ tiện ích hay đồ tra tấn: 
Suốt nhiều tuần qua, tôi vùi đầu vào công việc. Các công trình đang đi vào giai đoạn chạy nước rút cho kịp hạn định nên tôi chẳng còn mấy thời gian để trao đổi với bộ bốn. Tôi vẫn nhận mail từ 'cuti', 'docco', 'haothu' và 'ccxx' khá đều đặn và không có chọn lựa nào khác hơn là trả lời qua quít và hẹn gặp lại trong vài tuần tới. Bộ bốn cũng có vẻ khá bận rộn với bài vở ở trường. Mỗi lần trả lời e-mail, tôi luôn luôn nhắc bộ bốn xem lại nội dung của những lần 'đà khía' trước đây và khuyên mấy trự ấy đào sâu vào các chi tiết quan trọng. Tuần sau 3/4 khối lượng công trình tôi đang làm sẽ hoàn tất, tôi gởi chung một e-mail đến bộ bốn và hẹn gặp nhau chiều thứ bảy. Tất nhiên cả bọn náo nức chờ đợi buổi tái ngộ sau một thời gian dài vì tôi nhận e-mail hồi đáp thật nhanh với nội dung thật hứa hẹn. 


Hai giờ kém mười lăm, tôi vào YIM. Ngỡ rằng mình vào sớm nhưng không ngờ đã có 'ccxx' và 'cuti' đang 'vàng khè' online. Tôi chào hai trự: 

"Chào hai đứa, làm gì mà vô sớm vậy?" 

'cuti' đáp lời bằng một cú invitation: 
"Dạ, tụi em cũng mới lên chừng 20 phút thôi anh. Mình 'conference' chớ anh?" 

Tôi tiếp nhận cú invitation của 'cuti' và hỏi tiếp: 
"Sao? thời gian qua mấy đứa học hành, sinh hoạt ra sao rồi? Có gì vui không?" 

'cuti' lém lỉnh: 
"Dạ cũng chẳng có gì vui hết anh. Cũng bài với vở và bao nhiêu thứ để mày mò. Chỉ có 'ngày tân hôn' mới vui thôi anh." 

Tôi cười phá lên và đáp: 
"Hì hì, chưa có võng lọng về làng mà đòi 'rước nàng về dinh' sao cậu?" 

'ccxx' chêm vào: 
"Đúng đó, chưa có võng lọng thì đừng ở đó mà... mơ " 

'cuti' cũng chẳng vừa: 
"Em chả mơ đâu anh. Em đang 'hâm nóng' đó thôi, hì hì." 

Bọn tôi tán gẫu dăm ba phút thì 'docco' vào: 
"Em chào anh, chào hai ông bà.... non. " 

Tôi chào lại 'docco': 
"Khoẻ không em? Dạo này thế nào?" 

'docco' đáp: 
"Dạ, dạo này em cũng bận rộn lắm. Em đang cố luyện 'nội công' nên cũng túi bụi luôn." 

Tôi hỏi thêm: 
"Luyện nội công gì mà túi bụi em?" 

'docco' đáp: 
"Dạ, thì bao nhiêu là thứ mà mấy anh em mình 'đà khía' đó. Càng suy gẫm, tìm hiểu, em càng thấy thấm cái gọi là 'giềng mối' mà anh đã đưa ra. Lúc trước em cảm thấy mọi chuyện rất lờ mờ. Em thường thắc mắc và cũng đã có lần hỏi anh là mình nên bắt đầu từ đâu. Cho đến nay, em cũng chẳng biết câu trả lời và em cũng không rõ em đã bắt đầu từ đâu nhưng em đã thấy được mối liên quan giữa các mảnh kiến thức. Để hiểu B, phải nắm A, để hiểu C, phải nắm A và B và cứ thế mà mở rộng ra. Cái 'kinh nghiệm xương máu' em thấy được là để hiểu B không chỉ nắm A mà phải thực sự nắm A. Chừng nào còn có điều mù mờ về A thì về sau, càng ngày sẽ càng chồng chất những mù mờ." 

Tôi cười hoan hỉ và đáp 
"Tốt lắm. Anh nghĩ là em vượt ra khỏi cái 'ổ nhện' rồi đó. Một khi đã nắm được cái nguyên lý 'giềng mối' thì vấn đề còn lại chỉ là thời gian mà thôi. Bởi vì em cần phải có thời gian để tiếp thu kiến thức. Không ai có thể đốt giai đoạn được cả. Riêng với câu hỏi nhức nhối mà anh thường nghe bắt đầu từ đâu? thì anh cũng không có câu trả lời nhưng tận cùng mà nói, mình phải biết mình muốn đi đến đâu? trước khi tự hỏi mình bắt đầu từ đâu?. 

'ccxx' thắc mắc: 
"Anh nói thêm một tí về vấn đề này được không anh? Em cũng tự hỏi không biết mình nên bắt đầu từ đâu?" 

Tôi đáp: 
Lắm lúc có nhiều người hỏi anh câu hỏi này, anh chỉ có thể gợi ý để cá nhân ấy tự hình thành hướng đi cho mình. Đây là một điều rất khó bởi vì người ta thường muốn những điều trừu tượng và xa vời. Ví dụ: "em muốn trở thành một hacker lừng lẫy". Tại sao câu này trừu tượng và xa vời? Bởi vì, chính cá nhân ấy chưa hiểu được thật sự 'hacker' là gì và chưa hình dung được thế nào là 'lừng lẫy', 'lừng lẫy' trong giới hạn nào?. Để có thể xác định được việc bắt đầu từ đâu?, người đặt câu hỏi này nên hết sức cụ thể mục tiêu mình muốn, càng cụ thể càng tốt." 

'cuti' xen vào: 
"Em nghĩ mấy anh em mình nên bàn sâu hơn về chuyện này lúc nào đó tiện vì theo em thì chuyện này rất quan trọng." 

Tôi cười, đáp: 
"Ừa, nếu em thấy nó quan trọng thì mình cũng nên bàn về nó. Anh thật sự không hiểu tại sao vấn đề 'bắt đầu từ đâu' lại nhức nhối đến thế." 

docco hỏi: 
"Vậy hồi xưa anh 'bắt đầu từ đâu' vậy? anh có thể bật mí cho tụi em một tí được không?" 

Tôi đáp: 
"À, hoàn cảnh của anh lúc đó khác với hoàn cảnh mấy đứa bây giờ lắm. Anh cũng chẳng biết phải 'bắt đầu từ đâu', chỉ biết phải kiếm một công việc để làm kiếm sống và vừa làm vừa học. Đến khi học càng nhiều, biết càng nhiều thì tự nhiên đòi hỏi phải tìm công việc thích hợp hơn. Anh đoán hồi đó anh chẳng trằn trọc với chuyện 'bắt đầu từ đâu'. Anh chỉ lao thẳng vào công việc và học hành rồi nó đưa mình từ điểm này sang điểm kia thôi." 

'ccxx' cười, chêm vào: 
"Hì hì, anh nói gì mà lờ mờ vậy? Vậy là anh không muốn bật mí chuyện 'đời cô Lựu' của anh rồi chớ gì. Thôi, tha cho anh đó ). Em muốn hỏi anh tiếp chuyện kỹ thuật, khoái hơn." 

Tôi nén cười, đáp: 
"Ái chà, con gái mà nhậm lẹ vậy mai mốt chắc chắn nắm cổ thằng Hưng đi chơi rồi ). Em muốn hỏi chuyện kỹ thuật gì em?" 

'ccxx' đáp: 
"Hổng dám đâu anh. Ổng coi bộ vậy chớ cộc lắm đó. Đụng vào cục 'cộc' của ổng là phiền. Em muốn hỏi tiếp anh về cái option -O của nmap cho phép đoán footprint của mục tiêu đó anh. Nó làm sao hay vậy?" 

Tôi hỏi thêm: 
"Vậy em đã thử tìm hiểu tí nào về cái option -O chưa vậy?" 

'ccxx' nhanh nhảu: 
"Dạ em download cái source code của nmap về coi nhưng chắc chưa đủ 'nội công' nên nhìn vô thấy tá hoả. Chẳng hiểu gì hết. Em cũng thử search trên mạng thì thấy nói lung tung mà chẳng hiểu đầu đuôi làm sao nữa." 

Tôi đáp: 
"Vậy em thử đọc tài liệu có cái tên là 'Remote OS detection via TCP/IP Stack FingerPrinting' do Fyodor, tác giả của nmap viết chưa em?" 

'ccxx' trả lời: 
"Dạ rồi anh, nhưng đọc chẳng khác gì đọc tiếng Mán, tiếng Mường anh ơi. Có lẽ em phải học thêm rất nhiều về giao thức mạng thì mới mó vào mấy thứ này được (." 

Tôi đáp: 
"Ừa, tổng quát mà nói thì options -O của nmap chỉ là 1 cái flag trên dòng lệnh để ra lệnh nmap thực thi công tác xác định footprint mà thôi. Nếu em muốn biết cơ chế làm việc đằng sau đó thế nào thì cũng không phức tạp lắm đâu. Đại khái nmap có hồ sơ kèm theo chương trình gọi là "nmap-os-fingerprints"; nó chứa trọn bộ các bản mẫu 'dấu ấn' cho từng footprint có thể xác định được. Khi được ra lệnh xác định footprint, nmap sẽ thực thi một loạt thử nghiệm bằng cách 'phun' ra những request packets có tính chất khác nhau. Tuỳ theo kết quả thâu được và dựa trên bản mẫu này, nmap sẽ tường trình footprint đáng tin cậy nhất." 

'ccxx' hồ hởi: 
"Ra vậy. Vậy em có cần học chi tiết giao thức mạng không anh?" 

Tôi trả lời: 
"Hèm... tùy nhu cầu và mục tiêu của em thôi. Nếu em muốn trở thành chuyên gia phân tích gói tin hoặc muốn viết những chương trình chuyên ngành cho công tác này thì chắc chắn em phải cần rồi. Nếu em chỉ cần dùng nmap để xác định footprint cho mục đích thử nghiệm thì biết các nguyên tắc làm việc cũng đã đủ rồi." 

'cuti' chen vào hỏi tiếp: 
"hi hi, vậy anh có nghiên cứu sâu hơn các giao thức mạng không? em nghĩ là có. Vậy em muốn hỏi động lực nào làm anh nghiên cứu sâu hơn?" 

Tôi cười và trả lời 'cuti': 
"Thằng cu này tự hỏi, rồi tự trả lời, rồi dựa trên câu trả lời của mình để hỏi tiếp. Quá sức là ăn gian. Câu trả lời của anh là thế này. Có những thứ anh không có ý định nghiên cứu sâu nhưng vì nhu cầu công việc hoặc vì vô tình mó vào một điểm nào đó rồi bị cuốn vào lúc nào không hay. Có những thứ càng đào sâu càng thấy lý thú, có những thứ càng đào sâu càng thấy vô vị. Cái này tùy cá tính và nhu cầu cá nhân thôi em." 

'cuti' khơi mào: 
"Ví dụ như?" 

Tôi chậc lưỡi: 
"Chậc chậc... có bao nhiêu là ví dụ. Ùm ví dụ như... khách hàng than phiền là họ truy cập vào một web application nào đó mình đang chịu trách nhiêm và thấy chậm quá, mình phải phân tích từ cao xuống thấp, chậm là do băng thông, do application viết dỏm cho nên khi nhiều người truy cập quá thì nó... điếng, hay do database bị cổ chai, đi xuống thấp hơn thì xem I/O trên đĩa có vấn đề gì, hay packets có bị drop vì lý do gì.... Nói chung, đôi khi chỉ vì một lời than phiền của một ông khách "bự" nào đó, bọn anh mất cả tháng để tìm lý do từ kết quả audit, từ phân tích, theo dõi, thử nghiệm.... mỗi phần đều tạo cơ hội cho mình đi sâu xuống để tìm ra nguyên nhân." 

'cuti' cũng chậc lưỡi: 
"Chậc, em cũng không thể hình dung nổi những cái anh vừa nói. Thôi để mai mốt đụng chuyện rồi hẵng hay vậy )" 

'docco' tiếp chuyện: 
"Tựu trung là vì thích hoặc vì nhu cầu công việc mà đào sâu thôi anh nhỉ? Nếu ai đưa mình một đống tài liệu khô khan mà bắt mình... nuốt thì làm sao mà nuốt nổi ). Em muốn hỏi anh một chuyện khác, bọn em toàn dân học ngành tin nhưng học mỗi thứ một chút mà thứ nào cũng cào cào trên mặt. Không biết mai mốt ra đi làm thì làm cái gì nữa. Anh có thể giúp cho em chọn một cái hướng gì cụ thể không anh?" 

'ccxx' kháy: 
"Cái ông này đúng là xí xọn, người ta hỏi chưa xong chuyện nmap mà lại nhảy vô chuyện định hướng tương lai là sao ông? Để tui hỏi tiếp cho xong đã ông ơi." 

Tôi cười xoà và xen vào: 
"Ok, em muốn hỏi tiếp gì vậy cô bé? Duy để bé Như nó hỏi cho xong phần thắc mắc của nó đã em." 

'ccxx' đáp: 
"Dạ em chỉ muốn biết khi dùng nmap với option -O đó thì nó scan khác với tình trạng không có option này như thế nào thôi anh." 

Tôi trả lời: 
"Anh nghĩ cách dễ thấy nhất là thử scan bằng nmap và sniff packets cùng một lúc để xác định thôi em. Code của nmap có phần này nhưng em nói rằng em hơi bị tá hoả thì mình thử sniff là biết ngay thôi, sau này xem lại code cũng không muộn. Cái quan trọng là sniff thế nào để bắt được mỗi đoạn tin nmap gởi đi mà thôi thì mới chính xác." 

'ccxx' than thở: 
"Vậy là phải học thêm cách sniff (. Thôi, anh thử một cái rồi cho em xem đoạn anh sniff thế nào tí đi. Rồi từ từ em sẽ tự ngâm cứu sau. Năn nỉ đó." 

Tôi cười, đáp: 
"Được rồi, đợi anh một tí." 

Thế là tôi khởi động công cụ ưa thích của tôi cho việc sniffing: tcpdump, như sau: 
Code:
tcpdump -i eth1 host 172.17.1.60 and port 7777


Kế tiếp, tôi chạy một dòng nmap trên một console khác như sau: 
Code:
/usr/local/bin/nmap -sS -P0 -O -v 172.17.1.60 -p 7777


Trong tích tắc, tôi tóm được một đoạn thế này và cắt, dán lên khung conference để cô bé 'ccxx' xem: 
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
00:02:50.410083 IP 172.17.1.100.39201 > 172.17.1.60.7777: S 1628065974:1628065974(0) win 4096 <mss 1460>
00:02:50.410408 IP 172.17.1.60.7777 > 172.17.1.100.39201: R 0:0(0) ack 1628065975 win 0
00:02:50.445890 IP 172.17.1.100.39212 > 172.17.1.60.7777: S 3391958263:3391958263(0) win 4096 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:50.446440 IP 172.17.1.60.7777 > 172.17.1.100.39212: R 0:0(0) ack 3391958264 win 0
00:02:50.446673 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 0 win 2048 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:50.447215 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 3391958263:3391958263(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:50.447866 IP 172.17.1.100.39201 > 172.17.1.60.7777: UDP, length 300
00:02:51.369166 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 1 win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:51.369709 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 3391958263:3391958263(0) win 1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:54.062103 IP 172.17.1.100.39212 > 172.17.1.60.7777: S 106725245:106725245(0) win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:54.062516 IP 172.17.1.60.7777 > 172.17.1.100.39212: R 0:0(0) ack 1009734279 win 0
00:02:54.065002 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 1 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:54.067468 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 106725245:106725245(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:54.069372 IP 172.17.1.100.39201 > 172.17.1.60.7777: UDP, length 300
00:02:54.669329 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 1 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:54.669876 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 106725245:106725245(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:57.642391 IP 172.17.1.100.39212 > 172.17.1.60.7777: S 50202835:50202835(0) win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:57.642781 IP 172.17.1.60.7777 > 172.17.1.100.39212: R 0:0(0) ack 953211869 win 0
00:02:57.643252 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 1 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:57.643787 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 50202835:50202835(0) win 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:57.643987 IP 172.17.1.100.39201 > 172.17.1.60.7777: UDP, length 300
00:02:58.381570 IP 172.17.1.100.39213 > 172.17.1.60.7777: . ack 1 win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:02:58.382138 IP 172.17.1.100.39214 > 172.17.1.60.7777: FP 50202835:50202835(0) win 4096 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>


Cả ba đều cảm thán: 
"Ôi.. trời" 
"Như tiếng Mán" 
"Kiểu này tiêu..." 

Tôi chọc quê mấy cô cậu: 
"Hì hì, chứng tỏ là không chịu xem tài liệu về tcp/ip như đã đồng ý với nhau rồi đây hay là chỉ mới thấy, chưa nhìn cho kỹ đã la toáng lên. Đoạn trên khá đơn giản vì anh không sniff trọn bộ payload của packets và chỉ capture sequence mà nmap tạo ra thôi. Này ku Hưng, S flag ở trên là gì em?" 

'cuti' với vẻ giận dỗi: 
"Anh làm như em ngu lắm hông bằng á (, thì S là SYN chớ gì." 

Tôi cười, châm tiếp: 
"Hè hè, anh có nói em ngu hồi nào đâu thằng ku? Anh chỉ gợi ý thôi mà. Nếu em không ngu thì xem thử gói SYN đó do 'ai' gởi và gởi tới 'ai', theo sau là cái gì?" 

Cả ba đều im lặng khá lâu. 'ccxx' lên tiếng: 
"Đây là trọn bộ thông tin từ khi nmap khởi động đến khi nó hoàn tất scanning phải không anh?" 

Tôi đáp: 
"Đúng như vậy dó em, không dư, không thiếu một tí nào hết )." 

'docco' biểu lộ tư duy: 
"Lạ thiệt là lạ. Tại sao nmap lại gởi hàng loạt SYN, rồi tự động gởi ACK một mình nó. Đã vậy còn xen vô mấy cái UDP packets nữa chớ." 

Tôi cười thích thú: 
"Đó, đó. Em trả lời được tại sao thì em đã hiểu được cách làm việc của nmap khi nó muốn đoán footprint. Anh bật mí một tí là nmap không gởi gói tin đi nhiều hơn số lượng nó cần đâu. Mỗi gói tin nó gởi đi đều phục vụ một mục đích rõ ràng và cụ thể." 

'cuti' xen vô: 
"Anh nói thêm nữa đi. Cái vụ đọc và phân tích chi tiết các gói tin ở trên thì để tụi em tự tìm hiểu nhưng điểm anh nói là nmap luôn luôn gởi gói tin đi để phục vụ một mục đích rõ ràng là sao anh?" 

Tôi đáp: 
"Ùm... thế này. Anh nhớ có lần mình bàn sơ qua về việc ứng dụng RFC cho tcp/ip trên mỗi hệ điều hành có một số tương đồng và dị biệt phải không? Nmap dựa vào các điểm tương đồng và dị biệt này để đoán footprint đó. Ví dụ, nó gởi một gói SYN đi, nếu đầu bên kia có dịch vụ đang lắng nghe trên cổng và cho tiếp nối thì hẳn phải có gói SYN trả lời kèm theo ACK. Nếu không, tùy cách ứng dụng của tùy hệ điều hành mà có phản ứng khác nhau. Hơn nữa, nếu mục tiêu scanning của nmap không trả lời thì... nmap bó tay. Tuy nhiên, nếu mục tiêu trả lời thì ít nhiều thông tin mang "foot print" mà nmap có thể thu thập và đoán được. Cũng có thể có trường hợp mục tiêu có trả lời nhưng gói tin trả lời của nó 'tiêu chuẩn' quá, không có gì đặc biệt thì nmap sẽ không đoán nổi footprint của nó là gì hết." 

'cuti' liếng thoáng: 
"Á à, em biết rồi. Theo đoạn trên thì thằng 172.17.1.60 nhả cái R flag ra mỗi lần thằng 172.17.1.100 gởi S đến. Cái này chắc là thằng nmap bó tay rồi vì mấy cú RESET có khỉ gì đâu mà biết footprint phải không anh?" 

Tôi đáp: 
"Khá lắm! Em nói thêm xem lý do tại sao thằng 172.17.1.60 cứ trả lời bằng cú R được không? )" 

'cuti' ngập ngừng rồi đáp: 
"Ùm.... à.... Nếu em hiểu đúng thì một xuất truy cập đã được thiết lập hẳn hòi phải kết thúc đúng quy cách và phải dùng đến FIN chớ không RST ngang xương như thế. Điều đó chứng tỏ thằng 172.17.1.60 có cái firewall cản ở cổng 7777 hoặc trên máy này hoàn toàn không có cổng 7777 đang lắng nghe, phải không anh?" 

Tôi hoan hỉ đáp: 
"Đúng rồi! Vậy có nghĩa là đoạn thông tin của tcpdump ở trên báo cáo tình trạng nmap đến một cổng không mở. Vậy, nếu nmap đến một cổng mở thì sao? Hãy thử xem đoạn này: " 
Code:
# tcpdump -i eth1 host 172.17.1.60 and port 135
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
00:17:26.536870 IP 172.17.1.100.40507 > 172.17.1.60.135: S 257305512:257305512(0) win 3072 <mss 1460>
00:17:26.537402 IP 172.17.1.60.135 > 172.17.1.100.40507: S 2197701964:2197701964(0) ack 257305513 win 17520 <mss 1460>
00:17:26.537709 IP 172.17.1.100.40507 > 172.17.1.60.135: R 257305513:257305513(0) win 0
00:17:26.570448 IP 172.17.1.100.40514 > 172.17.1.60.135: SE 2921059574:2921059574(0) win 2048 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:26.570956 IP 172.17.1.60.135 > 172.17.1.100.40514: S 1807769488:1807769488(0) ack 2921059575 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:26.571178 IP 172.17.1.100.40514 > 172.17.1.60.135: R 2921059575:2921059575(0) win 0
00:17:26.571364 IP 172.17.1.100.40515 > 172.17.1.60.135: . win 2048 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:26.571894 IP 172.17.1.100.40516 > 172.17.1.60.135: SFP 2921059574:2921059574(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:26.572486 IP 172.17.1.100.40517 > 172.17.1.60.135: . ack 0 win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:27.571896 IP 172.17.1.100.40515 > 172.17.1.60.135: . win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:27.572443 IP 172.17.1.100.40516 > 172.17.1.60.135: SFP 2921059574:2921059574(0) win 4096 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:27.572985 IP 172.17.1.100.40517 > 172.17.1.60.135: . ack 1 win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.372001 IP 172.17.1.100.40508 > 172.17.1.60.135: S 2921059575:2921059575(0) win 2048 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.372613 IP 172.17.1.60.135 > 172.17.1.100.40508: S 2733080285:2733080285(0) ack 2921059576 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.372861 IP 172.17.1.100.40508 > 172.17.1.60.135: R 2921059576:2921059576(0) win 0
00:17:28.487967 IP 172.17.1.100.40509 > 172.17.1.60.135: S 2921059576:2921059576(0) win 2048 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.488447 IP 172.17.1.60.135 > 172.17.1.100.40509: S 3276928965:3276928965(0) ack 2921059577 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.488682 IP 172.17.1.100.40509 > 172.17.1.60.135: R 2921059577:2921059577(0) win 0
00:17:28.603969 IP 172.17.1.100.40510 > 172.17.1.60.135: S 2921059577:2921059577(0) win 1024 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.604513 IP 172.17.1.60.135 > 172.17.1.100.40510: S 2813980465:2813980465(0) ack 2921059578 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.604749 IP 172.17.1.100.40510 > 172.17.1.60.135: R 2921059578:2921059578(0) win 0
00:17:28.715967 IP 172.17.1.100.40511 > 172.17.1.60.135: S 2921059578:2921059578(0) win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.716443 IP 172.17.1.60.135 > 172.17.1.100.40511: S 3083838161:3083838161(0) ack 2921059579 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.716681 IP 172.17.1.100.40511 > 172.17.1.60.135: R 2921059579:2921059579(0) win 0
00:17:28.831987 IP 172.17.1.100.40512 > 172.17.1.60.135: S 2921059579:2921059579(0) win 4096 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.832454 IP 172.17.1.60.135 > 172.17.1.100.40512: S 2276644684:2276644684(0) ack 2921059580 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.832689 IP 172.17.1.100.40512 > 172.17.1.60.135: R 2921059580:2921059580(0) win 0
00:17:28.947998 IP 172.17.1.100.40513 > 172.17.1.60.135: S 2921059580:2921059580(0) win 3072 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>
00:17:28.948595 IP 172.17.1.60.135 > 172.17.1.100.40513: S 3388933545:3388933545(0) ack 2921059581 win 16430 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
00:17:28.948837 IP 172.17.1.100.40513 > 172.17.1.60.135: R 2921059581:2921059581(0) win 0


Tôi nói tiếp: 
"Khoan hẵng bàn chi tiết đoạn trên. Để cho mấy đứa khi nào rảnh thì so sánh với đoạn trước và tự tìm hiểu xem lần này có gì khác. Đồng ý hông?" 

'docco' trả lời: 
"Dạ em thấy vậy cũng hay nhưng mà đang hứng chí tử, không bàn thêm cũng uổng, hì hì." 

'ccxx' tham gia: 
"Nãy giờ em ngồi nghĩ ngợi thì thấy những điều mình vừa bàn quả là mở cửa cho cả một thế giới bao la và thú vị. Em không biết mấy ông thích cái trò chui vô máy của người ta để làm gì chớ riêng em, biết được cặn kẽ những điều mình thắc mắc còn lý thú hơn nhiều. Thôi, để tụi em tiếp tục nghiền ngẫm thì mới hay lận." 

Tôi tiếp lời: 
"Suy nghĩ của bé Như chỉnh lắm. Từ chỗ em thắc mắc về cái option -O dẫn đến việc mình thấy nmap gởi các gói tin và nhận các gói tin cho trường hợp cổng đóng và cổng mở để cung cấp kết quả, tuy ngắn ngủi nhưng nó bao hàm một quá trình tìm tòi và thử nghiệm khá dài. Đó là chưa kể trường hợp em điều chỉnh code của nmap để nó gởi gói có kích thước khác thường hoặc có sequence khác thường hoặc có checksum sai hoặc có tổng hợp các TCP flags bất thường để tìm hiểu cách phản ứng của hệ điều hành. Những cái này không phải là những thao tác trực tiếp để "mở cổng chui vô" như những rookie thường muốn biết mà nó đi sâu hơn nhiều. Đến lúc thật sự hiểu đến sự thể, việc "mở cổng chui vô" chẳng còn là điều gì đáng để thích thú nữa bởi vì em nắm được những thứ rộng và sâu hơn nhiều." 

'docco' đáp: 
"Dạ bọn em hiểu ý anh mà )". 

Tôi cười: 
"Thôi há, anh phải dông... nãy giờ ngồi lâu quá rồi. Mấy đứa rảnh thì ngâm kíu thử đoạn ở trên xem có gì vui hông nha?" 

'cuti' kêu lên: 
"Khoan đã anh, cho em thêm một phút nữa." 

Tôi đáp: 
"Gì đó ku?" 

'cuti' hỏi: 
"Em mới vừa rà qua đoạn sniff thứ nhì thì thấy có cái tcp flag gì ngộ ghê. Cái gì mà SE vậy anh? Em thấy có SYN, FIN, ACK, RST, PSH, URG thôi mà? sao bây giờ lòi đâu ra thêm cái SE kỳ vậy?" 

Tôi cười khoái trá và đáp: 
"Ngộ vậy với vui chớ em ). Thử tìm hiểu xem SE là cái gì đi hén? Nếu tìm hông ra thì anh sẽ giải thích sau vậy." 

Tôi nói tiếp: 
"Thôi anh logout đây nhe. Có gì mail cho anh. Bye mấy đứa." 

15/08/2006 
<còn tiếp>