15. tcp/ip info, thật hay giả?:
Mấy ngày qua tôi nhận e-mail dồn dập từ bộ tứ 'cuti', 'ccxx', 'haothu' và 'docco', về những điều các cô cậu tìm thấy trong những lần táy máy. Tôi trả lời bộ tứ một cách tổng quát và sơ sài, đại loại như "tốt lắm, thử thêm một tí nữa đi" hoặc "đã đến mức này, ráng động não một tí đi em"..... Mấy cô cậu bức xúc lắm và nhất định hẹn gặp nhau vào cuối tuần để gỡ rối. Tôi nhận lời sẽ online trên YIM khoảng trưa thứ Bảy.
Như lần trước, bộ tứ đã có mặt sẵn trên YIM và đã tập trung trong một "conference". Tôi tham gia và nhanh chóng đi qua bước chào hỏi.
Lần này 'docco' mở đầu:
"Em có cả đống thắc mắc và em nghĩ những thắc mắc này bọn em đứa nào cũng thắc mắc như nhau. Em khởi đầu nha anh?"
Tôi đáp:
"Tấp bi liền hả? . OK. shoot."
'docco' gõ ngay lên câu hỏi thứ nhất:
"Cả tuần nay em thử mày mò tìm trên Internet xem web server nào chạy những software khác ngoài Apache và IIS, hai cái này thì dễ rồi vì chúng phổ biến quá. Em muốn tìm các web site chạy những thứ khác như iPlanet, Domino, Zeus... mà không tìm ra. Em đoán là còn nhiều loại khác nữa. Anh chỉ dùm em chỗ nào trên Internet có những thông tin này được không?"
Tôi đáp:
"Cái này anh nghĩ đâu khó em? Em chỉ cần dùng google và tìm qua các từ khoá điển hình một tí là có ngay. Anh nghĩ em nên khởi đầu với từ khoá "netcraft" và từ đó mà đi ra ."
Sau một hồi, có lẽ vừa thử xong từ khoá tôi cung cấp, 'docco' cảm thán:
"Đúng là có kinh nghiệm thì lợi đủ điều. Em mò mẫm hoài mà chẳng được cái gì cho rõ ràng. Anh chỉ cho em một từ khoá là thấy có tùm lum thứ để xem rồi."
'ccxx' lên tiếng:
"Trước khi đi sâu vào chuyện tcp/ip, em muốn nêu lên một chuyện. Chuyện này vừa giúp trong việc thăm dò 'footprint' mà vừa chứng minh cho ông Khoa thấy là 'kiddie' khó có khả năng dùng các công cụ cho hiệu quả nếu họ không có đủ kiến thức hoặc không chịu khó."
Tôi cười, trả lời:
"Hì hì, nhất định 'khai chiến' hả em? OK, cứ việc thoải mái."
'ccxx' tiếp tục:
"Không anh, tính em muốn làm cho rõ chuyện thôi. Em có nghe qua về nmap rất nhiều cho nên cũng tải về dùng thử. Tất nhiên là em chọn phiên bản dành cho Windows, có giao diện đồ hình hẳn hòi. Tuy vậy, em mất rất nhiều thời gian để làm quen với nó nhưng vẫn chưa nắm được bao nhiêu. Nếu nmap không phải là một công cụ được xếp loại 'một trong mười công cụ đứng đầu trong bộ đồ nghề security' thì có lẽ em đã vứt nó qua một bên vì quá khó. Công cụ này thích hợp cho dân chuyên mà thôi."
Tôi hỏi:
"Vậy em muốn chứng minh là 'kiddie' không thể dùng nmap đúng tiềm năng của công cụ này?"
'ccxx' đáp:
"Dạ. Em muốn chứng minh là dân lơ tơ mơ như... em thì nhìn vào nmap chỉ có nước... nhìn mà thôi nếu như không chịu khó mày mò."
'haothu' chen vào:
"Nhưng tui thấy trong chuyện này bà Như dùng kinh nghiệm bản thân để đưa ra một cái nhận xét chung cho tất cả các 'kiddie' coi bộ không thoả đáng à nha."
'ccxx' phản hồi:
"Tui chưa chứng minh gì hết mà ông. Để tui đưa ra vài điểm thì ông sẽ thấy thôi."
'ccxx' nói tiếp:
"Khi khởi động chương trình nmap, thứ nhất: nó hoàn toàn sử dụng các thuật ngữ chuyên môn để đặt tên cho các nút bấm, các chi tiết của chương trình. Tui hỏi ông, SYN stealth scan là cái gì? Tôi không dám chắc có 'kiddie' nào hiểu nổi cái gọi là SYN stealth cả đâu. Đó là chưa kể cả đống những thứ khác; nào là Stealth FIN, rồi đến Null Scan, Xmas. Tui ráng tìm hiểu xem thử những cái này là gì nhưng muốn khùng luôn vì cái này liên hệ đến cái kia. Ông thử tìm hiểu xem mấy cái đó là gì và mất bao lâu để nắm được? (nếu như ông không bỏ dở nữa đường)."
'cuti' chêm vào:
"Ừ, mấy cái thuật ngữ kia tuy chỉ là thuật ngữ nhưng nếu mình không hiểu nó là gì, lý do tại sao phải dùng nó thì hơi mệt thiệt."
'haothu' chống chế:
"Thì dùng cái gì lại không tìm hiểu tính năng của nó bà Như? Tui đoán 'kiddie' (như tui chẳng hạn) chỉ cần theo tài liệu có sẵn mà gõ thôi. Nếu cái này không được thì thử cái khác. Vấn đề ở chỗ là nó mang lại cho mình kết quả gì."
'ccxx' chộp ngay câu này để tấn công:
"Đó đó, ông nói câu này chỉ chẳng khác gì chấp nhận là 'kiddie' chỉ nhắm mắt gõ lệnh mà không cần suy nghĩ. Nếu vậy thì ông vô tình đồng ý với quan điểm của tui rồi. Tui nghĩ để dùng một công cụ như nmap mình phải hiểu rất rõ về tcp/ip, phải nắm rõ mỗi chọn lựa công cụ này cung cấp làm việc ra sao để có thể ứng dụng một cách thích đáng cho mỗi trường hợp. Nếu ông dùng nmap để scan một host nào đó và nó đã hoàn toàn cản các gói ICMP, không cho ping, ông có thể ngộ nhận là host ấy không tồn tại hoặc offline nếu như ông không dùng -P0. Cái GUI cho nmap thật ra chỉ là một phương tiện cho những ai làm biếng gõ lệnh mà thôi nhưng để dùng thật sự thì phải hiểu các chọn lựa, phối hợp để đạt được kết quả."
Tôi cười, đáp:
"Hay lắm. Tiếp tục đi em "
'haothu' cảm thán:
"Ái chà, không ngờ bà rành nmap đến như vậy. Cãi với bà thì chắc tui không lại rồi đó nhưng tui vẫn tin rằng một công cụ được tạo nên là để phục vụ người dùng thì không có lý gì người dùng phải nắm tất cả những chi tiết kỹ thuật bên trong chương trình này thì mới dùng được. Ngoại trừ người dùng muốn đạt mức độ chuyên về lãnh vực này."
'ccxx' phản bác:
"Ui... ông nói nghe mắc cười quá. Tất nhiên là công cụ được tạo ra để phục vụ người dùng nhưng người dùng phải học cách sử dụng nó chớ? Công cụ càng đa năng, người dùng cần mất nhiều thời gian để làm quen với nó. Cái xẻng cũng là công cụ, chiếc xe xúc cũng là công cụ, ông nghĩ rằng học cách dùng xẻng và học cách điều khiển chiếc xe xúc đòi hỏi công sức như nhau à? Điểm ông đưa ra chính là điểm để biện bác cho lối suy nghĩ của 'kiddie' vì 'kiddie' chẳng cần biết đến cái tinh tế và khả năng sâu xa của một công cụ mà chỉ cần biết nhắm mắt mà nhấn nút thôi. Tui nói sai chỗ nào đâu à?"
Tôi xen vào can gián:
"Thôi thôi, anh thấy bé Như nhà mình nói và bảo vệ quan điểm của mình rất vững vàng. Cu Khoa thua 1-0 rồi đó nha. Rồi, Duy muốn tiếp tục không em?"
'docco' lên tiếng:
"Dạ, tiếp tục thì có biết bao nhiêu chuyện tiếp tục hở anh? Hay là mình tiếp tục với chuyện tìm footprint từ tcp/ip đi anh? Làm sao mình biết được những thông tin này từ tcp/ip?"
Tôi đáp:
"Khi nói đến việc tìm footprint xuyên qua tcp/ip thì có nghĩa là mình phải nắm vững về tcp/ip và các ứng dụng đặc thù trên từng hệ điều hành. Các RFC đưa ra các tiêu chuẩn của mỗi giao thức, tuy nhiên RFC có những điểm không cụ thể cho nên các nhóm ứng dụng cho các hệ điều hành đọc, hiểu và ứng dụng chúng khác nhau. Bởi thế mới có những tiểu tiết khác nhau giúp cho mình có thể nhận diện được footprint xuyên qua tcp/ip. Tuy vậy, mình nên nhớ rằng, bất cứ thông tin nào thu thập được cũng mang tính tương đối mà thôi. Cũng như phần trước mình đã bàn, càng thu thập được nhiều dữ kiện, càng có thể xác định chính xác mục tiêu của mình."
'cuti' chen vào:
"Lỡ may em chưa rành tcp/ip thì liệu em có hiểu nổi không anh?"
Tôi trả lời:
"Anh tin là em vẫn hiểu được trên mặt nguyên tắc. Tuy nhiên, muốn đi sâu vào thì có thể sẽ có những chướng ngại nếu chưa rành tcp/ip. Ví dụ, em hiểu thế nào là TTL?"
'cuti' ậm ừ:
"Ùm.... èm.... xí mê, xí mê, để em nghía cuốn sách một tí đã? "
Tôi phá lên cười:
"Ai làm gì mà xí mê, xê mí... ghê vậy? Em muốn coi mấy thì coi, anh chỉ hỏi bất chợt một câu vậy thôi mà."
'cuti' hớn hở:
"Tìm ra rồi, TTL là 'Time To Live'. May mà mấy cái e-book này cho search chớ không thì dò biết chừng nào cho ra trời? Anh hỏi nữa đi? Em chắc thế nào cũng tìm ra được thôi."
Tôi đáp:
"Hì hì, mình đà khía hay mình đang trắc nghiệm đây em? Mà thi oral kiểu này thì ăn gian quá, có sẵn cái e-book trước măt để xem và trả lời. Anh mách cho một kế thế này. Khi em muốn nắm về tcp/ip, em nên nghiên cứu một bức đồ hoạ về ip header, tcp header, udp header.... và xem kỹ các fields và chức năng của chúng. Xong được cái này là em đã nắm ít nhất 50% về giao thức này rồi. Nếu không nắm được những chi tiết và giá trị bên trong một header thì đọc mãi đống chữ trong sách cũng chẳng thu nhập được bao nhiêu đâu em."
'docco' gật gù:
"Có lý. Trước giờ em cứ đọc đi đọc lại nhưng ít để tâm đến mấy cái đồ hình về header của giao thức. Em phải xem lại mới được."
Đến lượt 'haothu' lên tiếng:
"Nhưng mà hồi nãy anh nhắc đến TTL có mục đích gì cụ thể cho việc phát hiện footprint không anh? Hay chỉ là một câu hỏi chung chung thôi?"
Tôi đáp:
"À... thật ra cái TTL cũng tiết lộ ít nhiều thông tin đó em. Thử mở một cái command prompt lên và gõ:
Code:
C:\>ping localhost
hay
Code:
C:\>ping 127.0.0.1
xem thử nó báo cái gì đi em?
Bộ tứ im lặng chừng một phút, sau đó 'ccxx' lên tiếng trước:
"A.... hoá ra là cái TTL là vậy. Khi em thử ping, trên máy em nó báo 4 lần TTL=128. Trước giờ em chẳng bao giờ để ý đến nó."
Tôi cười, hỏi qua 'cuti':
"Con Linux của em có sẵn đó không em?"
'cuti' đáp liền:
"Dạ có đây anh? Để chi vậy anh?"
Tôi đáp:
"Em thử mở một cái console và gõ:
Code:
$ ping -c 4 localhost
xem thử nó báo cái gì?
'cuti' trả lời ngay sau đó:
"Độc thiệt là độc, nó báo TTL là 64. Em biết ý anh rồi. Phải ý anh là mỗi hệ điều hành ấn định một TTL khác nhau và từ đó mình có thể đoán được footprint không anh?"
Tôi đáp:
"Đúng là như vậy . Em thông minh lắm."
'cuti' hớn hở:
"Chà, lâu lâu được khen một câu thấy phẻ ra. Nhưng mà em thắc mắc là mình đâu có vào console của một máy nào đó để chạy lệnh được để mà biết nó có TTL là gì anh? mà đã vào được để chạy lệnh ping thì cần gì phải nhìn đến TTL mà xác định footprint nữa anh?"
Tôi thong thả trả lời:
"Bọn em nghĩ sao với câu hỏi của 'cuti'?"
'haothu' đáp:
"Chắc đây là chuyện có liên quan đến việc anh muốn bọn em ngâm cứu kỹ về tcp/ip đây rồi."
'docco' lên tiếng:
"Nếu em hiểu không sai thì gói tin nào cũng có mang theo giá trị TTL cả phải không anh? Vậy bằng cách bắt lấy một đoạn tin thì mình thấy được giá trị TTL của mục tiêu ngay."
Tôi đáp:
"Excellent! Em nhận định rất đúng. Vậy, TTL field nằm ở đâu, tầng nào trong mô hình tcp/ip?"
'cuti' nhanh nhảu trả lời:
"Có đây, có đây, IP layer phải hông anh? . Hì hì, có cái cẩm nang nằm ngay đây công nhận sướng thiệt."
'ccxx' nhạo:
"Chơi ăn gian vậy mà còn làm như hay lắm. Đừng xem sách coi thử có lẹ như thế không mới hay."
'docco' nói tiếp:
"Em vừa thử sniff vài thứ bằng Ethereal để xem kết quả ra sao thì thấy có tùm lum thứ, làm sao mình biết cái nào mình cần sniff và cần xem đây anh?"
Tôi đáp:
"Câu hỏi này chỉ có một câu trả lời duy nhất là em phải rành Ethereal hoặc bất cứ công cụ nào đó dùng để sniff. Em có thể giới hạn loại traffic nào cần sniff, ví dụ sniff giao thức nào, cổng nào... Anh khó có thể nói chi tiết, em nên tham khảo tài liệu đi kèm với công cụ em muốn dùng để biết cách sử dụng. Nếu em dùng Ethereal thì phần 'Help' của nó có chỉ dẫn rất rõ ràng. Nói về mặt kỹ thuật, để xác định được TTL của máy từ xa em phải tìm cách tương tác đến nó. Ví dụ, máy chủ em muốn thăm dò có dịch vụ web chẳng hạn; em thử dùng trình duyệt để duyệt trang web ấy đồng thời sniff các gói tin trên cổng 80. Từ kết quả sniff được, chắc chắn em có thể xác định được TTL.
Điều cần nói thêm ở đây là TTL em lấy được không phải của chính máy chủ ấy. Cho nên, ngoài việc thu thập giá trị TTL, em còn phải xác định thêm các thông tin khác để xác thực kết quả. Chi tiết thế nào mình bàn sau."
'docco' trả lời:
"A... vậy mà em không xem phần help của Ethereal. Để em xem lại cẩn thận."
Tôi đáp:
"Ừa, cũng như 'ccxx' nói lúc nãy: "công cụ càng đa năng, người dùng cần mất nhiều thời gian để làm quen với nó". Muốn đạt được kết quả, không những em phải vận dụng một cách thành thạo một hoặc nhiều công cụ mà đôi khi em còn phải phối hợp chúng lại. Anh không đi vào quá chi tiết kẻo em lại 'lùng bùng' nhưng trên nguyên tắc mà nói, em đã biết:
- TTL cho mỗi hệ điều hành thường khác nhau
- TTL nằm trên IP header
- muốn lấy được TTL của mục tiêu phải 'tương tác' đến hệ thống mình muốn thăm dò.
- giá trị TTL sniff được không phải lúc nào cũng là TTL của máy chủ mình muốn lấy.
Từ các điểm ở trên, em có thể hình thành một phương pháp thăm dò dựa trên công cụ mình có."
'docco' cười, đáp:
"Hì hì, em hiểu rồi. Hồi nãy anh có đề cập đến việc 'xác định thêm các thông tin khác' là sao anh? Chắc là thông tin của những fields khác trên IP header hay TCP header nữa phải không anh?"
Tôi trả lời:
"Ừa, và hơn thế nữa."
'cuti' xen vào hỏi:
"Em đang ở trên con Linux, anh có cái lệnh gì để sniff cho lẹ không anh? Em muốn xem thử ra sao."
Tôi đáp:
"Trên Linux thì có lẽ có sẵn tcpdump. Tuy nhiên dùng công cụ này hơi khó và để "đọc" được thông tin mớ tin mà tcpdump bắt được, em cần một công cụ khác như Ethereal hoặc Snort để đọc. Cách dễ nhất là chạy lệnh:
Code:
# tcpdump -s0 port 80 -w abc
trong khi thử duyệt một website nào đó. Sao đó ngưng tcpdump (gõ Ctl-C) và copy file abc kia sang máy nào có Ethereal mà mở ra xem. Chú trọng vào thông tin trên tầng IP."
'cuti' đáp:
"Chà, hoá ra cũng phức tạp quá vậy? Để em thử cái xem."
Vài phút im lặng trôi qua. Dường như bộ tứ để tâm vào chuyện "thử" hoặc đang đợi xem 'cuti' công bố kết quả tìm thấy. 'cuti' phá vỡ sự im lặng:
"À há, em tìm ra rồi. Em sniff được một đoạn thông tin y như cái lệnh anh cho ở trên và mang sang con Win của em có Ethereal. Bây giờ thì thấy lồ lộ giá trị "Time To Live" của website em muốn tìm là 44. Nhưng TTL có giá trị là 44 thì nó là hệ điều hành nào anh?"
[i]Tôi trả lời:
"Hồi nãy mình đã thông qua là TTL em sniff được không phải là TTL thực sự của máy chủ kia rồi mà? Nếu em lấy con số này và cho rằng nó chính là TTL của máy chủ em cần dò tìm là thiếu mất.... một đoạn rồi đó. Cái TTL mà em thấy được đó là TTL sau khi gói tin này đi xuyên qua bao nhiêu 'hops' trước khi về tới máy của em. Bởi vậy, TTL này phải cộng thêm số hops đi từ máy chủ đến máy em thì mới ra TTL thật sự của máy chủ "
docco thốt lên:
"Mèn.. mấy cái này anh không nói thì tụi em ăn quả hết ráo."
Tôi cười đáp:
"Bởi vậy anh mới nói là mấy đứa nên nắm vững tcp/ip thì mới mó tay vào mấy thứ này được. Vả lại những điểm này cũng đi ra từ suy luận mà thôi. Nếu hiểu rõ TTL là gì, TTL đi và TTL nhận là thế nào thì tự nhiên sẽ thấy rõ mồn một."
'cuti' lại lên tiếng:
"Em vừa thử duyệt cái trang web đang chạy trên con Linux, vừa sniff traffic và thấy rằng TTL của nó là 64. Em ping nó, nó cũng cho biết TTL là 64. Vậy là sao anh? Hồi nãy anh nói là TTL mình sniff được không phải lúc nào cũng là TTL thật sự của máy chủ mình muốn thăm dò mà?"
Tôi trả lời:
"À, một câu hỏi lý thú đó . Sao em không thử tự hỏi tạo sao TTL trong trường hợp này chẳng hề thay đổi?"
"cuti" rên rỉ:
"Hic, anh làm em thấy... nản rồi đó. Sao mà càng ngày càng tùm lum thứ hết vậy trời "
Tôi im lặng vài giây rồi đáp:
"Nản thật sao em? Những thứ mình đang bàn ở đây chỉ là nguyên tắc mà thôi. Nếu mình thực sự đi vào từng điểm kỹ thuật có lẽ em... chịu không nổi đâu."
'cuti' chống chế:
"Nhưng... mỗi lần gặp anh là có thêm một mớ chuyện để tìm tòi, tra cứu. Mớ trước chưa xong thì mớ sau ập đến thì làm sao lãnh hội kịp được anh? Em thấy nản là vì để nắm C thì phải hiểu A và B, chưa nắm xong C thì đã có thêm D, E, F để nghiền ngẫm cho nên đến lúc mình chạm đến G, H thì coi như em mù."
Tôi đáp:
"Em nên hiểu rằng những gì mình bàn ở đây là cái khung mà thôi. Mình không thể đi sâu vào từng chi tiết bởi vì không thể tìm đâu ra thời gian cả. Ví dụ mình bàn chủ để footprint chẳng hạn, mình chỉ có thể tạo cái khung cho những gì liên quan đến footprint. Còn mọi chi tiết kỹ thuật ai cũng phải đọc, suy gẫm và rút tỉa cả thôi em. Nói tóm lại, em cần thời gian, chuyên tâm và kiên nhẫn để thu gặt kiến thức."
'haothu' xen vào:
"Em thấy khúc mắc của Hưng khá dễ hiểu. Có lẽ Hưng bị hoảng vì phải tiếp nhận dồn dập nhiều thông tin quá mà thôi. Em cũng cảm thấy như vậy."
'docco' tham gia:
"Em thì thấy rằng những điều anh nhấn mạnh từ đầu về giềng mối có lý do quá hiển nhiên. Cũng như Hưng, em cũng bị choáng nhưng em ghi chú rồi về xem kỹ lại sau. Em thấy chẳng có gì để nản cả."
'docco' cố dẫn câu chuyện về hướng khác nên nói tiếp:
"Mình vẫn còn bàn về TTL, anh có thể 'đào xới' thêm về cái TTL một tí được không anh?"
Tôi trả lời:
"Hèm... TTL.. ok. Cứ hiểu nôm na là mỗi khi gói tin đi qua một router, TTL nguyên thủy (lúc gói tin tạo ra) sẽ bị trừ đi 1. Chi tiết thế nào thì em nên xem lại cuốn tcp/ip illustrated của Richard Stevens, quyển này dành riêng mấy trang nói rất kỹ về TTL. Khi mình đã nắm được nguyên tắc: qua 1 router, TTL trừ 1 thì mình có thể suy luận và hình dung ra được ngay gói tin 'cuti' sniff được ở trên có TTL với giá trị đã được trừ 1 nhiều lần bởi vì nó phải đi qua nhiều router trước khi về đến máy của 'cuti'. Phải không nào?"
'docco' đáp:
"Dạ phải."
'cuti' xen vào:
"A, hèn chi em ping và sniff con Linux server trên cùng một network nên TTL không thay đổi vì nó chẳng qua 'hop' nào cả. Ái chà, kiểu này phải đọc và nhồi thêm rồi."
Tôi hỏi tới:
"Nếu thế thì để xác định một cách tương đối TTL của gói tin mà 'cuti' sniff được để từ đó đoán ra hệ điều hành của nó là gì thì mình cần làm sao đây?"
'ccxx' nhanh nhảu:
"Em nghĩ là mình phải làm sao tính được có bao nhiêu lần gói tin đó bị TTL trừ 1. Sau đó lấy số lần bị trừ một đó cộng với giá trị TTL của ông Hưng tìm thấy hẳn phải là TTL nguyên thuỷ."
Tôi cười, đáp:
"Bravo! thấy chưa? Chuyện đơn giản thế mà chóng thấy nản thì hơi uổng "
Tôi hỏi thêm:
"Thế thì làm sao mình xác định được bao nhiêu lần gói tin ấy bị TTL - 1 nhỉ? Có ai có ý kiến gì không?"
'cuti' rụt rè:
"Èm.... tracert phải không anh?"
Tôi cười, trả lời:
"Đúng rồi đó em. Tuy nhiên, tracert là chương trình để 'trace route' trên Windows. Chính xác là dùng 'trace route' để xác định có bao nhiêu hops đi từ máy mình đến máy mình thăm dò. Nên nhớ, đường gói tin đi (route) từ máy mình đến máy mình thăm dò thường khác đường gói tin đi từ máy mình thăm dò đến máy của mình đó nha. Cho nên, giá trị hops tìm ra được bằng traceroute từ máy mình cộng với TTL tìm được từ gói tin chỉ mang tính tương đối."
'ccxx' thắc mắc:
"Sao vẫn chỉ là tương đối vậy anh? Tạo sao các hops đi từ máy A đến máy B có thể khác từ máy B đến máy A?"
Tôi đáp:
"À, điều này phụ thuộc vào router và các thuật toán của chúng mà gói tin phải đi qua. Bởi thế, gói tin đi từ A đến B có thể đi xuyên các route ngắn hơn. Trong khi đó gói tin đi từ B đến A có thể lại dài hơn. Với điều kiện lý tưởng, độ sai biệt có thể chỉ nằm trong vòng vài hops. Tuy nhiên, trên thực tế có nhiều yếu tố chủ quan và khách quan khiến cho đường đi ngược và đường đi xuôi khác biệt nhau."
'haothu' lên tiếng:
"Nếu vậy thì dùng TTL để xác định OS quả là mong manh."
Tôi cười, đáp lời 'haothu':
"Chính vì vậy, kỹ thuật thăm dò đòi hỏi hàng loạt kỹ thuật và khả năng kết hợp, đúc kết, đối chiếu thông tin lấy được. Đó là chưa kể đến trường hợp admin nào đó quyết định thay đổi TTL của server vì lý do nào đó thì kết quả thu thập được lại càng... mong manh hơn."
'cuti' thốt:
"Ui trời... nếu vậy thì bao nhiêu cố gắng tìm TTL, chạy tracert hoá ra vô ích sao anh?"
Tôi đáp:
"Hì hì, em muốn... tuyệt vọng hơn không? Đó là anh chưa kể trường hợp một host nào đó mình muốn thăm dò thật ra nằm đằng sau một (hoặc nhiều) reverse proxy server. Reverse proxy server này thay mặt server "thật" để trả lời request từ bên ngoài. Cho nên, TTL này có thể là TTL của reverse proxy server không chừng? "
'cuti' rú lên:
"Anh lừa em, anh lừa em... anh dẫn dụ toàn là những thứ nặng đô xong rồi lại đưa đến chỗ kết luận là chúng vô ích. Hèm... vậy mà em ráng dỏng tai lên nghe nãy giờ "
Tôi cười thích thú:
"Hà hà, vậy là em tuyệt vọng thật sự rồi hả? Thế này, không có kiến thức nào phí cả. Mục đích tận cùng cho việc nghiên cứu tcp/ip, TTL hay cái gì đó là để trang bị cho mình lớp kiến thức quan trọng. Sau này, khi em làm network admin, security specialist hay ngay cả lập trình viên có dính líu đến mạng, thì mới kiến thức này quý hơn... vàng. Những điều mình bàn ở đây là con đường đi ra khỏi cái cõi 'kiddie' để trở thành một người có kiến thức thật sự và có thể ứng dụng kiến thức đó."
conference room bao trùm trong sự im lặng. Hồi lâu, 'docco' lên tiếng:
"Dạ, em hiểu ý anh rồi. Em chỉ muốn đào xới thêm một tí nữa, được không anh?"
Tôi cười, đáp:
"Tất nhiên là được. Em muốn... đào cái gì đây?"
'docco' nói tiếp:
"Vậy với tcp/ip, mình còn có thể dựa trên những chi tiết nào khác để xác định footprint không anh?"
Tôi trả lời:
"Tất nhiên là có. Như anh đã nói trước đây, các RFC được lập ra nhưng bỏ ngỏ nhiều chi tiết. Bởi thế, các nhóm phát triển cứ diễn dịch và ứng dụng theo ý họ. Từ đó mới nảy ra những dị biệt. Ví dụ, nếu tham khảo RFC 793 thì thấy rằng khi một host nhận được gói tin mang flag là FIN trơ trụi thì không trả lời gói tin này vì nó chẳng ăn nhập vào đâu cả. Gói tin FIN phải kèm theo ACK để 'acknowlege' xuất truy cập kết thúc. Tuy vậy, nhiều hệ điều hành ứng dụng không đúng RFC 793 nên mới có trường hợp FIN gởi đi, RST từ host ấy gởi về. Hệ điều hành phổ biến như Microsoft Windows cũng dính vào dạng này. Ngoài ra các ứng dụng trên HP/UX, IRIX và ngay cả Cisco cũng không phải là ngoại lệ. Bởi vậy, dùng một công cụ tạo ra một gói FIN đơn lẻ đến 1 host và nhận được gói RST trả lời thì em có thể đoán được một trong những hệ điều hành như trên đang trả lời."
'docco' thích thú:
"À, không ngờ có những chuyện lý thú đến như vậy. Nhưng làm sao mình nắm được hết các hệ điều hành nào có thái độ như thế nào anh? Và cho dù có nhận được gói RST trả lời, mình cũng không thể xác định chính xác hệ điều hành đó là gì mà?"
Tôi đáp:
"Đúng như vậy em. Để xác định OS footprint một cách chính xác, mình không thể dựa vào một thông tin đơn lẻ nào mà phải tổng hợp nhiều thông tin thâu lượm được. Bởi vậy, các công cụ được viết sẵn để detect footprint thường thi hành một loạt thăm dò và so sánh với kết quả đã có sẵn trong database của nó. Ngay cả như thế, không có công cụ nào có thể tuyệt đối xác định được footprint cả."
'docco' cảm thán:
"Chà, vụ detect footprint dùng tcp/ip xem ra cũng căng chớ chẳng dễ dàng gì. Vậy có công cụ nào tự động rà tìm và cung cấp cho mình thông tin về footprint của một máy chủ nào đó không anh?"
'ccxx' nhanh nhảu chen vào:
"Có đó chứ, nmap đó. Nó có thể thực hiện chuyện này nhưng tui chưa rành nó lắm vì chưa táy máy nhiều."
Tôi tiếp lời:
"Công cụ dùng để detect OS footprint thì có khá nhiều. Trước đây thì có checkos, queso, sau này có nmap và một số công cụ thương mại. Tựu trung, chúng làm việc trên cùng nguyên tắc, chỉ khác nhau tiến trình và độ tỉ mỉ trong khi thực thi công tác rà tìm. Theo anh, nmap là một công cụ mạnh nhất vì dường như nó mang lại kết quả trung thực nhất."
'haothu' hỏi:
"Vậy sao mình không dùng luôn cái nmap để tìm footprint cho khoẻ anh? Mình thăm dò bằng tay như nãy giờ mấy anh em mình bàn vừa chậm lại vừa thiếu chính xác."
Tôi cười, đáp:
"Anh nghĩ không riêng gì em mà mấy đứa kia cũng suy nghĩ như em vậy. Anh cũng đồng ý với ý kiến của em. Tuy nhiên, điều quan trọng của việc thăm dò bằng tay là nó mang lại cho em 'in-depth knowledge'. Em sẽ hiểu sâu, hiểu tường tận khi nhúng tay vào cõi này. Khả năng kết hợp công cụ để táy máy với tcp/ip stack không chỉ dừng lại cho mục đích thăm dò mà còn đi xa hơn rất nhiều. Nó sẽ giúp em thâm nhập hoặc bảo mật tùy chọn. Cái này cũng giống như người lái xe hiểu rõ chiếc xe vận động ra sao, có những thiết bị nào thay vì chỉ đơn thuần lái xe. Nếu xe bị hỏng hóc, hoặc nếu em muốn điều chỉnh chiếc xe theo ý thì em bó tay. Sau này, khi em chịu trách nhiệm quản lý một chuỗi server và em không muốn bị rà tìm footprint bằng các công cụ như nmap chẳng hạn, em phải hiểu rõ cách nmap làm việc để đánh lừa nó nếu em muốn ứng dụng một ít 'security from obscurity' "
'docco' gật gù:
"Ái chà, em chưa nghĩ tới cỡ phải hiểu rõ nmap để đánh lừa nmap. Như anh nói lần trước, 'security from obscurity' chỉ là một lớp vỏ bên ngoài, vậy thì việc gì mình phải mất thời gian với nó để dấu footprint với nmap scan hở anh?"
Tôi đáp:
"Hì hì, cu Duy tinh tế quá. Thế này, defeat nmap chỉ là một ví dụ, một trường hợp. Để kiện toàn bảo mật, nếu muốn nhìn từ phương diện này, em phải hiểu các dạng rà tìm, tấn công, các công cụ thường dùng cho mục đích này để phòng chống. Khái niệm 'hiểu' này không chỉ gói gọn trong khuôn khổ defeating nmap hay một công cụ riêng biệt nào cả. Anh ví dụ có một công cụ tự động hoá dùng để tạo các http header cực lớn nhằm mục đích làm treo web service chẳng hạn. Có ít nhất hai hướng nhìn để defeat dạng tấn công này.
- Hướng 'đụng đâu chữa đấy' là hướng đợi server bị treo rồi mới phân tích log và tìm thấy nguyên nhân rồi mới đi đến chỗ sửa chữa nó.
- Hướng 'phỏng định trước' là hướng nghiên cứu các trường hợp có thể xảy ra, tìm các loại công cụ tạo các dạng tấn công như thế đề phòng chống.
Khi nhìn vào một cái perl script được công bố trên các website chuyên bảo mật, đọc xuyên qua em có thể hình dung là các web service có thể bị 'yếu' ở những điểm nào. Từ suy luận, em có thể đi đến giải pháp sau đó. Ý anh là dựa vào cách thức tấn công của các công cụ có sẵn và hình thành cách phòng chống những dạng tấn công tương tự. Điều này có nghĩa: em phải hiểu cách làm việc của công cụ ấy."
'docco' trả lời:
"Èm... em thấy xa vời quá. Có lẽ bọn em chưa đủ 'đô' để nghĩ đến những chuyện này đâu anh. Hy vọng một ngày nào đó bọn em sẽ thấy hữu lý . Với lại em thấy có bug track và các cty, các nhóm phát triển cung cấp bản vá rồi mà anh? Nếu mình đào sâu quá thì lấy đâu ra thời gian?"
Tôi cười, đáp lời 'docco':
"Ừa, em suy nghĩ thế cũng có cái lý của nó. Tuy vậy, nếu mình muốn làm việc và suy nghĩ như một 'hacker' thì mình không thể ỷ lại như một 'user'. Có thể em không đụng hết mọi thứ, có thể em chỉ chuyên một thứ nào đó và em đóng góp những điều em tìm thấy từ lãnh vực em chuyên."
'haothu' hỏi tiếp:
"À quên chứ, anh có tài liệu nào liệt kê các TTL tiêu chuẩn của từng hệ điều hành không anh? Em muốn tham khảo thêm xem sao."
Tôi cười phá lên rồi trả lời:
"Hì hì, em muốn quay lại cái TTL để táy máy hả? Tốt lắm. Anh có nhớ là đã lưu một bản TTL tiêu chuẩn anh tìm thấy trên Web, để anh tìm cái xem."
Sau vài phút lục lọi, tôi paste đoạn TTL mà tôi tìm được:
"Đây em, tha hồ mà tham khảo"
Code:
OS VER PLATFORM TTL WINDOW DF TOS
DC-OSx 1.1-95 Pyramid/NILE 30 8192 n 0
Windows 9x/NT Intel 32 5000-9000 y 0
AIX 4.3.x IBM/RS 60 006016000-16100 y 0
AIX 4.2.x IBM/RS 60 006016000-16100 n 0
Cisco 11.2 7507 60 65535 y 0
DigitalUnix 4.0 Alpha 60 33580 y 16
IRI X6.x SGI 60 61320 y 16
OS390 2.6 IBM/S390 60 32756 n 0
Reliant 5.43 Pyramid/RM1000 60 65534 n 0
FreeBSD 3.x Intel 64 17520 y 16
Linux 2.2.x Intel 64 32120 y 0
OpenBSD 2.x Intel 64 17520 n 16
OS/400 R4.4 AS/400 64 8192 y 0
SCO R5 Compaq 64 24820 n 0
Solaris 8 Intel/Sparc 64 24820 y 0
FTX(UNIX) 3.3 STRATUS 64 32768 n 0
Unisys x Mainframe 64 32768 n 0
Netware 4.11 Intel 128 32000-32768 y 0
Windows 9x/NT Intel 128 5000-9000 y 0
Windows 2000 Intel 128 17000-18000 y 0
Cisco 12.0 2514 255 3800-5000 n 192
Solaris 2.x Intel/Sparc 255 8760 y 0
"Thông tin này đã hơi cũ rồi nhưng có phần lớn vẫn còn giá trị. Thử 'ngâm kíu' xem sao."
'cuti' tắc lưỡi:
"Chậc.... có những OS em chưa hề nghe qua luôn, đừng nói chi là có để mà thử . Còn mấy cái cột WINDOW, DF và TOS để làm gì vậy anh?"
Tôi đáp:
"À, WINDOW là window size của packet, DF là viết tắc của "don't fragment" và TOS là viết tắc của "type of service". Em xem trong cuốn 'cẩm nang' tcp/ip của Richards thì sẽ rõ chúng là gì, có vai trò gì. 3 giá trị WINDOW, DF và TOS cũng là các giá trị đặc thù trong việc ứng dụng tcp stack trên mỗi hệ điều hành. Bởi vậy, có thể dùng các giá trị này để phần nào xác định footprint."
'haothu' tham gia:
"Em cũng chưa hề nghe qua tên của một số hệ điều hành trên danh sách này. Chắc điều kiện ở VN thì có lẽ khó lòng mà tiếp cận được nhưng cái chính là để mình tham khảo cho một số hệ điều hành mình có thể mó tay vào. Nhưng mà làm sao thu thập được các thông tin ở trên hở anh? Chẳng lẽ muốn biết thì phải cài hết các hệ điều hành đó mà vọc sao?"
Tôi trả lời:
"Không em. Thông thường một project như nmap khởi đầu chỉ nhỏ thôi và nó cũng thừa hưởng khá nhiều từ những công cụ đi trước. Họ tạo một database để mọi người đóng góp các footprint đã được tìm thấy. Mỗi người một ít, lâu dần nó đồ sộ và bao gồm rất nhiều thông tin. Chẳng có ai có thể tự tạo ra mọi thứ được đâu em ."
'haothu' đáp:
"À, ra vậy."
'ccxx' lên tiếng:
"Em thấy nmap có option -O để đoán OS của máy mình muốn thăm dò. Thật sự nó làm việc thế nào vậy anh?"
'docco' xen vào:
"Em thì khoái tìm cách khắc chế mấy cái rà quét như nmap mà thôi. Em nghĩ trước mắt mình chỉ cần thừa hưởng những điều đã được hình thành cũng đã đủ vỡ cả đầu rồi."
Tôi đáp:
"Ý kiến của ccxx và docco đều hữu lý cả. Có lẽ mấy anh em mình bàn đến chuyện này sau hả? Mình ngồi 'ngâm' thế này đã khá lâu. Anh phải dọt. Lần này mình bàn khá nhiều vấn đề đó, cho nên mấy đứa chịu khó xem lại và kiểm chứng, thử nghiệm sơ sơ để nắm hả? Chào mấy đứa."
Bộ bốn đáp:
"Chào anh."
Tôi logoff
10/01/2006
<còn tiếp>
Những cuộc đối thoại với rookie - Phần 12
4/
5
Oleh
Unknown
