1. Mở đầu: 
Tôi không nhớ rõ bao nhiêu lần tôi nhận được thông điệp với dạng "Anh chỉ cho em cách hack với". Những thông điệp này đến từ e-mail, offline message của Yahoo, personal message trên diễn đàn..v..v.. Điều lý thú là những người gởi thông điệp này có khả năng và kinh nghiệm về CNTT ở mức độ khác nhau (sau khi tôi thử tìm hiểu và tiếp xúc để biết được điều này). Lý do tại sao những câu hỏi như trên được đặt ra quá nhiều? Họ hiểu thế nào là "hack"? Họ muốn "hack" để làm gì? Họ tìm tòi những gì về "hack"? Lúc bắt đầu tiếp cận với các câu hỏi thế này, tôi cố gắng giải thích ít nhiều (trong phạm vi cho phép) nhưng dần dà, tôi đâm ra... nản vì biết chắc những điều tôi trả lời không có kết quả hoặc tác dụng gì cả. Tuy vậy, những cuộc trao đổi này dẫn tôi đến chỗ thích thú khai phá, tìm tòi tâm lý của những người đặt câu hỏi. Tôi nhận ra vài điều lý thú: 
- những lối mòn của cách suy tư (nếu có suy tư) 
- khả năng tiếp cận và hình thành giải pháp cho vấn đề 
- ý muốn đào sâu và rèn luyện 

Đây là những điểm cốt lõi tôi muốn chia xẻ với bạn trong loạt bài "những cuộc đối thoại với rookie". Loạt bài này không có dụng đích phân tích kỹ thuật (mặc dù để hình thành nội dung bài viết chắc chắn không thể thiếu những chi tiết về kỹ thuật). Nó được khai triển ở dạng trò chuyện, trao đổi giữa hai (hoặc nhiều nhân vật) xen vào những chi tiết kỹ thuật. Những nhân vật này là tổng hợp từ tính cách của nhiều nhân vật có thật. Tuy nhiên, ngôn từ trao đổi trong bài viết đã được điều chỉnh và xây dựng lại cho thích hợp với tình tiết của các mẩu chuyện. 

Xin lưu ý rằng, những vấn đề được đưa ra trong chuỗi bài này nhằm thúc đẩy kỹ năng tiếp cận vấn đề, nghiên cứu và giải quyết vấn đề. Bởi thế, mọi giải đáp cho thắc mắc (nếu có) đều tìm thấy từ việc đọc và suy nghĩ kỹ lưỡng. 

2. Gặp gỡ: 
Chiều nay, một buổi chiều Chủ Nhật, rảnh rỗi và yên tĩnh. Tôi mở máy và log vào Yahoo Instance Messenger (đã gần một tuần lễ tôi không vào YIM). Chà, có vài cái "thỉnh cầu" đưa tên tôi vào danh sách YIM của ai đó. Thử xem nào... ngoại trừ một "thỉnh cầu" khá ngổ ngáo, tôi tiếp nhận các thỉnh cầu còn lại. Trong số "thỉnh cầu" này, có một cái làm tôi chú ý. Người thỉnh cầu có cái "nick" khá ngộ nghĩnh là "cuti" và thông điệp thỉnh cầu như sau: "nếu không phiền, xin phép anh add em với. Em có một số thắc mắc muốn nhờ anh chỉ dẫn, Nghe nói anh khó tính lắm nhưng em cũng liều một phen.". 

Tôi mỉm cười và nhấn nút "accept" và sau đó gởi đi thông điệp "Được, anh khó tính lắm. Thử xem!. Và đây là điểm khởi đầu của những cuộc trò chuyện giữa tôi và "cuti". 

Tôi chuyển trạng thái YIM của mình sang "invisible" vì không muốn trò chuyện lúc này. Tôi muốn kiểm tra mail và duyệt web để tìm một số thông tin cần thiết. Chừng năm phút sau, tôi nhận được một thông điệp nhấp nháy. Tôi mở ra và thấy rằng "cuti" vừa trả lời: 
"Cám ơn anh đã add em, khi nào anh online, cho em biết với!". 

Tôi muốn "thử" anh chàng một phát, bèn trả lời như sau: 
"Anh đã online, nhưng anh chưa nói chuyện được, em chờ được không?. 

"cuti" hồi đáp: 
Ồ may quá, may quá... dạ được chứ. Trưa Chủ Nhật em chẳng có chuyện gì đâu. Khi nào rảnh cho em biết với" 

Tôi yên lặng, thâu gọn cửa sổ của YIM và tiếp tục kiểm tra mail, trả lời mail. Gần nữa giờ trôi qua, tôi quên bẵng có "cuti" đang chờ. Tôi mở cửa sổ YIM lên xem và thấy "cuti" vẫn còn online. Tôi gởi cho anh chàng một thông điệp: 
"Chà, nãy giờ chat đã đời rồi hả? Anh rảnh rồi, em cần hỏi gì?". 

Tôi không ngờ trong tích tắt "cuti" đã trả lời tôi ngay. Điều này chứng tỏ cu cậu không bận rộn và quả thật... đang chờ. Nó cũng chứng tỏ cu cậu là một "cao thủ" gõ chữ vì trong tích tắc tôi đã nhận được thông điệp như sau: 
"Dạ, em đâu có chat, chỉ đang duyệt mấy trang web thôi. Em có vài thắc mắc là nếu mình muốn học hỏi, tham khảo tài liệu, cứ cho là mình đã có một mớ sách, cách nào để giúp mình nhớ được mọi thứ trong đống sách đó? À mà, anh cho phép em hỏi thăm anh bao nhiêu tuổi để tiện xưng hô. Nếu anh không muốn nói cũng không sao". 

Tôi mỉm cười thầm nghĩ "cu cậu này liếng lắm, muốn nói chuyện phương pháp và rào trước, đón sau". Tôi trả lời: 
"Anh nghĩ là anh lớn hơn em đó, em thấy xưng hô thế nào tiện thì xưng hô nhưng có lẽ nên xưng anh em thì hay nhất vì anh đoán em nhỏ tuổi hơn anh.". 

"cuti" nằng nặc muốn rõ chuyện tuổi tác: 
"Nhưng em muốn biết mà, lỡ xưng hô không phải đạo thì... kẹt lắm!" 

Tôi trả lời: 
"Được rồi, nếu em muốn biết thì anh mem mém tứ tuần." 

"cuti" im lặng một chặp, có lẽ cu cậu nghĩ ngợi gì đây. Sau đó, một thông điệp khác đến từ "cuti" như sau: 
"Ùm... thôi, để cháu gọi chú bằng chú đi, chú chỉ kém ba cháu có vài tuổi, gọi bằng anh kỳ cục sao đó!". 

À, hoá ra cu cậu im lặng một chặp là vì lý do này. Tôi mỉm cười trả lời: 
"Thôi đi, chú với chả cháu. Xưng anh em vui hơn!" 

3. Khai mở: 
Tôi tiếp tục giải đáp thắc mắc của "cuti": 
"Về việc đọc và nhớ những gì mình đọc thì như thế này. Để có thể đọc và nhớ, em phải tập cho mình thói quen tổng kết những gì mình đọc được ở dạng ngắn gọn và có hệ thống nhất có thể được (trong khả năng của em). Đây là một kỹ năng hẳn hòi và nó cần sự rèn luyện liên tục. Ví dụ, đọc xong một chương, thử tóm tắt lại chương này đề cập những chuyện gì? những điểm cốt lõi của nó nằm ở đâu? Nếu chưa có thói quen tổng kết trong não thì thử tổng kết trên giấy. Ghi lại những điểm mình nắm được. Đừng ngại sai đúng, đủ thiếu gì cả. Sau đó so sánh lại với thông tin trong sách xem thử mình thu thập được bao nhiêu sau lần đọc thứ nhất. Sau một thời gian, chắc chắn khả năng này sẽ thay đổi." 

"cuti" trả lời ngay: 
"Ôi trời! sao mà khó vậy?" 

Tôi phá lên cười và hỏi tiếp: 
"Em đã thử chưa mà thấy khó? Em tự xét xem em có đủ kiên nhẫn để đạt được điều mình muốn không?" 

Lần này "cuti" im lặng khá lâu, chứng tỏ cu cậu đắn đo lắm trước khi trả lời. Tôi biết cu cậu không chat với ai khác bằng YIM bởi vì thanh "status" của YIM không hiển thị thông điệp "cuti is typing a message". Tôi thong thả đốt điếu thuốc và chờ. Gần hai phút sau, "cuti" mới hồi đáp một câu: 
"Cho em nói thật cái này nha? Em thấy là anh không khó tánh như người ta nói nhưng nói chuyện với anh em bị cảm giác căng thẳng vì phát biểu không cẩn thận sẽ bị anh "bẻ" ngay." 

Tôi cười phá lên và đáp: 
"Em sắc sảo đấy. Anh chả khó tính tí nào. Có lẽ em bị 'chạm' vì anh hỏi vặn lại 'em thử chưa mà thấy khó?' chứ gì? Câu hỏi đơn giản này của anh hàm chứa một điều như sau: đừng xét vấn đề dựa trên cảm tính mà hãy xét nó một cách khoa học. Hãy cân nhắc, thử nghiệm, rút tỉa rồi mới hình thành ý kiến của mình về một vấn đề nếu như vấn đề ấy mình chưa bao giờ kinh qua. Rõ ràng là em chưa hề thử qua cách đọc, suy nghĩ và tổng kết bao giờ thì làm sao em có thể kết luận ngay 'sao mà khó vậy?'. Cho nên câu phát biểu này theo anh thấy, nó đầy cảm tính. Đây là một trở ngại đầu tiên và thường thấy, nó sẽ làm em chùn bước trước những cái còn 'khó' hơn nhiều. À mà em vẫn chưa trả lời câu hỏi của anh là em có đủ kiên nhẫn hay không?" 

"cuti" trả lời: 
"Có lẽ em suy nghĩ quá đơn giản. Thông thường nếu em nói là 'cái đó khó quá' thì người đối diện hay trả lời là 'khó thì thôi' chớ ít ai hỏi ngược lại 'chưa thử mà biết khó hay sao?'. Cái này làm em chột dạ, nhưng không sao, em phải làm quen với lối suy nghĩ và cân nhắc vấn đề này. Còn chuyện kiên nhẫn hay không thì... hy vọng em có đủ kiên nhẫn." 

Tôi đáp: 
"Vậy thì tốt. Thử dùng cái kiên nhẫn của em, tìm ngay một cuốn sách nào đó, về vấn đề gì đó em rất thích. Đọc và thử nghiệm cách tổng kết rồi cho anh biết kết quả ra sao nha?" 

4. 'hack' là gì? 
"cuti" vui vẻ trả lời: 
"hi hi, nhất định rồi. Để tối nay em 'thử nghiệm' xem sao. À mà đúng ra em muốn hỏi anh câu này ngay từ đầu nhưng hơi ngại. Anh có thể chỉ em cách hack được không? Em mê 'hack' lắm á, em muốn học mà chẳng biết bắt đầu từ đâu. 

Tôi có phần cụt hứng khi nhận được câu hỏi này, không phải là vì "cuti" đề cập đến chuyện hack mà cách "cuti" hỏi về chuyện hack trong một câu ngắn gọn đến thế. Tôi hỏi thêm: 
"Em hiểu thế nào là 'hack' vậy? May mà em không hỏi câu này ngay từ đầu không thì anh lại 'bẻ' cho hụt hơi". 

"cuti" trả lời ngay: 
"Ồ, hack hả anh? anh hỏi theo kiểu mẹo hay hỏi thiệt vậy? Hack là gì ai mà không biết?" 

Tôi gõ ngay câu trả lời: 
"Ừa, vậy mà anh vẫn muốn biết em hiểu thế nào là 'hack'. Em thử trả lời anh xem?" 

"cuti" tỏ vẻ đắn đo vì cu cậu im lặng vài chục giây rồi mới trả lời: 
"Ùm... em nghĩ rằng hack là thâm nhập vào một máy nào đó... phải không anh?" 

Tôi phá lên cười vì tính thành thật và đơn giản của "cuti" trong khi gõ thông điệp trả lời cho cu cậu: 
"Em lầm rồi, 'hack' không phải và không chỉ đơn giản là 'thâm nhập vào một máy nào đó'!" 

Cu cậu hồi báo ngay: 
"Anh lại trêu em rồi. Thôi đi, bày cho em cách hack đi mà." 

Tôi trả lời: 
"Không đâu, anh nói thật. Em hiểu sai về 'hack' rồi đó!" 

Lần này "cuti" thật sự sửng sốt: 
"Vậy.... theo anh 'hack' là gì? Em hy vọng là anh không trêu em tội nghiệp." 

Tôi mỉm cười trả lời: 
"theo anh? Vậy ý em theo anh nghĩ thì khác, theo em nghĩ thì khác và theo ai đó nghĩ thì khác về khái niệm 'hack' là gì phải không? Nếu vậy thì theo anh, chỉ có hai khả năng: hiểu đúng về cái gọi là 'hack' hoặc hiểu chưa đúng về cái gọi là 'hack', thế thôi. 

Theo anh (hiểu), 'hack' là sự sửa đổi nào đó có dụng đích rõ ràng trên hệ thống (trên nền tảng của hệ thống, trên cơ chế làm việc của hệ thống...) và sửa đổi này làm thay đổi 'thái độ' làm việc của hệ thống ấy. 'Sửa đổi' này là một trong những biểu thị của việc 'hack'. 'Thái độ' này đúng hay sai, thiện hay ác, ngắn hay dài... là chuyện khác. " 

"cuti" im lặng khá lâu. Có lẽ cu cậu đang "tiêu hoá" đoạn định nghĩa lỏng chỏng của tôi. Sau một hồi, "cuti" trả lời: 
"Chà, phức tạp quá vậy? nhưng việc thâm nhập vào một máy nào đó cũng là 'hack' theo định nghĩa của anh cơ mà?" 

Tôi cười đáp: 
"Không đâu em, nếu em phân tích kỹ hơn một tí thì sẽ thấy điểm khác biệt ở đây. 
a. 'hack' là sự thay đổi nào đó đến hệ thống. Điều này có nghĩa em phải có quyền truy cập, sử dụng rồi mới có thể thực hiện sự thay đổi. Ít nhất em phải có một chủ quyền nào đó, dù nhỏ bé nhất, mong manh nhất thì mới có thể 'hành động' được. 
b. thâm nhập vào một máy nào đó có nghĩa là em ở trong giai đoạn trước khi xác định được chủ quyền cần thiết để thực hiện 'hành động' hack." 

Nói một cách khác, phải có a thì mới có b. 


Lần này "cuti" im lặng khá lâu. Tôi để yên cho cu cậu nghĩ ngợi thoả thích. Sau một hồi, "cuti" hỏi tiếp: 
"Nếu thế thì việc thâm nhập vào một máy nào đó bao gồm 'hành động' hack chớ chính nó không phải là 'hack'? Mình gọi chung chung tất cả là 'hack' không được sao?" 

Tôi đáp: 
"Đúng vậy, nếu như em muốn xét vấn đề trên phương diện hiện tượng thay vì phương diện thứ tự thời gian. Việc gọi như thế nào không quan trọng bằng việc hiểu thực chất vấn đề là ở đâu." 

"cuti" hồi đáp ngay: 
"Hình như anh đang chỉ cho em chỉ phần lý thuyết mà thôi? Em cố gắng hình dung việc áp dụng lý thuyết này vào thực tiễn nhưng sao thấy mù mờ quá." 

Tôi trả lời: 
"Được rồi, hãy xét xem một vài trường hợp anh nghĩ thuộc dạng 'hack'. 

a. nếu em thay đổi một giá trị trong Windows registry để đạt được mục đích nào đó hoặc 'mở' ra thêm một chức năng nào đó mà Windows không có ở chế độ mặc định. Đây chính là 'hack'. Để có thể thực hiện chuyện này, em phải được phép (có quyền) khởi động lệnh regedit. Nếu không, hành động 'hack' này không thể xảy ra. 

b. tương tự cho hệ thống *nix, nếu những giá trị mặc định nào đó trong /proc system của Linux không ứng hiệu theo ý em, khi em thay đổi chúng có nghĩa là em đã 'hack'. Để làm được chuyện này, em phải có chủ quyền nhất định. 

c. em có thể duyệt một trang web nào đó nhưng không thể thay đổi 'thái độ' của nó (cách hiển thị, giá trị hiển thị....). Tuy nhiên, để ứng dụng web (của trang web này) hiển thị những thứ khác hơn (đáng lẽ ra nó không được hiển thị như thế), em phải tác động đến nó bằng cách này hoặc cách khác (dùng telnet, dùng netcat, dùng string ngay trên chính trình duyệt....). Để làm được chuyện này, em phải có chủ quyền nào đó. 

Trong phạm vi truy cập, nếu em có thể duyệt trang này, ít nhất em đã có chủ quyền như một guest và ít nhất, em đã truy cập được vào trang web trước khi có thể thực thi một 'hành động' nào đó. Làm guest có giá trị chủ quyền nhất định. 

Nói một cách tổng quát, giả sử dịch vụ cho phép truy cập nhưng lại đòi hỏi tên người dùng và mật khẩu hẳn hòi, em hoàn toàn không có chủ quyền nếu như em duyệt trang web này với tư cách guest. Nói một cách khác, cơ hội để em 'hack' (hay tạo một tác động nào đó) trên web server này là rất thấp (hoặc giả không có). Tuy nhiên, nếu em phân tích tỉ mỉ thì thấy rằng, khi em truy cập vào một trang web đòi hỏi xác thực danh tánh, sẽ có giai đoạn em vẫn là guest và vẫn có thể tác động đến web server (để thực thi giai đoạn xác thực danh tánh). Giai đoạn ngắn ngủi này là chổ trống (có thể) để em tạo một tác động gì đó đến máy chủ (hay còn gọi là 'hack'). 


"cuti" trả lời (kèm theo một emotion icon biểu thị cho sự 'buồn bã'): 
"Chà, càng lúc càng rối bòng bong cả lên. Nếu vậy, em muốn thâm nhập vào một máy con nào đó trên Internet thì có nghĩa em phải có chủ quyền gì đó trên máy kia?" 

Tôi cười đáp: 
"Tất nhiên. Nếu không em không thể 'hack' được. Anh nhắc lại: 'hack' là một hành động chỉ có thể xảy ra khi có được chủ quyền, có thể truy cập đến mục tiêu mình muốn thâm nhập. Đây mới chỉ là khái niệm tổng quát. Nếu em muốn thâm nhập vào một máy nào đó trên Internet, em phải biết rõ máy đó là máy gì? nó chạy trên hệ điều hành nào? Kế tiếp em mới tìm hiểu xem em có thể truy cập nó vào vị trí nào và xem thử em có được chủ quyền gì? Nói trên bình diện thâm nhập xuyên qua mạng và dùng phương tiện truyền tải TCP/IP, lối vào duy nhất và hiển nhiên nhất là cổng dịch vụ. Nếu dịch vụ không chạy --> không có cổng. Nếu không có cổng --> không thể vào." 

"cuti" nhăn nhó: 
"Gì mà khó khăn, rắc rối vậy? Bộ không có một phần mềm nào đó, mình chỉ cần gõ tên hoặc địa chỉ của máy mình muốn thâm nhập và mình .... "chui' vào máy đó?" 

Tôi phá lên cười và có phần thất vọng (sau khi cố gắng giải thích một cách có đầu đũa, có nguyên tắc với cu cậu). Tuy nhiên, tôi vẫn trả lời: 
"Tất nhiên là có phần mềm làm những chuyện này ở mức độ nào đó. Tuy nhiên, dựa vào phần mềm để làm chuyện này có lẽ không còn là 'hack' nữa nói theo khái niệm nãy giờ anh cố gắng trao đổi với em." 

"cuti" cãi lại: 
"Nhưng.... mục tiêu cuối cùng là thâm nhập. Không cần biết mình dùng công cụ nào, miễn sao thâm nhập được là... xong. Nếu anh nói cần phải có chủ quyền rồi mới có thể tạo tác động, thì phần mềm này sẽ xác định mục tiêu thâm nhập có phải là hệ điều hành mình muốn, sau đó nó thử truy cập và dùng quyền guest chẳng hạn rồi... thực thi một lệnh nào đó và thâm nhập vào máy. Những bước này hoàn toàn phù hợp với khái niệm anh đưa ra. Chỉ có cái khác là em không làm 'bằng tay' mà dùng một công cụ." 

Tôi cười và nói: 
"Nếu thế thì lẽ ra em phải hỏi anh thế này: 'anh có biết công cụ nào dùng để rà và thâm nhập vào máy nào đó hoàn toàn tự động mà mình không cần làm gì hết?', thay vì: 'Anh có thể chỉ em cách hack được không?'. Nãy giờ anh thử 'chỉ' em cách 'hack' đó nhưng có lẽ em không đủ kiên nhẫn để tiếp thu những điều anh 'chỉ' mà chỉ muốn tìm một cách nào đó, một công cụ nào đó giản tiện và đạt được mục đích ngay lập tức. Thật tình mà nói, anh có thấy một số công cụ ở dạng này và đã có thử qua cho biết nhưng chỉ một lần rồi anh không bao giờ đụng đến chúng nữa. Em muốn biết lý do tại sao không?" 

"cuti" hăm hở: 
"Thật sao? thật có phần mềm nào tuyệt diệu đến thế sao? anh chỉ cho em chỗ nào để down nó về đi. Năn nỉ đó!" 

Tôi chắc lưỡi than thầm "lại thêm một anh chàng newbie thích ăn xổi, ở thì". Tôi cố kiên nhẫn tiếp tục trả lời: 
"Link để download thì có thể tìm ra nhưng anh không nhớ ngay lúc này vì anh không còn đụng đến chúng nhiều năm rồi. Tuy nhiên, điều anh muốn nói ở đây là thế này: 
- 'hack' với dụng đích nào đó (tốt hay xấu) có sự lý thú của nó. Lý thú ở chỗ nó là một sự thách thức (challenge) để mình phải suy nghĩ, phân tích, tìm tòi và giải quyết. Thiếu mất điều này, 'hack' chẳng còn gì là thú vị nữa. 
- công cụ nào cũng vậy, nó có giới hạn nhất định. Công cụ được viết ra nhằm thâm nhập một hệ điều hành cho khoảng thời gian nào đó. Sau khi hệ điều hành này vá lỗi, các công cụ này trở nên vô dụng. Đó là chưa kể trường hợp các công cụ ở dạng này không hiếm bị đính một con trojan. Người dùng nó chưa thâm nhập được thì lại bị thâm nhập. 
- kiến thức và kinh nghiệm 'hack' theo đúng nghĩa của nó được trả giá bằng thời gian, bằng sự kiên nhẫn và niềm đam mê của người muốn tìm tòi và khai phá những điều mình thắc mắc. 

Thật sự anh chỉ thích trao đổi với những ai thật sự kiên nhẫn và muốn tìm tòi theo đúng nghĩa của nó. Nhưng, cho anh biết lý do tại sao em thích thâm nhập theo lối dùng một công cụ và phó mặc công cụ ấy vậy?" 

"cuti" trả lời kém hăm hở hơn trước: 
"Thật sự em chỉ tò mò xem thử 'chui' vào máy ai đó thế nào thôi. Xem thử nó ra sao, vậy thôi. Nếu em có được phần mềm này, chắc em chỉ thử một lần cho biết xem 'hack' là cái gì." 

Tôi trầm ngâm vài giây rồi trả lời cu cậu: 
"Có lẽ anh nhận định sai về cái em gọi là 'em muốn học mà chẳng biết bắt đầu từ đâu' như em đã nói. Dùng một công cụ nào đó để 'chui' vào máy của người khác chỉ có thể nằm ở mức độ giải quyết sự tò mò chớ không thể thuộc diện tìm tòi và học hỏi vì việc làm này chẳng mang tí gì tính học hỏi một cách đúng nghĩa cả. Em thử tưởng tượng máy của một người dùng bình thường khác với máy của em thế nào? Anh nghĩ nếu như nó là một máy chạy Windows (anh nghĩ em thạo Windows) thì cũng C: rồi D: và bấy nhiêu software mà ai cũng dùng. Có gì đáng để 'thoả' cái tò mò đâu nhỉ? Đừng nói là em muốn tìm xem trong máy nào đó có CC và những thông tin 'lý thú' khác để... phá bởi vì anh không ủng hộ những chuyện này đâu. Không những thế mà anh cảm thấy.... mất hứng khi trao đổi." 

"cuti" đáp: 
"Dạ không, em chẳng dám nghĩ đến chuyện kiếm CC hay gì đâu. Cùng lắm là thâm nhập vào máy nào đó, cài một .bat file để doạ chủ nhân của máy chơi cho vui. Ví dụ như, khi chủ nhân mở máy, nó hiện ra thông điệp 'you are hacked' rồi chờ vài giây, nó lại hiện ra thông điệp 'just kidding!. Em nghĩ mấy trò này vô hại mà." 

Tôi phá lên cười vì tính trẻ con của "cuti" và trả lời: 
"Ừa, anh thấy mấy trò này quả vô hại nhưng cũng vô... ích luôn. Em thử nghĩ xem, em phải mất thời gian tìm tòi, hỏi han cho ra một software có thể dùng để 'chui' vào máy của ai đó chỉ để tạo ra hai thông điệp 'doạ' khổ chủ cho vui thôi thì khá phí thời gian. Mấy việc làm tinh quái này càng không dính dự gì đến chuyện em nói ngay từ đầu là 'em muốn học hỏi'. Có thể chính em không làm gì phương hại cho khổ chủ của cái máy kia nhưng những cậu bé khác chắc gì có suy nghĩ như em? Cho anh hỏi, em đang làm gì hay còn đi học?" 

"cuti" trả lời ngay: 
"Dạ em đang còn đi học mà, em học tin năm thứ hai. Bộ hồi nhỏ anh không có thử qua những trò tinh quái của tuổi học trò sao? Chắc anh cũng biết 'nhất quỷ, nhì ma, thứ ba học trò' phải không?" 

Tôi chậm rãi đáp lại, cố gắng thuyết phục "cuti" từ bỏ ý định làm một việc vô ích: 
"Không may (hay có thể là may) cho anh là thời anh còn bé, mọi chuyện thời ấy khó khăn lắm, nó làm cho con người trưởng thành hơi sớm và bị mất đi rất nhiều những trò tinh quái kia. Đến lúc anh bắt đầu làm quen với computer thì lúc ấy anh cũng đã qua tuổi 'rookie' rồi cho nên quả thật anh chưa hề kinh qua những trò tinh quái như em nói. Anh thật sự không chống đối những trò chơi vặt và vô hại kia, anh chỉ tiếc cho thời gian và công sức mình bỏ ra chỉ để tạo những thoả mãn rất mơ hồ. Nếu em thật sự muốn học hỏi về 'hacking' đúng nghĩa của nó, thỉnh thoảng (khi rảnh) anh có thể góp ý cho em để đỡ vất vả trong chuyện định hướng và tìm tòi. Còn nếu em muốn anh 'bày' em những tiểu xảo để thực hiện những việc làm buồn cười và tinh quái kia thì... có lẽ anh không có hứng thú đâu. Vả lại em đang học năm thứ hai thì có lẽ khối lượng công việc, bài vở bắt đầu nhiều rồi đó. Thay vì phí thời gian với những chuyện này, sao em không dùng nó để 'đầu tư' vào chuyện học hành? Anh dám chắc những kiến thức em đã học qua vẫn còn những chỗ lổng chổng trong đó, sao không dùng thời gian để đào sâu và nắm rõ ngọn ngành?" 

"cuti" cười đáp: 
"hi hi, anh nói giống ông bác của em nói quá. Đúng là mấy ông già thường có khẩu khí giống nhau. Em thấy anh có lý lắm. Mặc dù em vẫn còn ấm ức chuyện 'thâm nhập' nhưng quả thật em không cãi lại anh. Đối với em, 'hack' là cái gì đó hết sức mù mờ nhưng biết 'hack' và 'hack' được gì đó quả là phê. Nếu bạn bè em biết em biết cách 'hack' thì bọn nó sẽ phục em lăn quay. Làm 'cao thủ' hack hơi bị... hay đó. Chắc em phải theo anh để 'tầm sư học đạo' quá, được không anh?" 

Tôi chợt nhận ra một khía cạnh mới trong suy nghĩ của "cuti": 'hack' để được bạn bè nể trọng. Quả là khái niệm lý thú về mặt tâm lý. Tôi trả lời cu cậu: 
"Vậy, em muốn 'hack' là vì một lý do khác nữa: 'hack' để được bạn bè nể trọng? Ở mức độ nào đó, bọn nó nể trọng em cũng phải vì em biết được điều bọn nó chưa biết. Nói trên bình diện khả năng thì cái 'nể' ở đây chính là kiến thức bởi vì em có kiến thức 'hack' còn đám bạn của em không có kiến thức này. Cho đến lúc này, em lại quay về chuyện 'kiến thức' và 'học hỏi'. Tuy nhiên, suy nghĩ 'hack' để được bạn bè nể trọng khá sai lạc nếu như 'hack' đồng nghĩa với tấn công và phá hoại. Người được 'nể' vì chuyện này đã sai mà người nể khả năng này cũng sai nốt. 

Anh tạo điều kiện cho em suy nghĩ và trả lời anh lần tới nếu mình có cơ hội nói chuyện tiếp: 

a. em thực sự muốn trau dồi kiến thức hay không? 
b. em thực sự có đủ kiên nhẫn để thực hiện việc 'trau dồi' này không? 
c. em thực sự hiểu 'hack' là gì không? 

Nếu em có thể trả lời ba câu này, mình có cơ hội trao đổi nhiều hơn." 

"cuti" đáp không chút đắn đo: 
"Em trả lời ba câu trên được ngay mà. Khỏi cần đợi lần tới." 

Tôi cười đáp: 
"Không, anh muốn em suy gẫm lại những gì mình trao đổi hôm nay thật kỹ rồi trả lời anh sau. Anh tin rằng có nhiều thông tin em cần thời gian để 'tiêu hoá'. Nếu cần, em nên save lại trọn bộ nội dung anh em mình chat ngày hôm nay để khi nào rảnh, đọc lại cho kỹ. Đối với anh, mình chat vậy là phá kỷ lục rồi đó." 

"cuti" có vẻ hơi cằn nhằn: 
"Mình chat cũng lâu nhưng anh toàn nói chuyện lý thuyết không thôi. Em thích động tay, động chân hơn. Em thích làm cái gì có kết quả liền." 

Tôi đáp: 
"Chuyện thực hành không khó nếu như mình nắm được nguyên tắc, nắm được cốt lõi của vấn đề. Nếu bây giờ mình bàn về một 'lệnh' nào đó, có thể nó vô ích và vô nghĩa nếu như anh em mình chưa thống nhất ý kiến cái gọi là 'hack'. Bởi vậy, em nên xem lại những gì mình chat đi, đừng nóng vội vì nếu mình còn... 'duyên' trao đổi thì thời gian còn dài. Anh phải đi chuẩn bị một số chuyện để ngày mai còn đi làm nữa. Thôi, mình gặp lại sau hả? Chào 'cuti'." 

Tôi không quên save lại nội dung chat hôm nay để tham khảo và tiếp nối cho lần sau (nếu còn dịp chat với "cuti") rồi logoff. 

Sau bốn mươi phút chat với một cậu bé đang học đại học năm thứ hai, có kiến thức về tin học, tôi rút ra được vài điều như sau: 
- hiểu chưa đúng về cái gọi là 'hack' 
- vẫn còn thích phá phách một cách tinh quái 
- chưa bình tĩnh để xét đoán một vấn đề 
- thiếu kiên nhẫn để nhận ra những điểm cốt lõi mà chỉ thích thấy ngay kết quả 
- bị cám dỗ bởi cái danh tiếng rất mơ hồ là 'cao thủ hacker' 

Tôi không chắc "cuti" có đủ kiên nhẫn để đi qua "con đường chông gai" hay không, nhưng đây là chuyện của lần tới. Tôi xếp máy lại. 

16/06/2005 

Chú thích: 
-1- rookie chỉ cho những người trẻ tuổi, bồng bột và thiếu kinh nghiệm.

5. Nền tảng 
Gần một tuần lễ trôi qua, tôi quá bận bịu và không có chút thời gian để log vào YIM. Chiều hôm nay, một chiều thứ Năm yên tĩnh một cách hiếm hoi, "thủ trưởng" thì nghỉ bệnh, mấy tay làm việc trong nhóm thì đi tham dự khóa huấn luyện. Chỉ còn mỗi mình tôi ở lại "trụ". Hơn một giờ nữa mới đến giờ tan sở nhưng tôi không thể làm gì hơn với mớ công việc dang dở (vì phải đợi thông tin từ một số phần hành khác). Chợt nhớ đến "cuti" và lần chuyện trò với cu cậu gần một tuần lễ trước đây, tôi quyết định log vào YIM. 

Chà, có hàng đống offline messages và quả thật, trong mớ này có đến năm sáu cái của "cuti". Tôi xem xét từng message và thong thả hồi âm cho từng người. Khi đọc đến các messages của "cuti" tôi phá lên cười nhiều lần vì chúng có nội dung rất ngô nghê như sau: 
"Anh 'già khó tánh' có đó không? Em đã nghe theo anh và in ra phần nội dung chat để 'ngâm kíu' nhưng em thấy sao mà khó quá. Anh có đó không? 

Chắc hẳn "cuti" nghĩ rằng tôi cố tình "núp" ở tình trạng "invisible" và cu cậu đã xác nhận tôi là "anh già khó tánh". Tôi lẩm bẩm: "Hừ, lại 'khó quá' mà chẳng có thêm một dòng giải thích tại sao khó", nhưng lại cười một mình vì nghĩ rằng tôi hơi ngớ ngẩn khi cho rằng "cuti" đã bắt đầu có thói quen trình bày có "đầu đũa" sau một lần chat ngắn ngủi với tôi. 

Một thông điệp khác cũng không kém phần "hài hước" từ "cuti": 
"Anh 'già khó tánh' ơi? vậy 'hack' là một hành động xảy ra sau khi thâm nhập được? Nếu vậy em không cần biết 'hack' mà chỉ cần biết cách thâm nhập là đủ. Bày em cách thâm nhập đi anh già khó tánh ơi". 

Ngay sau thông điệp trên là thông điệp như sau (tính theo thời gian gởi) của "cuti": 
"Anh già khó tánh núp đâu kỹ vậy? Cho em hỏi cái này một tí đi. Nếu em muốn 'hack' vào một máy khác, em phải thâm nhập nó trước rồi mới 'hack' nó? Nếu em đã thâm nhập nó được rồi có nghĩa là là đã 'hack' thành công rồi còn gì nữa mà... hack trời? Chết em rồi, bị tẩu hoả rồi, hu hu hu." 

Lần này tôi bật cười thật to vì tính ngộ nghĩnh của "cuti". Quả thật cu cậu đang đi vào con đường "tẩu hoả" bởi vì cứ bị "ám" mãi cái khái niệm sai lạc về 'hack'. Tôi quyết định gởi "cuti" một thông điệp thế này: 
"Hello cuti, anh không trốn mà ít vào YIM thôi. Em bắt đầu có chiều hướng 'tẩu hoả' thật rồi đó. Anh đã bảo thâm nhập không phải là 'hack' cơ mà. Thâm nhậplà bước xảy ra trước khi 'hack'. Em cứ bị ám ảnh mãi khái niệm 'thâm nhập' là 'hack'. Đừng cố quá mà hỏng hết." 

Vài phút sau, "cuti" dội cho tôi hàng loạt thông điệp trên YIM, toàn là những chuyện cu cậu xuýt xoa về cái khái niệm 'hack' tôi đưa ra làm cậu mất ăn, mất ngủ. Tôi đáp bằng một thông điệp ngắn gọn: 
"Thong thả nào cuti. Anh em mình thử 'bàn' một ví dụ cụ thể nào đó có lẽ dễ chịu hơn hả?". 

Không đợi "cuti" trả lời, tôi gởi tiếp một thông điệp khác: 
"Này, ví dụ ở nhà em có hai máy chạy Windows chẳng hạn. Bằng cách nào đó, em truy cập máy B từ máy A (là máy của em). Tuy nhiên, sau khi truy cập vào máy B, em chỉ duyệt máy này mà không thay đổi gì cả, không tạo thêm file mới, cũng chẳng delete file cũ... Như thế có gọi là 'hack' không?" 

"cuti" trả lời nhanh như điện: 
"Anh ăn gian quá, làm như thế thì chỉ là truy cập thôi chớ hack hiếc gì anh. Em biết tên người dùng và mật khẩu của máy B thì em vào chớ đâu có gì vất vả đâu mà gọi là 'hack'?" 

Tôi thấy thêm một nhìn nhận mới về cái gọi là 'hack' theo suy nghĩ của "cuti", nên tôi hỏi lại: 
"À, ra thế. Vậy, nếu em biết tên người dùng và mật khẩu của một máy nào đó và dùng chúng để truy cập vào máy này thì chỉ là... truy cập? Nếu em không hề biết tên người dùng và mật khẩu nhưng bằng cách nào đó em có thể truy cập nó thì gọi là... 'hack'?" 

"cuti" cười hớn hở: 
"Hi hi, đúng vậy đó anh! Chỉ đơn giản như thế thôi. Còn cái khái niệm quỷ quái của anh làm em điên đầu chớ chẳng đi tới đâu cả." 

Tôi cười, hỏi tiếp: 
"Thế, điểm khác nhau giữa việc: 

a. ai đó cho em tên người dùng và mật khẩu để truy cập đến máy X nào đó. Người này không phải là chủ nhân của máy. 

b. em tự dùng cách nào đó (đoán mò, brute force...) để rốt cuộc tìm ra được tên người dùng và mật khẩu cũng để truy cập đến máy X này. 

a và b khác nhau chỗ nào?" 

"cuti" im lặng hồi lâu rồi rụt rè trả lời: 
"Hình như anh lại hỏi mẹo em nữa hay sao đó phải không? Em thấy rõ điểm khác nhau duy nhất là trường hợp b cực hơn trường hợp a và đôi khi không đạt được trường hợp b nữa là đằng khác." 

Tôi trấn an "cuti": 
"Không, anh chưa hề 'hỏi mẹo' em bao giờ, câu nào anh hỏi cũng đều là hỏi thật cả. Vậy, cả a và b ở trên có được gọi là 'hack' hay không?" 

"cuti" đáp ngay, không suy nghĩ: 
"Tất nhiên b là 'hack', a là 'truy cập'." 

Tôi cười phá lên và hỏi thêm: 
"Tại sao a là 'truy cập' mà b là 'hack' vậy cuti?" 

"cuti" có vẻ giận dỗi, đáp: 
"Anh hứa là mình sẽ bàn một ví dụ cụ thể mà lại đi hỏi em lăng nhăng như thế này thì... oải quá . Tất nhiên b là 'hack' vì mình phải mò mẫm, chịu khó, mất thời gian để tìm ra tên người dùng và mật khẩu để vào được máy X chớ sao nữa anh?" 

Tôi vẫn kiên trì "khai thác" suy nghĩ của "cuti": 
"Vậy nếu một tên đạo chích muốn 'thâm nhập' vào dinh cơ của ông phú ông chẳng hạn. Có hai trường hợp xảy ra vời tên đạo chích này: 

a. hắn có chìa khoá mở cửa vào. 

b. hắn dùng cọng dây thép để ngoáy lỗ khoá. 

Cả hai trường hợp đều tạo ra điều kiện cho tên đạo chích vào được nhà ông phú ông. Chỉ có cách b khó khổ hơn cách a. Tuy nhiên, sau khi tay đạo chích vào được trong nhà nhưng hắn chưa 'mó tay' vào món nào của phú ông mà chỉ 'nghía' xung quanh thì hắn 'hack' chưa? " 

"cuti" reo lên: 
"Á à, em hiểu rồi. Ý anh 'thâm nhập' bằng cách này hay cách khác chỉ là 'thâm nhập'. Còn 'hack' thì phải động đến cái gì đó bên trong môi trường mình đã thâm nhập, phải không anh già khó tánh? ." 

Tôi cười đáp: 
"Đúng vậy. Ngay cả trường hợp trên thay tên đạo chích bằng thằng cháu của phú ông và phú ông đưa hẳn chìa khoá cho nó vào dinh thự. Nếu nó đã vào được dinh thự (bằng chìa khoá hẳn hòi) và chỉ quan sát mà không 'mó' tay vào bất cứ thứ đồ đạt gì trong nhà thì có nghĩa nó chưa 'hack' ông phú ông vậy . Nói một cách khác, 'thâm nhập' một cách hợp lệ hay bất hợp lệ vẫn là 'thâm nhập'; sau khi 'thâm nhập' rồi, 'hack' hay không là một hành động khác. Anh muốn mình thông qua khái niệm này." 

"cuti" cảm thán: 
"Trời đất, trước giờ em cứ tin tưởng rằng hễ mình thâm nhập được vào một hệ thống thì có nghĩa là mình đã 'hack'. Nhưng nói theo 'định nghĩa' của anh thì quả thật 'hack' là một hành động thay đổi thái độ làm việc của hệ thống. Mình không 'mó' gì cả thì chẳng có gì thay đổi --> no hack. Thú vị thật, thú vị thật." 

"cuti" dường như nhận ra điều gì đó bèn nói tiếp: 
"A, em biết ý anh rồi. Anh đáo để thật. Anh nói là anh sẽ bày em cách 'hack' có nghĩa là anh không động đến chuyện 'thâm nhập', có nghĩa là mặc em muốn 'thâm nhập' ra sao thì tuỳ rồi 'hack' thế nào thì anh chỉ vẽ sau, phải không?" 

Tôi cười phá lên: 
"Ha ha ha, đó là em tự suy diễn đó nha. Em thích như vậy thì cũng tốt!" 

"cuti" phụng phịu: 
"Trời ơi, em bị lừa một quả đau thật . 'thâm nhập' mới khó chớ, đã 'thâm nhập' được rồi muốn 'hack' sao lại không được?" 

Tôi nghiêm giọng: 
"Em thật sự tin rằng 'thâm nhập' khó hơn 'hack' sao? anh em mình thử đánh cuộc một phát xem?" 

"cuti" thận trọng hơn trước nhưng câu trả lời của cu cậu không dấu được sự tự tin với ý kiến của mình: 
"Ùm... em tin rằng 'thâm nhập' mới thật là khó, 'hack' cũng khó nhưng không 'thâm nhập' được thì làm sao mà 'hack'?, phải vậy không anh? Nếu anh chứng minh được 'hack' khó hơn 'thâm nhập' hoặc khó bằng 'thâm nhập' thì anh nói gì em cũng nghe hết!" 

Tôi cười, đáp lời "cuti": 
"Được rồi, hứa đó nha 'anh nói gì em cũng nghe hết!'. Anh cho em IP của một Linux server, anh cho em biết luôn đó là Linux gì, chạy kernel nào, dùng filesystem nào. Anh cho em luôn tên người dùng, mật khẩu và cổng SSH để log vào. Em khỏi lo chuyện 'thâm nhập' đi. Bây giờ anh cho em một ngày để 'hack' cái server đó để làm sao trang chủ index.html có dòng "cuti was here and won the bet to the grumpy old man!". Anh không cho em biết web server này chạy bằng chương trình nào, hồ sơ cấu hình nó nằm ở đâu... Tùy em phải tìm hiểu. Em thử 'hack' xem dễ hay khó!" 

"cuti" rú lên và tuôn ra hàng tràng ca cẩm: 
"Tiêu em rồi anh già khó tánh ơi! Anh biết em không rành Linux mà lại mang Linux ra bắt em 'hack' thì em thua là cái chắc . Lúc trước em có nghe mấy đứa bạn tán kháo là Linux mạnh lắm. Em cũng cài thử. Mất mấy ngày trời bầm dập mới xong. Rốt cuộc cũng vào được Linux nhưng chỉ thấy màn hình đen thùi với dòng chữ màu trắng, y như mấy cái cửa sổ DOS cổ lỗ sĩ, chán như con gián. Em chả thấy mạnh ở đâu mà chỉ thấy chán thôi. Sau đó chỉ tháo bỏ Linux thôi mà vất vả quá trời, thiếu điều mất luôn cái partition Windows của em. Thôi thôi, em chịu thua độ rồi đó." 

Tôi nhận thấy cái tính thiếu kiên trì, thiếu ngọn ngành của 'cuti' một lần nữa thể hiện rõ trong câu trả lời trên. Trầm ngâm vài giây, tôi đáp: 
"Anh thật sự không biết là em không rành Linux bởi vì anh thấy rằng, muốn 'hack' mà không thạo các hệ điều hành hiện thời thì không thể 'hack' được. Hơn nữa, Linux là môi trường sản sinh từ 'hack' mà ra và nó có một kho tàng công cụ để 'hack' theo đúng nghĩa của nó. Qua phần trả lời của em ở trên, anh có nhận xét như sau: 

- em chỉ nghe bạn tán kháo là Linux mạnh, em thấy đủ hấp dẫn để bắt tay vào việc cài Linux. Đây là một điều tốt. Tuy nhiên, em bị mất hẳn bước tham khảo (chính em tham khảo chớ không nghe tán kháo) xem Linux mạnh ở chỗ nào. Bởi thế em bị mất định hướng ngay khi vào được Linux và thấy màn hình đen, chữ trắng. 

- Em chưa tự ép mình hơn mức bình thường để tìm hiểu xem đằng sau màn hình đen và dòng chữ trắng ấy có những gì lý thú. Anh thừa biết với khả năng của em và sự thông minh sẵn có của em, em có thể 'vén' được màn hình màu đen đó để đi vào bên trong và thấy được những điều lý thú và bổ ích. Nhưng tiếc là em đã không đủ 'can đảm' và 'kiên nhẫn' để thực hiện. 

Quay về với chuyện 'thâm nhập' và 'hack' em có thấy rằng, để 'hack' được server mà anh đánh cá với em, em phải hiểu rõ Linux không? Vậy, theo em nghĩ, 'hack' khó hay 'thâm nhập' khó? 'thâm nhập' có khó hơn 'hack' không?" 

"cuti" trở nên buồn bã: 
" Anh nói đúng lắm và những lời anh nói còn đau hơn ong chích. Bây giờ em mới thấy 'thâm nhập' không dễ mà 'hack' cũng mênh mông quá. Nếu em hiểu không sai thì anh muốn nói rằng: muốn 'hack' thì phải hiểu rõ mục tiêu mình dự định 'hack', phải không ạ?" 

Tôi trả lời: 
"Chính xác!" 

"cuti" trả lời với vẻ thiếu phấn khích thấy rõ: 
"Vậy có nghĩa là trước khi em muốn 'hack' Linux em phải thành thạo Linux, muốn 'hack' Windows em phải thành thạo Windows. Nếu chưa thành thạo thì em phải học từ đầu đến cuối. Hu hu, vậy đến đời nào, kiếp nào em mới 'hack' được bây giờ?" 

Tôi đáp lại một cách ngắn gọn: 
"Cho đến khi nào em có thể!" 

"cuti" than thở: 
"Anh không có cách nào khác sao? Em thấy trên các diễn đàn bày cách 'hack' đủ kiểu, đủ cỡ. Có những trường hợp làm được, có những trường hợp thử hoài chẳng có kết quả. Nhưng ít ra những trường hợp thành công thì cũng là cách 'hack' có kết quả vậy? Những cách này em đọc vào thấy ù ù, cạc cạc nhưng làm vẫn được mà em cũng đâu cần phải học cho có ngọn ngành như anh nói đâu?" 

Tôi cười đáp: 
"Em nói như thế là một lần nữa muốn sa vào cõi 'tẩu hoả'. Anh hỏi lại, em muốn 'hack' hay em muốn 'thâm nhập'? em muốn thật sự học hỏi hay em chỉ muốn thấy kết quả ngay lập tức? Những dạng bày cách 'hack' mà em thường thấy trên các diễn đàn cũng giống như tin tức trên báo chí hàng ngày vậy. Nó nóng hổi, mới toanh sáng nay nhưng sáng mai nó sẽ cũ kỹ, lỗi thời. Thật sự anh nói hơi quá nhưng dùng hình ảnh nhật báo để so sánh với các 'chiêu' hack trên các diễn đàn không khác nhau mấy. Thử nghĩ xem, em thâu thập và trang bị mọi thứ từ một bài bày cách 'hack' nào đó. Em sẽ có 2 lựa chọn: 

- thử 'thâm nhập' và 'hack' vào chính máy chủ nào bị lổ hổng (và được dùng làm mục tiêu trong nội dung bài chỉ cách 'hack') --> cách này chán phèo vì máy chủ đó đã bị nát như tương. Em 'thâm nhập' để xem 'rác' chớ chẳng còn gì lý thú. 

- thử tìm và 'thâm nhập' một máy chủ nào đó bị lổ hổng tương tự. Em bị kẹt. Kẹt chỗ nào? Kẹt ở chỗ em không biết cách nào để tìm ra một máy chủ bị lổ hổng tương tự bởi vì em thiếu mất những kỹ năng căn bản. Cho đến khi em tìm ra được một máy chủ nào đó ưng ý, có thể máy này đã vá lỗi mất rồi. 

Chẳng những thế, có lắm trường hợp em đọc các bài hướng dẫn 'hack' và hoàn toàn mất phương hướng bởi vì hầu hết những người viết các bài này không phải viết theo tinh thần truyền đạt cặn kẽ cho người muốn biết mà dừng lại ở dạng 'tóm lượt' lại những gì họ trải qua. Đó là chưa kể những trường hợp 'tam sao thất bổn', người thứ nhất đọc, thử và làm rồi diễn dịch thành một thứ khác. Người thứ nhì tiếp nối tinh thần này... đến lượt em, em chẳng còn hiểu được bao nhiêu. Điều này cũng phải bởi vì chẳng ai có thể viết một bài hướng dẫn đi từ chuyện căn bản nhất đến chuyện cao cấp nhất cả. Những kiến thức căn bản cần có để 'hành động' là do bản thân mình tạo dựng nên. 

Anh thường thấy các bài hướng dẫn ngầm phỏng định là người đọc phải hiểu rất nhiều chi tiết căn bản và tự mình hình dung ra môi trường của máy chủ bị 'thâm nhập'. Thiếu nền tảng này, người đọc chỉ nhắm mắt mà làm theo bước một, bước hai, bước ba rồi kêu oai oái là... không được." 

"cuti" đâm liều lĩnh: 
"Chà, anh làm em không còn bụng dạ nào cho chuyện hack hiếc gì nữa. Anh làm cho em cảm thấy mình ngu ngốc kinh khủng. Kỳ này chắc em bỏ hết, không thèm học tin nữa." 

Tôi đoán chắc "cuti" nói dỗi, bèn hỏi tới: 
"Vậy lý do gì làm em quyết định theo học ngành tin vậy?" 

"cuti" hăm hở: 
"Anh cũng trong ngành, anh biết mà. Ai theo ngành tin, giỏi ngành tin thì chắc chắn sẽ 'cơm no, bò cưỡi', ra đường mấy 'ẻm' chen nhau chạy theo ". 

À, ra thế, lại thêm một điểm 'nhức nhối' trong suy nghĩ của "cuti", một lý do mạnh mẽ để "cuti" chọn ngành tin. Tôi đáp: 
"Cứ cho ngành tin có 'phép mầu' như thế đi. Em thử tính sơ qua xem mỗi năm có bao nhiêu sinh viên tốt nghiệp ngành tin và có bao nhiêu người được nhận làm trong ngành tin, có bao nhiêu người được ở vị thế 'cơm no, bò cưỡi'? Hẵng khoan tính số lượng người hiện đã và đang làm trong ngành tin và có kinh nghiệm hơn nhiều. Từ con số này, em thử ước tính xem, với kết quả 'bình bình, chẳng hơn ai' thì em có được bao nhiêu phần trăm cơ hội đạt được cái gọi là 'cơm no, bò cưỡi', ra đường mấy 'ẻm' chen nhau chạy theo'?" 

"cuti" im lặng rất lâu, phải đến gần hai phút. Tôi cứ nghĩ cu cậu bị 'rớt mạng' nhưng thật sự không phải thế. Cu cậu vẫn còn online và có lẽ đang nghĩ mông lung. Sau đó, "cuti" mới trả lời: 
"Trời ơi, anh làm em thật sự lo ngại và nhụt chí rồi đó. Vậy em phải làm sao bây giờ?". 

Hẳn nhiên là hồi nãy "cuti" đã nói liều "không thèm học tin nữa". Tôi đoán chắc cu cậu đã hình dung được "con đường chông gai" trước mắt. Đến lúc này tôi mới góp ý "cuti" cú chót một cách nghiêm túc: 
"Nếu em thật sự muốn hỏi ý kiến anh thì thế này. Hãy tạm dẹp sang một bên những trò 'thâm nhập' vô ích kia đi. Chuyên chú vào chuyện học là chính. Chẳng những em cần hiểu những điều mình học được mà còn phải tìm tòi thêm để hiểu rộng và hiểu sâu mỗi vấn đề. Nếu em đạt được kết quả trên 90%, chắc chắn em có nhiều cơ hội thành công hơn. 

Ngay cả nếu em có định hướng theo ngành bảo mật, em phải nắm rất vững những hệ thống máy em cần bảo vệ hoặc cần 'khai thác'. Một khi em nắm vững những cái này, tự nhiên chuyện 'bảo vệ' hay 'khai thác' (thâm nhập và 'hack') trở nên rõ ràng. Nếu em dành thời gian để mày mò những tiểu xảo nho nhỏ, kết quả sẽ đi về đâu? chẳng đi về đâu cả vì chúng chỉ là những tiểu xảo không hơn, không kém. Cho dù em rành rẽ các tiểu xảo này nhưng khi đặt em vào một môi trường có những thay đổi khác, em sẽ không 'khai thác' được vì em bị thiếu mất căn bản, không nắm vững các nguyên tắc cần thiết." 

"cuti" trả lời một cách buồn bã: 
"Đúng là trước giờ em phí thời gian quá. Chắc em phải chấn chỉnh lại. Nhưng em có một thắc mắc. Anh nói là 'muốn thâm nhập và hack thì phải nắm vững hệ thống mình cần thâm nhập và hack', điều này có nghĩa là em phải sử dụng các hệ thống này thành thạo?" 

Tôi đáp: 
"Tất nhiên rồi. Theo anh, 'hacker' là một 'user' có kiến thức rất quảng bác. Không những anh ta (hoặc cô ta) nắm vững cách sử dụng hệ thống (trên bình diện một user) mà còn có khả năng phân tích và thấu hiểu cơ chế làm việc của hệ thống. Nói một cách nôm na, 'user' chỉ cần biết nhấn một nút thì có kết quả gì đó còn 'hacker' thì chẳng những phải biết như thế mà còn biết được hành động nhấn nút ấy đã tạo ra biến cố gì, biến cố này tác động thế nào đến hệ thống, những tác động này tại sao hợp lệ, những tác động này sẽ không được xem là hợp lệ trong những tình trạng nào.... và hơn hết, làm sao để điều chỉnh cho tác động đến nút này luôn luôn hợp lệ (trên quan điểm bảo mật) hoặc điều chỉnh làm sao cho tác động trở nên bất hợp lệ (trên quan điểm khai thác). 

Ví dụ ai đó hỏi em 'làm sao dùng NET USE để truy cập vào một máy khác? (một cách hợp lệ hay bất hợp lệ)' thì tất nhiên để có thể trả lời câu này, em phải nắm rất vững cách dùng NET USE, sau đó em phải hiểu rõ NET USE tác động đến hệ thống thế nào và nếu cần dùng NET USE để 'thâm nhập' thì em phải biết xác định điểm yếu của hệ thống từ các tác động này nằm ở đâu. Để làm được việc này, em phải là một 'user' giỏi và thành thạo Windows. 

Nếu em chỉ vẽ cho ai đó một dòng lệnh NET USE để thâm nhập vào hệ thống chạy Windows chẳng hạn, nhưng lệnh này không tạo kết quả gì cả. Em phải ước đoán được các lý do làm cho lệnh này không thực hiện được. Như vậy, 'thâm nhập' ở đây chỉ dừng lại ở chỗ gõ dòng lệnh nhưng 'hack' ở đây thì đi xa hơn: hiểu rõ dòng lệnh làm những gì đằng sau đó." 

"cuti" gật gù, trả lời với loại ngôn từ rất thịnh hành (với hai chữ "hơi bị" được dùng khá sai lạc về mặt ngữ pháp): 
"Anh lấy ví dụ này... hơi bị hay đó. Vậy, một người thuộc dạng 'script kiddie' như người ta thường nhắc đến thì thuộc dạng 'user' hay 'hacker'?" 

Tôi mỉm cười, trả lời: 
"Dạng 'script kiddie' theo anh là một 'user' nhưng không phải là một 'user' bình thường. 'script kiddie' có thể rành một số tiểu xảo nào đó hơn 'user' bình thường nhưng lại kém kiến thức hơn 'user' bình thường nhiều mặt khác. Chắc chắn 'script kiddie' không phải là 'hacker' vì 'hacker' thật sự là một người không quản ngại khó khăn để tìm cho mình giải đáp, tìm cho mình sự thoả mãn một cách vững chắc thay vì muốn thấy ngay kết quả (mà không chịu khó khổ) như 'script kiddie'. Nói một cách nôm na: 'hacker' tìm ra và thay đổi thái độ làm việc của một nút bấm nào đó, 'script kiddie' chỉ cần bấm nút, chờ kết quả và không cần quan tâm chuyện gì xảy ra sau khi bấm nút." 

"cuti" rên rỉ: 
"Oái, anh đang chửi xéo em đó phải không? . Sao em thấy em giống 'script kiddie' quá. Chắc em đúng là 'script kiddie' rồi . Hu hu, nhưng làm sao để tránh không trở thành một 'script kiddie' vậy anh?" 

Tôi đáp: 
"Em hỏi câu này hơi thừa rồi đó. Anh tin rằng qua hai lần chat với nhau, em đã hiểu cần phải làm thế nào để không trở thành một 'script kiddie'. Có lẽ anh không cần phải tổng kết lại hả? Thử rèn luyện khả năng tổng kết đi em . À mà này, lần trước mình có bàn về chuyện đọc sách và rèn luyện kỹ năng tổng kết, em đã thử nghiệm chưa và thấy thế nào?" 

"cuti" cười gượng gạo: 
"Ùm... em có thử lôi một cuốn e-book ra nghiền ngẫm như chỉ được mấy trang đầu là thấy choáng váng cả mặt mày . Em tự nhủ là để mai xem tiếp nhưng rồi hết chuyện này đến chuyện khác, em vẫn chưa đọc quá ba trang." 

Tôi cười phá lên: 
"Hà hà, đúng là điển hình rookie . Vậy em đọc cuốn gì mà thấy choáng váng cả mặt mày?" 

"cuti" phụng phịu: 
"Thì em nghe theo lời anh nói trên diễn đàn HVA là cuốn TCP/IP Illustrated của Richard Stevens là cuốn để đầu giường nên em tóm ngay cuốn đó thôi. Đâu ngờ nó khó nuốt đến như vậy  " 

Tôi không ngạc nhiên khi "cuti" nhận định như thế, tôi đáp: 
"Ừa, đọc những cuốn 'thuần' như cỡ TCP/IP Illustrated của Richard Stevens thì em phải cần một ít kỹ năng và phải thật sự muốn tìm hiểu thì mới tiêu hoá nổi. Còn không thì nó 'khô như rơm' thì làm sao mà nuốt cho vô? Cuốn này của Richard Stevens dùng để bổ túc, đối chiếu và đào sâu những gì em học ở trường thì rất hay, nếu em nhảy ngang vào và cố đọc thì chỉ dẫn đến chuyện chán nản mà thôi. Ở trường em đã đụng đến TCP/IP chưa?" 

"cuti" trả lời không ngần ngừ: 
"Ở trường hả anh? ở trường có gì mà học? Cái gì cũng đại cương với khái niệm, chán như con gián. Học như vậy biết chừng nào mà thành?" 

Tôi mắng "cuti" ngay": 
"Em đầy mâu thuẩn. Em xem thường mấy thứ 'đại cương' với 'khái niệm' nhưng không có chúng thì làm sao em có nền tảng để đi sâu hơn? Từ những thứ 'đại cương' và 'khái niệm' này, em có thể tham khảo sách vở, tài liệu và trau dồi cho mình thêm kiến thức. Không những đây là chuyện bổ ích cho bản thân em mà đây cũng là điểm để đo cái khác biệt giữa một sinh viên 'thường thường bậc trung' và một sinh viên 'xuất sắc' đó. Hèm, con đường đi tới chỗ 'cơm no, bò cưỡi' e hơi chông gai đó em!" 

"cuti" nhăn nhó: 
"Trời, hôm nay đúng là xuất hành không coi ngày hay sao đó. Từ nãy giờ em bị sao quả tạ của anh 'chiếu' liên hồi luôn  " 

Tôi cười đáp: 
"Vậy em muốn 'sao quả tạ' không chiếu chớ gì? dễ ợt thôi mà. Bây giờ mình bàn chuyện 'hack gunbound' hay 'chôm Yahoo password' là hết 'sao quả tạ' " 

"cuti" cuốn quýt: 
"Không, không, em chỉ đùa tí thôi mà. Thật tình nói chuyện với anh, em thông được nhiều điều lắm. Chỉ có điều 'cái đầu khổ sở' của em nó làm việc chậm như bộ vi xử lý 486 cũ kỹ nên chắc em cần phải có thời gian để từ từ mà 'xử lý'. Nói chuyện với anh, em bị nhiều cú đau đầu lắm á nhưng không hiểu sao nó... hơi bị phê, hì hì." 

Tôi cười: 
"Lại cái kiểu nói 'hơi bị...' dùng từ gì kỳ cục vậy? 'hơi bị' là dạng thụ động dùng để chỉ cho điều gì đó không được hay mà sao lại đi trước một từ như 'phê', 'hay' vậy? 'hơi bị hay' rồi 'hơi bị phê' nghe nó trái tai làm sao đó!" 

"cuti" cười nhanh nhẩu: 
"Thôi anh ơi, anh quá cổ lổ sĩ rồi, thời nay mọi người dùng từ kiểu này không anh à. Nhưng mà đừng nói là anh lại chuẩn bị cho em một bài về 'ngữ pháp' đó nha. Hì hì, em bị 'quả tạ' gần trúng thực rồi đây." 

Tôi đáp: 
"Thôi, anh chỉ nhận xét vậy thôi, dính vô mấy chuyện ngữ pháp tiếng Việt, tiếng Việt trong sáng... coi chừng 'tẩu hoả' dạng khác bây giờ. Thế này, em hiện đang học cái gì ở trường và em nghĩ là hiện thời em thích tham khảo chuyện gì nhất. Có cần e-book hay tài liệu gì, anh cố tìm cho mà đọc. Nhưng quan trọng là phải khởi đầu bằng cái gì đó vừa sức em và đừng 'khô như rơm' thì mới nuốt nổi." 

"cuti" trả lời ngay: 
"e-book hả anh? em có hàng... tấn. Nghe ở đâu có e-book là em hì hụi down về cho được. Em có chừng 2 gig e-book để mục miễu trong máy á. Có cái em chưa bao giờ ngó qua, có cái xem có vẻ hay hay nhưng có lẽ nội công còn non nớt quá nên chưa bao giờ luyện qua hết tầng một (chương một) của bộ bí kíp nào hết. Anh muốn em đọc cuốn nào, em lục cuốn ấy mà đọc thôi." 

Tôi cười một mình, lắc đầu và trả lời "cuti": 
"Lại thêm một điển hình khác của 'rookie'. Nghe thấy ở đâu có e-book thì cố mà download về rồi bỏ đó. Anh không thể 'muốn' em đọc cuốn nào mà phải chính em quyết định em 'muốn' đọc cuốn nào. Chuyện quan trọng lúc này là cách làm quen với sách kỹ thuật chớ chưa cần nội dung cao siêu cỡ nào hết. Miễn sao em thích đề tài nào thì chọn một trong mấy cuốn em có mà thử thôi. Cái quan trọng là phải tự kỷ luật, đừng hứa hẹn cho ngày mai. Chắc cũng gần đến giờ anh dzọt rồi. Để khi khác mình tiếp tục vậy hả?" 

"cuti" nằn nì: 
"Khoan đã anh, cho em hỏi thêm một tí nữa thôi. Anh 'bắt' em đọc sách nhưng anh chẳng chịu cho em một tí 'khẩu quyết' gì để 'đả thông' hết làm sao em nuốt vô cho nổi? . Anh bày em cách đọc và tổng hợp như anh nói đi. Hồi đó đi học, anh có phương pháp gì vậy?" 

Tôi chậm rãi đáp: 
"Cái thời 'hồi đó' của anh có lẽ khác cái thời 'hồi nay' của em nhiều lắm. Thời đó chưa có cái gọi là 'google', Internet cũng chưa có luôn. Modem thời đó lúc anh mới làm quen computer là 4800 bauds còn sách và tài liệu thì quý như... vàng. Muốn mua một cuốn sách phải tằng tiện cả tháng trời hoặc hơn cho nên có một cuốn sách trong tay là 'nghiến' từng dòng, từng chữ. Bởi hai 'thời' khác nhau quá, anh chỉ có thể góp ý với em thế này: 

- sách vở, tài liệu có hai dạng chính: sách giáo khoa và sách tham khảo. Cách đọc và 'tiêu hoá' hai loại này khác nhau. 
- sách giáo khoa là để học các kiến thức em gọi là 'đại cương và khái niệm'. Loại sách này em phải học, hiểu và tiếp nhận nó như một thứ kiến thức căn bản và cần thiết. 
- sách tham khảo là để đối chiếu, mở rộng, đào sâu những thứ em đã học được từ sách giáo khoa. Các e-book của em có chắc hầu hết là sách tham khảo. 
- vậy, để đọc được sách tham khảo em phải có căn bản trước không thì em bị 'bọng' và sẽ thấy 'khó nuốt' bởi vì loại sách này viết với ngầm định là em đã nắm kiến thức căn bản. 

Riêng phần 'khẩu quyết' thì đại loại là thế này: để làm quen với việc 'đào sâu', em nên tự đặt cho mình các câu hỏi rồi tìm cách tự trả lời. Nếu em chưa quen 'tự đặt câu hỏi' thì em có thể dùng vô số các câu hỏi được đặt ra xung quanh em. Thời nay diễn đàn CNTT mọc lên như nấm, có bao nhiêu là câu hỏi từ dạng đơn giản nhất đến dạng phức tạp nhất. Em thử chọn một vài câu hỏi rồi hình thành cho mình câu trả lời sao cho đầy đủ nhất, hữu lý nhất. Câu trả lời tìm ở đâu? từ các sách tham khảo em có, từ 'google', từ các search engines.... Ví dụ, ai đó phát biểu một câu như sau: giao thức TCP là một giao thức stateful và UDP là một giao thức stateless. Em thử tìm hiểu xem lý do tại sao câu này được phát biểu như thế? có những lý do nào làm cho TCP thuộc dạng stateful và UDP thuộc dạng stateless? Tham gia sinh hoạt trên một diễn đàn một cách nghiêm túc cũng là một phương pháp hay cho việc 'hỏi' và 'trả lời'. Nếu em cần một câu trả lời thấu đáo cho chính mình thì chính câu trả lời này sẽ là câu trả lời rất giá trị cho người khác." 

"cuti" có vẻ không lấy làm hào hứng: 
"Chà, xem có vẻ căng đây. Nhưng để em cố xem sao. Đúng là em có cái tật qua quít cho xong nên chẳng có cái gì cho ra cái gì cả. Em biết anh đang truyền đạt cho em một lối suy nghĩ khác? Em thấy con đường 'tu luyện' có vẻ đầy chông gai như anh đã nói. Nhưng em có thắc mắc là làm sao mình có thể nhớ một trăm thứ, một ngàn thứ được?" 

Tôi đáp: 
"Ừa, chữ 'truyền đạt' hơi quá, anh nghĩ là 'góp ý' thì đúng hơn. Anh đang 'góp ý' em để hình thành cái gọi là nền tảng. Phải có nền tảng rồi thì mới đi tiếp được. 

Riêng chuyện nhớ thì em không thể nhớ một trăm, một ngàn thứ ngay lập tức được nhưng nếu em thật sự hiểu một thứ nào đó, nó sẽ vĩnh viễn là của em vì nó đã thuộc về kiến thức của em. Lý do 'cần phải ngọn ngành' cũng đi từ đây ra thôi, nó giúp em 'thật sự hiểu'. Còn chuyện nhớ nhanh, nhớ chậm, nhớ lâu hay nhớ mau thì có phần nào phụ thuộc vào khả năng tự nhiên của mỗi người nhưng không có nghĩa là không thể rèn luyện để nâng cao khả năng này cho mình. Em thử đi rồi lần sau cho anh biết cách em đọc thông tin của một chương ra sao, cách em hiểu nó như thế nào, cách em tóm lược nó (để nhớ) ra làm sao... rồi anh sẽ góp ý cho. Bây giờ anh phải đi, nếu tiện mình sẽ liên lạc sau hả? Chào cuti." 

"cuti" không quên hóm hỉnh: 
"Chào anh già khó tánh " 

Và tôi logoff. 

6. "Vật vã": 
Điều lạ đã xảy ra. Suốt tuần lễ này tôi không hề nhận được một thông điệp nào từ "cuti". Tôi không thể đoán nổi "cuti" bận học hành, thi cử hay cu cậu đã chán nản "con đường chông gai". Dù gì đi chăng nữa, tôi đã có ít nhiều cảm mến "cuti" ở cái tính thật thà và hóm hỉnh của cu cậu. Một phần nào đó thầm kín trong lòng, tôi mong "cuti" đừng bỏ cuộc. 

Thế rồi, sang tuần lễ thứ hai, tôi nhận được một thông điệp ngắn gọn và bí hiểm từ "cuti": 
"Chào anh già khó tánh. Em đang vật vã đây nhưng cũng chưa đến nỗi 'lực cùng, sức tận'. Em sẽ cho anh biết kết quả thử nghiệm của em". Tôi lẩm bẩm "chà, có gì mà bí hiểm quá vậy? 'thử nghiệm'? chắc cu cậu đã táy máy cái gì đây.". Tôi thấy vui vì thông điệp này chứng tỏ cu cậu chưa bỏ cuộc nhưng lại thắc mắc không hiểu lý do tại sao "cuti" lại trở nên tiết kiệm ngôn từ đến thế. 

Tôi tiếp tục lao vào công việc suốt những ngày còn lại của tuần lễ. Mãi đến chiều thứ Bảy, rảnh rỗi một tí, tôi log vào YIM để xem các "offline message". Như thường lệ, tôi nhận hàng đống thông điệp và thong thả trả lời từng cái một. Quả nhiên có vài cái thông điệp của "cuti". Lần này "cuti" có vẻ rất khẩn trương: 
"Ui, anh già khó tánh co đó không? Em bó tay rồi á. Anh có online cho em biết với" 

Một thông điệp khác: 
"Cuối tuần chắc anh rảnh hả? Lúc nào tiện, cho em biết. Em sẽ online cuối tuần để nhờ anh chỉ cho em thêm vài 'khẩu quyết'.". 

Tôi chậc lưỡi: "Chà, cuti này làm gì mà có vẻ bí hiểm thật." Tôi đoán chắc cu cậu đang táy máy cái gì đây như bị tắc tị. Tôi bèn gởi cho "cuti" một thông điệp: 
"Hello cuti, anh hiện đang online. Có cần gì thì vào mà hỏi. Anh sẽ online từ 2 giờ chiều đến tối đa là 3 giờ." 

Không đầy một phút, tôi nhận được thông điệp của "cuti": 
"Dạ, em đây. Em ngồi chờ từ sáng đến giờ á." 

Tôi cười, đáp: 
"Hì hì, rảnh rỗi quá hả? 'nằm' trên Internet thường trực? Mà này, em cũng chơi trò 'invisible' như anh hả? Có chuyện gì mà có vẻ khẩn trương vậy?" 

"cuti" rối rít: 
"Dạ, em chuyển sang 'invisible' để khỏi bị quấy rầy. Cả hai tuần qua em chả chat với ai cả mà gầm đầu vào để tìm hiểu lời thử thách của anh." 

Tôi ngạc nhiên: 
"Ủa, 'lời thử thách' nào của anh vậy?" 

"cuti" nhanh nhẩu: 
"Trời, mới có hai tuần mà anh quên béng hết rồi sao? Cái thử thách anh nói là anh cho em IP, account của một Linux box để em vào hack đó. Anh còn nhớ không?" 

Tôi bật cười nhưng không kém phần ngạc nhiên. Quả tôi có 'thách' "cuti" thật nhưng đó chỉ là một chi tiết trong cuộc đàm thoại để làm rõ quan điểm của tôi mà thôi. Không ngờ "cuti" tiếp nhận vấn đề một cách nghiêm túc và nghiêm trọng. Tôi đáp: 
"À, tất nhiên là anh nhớ chớ. Nhưng đó đâu phải là điều anh thách thức một cách chính thức đâu? Đó chỉ là một cách làm rõ quan điểm thôi mà em. Hơn nữa, anh nhớ là em chịu thua rồi mà? " 

Không ngờ "cuti" trả lời như sau: 
"Dạ, em thua thật nhưng sau khi nói chuyện với anh lần thứ nhất, rồi đến lần thứ hai. Mọi điều anh em mình trao đổi em đều ghi nhớ và cố gắng suy gẫm. Có những điều em suy không ra, nhưng cũng có nhiều điều em thấy thấm lắm. Cho nên, những điều anh nói em đều cho rằng phải có một ẩn ý nào đó. Hơn nữa, quả thật anh đã 'thách thức' em mà. Em đã chịu thua nhưng sau đó nghĩ ngợi lại em thấy ấm ức chịu không nổi. Thế là em bắt tay vào thử nghiệm." 

Hơi ngạc nhiên, tôi hỏi tiếp: 
"Rồi sao nữa?" 

"cuti" tiếp tục: 
"Dạ. Em chỉ có một con Pentium 3 mà thôi. Lần trước em học đòi cài đặt Linux, xém chút nữa là tiêu cái Windows của em. Bây giờ em muốn học Linux nên em... vòi mẹ em tiền để sắm một con Pentium 4. Em viện lý do là em phải học mạng, cần hai máy nên rốt cuộc mẹ cho tiền sắm thêm một con P4. Thật là thích. Con này mạnh nên em mang cái đĩa chạy Windows qua và dùng con cũ để cài Linux." 

"cuti" đưa tôi đi từ ngạc nhiên này đến ngạc nhiên khác, tôi hỏi tiếp: 
"Thế rồi sao? 

"cuti" hớn hở đáp: 
"Em tậu con P4 chỉ trong vòng 2 ngày là có và đến ngày thứ 3 thì em đã có con P3 cũ để vọc quậy với Linux. Em mua một bộ đĩa RedHat 9 và tham khảo đống e-book của em để cài lại con Linux này. Ròng rã mấy ngày trời, em hoàn tất con Linux. Có hôm em thức đến mấy giờ sáng, ngủ chập chờn một tí rồi thức dậy đi học." 

Tôi thầm cảm phục cái "bướng bỉnh" và quyết tâm của "cuti". Không ngờ cu cậu quá nghiêm trọng với chi tiết "thách thức" kia. Tôi hỏi tiếp: 
"Vậy, cài xong con Linux kia, em dự định làm những gì?" 

"cuti" đáp tỉnh khô: 
"Trời, vậy mà anh không biết sao? Em định tạo dịch vụ web trên con Linux này rồi tự 'hack' nó để thay đổi trang chủ y hệt như lời anh thách thức em đó. Nhưng cài xong em chẳng biết thằng apache làm việc ra sao nữa. Khi cài, em chọn cài tất cả nên có tùm lum tá lả dịch vụ trên máy chủ này. Em lại lọ mọ tham khảo cuốn e-book nói về apache để xem nó làm việc ra sao. Anh cũng biết là tiếng Anh của em dỏm số một nên nhiều lúc tham khảo mấy tài liệu kia choáng váng cả mặt mày. Nhưng rốt cuộc em cũng đã hoàn tất được thằng apache rồi. Mất của em ròng rã mấy ngày trời á." 

Tôi cười rộ vì lối suy nghĩ "thẳng ruột ngựa" của "cuti" nhưng đồng thời cảm thấy mến cu cậu nhiều hơn. Mến ở chỗ cu cậu không chỉ "nói miệng" mà dám gát qua hết mọi chuyện để tạo ra một môi trường để tự thử nghiệm và kiểm chứng. Tôi đáp: 
"Tốt lắm đó 'cuti'. Em dám hy sinh thời gian và những 'trò chơi' thông thường để tự hình thành cho mình một cái Linux server trong khoảng thời gian ngắn như vậy thì quả thật xuất sắc. Anh thật lòng hoan nghênh em đó " 

"cuti" hồ hởi: 
"Anh nói thật sao? ặc ặc, hu hu, sướng quá đi mất. Em cứ tưởng anh sẽ mắng cho em một chặp vì tội phí thời gian cài một con Linux để chứng minh một chuyện chẳng là cái gì hết. Ặc, ặc... em tưởng anh thật sự là 'anh già khó tánh' nhưng không ngờ anh cũng biết khen đó chớ, hì hì." 

Tôi đáp: 
"Trời, sao không khen được "cuti"? Nếu em làm một chuyện gì đúng và có giá trị thì phải được khen mới phải chớ? Anh khen vì anh thấy em không chỉ 'nói miệng' cho xong chuyện nhưng em đã thật sự bắt tay vào làm một việc cụ thể. Chưa biết kết quả công việc đó như thế nào nhưng ở giai đoạn tìm hiểu với một người như em, theo anh, em đã đạt một bước đầu hết sức quan trọng: học đi đôi với hành. Cái này cũng chứng tỏ là em có đủ ham muốn để tìm hiểu và làm sáng tỏ điều mình thắc mắc. Thật sự, anh thấy rất vui khi nghe chuyện này." 

"cuti" rên rỉ: 
"Hic hic, hơn một tuần qua em 'phờ phạc' với con Linux này. Giờ được khen tự nhiên bao nhiêu mệt nhọc biến đi đâu hết. Anh là một người rất 'nguy hiểm'! hì hì. Lý do em muốn gặp anh là vì em thấy muốn đổi thông tin trên trang chủ của website quá đơn giản. Em nghĩ là anh đố 'mẹo' em gì đây. Em nghĩ nát óc mà không ra lý do. Anh chỉ cho em với." 

Tôi cười, hỏi lại: 
"Thứ nhất, tại sao nghĩ anh là người nguy hiểm? Thứ hai, em điều chỉnh thông tin trên trang chủ của website em tạo ra bằng account nào và bằng công cụ nào vậy?" 

"cuti" nhanh nhảu: 
"Thứ nhất, anh là người 'nguy hiểm' vì anh có khả năng 'hành hạ' bộ não của em rồi sau đó mới khen một tiếng. Cú khen này thấy 'phê' hơn các cú khen thông thường. Theo em, như vậy là... 'nguy hiểm' . Thứ nhì, ý anh account nào là sao? khi em cài con RH9 này nó cho phép em chọn mật mã của account root cho nên em chỉ dùng root từ bữa giờ thôi. Đâu có account nào khác đâu? Còn công cụ thì em thấy có cái Gnu Text Editor gì đó nên em dùng vậy thôi." 

Tôi đáp: 
"À ra vậy. Thứ nhất, nếu em nghiệm ra được anh là người 'nguy hiểm' thì không chừng em còn 'nguy hiểm' hơn anh. Thứ hai, em nghĩ lần trước anh đánh cuộc với em chuyện sửa nội dung một trang web trên Linux server, anh sẽ cho em root account sao? . Nếu vậy còn gì vui nữa. Anh chỉ cho em một account như một người dùng bình thường trên server này thôi. Còn chuyện em dùng Text Editor gì đó thì có nghĩa là em chạy trên môi trường GUI hả?". 

"cuti" thắc mắc: 
"Vậy root account với account của người dùng bình thường khác nhau thế nào anh? Và anh nói chuyện GUI, có phải ý anh là làm việc trên giao diện đồ hoạ phải không?" 

Thấy rõ "cuti" còn hổng nhiều điểm căn bản, tôi ngẫm nghĩ cách tốt nhất để giải thích cho cu cậu. Sau đó tôi trả lời: 
"Anh nghĩ em rành Windows nên anh tạm dùng Windows để em dễ liên tưởng. Thế này, trên Windows, Administrator có chủ quyền cao nhất, có nghĩa là ai dùng account này có thể làm bất cứ chuyện gì trên máy. Trên *nix nói chung, root chính là Administrator vậy. Thông thường ít có ai (kinh nghiệm với *nix) mà dùng root account để làm việc bởi vì quá nguy hiểm. Nguy hiểm ở chỗ nếu 'lỡ tay' thì không cứu vãn được vì root có uy quyền tuyệt đối. Bởi thế, admin của server thường tạo các account thông thường cho người dùng thông thường. Chỉ có những trường hợp cần thiết thì mới chuyển sang su (super user mode - hay còn gọi là root mode). Trong trường hợp của em, em phải tạo thêm một account bình thường cho người dùng rồi mới dùng account này để 'hack' thì mới gần với hoàn cảnh chuyện anh đánh cuộc với em. 

Riêng chuyện GUI thì thế này. GUI giúp cho những người mới làm quen *nix thấy dễ dàng và nó rất tốt nếu em có thể dùng nó như một dạng desktop để làm việc. Tuy nhiên, trong trường hợp anh cho em một account trên một Linux server nào đó để 'hack' thử, em thử nghĩ xem, em sẽ login server này bằng cách nào?" 

"cuti" đáp ngay: 
"Em nghĩ là phải dùng một dạng 'pcanywhere' hay 'terminal service' để log vào chớ sao nữa anh?" 

Tôi cười đáp: 
"Hì hì, trên *nix làm gì có 'pcanywhere' hay 'terminal service'? Thông thường, để bảo mật, những dạng dịch vụ cung cấp khả năng truy cập theo dạng GUI (trên *nix còn gọi là X) hoàn toàn bị loại bỏ vì rất dễ bị 'khai thác'. Nếu vậy, theo em thì mình log vào bằng cách nào?" 

"cuti" ngẫm nghĩ rồi đáp: 
"Bằng telnet phải không anh?" 

Tôi đáp: 
"Gần đúng! ngày trước dịch vụ telnet được dùng rất phổ biến nhưng ngày nay rất hiếm thấy máy chủ cung cấp phương tiện truy cập đến dịch vụ telnet vì lý do thông tin trao đổi giữa telnet client và telnet server hoàn toàn là 'cleartext' nên dễ bị 'sniff' (kể cả password). Thay vào đó, ngày nay người ta dùng ssh là chính." 

"cuti" hớn hở: 
"A, em có nghe đến SSH rồi nhưng chưa hề mó qua nó. Vậy mình truy cập vào bằng đường SSH có nghĩa là mình chỉ có một cửa sổ đen ngòm để làm việc phải hông anh?" 

Tôi xác nhận: 
"Đúng thế, em sáng dạ lắm . Mình chỉ có một cửa sổ 'đen ngòm' để làm việc. Muốn có nhiều cửa sổ thì mình phải login nhiều lần. Rồi, nếu mình login qua ssh và có cửa sổ 'đen ngòm', vậy liệu em có thể dùng "Notepad" gì để để điều chỉnh hồ sơ trên website không?" 

"cuti" liến thoắn: 
"Hi hi, anh ghẹo em hoài. Lúc này không có GUI thì làm sao mà 'Notepad'? Vậy mình phải dùng cái gì để thực hiện chuyện điều chỉnh đây anh?" 

Tôi cảm thấy phải đi chầm chậm với "cuti" không thì cu cậu choáng ngợp thì hỏng hết, bèn đáp: 
"Ừa, khi làm việc với *nix, một trong những công cụ căn bản và không thể thiếu là vi hoặc emacs. Em phải học cách sử dụng một trong hai công cụ này. vi thì phổ biến và đơn giản hơn, emacs thì có server không dùng nhưng nó cao cấp hơn. Anh nghĩ em nên làm quen với vi trước." 

"cuti" reo lên: 
"Hi hi, vi? cái tên gì ngộ thật  Em chưa từng nghe qua, đừng nói chi là đụng đến nó. Vậy mình có cần cài gói vi không anh?" 

Tôi đáp: 
"Không em, vi có sẵn khi em cài Linux rồi đó vì nó là một trong những gói căn bản nhất. Em xem thử trong mớ e-book của em có cuốn sách nào nói về vikhông? anh nhớ mang máng là O'Rilley có một cuốn chuyên chú về vi đó. Nếu không có, cho anh biết để anh tìm vài cái link trên Internet chỉ cách học và thực tập vi cho." 

"cuti" trả lời ngay: 
"Dạ, chờ em một tí thôi, con Windows của em ngay trên bàn, để em xem liền thử có cuốn e-book này không." 

Tôi ngồi chờ "cuti" và cố hình thành một phương án ngắn gọn để 'đưa' "cuti" đi từ chỗ thiếu lớp lang đến chỗ có lớp lang hơn. Cái khó là vấn đề thời gian và phương tiện liên lạc. Tôi thì rất ít có thời gian để vào YIM. Ngay cả vào YIM và chat bằng text thì chẳng 'hiệu xuất' vì chậm quá. Tôi thầm nhủ "thôi thì cứ từng bước mà mần, xem thử cuti kéo dài được bao lâu rồi tính tiếp". Sau vài phút, "cuti" gởi cho tôi một thông điệp khác: 
"Anh già khó tánh ơi, còn đó hông? Em đã tìm ra được cuốn e-book của O'Rilley anh nói rồi đó. Em nghĩ đúng là nó vì trong đống e-book của em chỉ có một cuốn nói về vi. Hi hi, bây giờ em mới thấy quý cái 'kho' ebook của em. Trước giờ cứ để nó một góc mà chẳng biết tận dụng nó." 

Tôi đáp: 
"Tốt lắm. Sẵn có hai máy, em mở cái ebook đó trên Windows và dợt vi trên Linux đi. Nhưng nhớ đừng tự dồn ép quá mà không tốt và dễ bị nản. Thức ăn dành cho não bộ cũng như thức ăn dành cho... bộ lòng . Em phải ăn uống điều độ thì nó mới tiêu hoá và tiếp thu được. Ráng dồn cho nhiều vào thế nào cũng bội thực cho mà xem. À mà này, em đã nắm khái niệm 'root' account và account cho người dùng bình thường chưa?" 

"cuti" hóm hỉnh: 
"Đơn giản quá mà anh. Anh cứ dùng Windows giúp em liên tưởng Linux thì em hiểu liền liền thôi. Còn chuyện dồn ép thì anh đừng lo. Hễ em thích thì bao nhiêu cũng được hết. Anh thấy không, gần hai tuần qua em vật lộn với con Linux, vừa đọc tài liệu vừa ráng hiểu vậy mà cũng cài được con Linux mà. Em chẳng thấy mệt gì cả mà lại thấy thích vì lần đầu tiên em cài nó vì có mục đích rõ ràng " 

Tôi cười và đáp: 
"Thôi đi, đúng ra anh không nên dùng Windows để giúp em liên hệ với Linux bởi vì chúng khác nhau rất nhiều. Khi làm việc với Linux nên tránh liên hệ và so sánh đến Windows vì nó có thể dẫn đến những sai lạc căn bản. Lần sau anh không liên hệ kiểu này nữa đâu. Còn chuyện cài được con Linux thì anh thấy tốt lắm. Em đã vượt qua được một bước rất quan trọng cho những bước về sau. Tuy nhiên, anh góp ý với em chuyện điều độ là vì anh không muốn em lao vào thật nhanh rồi rút lui thật nhanh vì bị choáng ngợp. Nếu lâm vào tình trạng này không những uổng phí mà còn nguy hại nữa bởi vì lần sau em sẽ e ngại vì có ấn tượng không tốt từ lần trước và bởi thế em sẽ rất khó quay lại mức bền bỉ và quyết tâm cần thiết để thành công." 

"cuti" trả lời: 
"Vậy thì em nghe theo lời anh. Em chỉ sợ tự nhiên giảm 'tốc độ' lại một cách đột ngột sẽ làm em mất trớn thôi. Vậy em phải bắt tay vào học vi phải không anh? Anh nghĩ bao lâu thì em sẽ thành thạo với công cụ này?" 

Tôi đáp: 
"Anh nghĩ không lâu đâu. Căn bản thì vi chỉ có vài chục lệnh để di chuyển và sửa đổi nội dung hồ sơ. Phần khó là phần dùng regex để tìm 'pattern' và thay thế 'pattern'. Tuy nhiên, em có thể 'nâng cấp' từ từ. Cái quan trọng là phải chịu khó 'dợt' vi bằng cách làm việc thử trên các hồ sơ; đọc sách 'khan' mà không thử thì không cách gì mà nhớ hết và thông thạo được. 

À, có một chi tiết anh muốn nhắc em về chuyện em muốn thực hiện vụ đánh cuộc của mình. Em nên nhớ là em phải thực hiện các thao tác từ xa và chỉ dùng một cửa sổ 'đen ngòm, chữ trắng'. Em phải thử login máy Linux server của từ một máy khác. Trong trường hợp của em thì nên logon từ máy Windows và nên dùng Putty, một ssh client rất hay và miễn phí. Thử vào google và tìm 'Putty' thì sẽ thấy đường dẫn để download công cụ này. Nếu em đã chọn chế độ 'cài tất cả' khi cài Linux, anh nghĩ là em đã có sẵn dịch vụ SSH trên máy Linux rồi đó." 

"cuti" cười, đáp: 
"Hì hì, anh cẩn thận quá. Em biết em phải làm gì mà." 

Tôi vẫn kiên trì: 
"ok, nếu em biết em phải làm gì, em tóm tắt những điểm em phải làm gì anh xem thử? " 

"cuti" trả lời ngay: 
"Đơn giản như... đang giỡn. Nè, em phải: 
- download thằng Putty về máy Windows 
- dùng nó để truy cập vào máy chủ Linux 
- thử thay đổi nội dung trang web đang có trên máy chủ Linux" 

Tôi đáp: 
"Còn thiếu! dùng Putty để truy cập vào máy chủ Linux bằng một account bình thường. Điểm này cực kỳ quan trọng." 

"cuti" rú lên: 
"Oái, chuyện đơn giản vậy mà em vẫn sót một chi tiết quan trọng. Không sao, để em save nội dung anh em mình chat và đọc lại thì chắc ăn, không sót gì đâu. Ơ, nhưng mà muốn truy cập và máy chủ Linux bằng một account bình thường thì phải có một account bình thường phải không anh? Nếu vậy mình phải tạo thêm account bình thường. Tạo account bình thường là làm sao vậy anh?" 

Tôi cười: 
"Sao hỏi anh? Cuốn cẩm nang Linux của em đâu? Tạo account trên *nix cũng được xem là một trong những thao tác 'hack' đó và không có cuốn sách chỉ dẫn dùng Linux nào lại không nói đến chuyện này cả. Em thử tìm cách 'hack' hợp lệ bằng cách tạo 'user account' đi ." 

"cuti" rên rỉ: 
"Ặc ặc, em muốn anh chỉ liền để đỡ mất công đọc sách và có ngay một account để mà quậy. Vậy mà anh cũng không chịu chỉ dùm." 

Tôi tìm cách khuyến khích "cuti" và đáp: 
"Hì hì, anh chẳng hẹp hòi với cái lệnh thêm user account vào máy đâu. Tuy nhiên, anh không chỉ em ngay lập tức bởi vì em phải làm quen với những thao thác đơn giản và căn bản này thì về sau em mới có thể 'hack' được. Cái đơn giản và căn bản luôn luôn có giềng mối sâu xa với cái phức tạp và nâng cao. Cho nên em cần chịu khó bước đầu." 

"cuti" vui vẻ trả lời: 
"Không có gì đâu anh, em tìm hiểu nó được mà. Em chỉ có thắc mắc là tại sao anh rất kiên trì với chuyện bắt em phải làm quen với việc tạo account thôi. Chắc anh phải lý do gì đó phải hông?" 

Tôi đáp: 
"Ừa, em tinh ý lắm. Chắc chắn là anh có lý do. Lý do khá rõ ràng như sau nếu em thắc mắc. Bởi lẽ em phải đọc phần hướng dẫn cách tạo user account, chắc chắn nó sẽ kèm thông tin về tài khoản và quyền hạn của account. Nó lại trực tiếp dính đến nhóm người dùng (group) và cả password, thư mục nhà (home directory), shell ấn định cho người dùng và chủ quyền truy cập trên filesystem.... Đây là những kiến thức căn bản không thể thiếu được. Nếu em là người có 'máu' system admin thì em sẽ tò mò tìm hiểu thêm cơ chế lưu trữ password của Linux thế nào, cơ chế xác thực người dùng (authentication) ra làm sao. Nếu em là người có 'máu' coder thì em sẽ tò mò tìm hiểu xem khi tài khoản được tạo ra, nó sẽ dính líu đến các system calls nào, khi người dùng xác thực để login thì có những system calls nào cần dùng? thuật toán nào dùng để băm (hash) password?.... Những kiến thức này là những kiến thức sẽ làm em "vật vã" trong giai đoạn đầu nhưng không thể thiếu được nếu như em muốn làm 'hacker' đúng nghĩa." 

"cuti" cảm thán: 
"Chà chà, nghe mà phát khiếp. Thôi anh chậm chậm lại một chút hông thì em 'nuốt' không kịp. Ý anh là em phải nhìn vấn đề từ nhiều phương diện? nhìn vấn đề như một system admin cũng như một coder? Và tại sao mình cần phải hiểu rõ một cách tinh tế như vậy anh?" 

Tôi cười đáp: 
"Anh đoán trước thế nào em cũng thắc mắc những điểm này. Để anh giải thích thêm một tí nữa. Hãy thử dùng một ví dụ 'hiện thực' hơn một tí: em vào được một dinh thự, trong dinh thự có một cái két sắt chứa bản đồ dẫn đến một kho tàng khổng lồ. Việc em cần làm là lấy cho được tấm bản đồ này. Có hai lựa chọn: 1) dùng thuốc nổ để phá tan cái két sắt (có thể làm hỏng cả cái bản đồ và tạo tiếng ồn, để lại dấu tích) 2) nghiên cứu cách mở ổ khoá của cái két sắt này (để mở nó ra một cách nhẹ nhàng, êm thấm, không có vết tích, không có tiếng ồn). Tất nhiên cách thứ nhất nhanh hơn và có nhiều hiểm hoạ hơn cách thứ nhì. Trong khi đó, cách thứ nhì khó khổ hơn, mất thời gian hơn nhưng ít hiểm hoạ hơn. Hơn nữa, sau khi nghiên cứu kỹ lưỡng cách mở khoá két sắt, tự nhiên các két sắt khác trở nên không còn khó khăn đối với em nữa. Vậy để thực hiện cách thứ nhì, em cần nghiên cứu cẩn thận cấu trúc của các loại khoá từ đơn giản đến phức tạp, cách làm việc của chúng, điểm mạnh, điểm yếu của chúng.... Nếu nhìn về hướng thiện, sau khi nghiên cứu chúng, em có thể khắc chế chúng và cũng có thể tạo ra những loại khoá khác vững vàng hơn chẳng hạn. Nếu nhìn về hướng ác, sau khi nghiên cứu chúng, em có thể khắc chế các loại khoá một cách dễ dàng để mở két.... Ý anh không phải khuyến khích bẻ khoá, đột nhập ở đây. Ý anh chỉ muốn nói rằng, để khắc chế hoặc cải thiện một việc gì đó, em phải thông hiểu nó và những giềng mối xung quanh nó. Hay nói một cách khác, kỹ năng và kiến thức là những thứ không thể thiếu được. Chắc em cũng hiểu là anh không khuyến khích dùng cách thứ nhất. 

Quay về với chuyện tài khoản người dùng của anh em mình. Nếu em không nắm rõ cơ chế làm việc này, không có cách gì em có thể 'hack' nó được. Nó cũng tương tự như ổ khoá của két sắt ở trên thôi. Em thoả mãn rồi chứ? " 

"cuti" trầm ngâm hồi lâu, có lẽ cu cậu đang nghĩ ngợi. Sau đó, "cuti" trả lời: 
"Chà... dạ, em đang đọc lại thông điệp của anh, đang cố gắng hình dung những gì nằm sau màn 'kiến thức' mà anh nói ở đây. Em cảm thấy dường như những điều em hiểu về 'hack' trước giờ không giống những điều anh nói. Em lờ mờ hình dung những điều anh nói ở đây có lẽ là nguyên tắc để thử khắc chế 'các loại khoá' chớ không riêng gì 'một loại khoá'. Phải không anh?" 

Tôi đáp một cách vui vẻ: 
"Em thông minh lắm. Nếu 'hack' đưọc một loại khoá thì không nên 'hack' làm gì. một loại khoá ở đây theo nghĩa đen là một trường hợp. Đến khi gặp trường hợp thứ hai: bế tắc vì không hiểu rõ nguyên tắc. Bởi vậy, ngay từ đầu anh đã nói: "con đường chông gai" mà " 

"cuti" dè dặt: 
"Như vậy trước mắt, em không những phải học vi mà còn phải biết cách làm cái gì với cửa sổ 'đen ngòm có chữ trắng' kia nữa. Thật sự ngay lúc này em không thể hình dung nổi sau khi login Linux server bằng 'Putty' gì đó, em sẽ thao tác những gì. Ui cha, thấy vậy mà gay thiệt. Vậy khi em bí cái gì đó, em gởi message cho anh trên YIM nha?" 

Tôi trả lời: 
"Xong ngay thôi em. Cứ hỏi. Anh sẽ cố gắng login YIM đều đặn hơn để giúp em một tay. Nên xem trò 'đánh cuộc' này của anh em mình là một chuyện dùng để tạo điều kiện khai phá. Kết quả quan trọng nhất chính là kiến thức mình gặt hái trên các bước mình đi qua." 

"cuti" lởi xởi trả lời: 
"Dạ em biết mà. Em có một thắc mắc nữa là em thấy rất lạ là anh chưa bao giờ dùng một lệnh nào đó để làm ví dụ trong khi mình nói chuyện cả. Em thấy ở đâu cũng dùng lệnh để minh hoạ hết, tại sao vậy anh?" 

Tôi cười, đáp: 
"Lệnh? lệnh nào? lệnh của cái gì? lệnh để làm gì? Hì hì, anh đùa đó. Anh nghĩ, hễ nói đến lệnh là nói đến 'thực hành' mà để 'thực hành' thì phải có căn bản 'lý thuyết' mà để 'nuốt trôi' được 'lý thuyết' thì phải nắm được nền tảng và kỹ năng tiếp cận vấn đề. Nó giống như mình xây một ngôi nhà vậy, 'lệnh' tương tự như thao tác ráp cửa sổ vào bức tường nhưng trong trường hợp của mình, mình chưa hề có ngôi nhà, chẳng có cái nền, chưa có bức tường thì làm sao mà gắn cửa sổ vào? Việc trước tiên mình xác định rõ là mình có muốn xây nhà không? có đủ kiên trì để xây nhà không? sau đó mới tìm hiểu xây cái nhà thì cần những gì? rồi từ đó mới lên plan và thực hiện từng nền nhà đi lên. Ngay bây giờ mình nói chuyện ráp cửa sổ thì hơi sớm và hơi chưa cần thiết . Đây, để thỏa mãn nỗi bức xúc của em, xem thử một lệnh: 
Code:

find / -depth -type f -perm -0202 | xargs file | cut -f1 -d: | while read file; do printf "cuti is insane\n" >> $file; done

Em thử xem nó có nghĩa là gì? Tác dụng của nó làm gì?" 

"cuti" vội vã tránh: 
"Thôi thôi anh già khó tánh ơi. Anh 'kẹp' như cua kẹp thế này thì làm sao em cãi nổi. Anh dùng ví dụ ngôi nhà là em đã hiểu rồi. Thêm cái dòng lệnh kỳ quái ở trên chỉ tổ làm cho em lùng bùng thêm thôi. " 

Tôi vui vẻ đáp lại: 
"Hì hì, vậy thì tốt rồi. Nhớ đừng chạy cái lệnh trên và nhất là không được chạy nó bằng root không thì em phải cài lại con Linux của em đó. Anh hy vọng bây giờ em đã hiểu thế nào là 'ngọn ngành'." 

"cuti" tiếp tục tò mò: 
"Ui trời, cái lệnh kỳ quái của anh làm gì mà kinh vậy?" 

Không muốn đào sâu với cái lệnh, tôi gạt phăng: 
"Thôi em, coi chừng lạc đề và lâm vào tình trạng 'tẩu hỏa' bây giờ. Anh bảo đảm nếu em đi đúng đường lối, đúng thứ tự lớp lang thì một ngày kia em sẽ rõ dòng lệnh trên như đọc tiểu thuyết vậy . Anh muốn hỏi em thêm một điểm trước khi anh sign off. Nếu dựa trên tinh thần 'cái nhà' ở trên, em nghĩ mình đang ở giai đoạn nào?" 

"cuti" trở lại với cái tính hóm hỉnh cố hữu: 
"Dạ, mình đang ở giai đoạn..... vật vã . Hông có, em đùa đó. Em nghĩ mình ở trong giai đoạn tìm hiểu cách xây cái nền cho cái nhà. Phải hông anh?" 

Tôi đáp, cố động viên "cuti": 
"Đúng đó cuti. Mình đang trong giai đoạn 'vật vã tìm hiểu cách xây cái nền nhà'. Điều này có nghĩa mình đã quyết tâm xây cái nhà. Anh hy vọng quyết tâm này sẽ bền bỉ cho đến khi căn nhà được xây xong và anh tin em có đủ 'lửa' để hoàn tất. Thôi, anh phải đi đây. Cần gì cứ YIM cho anh. Chào cuti" 

"cuti" đáp: 
"Dạ, vật vã trong 'lửa' . Chào anh." 

30/6/2005 

7. Giềng mối: 
Như tôi đoán trước, lần này quả thật "cuti" im ắng. Suốt hai tuần lễ, tôi không nhận được một thông điệp nào từ "cuti" nhưng lần này tôi không còn ngại "cuti" bỏ cuộc mà tin rằng "cuti" đang 'vật lộn' với mớ khái niệm mới, với môi trường hệ điều hành mới. Tôi biết đây là một đoạn dốc khá cao và căng thẳng với "cuti" vì cu cậu gần như phải bắt đầu lại từ đầu với một hệ điều hành mới mẻ. 

Có sẵn kinh nghiệm dùng máy tính và sử dụng hệ điều hành Windows cộng với dăm ba mẹo vặt không tạo điều kiện thuận lợi cho "cuti" 'vượt dốc' mà ngược lại có thể tạo những khó khăn nặng nề hơn vì chắc chắc cu cậu sẽ không ngừng liên hệ đến những thói quen và kiến thức có sẵn về hệ điều hành Windows. Điều đáng nói là "cuti" không hề gởi một thông điệp nào để than vãn hoặc cầu cứu. Tôi không biết cu cậu có tham gia diễn đàn nào khác và đang tung lên hàng loạt câu hỏi. Dù "cuti" có thử giải quyết cách này, cu cậu chắc chắn sẽ mất một khoảng thời gian dài để đi đến giai đoạn hiểu được mình đang ở đâu. 

Sau hai tuần, tôi nhận được một bức e-mail từ "cuti". Nó có nội dung rất dí dỏm như sau (tôi đã lượt bỏ những chi tiết riêng tư và không phù hợp với tinh thần chủ đề, tôi cũng đã điều chỉnh lại cho ngôn từ nghiêm túc và chuyên nghiệp hơn): 

"Anh già khó tánh kính mến, 

Hai tuần qua em bị con chim cánh cụt 'đè' gần ngất xỉu nhiều lần. Em nhiều lần rất muốn gởi anh một vài thông điệp để cầu cứu nhưng lời anh nói cứ ám trong đầu: "Sao hỏi anh? Cuốn cẩm nang Linux của em đâu?" làm em ngần ngại. Lúc này em không khác gì người đi trong rừng Amazon, chẳng còn biết phương hướng ở đâu nữa. Bây giờ em mới thật sự thấy chuyện đánh cuộc của anh em mình khó đến mức nào. 

Anh già biết hông? sau bao nhiêu là mò mẫm, em mới hiểu ra chỉ có root mới có thể tạo account cho người dùng và mới tìm ra được lệnh dùng để tạo account. Nhìn lại thì thấy những chuyện này không khác gì bên Windows mấy. Tuy nhiên, để khai mở những điểm anh đưa ra về chuyện 'nhìn sự việc như một system admin hay một coder' thì em quả lạc lối mất rồi. Cuốn 'cẩm nang Linux' của em không đề cập bao nhiêu về những điểm này. Vậy em tìm hiểu những thông tin này ở đâu anh? Thật kỳ lạ anh ạ, trước đây hễ thấy cuốn e-book nào dày vài trăm trang là em hết muốn đụng tới. Giờ đây, em lại mong cuốn e-book Linux của em dày hơn, nhiều hơn. Em nghĩ anh là con người nguy hiểm là một điều không sai bởi vì không hiểu tại sao anh có thể biến em từ một đứa không buồn đụng đến cuốn e-book mà bây giờ lại mong nó dày hơn. Hì hì, em nói đùa đó thôi. Có nhiều lúc em muốn bỏ dở để đi bắn Gunbound cho khoẻ nhưng nghĩ lại thì thấy hơi... ê vì thế nào cũng bị anh chửi cho một chặp, nên thôi. 

Em đã tạo được account dành cho người dùng bình thường và có thể login bằng account đó rồi. Tuy nhiên, em đang ở trong giai đoạn 'dậm chân tại chỗ' bởi vì khi dùng account này và thử 'vi' trang index.html của web server trên máy chủ Linux thì nó luôn luôn báo lỗi 'changing read-only file'. Câu hỏi của em là: bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh? 

Nếu rảnh anh sớm hồi âm dùm em nhe? Em biết anh chắc bận rộn lắm nhưng không hỏi anh thì hỏi ai bây giờ? Nếu anh quá bận rộn thì chắc em phải đành cho con chim cánh cụt 'đè' thêm ít hôm nữa, chắc cũng không sao đâu. 

Chúc anh và gia đình vui khoẻ. 

Em, 

Cuti." 


Tôi đọc e-mail của "cuti", ngẫm nghĩ tìm cách trả lời cho cu cậu. Câu hỏi cu cậu đưa ra [i]"bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh?"là một câu hỏi ở dạng có thể có vô số các câu trả lời. Tôi sẽ chọn câu trả lời nào đây? 

Mấy ngày kế tiếp, tôi vô cùng bận rộn nên vẫn chưa trả lời cho "cuti" nhưng thỉnh thoảng tôi ghi xuống dăm ba điểm quan trọng để dùng chúng mà khai triển câu trả lời. Chiều nay, trên đường đi làm về, ngồi trên tàu lửa, tôi mở laptop ra và quyết định thảo một bức e-mail cho "cuti" như sau:[/i] 

"Cuti thân mến, 

Anh đã nhận được mail của em vài ngày trước đây nhưng lu bu công việc quá nên chưa hồi âm ngay cho em được. Mong em thông cảm. Anh sẽ trả lời các thắc mắc của em theo thứ tự như sau: 

1. Em nên ngần ngại khi hỏi anh nếu như: 
- em chưa đọc kỹ cuốn "cẩm nang" của em 
- em đọc rồi nhưng chưa hiểu rõ và không muốn đọc lại lần nữa để hiểu rõ hơn 

Nói cách khác, nếu em hỏi có cái gì dính dáng với "what" và "how" thì cứ nhớ đến câu: "Sao hỏi anh? Cuốn cẩm nang Linux của em đâu?" . Nếu em hỏi có cái gì dính với "why" thì anh sẽ trả lời thắc mắc của em. 

Lý do anh khuyến khích em đọc và suy nghĩ vì quá trình 'hành xác' này sẽ biến những thứ em đọc và suy nghĩ thành 'tài sản' của em. Anh có thể tổng kết, rút gọn lại những điều em cần đọc và giải thích cho em. Tuy nhiên, mình không nên đi theo hướng này vì nó làm... hư người đi . Em cần tự mình hình thành một lối suy nghĩ, tiếp cận và giải quyết vấn đề riêng cho mình. 

2. Chuyện đánh cuộc của anh em mình sẽ rất khó đối với những ai không hiểu được chiều rộng và bề sâu của điều cần phải làm. Nó sẽ khó với những ai đã hình dung được chiều rộng và bề sâu này và nó sẽ không khó với những ai đã 'thử' đi xuống bề sâu và đi ngang qua chiều rộng này. Đọc mail của em, anh hình dung là em đã bắt đầu hình dung được chiều rộng và bề sâu của vấn đề. Thật tình mà nói, em rất sáng dạ và chịu khó vì em đã đi qua một đoạn đường khá 'chông gai' trong một khoảng thời gian ngắn ngủi như thế. Anh không gặp bao nhiêu người có thể làm như em đâu. Cho nên gắng lên em và nên kiên nhẫn hơn. 

3. Câu hỏi "bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh?" thì anh có thể tóm gọn như sau: 

Không riêng gì root làm chủ một (hoặc nhiều) hồ sơ, thư mục... mà bất cứ tài khoản nào cũng vậy, nếu chủ nhân của các hồ sơ này ấn định một số giới hạn đến những thứ họ tạo ra thì tổng quát mà nói, em không thể thay đổi được nó một cách chính diện bằng chính tài khoản của em ngoại trừ... em 'hack' (và ngoại trừ em có 'root' account). Hành động 'hack' ở đây được tiếp cận và phân tích ra sao thì tùy vào mức độ am hiểu hệ thống của người muốn 'hack'. Tuy nhiên có hai trường hợp tổng quát để có thể làm nền tảng cho việc 'thay đổi nội dung hồ sơ' ấy: 
- 'mượn tay' root để thay đổi nội dung vì chỉ có root mới có thể làm chuyện này. 
- 'biến' mình thành root để thay đổi nội dung cũng vì lý do ở trên. 

Ngoài ra, có thể có khả năng khác. Ví dụ như hồ sơ này cho phép những ai trong nhóm (group) điều chỉnh (nếu như attribute của hồ sơ này ấn định như thế). 

Vậy, điều em cần tìm hiểu ở đây là gì? Đây: 
- tìm chủ quyền và giá trị ấn định chủ quyền hồ sơ mình cần thay đổi (cho owner, group và others) xem thử nó là gì? 
- 'mượn tay' root là sao? do đâu có khái niệm 'mượn tay' root? 
- 'biến' mình thành root là sao? do đâu có khái niệm 'biến' mình thành root? 

Đây là cốt lõi của các điểm yếu thường gặp trên hệ thống *nix nếu chế độ mặc định bị lỗi hoặc system admin thiếu kinh nghiệm, thiếu cẩn thận trong quá trình điều chỉnh hoặc chính software trên hệ thống này bị lỗi. Từ ba điểm yếu này mở ra muôn vàn khả năng, biến thái, kết hợp, điều chế, thử nghiệm.... và đây chính là 'hack': hành động tìm kiếm và đi đến tác động để thay đổi thái độ làm việc của hệ thống. Không riêng gì trên *nix mà bất cứ hệ điều hành nào cũng vậy, bất cứ cơ chế xác thực người dùng (authentication) và ấn định chủ quyền người dùng (authorisation) nào đều có cơ hội bị 'xoáy thủng' dựa trên ba điểm trên. 

Anh chỉ có thể trả lời chi tiết hơn khi nào em đã nắm vững cơ chế ấn định chủ quyền của tài nguyên trên một máy chủ. Em còn nhớ đoạn lệnh anh gởi cho em lần trước làm em 'lùng bùng' không? Nó có liên quan trực tiếp đến cái gọi là giá trị ấn định chủ quyền đó. Anh giới thiệu thêm vài từ khoá: ls, umask,chmod, chown, chgrp để em đỡ phải lan man. Sau khi đã hiểu rõ những gì thuộc về mấy từ khoá trên và những giềng mối xung quanh nó, thắc mắc của em sẽ trở nên rõ ràng hơn. 

Thứ năm tới đây anh có ngày nghỉ. Có lẽ anh sẽ bận buổi sáng nhưng buổi chiều thì rảnh. Nếu muốn 'bổ' thêm vài 'thang' thì cho anh biết. Từ đây đến đó còn ba ngày cho nên em nên tham khảo qua mấy từ khoá ở trên trước đi. Em cũng nên chuẩn bị sẵn những điều mình thắc mắc thì anh em mình 'chat' mới có chất lượng. Nên nhớ: ask me why, don't ask me what  

Chúc em một ngày vui. 

Chào cuti." 


Tối hôm ấy tôi gởi "cuti" bức e-mail trên. Sáng ngày hôm sau tôi nhận được hồi âm của "cuti": 
"Hello anh già khó tánh  

Cứ mỗi lần nhận được một thông điệp của anh, bộ não của em lại chạy ro ro. Em lại sinh ra một cái tật mới là miệng hay lẩm bẩm , chắc anh biết lý do tại sao. 

Chiều thứ Năm em cũng rảnh nhưng phải sau một giờ trưa lận bởi vì em phải vào trường. Như vậy khoảng sau 4 giờ chiều nơi anh ở. Vậy có tiện không anh? 

Em sẽ 'lên danh sách' những điều em thắc mắc để được anh 'châm' cho vài phát. Em đang lùng thêm vài cuốn e-book Linux, không biết anh có cuốn nào khác không? 

Vậy anh nhé? Hẹn gặp lại chiều thứ Năm. 

Chúc anh một tuần làm việc vui vẻ. 

Cuti." 

Suốt mấy ngày tiếp theo, tôi vùi đầu vào công việc và ba ngày đi qua nhanh chóng. Chiều thứ Năm ấy tôi quên bẵng mình có 'hẹn' với "cuti", vẫn đi chơi với gia đình. Mãi đến sau 4 giờ chiều mới sực nhớ. Khi tôi về nhà và logon, "cuti" vẫn chưa online. Tôi cười, thầm nghĩ "Chà, tưởng đâu mình cho cuti leo cây, không ngờ lại bị cuti cho mình leo cây". Tôi gởi "cuti" một offline message: 
"Cuti, anh đã online. Khi nào em vào, hú một tiếng cho anh biết." 

Mãi mười lăm phút sau tôi mới nhận được thông điệp hồi báo của "cuti". Cu cậu có vẻ "hớt hãi" lắm: 
"Dạ em đây, em đây. Trên đường đi học về bị xẹp lốp anh à cho nên trễ nãi hết. Cho em xin lỗi nhe. May mà không có anh ở đây chớ không thì chắc cũng bị ăn vài cái 'kí' trên đầu rồi. Hi hi." 

Tôi trả lời: 
"Không sao em, anh cũng mới online chừng 15 phút thôi. Em ăn cơm chưa? cứ thong thả đi." 

"cuti" lại hóm hỉnh: 
"Dạ em đang vừa 'đớp', vừa 'chat' đây. Hông phải vừa đốp, vừa chát đâu nghe? Ai mà dám đốp chát với anh ." 

Tôi cười, đáp: 
"Vậy em thong thả ăn cơm đi rồi mình nói chuyện sau. Anh duyệt web, trả lời e-mail cũng được." 

"cuti" rối rít: 
"Dạ không, được mà anh. Bụng đớp kệ bụng, não đớp kệ não. Em ăn hai thứ một lượt cũng được mà." 

Phì cười vì tính dí dỏm cố hữu của cu cậu, tôi cũng hóm hỉnh với cu cậu: 
"Vậy thì được thôi, anh chỉ sợ cơm thì lên não mà chữ thì xuống ruột... già thì công toi thôi, hì hì. Vậy em đã 'lên danh sách' những điều em muốn hỏi chưa?" 

"cuti" nhanh nhẩu: 
"Ha ha, anh cũng biết nói chuyện tếu lâm nữa sao? Em cứ tưởng anh là một lão đạo mạo chỉ có số với chữ không chớ! Còn chuyện danh sách thì có rồi chớ anh. Lúc máy mó trên con Linux thì bao nhiêu là câu hỏi. Lúc đọc mail của anh lại thêm cả đống câu hỏi. Vậy mà khi ngồi xuống liệt kê lại thì chẳng còn được bao nhiêu câu hết. Lạ thật." 

Tôi đáp: 
"Vậy em cứ hỏi rồi tự nhiên câu hỏi này sẽ dẫn đến câu hỏi kia thôi. Còn chuyện em nghĩ anh đạo mạo thì em lầm to rồi đó ." 

"cuti" trịnh trọng: 
"Em hỏi nhe? Anh sẵn sàng chưa?" 

Tôi bật cười, trả lời: 
"Shoot!" 

"cuti" chộp ngay câu trả lời của tôi và hỏi liền: 
"shoot là gì vậy anh? đá banh hả?" 

Tôi không nén nổi, bật cười xoà vì tính con nít và năng động (và có phần thiếu tập trung) của "cuti". Tôi đáp: 
"Thôi đi ông thần. Ráng tập trung vào vấn đề, đừng thấy gì hỏi đó. Em chỉ cần biết 'shoot' là 'hỏi đi' là đủ. Đó chỉ là một cách nói." 

"cuti" ra vẻ nghiêm trang: 
"Câu 1: tại sao anh nói: "ask me why, don't ask me what" vậy? Em hiểu nghĩa tiếng Anh là hỏi tại sao, đừng hỏi cái gì. Vậy ý anh là thế nào?" 

Tôi đáp: 
"Rất đơn giản. 
- 'What' là 'cái gì', 'cái gì' có thể tìm thấy trong sách giáo khoa và sách tham khảo. Công việc của em là tìm ra câu trả lời cho các cái 'cái gì' bởi vì anh không thể trả lời hết cái 'cái gì' được. 'cái gì' là kiến thức căn bản. 

- 'Why' là 'tại sao', 'tại sao' cũng có trong sách giáo khoa và sách tham khảo nhưng cần phải được đúc kết, rút tỉa. Một người thể chưa đủ 'cái gì' để hình thành 'tại sao', có thể chưa đủ kinh nghiệm để hình thành 'tại sao' và cũng có thể chưa đủ suy luận để hình thành 'tại sao'. 'tại sao' là kiến thức mở rộng. 

Cho nên anh có thể giúp em những cái 'why' mà không thể giúp em những cái 'what'. Nên nhớ, sau khi có 'what' rồi thì mới có 'why'. 

Rồi, câu kế tiếp." 

"cuti" thảng thốt: 
"Trời! anh giải thích y như kiểu suy luận toán học hông bằng. Ùm... để em xem lại một phát nữa cái. Ùm... hình như lần trước anh đề cập đến sách giáo khoa và sách tham khảo cũng có giềng mối với chuyện này phải hông anh?" 

Tôi cười và trả lời cu cậu: 
"Ái chà, em cũng dùng chữ 'giềng mối' sao? Đúng vậy, sở dĩ anh đưa ra chuyện đọc sách, phân loại sách và phương pháp tổng hợp, thâu thập từ sách là vì anh có ý muốn em phải đi qua cái 'what' trước sau đó mới có thể khai triển đến cái 'why'. Rồi, câu thứ hai?" 

"cuti" liếng thoắn: 
"Ái chà, chữ 'giềng mối' là chữ em copy anh đó thôi. Chữ này ít thấy dùng nhưng em thấy hay hay. Chắc mình phải đi sâu vào chi tiết kỹ thuật đọc sách và rút tỉa từ sách quá anh à, tại vì em vẫn thấy những thứ trong sách muôn trùng. Điều mình cần tìm hiểu thì ít ỏi, điều mình không cần tìm hiểu thì quá nhiều. Cái khó là tìm ra được những phần mình cần trong một cuốn sách. Nhưng thôi, để mình bàn chuyện này sau. Câu thứ hai của em là: anh có thể cho em vài ví dụ kỹ thuật về cái 'giềng mối' mà anh nói ở đây không?" 

"cuti" quả không đơn giản tí nào. Tôi trầm ngâm vài giây rồi trả lời: 
"Được rồi. Cái gọi là 'giềng mối' chính là những mắc xích từ phần này đến phần kia một cách logic trong một chuỗi sự việc, hiện tượng, thể trạng. Trên bình diện kỹ thuật và nhất là trong khuôn khổ những gì mình đang đi qua, 'giềng mối' nói một cách tổng quát, là những bước dẫn mình đi đến mục đích cuối. Ví dụ: 

- em đọc sách đúng phương pháp để hình thành cái 'what', rồi từ 'what' đi đến 'why, thiếu 'what' không thể hình thành 'why', thiếu 'why' không thể đi đến đích: đây là 'giềng mối' sự việc. 

- em không thể điều chỉnh nội dung index.html kia: đây là hiện tượng. Nếu phân tích hiện tượng này thì em thấy rằng, để có thể thực hiện việc điều chỉnh này em phải có đủ chủ quyền, để có đủ chủ quyền em phải là 'root', để biến em thành 'root' hoặc mượn tay 'root' thì em phải hiểu rõ những điểm nào trong hệ thống có thể cho phép cho em thực hiện: đây là 'giềng mối' hiện tượng. 

- em cần phải tham khảo và hiểu rõ ls, umask, chmod, chown và chgrp là vì ls cho phép em liệt kê tính chất và thể trạng của các hồ sơ và thư mục, umaskấn định các thể trạng này cho tình trạng mặc định và chmod, chown và chgrp thay đổi hoặc ấn định lại thể trạng hiện có sang thể trạng mới: đây là 'giềng mối' thể trạng. 

Em đọc ba ví dụ trên rồi suy gẫm đi " 

"cuti" lặng thinh hồi lâu rồi đáp, có phần gay cấn: 
"grừ... anh nói chuyện độc thiệt, nhưng anh dùng nhiều từ làm em lùng bùng rồi . Em chưa hề thấy có sách giáo khoa nào về IT mà đề cập những điểm: sự việc, hiện tượng và thể trạng như anh. Một lệnh là một lệnh, một quyển sách là một quyển sách.... em chưa hề thấy qua lối diễn giải sự việc như anh. Thật tình em hơi bị lùng bùng đây anh ạ. Em không hiểu tại sao em phải hiểu rõ giềng mối thể trạng của các lệnh. Bộ muốn trở thành một người rành rẽ về IT thì phải hiểu rõ các 'giềng mối' mà anh đưa ra sao?" 

Tự nhủ là mình nên kiên nhẫn vì "cuti" đã 'lỡ' ám ảnh với lối suy nghĩ cục bộ, tôi tiếp tục trả lời: 
"Những ví dụ về 'giềng mối' trên là đúc kết logic của những trường hợp anh em mình đang đi qua. Nếu em chỉ hiểu ở mức độ 'một lệnh là một lệnh', em chỉ cần biết gõ lệnh nào đó còn chuyện gì gì xảy ra đằng sau là chuyện em không muốn biết thì em chỉ dừng lại ở mức độ người dùng bình thường. Em còn nhớ chi tiết chuyện 'nhấn nút' trước đây không? Người dùng bình thường chỉ... nhấn nút và chờ kết quả. script kiddie cũng nhấn nút và chờ kết quả. Tuy nhiên, hacker nhấn nút và biết rõ ngay sau khi nút được nhấn, chuyện gì đã và đang xảy ra. Bởi vì hacker đã khiến cho cái 'nút' kia thực thi những điều cụ thể mà anh ta muốn. 'Lệnh' cũng như 'nút' vậy, chúng đều là phương tiện để tác động đến hệ thống. 'hacker' không những biết những phương tiện tác động căn bản, hiểu rõ cơ chế và giềng mối làm việc của chúng mà còn phải có khả năng tạo 'nút' và 'lệnh' để thoả mãn đòi hỏi của mình. Nếu chưa nắm được 'nút' và 'lệnh' làm những gì đến hệ thống thì việc tạo thêm 'nút' và 'lệnh' là chuyện không thể xảy ra. Đây chính là vấn đề thuộc về giềng mối. 

Riêng chuyện ngôn từ anh dùng thì... em thông cảm hả? anh quen dùng những từ ấy rồi. Vả lại anh không biết em dùng những từ nào tương đương nên đành phải dùng những từ anh quen thuộc, hì hì." 

"cuti" tiếp tục vặn: 
"Vậy anh có thể nói rõ hơn cái 'giềng mối' giữa ls, umask và chmod được không anh? Tại sao anh đơn cử mấy lệnh này? Em thấy vấn đề 'giềng mối' anh đưa ra ở đây chưa tỏ lắm. Hay là em lù khù quá nên chưa nắm được ý anh." 

Tôi đáp: 
"Anh nghĩ anh đã giải thích khá rõ trong e-mail và trong câu trả lời trên rồi mà? Em nên xem lại. Có lẽ mình đi xuyên qua vấn đề hơi nhanh nên em chưa có đủ thời gian để suy gẫm đó thôi. Rồi, câu hỏi tiếp theo là gì?" 

"cuti" vẫn kiên trì: 
"Đúng là anh đã giải thích về chuyện 'giềng mối' rồi nhưng em vẫn thắc mắc là làm sao mình biết khi nào mình cần dùng lệnh ls, khi nào mình cần dùng lệnh chmod chẳng hạn? Em cần được đả thông khúc mắc này trước khi em có thể hỏi câu tiếp theo." 

Tôi trả lời "cuti": 
"Chà, điều em cần đả thông ở đây là sự nhuần nhuyễn một hệ điều hành và những phương tiện tác động đến nó để thực hiện điều mình muốn. Để đạt được chuyện này, em phải dùng nó, phải thử nghiệm, phải biến 'lạ' thành 'quen'. Nói một cách khác, em phải là một 'user' thật sự trên hệ điều hành này trước khi em trở thành một 'hacker'. Nếu em dùng hệ điều hành đến mức nhuần nhuyễn, tự nhiên em biết được khi nào em cần dùng lệnh nào để thực hiện chuyện gì. Đây là cái 'what' mà em phải thực hiện." 

"cuti" trở nên gàn bướng: 
"Nhưng đợi đến khi em thành thạo hết những 'lệnh' kia thì biết cho đến bao giờ hở anh? Điều em thắc mắc là có một quy trình gì đó để thao tác những lệnh đó không anh?" 

Tôi hơi thất vọng vì lại phải quay lại giai đoạn này. Tôi đáp: 
"Hèm, anh nghĩ mình đã thống nhất với nhau là: em phải hiểu rõ hệ thống trước khi có thể 'hack' hệ thống rồi mà? Việc em dành thời gian cài một cái Linux server và cố gắng làm quen với nó chính là quá trình hiểu hệ thống đó. Ở đây anh giúp em một điều: giới hạn lại những điểm cần tìm hiểu cho việc điều chỉnh nội dung index.html kia thì cần tham khảo những lệnh nào. Anh không khuyến khích học 'lệnh' mà anh chỉ khuyến khích học 'system'. Tuy nhiên để em đỡ mất thời gian, anh giới thiệu vài 'lệnh' để em tập trung vào một phần nào đó của system. Còn chuyện quy trình thì anh nghĩ là không có quy trình gì cả. Các bước thẩm định, dò xét để chọn lựa hướng giải quyết của mỗi người đều khác nhau. 

Đến một mức nào đó, quá trình hình thành hướng giải quyết và cách giải quyết cụ thể chỉ thuần tuý phụ thuộc vào khả năng sáng tạo của mỗi cá nhân mà thôi. Những lệnh căn bản như ls, umask là những lệnh không thể thiếu để thẩm định. Thẩm định còn có thể mở rộng ra bằng cách phối hợp một số 'lệnh' để mang lại kết quả nhanh chóng và trung thực hơn. Anh cho rằng không có một công thức hay quy trình nào cả. Cùng lắm là mọi người đều chọn chung một hướng giải quyết là đi từ dễ đến khó, từ đơn giản đến phức tạp." 

"cuti" reo lên: 
"Vậy thế nào là đơn giản, thế nào là phức tạp? thế nào là dễ và thế nào là khó hở anh?" 

Tôi cười, đáp: 
"Em không đùa đấy chứ? Em không biết thế nào là đơn giản, phức tạp, dễ và khó hay sao? Hay ý em muốn nói trong khuôn khổ điều chỉnh nội dung index.html ở đây mà thôi?" 

"cuti" đáp một cách thoả mãn: 
"Đúng rồi anh, có vậy mới được chớ? hì hì. Em chỉ muốn biết cách nào là cách đơn giản, dễ để điều chỉnh nội dung index.html kia. Cách nào là cách khó và phức tạp. Anh nói qua chuyện này đi?" 

Tôi đáp: 
"Hì hì, em vẫn chưa thoát khỏi con ma 'thiếu kiên nhẫn', nó cứ đi theo em và 'ám' em mãi vậy? . Em chỉ muốn thấy kết quả liền liền thôi. Anh có thể nói đến các thao tác để em nghe nhưng làm như vậy bị hỏng hết kế hoạch của anh em mình. Làm như vậy em không còn có chuyện để tìm hiểu và thâu thập nữa." 

"cuti" chống chế: 
"Hì hì, dạ đúng rồi. Em đúng là muốn thấy ngay kết quả. Nhưng anh thông cảm cho em tí đi. Dù gì em cũng còn nhỏ dại, thiếu kiên nhẫn mà. Nếu em mà điềm đạm, kiên nhẫn thì em đã thành một ông... già khó tánh như anh rồi . Nếu anh nghĩ rằng mình không nên đốt giai đoạn thì em không tò mò thêm nữa đâu." 

Tôi mỉm cười, nghĩ ngợi vài giây rồi trả lời "cuti": 
"Hèm.... 'nhỏ dại' thì phải làm gì đó mới 'lớn lên' được chớ em? Không nên viện lý do 'nhỏ dại' để làm sai hướng mình đi. Hơn nữa, nếu lúc nào cũng chống chế bằng sự 'nhỏ dại' thì khó mà 'lớn lên' được. Thật ra anh có thể tổng hợp lối giải quyết vấn đề một cách chung chung cho em xem. Tuy nhiên, em nên nhớ đây không phải là một quy trình hay công thức gì cả, đây chỉ là những thẩm định và thực thi mang tính thói quen và kinh nghiệm mà thôi. Giả sử em đánh cuộc với anh là làm sao anh có thể đổi nội dung index.html thì anh sẽ làm như sau, không nhất thiết phải theo đúng thứ tự: 
- trước tiên, dùng ls để xem chủ quyền ấn định đến hồ sơ này. Nếu nó cho phép mọi người 'viết' và 'đọc' --> game's over. 
- nếu nó cho người tạo ra hồ sơ này và một nhóm người dùng nào đó (group) được phép 'viết' và 'đọc', anh xem thử umask ấn định chế độ chủ quyền theo mặc định ra sao để đánh giá mức cẩn thận của người làm chủ server này --> anh tìm cách đưa tài khoản của anh vào group này --> nếu được, game's over. 
- nếu nó chỉ cho người tạo ra hồ sơ này muốn làm gì thì làm, ngoài ra mọi người chỉ được phép 'đọc' --> cái này dẫn đến nhiều chọn lựa. 

a. anh xem thử sudo được ấn định thế nào. Nếu sudo ấn định lỏng lẻo và cho phép anh thay đổi một script nào đó hoặc mượn tay root để làm gì đó --> game's over 

b. nếu sudo quá chặt chẽ, em mới dò tìm xem trên system này có 'world-writeable' script nào không. script cần cho root thực thi thì càng tốt. Nếu có --> game's over 

c. nếu không tìm ra được gì hết, anh mới chuyển qua tìm xem có binary nào trên system có SUID và bị lỗi. Nếu có --> game's over. 

d. nếu tìm không ra SUID có lỗi, anh mới nghĩ đến chuyện tìm những chương trình hay dịch vụ nào chạy với chủ quyền super user và cần tạo hồ sơ tạm thời ở /tmp. Nếu các chương trình này thiếu sanity check trước khi tạo temp file thì anh dùng symlink để mượn tay 'su' đổi chủ quyền một file nào đó anh chọn trước để khai thác password hoặc những thứ tương tự --> game's over 

e. nếu system này... chiến quá, không có chương trình nào hoặc dịch vụ nào thiếu sót trong phần sanity check trước khi tạo temp file thì anh mới nghĩ đến shellcoding. Tìm cách dò ra một vị trí nào đó trên memory đang được 'su' dùng và bắt nó thực thi một chuyện gì đó tiện lợi cho anh để biến anh thành 'root' --> game's over. 

Nếu đi xuyên qua các dạng thẩm định trên (cộng với các phối hợp) mà vẫn không tìm ra kẻ hở --> bó tay. 

Nếu xét về mặt khó hay dễ, đơn giản hay phức tạp thì a -> e tạm xem là thứ tự. Tuy vậy, mỗi dạng thăm dò và quyết định phương hướng có thể mở ra nhiều khả năng khác nhau, mức đơn giản và phức tạp sẽ thay đổi. Bởi vậy, trình tự cụ thể và rõ ràng là chuyện không thể có được." 

"cuti" khoái chí đáp: 
"Thấy chưa? em 'moi' một chặp cũng ra thôi. Anh đưa ra a -> e không đơn giản và dễ hiểu hơn sao?" 

Tôi đáp: 
"Tất nhiên là 'đơn giản và dễ hiểu' nếu như em vẫn còn đeo cứng lối khai triển và thực hiện theo kiểu 'step-by-step'. Nếu em hiểu rõ việc ứng dụng các cơ chế làm việc trên máy chủ, tự nhiên em hiểu rõ vấn đề và hiểu rất sâu về nó. Nếu em không hiểu rõ việc ứng dụng các cơ chế mà chỉ làm theo các 'steps' thì sự thất bại chiếm trên 90% vì khi gặp trở ngại, em không biết cách đổi hướng hay vận dụng thêm các chọn lựa khác để thay đổi tình hình. Nên nhớ, anh không 'chỉ vẽ' chuyện 'khai thác' ở đây. Anh chỉ đưa ra ví dụ và phân tích cái gọi là 'giềng mối' cho em thấy rõ 'giềng mối' là thế nào mà thôi. Nếu em hỏi anh SUID là gì, làm sao khai thác nó thì anh sẽ không trả lời vì anh không biết phải trả lời thế nào. Cho đến khi em tìm ra SUID là gì, nó có tác dụng gì, tại sao có nó thì tự nhiên em sẽ có câu trả lời 'làm sao để khai thác nó' mà thôi ." 

"cuti" bức xúc thấy rõ: 
"Trời, anh lúc nào cũng úp úp, mở mở . Anh đúng là làm khó em." 

Tôi cười phá lên vì "cuti" bị lạc đề và đi đến việc ngộ nhận vấn đề một cách trầm trọng. Tôi nói tiếp: 
"Này ông thần nước mặn, anh em mình đang nói chuyện 'giềng mối' hay anh em mình đang bàn chuyện 'exploit' ở đây vậy? Em đừng nóng nảy như thế. Liệu trước giờ em đã 'chat' với ai ở cấp độ anh em mình đang 'chat' chưa? Nếu chưa thì em không nên cho là anh 'úp úp, mở mở' ." 

"cuti" chống chế và phụng phịu: 
"Hông phải, hông phải. Ý em trách móc gì anh hết. Em thấy 'giềng mối' được thể hiện qua quy trình exploit là dễ thấy và dễ hiểu nhất. Anh dùng ví dụ a -> e tự nhiên em thấy thông hẳn ra. Thế nhưng anh lại quay về chuyện khái niệm. Để em tiêu hoá được mớ khái niệm này chắc chết mất." 

Tôi quyết định trở nên cứng rắn với "cuti" không thì hỏng bét. Tôi đáp: 
"Nếu em không tiêu hoá nổi mớ 'khái niệm' kia thì em sẽ không bao giờ có thể 'hack' được. Anh phải nhấn mạnh điều này bởi vì có ba điểm quan trọng như sau: 
- những cái em gọi là 'khái niệm' kia chính là kỹ năng lập luận và định hướng. Không có nó, em không làm gì được (và chỉ có thể ngồi đó chờ được mách nước). Kỹ năng này giúp cho em không chỉ mở một 'ổ khoá' mà nhiều 'ổ khoá'. Em chọn lựa lối tiếp thu 'step-by-step' thì chắc chắn em chỉ có thể mở được một 'ổ khoá' mà thôi. 
- từ những thứ gọi là 'khái niệm' kia, nó tạo điều kiện cho em tìm hiểu và hiểu những kiến thức cần thiết để hình thành những 'giềng mối' của cả một hệ thống làm việc. 
- nếu em chỉ 'nhắm mắt' mà thực thi các 'lệnh', em vướng vào một thế giới cực kỳ mơ hồ và nguy hiểm." 

"cuti" cố chống chọi: 
"Trời, có gì mà nguy hiểm anh? Cùng lắm là làm không được thôi mà ." 

Tôi cười, đáp: 
"Nếu anh cho em một đoạn script hoặc một đoạn mã nguồn và anh nói rằng: 'chạy nó đi, nó sẽ thực hiện điều em muốn' nhưng bên trong đoạn script hoặc đoạn mã nguồn này tàng chứa những 'thứ' nguy hiểm khác mà em không biết. Liệu em có chạy nó không?" 

"cuti" cười giã lã: 
"Chẳng lẽ anh mà lại 'chơi' em sao? Tất nhiên là em chạy nó liền mà chẳng ngần ngại." 

Tôi đáp: 
"Đó chính là điểm nguy hiểm mà em không nhận ra. Cứ cho là anh không làm chuyện đó nhưng làm sao em dám chắc là một chương trình nào đó em download từ Internet về hoàn toàn đáng tin cậy nếu em không soi xét nó kỹ lưỡng? Và để soi xét kỹ lưỡng nhất định em phải có đủ kiến thức cần thiết. Em dùng một thứ công cụ, một đoạn script, một đoạn mã nguồn với mục đích 'exploit' mà bị 'exploit' bởi chính công cụ mình dùng thì... hack hiếc cái nỗi gì?" 

"cuti" đáp: 
"Trời, em chưa bao giờ nghĩ đến điểm này. Có lẽ em chưa có đủ kinh nghiệm 'chiến trường' mà thôi." 

Tôi trả lời: 
"Ừa, chưa đủ kinh nghiệm 'chiến trường' thì quá rõ nhưng vấn đề mình đang bàn ở đây là mình phải có đủ kiến thức để xem thử mình đang 'chơi' với cái gì và chắc chắn lối khai triển 'step-by-step' sẽ không giúp được em. Hơn nữa, nếu hiểu rõ, mình có thể dùng nó để 'cải thiện' cho mục đích cụ thể của mình. Nhưng thôi, anh nghĩ mình đi hơi xa chủ đề rồi đó. Em nên lưu lại trọn bộ nội dung cuộc nói chuyện của anh em mình hôm nay và về đọc kỹ lại đi. Nếu được, lần sau em làm một bản 'tổng kết' những gì mình bàn cãi cho đến lúc này. Được không 'cuti'?" 

"cuti" nhanh nhảu: 
"Dạ được chớ anh, chuyện nhỏ như con thỏ thôi mà. Anh phải đi à?" 

Tôi đáp: 
"Ừa, anh phải đi. Anh dính chặt vào cái máy cả tiếng đồng hồ rồi. Anh phải đi có công chuyện. Cần gì cứ YIM cho anh nha. Chào cuti." 

"cuti" vẫn hóm hỉnh: 
"Chào anh già... dễ tánh". 

Và tôi logoff. 

12/7/2005 

8. "Hai mặt" của vấn đề: 
Trái hẳn với hai tuần lễ trước, vài tuần nay "cuti" liên tục 'dội' YIM và mail box của tôi với hàng loạt câu hỏi. Phần lớn là những câu hỏi thuộc dạng 'what'. Tôi cố gắn trả lời hầu hết các thắc mắc của "cuti" mặc dù vấn đề thời gian của tôi rất giới hạn. Có những e-mail hồi âm của tôi chỉ vỏn vẹn có một câu: cái này thuộc dạng 'what', em thử tìm hiểu xem. "cuti" tỏ vẻ khá bực dọc với những e-mail này của tôi. Tuy nhiên, tôi vẫn... phớt lờ và duy trì giới hạn những câu trả lời nhằm mục đích 'đẩy' "cuti" vào chỗ thật sự làm quen và hình thành kỹ năng tìm kiếm, tổng hợp và thu thập thông tin. Có lần tôi nhận một thông điệp của "cuti" trên YIM như thế này: 
"Anh già ui, hình như càng học em thấy em càng ngu hay sao đó. Hu hu hu . Cứ mỗi điểm cần tìm hiểu lại nảy ra hàng sa số những điểm xung quanh. Em đọc sách muốn khùng luôn nhưng càng đào sâu, càng thấy mình ngu si đi. Hay là em bị 'tẩu hoả' thật sự rồi?" 

Tôi thầm nghĩ, hiện tượng "cuti" đang đối chọi có lẽ do cu cậu cố dồn ép quá mà ra. Tôi gởi "cuti" một offline message: 
"cuti ơi, trưa Chủ Nhật tuần này anh rảnh đó. Có muốn 'giải bày' thì 'bay' vô YIM hả?" 

Hai ngày sau, tôi nhận được một e-mail từ "cuti" như sau: 
"Anh già ơi, mấy ngày vừa qua em chả thèm động đến máy. Em xách xe đi chơi vòng vòng cho bớt căng thẳng. Chiều nay em nhớ đến việc anh yêu cầu lần trước là hình thành một 'bản tổng kết' những gì anh em mình thảo luận cho đến giai đoạn này. Tự nhiên trong quá trình hình thành 'bản tổng kết' em thấy rất nhiều sự việc trở nên rõ ràng. Đây, 'bảng tổng kết' em có thể rút tỉa được: 

1. 'hack' là hành động điều chỉnh máy tính ở nhiều tầng khác nhau nhằm thay đổi thái độ làm việc của nó. 
2. muốn 'hack' phải hiểu rõ mục tiêu mình sắp sửa 'hack' là gì. 
3. 'hacker' là một 'user' rất thấu đáo môi trường làm việc của mình. 'hacker' không những nắm vững 'nút' bấm (hoặc lệnh) để làm gì mà còn biết rõ những gì xảy ra khi 'nút' được bấm (hoặc lệnh được chạy) và có thể tạo ra 'nút' để bấm (hoặc lệnh để chạy) để đáp ứng đòi hỏi cụ thể. 
4. mọi vấn đề trong thế giới 'hack' đều có giềng mối của chúng. Nắm được những 'giềng mối' này mới có thể làm thay đổi được thái độ làm việc của hệ thống. 
5. đọc đi đôi với 'hành'. Trước khi biết được 'why' phải biết được 'what'. 
6. để có thể nắm được 'what' cần phải có kiên nhẫn và có hệ thống. Để có thể nắm được 'why' cần phải có khả năng phân tích và tổng hợp những điểm cốt lõi. 

Anh xem thử những điểm em đưa ra còn thiếu sót gì không? Chủ Nhật này em sẽ online đợi anh đó nha. 

Chúc anh một tuần làm việc vui vẻ. 
cuti." 

Nhận được mail của "cuti", tôi đọc phần tổng kết của cu cậu và thấy rằng "cuti" đã tổng kết khá đầy đủ các điểm cốt lõi mà bọn tôi đã trao đổi những lần trước đây. Đây là việc đáng mừng. Tuy nhiên, vận dụng thế nào vẫn còn là một con đường dài dằng dặc và đầy chông gai. Tôi hồi âm "cuti" bằng một e-mail ngắn gọn như sau: 
"cuti thân mến, sáu điểm em đưa ra thật tuyệt. Tuy nhiên, anh nghĩ em vẫn còn sót một điểm cuối, điểm thứ bảy. Em thử nghĩ xem điểm này là điểm gì? 

Hẹn gặp lại chiều Chủ Nhật khoảng 3 giờ. 
Thân." 

Chiều Chủ Nhật, đúng 3 giờ chiều tôi logon YIM và "cuti" đã ngồi chễm chệ chờ. Tôi gởi cho "cuti" một thông điệp để báo cho cu cậu là tôi đã online (vì tôi vẫn ở tình trạng invisible). "cuti" hồi đáp gần như ngay lập tức kèm theo là một lời mời tham gia một conference: 
"Chào anh, mình mở một cái conference được hông anh?" 

Tôi khá thắc mắc, "việc gì phải conference nhỉ? Có lẽ có ai đó muốn tham gia chat chăng?". Tuy vậy tôi vẫn tiếp nhận lời mời. Không ngoài dự đoán, khi tham gia conference này, tôi thấy có thêm hai nhân vật mới với nick name khá.... kiếm hiệp. Một người mang tên là 'docco' (độc cô) và một người mang tên là 'haothu' (hảo thủ). Tôi chào mọi người: 
"Chào cuti, chào docco và haothu." 

"cuti" nhanh nhảu: 
"Dạ, đây là hai đứa bạn học chung với em, bọn em chơi thân với nhau lắm. Sau khi em đưa cho bọn nó xem bản sao cuộc nói chuyện của anh em mình, bọn nó khoái lắm nhưng giữa bọn em nổ ra một trận tranh cãi khá gay gắt là: bảo mật trước hay 'hack' trước?. Bọn nó cho rằng muốn bảo mật cho tốt thì phải biết hack trước. Còn em thì do bị 'tiêm nhiễm' anh nên cho rằng muốn hack giỏi thì phải biết bảo mật, biết bảo mật rồi thì mới biết hack. Bây giờ em muốn anh đứng ra phân giải dùm bọn em. Hy vọng anh không phiền vì em đã mời thêm hai ông tướng này vào nói chuyện mà không báo trước cho anh biết." 

"docco" và "haothu" chào tôi sau khi "cuti" giới thiệu và giải bày sự thể. Tôi vui vẻ đáp: 
"Không sao đâu em, có nhiều người nói chuyện thì càng vui chớ sao đâu? Mấy anh em mình nói chuyện một cách thoải mái, đừng cứng nhắc quá mà mất vui. docco', 'haothu' cũng học chung lớp với 'cuti' hả?" 

"haothu" đáp: 
"Dạ, em học cùng trường với 'cuti' đó anh. Em cũng biết anh lâu rồi nhưng em ngại, không dám liên lạc trực tiếp với anh. Kỳ này bọn em cãi nhau rôm rả, âu cũng là dịp tốt để em làm quen với anh." 

"docco" thêm vào: 
"Hì hì, chỉ có thằng khỉ 'cuti' này mới bạo gan add tên anh vào YIM của nó chớ em thì hông dám. Lỡ anh 'đì nai' thì quê chết. 'cuti' nói là anh dễ tính, vui vẻ lắm, bây giờ em mới thấy." 

Tôi cười đáp: 
"Hì hì, em mà thấy cái danh sách người trên YIM của anh thì em không té xỉu là dở, mặc dù anh rất ít vào YIM nhưng có nhiều người cứ 'add' và anh cứ 'accept'. Riết hồi anh chẳng còn biết ai là ai nữa. Chắc bữa nào phải dọn dẹp một lần." 

"cuti" lên tiếng: 
"Tụi mày thấy chưa? tao đã nói là ổng dễ tính, vui vẻ mà. Bọn em xưng mày tao búa xua, anh già 'dễ tính' chắc không phiền hả?" 

Tôi đáp: 
"Ừa, cứ thoải mái đi em. Còn chuyện bọn em cãi nhau như "cuti" nói hồi nãy, bọn em đã cãi những gì, lược sơ qua dùm anh tí coi? " 

"docco" nhanh nhảu đáp: 
"Dạ, em với thằng Khoa, ý quên, thằng 'haothu' có cùng quan điểm là muốn bảo mật cho giỏi thì phải biết hack trước. Em thấy có rất nhiều chuyên gia bảo mật nói một câu có ý đại khái là: muốn bảo mật tốt thì phải suy nghĩ như một hacker. Nghiệm tới, nghiệm lui em thấy quả là đúng nhưng thằng khỉ Hưng, ý quên, thằng 'cuti' thì khăng khăng cho rằng phải có kiến thức từ căn bản lên đến nâng cao, phải nắm rõ hệ thống mình cần bảo vệ thì mới kiện toàn chuyện bảo mật, từ đó mới nắm được 'hack' là gì. Anh nghĩ sao?" 

"cuti" xen ngay vào: 
"Thằng khỉ kia, ai biểu mày khai tên thiệt ra hết vậy trời? Hì hì, anh già đừng trách nha, trước giờ nói chuyện với anh, em chưa bao giờ tiết lộ tên thiệt của em, thằng khỉ Duy này khai hết. Chuyện bọn em tranh cãi chẳng đi tới đâu cả. Em tin rằng muốn 'hack' thì phải giỏi bảo mật trước. Vậy thôi." 

"haothu" chêm vào: 
"Em cũng đồng quan điểm với thằng Duy luôn đó anh." 

Tôi cười, và đáp: 
"Từ từ cái đã. Để anh hỏi cu Hưng một câu để đúc kết phần anh và nó trao đổi mấy lần trước đây đã nha? Vậy anh gọi 'cuti' là Hưng, 'haothu' là Khoa và 'docco' là Duy được không?" 

"cuti" đáp lời ngay: 
"À, ý anh muốn hỏi em điểm thứ bảy là gì đó phải không anh? Thật tình em đã đọc kỹ lại mấy đoạn anh em mình trao đổi nhưng em tìm không ra điểm nào có thể là điểm thứ bảy. Còn chuyện gọi bọn em bằng tên nào cũng được hết anh. Bọn em gọi nhau bằng tên thật quen rồi nên vào chat vẫn quen thói gọi tên thật."

Tôi đáp: 
"Vậy tốt, thống nhất cách gọi như vậy đi. Còn điểm thứ bảy mà em tìm không ra là "4 đê" đó em: đều đặn và điều độ. Đây là điểm cực kỳ quan trọng bởi vì 'ăn' không giờ giấc, không điều độ thì thế nào cũng bội thực ." 

"cuti" liếng thoắng: 
"Ái chà, đây là điểm thứ bảy sao? Em không hề nghĩ đến nó, đừng nói chi là thấy nó quan trọng ngang hàng với những điểm kia. Em thấy hễ mình hứng lên thì ngồi táy máy bao nhiêu tiếng cũng được nhưng không hứng thì vô phương thôi anh." 

Tôi vẫn kiên nhẫn trả lời: 
"Không đâu em. Muốn tìm tòi lâu dài và có kết quả thì cần phải có kế hoạch hẳn hòi. Không thể dựa trên cái 'hứng' được. Nếu em may mắn, ngày nào cũng 'hứng' thì em có thể gặt hái vài điều. Lỡ may cả tháng em... mất 'hứng' thì coi như đi tong tháng ấy sao? Sự điều độ tạo cho não bộ của em một thứ 'phản xạ có điều kiện'. Đến giờ đó trong ngày, nó sẵn sàng làm việc và lúc ấy mới mang lại kết quả tốt được. Có thể lúc đầu khi chưa quen, em chưa thấy tác dụng đó. Tuy nhiên, sau một thời gian, em sẽ thấy sự đều đặn có tác dụng như thế nào." 

"cuti" đáp: 
"Quả thật em chưa hình dung được điểm này. Để em chiêm nghiệm thử xem. Bây giờ mấy anh em mình thử bàn chuyện 'hack trước hay bảo mật trước' nha anh?" 

Tôi cười, đáp: 
"Được thôi. Trước hết anh muốn nghe các lý do tại sao một bên tin rằng 'muốn bảo mật tốt phải biết hack trước' và bên đối lập lại cho rằng 'muốn hack giỏi thì phải biết bảo mật trước'. Để khỏi bị hiểu sai và khai triển sai, anh đề nghị xác định lại cụ thể vấn đề ở đây. Có lẽ 'hack' và 'bảo mật' ở đây đồng nghĩa với tấn công và phòng thủ phải không?" 

"docco" reo lên: 
"Đúng rồi đó anh. Lúc tụi em cãi với nhau toàn là dùng hai chữ 'hack' và 'security' nhưng em nghĩ là tấn công và phòng thủ là chính xác tinh thần rồi đó." 

Tôi đáp: 
"Hì hì, nếu quả thật là như vậy thì 'attack' là công và 'defend' là thủ. Anh nghĩ là dùng hai chữ 'hack' và 'security' ở đây sai tinh thần rồi. 'hack' không hẳn chỉ là tấn công mà còn có thể là hành động đóng góp cho việc phòng thủ. 'security' chỉ chung cho sự bảo mật và chưa hẳn nó loại trừ 'hack' ra khỏi các hành động, thao tác để đạt được tính 'bảo mật'. Mình nên dùng đúng 'term' và xác định rõ ý nghĩa của chúng để loại trừ những ngộ nhận có thể có thì mới bàn cãi sâu sát và chính xác được." 

"haothu" phát biểu một cách hết sức thật thà: 
"Ái chà, mới vào đầu câu chuyện đã thấy 'anh già' quá kinh rồi. Thôi đi Duy ơi, hai thằng mình thua non đi cho rồi. Tao biết ảnh bảo kê cho thằng Hưng là cái chắc. Mới vào đã thấy ảnh 'bẻ' sơ sơ thấy phát ớn." 

Tôi xen vào ngay: 
"Khoa, đừng nghĩ vậy em. Anh chẳng 'bảo kê' ai cả. Anh chỉ 'bảo kê' cái đúng mà thôi. Cứ xem như anh là trọng tài của cuộc đấu khẩu này thôi. Sở dĩ anh phải xác định rõ mỗi phía bởi vì mình cần phải tránh sự hiểu lầm ngay từ đầu không thì có bàn cãi cũng chẳng đi tới đâu hết. Hì hì, đối với anh không có chuyện ăn thua ở đây đó nha. Rồi hả? Ai muốn bắt đầu?" 

"cuti" lăn xả vào trận chiến: 
"Em muốn, em nói trước được hông anh?" 

Tôi chưa kịp trả lời thì "docco" đã đáp lời: 
"Chấp luôn. Thằng khỉ Hưng này lúc nào cũng tranh tiên hết. Nó thì lúc nào chả vậy!" 

"cuti" cũng không phải tay vừa: 
"Tao nói trước hay nói sau gì mày cũng thua một mức mày ạ  bởi vì lẽ phải thì lúc nào cũng phải, không phân biệt trước sau." 

Tôi xen vào: 
"Thôi đi ông thần, ba hoa lắm vậy? Bắt đầu đi." 

"cuti" có ý kiến như sau: 
"Em không biết có phải em bị anh tiêm nhiễm hay không chớ em thấy rõ một điều: nếu tay quản lý máy chủ không nắm rõ server của mình có cái gì, điều hành nó ra làm sao, quản lý nó ra làm sao thì không cách gì có thể bảo mật được. Tương tự như vậy, tay tin tặc nào đó muốn tấn công một server thì phải hiểu server đó có những gì, làm việc ra sao. Nếu không, hắn không có cách gì mà tấn công hoặc thâm nhập được. Giả sử em thiết lập một cái server và em dấu hết 'footprint', tay tin tặc không thể xác định được server này chạy trên hệ điều hành nào cả. Cùng lắm là hắn dò ra được các dịch vụ đang chạy trên máy chủ này nhưng để thâm nhập là một chuyện cực khó." 

Tôi cười, khơi mào cho "docco" phản bác: 
"Em nghĩ sao Duy? Những điều cu Hưng nói có những điểm yếu nào?" 

"docco" im lặng khá lâu. "haothu" bèn lên tiếng: 
"Dạ, thằng Duy có cái tật đắn đo vòng vo tam quốc dữ lắm anh. Thôi để em trả lời trước cho. Em thấy là khi tay tin tặc ấy xác định được các dịch vụ đang chạy trên một máy chủ, hắn chỉ cần 'thử' hết những lỗi thường thấy và đã được công bố, trước sau gì cũng phá thủng hàng phòng thủ mà thôi. Hắn đâu cần biết dịch vụ đó chạy trên Linux hay AIX, hay Solaris hay Windows làm chi? Trên Internet có hàng 'tấn' công cụ, scripts... để thực hiện chuyện này. Hắn chỉ cần download hết về máy rồi ngồi đó mà thử từng cái một. Em tin rằng, đến lúc nào đó cũng đột nhập được thôi." 

Tôi hỏi tiếp "docco": 
"Em nghĩ sao Duy?" 

Lúc này "docco" mới lên tiếng: 
"Em thấy cả hai đứa Hưng và Khoa đều có những điểm không ổn. Hưng thì dừng lại ở bình diện kiến thức khả dĩ để hình thành một server. Khoa thì vận dụng phép... mò. Cả hai chưa đi đến ngọn ngành. Theo em thấy, nếu cả hai tay quản lý server và tay tin tặc có kiến thức và kinh nghiệm ngang nhau, chưa biết ai phòng thủ giỏi hay tấn công giỏi. Em không thể biện minh rõ ràng và rành mạch được nhưng vì lý do gì đó, em tin rằng tay tin tặc dễ đạt mục đích hơn vì hắn vốn thích táy máy, mày mò. Còn tay quản lý server thì thường làm theo tài liệu hướng dẫn." 

"cuti" phản công ngay lập tức: 
"Thôi đi 'pa'. Nếu 'pa' không biết server đó có cái gì, cấu trúc nó ra làm sao thì làm sao mà thâm nhập? Cho dù thâm nhập rồi mà không biết đường đi nước bước thì có nước đứng đó... ngẩn tò te thôi. Như cái vụ 'anh già' và tao đánh cuộc đây này, ảnh cho tao luôn cả account name và password để vào máy chủ luôn đó nhưng sau đó thì... bó tay vì không biết làm gì hết." 

"haothu" reo lên thích thú: 
"Á à, vậy mày chịu thua rồi hả Hưng? Mày đóng vai là tay phòng thủ mà lại ngẩn tò te thì thua non đi cho rồi con ơi." 

Tôi xen ngay vào để 'nắn' câu chuyện khỏi lạc đề: 
"Anh thấy Duy có những nhận xét rất cẩn thận và lý thú. Hưng và Khoa cũng có lý đứng trên quan điểm của mỗi phía. Tuy nhiên, điểm cần xác định thêm ở đây là trình độ của cả 'kẻ công' chọi với 'người thủ' là thế nào? Nếu 'kẻ công' là một tay cực kỳ kinh nghiệm và 'người thủ' là một tay mơ thì cán cân sẽ khác rõ. Ngược lại 'người thủ' là một tay từng trải và 'kẻ công' là một tay ứng dụng phương thức... mò thì kết quả cũng quá hiển nhiên. Có lẽ mình nên xác định lại một cách cụ thể trình độ và kinh nghiệm của hai tay này cho thoả đáng." 

"cuti" nhảy ngay vào: 
"Dạ, nếu vậy thì cứ cho là cả hai tay đều rành Linux như nhau, có 5 năm kinh nghiệm như nhau, có khả năng thiết lập máy chủ như nhau. Vậy thì 'phòng thủ' sẽ thủng hay, 'tấn công' sẽ bó tay?" 

"docco" lên tiếng: 
"Em thấy cách xác định hai tay này có trình độ ngang nhau để so sánh hai phía công / thủ là công bình nhất. Ở cỡ tụi em, nếu thằng Hưng mà thiết lập một server và thằng Khoa thì dùng mấy thứ đồ nghề khai thác có sẵn trên Internet thì em tin rằng thằng Hưng sẽ bị thủng vì nó chưa nắm được cách phòng thủ cho đúng mức. Trong khi đó, thằng Khoa không cần biết nhiều về Linux, nó chỉ thử hết cái này đến cái kia thì rốt cuộc cũng vào được máy chủ kia mà thôi." 

"haothu" chêm vào: 
"Hẳn nhiên rồi." 

"cuti" cay cú: 
"Mấy thằng này đầu xi măng hay sao mà nói mãi không lay nhỉ? Tao nói là cỡ thằng Khoa có cho account để vào cũng chống mắt mà nhìn chớ biết làm khỉ gì." 

Tôi vội vàng xen vào: 
"Hưng làm gì mà cay cú vậy em? . Vậy thì mình phải thêm một yếu tố để so sánh: tay 'tấn công' phải thâm nhập và thay đổi cách làm việc của hệ thống, nếu vào được rồi mà ngồi đó... ngó thì không thể gọi là 'tấn công'. Còn tay 'phòng thủ' phải làm sao không cho chuyện thâm nhập xảy ra. Ngay cả có thâm nhập được rồi cũng 'ngồi đó mà ngó' thì phía phòng thủ thắng chớ gì?" 

"cuti" nhanh nhảu: 
"Hì hì, chắc anh hơi ngạc nhiên với cách nói chuyện của bọn em hả? Bọn em ăn nói bất kể lắm nhưng không có ý gì đâu anh. Chắc anh không khó chịu chớ? Còn yếu tố anh đưa ra thêm em thấy hoàn toàn có lý." 

"docco" đáp lời: 
"Nếu theo đúng các yếu tố anh đưa ra để có thể so sánh thì em nghĩ bọn em không đủ sức so sánh cho xác thực. Bởi vì thật tình mà nói, thâm nhập cũng như bảo vệ có quá nhiều trường hợp, có quá nhiều tầng. Nhìn hai mặt của vấn đề đều thấy sự phức tạp của chúng." 

Một lần nữa, tôi thầm cảm mến tính chững chạc và cẩn thận của "docco". Rõ ràng những nhận định của "docco" đánh đổ trọn bộ những nhận xét và ý kiến mang nặng cảm tính. Tôi đáp: 
"Em nhận xét tinh tế và cẩn thận lắm Duy. Nếu so sánh, mình cần phải nhìn cả hai mặt của vấn đề. Nếu thiên vị mặt nào thì mặt ấy sẽ nặng hơn và nhận xét trở nên thiếu chính xác. Như vậy làm sao mình đánh giá thật sự cần biết 'công' trước hay biết 'thủ' trước thì mới bảo mật tốt theo đúng tin thần của cuộc bàn cãi?" 

"cuti" vẫn khăng khăng: 
"Thủ trước. Em vẫn nghĩ là thủ trước." 

"haothu" không nhường bước: 
"Công trước. Em vẫn tin là công trước." 

"docco" vẫn trung hoà: 
"Em không xác định được. Anh có ý kiến gì không vậy?" 

Tôi đáp: 
"Hãy tóm lược lại 'bài toán' của chúng ta: có hai nhân vật, một kẻ chuyên 'công', một người chuyên 'thủ'. Cả hai có kinh nghiệm tương đương nhau, đều nắm rõ hệ thống như nhau nhưng đào luyện với tinh thần khác nhau. Kẻ 'công' thì nhìn vấn đề từ phía 'công', có nghĩa là hắn ta phải nắm rõ hệ thống để có thể tìm ra những điểm yếu cho việc thâm nhập và tấn công. Trong khi đó, người 'thủ' thì nhìn vấn đề từ hướng 'thủ', có nghĩa là hắn nắm rất rõ hệ thống mình thiết kế, biết chọn lọc những dịch vụ cần thiết, biết thắt chặt những điểm hở. Trong 'cuộc đấu' này, nếu kẻ 'công' có thể thâm nhập và thay đổi được hệ thống làm việc, hắn nắm phần thắng. Nếu kẻ thủ 'phòng thủ' quá chặt kiến cho kẻ công không thể thâm nhập và thay đổi hệ thống, 'kẻ thủ' thắng. Liệu anh tóm lược như vậy đủ chưa?" 

Bộ ba Hưng, Khoa và Duy đều im lặng hồi lâu. "haothu" Khoa là người lên tiếng trước: 
"Em thật tình không biết phải so sánh thế nào." 

"cuti" Hưng tiếp theo: 
"Em nghĩ rằng không thể so sánh được." 

"docco" Duy đá lời sau chót: 
"Theo em, nếu mình phân tích từng trường hợp thâm nhập và phòng thủ một cách tỉ mỉ thì may ra có thể đi đến một kết luận nào đó. Ngoài ra, em bắt đầu tin rằng không thể xác định được nên biết 'công' trước hay nên biết 'thủ' trước. Nói một cách khác, định đề muốn bảo mật cho tốt thì phải biết thâm nhập trước và ngược lại đều thiếu cơ sở." 

Tôi gật gù trước nhận định chặt chẽ của "docco". Chỉ qua vài chục dòng chat, cá tính của mỗi người trong bộ ba này thể hiện thật rõ. "cuti" Hưng nhanh nhảu, thông minh. "haothu" Khoa nóng nảy, trực tính. "docco" Duy chậm chạp nhưng sâu sắc. Vậy mà ba cu cậu chơi rất thân với nhau. Có thể ba cá tính bổ khuyết cho nhau nên chúng thân với nhau chăng? Tôi khơi mào: 
"Vậy, mấy anh em mình có nên 'khai phá' vài trường hợp để xem thử hai định đề muốn bảo mật cho tốt thì phải biết thâm nhập trước hoặc muốn thâm nhập cho giỏi thì phải biết bảo mật trước không?" 

Cả ba cùng reo lên: 
"Dạ." 

"Chơi luôn." 

"Chắc anh là người 'khai phá' chớ bọn em thì không đủ sức rồi " 

Tôi ngẫm nghĩ rồi đáp: 
"Thế này, anh nghĩ để tạo ra một buổi bàn thảo lý thú, mấy anh em mình nên chuẩn bị kỹ lưỡng trước các điểm cần bàn. Hãy hình thành một số trường hợp cụ thể. Đặt tên cho kẻ tấn công, người phòng thủ. Phải quy định xem nên thiết lập một máy chủ ra sao, có những dịch vụ nào. Sau đó mình sẽ phân tích từng 'thử nghiệm' cụ thể cả hai phía. Ví dụ như: 
'kẻ công' = A 
'người thủ' = B 
server của B thiết lập = Z 
dịch vụ của Z = z1, z2, z3... 

Sau đó mới khai triển: 

A xác định footprint Z như thế nào, B ngăn chặn việc này ra làm sao. 
A dò tìm z1, z2, z3 như thế nào, B kiện toàn các dịch vụ này ra làm sao. 
A exploit z1, z2, z3 như thế nào, B thắt chặt các dịch vụ này ra làm sao... 

Mấy anh em mình chat đã khá lâu, anh phải đi. Mình có một tuần để suy nghĩ xem: nếu mình là A thì mình sẽ thăm dò ra sao? thử nghiệm những gì và hành động như thế nào? Nếu mình là B thì mình thiết lập những gì, thắt chặt những gì và đối phó ra sao khi A thâm nhập. 

Thấy được không?" 

"cuti" reo lên trước: 
"Ái chà, được như vậy thì hơi bị... hay. Vậy em sẽ chọn vị trí A hay B?" 

"haothu" cũng không kém hào hứng: 
"Ui chao, phân tích những thứ này đến đầu, đến đũa thì còn gì bằng? Em chọn mình là A được không anh?" 

Như thường lệ, "docco" trả lời sau cùng: 
"Em thấy ý kiến này tuyệt diệu. Nó tạo điều kiện cho mình tự đặt mình ở hai phía và tìm giải pháp thích ứng. Sao bọn em không chọn cả A và B để tự lý giải anh nhỉ?" 

Tôi đã không sai lầm khi nhận định rằng "docco" Duy là một cậu bé hết sức điềm đạm và cẩn thận. Tôi đáp: 
"Hoan hô Duy, em đề nghị rất hay. Khi đưa ra các trường hợp ở trên, ý anh là mọi người đều nên lý giải hai mặt của vấn đề. Có như thế thì mình mới hình thành một cái nhìn toàn diện, không thì bị rơi vào tình trạng thiên vị và bởi thế, không thể khai phá đến nơi, đến chốn." 

"cuti" phụng phịu" 
"Trời ơi, một tuần làm sao mà đủ thời gian để tìm hiểu hết những chuyện cần tìm hiểu anh?" 

Tôi đáp: 
"Hì hì, bộ em nghĩ trong một tuần bọn mình nắm được cặn kẽ vấn đề hay sao em? Anh không nghĩ thế đâu. Một tuần để bọn em tự hình dung những điểm tổng thể. Khai triển và 'đào xới' thì không biết chừng nào mới xong. Em chỉ thử hình dung xem một máy chủ thông thường cần có những gì? và một máy chủ như thế nếu 'bị' tấn công thì tấn công vào đâu? Như thế đã là nhiều. Sau đó đám tụi mình mới bàn sâu từng trường hợp. Vậy hả?" 

"cuti" lẩm nhẩm: 
"Vậy là sắp thêm 'những đêm không ngủ'." 

"haothu" phấn khích: 
"Ái chà, trúng 'mánh' rồi." 

"docco" điềm đạm: 
"Quả là một điều kiện để học hỏi và nghiên cứu một cách tuyệt vời!" 

Tôi kết thúc: 
"Rồi nha, Chủ Nhật tuần sau, cũng vào giờ này. 'cuti' nên nhớ đến '4 đê' nha em? Chào Khoa, chào Duy." 

và tôi logoff. 
19/7/2005 

9. "Hai mặt" của vấn đề - cơ chế làm việc: 
Không ngoài dự phỏng, tôi liên tục nhận mail từ bộ ba Khoa, Duy, Hưng. Một lần nữa, tôi cố trả lời hầu hết các e-mail từ bộ ba này bằng thông điệp ngắn gọn: 
"Em nghĩ điều em thắc mắc là 'what' hay là 'why'? Anh nghĩ nó là 'what' chớ chẳng phải là 'why' cho nên em nên xem sách đi rồi hỏi anh cái 'why' " 

Tuy vậy, bộ ba này không hề mệt mỏi trong chuyện hỏi, hỏi và hỏi. Trong tuần này, tôi nhận được e-mail từ "haothu" Khoa có một phần nội dung như sau: 
"Anh thân mến, 

Rốt cuộc bọn em đã đi đến quyết định tạo một máy chủ gồm có các dịch vụ: web, mail và ssh cho remote control bởi vì thật ra những dịch vụ râu ria khác không cần thiết. Bọn em chia 'công tác' ra thành ba phần: Hưng lo việc thiết kế và cài dịch vụ web, em thì lo dịch vụ mail còn Duy thì lo dịch vụ secure shell. Tuy nhiên, khi ba dịch vụ này hoàn thành, bọn em phải cùng điều chỉnh chi tiết cho mỗi dịch vụ. Cái khó là bọn em (em và Duy) chẳng có con server nào để vọc cho nên phải chạy qua nhà thằng Hưng thường xuyên. Thời gian thì rất hạn hẹp nên sau khi hỏi thăm ý kiến của anh nhiều lần, bọn em cũng chưa hoàn tất cái gì cho ra đầu đũa. Em có vài điều cần hỏi anh, mong anh trả lời dùm em (nếu rảnh): 

1. nếu bọn em chỉ dùng ba dịch vụ web, mail và ssh, làm cách nào mình có thể tắt hết các dịch vụ khác không cần thiết hở anh? hay là dùng firewall để che hết những dịch vụ không cần thiết và không phải lo những dịch vụ không cần thiết kia? 

2. sau khi ngâm cứu, bọn em hiểu rằng nếu dịch vụ web chỉ phục vụ dữ liệu tĩnh (static content) thì cơ hội có thể thâm nhập và tấn công dịch vụ web thành công sẽ rất thấp. Bởi vậy bọn em nghĩ đến chuyện tạo dịch vụ web có phục vụ dữ liệu động (dynamic content). Nếu thế, phải dính đến php, CSDL (mysql hay cái gì đó) mà bọn em chẳng đứa nào rành mấy cái món này. Anh nghĩ bọn em nên dành thời gian học thêm về chuyện thiết lập server chạy php, thiết lập mysql không anh? Nếu vậy thì biết chừng nào bọn em xong cái server để mà... quậy bây giờ?  

3. nếu câu hỏi thứ 2 không có cách giải quyết liền, em đề nghị thế này: hay là mấy anh em mình chọn một máy chủ nào đó có sẵn trên web rồi cứ dùng nó mà... khai thác. Được không anh? 

Mong anh sớm hồi âm bọn em. 

Thân, 
Khoa." 

Đọc e-mail này của "haothu" Khoa tôi không hỏi nghĩ ngợi để tìm cách trả lời cho đúng mức. Hiển nhiên "haothu" Khoa nhà ta rất hăm hở với chuyện thâm nhập và tấn công nên mới đặt vấn đề như trên. Phải sau hai ngày và sau nhiều lần tranh thủ khi rảnh tôi mới hoàn thành mail trả lời cho Khoa như sau: 
"Khoa thân mến, 

Anh mất hai ngày mới có thể trả lời mail cho em. Trước tiên, anh có nhận xét là em vẫn chưa (muốn) nhìn vấn đề từ hai phía mà em chỉ thích chuyên chú theo hướng tấn công. Nếu em chưa có thể thiết lập, cài đặt một máy chủ có các dịch vụ nào đó ở mức đạt thì em không thể tấn công và khai thác một máy chủ khác cũng được thiết lập ở mức đạt này hoặc hơn. Anh hy vọng sau khi anh em mình trao đổi sâu hơn vào từng vấn đề, em sẽ hiểu ý anh. Bây giờ anh trả lời các câu hỏi của em tuần tự như sau: 

1. trên nguyên tắc, nếu em dùng một dạng firewall nào đó và cản lọc trọn bộ các dịch vụ trên máy chủ, ngoại trừ các dịch vụ em cho phép thì các truy cập từ bên ngoài đến những dịch vụ đã bị cản lọc không thể xảy ra được (nếu như firewall của em chặt chẽ). Tuy nhiên, em nên xét lại các trường hợp có thể xảy ra như sau: 
- chuyện gì xảy ra nếu firewall của em bị hổng chỗ nào đó và nó cho phép truy cập đến vài dịch vụ 'chết người'? 
- chuyện gì xảy ra nếu tài nguyên của máy chủ có giới hạn nhất định nhưng lại tiêu tốn cho các dịch vụ không cần thiết? Hãy nhìn nhận vấn đề ở khía cạnh em đang thiết kế một máy chủ cung cấp dịch vụ thật sự và có hàng ngàn người truy cập nó xem?  

Bởi thế, ý kiến cá nhân của anh là: tắt bỏ mọi dịch vụ không cần thiết cho dù em có firewall bảo vệ và cho dù firewall của em hoàn toàn vững. 

Để tắt bỏ các dịch vụ trên máy thì có 2 phần chính em cần xem xét: dịch vụ được tạo ra từ inetd/xinetd và dịch vụ tạo ra từ run level scripts (trong rc.d). Nếu em dùng RedHat hoặc các distro dựa RedHat thì em có thể dùng tiện ích chkconfig để kiểm tra xem có những dịch vụ nào đang hoạt động trên máy. Nếu em không dùng RedHat thì điều em cần tìm hiểu chính là inetd/xinetd và dịch vụ tạo ra từ run level scripts. Tại sao em nên cần tìm hiểu những cái này? Lý do: một khi đã hiểu rõ cơ chế khởi tạo dịch vụ của một *nix server, em sẽ bắt đầu nắm được điểm mạnh của nó ở đâu, điểm yếu của nó ở đâu. Nếu em có cái nhìn thiên về hướng "exploit" thì tự nhiên em sẽ thấy chúng dễ (hay khó) bị khai thác như thế nào nếu như điều chỉnh không kỹ (hoặc kỹ). inetd là gì?, xinetd là gì?, run level là gì?, initialization / startup scripts là gì? 

2. Bọn em đã xác định được 'static web' ít bị khai thác hơn 'dynamic web' thì đã hình thành một cái nền khá tốt để tạo dịch vụ web rồi đó. Tất nhiên muốn nó 'động' thì em phải làm cho nó 'động'. Không nhất thiết phải dùng php mà bất cứ cái gì (cgi, asp, jsp...) đều được cả. Bọn em sở trường 'món' nào thì cứ dùng 'món' đó. Cái chính mình cần khai phá ở đây là thể trạng 'động' của một web server và nó dẫn đến những lỗ hổng gì chớ không cần phải đi sâu vào từng công nghệ để phân tích và ứng dụng chúng. Nếu bọn em chưa hề có sở trường 'món' nào thì phải chọn lấy một 'món' và bắt đầu học + khai triển. Em có thể phàn nàn là: học như thế biết chừng nào xong và anh có thể trả lời là: chừng nào em không biết php làm việc ra sao, chừng ấy em không thể khai thác php. Câu này dành cho mọi công nghệ em muốn dùng. 

3. Câu thứ ba làm cho anh phải đắn đo trước khi trả lời em. Điều anh muốn bàn thảo với bọn em lúc này là hai mặt của vấn đề. Đề nghị của em có một số điểm khá kẹt: 
- nó làm hỏng tinh thần khai phá hai mặt của vấn đề. 
- nó đi ra ngoài khuôn khổ học tập (anh không chủ trương chọn đại một server nào đó không phải của mình để làm thí điểm). 
- nó sẽ không giúp bọn em đi cho đúng bước và từ đó khó hình thành một cái nhìn đúng đắn về security. 

Qua những điểm trên, anh thấy đề nghị thứ ba này của em không thích hợp. Nếu như em đã đọc kỹ những phần anh và 'cuti' Hưng trao đổi trước đây, em ắt sẽ thấy rõ một điều anh muốn nhấn mạnh: tiếp cận sự việc một cách có quy cách và có ngọn ngành là một điều quan trọng hàng đầu. Nếu bọn em cảm thấy chưa sẵn sàng thì mình dời sang tuần sau. Em thử hội ý với Hưng và Duy xem sao rồi cho anh biết nha. 

Thân." 

Một ngày, hai ngày rồi ba ngày... bộ ba HKD (Hưng, Khoa, Duy) hoàn toàm im ắng. Sao vậy nhỉ? Đến ngày thứ tư, tôi nhận được e-mail từ 'docco' Duy có nội dung như sau: 
"Anh kính mến, 

Đầu thư em xin chúc anh một ngày làm việc vui vẻ. Em rất cảm ơn anh đã dành nhiều thời gian cho bọn em. 

Em mạn phép gởi anh bức e-mail này vì sau khi thằng Khoa nhận được mail của anh, nó than như bọng. Nó sợ trả lời anh không khéo lại bị mắng nữa. Bọn em cùng đọc mail của anh trả lời cho Khoa và đứa nào cũng ngại. Cho nên, đẩy tới, đẩy lui rốt cuộc em phải là người hồi âm cho anh. Bản thân em thì em thấy việc anh từ chối đề nghị của thằng Khoa là hoàn toàn hữu lý. Có lẽ bọn em đứa nào cũng nôn nóng muốn thấy kết quả mà thôi chớ chẳng phải bọn em muốn phá phách gì đâu. Mong anh hiểu cho bọn em. 

Đọc e-mail của anh, em thấy rằng có quá nhiều điều bọn em phải chuẩn bị, phải đi qua, phải thực sự lãnh hội trước khi có thể nhìn vấn đề từ hai phía như anh đưa ra. Lý do rất đơn giản anh ạ. Em nghĩ, cho dù bọn em có thể thiết lập, cài đặt một máy chủ cho nó chạy được (dựa vào e-book và những tài liệu tìm được trên Internet) nhưng để liên hệ đến cấp độ bảo mật hay tấn công, đây là một điều hết sức khó khăn. Bản thân em chưa hình dung ra được cái giềng mối giữa chuyện thiết lập một một máy chủ cho nó chạy và một máy chủ cho nó chạy nhưng bảo mật. Đừng nói chi chuyện khai thác nó. Em xin đơn cử trường hợp SSH chẳng hạn vì nó là phần dịch vụ em phải lo. 

Em đã theo một vài tài liệu how-to để cài SSH thành công. Nó làm việc ngon lành nhưng ngẫm nghĩ mãi em không thể tìm ra chỗ yếu của nó ở đâu để thắt chặt (nói theo phương diện bảo mật) và để khai thác (nói theo phương diện tấn công). Em cũng đã tìm hiểu các lỗi xảy ra với open-ssh trên Internet nhưng đến thế là hết. Em biết chắc phiên bản openssh này em dùng không bị CRC exploit vậy thì muốn thắt chặt thì phải làm sao anh? 

Thằng Hưng cũng lâm vào tình trạng không khác gì em cả. Nó chọn phiên bản mới nhất của Sendmail về cài, cũng khổ sở với mấy cái .cf và .m4 và rốt cuộc cũng tạo được dịch vụ smtp. Tuy nhiên nó cũng đang nặn óc suy nghĩ xem hệ thống mail của nó có gì không vững. Em thì hẳn nhiên là mù tịt chuyện này vì em chưa bao giờ thiết lập sendmail nên cũng chẳng góp ý gì được cho nó. Tội nghiệp, nó thức suốt, ngoáy phá rồi lầm bằm chửi rủa một mình mãi. 

Riêng thằng Khoa thì chẳng tiến triển gì mấy ngoài việc hoàn tất xong cái apache với một trang index.html. Nó đang kẹt cứng vì phải chọn một trong mấy công nghệ php, asp, jsp hay cgi và cái nào cũng đòi hỏi phải nghiên cứu thật sự. 

Em nghĩ có lẽ mấy anh em mình nên bàn đến từng dịch vụ, bàn điểm mạnh và điểm yếu của từng dịch vụ. Từ đó bọn em mới có được cái 'hướng' để khai triển. Anh nghĩ sao? 

Mong anh sớm cho bọn em ý kiến. 

Em chào anh. 

Duy." 

Tôi nhận được mail của "docco" Duy và cảm thấy phấn chấn bởi vì điều quan trọng nhất là cả bọn trong bộ ba kia đều cố gắng tiếp cận vấn đề một cách nghiêm túc và say mê. Thiếu nền tảng này, mọi dự định khai phá sẽ chẳng đi tới đâu. Tôi liền hồi âm cho "bộ ba" như sau: 
"Chào Hưng, Duy và Khoa, 
Anh đã nhận được mail của Duy, đã đọc. Anh dự phỏng thế nào bọn em cũng gặp những trở ngại. Mình nên xem những trở ngại này là chuyện hiển nhiên và đừng vội nản. Bọn em nên tìm hiểu kỹ lưỡng hơn cơ chế làm việc của từng dịch vụ mình muốn thiết lập. Đây là chuyện cần thiết vì nó sẽ giúp cho việc bàn thảo của mấy anh em mình dễ dàng hơn. 

Chiều thứ Bảy tuần tới anh rảnh. Anh sẽ online khoảng 1 giờ trưa giờ VN. Nếu bọn em thấy ổn thì cho anh biết nha. 

Thân." 

Ngày hôm sau tôi nhận được một thông điệp ngắn gọn từ "cuti" Hưng trên YIM: 
"Chào anh già, bọn em sẽ online lúc 1 giờ chiều thứ Bảy tuần sau như anh đã hẹn." 

Thêm một tuần lễ trôi qua. Tôi chẳng hề nhận thông điệp nào từ bộ ba. Có lẽ cả bọn đang 'chúi đầu' vào xem xét cái gọi là "cơ chế làm việc". Chiều nay, chiều thứ Bảy, tôi log vào YIM như đã hẹn. "cuti" Hưng và "docco" Duy đang ngồi chờ. "haothu" Khoa đâu nhỉ? Tôi gởi "cuti" một thông điệp: 
"Hello Hưng, anh đã online đây. "haothu" Khoa đâu rồi?" 

"cuti" bèn gởi ngay 'lời mời' để vào conference, kèm theo một thông điệp: 
"Dạ, thằng Khoa bị bệnh rồi anh. Em gọi dtdd cho nói thì thấy nó ho khù khụ, than đau đầu, đau cổ búa xua." 

Tôi tiếp nhận lời mời của "cuti" rồi tiếp tục: 
"Vậy hả? tiếc thật. Vậy em nên lưu lại nội dung trao đổi của anh em mình cho nó đọc không thì nó bị thiếu liền lạc nha. Trong bộ ba bọn em, anh hơi ngại cho nó vì nó có vẻ thiếu kiên nhẫn nhất." 

Lúc này "docco" Duy lên tiếng: 
"Chào anh, anh khoẻ không? Bọn em biết rõ tính thằng Khoa mà. Anh nhận xét đúng lắm. Nó thì lúc nào cũng muốn liền liền. Chuyện gì thích là làm ngay, không cần suy nghĩ. Em với nó cứ cãi nhau hoài về khoản này. Thằng Hưng thì... trung tính hơn nên em thấy trao đổi với nó dễ hơn." 

Tôi gật gù. Trong một không gian bé nhỏ, với phương tiện ngôn ngữ 'cà rỡn' mà đám chúng tôi đang trao đổi, vậy mà cái gọi là 'cá tính' vẫn hiển hiện một cách thật rõ ràng. Tôi đáp: 
"Ừa, anh cũng thấy như vậy. Bây giờ anh em mình bắt đầu chớ? Anh đề nghị mình nên phân tích từng dạng dịch vụ thì mới có thể dễ hình thành "hai mặt vấn đề". Bọn em thấy sao?" 

"cuti" đáp lời ngay: 
"Dạ, em thấy cách đó hay nhất. Mình bàn về sendmail trước nha anh? " 

"docco" Duy xen ngay vào: 
"Thôi đi mày, nhào vô là muốn tranh tiên liền hả? Công sức tao gởi mail cho ảnh thì phải được đền bù là đứng đầu danh sách chớ " 

Tôi đáp: 
"Cái nào trước cũng được. Cái nào cũng quan trọng cả. Điều mình cần bàn ở đây không phải cách cài đặt và thiết lập để một dịch vụ chạy được mà là bàn về những điểm có thể thắt chặt (hoặc có thể khai thác) sau khi dịch vụ này đã hoạt động. Anh nghĩ mình nên khởi đầu với SSH vì đây là phương tiện cho phép truy cập trực tiếp vào hệ thống để điều khiển hệ thống." 

"docco" đắc thắng: 
"Hì hì, thấy chưa Hưng? Mày đòi tranh tiên làm chi cho mệt." 

"cuti" tiu nghỉu: 
"Thôi, nhường cho mày đi tiên một lần cũng được." 

Tôi cười, đáp: 
"Làm như oánh cờ tướng không bằng. Đi tiên với đi hậu . Rồi, Duy, em đặt vấn đề đi." 

"docco" Duy ngơ ngác: 
"Dạ.... đặt vấn đề... sao anh?" 

Tôi đáp: 
"Ùm... đặt vấn đề là cho đến lúc này em đã làm được gì với SSH, đã hiểu những gì về cơ chế làm việc của SSH và lý do tại sao em không tìm ra được chỗ nào để thắt chặt nó." 

"docco" Duy im lặng một đỗi rồi bắt đầu: 
"Em hiểu rằng SSH là một phương tiện, một dịch vụ cho phép người dùng truy cập từ xa vào để điều khiển một hệ thống nào đó. Sở dĩ nó là secure shell vì thông tin gởi / nhận từ hai đầu được hoàn toàn mã hoá. Nói về mặt thắt chặt, em đã thử những tài khoản không tồn tại để truy cập và ssh hoàn toàn từ chối, em không biết phải làm gì khác. Nói về mặt khai thác, em cũng thử truy cập từ máy khác vào bằng các tài khoản 'có thể đoán được' nhưng cũng không có cách nào vào được. Đến giai đoạn này em hoàn toàn bế tắc " 

Tôi gợi ý: 
"Nói về phương diện 'cơ chế làm việc' của ssh, em thử phân tích xem: để ssh có thể làm việc được, nó cần những 'cơ phận' nào?" 

"docco" Duy rụt rè: 
"Dạ... tất nhiên là mình phải cần chương trình ssh thì nó mới tạo được dịch vụ chớ anh?" 

Tôi khuyến khích: 
"Đúng lắm. Em thử liệt kê một cách tổng quát xem, gói ssh (chắc em dùng rpm để cài?) gồm có những gì trong đó?" 

"docco" Duy hơi ngập ngừng như thể cu cậu không tự tin ở điều mình sắp nói: 
"Dạ... em nghĩ... em thấy... em cài gói ssh từ rpm đúng rồi đó anh. Nhưng em thấy nó có tùm lum thứ cả. Anh muốn em liệt kê ra hết hả?" 

Tôi cười, đáp: 
"Không em, anh muốn em liệt kê ra hết làm chi? Anh chỉ muốn em có nhận định tổng quát về một gói chương trình thôi. Từ đó em mới hình thành được cơ chế làm việc của nó. Thế này, để anh thử 'nhận định' theo kiểu của anh hả?" 

"docco" vội vã đáp: 
"Dạ, anh 'thử' đi. Ngay từ đầu anh bảo em 'đặt vấn đề' làm em khiếp vía nên không biết phải nói thế nào cho suông nữa." 

Tôi trấn an "docco": 
"Hì hì, có gì đâu mà 'khiếp vía' em? 'đặt vấn đề' là một cách tóm tắt một vấn đề mình cần giải quyết. Phải nắm rõ vấn đề trước khi nghĩ đến giải pháp để giải quyết vấn đề. Nên nhớ, there is no solution for unknown problem. Anh thấy thế này: gói ssh có binaries, có libraries, có configuration files, có init script. Binaries là để khởi tạo chương trình, tuy nhiên, thiếu thư viện, thiếu hồ sơ cấu hình thì dịch vụ không thể hình thành được. Còn init script là một phương tiện để khởi tạo dịch vụ theo đúng trình tự 'run level' trên hệ thống, nó cũng là phương tiện để tắt bỏ dịch vụ đúng quy cách. Vậy, với tư cách của một người dùng, một admin (và không phải là một lập trình viên), yếu tố nào quan trọng nhất quyết định tính năng hoạt động của ssh?" 

"docco" đáp: 
"Dạ em nghĩ hồ sơ cấu hình là yếu tố quan trọng nhất quyết định tính năng hoạt động của ssh. Phải ý anh hồ sơ cấu hình là tập tin không anh? Bọn em bên này toàn là dùng thuật ngữ 'tập tin' không à." 

Tôi cười, đáp: 
"Chính xác! 'tập tin' là yếu tố quan trọng nhất quyết định tính năng hoạt động của ssh. Mình dùng thuật ngữ 'tập tin' đi, mặc dù anh không hoàn toàn đồng ý 'configuration file' được dịch là 'tập tin cấu hình'. Tuy nhiên đây là chuyện khác, nếu có dịp anh em mình 'cãi' chơi cho vui. Vậy, em đã thử 'hack' tập tin cấu hình chưa?" 

Cả hai "cuti" và "docco" cùng sửng sốt hỏi lại: 
"Hack tập tin cấu hình?" 
"Hack tập tin cấu hình?" 

"cuti" hỏi thêm: 
"Tập tin cấu hình có gì để hack đâu anh?" 

Tôi cười phá lên rồi thong thả trả lời: 
"Sao không 'hack' được em? Em hỏi thế này chứng tỏ em chưa hoàn toàn 'đả thông' khái niệm 'hack' mà anh em mình đã nhắc tới, nhắc lui nhiều lần. Bất cứ một hành động nào làm thay đổi thái độ hoạt động của hệ thống đều là hack cả. Em cứ bị ám mãi 'hack' == 'thâm nhập'. Khi em dùng một gói rpm có sẵn tập tin cấu hình, có sẵn binaries, libraries... để cài trên máy chủ, hành động này có thể được xem là cài đặt. Ở mức độ cực đoan, nếu người quản lý máy chủ (không phải em) không muốn cài ssh nhưng bằng cách gì đó em lại cài ssh trên máy thì đây cũng là hành động hack. Bởi vì em đã thay đổi thái độ làm việc của máy chủ. Nếu em là người quản lý máy chủ và quyết định cài gói rpm của ssh, không điều chỉnh bất cứ thứ gì và chỉ khởi tạo dịch vụ ssh thì đây là cài đặt. Ngay khi em dùng vi để mở cái sshd_config để táy máy và 'save' nó, em đã thực hiện việc 'hack'. Nếu em 'hack' dở quá, ssh không chạy nữa thì cũng là 'hack' (nhưng dở). Nếu em 'hack' thiếu cẩn thận và làm cho ssh không còn bảo mật nữa thì cũng là 'hack' (nhưng không cẩn thận). Anh hy vọng giải thích như thế này tạm để em hiểu hơn thế nào là 'hack' " 

"cuti" rên rỉ: 
"Ôi trời. Chỉ thế thôi sao anh? Vậy là hack hả? . Thôi rồi, mọi thứ sụp đổ." 

Đến lúc này "docco" Duy vẫn chưa lên tiếng. Có lẽ cu cậu đang ngẫm nghĩ gì đây nên tôi trả lời tiếp: 
"Sao lại 'chỉ thế thôi' em? Những ví dụ anh đưa ra ở trên là một trong những ví dụ thuộc dạng 'hack'. Tất nhiên là 'hack' không 'chỉ là thế thôi' . Này, mình thử đi sâu hơn một tí là em sẽ thấy rõ hơn. Đồng ý không?" 

"docco" Duy cất tiếng: 
"Thú thật em cũng bị hụt hẫng bởi mấy cái ví dụ của anh. Có lẽ trước giờ em bị tẩy não bởi những mẩu chuyện màu mè hoa lá cành, những huyền thoại về cái gọi là 'hack' nên cứ ngỡ rằng 'hack' là những hành động nào đó cao siêu và mầu nhiệm để phá vỡ một hệ thống làm việc. Ngờ đâu anh lại dùng vài ví dụ hết sức đơn giản để minh hoạ 'hack'. Có lẽ em cần phải điều chỉnh lại một số quan niệm mà em đã 'quen' từ trước đến giờ." 

Tôi trầm ngâm khi đọc đoạn đối thoại của "docco" Duy và tìm cách trả lời cu cậu sao cho đầy đủ, súc tích. Sau đó, tôi nói: 
"Thế này. Em nghĩ rằng những ví dụ anh đưa ra ở trên là đơn giản thật sao? Anh thì không nghĩ thế. Anh cho rằng chúng phức tạp như bao nhiêu chuyện phức tạp khác. Việc 'hack' để phá vỡ một hệ thống làm việc chỉ là 'một mặt của vấn đề'; 'hack' còn có mục đích chống lại hành vi phá vỡ nữa. Để anh chứng minh cho mà xem. 

1. nói về chuyện điều chỉnh sshd_config, hãy xem thử cấu hình chung chung như sau: 
Code:

Port 22
ListenAddress 203.210.205.200
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa_key
ServerKeyBits 768
LoginGraceTime 60
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts no
IgnoreUserKnownHosts yes
StrictModes no
X11Forwarding yes
PrintMotd yes
KeepAlive yes
SyslogFacility AUTH
LogLevel INFO
RhostsAuthentication yes
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Nếu không hiểu tường tận từng giá trị, làm sao em có thể biết được giá trị nào có nguy cơ 'làm giảm' độ bảo mật? Vậy chỉnh lý thế nào để giảm những 'nguy cơ' có thể xảy ra? Làm sao em xác định được giá trị nào là thích hợp? Cách bảo đảm nhất (và cũng đau khổ nhất) là điều chỉnh từng giá trị, khởi động lại sshd rồi thử nghiệm. Đây là công việc rất mất thời gian và cần sự kiên nhẫn và tất nhiên là không đơn giản tí nào. Tập tin này ở dạng mặc định thường có các giá trị cấu hình căn bản nhất và thoải mái nhất nhằm mục đích 'dùng được liền' cho mọi người. Nếu em không điều chỉnh lại thì hoàn toàn không mang tính chất gì gọi là 'bảo mật' cả. Cũng chính vì thế mà những kẻ muốn tấn công thường dựa vào những điểm 'thoải mái' trong tập tin cấu hình mặc định mà khai thác. 

2. bởi vì em cài đặt nó từ một rpm và mọi thứ đều được sắp xếp đâu vào đó, em chỉ chạy /etc/rc.d/sshd start là dịch vụ này sẵn sàng phục vụ --> xem có vẻ đơn giản. Nếu như em không muốn cài từ rpm mà muốn biên dịch trọn bộ từ nguồn vì một lý do gì đó (vì rpm chưa kịp cập nhật hay vì em muốn điều chỉnh cái gì đó trong mã nguồn). Liệu nó có đơn giản không? Câu trả lời là không. Bởi vì em phải điều chỉnh mọi thứ cho thích hợp, phải tạo ra init script nếu chưa có sẵn, phải điều chỉnh lại LD_LIBRARY_PATH để các binaries biết dùng thư viện nào cho đúng, em phải điều chỉnh là PATH, em phải bảo đảm vấn đề dependency hoàn toàn đâu vào đó. Sau đó em phải điều chỉnh lại sshd_config. 

Anh không tin là trọn bộ thao tác đơn giản và dễ dàng tí nào." 

"cuti" dường như cũng có cùng bức xúc như "docco" nên hưởng ứng thêm: 
"Quả là phức tạp nhưng em vẫn thắc mắc là việc điều chỉnh sshd_config nằm ở giới hạn điều chỉnh chớ sao gọi là hack được anh?" 

Tôi cười, đáp: 
"Ừa, em nghĩ đó là điều chỉnh cũng hợp lý nhưng theo cách nhìn của anh, nếu em thay đổi cấu hình mặc định của một dịch vụ để thay đổi thái độ làm việc của nó thì đó là 'hack'. Kiện toàn bảo mật cho sshd (cũng như các dịch vụ khác) không chỉ dừng lại ở chính tập tin cấu hình của nó mà còn phải xét duyệt, điều chỉnh những thứ xung quanh nó. Ví dụ, em biên dịch lại ssh để áp đặt dùng pam (plugable authentication module) và sau đó điều chỉnh pam dành riêng cho ssh có thái độ cụ thể nào đó chẳng hạn. Những công việc này đều là 'hack'. Anh đơn cử một ví dụ rất đơn giản: anh điều chỉnh lại giá trị #VERSION của ssh trước khi biên dịch lại nó từ mã nguồn với mục đích dấu footprint, cái này hẳn nhiên là 'hack' rồi ." 

Cả "cuti" và "docco" đều trầm ngâm hồi lâu. Sau đó "docco" lên tiếng: 
"Bây giờ em mới thấy khái niệm quan trọng như thế nào. Khái niệm được hình thành một cách sai lạc và què quặc thì sẽ dẫn đến hàng loạt các sai lạc khác. Vẫn với chủ đề tập tin cấu hình sshd_config, anh có thể phân tích thêm theo phương diện tấn công được không anh?" 

Tôi đáp: 
"Được chớ em. Hãy thử 'đào xới' giá trị thứ nhất Port 22. Ai cũng biết đây là cổng chính thức của dịch vụ ssh. Nếu muốn táy máy, anh chỉ cần thử một dòng nmap đã đủ có thể xác định xem có dịch vụ ssh trên máy chủ hay không rồi: 
Code:

[conmeo@home conmale]# /usr/local/bin/nmap -sT someserver.somedomain.com -p 22 -v

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:04 EST
Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:04
Discovered open port 22/tcp on xx.xx.xx.xx
The Connect() Scan took 0.23s to scan 1 total ports.
Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
PORT      STATE SERVICE
22/tcp open  SSH
Nmap finished: 1 IP address (1 host up) scanned in 1.464 seconds
               Raw packets sent: 2 (68B) | Rcvd: 1 (46B)

Nếu cần, anh có thể thêm một thông số để xác định phiên bản của ssh: 
Code:

[conmeo@home conmale]# /usr/local/bin/nmap -sT -sV someserver.somedomain.com -p 22 -v

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:03 EST
Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:03
Discovered open port 64321/tcp on xx.xx.xx.xx
The Connect() Scan took 0.23s to scan 1 total ports.
Initiating service scan against 1 service on someserver.somedomain.com (xx.xx.xx.xx) at 17:03
The service scan took 0.47s to scan 1 service on 1 host.
Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
PORT      STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 3.5p1 (protocol 2.0)

Nmap finished: 1 IP address (1 host up) scanned in 2.481 seconds
               Raw packets sent: 2 (68B) | Rcvd: 1 (46B)

Hoặc đơn giản hơn nữa: 
Code:

$ telnet someserver.somedomain.com 22
Trying someserver.somedomain.com...
Connected to someserver.somedomain.com (xx.xx.xx.xx).
Escape character is '^]'.
SSH-2.0-OpenSSH_3.5p1

Từ những thông tin này, anh có thể hình thành một kế hoạch 'đào xới' ssh của em. Nếu như em cần dịch vụ ssh cho chính em (và một số giới hạn người dùng nào đó), tại sao em không đổi cổng 22 thành cổng gì đó nằm trên dãy high ports: 22334 chẳng hạn? Nếu em xoá luôn footprint của ssh thì anh sẽ mất nhiều thời gian hơn để xác định xem có ssh đang lắng nghe hay không? Đôi khi anh bỏ cuộc vì mất thời gian quá . Nếu chỉ có cổng ssh mở ra trên toàn máy chủ và nếu anh phải thâm nhập máy chủ của em thì có một vài cách khai triển: 
a. xem thử phiên bản này có thuộc một trong những bản bị lỗi hay không (đây là cách của đa số perpetrator). 

b. nếu phiên bản này mới hoặc không thuộc diện "known vulnerability" thì mới tiếp tục dò dẫm những điểm sơ hở của cấu hình (đây là cách của những perpetrator cố tình thâm nhập khai triển). 

c. tải mã nguồn của chính phiên bản đang được dùng trên mục tiêu về để 'soi' xem chúng có lỗi gì rồi hình thành phương pháp thâm nhập. Tất nhiên là chỉ có thể nếu có mã nguồn để tải (đây là cách của những 'hacker' thật sự chuyên chú và say mê). 

d. nếu chính mã nguồn của ssh không có lỗi (hoặc không thể tìm ra lỗi), thì tìm lỗi của những thư viện hỗ trợ (ssl, zlib...) bởi vì chúng trực tiếp ảnh hưởng đến bảo mật của ssh (đây cũng là cách của những 'hacker' thật sự chuyên chú và say mê). 

Nếu trên máy chủ của em còn nhiều 'tiềm năng' khác và ssh... 'khó ăn' quá thì không biết chừng, anh lơ đẹp ssh và chuyển sang điểm yếu khác. Cái này còn tuỳ vào mục đích thâm nhập và vai trò của người thâm nhập nữa. Nếu anh là 'ethical hacker' đang làm công tác bảo mật và muốn kiện toàn hệ thống thì anh phải cố exploit mọi điểm có thể tìm được. Nếu anh là 'professional hacker' thì anh tìm bất cứ điểm nào yếu nhất của hệ thống mà khai thác hoặc kết hợp những yếu tố 'yếu' nhất để khai thác để đạt mục đích nhanh chóng nhất. Nếu anh là 'amateur hacker' thì... "từ từ mà mần", lỗ này không được thì thử tiếp lỗ khác." 

"cuti" reo lên: 
"Ồ... nghe 'đã' thiệt! Anh nói thêm nữa đi." 

"docco" thì cẩn thận hơn: 
"Em thấy những điều này thật là lý thú. Em nghĩ rằng bọn em ngay lúc này thì bó tay với điểm c và d rồi đó. Bởi vì có đủ khả năng ngồi 'soi' code thì đúng là cao thủ rồi. Vậy, những giềng mối của "hai mặt vấn đề" trong điểm a và b là sao anh?" 

"docco" quả là ranh mãnh . Tôi mỉm cười và nói tiếp: 
"Rồi, 'hai mặt của vấn đề' trên điểm a và b thế này. Thử đơn cử một giá trị trong sshd_config là PermitEmptyPasswords yes chẳng hạn. 
- nếu anh đóng vai trò là B (người thủ): và anh chọn PermitEmptyPasswords yes thì anh bị sút 'kẻ công' một điểm. Bảo mật không tha thứ cho thiếu sót, lại càng không tha thứ cho thiếu nghiên cứu và 'lờ' bất cứ chi tiết nào. 

- nếu anh đóng vai trò là A (kẻ công): anh có thể enumerate ra danh sách user trên server bằng phương tiện nào khác và cứ đơn giản logon server của em bằng username mà không cần password. Thế nào anh cũng tìm ra được account không có password (nếu như em thiết kế thiếu cẩn thận). Sau khi login được rồi thì chuyện privilege escalation là một chuyện khác. 

Vậy, với tư cách là B, làm sao anh biết giá trị PermitEmptyPasswords yes là nguy hiểm? Tất nhiên là anh phải nghiên cứu tài liệu cụ thể của ssh và thử nghiệm một cách tỉ mỉ và cẩn thận. Với tư cách là A, làm sao anh biết giá trị PermitEmptyPasswords yes có thể là cơ hội đạt kết quả? Tất nhiên anh cũng phải nghiên cứu tài liệu cụ thể của ssh thì mới biết được có cái 'màn' empty password ở đây. Nếu không thì việc gì anh bỏ thời gian ra để enumerate account rồi ngồi đó mà thử 'empty password'? 

'Hai mặt vấn đề' ở đây quy tụ lại một điểm: cả A và B đều phải biết rõ ssh có những chức năng gì? có thể 'hở' ở những điểm nào? Kẻ công thì khai thác những điểm nào bị 'hở', người thủ thì lo bít những điểm có thể bị 'hở'. Nhìn từ hai phía, cả hai đều phải có kiến thức. Nên nhớ, những điều kẻ công A làm (mình bàn ở đây) chưa phải là 'hack' mà chỉ là kỹ thuật dò tìm và thâm nhập. Đừng lẫn lộn nó với 'hack'. Ở bước này, A chưa hề làm gì để thay đổi thái độ làm việc của hệ thống cả." 

"cuti" thốt lên: 
"Thật thú vị. Em cứ ngỡ những người thích thâm nhập có những công thức hay đồ nghề bí mật gì đó. Không ngờ sự thể đơn giản và dễ hiểu đến thế. Nhưng sao ssh lại cung cấp chọn lựa 'empty password' chuối quá vậy anh? Làm thế thì còn gì là bảo mật?" 

"docco" xen vào: 
"Thôi đi mày ơi, làm sao mà đơn giản? Nhờ ổng phân tích thì mới thấy đơn giản và dễ hiểu chớ thực tế thì trước mắt bọn mình phải 'xoi' qua cuốn sách nói về ssh để thử nghiệm từng giá trị trong tập tin cấu hình rồi đó." 

"cuti" chống chế: 
"Thì tao có nói gì gì đâu. Ý tao là sau khi được giải thích rồi mới thấy nó dễ hiểu. Mày thì lúc nào cũng giỏi bắt bẻ." 

Tôi xen ngăn ngay trận khẩu chiến: 
"Thôi, thôi hai trự. Sở dĩ thấy nó có vẻ đơn giản bởi vì nó có nguồn gốc, căn nguyên rõ ràng. Công thức thì anh nghĩ chẳng có công thức gì hết, chỉ có những bước khai triển dựa trên tình hình, thông tin lấy được và hoàn cảnh mà thôi. Cái này có thể xem là nguyên tắc chớ không thể xem là công thức. Còn công cụ thì chủ yếu là tự chế mà thôi, bởi vì mỗi hoàn cảnh, mỗi đòi hỏi cần một thứ công cụ khác nhau. Có những công cụ có sẵn và cực hay dành để dò tìm thông tin như nmap chẳng hạn. Có thể ứng dụng nó trong mọi hoàn cảnh vì lấy footprint là một bước hầu như không thể thiếu. Tuy nhiên, những thao tác để thử 'xâm nhập' thì quá nhiều và quá rộng cho nên cách hay nhất và cụ thể nhất là tự tạo cho mình công cụ. 

Riêng chuyện ssh cho phép 'empty password' là chuối thì.... hèm... mình phải nhìn vấn đề một cách rộng hơn. Không riêng gì ssh mà dịch vụ nào cũng có hai mặt: tiện dụng và bảo mật. Một chương trình có nhiều chức năng, linh động trong cấu hình, cho phép lựa chọn thì lại dễ vướng vào chuyện 'yếu' bảo mật. Một chương trình muốn bảo mật thì lại giới hạn chức năng và lựa chọn. Bởi vậy, công tác của người làm bảo mật là tạo nên sự cân bằng giữa tiện dụng và bảo mật. Trong khi đó, vai trò của kẻ tấn công là tìm ra những điểm yếu của sự thiếu cân bằng giữa tiện dụng và bảo mật để thâm nhập." 

"cuti" rú lên: 
"Trời ơi. Nếu mình dành thời gian ngồi đó viết chương trình thì chừng nào cho xong anh?" 

Tôi ngắt lời "cuti": 
"Đó đó, em lại bị sa vào 'cõi' thiếu kiên nhẫn rồi. Anh ví dụ trường hợp SSH tiếp nhận "empty password" ở đây, em có thể dùng Perl hay ngay cả shell script để tự động hoá thao tác truy cập. Cách này đúng ra còn nhanh hơn là dò tìm xem có công cụ nào làm cho việc này. Anh nghĩ cùng lắm là một chục dòng code là xong. Muốn 'đao to búa lớn' hơn nữa thì thử dùng C hoặc một số ngôn ngữ khác. Không những nhanh hơn chuyện tìm kiếm công cụ, nó còn bảo đảm kết quả em muốn tìm bởi vì chính em viết ra." 

"cuti" vẫn rên rỉ: 
"Trời, cấu hình cho cái dịch vụ chưa nên dáng. Bây giờ lại thêm chuyện viết công cụ để 'thâm nhập' nó . Sao mà mênh mông quá vậy trời?" 

"docco" thắc mắc: 
"Em muốn hỏi thêm điểm này. Theo anh nói, những người dùng các công cụ có sẵn để tìm đường vào hiển nhiên là... mò. Mình viết script để tìm đường vào trong trường hợp 'empty password' ở đây em nghĩ cũng là... mò luôn. Vậy sao không dùng công cụ có sẵn để mò hở anh? Như vậy không dễ dàng hơn sao?" 

Tôi cười đáp: 
"Em thắc mắc một điểm rất lý thú đó Duy. Trường hợp 'mò' empty password ở đây cũng có thể xem là... mò. Tuy nhiên điểm khác biệt lớn lao là 'mò' ở đây là 'mò' có căn, còn 'mò' theo kiểu dùng một công cụ có sẵn và cứ 'phang' đại thì đó là 'mò'... mù . Nói một cách khác, 'mò' empty password ở đây là một hành động có chủ đích, nhắm vào một điểm rất cụ thể để đột phá sơ hở của cấu hình ssh. Như anh đã có lần đề cập, 'script kiddie' chỉ cần khởi động một công cụ có sẵn và nhắm mắt mà chạy, không cần biết công cụ này làm gì. Nếu không có kết quả gì hết thì 'kiddie' này... bế tắc. Trong khi đó, nếu em tự viết một công cụ cho một mục đích cụ thể nào đó, em biết chính xác chuyện gì xảy ra. Nếu em thử viết script để truy cập: thành công, nó cho kết quả; không thành công, không có kết quả gì cả. Ít nhất em có thể thu thập được ở đây là xác định được dịch vụ ssh này không cho (hoặc cho phép) empty password." 

"docco" trả lời: 
"Dạ, quả thật có khác nhau. Em nghĩ là em được đả thông chuyện này rồi đó, thật là đã. Vậy bọn em phải ngâm cứu thật kỹ cấu hình của mỗi dịch vụ rồi chắc phải nhờ anh 'chỉ điểm' thêm quá." 

Tôi đáp: 
"Ừa, để mình có thể bàn ở cấp độ 'công' hay 'thủ' thì phải thật sự nắm vững cấu hình của dịch vụ và biết rõ lý do tại sao mình quyết định như vậy. Anh phải đi rồi. Nếu muốn, tuần sau mình tiếp tục hả?" 

"cuti" lém lỉnh: 
"Dạ, nhất định tuần sau anh em mình sẽ có những chuyện lý thú hơn bởi vì sẽ đụng đến phần của em ." 

Tôi đáp: 
"Ừa, chưa biết sẽ 'lý thú' hơn hay 'đau đầu' hơn đó em. Em xem thử sendmail có thể bị 'thủng' ở đâu rồi mình bàn hả? Duy, em xem thử sau một tuần ngâm cứu em sẽ có những thắc mắc gì về SSH nha? Chào Duy, chào Hưng." 

Tôi xếp laptop lại. 


30/7/2005 

10. "Hai mặt" của vấn đề - 'nhu cầu cụ thể': 
Tuần này, tôi liên tục nhận mail và offline message từ bộ ba Khoa, Hưng, Duy nhưng 'docco' Duy là người gởi nhiều nhất và thường xuyên nhất. Điều làm tôi thích thú khi đọc mail và offline messages của 'docco' là vì tính chín chắn và cẩn thận của cu cậu. Hẳn nhiên 'docco' Duy vẫn phảng phất hơi hám của một 'rookie', điều này hẳn không tránh khỏi nhưng so với 'cuti' và 'haothu', những phát biểu và nhận định của 'docco' có trọng lượng khác hẳn. Có lẽ cu cậu đã suy nghĩ kỹ trước khi nói. Tôi cảm mến từng cậu trong bộ ba này, mỗi người một vẻ, mỗi người đều có ưu khuyết điểm. Tuy nhiên, một điều làm tôi cảm thấy không bị 'phí' là cả ba cậu đều tỏ vẻ thật sự chuyên chú vào những điều chúng tôi bàn cãi. 

Hôm qua tôi nhận được một e-mail từ 'docco' như sau: 
"Anh D thân mến, 

Sau một hồi truy lùng, em đã biết được tên thật của anh. Thật không ngờ em biết anh đã lâu, từ một nơi khác nhưng không biết anh... chính là anh. Em đã có lúc ngờ ngợ vì cách nói chuyện của anh nhưng không tiện hỏi. Và thế là sau một cuộc dò xét, em đã biết chắc anh chính là người em đã biết và từng trao đổi (không trực tiếp mà chỉ trên một diễn đàn nọ) từ mấy năm trước. Cho em xin lỗi nếu như anh cảm thấy khó chịu khi danh tánh của anh bị em khám phá nha?  Em không có ý gì hết, em chỉ muốn tìm hiểu người mình đang trao đổi. Lý do rất đơn giản là em không hiểu tại sao anh có thể khiến em phải suy nghĩ rất nhiều với những điều mấy anh em mình trao đổi. Cho nên, em mới tò mò tìm hiểu xem thực sự anh là ai. 

Tuần này anh có rảnh không? Khi nào rảnh, anh cho em biết với. Em rất muốn nói chuyện với anh. Em có một số thắc mắc muốn anh giải toả dùm em. Em muốn hỏi những vấn đề thuộc về kỹ năng phân tích. Mấy cái mail với offline message bị tản mạn quá, nếu nói chuyện được thì liền lạc hơn. 

Mong anh sớm hồi âm. Chúc anh một ngày làm việc vui vẻ." 

Tôi tự hỏi không biết 'docco' Duy là ai mà bí hiểm thế. Tôi trả lời mail cho 'docco' như sau: 

"Duy thân mến, 
Thứ Năm tuần này anh có ngày nghỉ bù. Buổi sáng anh rảnh nhưng lúc đó chắc em chưa ngủ dậy. Buổi trưa thì anh phải đi ít công chuyện. Buổi chiều chắc anh rảnh được 1, 2 tiếng. Nếu thấy tiện, cho anh biết để anh online nha? Nhớ rủ luôn hai đứa Hưng, Khoa nếu tụi nó rảnh. Còn chuyện danh tánh... hì hì, sao mày lắm chuyện vậy em?  

Thân." 

Chẳng mấy chốc, tôi nhận được hồi âm của 'docco'. Cu cậu sẽ online chiều thứ Năm. 

Như đã hẹn, tôi làm một ly cà fê và logon YIM vào chiều thứ Năm. 'docco' đã có mặt sẵn nhưng chẳng thấy tăm hơi hai trự Hưng và Khoa đâu cả. Tôi gởi 'docco' một thông điệp: 

"Chào Duy, em vào lâu chưa? Còn hai đứa kia đâu?" 

'docco' trả lời ngay: 
"Dạ, em vào cũng gần một tiếng rồi anh à. Nãy giờ em ngồi lướt web, đọc lăng nhăng mấy bản tin vậy mà. Còn thằng Hưng thì đi Long Hải chơi rồi. Nó nhắn em nó xin lỗi vì không vào được bởi vì bị kẹt 'sô' với gia đình nhưng em nghi nó dẫn con bồ đi Long Hải chơi chớ chẳng gia đình gì đâu, hi hi. Còn thằng Khoa thì hôm nay kẹt đám giỗ gì đó anh, nó không online được." 

Tôi đáp: 
"Ừa, 'cuti' nhà mình đi chơi với bồ thì đó là 'đại sự' cho nó đó em, nó đã muốn dấu mà còn 'khai' với anh làm chi?. Còn trự Khoa bận gia đình thì lần khác cũng được. Thôi thì anh em mình nói chuyện lai rai cũng được." 

'docco' phản đối: 
"Sao lại lai rai anh? Em có những thắc mắc toàn là... gay cấn không đó. Vậy anh thích nói chuyện lai rai hay anh thích nói chuyện kỹ thuật?" 

Tôi cười, đáp: 
"Hì hì, lai rai kỹ thuật được hông?" 

'docco' đáp: 
"Dạ được chớ anh. Miễn có kỹ thuật là đã rồi ." 

Tôi đà khía: 
"Hèm... em có vẻ khoái kỹ thuật lắm hả? Được rồi, để xem bao lâu em sẽ ngán 'kỹ thuật' lên tới cổ ." 

'docco' vẫn một mực: 
"Dạ chắc em chẳng khi nào ngán kỹ thuật tới cổ đâu anh. Chừng nào em ngán thì anh thấy em biến mất tăm liền. Bây giờ em muốn hỏi anh câu này: công tác của người làm bảo mật là tạo nên sự cân bằng giữa tiện dụng và bảo mật. Trong khi đó, vai trò của kẻ tấn công là tìm ra những điểm yếu của sự thiếu cân bằng giữa tiện dụng và bảo mật để thâm nhập. Em hình dung câu này tổng hợp 'hai mặt của vấn đề'. Tuy nhiên, em chưa thể hình dung ra khi nào là tiện dụng và khi nào bảo mật. Làm sao kẻ tấn công biết được những điểm tiện dụng của một hệ thống nào đó mà khai thác? Có lẽ em chưa đọc đủ nhiều để thấy những điểm này trong sách. Anh phân tích dùm em được không?" 

Tôi cười đáp: 
"Em tinh tế lắm, lôi ra được câu này trong đống chữ mình trao đổi lần trước chứng tỏ em 'rà' rất kỹ. Anh nghĩ mình nên dành câu này làm câu chót đi. Anh em mình đà khía một hồi, tự nhiên em không cần hỏi câu này nữa đâu. Anh tin như vậy." 

'docco' hồ hởi: 
"Dạ được mà, nhưng em phải ghi xuống để tí nữa lại hỏi anh câu này nếu em thấy còn cần phải hỏi. Vậy em muốn hỏi tiếp là thế nào là tiện dụng và thế nào là bảo mật anh?" 

Tôi ngẫm nghĩ rồi đáp: 
"Thế này. Bất cứ một chương trình nào được tạo ra cũng không ngoài mục đích phục vụ một nhu cầu nào đó. Một chương trình càng lớn, càng phức tạp thì thường có nhiều chức năng để phục vụ nhiều nhu cầu, nhiều trường hợp nhưng lại bị vướng vào tình trạng dễ bị lỗi. Ngày trước, một chương trình viết ra thường cố gắng đạt được mức gọn nhẹ và hiệu xuất bởi vì khả năng đáp ứng và xử lý của hardware lúc ấy còn hạn chế. Khi hardware càng ngày càng nâng cao và cải tiến, software càng ngày càng mở rộng chức năng. Đòi hỏi 'gọn nhẹ' không còn là điểm tối quan trọng nữa mà đòi hỏi 'đa năng' chiếm vị trí ưu tiên. Tất nhiên ngày nay vẫn có những software được viết với tinh thần 'gọn nhẹ và hiệu xuất nhưng khá hiếm. Vì lẽ tự nhiên, cái gì càng phức tạp càng dễ gặp phải thiếu sót và thiếu sót dẫn đến lỗi. Ngay cả những software được viết có rất ít lỗi nhưng vì đòi hỏi 'đă năng' nên tính bảo mật 'bị' nhân nhượng. 

Ví dụ, một software có mười chức năng chẳng hạn. Không nhất thiết chức năng nào cũng áp đặt tính bảo mật trong đó. Trái lại, tính tiện dụng thường chiếm ưu tiên. Ngoại trừ những software chuyên cho bảo mật thì không kể (nhưng vẫn có ít nhiều tính năng tiện dụng, không thì không đáp ứng được nhu cầu... lười của con người ). Lần trước mấy anh em mình bàn về SSH, em cũng thấy rằng tập tin cấu hình của ssh (sshd_config) có vài tá giá trị chọn lựa. Hơn một nửa là để phục vụ tính tiện dụng, phần còn lại chuyên chú về bảo mật. Nếu áp đặt quá nặng bảo mật thì người dùng sẽ gặp khó khăn, nếu thả lỏng để tiện dụng thì làm mất đi tính bảo mật. 

Vậy, tiện dụng là gì? là những tính năng giúp cho việc sử dụng dễ dàng, đỡ mất công và nhanh chóng. Bảo mật là gì? là những tính năng 'làm khó', làm cản trở sự thâm nhập. Những cái 'làm khó' này dẫn đến sự mất tiện dụng cho người dùng bình thường." 

'docco' tiếp tục 'khai thác': 
"Anh có thể chứng minh những điểm 'tiện dụng' và 'bảo mật' trong một hồ sơ cấu hình được không anh? sshd_config chẳng hạn? Thú thật là em chưa đọc kỹ và thử nghiệm hết những thứ có trong sshd_config nhưng nếu anh cho em vài ví dụ thì quá hay." 

Tôi cười, đáp: 
"Chừng nào em còn chưa đọc kỹ và tự thử nghiệm thì chừng đó em chỉ dừng lại ở những điểm em... đọc chưa kỹ và chưa thử nghiệm mà thôi. Anh có thể cho em một ví dụ trong tập tin cấu hình sshd_config nhưng để thật sự nắm bắt sshd_config, em phải tự tay 'táy máy' thôi. Lý do? mỗi giá trị cấu hình (của bất cứ dịch vụ nào) đều có những giềng mối, những liên quan sâu xa đến hệ điều hành nó đang chạy và chỉ có tận tay thực hành thì mới thấy rõ được. 

Hãy thử xét giá trị RhostsAuthentication yes chẳng hạn. Nếu em đọc kỹ man của sshd, em sẽ thấy giá trị RhostsAuthentication này dùng để cho phép người dùng xác thực danh tánh của mình dựa trên hai giá trị: tên của máy và tên người dùng. Giá trị RhostsAuthentication yes trực tiếp liên hệ với hai giá trị khác: StrictModes và IgnoreRhosts. Nếu tên của máy (ở xa) cũng như tên người dùng của máy này đã được ssh server 'tin' (trusted) thì người dùng ấy chỉ cần gõ: 
Code:

$ ssh myserver

Là người ấy có thể đi thẳng vào máy chủ myserver mà không cần gõ password hay pass-phrase gì cả. Tiện không? Tiện quá đi chớ. Nhưng bảo mật? chắc chắn là không bảo mật. Đây là điểm tiện dụng mà nhóm phát triển SSH vẫn giữ lại để đáp ứng nhu cầu của những người quen dùng series r trên *nix. 

Có những system admin mỗi ngày phải login, logout hàng chục hoặc hàng trăm servers và phải gõ tên + password như vậy thì quá... mệt. Cho nên, đã có những người 'hack' *nix từ thuở ban đầu để tạo sự tiện dụng. Nếu em dùng UNIX nhiều, đặc biệt là nhánh *bsd, em hẳn quen biết đến series r* như rlogin, rsh, rcp, rexec... cho phép truy cập và thực thi lệnh từ máy này đến máy kia mà không cần phải gõ tên người và password. Điều duy nhất system admin cần điều chỉnh là đưa vào giá trị tên máy (của người muốn truy cập vào server) vào /etc/hosts.equiv của server là xong. Tất nhiên người ấy phải có tài khoản trên myserver (được làm ví dụ ở đây)." 

'docco' reo lên: 
"Chà, tiện quá vậy anh? Em không ngờ *nix có nhiều cái hay ghê. Nhưng dùng cách trên em thấy cũng an toàn mà anh? Nếu kẻ muốn thâm nhập thử dùng tên account không có trên myserver kia thì cũng chẳng làm gì được phải không anh?" 

Tôi đáp: 
"Tất nhiên là không rồi. Nhưng em thử nghĩ thêm một chút xem, nếu kẻ tấn công dùng account có tên là a và vào không được, liệu hắn ta có thử dùng account có tên là b để thử tiếp không? . Đó là chưa kể đến những phương tiện và kỹ thuật có thể enumerate ra tên người dùng của các tài khoản hiện hữu trên hệ thống." 

'docco' trầm ngâm: 
"Dám lắm chớ. Gặp em thì em cũng thử b sau khi thử a liền. Nhưng làm cách này mất công quá anh? Và nếu kẻ tấn công đi từ bên ngoài vào, làm sao tên máy của hắn có trên máy chủ myserver mà thử anh? Dẫu hắn có dùng đúng account có thật đi chăng nữa cũng vô ích thôi. Em nghĩ vậy không biết có đúng không?"

'docco' thật tinh tế! Tôi cười đáp: 
"Em nghĩ hoàn toàn đúng trong khuôn khổ 'thâm nhập điểm thứ nhất của hệ thống' nhưng chưa đủ sâu trong khuôn khổ 'từ điểm thứ nhất của hệ thống đến trọn bộ hệ thống'." 

'docco' ngỡ ngàng: 
"Ui.... là sao hở anh?" 

Tôi tiếp tục trả lời: 
"Bảo mật cho một hệ thống (mạng) không dừng lại chỉ một máy mà bảo mật phải cho tất cả các máy của hệ thống. Nếu một trong những máy của hệ thống bị nhân nhượng (vì lý do nào đó) và nếu chế độ truy cập từ máy này sang máy kia của hệ thống dựa trên tinh thần 'trust' một cách 'tiện dụng' theo kiểu dùng /etc/hosts.equiv ở trên thì trọn bộ hệ thống bị sụp đổ nhanh chóng sau khi máy thứ nhất bị nhân nhượng. Ở đây anh muốn nhấn mạnh cái tác hại của dạng thiết kế thiếu cân bằng giữa tiện dụng và bảo mật. 

Sự cân bằng giữa 'tiện dụng' và 'bảo mật' nằm ở chỗ: những gì không cần tiện dụng, không nên làm cho nó tiện dụng; những gì nên bảo mật, không nên làm cho nó tiện dụng. Nhu cầu tiện dụng phải có giới hạn nhất định và giới hạn này được đánh giá dựa trên cái nhìn bảo mật chớ không phải dựa trên cái nhìn tiện dụng." 

'docco' vẫn thắc mắc: 
"Nhưng em thấy rằng các máy chủ chính nó thường bị thâm nhập chớ em chưa từng nghe thấy trường hợp một máy trong nội mạng và các máy khác bị thâm nhập theo bao giờ. Trường hợp này là sao anh?" 

Tôi giải thích: 
"À, anh biết em thắc mắc vì em nghĩ rằng (hoặc nghe thấy) những vụ 'deface' hay thâm nhập xảy ra thường chuyên chú vào một web server nào đó và khi một thông điệp hiện lên trên trang chủ, đại loại như defaced by docco thì... xong chuyện. Tính về độ 'tàn phá' thì làm như thế chỉ xước nhẹ trên bề mặt, hay thuật ngữ tiếng Anh còn gọi là 'scratch the surface'. Khổ chủ chỉ bị 'mất mặt' vì website của mình bị ai đó thay đổi nội dung. So what? một ngày, hai ngày, ba ngày hay một tháng thì chẳng ai còn nhớ đến biến cố bị deface này nữa. Chẳng những thế, nếu họ bị 'deface' một lần thì cơ hội bị 'deface' lần kế tiếp rất thấp vì họ sẽ kiện toàn. Ngoại trừ website này là một website chẳng ai thèm viếng, chẳng ai buồn lo cho sự tồn tại của nó hoặc khổ chủ không có điều kiện, phương tiện để kiện toàn nó. Nếu thế thì còn gì lý thú để mà thâm nhập lần nữa? 

Mức độ nguy hiểm thực sự khi một máy chủ bị thâm nhập nhưng chẳng ai biết, kể cả khổ chủ. Ngay cả máy chủ này chẳng có thông tin gì lý thú, kẻ tấn công thuộc dạng 'nguy hiểm' thường để dành nó cho những việc khác. Ví dụ, dùng máy chủ này làm bàn đạp để thâm nhập những máy chủ khác, dùng máy chủ này để biến nó thành zombie để tấn công những mục tiêu khác hoặc ngay cả dùng nó để làm tài nguyên cho những công việc như biên dịch, brute force password, chứa dữ liệu.... Anh thấy những trò dán bảng hiệu 'defaced by someone' khá là con nít và vô ích nếu xét trên phương diện thâm nhập một cách nghiêm túc. Nếu cả một hệ thống đều bị nhận nhượng ở tình trạng 'yên ắng' thế này thì độ nguy hiểm hẳn phải ghê gớm hơn nhiều." 

'docco' reo lên thích thú: 
"Ái chà, em chưa bao giờ nghĩ đến hoặc nghe đến việc 'hack' một máy chủ và dùng nó cho mục đích riêng của mình như để biên dịch hay để brute force password bao giờ. Quả là thâm, quả là thâm. Anh chỉ đường cho hươu chạy rồi đó nhe? Vậy anh có áp dụng chuyện này cho mục đích riêng của anh không? Em đoán chắc là có " 

Tôi cười, đáp: 
"Em lại dùng chữ 'hack' sai nữa rồi. Không em, em đoán sai rồi. Anh may mắn được làm việc trong những môi trường có CPU, có tài nguyên để đáp ứng nhu cầu mình cần. Nếu cần brute force, anh có thể dùng vài cái mid-range servers để thực hiện, anh không cần phải mất thời gian để thâm nhập một server nào đó rồi 'chôm' một ít CPU. Ngay cả nếu như anh không được điều kiện thuận lợi để dùng các máy thứ dữ ở công ty, anh cũng chưa bao giờ có ý định thâm nhập để 'chôm' CPU bao giờ. Lý do anh biết được điểm lý thú này là vì trước đây có một khách hàng của anh bị thâm nhập. Máy chủ đó bị 'root-kit' và nó bị biến thành một máy chuyên để brute force. Tay chủ nhân chỉ thấy máy chủ của mình có những lúc chạy chậm quá nên nhờ anh điều tra (và bởi thế họ trở thành khách hàng của anh). Nhờ dịp này anh mới học được kinh nghiệm đó. 

Còn chuyện 'chỉ đường cho hươu chạy' thì em đừng lo. Để có thể thâm nhập một mục tiêu và lẳng lặng biến nó thành nguồn tài nguyên cho mục đích riêng của mình đòi hỏi phải có kinh nghiệm và khả năng thật sự. Những người chỉ biết thao tác mấy thứ sql injection hay xss từ những tài liệu có sẵn trên tầng web thì không có cách gì thực hiện ý định ở mức độ anh nêu ra ở đây đâu. Em đừng lo. Anh đề cập chuyện này ở đây theo tinh thần là: có nhiều cấp độ thâm nhập và nhiều cấp độ sử dụng kết quả đạt được mà thôi." 

'docco' trầm ngâm hồi lâu rồi cảm thán: 
"Chà, hình như anh em mình bắt đầu đi vào cõi thâm u rồi đây. Thú thật em hơi bị lùng bùng rồi đó. Vậy còn chuyện 'trust' anh đề cập ở đây có giống như kiểu 'trusted domains' trên Windows không anh?" 

Tôi đáp: 
"Hì hì, em không dằn được ý muốn phải dùng Windows để so sánh hả?  Chuyện 'trust' ở đây, về mặt khái niệm thì nó tương tự như 'trusted domains' trên Windows nhưng cơ chế thì khác. 'trust' ở đây là sự tin tưởng được thiết lập dựa trên một số dữ kiện nào đó. Trong trường hợp /etc/hosts.equiv mình bàn ở đây, miễn sao trong hồ sơ cấu hình này có giá trị tên máy thì máy đó được quyền truy cập vào máy chủ mà không cần phải cung cấp thêm thông tin nào khác. Mức độ 'trust' ở đây giới hạn giữa máy trạm và máy chủ nào có giá trị tên máy trạm trong /etc/hosts.equiv mà thôi. Nó không mở rộng ra ở biên độ trọn bộ một (hoặc nhiều) 'forest' như trên Windows. 

Nói về mặt tinh thần, 'trust' bằng rhost và /etc/hosts.equiv trên *nix và trusted forest trên Windows có cùng mục đích: tiện dụng. Tính tiện dụng ở đây lấn át tính bảo mật và đây là chuyện một chuyên viên bảo mật phải cân bằng." 

'docco' than vãn: 
"Có quá nhiều khái niệm mới mẻ em cần phải nắm bắt . Càng đi vào sâu, em càng thấy rối rắm đó anh." 

Tôi cười thông cảm và đáp: 
"Có lẽ em chưa quen với những khái niệm này thôi. Em chỉ cần nắm một điểm cốt lõi: tiện dụng cho người dùng hợp lệ thì cũng tiện dụng cho người dùng bấthợp lệ --> kém bảo mật. Nói một cách khác, tiện dụng tỷ lệ nghịch với bảo mật. Người bảo mật phải biết dừng lại ở đâu khi cung cấp tính 'tiện dụng' cho người dùng. Kẻ tấn công phải biết suy xét từ thông tin thu thập được sau khi 'khảo sát' một hệ thống để đánh giá mức độ 'tiện dụng' đang được dùng trên hệ thống và rồi hình thành kế hoạch thâm nhập. 

Nếu người làm bảo mật có cái nhìn vững vàng về bảo mật thì anh ta sẽ thiết kế hệ thống có những điểm tiện dụng nhưng phải cân bằng với bảo mật. Nếu kẻ tấn công có cái nhìn vững vàng về thâm nhập, hiểu rõ về hệ thống thì hắn ta sẽ có khả năng xác định được hệ thống này được đặt trên tiêu chỉ 'bảo mật' hay tiêu chỉ 'tiện dụng'. Nói cho cùng, nhu cầu cụ thể phải được xác định rõ ràng và cụ thể ngay từ đầu rồi mới hình thành được mức độ tiện dụng và bảo mật. 

'docco' đào xới: 
"Nói vậy, nhìn từ phương diện 'kẻ tấn công', tính 'tiện dụng' được khám phá và thẩm định thế nào để có thể tấn công vậy anh?" 

Tôi đáp: 
"Xét về mặt tâm lý, khi thử nghiệm và dò xét một hệ thống, nếu em phát hiện ra một lỗi nhỏ nào đó --> chưa hẳn là admin của hệ thống này kém cỏi, lười biếng hay chọn nguyên tắc 'tiện dụng'. Tuy nhiên, nếu em phát hiện ra nhiều sơ sót và những sơ sót này nghiêng hẳn về hướng tiện dụng --> chắc chắc phần lớn hệ thống thiết kế theo hướng tiện dụng. Kỹ thuật thẩm định (hay còn gọi là reconnaissance technique) đòi hỏi rất nhiều kinh nghiệm và kiến thức. Quá trình thẩm định có thể bao gồm một máy chủ cho đến trọn bộ một network hay nhiều network liên hệ đến mục tiêu. Từ những thông tin lấy được, em có thể xác định được tỉ lệ 'tiện dụng' so với 'bảo mật' của mục tiêu này và từ đó, một kế hoạch thâm nhập sẽ được hình thành. Thông tin thu lượm được có xác thực hay không là tùy vào sự kiên nhẫn và kiến thức của em; đây cũng là chìa khoá của sự thành công hay thất bại của việc thâm nhập. 

Nếu system admin của mục tiêu em muốn thâm nhập có rất ít kinh nghiệm về bảo mật, không hình thành kế hoạch trước khi thiết lập hệ thống một cách chi tiết và khoa học, điều này sẽ thể hiện rất rõ trong quá trình em thực hiện 'reconnaissance'. Đây là lý do có những hệ thống bị nhân nhượng một cách nhanh chóng và dễ dàng." 

'docco' cười một cách thích thú: 
"He he, em thấy những hệ thống em từng được phép tiếp xúc, chẳng hạn như các hệ thống ở trường em, system admin chỉ cắm đầu cắm cổ mà cài cài, đặt đặt miễn sao cho nó chạy là mừng rồi. Hèn chi mà máy chủ ở VN mình bị phá tơi bời. Vậy ý anh là việc chuẩn bị trước khi thiết lập một hệ thống là điều cần thiết?" 

Tôi cười, đáp lời 'docco': 
"Đúng rồi đó em. IT nói chung và bảo mật nói riêng cũng như bao nhiêu ngành nghề khác, bước chuẩn bị là bước quan trọng nhất. Muốn kết quả có mỹ mãn hay không, muốn giảm thiểu tắc trách, muốn loại trừ thiếu sót, muốn không mất thời gian về sau.... tất cả đều phụ thuộc vào bước chuẩn bị này. Một chuyên viên có giỏi kỹ thuật đến mấy, có kinh nghiệm làm việc đến cỡ nào mà xông thẳng vào việc thiết lập, bỏ ngang bước chuẩn bị hoặc xem nhẹ bước chuẩn bị thì không thể nào có kết quả bằng một chuyên viên khác biết chuẩn bị kỹ lưỡng. Thiết kế một hệ thống làm việc không những chỉ dừng lại ở sự tiện dụng, sự bảo mật mà còn liên hệ trực tiếp đến hiệu xuất của hệ thống và khả năng mở rộng của chúng nữa. Những cái này đi ra từ bước chuẩn bị cả ." 

'docco' reo lên: 
"Ái chà, anh nói em thấy có hơi hướm của ngành thiết kế phần mềm mà tiếng Anh gọi là software engineering đó. Phải vậy không anh?" 

Tôi đáp: 
"Ừm... anh nghĩ em nhận xét như thế cũng đúng. Bước chuẩn bị trong ngành lập trình, trong việc viết software là một bước cực kỳ quan trọng. Thiếu nó, software sẽ thiếu chất lượng, sẽ nhiều lỗi, sẽ khó mở rộng, sẽ thiếu hiệu xuất. Nó cực kỳ quan trọng là vì quá trình tạo ra một software hoàn chỉnh rất phức tạp. Thiếu thiết kế một cách cẩn thận, khi đi sâu vào công trình và không may khám phá ra mình đã đi sai hướng thì đó là một sự đổ vỡ, thiệt hại lớn lao. Nếu mình đặt việc thiết kế một hệ thống làm việc với tinh thần tương tự như viết software thì... quả thật điều mình bàn ở đây có 'hơi hướm' software engineering. Em cứ thử so sánh việc xây một ngôi nhà với việc xây dựng một hệ thống máy tính xem; chúng có rất nhiều điểm tương đồng. Em không thể cứ nhắm mắt mà thi công rồi sau đó mới thấy mình muốn để cửa sổ chỗ này, để cửa chính chỗ kia... nhưng nhà đã xây nửa chừng rồi. Em bị lâm vào tình trạng rất kẹt. Phải vậy không?" 

'docco' tiếp tục: 
"Dạ nhất định rồi. Còn chuyện 'nhu cầu cụ thể' được anh đề cập hồi nãy là sao anh?" 

Tôi hỏi ngược lại 'docco': 
"Hì hì, giống như em đang phỏng vấn anh vậy?  Vậy em hiểu thế nào là 'nhu cầu cụ thể'?" 

'docco' ấp úng rồi rụt rè đáp: 
"Dạ... ùm.... à.... em nghĩ.... nhu cầu cụ thể là nhu cầu cụ thể chớ là gì nữa anh? Ví dụ em cần tạo dịch vụ web, thì đó chính là nhu cầu cụ thể chớ còn gì nữa? Hay là anh ghẹo em nên mới hỏi câu này?" 

Tôi cười phá lên, rồi trả lời 'docco': 
"Hì hì, em có thấy anh ghẹo em lần nào chưa? . Không, anh hỏi câu này là hỏi một cách nghiêm túc đó. Tất nhiên em cần tạo dịch vụ web thì đó là nhu cầu của em, nhưng nói nó là cụ thể thì nó chẳng cụ thể tí nào." 

'docco' cười trừ: 
"Khì khì, em chịu thua đó. Anh giải thích dùm em tí đi?" 

Tôi chậm rãi đáp: 
"Giả sử như em hỏi anh, 'nhu cầu cụ thể của anh là gì nếu như anh cần tạo dịch vụ web'? thì anh sẽ chuẩn bị nhiều thứ trước khi trả lời cho em. Anh cần xác định rõ: 
- website này dự phỏng sẽ có nội dung thuộc chuyên ngành gì? 
- dịch vụ web ấy phục vụ ai? 
- độc giả của trang web đa số là giới nào? 
- dự tưởng sẽ có bao nhiêu người viếng website đó? 
- kinh phí dự trù là bao nhiêu? 
- mức độ quan trọng của website này thế nào? 
- nếu nó bị 'chết' ngắn hạn thì chuyện gì xảy ra? 
- nếu nó bị 'chết' dài hạn thì chuyện gì xảy ra? 

sau đó mới đào xới đến vấn đề kỹ thuật làm sao để thoả mãn những điều đặt ra. Rồi từ đó mới có một phương án cụ thể sẽ khai triển thế nào, quy chế ra sao, cấu hình cụ thể sẽ ra làm sao, cách xử lý trong những trường hợp điển hình có thể xảy ra với dịch vụ mình tạo sẽ là gì..... và tất nhiên là bảo mật sẽ là một yếu tố quan trọng trong mỗi câu trả lời được đưa ra." 

'docco' rú lên: 
"Ôi trời! Anh thật sự phải chuẩn bị những thứ như thế sao anh?" 

Tôi trả lời một cách ngắn gọn: 
"Hẳn nhiên rồi!" 

'docco' hỏi tiếp: 
"Vậy việc xác định nhu cầu có liên quan trực tiếp đến vấn đề bảo mật ra sao anh?" 

Tôi đáp: 
"Một khi đã xác định cụ thể nhu cầu, em có thể hình thành một kế hoạch khai triển, một cái sườn rồi mới thiết lập từng chi tiết cho cái sườn này. Làm như thế em có thể tránh được những thiếu sót hay dư thừa trong khi cài đặt, điều chỉnh. Bởi thế, lỗi bảo mật sẽ giảm thiểu đáng kể. Ví dụ, sếp của em muốn em thiết lập dịch vụ ssh trên máy chủ nào đó. Nếu em xác định được dịch vụ này sẽ cho những ai dùng, bao nhiêu người dùng, truy cập từ đâu thì hồ sơ cấu hình cho nó sẽ trở nên xác thực và vừa đủ. 
- Nếu dịch vụ ssh này giới hạn cho một nhóm người dùng rất nhỏ và chỉ truy cập trong nội mạng, em có thể dễ dàng áp đặt cơ chế xác thực người dùng và áp đặt cụ thể những IP nào được quyền truy cập đến dịch vụ này. 
- Nếu dịch vụ này có biên độ rộng lớn hơn thì em phải ấn định cơ chế xác thực người dùng nào là tiện dụng và bảo đảm nhất, thay vì dùng password-based authentication, họ dùng key-based authentication key để xác thực chẳng hạn. 

Càng nắm cụ thể nhu cầu, càng có thể hình thành một cấu hình chi tiết. Càng hình thành một cấu hình chi tiết, càng giảm thiểu thiếu sót. Càng giảm thiểu thiếu sót, tính bảo mật càng cao. Đây là giây chuyền logic đi từ 'nhu cầu' đến 'bảo mật'." 

'docco' xuýt xoa: 
"Quả thật bây giờ em mới biết được thêm nhiều cái mới mẻ. Những vấn đề này có phải là kiến thức trong ngành IT không anh?" 

Tôi cười đáp: 
"Nó không phải là kiến thức kỹ thuật theo kiểu IT = 'gõ lệnh' nhưng nó được dùng trong IT, dùng trong việc quản lý các công trình IT. Ngay cả em muốn tự viết software hay thực hiện điều gì đó, em cũng cần đến nó. Như anh đã nói ở trên, thiếu chuẩn bị thì kết quả không mỹ mãn như ý muốn là vậy." 

'docco' cảm thán: 
"Hoá ra bảo mật không dễ dàng chút nào. Anh chỉ nói sơ qua em đã thấy nó dính líu đến quá nhiều vấn đề khác nhau chớ không đơn giản dừng lại ở kỹ năng cài đặt và điều chỉnh. Em nghĩ việc hình thành kế hoạch, quản lý công trình là việc của đám quản lý công trình mà anh? Mình là dân kỹ thuật thì việc gì phải lo đến những thứ này?" 

Quả thật 'docco' này sắc sảo lắm. Cu cậu không bỏ qua một chi tiết nhỏ nào. Tôi trả lời: 
"Nói trên mặt lý thuyết thì việc lên kế hoạch và quản lý công trình là chuyện của đám project manager. Tuy nhiên, trên thực tế anh hiếm khi thấy có tay project manager nào có đủ khả năng kỹ thuật để hình thành một kế hoạch cho đẹp cả. Trên thực tế anh toàn thấy những tay này quan ngại đến yếu tố thời gian là chính. Nếu em trông chờ vào họ về việc khai triển kỹ thuật thì em sẽ bị 'dậm chân tại chỗ' bởi vì làm sao họ nắm được chi tiết kỹ thuật mà lên kế hoạch? Hoạ may em cung cấp mọi thông tin kỹ thuật cho họ như kiểu 'tư vấn kỹ thuật' và họ kết hợp lại để lên chương trình. Còn không thì công trình chẳng đi tới đâu cả . Họ đâu cần biết sshd_config hay httpd.conf cần có những gì? Họ càng không biết những dịch vụ này liên quan thế nào để ngoại mạng, nội mạng, firewall và các cơ chế bảo mật khác." 

Lần này 'docco' thật sự choáng. Cu cậu gởi cho tôi các emotion icon biểu lộ sự buồn bã và phát biểu như sau: 
"  , càng đi vào sâu em càng thấy kinh khủng. Hình như những điều anh nói là dành cho những tay chuyên viên bảo mật hay sao đó chớ system admin bình thường làm gì mà cáng đáng nhiều thứ quá vậy anh? Có quá nhiều khái niệm mới mẻ mà em chỉ nghe đây là lần đầu. Vậy em phải học ở đâu, đọc những sách nào để nắm những chi tiết anh đưa ra vậy anh?" 

Tôi hiểu 'docco' đang cảm thấy thế nào nên nói tiếp: 
"Anh hiểu cảm giác của em. Em nghĩ rằng những vấn đề anh đưa ra chỉ dành cho 'chuyên viên bảo mật' sao?. Bộ em không muốn làm chuyên viên bảo mật hay sao? Cho nên, em cần biết những điều này là điều cần thiết và hợp lý. Theo anh, người làm công tác bảo mật khác hẳn với một system admin hoặc network admin bình thường. system admin hoặc network admin dừng lại ở mức độ: cài đặt, thiết lập dịch vụ và một phần nào đó khá hạn hẹp liên quan đến việc kiện toàn bảo mật theo đề nghị của 'chuyên viên bảo mật'. Họ chỉ dừng lại ở mức độ 'làm sao cho dịch vụ chạy ổn định'. Trong khi đó, chức năng của 'chuyên viên bảo mật' rộng hơn và sâu hơn. Chuyên viên bảo mật là người xác định những dịch vụ nào nên chạy, thẩm định những dịch vụ đưọc chạy phải ở mức an toàn và tiện dụng như thế nào. Để có thể xác định và thẩm định như thế, họ là người nắm trọn bộ mô hình mạng từ thấp đến cao. Nếu ai cho rằng, chuyên viên bảo mật thì chỉ biết firewall, IDS, proxy.... thì theo anh, đó là một sự ngộ nhận" 

'docco' lên tiếng: 
"Vậy giới hạn trách nhiệm và chức năng của 'chuyên viên bảo mật' nằm ở dâu anh?" 

Tôi đáp: 
"Anh nghĩ rằng, giới hạn trách nhiệm và chức năng thực sự của 'chuyên viên bảo mật' nằm ở mọi phương diện xây dựng và bảo trì cho một hệ thống. Từ lúc có nhu cầu xây dựng dịch vụ cho đến lúc đã hình thành dịch vụ và kéo dài suốt quá trình hoạt động của dịch vụ đều có 'chuyên viên bảo mật' nhúng tay vào. Ngay cả khi dịch vụ này biến chuyển, nâng cấp và mở rộng sau này cũng cần phải có sự tham gia của 'chuyên viên bảo mật'. Anh nghĩ rằng chuyên viên bảo mật không dính đến chuyện quyết định bỏ ra bao nhiêu kinh phí để hình thành hệ thống mà thôi. Tuy nhiên, chuyên viên bảo mật cũng có ít nhiều ảnh hưởng đến con số kinh phí. 

Tất nhiên những điều anh đưa ra ở đây là những điều chỉ có các tổ chức có lớp lang mới thực hiện. Những tổ chức thiếu sắp xếp thì đây là một khái niệm lạ lẫm và đôi khi còn bị xem là 'phí công sức, phí thời gian'." 

'docco' cảm thán: 
"Nhìn một cách tổng quát thì thấy, nếu một tay chuyên viên bảo mật dùng kiến thức của mình để thâm nhập thì nguy hiểm biết chừng nào anh nhỉ?" 

Tôi cười, hỏi lại: 
"Lý do nào làm em nghĩ như thế vậy?" 

'docco' ngần ngừ rồi trả lời: 
"Ùm... à... dạ... em nghĩ là một người hiểu biết thấu đáo cấu trúc các hệ thống, nắm rõ các ngóc ngách cấu hình, tường tận đường đi nước bước thì ắt phải thâm nhập rất dễ dàng. Không biết em nghĩ thế có đúng không?" 

Tôi cười, đáp: 
"Tổng quát mà nói thì em nhận xét như thế là đúng. Tuy nhiên, trên thực tế các cấu trúc hệ thống và các tập tin cấu hình rất đa dạng. Một chuyên viên bảo mật có thể thẩm định dễ dàng hơn và chính xác hơn vì nắm vững một số nguyên tắc nhất định. Bởi thế khả năng và kết quả thâm nhập của hắn cao hơn một người không có cùng mức độ kiến thức như hắn. Tuy nhiên, quá trình thẩm định vẫn phải mất thời gian. Em nhận xét như thế có nghĩa là em công nhận 'biết bảo mật trước rồi mới thâm nhập'?" 

'docco' ý kiến: 
"Hì hì, anh trêu em hoài. Lần trước em đã công nhận chuyện này rồi mà. Ngay từ lúc anh nêu ra trường hợp ai đó 'thâm nhập' được vào một máy chủ nhờ phương tiện hay 'công thức' nào đó xong rồi ngồi... ngó vì không biết làm gì nữa, lúc ấy em đã công nhận quan điểm: phải có kiến thức thật sự mới có thể thâm nhập một cách đúng nghĩa được." 

Tôi đáp: 
"Vậy thì tốt " 

'docco' hỏi thêm: 
"Khi nào tiện, anh cho em hỏi thêm về các kỹ thuật nhận định "reconnaissance" nha anh? Em muốn biết kỹ thuật này đòi hỏi những gì? quá trình thực hiện ra sao và phân tích kết quả tìm được như thế nào. Em nghĩ để kiện toàn bảo mật, việc tự thẩm định hệ thống mình tạo ra bằng "reconnaissance" không thể thiếu được." 

Tôi cười đáp: 
"Anh sẵn sàng thôi. Tuy nhiên, chắc để lần tới đi em nha? Anh em mình 'đà khía' hơi lâu rồi đó. Anh phải chuẩn bị vài thứ để ngày mai còn đi làm nữa. Em nhớ lưu lại nội dung 'lai rai' của anh em mình hôm nay để Hưng và Khoa đọc với nha? Còn chuyện cấu hình 'con' server của bọn em tới đâu rồi?" 

'docco' nhanh nhẩu: 
"Thôi anh à, em nghĩ là bọn em cần nhiều thời gian cho chuyện này hơn dự tính. Chưa hình thành được nhu cầu cụ thể, chưa cài đặt cho ổn thì làm sao nói đến chuyện bảo mật hay thâm nhập nó được anh? Em không biết thằng Khoa với thằng Hưng nghĩ sao chớ riêng em thì em nghĩ có lẽ nên thong thả." 

Tôi cười phá lên: 
"Ái chà, "chưa hình thành được nhu cầu cụ thể"? Hì hì, em ứng dụng ngay vậy? . Em còn cần hỏi câu hỏi đầu tiên không?" 

'docco' ngượng ngịu: 
"Anh cứ diễu em mãi. Học phải đi đôi với hành mà anh. Ngẫm nghĩ em thấy quả thật nếu không biết thiết lập server để làm gì, để đáp ứng cái gì thì không thể tạo nên cấu hình cho nó được. Nếu thế thì khoan hẵng nói chuyện bảo mật cho nó. Hì, anh vẫn nhớ câu hỏi đầu hả? Tất nhiên là em không cần phải hỏi câu hỏi đầu tiên nữa anh ." 

Tôi rất vui khi nghe 'docco' tổng kết như thế. Tôi bảo: 
"Tốt lắm. Em nhận ra được điều này thì có nghĩa lần này anh em mình nói chuyện không chỉ 'lai rai' mà có kết quả hẳn hòi: nhu cầu cụ thể là một yếu tố quan trọng để hình thành việc bảo mật. Nếu nhìn từ phía 'thâm nhập', anh tin rằng em cũng thấy được mặt trái của nó như thế nào rồi hả? 

Thôi, anh phải đi đây Duy. Anh em mình gặp lại sau hả? Chào em." 

'docco' chào tạm biệt: 
"Em sẽ thông báo tình hình lại với hai đứa kia. Chào anh." 


15/8/2005 

11. Information? What the... 
Suốt vài tuần qua tôi quá bận rộn nên liên lạc rất qua loa với bộ ba Hưng, Khoa và Duy. Hình như các cậu cũng nhận ra được điều này nên offline messages và e-mail từ bộ ba này ít hẳn. Cũng có thể các cậu quá bận rộn nên không còn thời gian để hỏi han nữa. 

Chiều nay rảnh rang, tôi đăng nhập vào YIM để xem offline messages và không ngờ bộ ba Hưng, Khoa, Duy đang online. Tôi chào 'cuti': 
"Hello Hưng, khoẻ hông em? Sao không học hành gì mà cứ 'trực' online hoài vậy?" 

'cuti' trả lời tôi bằng một 'conference invitation': 
"Hello anh già. Anh rảnh hông? Vào đây đi. Tụi em muốn hỏi vài chuyện được hông anh?" 

Tôi chậc lưỡi, ngẫm nghĩ không biết mấy ông tướng này muốn hỏi gì. Hơn nữa tôi đang ở sở, vào YIM không tiện lắm. Thế nhưng tôi cũng tiếp nhận lời mời và mở đầu: 
"Được rồi, anh vào vài phút rồi phải dzọt vì anh đang ở sở đó nha!" 

'haothu' chào và nhận định: 
"Chào anh, lâu ngày quá anh. Em thấy anh lúc nào cũng bận rộn vậy? Ngồi chơi với bọn em một tí thôi mà." 

Tôi đáp: 
"Ừa, anh thì lúc nào cũng bận rộn. Anh hiện đang ở sở nên vào YIM không tiện lắm. Nếu anh đang ở nhà thì dễ rồi. Mấy đứa có chuyện gì cần thiết không?" 

'cuti' nhanh nhảu: 
"Dạ cũng không có gì. Bọn em vừa thi xong nên rảnh rang hơn trước, định tiếp tục 'làm phiền' anh đây ." 

'docco' cẩn thận: 
"Em thấy mớ khái niệm và dẫn giải của anh trong những lần trước đây còn quá sức nhiều thứ để bọn em thử nghiệm và lãnh hội. Em không biết Hưng và Duy nghĩ sao chớ riêng em thì em cảm thấy như thế. Em sợ bị... 'bội thực' nếu không 'tiêu hoá' kịp  nên có lẽ em sẽ không hỏi nhiều đâu." 

Tôi cười đáp: 
"Em nói đúng đó. Thông tin xung quanh mình nhiều lắm nhưng cái quan trọng là dung nạp nó như thế nào. Có những điểm mình cần phải hiểu cặn kẽ, có những điểm mình chỉ cần tiếp nhận để tiếp tục khai mở. Tuy nhiên, nếu một lúc nào đó cảm thấy có cảm giác muốn 'bội thực' thì nên chậm lại và dành thời gian để tháo gỡ những khúc mắc trước khi đi tiếp." 

Cả ba dường như đang trầm ngâm. Hồi lâu, 'cuti' lên tiếng: 
"Em thấy thằng Duy nói đúng thật và anh ủng hộ nhận xét của nó là hoàn toàn chính xác. Cũng may là bọn em có điều kiện học hành căn cơ ở trường. Cho nên khi nhận ra những lổ hổng của chính mình trong khi trao đổi với anh, bọn em có thể 'lấp lổ' không đến nỗi cực nhọc. Điều em thấy rõ là chương trình giáo dục của nước mình có những điểm cần cải thiện. Em thấy thầy cô giáo ít chịu đào sâu hoặc giới thiệu những kiến thức, thông tin mới mẻ mà cứ theo cái giáo trình cũ rích mà lặp đi, lặp lại." 

Tôi thắc mắc: 
"Làm sao em biết được giáo trình em đang học cũ rích vậy? và nếu chương trình giáo dục của nước mình cần cải thiện thì cần làm những gì?" 

'haothu' Khoa xen vào: 
"Hì hì, anh không biết đó thôi. Em dám chắc là anh không có giáo trình của trường em trong tay nên anh không rõ nó 'cũ rích' đến cỡ nào. Bọn em thì có thể truy cập Internet nên mày mò, lục lạo trên Internet, vào các trường đại học lớn trên thế giới thì thấy giáo trình của họ 'nặng' và mới hơn mình nhiều. Em chẳng thấy có mấy nước tân tiến còn dạy Pascal nữa. Trong khi đó ở VN mình, cứ chui đầu vào lập trình là dính ngay Pascal. Học mòn ghế vẫn cứ mấy cái chương trình 'đồ chơi' viết bằng Pascal chán như con gián. Lên một chút thì học VB. Ban đầu em còn thấy thích, sau đó mò vào các diễn đàn 'chuyên' về lập trình thì thấy bà con choảng nhau chí choé về VB. Em thấy phe chống cũng có lý vì học VB là học chương trình viết Visual Basic của Microsoft chớ chẳng phải hoàn toàn là học ngôn ngữ Basic. Học sinh học như thế, khi bị đẩy đến chỗ phải viết chương trình dùng ngôn ngữ Basic mà không có công cụ VB thì... bó tay. Còn khái niệm software engineering thì chẳng mấy ai đề cập đến. Cho nên khi thằng Duy chuyển cho em nội dung nó chat với anh lần trước, em thấy tiếc là đã vắng mặt " 

Tôi đáp: 
"Ùm... quả thật là anh không nắm được tình hình ở VN cho lắm. Anh có sinh hoạt trên một diễn đàn khác thì thấy có rất ít người quan tâm hơn đến những ngôn ngữ lập trình mới và quan tâm sâu đến software engineering. Ngoài ra, phần lớn tình hình quả có những điểm phản ảnh điều em vừa nhận xét." 

'cuti' Hưng không kém phần khích động: 
"Đó chỉ mới ở phương diện lập trình thôi đó anh. Các phương diện khác như networking, bảo mật thì rất sơ sài. Networking thì gần như là Microsoft Networking chớ chẳng phải là networking tổng quát. Còn bảo mật thì hầu như em chưa thấy ở trường dạy gì hết. Bởi vậy khi bắt đầu lò dò tham gia các diễn đàn, em thấy mình giống y như trong bụi nhảy ra vì có quá sức nhiều thứ mình chưa bao giờ nghe tới. Em nghe mấy thằng bạn đi học bên Sing, bên Châu Âu... bảo là bọn nó có nguyên một môn về security và môn này có nhiều phần nhỏ. Học xanh mặt luôn. Em không biết chừng nào nước mình mới đưa những thứ này vào giáo trình nữa. Còn vào diễn đàn chuyên bảo mật thì quanh đi quẩn lại chỉ toàn là những thứ đụng tới web, tới yahoo, chán ngấy đến cổ " 

Tôi cười và nhận xét: 
"Này, hình như bọn em kêu anh vào đây để 'tố khổ' chuyện giáo trình hay sao đó . Kêu với ai chớ kêu với anh thì cũng như 'nước đổ đầu vịt' thôi bởi vì anh đâu có làm gì được đâu nào. Anh nghĩ bọn em và các sinh viên nói chung nên làm một việc gì đó tích cực hơn cho vấn đề này. Ví dụ, bọn em ngồi lại với nhau và phân tích cặn kẽ ưu, nhược điểm của giáo trình hiện tại. Đưa ra các đề nghị thay đổi và lý do cụ thể để bảo vệ các đề nghị này. Tất nhiên mọi thứ phải trên giấy bút đàng hoàng, câu cú, trình bày cho tươm tất rồi trình lên ông trưởng khoa thì hoạ may." 

'docco' Duy gởi một biểu tượng 'lè lưỡi' tỏ ý e ngại rồi nói: 
"Trời, anh đúng là lạc hậu quá rồi. Chắc anh ở nước ngoài lâu quá nên quên hết chuyện nước mình. Em thấy chuyện này cực kỳ khó thực hiện. Thứ nhất, bọn em không đủ sức hình thành một bản phân tích cho ngon lành để trình cho ông trưởng khoa. Thứ nhì, em không dám chắc ông trưởng khoa có buồn tiếp nhận bản phân tích này hay không. Thứ ba, cho dù ông ta có tiếp nhận đi chăng nữa, em cũng không dám tin là ông ấy làm gì đó với đề nghị này hay nó bị... chìm vào quên lãng." 

Tôi gật gù rồi đáp: 
"Hèm... em đưa ra khó khăn, anh đề nghị hướng giải quyết nhưng hướng này xem ra không được hả? Anh chẳng biết phải làm gì hơn. Anh không thể nhận xét hay ý kiến nhiều vì chưa nắm rõ sự thể, chưa biết cái giáo trình em nói có nội dung như thế nào. Điều anh có thể đề nghị là nên làm một việc gì cụ thể và tích cực thì mới giải quyết được vấn đề. Nhưng sao tự nhiên lại 'tố khổ' vậy cà?" 

'cuti' Hưng nhanh nhảu: 
"Không phải tố khổ đâu anh. Em muốn đưa chuyện này ra chỉ để anh thấy rằng thực tế bọn em phải đối diện nhiều hạn chế lắm. Riêng em thì em chỉ mong là anh đừng nghĩ rằng bọn em lười nhác nên chẳng thu hoạch được bao nhiêu trong chuyện học tập bởi vì lắm khi em hỏi anh những điều... ngớ ngẩn." 

Tôi đáp: 
"Hì hì, hoá ra là muốn... phân bua đây. Có bao giờ em thấy anh phát biểu hay anh có thái độ gì chứng tỏ rằng anh nghĩ em lười nhác chưa? Em an tâm đi. Cứ thử chiêm nghiệm về mức độ trao đổi của anh em mình những lần đầu, lần này và những lần về sau, em sẽ thấy có những cái khác, có những cái biến thiên. Bởi vì không những chuyện kiến thức mà sự thông hiểu ý kiến và suy nghĩ của nhau làm cho việc trao đổi trở nên dễ dàng và thông suốt hơn nhiều. Nếu em quả thật lười biếng thì anh sẽ 'quạt' thẳng tay liền, đừng lo . Vậy bọn em cần anh vào đây có chuyện gì gấp không?" 

'haothu' Khoa lên tiếng: 
"Dạ không có gì gấp đâu anh. Phần em thì em chỉ thấy càng lúc càng lùng bùng sau mỗi lần xem lại nội dung trò chuyện của mấy anh em mình. Em đang cố gắng ghép nối những mẩu chuyện, những thông tin trong nội dung trò chuyện này lại với nhau để hình thành một khối thông tin liền lạc nhưng em thấy khó quá . Em định hỏi thêm anh một số điểm, được không anh?" 

Tôi trả lời: 
"Được chớ em. Tuy nhiên không phải ngay bây giờ bởi vì anh đang ở sở, anh phải logoff đây. Tối nay về nhà, mấy anh em mình nói chuyện tiếp nếu bọn em rảnh. Hay em thấy khi nào thì tiện?" 

'cuti' Hưng liếng thoán: 
"Dễ quá mà anh. Bọn em vừa thi xong, thời gian không là vấn đề. Chiều nay em sẽ online canh chừng anh lên á." 

'docco' Duy diễu: 
"Còn 'ẻm' để đâu mà lên ngồi canh chừng vậy pa? Nói lên là phải lên đó nha." 

Tôi kết thúc: 
"Thôi, anh phải dông đây. Có gì chiều tối gặp lại." và tôi logoff. 

--------------------- 

Cơm nước xong, tôi thong thả log vào YIM. Quả thật ba 'trự' Hưng, Khoa và Duy đang 'canh chừng'. Tôi chào và chọc quê 'cuti': 
"Hông bận lo 'ẻm' hay sao mà lên đây 'canh' thật vậy em?" 

'cuti' gởi tôi conference invitation kèm theo thông điệp: 
"Ái chà, thằng khứa Duy khai với anh hết rồi phải hông?" 

Tôi tiếp nhận lời mời và kèm theo câu trả lời: 
"Khai gì em? khai vụ em đi hóng mát với 'ẻm' đó hả?" 

'haothu' và 'docco' gởi hai thông điệp gần như cùng một lúc, cùng chế diễu 'cuti': 
"Thằng khỉ Hưng này cái gì cũng được, chỉ có chuyện 'ghệ' là dấu dấu diếm diếm như mèo dấu..." 
"Trời, có gì mà dấu hả pa? 'ẻm' chịu đi chơi thì phải vỗ ngực tự hào chớ việc gì phải ngại?" 

Tôi xen vào: 
"Thôi, 'cuti' không thích 'bàn' chuyện này thì tha cho nó đi mấy đứa. Chừng nào nó muốn 'thổ lộ tinh tầm' thì tự nhiên nó sẽ... phun ra có... vòi thôi ." 

'haothu' không tha, chêm thêm: 
"Em biết thằng khỉ Hưng quá rõ mà anh. Em học với nó từ cấp I lên, bây giờ nó đang nghĩ trong đầu em cũng biết nữa mà. Em chỉ chọc quê cho vui tí thôi chớ thằng này lịt lịt mà xịt ra khói đó." 

Tôi cười và lảng sang chuyện khác: 
"OK, hồi chiều em nói là em có vài thắc mắc gì đó Khoa, em nói đi." 

'haothu' ngập ngừng: 
"Chà.... hông biết tự nhiên sao em quên tuốt luốt là mình muốn nói gì nữa. Anh chờ em một tí để em 'restart' lại con CPU trong não của em cái đã." 

Chuyển hướng sang 'cuti' để 'haothu' có thời gian sắp xếp lại những điều mình muốn nói, Tôi đáp: 
"Thong thả thôi em. Còn 'cuti' có nhận xét gì về nội dung Duy và anh nói chuyện lần trước không?" 

'cuti' nhanh nhẩu: 
"Thì... đã chớ sao anh? nhưng chắc không đã bằng nói chuyện 'trực thoại' rồi đó. Em chỉ có cảm giác là những điều mấy anh em mình bàn càng ngày càng rộng ra chớ không phải càng ngày càng đi vào chi tiết. Em đoán rằng anh muốn chia xẻ những khái niệm quan trọng và cần thiết để tiếp cận vấn đề. Tuy nhiên, thực tình mà nói thì em thấy rất khó liên hệ nó đến môi trường thực tế. Có lẽ tụi em chưa đi làm, chưa có nhiều kinh nghiệm nên thấy những khái niệm anh đưa ra nó lạ lẫm quá." 

'haothu' reo lên: 
"Trời, thằng Hưng nói sao đúng ý em vậy? Em cũng muốn nói với anh như thế. Em thấy những khái niệm về tính liền lạc, về sự quan trọng của giềng mối, dẫn đến chuyện nhìn vấn đề từ nhiều phía, rồi khái niệm và kỹ năng chuẩn bị trước khi thực hiện ý định.... mà anh đưa ra đều hết sức lý thú. Tuy nhiên, em ráng 'apply' vào trong thực tế em đang đối chọi thì chẳng biết phải bắt đầu từ đâu cả. " 

Tôi trầm ngâm vài giây rồi hỏi: 
"Em cho anh một ví dụ thực tế mà em đang đối chọi xem?" 

'haothu' đáp: 
"Dạ ví dụ như ở trường ra bài lập trình chẳng hạn. Yêu cầu dùng một ngôn ngữ lập trình nào đó để tính ngày, giờ, khoảng cách, chuỗi số, biến thiên.... Em thấy những thứ này chỉ cần hình thành một cái thuật toán nào đó rồi xem cú pháp ngôn ngữ làm thế nào là viết thôi. Em cố hình dung làm sao nhận định giềng mối của yêu cầu đến phần tạo thuật toán rồi đến chuyện tìm hiểu cú pháp. Và rồi, nhìn từ nhiều phía trong hoàn cảnh này là nhìn thế nào anh? Còn chuẩn bị kế hoạch thì tất nhiên là phải chuẩn bị rồi đó nhưng chẳng lẽ em phải viết một bản kế hoạch trên giấy?" 

Tôi cười đáp: 
"Anh nghĩ em hơi bị... máy móc rồi. Những khái niệm kia nên ứng dụng một cách linh động, tùy hoàn cảnh, tùy mức độ lớn nhỏ của công việc. Mình không thể áp dụng mọi thứ một cách cứng nhắc được. 

Nói về mặt giềng mối cho yêu cầu cụ thể ở trên với việc hình thành thuật toán và cú pháp của ngôn ngữ lập trình thì anh nghĩ rằng em khai triển nó đúng trình tự và logic rồi. Giềng mối giữa yêu cầu và thuật toán quá rõ ràng và hiển nhiên: phải hiểu được và hiểu đúng yêu cầu thì mới hình thành đúng thuật toán. Đi xa hơn nữa em có thể tự chất vấn mình để xem thuật toán mình vừa hình thành có tối ưu chưa. Sau khi hình thành kết quả cuối cùng cho thuật toán, mang nó vào việc coding chỉ là một bước ứng dụng. Thuật toán của em càng hay, càng súc tích, càng vững thì tự nhiên bước coding trở nên đơn giản và đẹp thôi. Theo anh đây là cái giềng mối hiển nhiên. 

Nói về chuyện 'nhìn nhiều phía' thì có vẻ hơi trừu tượng hơn mặt 'giềng mối' một tí. Tuy nhiên, ở mức độ nào đó em vẫn có thể 'nhìn' nó ở góc độ khác nhau. Ví dụ em tự xét xem giải thuật được đặt ra với mục đích là gì? em muốn lấy kết quả cuối cùng mà chương trình trả về, hay em muốn thấy nó giải quyết vấn đề nhanh chậm, hiệu xuất ra sao trong cả một khối ứng dụng nào đó. Giả sử chương trình em viết sẽ được một người dùng và chỉ sử dụng những giá trị nhập đơn giản, đúng tiêu chuẩn thì sao? nếu 100 người cùng dùng và họ đòi hỏi giá trị nhập phức tạp hơn, đa dạng hơn thì sao? Đó là chưa kể em cần nhìn từ góc độ người dùng để hình thành chương trình của mình vững vàng hơn. 

Riêng chuyện 'hình thành kế hoạch' thì anh nghĩ thế này. Đây là một thói quen và lối khai triển của mỗi cá nhân. Nếu em có thói quen và khả năng hình thành kế hoạch trong đầu một cách rành mạch mà không cần giấy bút thì không việc gì phải dùng giấy bút. Trường hợp này thật ra chỉ khả thi cho những công việc có tầm cỡ nhỏ và đơn giản. Một khi em phải tiếp diện với một công trình lớn, phân tích và hình thành kế hoạch trên giấy bút không những giúp em nhận định vấn đề một cách chính xác và chi tiết hơn, nó còn là một phương tiện lưu trữ bởi vì dăm ba ngày, một vài tháng em sẽ quên hết các chi tiết. Nếu em muốn quay lại (vì lý do nào đó) thì em vẫn còn thông tin lưu trữ. Ở khuôn khổ bài tập ở trường, có lẽ em chưa thấy sự quan trọng của việc hình thành kế hoạch (mặc dù ở mức độ nào đó em vẫn phải hình thành kế hoạch trước khi thực hiện) nhưng chắc chắc em sẽ thấy nó quan trọng như thế nào trên thực tế công việc. Cho mục đích hoàn tất bài tập, một trang nhăng nhít những chọn lựa, sửa đổi thuật toán và dăm ba dòng mã giả (psuedo code) trước khi em bắt tay vào viết, theo anh đó chính là 'hình thành kế hoạch' rồi ." 

'haothu' Khoa hỏi tiếp: 
"Anh cho em hỏi chi tiết này nha? anh nói Đó là chưa kể em cần nhìn từ góc độ người dùng để hình thành chương trình của mình vững vàng hơn là sao anh?" 

Tôi đáp: 
"Ừa, anh cũng đoán nếu như em thực sự quan tâm đến kết quả em tạo ra, em sẽ thắc mắc khía cạnh này. Em nghĩ thế nào về câu nói ấy vậy?" 

'haothu' Khoa có vẻ ngập ngừng: 
"Dạ, em nghĩ... à... ùm... mình viết chương trình xong rồi mình dùng nó để thử nghiệm thì mình đã tự đặt mình vào góc độ người dùng rồi phải không anh? Em nghĩ phải có lý do gì khác anh mới đề cập chi tiết này. Nếu nó chỉ đơn giản như thế thì anh nêu ra làm chi phải không ạ?" 

Tôi cười đáp: 
"Đúng vậy, em nhận xét đúng lắm. "Nhìn từ khía cạnh người dùng" tất nhiên sẽ liên quan đến chuyện dùng chương trình này. Tuy nhiên, nhìn như thế nào mới là quan trọng. Khi em viết một chương trình hay tạo ra một quy định nào đó, em thường bị sa vào cõi chủ quan. Có nghĩa là em giả định mọi người cũng nghĩ như em. Ví dụ, em biết rõ chương trình của em chỉ tiếp nhận số nguyên chẳng hạn, khi thử nghiệm hiển nhiên em chỉ dùng các con số tròn trịa để dùng. Bởi thế, kết quả em nhận được luôn luôn chính xác. Tại sao em lại dùng những con số 'tròn trịa' để thử nghiệm? đây là vấn đề tâm lý mà thôi, trí não con người làm việc rất kỳ lạ . Nếu người dùng bình thường lỡ tay gõ vào một số thực chẳng hạn, chuyện gì xảy ra? Hoặc họ lỡ tay gõ nhầm một dấu chấm, dấu phẩy trong phần INPUT thì chuyện gì xảy ra? Tất nhiên là chương trình sẽ có sự cố, phải không em?" 

'cuti' Hưng rú lên: 
"Ái chà, hay thật. Nếu là em thì em cũng chẳng nghĩ đến chuyện người dùng sẽ gõ những gì khác ngoài các con số thực. Đúng là trí não con người kỳ lạ thật. Đây có phải là 'kinh nghiệm chiến trường' không anh?" 

Tôi đáp: 
"Ừa, 'kinh nghiệm chiến trường' đóng góp một phần nào đó nhưng theo anh, 'kế hoạch chuẩn bị' chu đáo giúp loại bỏ các sự cố này. Vậy, nhìn từ phương diện người dùng, em nghĩ sao nếu như em 'lỡ tay' gõ một giá trị gì đó và làm cả chương trình bị... treo?" 

'haothu' cười và trả lời: 
"Dạ, thì em sẽ nghĩ rằng chương trình đó... chuối chớ sao anh? " 

Tôi nói tiếp: 
"Nếu thế thì mình nên làm gì để cho nó không... chuối nữa?" 

'cuti' liếng thoắng: 
"Mình mở rộng để chương trình ấy tiếp nhận thêm số thực?" 

'docco' Duy chậm rãi: 
"Em nghĩ mình cần dùng cơ chế 'error handling' nào đó. Đưa vào các cụm điều kiện cách để thẩm định xem giá trị INPUT có thoả mãn yêu cầu hay không trước khi xử lý." 

Tôi đáp: 
"Ý kiến của em hay lắm đó Duy. Liệu mình mở rộng ra để tiếp nhận thêm số thực có đáp ứng chính xác yêu cầu của đề bài hay không Hưng? Đó là chưa kể trường hợp người dùng 'lỡ tay' gõ vào một ký tự nào đó bất hợp lệ. Anh thấy một điểm lý thú là mấy đứa nghiên về hướng tạo giải pháp cấp thời hơn là nhìn vấn đề ở bình diện tổng quát ." 

'cuti' chống chế: 
"Em nghĩ mở rộng cũng hay mà anh. Chắc em suy nghĩ chưa kỹ hay sao đó." 

Tôi trả lời: 
"Ừa, có lẽ em chưa suy nghĩ kỹ không chừng . Đà khía chi tiết này là vì anh muốn nhấn mạnh tầm quan trọng của việc chuẩn bị kế hoạch đó thôi. Nếu chuẩn bị kế hoạch kỹ thì em có dịp liệt kê ra hầu hết các tình huống và giải pháp cho mỗi tình huống hơn là nảy ra một ý kiến nhất thời nào đó." 

Tôi tiếp tục khơi mào: 
Vậy đứng trên phương diện bảo mật, sự nguy hiểm của việc thiếu xác thực giá trị nhập sẽ là gì?" 

'haothu' xuýt xoa: 
"Ái chà, em thấy làm gì thì làm chớ software mình viết mà chính nó bị treo hay nó làm treo máy thì thật là xấu hổ. Nếu nói về mặt bảo mật thì rõ ràng sự cố này phạm lỗi bảo mật rồi." 

Tôi đáp: 
"Đúng như vậy đó Khoa. Bất cứ sự cố ý hay vô tình làm software bị crash trong môi trường một hoặc nhiều người dùng đều có thể xem là bị phạm lỗi bảo mật (vì software thiếu an toàn). Khía cạnh bảo mật nằm ở chỗ tình trạng dịch vụ bị treo hoặc không còn tồn tại để cung cấp cho người dùng." 

'docco' reo lên: 
"A, em liên tưởng đến những trường hợp thâm nhập trên web mà em có đọc qua nhiều nơi. Có phải ý anh là việc input validation không vững chắc thì sẽ dẫn tới hiệu quả thiếu bảo mật?" 

Tôi cười và đáp lời 'docco': 
"Em nhận xét đúng lắm. Một HTML form hay bất cứ một phương tiện nào tiếp nhận dữ liệu nhập đều nên có cơ chế input validation. Thiếu cơ chế này, dữ liệu nhập có thể chứa những thứ bất hợp lệ (đối với chương trình ứng dụng) và sẽ tạo hậu quả lớn nhỏ, khác nhau, tùy theo hoàn cảnh. Không những 'input validation' hết sức quan trọng mà cơ chế 'error handling' cũng vậy. Một lập trình viên giỏi và cẩn thận thường đi xuyên qua bước 'chuẩn bị kế hoạch' để tạo nên các trường hợp cho 'error handling'. Cơ chế này càng tỉ mỉ thì cơ hội dẫn đến những biến cố tiêu cực và những thông tin nguy hại xảy ra càng ít." 

'cuti' Hưng nhận xét: 
"Hì hì, từ một bài tập lập trình mà anh dẫn đến cả chuyện thiết kế phần mềm lẫn khía cạnh bảo mật của nó được. Phải nói là em phục anh đó. Em nghĩ cái bài tập đó chỉ có tụi em dùng thôi, ông thầy chấm xong là vĩnh viễn chẳng bao giờ đụng tới mấy cái software 'đồ chơi' đó nữa anh ơi." 

Tôi cười, đáp: 
"Hì hì, bởi thế ngay từ đầu anh đã nói là mình phải uyển chuyển, phải linh động trong khi ứng dụng một hoặc nhiều nguyên tắc / khái niệm cho việc gì đó. Không nên cứng nhắc không thì hoá ra trì trệ và thiếu ứng hiệu. Chuyện anh mở rộng ở đây chỉ là một số khía cạnh thường thấy trong khi đi học cũng như trong lúc đi làm thôi. Đó là những 'kinh nghiệm xương máu' anh muốn chia xẻ để em khỏi dẫm lại những bước anh đã dẫm . Có thể em chưa liên tưởng những điểm trên rõ ràng ngay lúc này nhưng anh hy vọng một ngày không xa em sẽ thấy điều anh đặt ra ở đây nó 'thật' và 'thường gặp' đến mức nào. Tạo một chương trình nhỏ bé, đơn giản có thể khó thấy được tầm quan trọng của việc 'chuẩn bị kế hoạch' và chuyện 'error handling' hay 'input validating'. Tuy nhiên, nắm bắt được tầm quan trọng của các khái niệm này ngay lúc này thì sẽ đỡ vất vả hơn khi đụng phải những thứ to lớn hơn." 

'docco' lên tiếng: 
"Em vẫn thấy những chuyện này quá gần với lãnh vực software engineering hơn là bảo mật anh à. Có lẽ em vẫn chưa hình dung được một chuyên viên bảo mật thật sự phải làm những gì. Cũng có thể những điều em nghe thấy đã tạo ra cho em một tiêu chuẩn nào đó về trách nhiệm của một chuyên viên bảo mật và tiêu chuẩn này hơi... khác những điều anh đưa ra." 

Tôi đáp: 
"Em có nghe câu ngạn ngữ tiếng Anh: the first impression lasts chưa? Ấn tượng đầu tiên đóng vai trò rất quan trọng. Những điều em nghe thấy và đã tiếp nhận trước đây thường trở thành một thứ tiêu chuẩn của em. Anh thấy việc tiếp nhận một điều hoàn toàn mới dễ hơn là vứt bỏ 'tiêu chuẩn' cũ để tiếp nhận 'tiêu chuẩn' mới. Điều mình có thể rút ra ở đây là một chuyên viên bảo mật kinh nghiệm, một tay thâm nhập sừng sỏ và một lập trình viên dày dặn đều có chung một điểm: họ đều có khả năng chuẩn bị kế hoạch, có khả năng phân tích và thẩm định vấn đề. Còn lý do tại sao việc 'chuẩn bị kế hoạch' cẩn thận là việc cần thiết thì anh đã phân tích lần trước rồi. 

Trong giới hạn bài tập ở trường mà Khoa đưa ra ở đây thì anh dám chắc một điều: em đạt kết quả cao hơn nếu em 'chuẩn bị kế hoạch' kỹ lưỡng; em đạt kết quả thấp hơn nếu em bắt tay vào thực hiện liền mà không chuẩn bị hoặc ít chuẩn bị. 

Trên bình diện bảo mật, nhiều người cho rằng viết software thế nào thì viết, miễn sao nó chạy là tốt. Muốn bảo vệ hệ thống thì chỉ cài firewall, gắn những thiết bị bảo mật vào là đâu vào đó. Đây là một cách nhìn phiến diện. Nếu em quan tâm đến bảo mật và thâm nhập thì đây là một chi tiết quan trọng đó. Firewall chỉ cản không cho phép truy cập các dịch vụ bị 'cấm' và ở mức độ nào đó, nó cản một số trường hợp thâm nhập điển hình. Không có firewall nào có thể cản lọc mọi hình thức đăng nhập dữ liệu (vô tình hoặc cố ý) có thể gây ra vấn đề hư hoại cho hệ thống cả." 

'cuti' phát biểu: 
"Em công nhận anh nói rất có lý. Chắc bọn em phải ứng dụng thử xem sao. Hình như anh có vẻ chú trọng đến 'thái độ' tiếp cận và khai triển vấn đề hơn là chi tiết khai triển cụ thể như thế nào phải không anh?" 

Tôi đáp: 
"Chà, hôm nay 'cuti' nhận xét tinh tế lắm. Đúng như thế. Chi tiết khai triển thế nào thì chỉ cần có thời gian và thông tin thu thập được là khai triển được. Tuy nhiên, 'thái độ' thì chỉ có thể xác định đúng một lần ngay từ đầu mà thôi. Nếu tiếp cận và khai triển với thái độ không đúng mức thì cho dù có bao nhiêu cách khai triển (có sẵn) cũng có thể dẫn đến kết quả không hoàn toàn như ý." 

'cuti' khoái chí: 
"Dạ, không ít thì nhiều cũng thu thập được gì đó chớ anh? " 

'docco' Duy hỏi tiếp: 
"Bây giờ em hỏi những việc gì cần chuẩn bị cho kỹ thuật "reconnaissance" được không anh? Hồi nãy anh có đề cập đến chuyện chuyên viên bảo mật, người thâm nhập và lập trình viên giỏi đều có khả năng chuẩn bị kế hoạch. Vậy trong việc dò tìm thông tin của một hệ thống đòi hỏi phải chuẩn bị những gì vậy anh?" 

Tôi cười đáp: 
"Hà hà, em thấy 'ngứa ngáy' với 'reconnaissance' hả? Rồi, thì mình bàn thử. Hãy nhìn 'reconnaissance' như một công tác và đã là một công tác thì nó phải cónhu cầu cụ thể. Em còn nhớ chuyện 'nhu cầu cụ thể' mà mình đã đà khía trước đây hông?" 

'docco' đáp: 
"Dạ nhớ chớ anh. Anh muốn em trả lời nhu cầu cụ thể của em cho việc 'reconnaissance' là gì hả?" 

Tôi đáp: 
"Ừa, phải có nhu cầu cụ thể thì mình mới khai triển được chớ em " 

'docco' trả lời: 
"Em nghĩ 'reconnaissance' là tìm hiểu xem hệ thống mình muốn thâm nhập có những dịch vụ gì, nó chạy trên môi trường nào, nó thuộc mô hình mạng ra sao, có những điểm mạnh yếu gì... để giúp mình hình thành phương án thâm nhập (hay bảo vệ) cho sâu sát. Đó là những điểm em 'gặt hái' được từ những lần mấy anh em mình nói chuyện," 

Tôi cười và khơi mào thêm: 
"Vậy, nhu cầu cụ thể là biết rõ mục tiêu để tìm cách thâm nhập nó phải không? Bây giờ để hình thành kế hoạch cụ thể, mình sẽ thăm dò cái gì trước? cái gì sau? làm sao mình xác định được những thông tin mình tìm kiếm là xác thực? những phương tiện nào mình sẽ dùng để thăm dò?" 

'cuti' xen vào: 
"Ái chà, nãy giờ ngẫm nghĩ em mới thấy những gì anh em mình đà khía từ trước đến giờ đều có liên quan mật thiết với nhau. Công nhận độc thật.. độc thật." 

'haothu' thắc mắc: 
"Pa lại lảm nhảm gì nữa đó pa?" 

'cuti' giải thích: 
"Nè nè, đầu tiên mình bàn chuyện 'hack' là gì, sau đó mình bàn đến chuyện muốn 'thâm nhập' phải biết rõ cái mình muốn 'thâm nhập'. Kế tiếp mình đào xới chuyện 'biết rõ' là phải biết thế nào, phải nắm ngọn ngành ra làm sao. Rồi đến chuyện những giềng mối trong quá trình thu thập để có thể 'biết rõ'. Kế đến là kỹ năng nhìn nhận và tiếp nhận vấn đề từ nhiều phía. Lại thêm chuyện phải có kế hoạch để khai triển việc mình cần làm sau khi xác định rõ nhu cầu cụ thể. Những điểm này không liên quan mật thiết với nhau thì là gì nữa ông cụ?" 

'haothu' gật gù: 
"À há, tao thua mày đó Hưng. Tao cố tổng hợp lại những thứ này mà không được và nó cứ rối bòng bong lên." 

'cuti' phấn khích nhưng làm ra vẻ khiêm tốn: 
"Đâu có gì đâu mày. Chỉ cần xét lại trọn bộ những điểm cốt lõi mà bọn mình đã bàn thì ra liền thôi." 

Tôi nhận xét: 
"Em tổng hợp vậy là xuất sắc đó Hưng. Phần còn lại chỉ là ứng dụng sao cho uyển chuyển thôi." 

'cuti' không kìm được: 
"Ặc ặc, tưởng đâu đầu óc bị lú lẫn rồi chớ. Lâu lâu nói đúng một phát, được khen một phát sướng lên mây... ặc ặc, hu hu." 

Lúc này 'docco' mới xen vào: 
"Mấy pa này cứ cắt ngang hoài. Người ta đang nói chuyện 'recconnaissance' mà trời!" 

Tôi trấn an 'docco': 
"Lo gì em. Mình còn ngày dài tháng rộng để nói chuyện mà. Anh thấy Hưng tổng kết như vậy là chuyện rất nên làm đó. Ok, hồi nãy mình đang nói tới đâu rồi nhỉ?" 

'docco' hình như đã gõ sẵn nên thông điệp của cu cậu hiện ra trên màn hình gần như ngay sau khi tôi trả lời: 
"Dạ, hồi nãy đến đoạn anh hỏi là mình sẽ thăm dò cái gì trước? cái gì sau. Cách nào xác định được những thông tin tìm kiếm là xác thực. Những phương tiện nào sẽ dùng để thăm dò đó anh. Những điểm anh đưa ra ở đây chính là những điểm em thắc mắc đó. Mình thăm dò cái gì trước, cái gì sau có quan trọng không anh?" 

Tôi đáp: 
"Ừa, có lẽ mình nên khai triển từng phần một để đỡ rối rắm. Theo anh thấy, thăm dò có hai loại chính: động và tĩnh. Mỗi loại gắn liền với cái gọi là 'trước' và 'sau'. Điểm quan trọng hàng đầu của việc thăm dò là làm sao thu thập được thông tin xác thực nhất nhưng lại kín đáo nhất, ít bị phát hiện nhất." 

'haothu' reo lên: 
"Ái chà, thăm dò có 'động' và 'tĩnh' sao anh? Lần đầu tiên em nghe đó." 

Tôi cười đáp: 
"Ừa, động và tĩnh là hai từ anh tạm dịch sang tiếng Việt. Đúng ra nó là "active" và "passive" theo tiếng Anh. "Active" ở đây là 'động' nhưng nó còn có tinh thần là trực tiếp. Trong khi đó, "passive" là tĩnh và nó mang tinh thần gián tiếp. Vậy thế nào là "active" và thế nào là "passive"? active là lối thăm dò tạo ra bằng cách tương tác trực tiếp với hệ thống mình muốn thăm dò và passive là lối thăm dò không tương tác trực tiếp." 

'cuti' thắc mắc: 
"Nhưng làm sao mình biết được có hai dạng thăm dò 'active' và 'passive' anh? Cái này mình đọc sách hay tham khảo ở đâu vậy?" 

Tôi đáp: 
"Hai dạng thăm dò này quá rõ cho nên chỉ cần dùng suy luận thông thường cũng có thể xếp loại chúng thành hai dạng. Còn những cách thăm dò thế nào thì mình phải tham khảo nhiều nơi và tự tay táy máy mà ra." 

'docco' hỏi tiếp: 
"Vậy giữa hai dạng này, cái nào cho mình thông tin chính xác hơn cái nào anh?" 

Tôi trả lời: 
"Kinh nghiệm bản thân anh thấy dạng thăm dò 'active' thường cho thông tin chính xác hơn nhưng cũng còn tuỳ mình muốn lấy thông tin gì nữa. Ví dụ như cách thăm dò để lấy thông tin về domain name, các hosts trong domain và IP của chúng thì em chỉ cần query một DNS server nào đó thì đã có thể có một số thông tin. Ngay cả em dùng các công cụ online (web-based) để lấy thông tin loại này cũng thuộc dạng 'passive' và cũng có thông tin khá chính xác (ngoại trừ công cụ online này sử dụng một DNS server nào đó có vấn đề). Nếu em muốn lấy thông tin cụ thể hơn và các hosts trong một mạng mà thông tin này không được công bố trên DNS công cộng thì phải vận dụng đến cách thăm dò 'active'. Nói tổng quát thì có những loại thông tin đòi hỏi dùng dạng 'active' thì mới lấy được. Cho nên, 'active' thì thường chính xác hơn nhưng ít kín đáo hơn, 'passive' thì kín đáo hơn nhưng những thông tin này mang tính tổng quát hơn." 

'cuti' vẫn tiếp tục thắc mắc: 
"Em vẫn thắc mắc là làm sao biết được những kỹ thuật thăm dò đây anh. Ví dụ như bọn em tay mơ, chưa biết gì hết. Bây giờ bọn em muốn thử thăm dò thì bắt đầu từ đâu anh?" 

Tôi cười, đáp: 
"Tất nhiên là bắt đầu từ tài liệu, thông tin trong sách, trên web, trên các forum chuyên về bảo mật hay thâm nhập. Nếu em thử dùng từ khoá 'reconnaissance' và google thử thì em sẽ thấy thông tin nhiều biết chừng nào. Theo anh thấy, cái khó không phải là phương tiện tìm thông tin mà là phương tiện thu thập, lọc lựa, thử nghiệm và ứng dụng thông tin." 

'haothu' cảm thán: 
"Ôi trời, sao em thấy bây giờ hỏi ai cái gì cũng được trả lời là 'google', 'google', 'google' vậy anh. Anh cũng đề nghị bọn em nên 'google' nữa rồi . Em thấy tìm thông tin trên 'google' lan man quá anh." 

Tôi đáp: 
"Em không biết sao? Dùng search engine cũng là một trong những kỹ thuật 'reconnaissance' đó em. Nói chung, khả năng tìm không thể thiếu cho việc 'reconnaissance'. Không biết tìm, không thể thực hiện 'reconnaissance' hiệu quả được." 

'cuti' láu lỉnh: 
"Vậy anh muốn bọn em học cách dùng 'google' luôn chớ gì? " 

Tôi trả lời: 
"Hì hì, không anh muốn mà anh chỉ đề nghị mà thôi. Thời buổi này 'information is gold'. Information thì có khắp nơi. Em lên web thì từ thứ rác rưởi đến những thông tin cực kỳ quý giá đều có. Chỉ có em tự đào luyện cho mình kỹ năng tìm thông tin (bằng google hay bất cứ search engine nào) và kỹ năng chọn lọc thông tin. Càng có thể thu thập và chọn lọc thông tin, em càng 'đi trước' những người khác trên phương diện này." 

'cuti' phân bua: 
"Hì hì, em chỉ đùa thôi mà. Em biết 'google' và các search engine khác có những thông tin cực kỳ quý giá. Em chỉ thấy khó ở chỗ dùng cách nào để tìm và làm sao biết được thông tin nào cần lấy, thông tin nào không cần lấy thôi." 

Tôi đáp: 
"Em vào bất cứ trang chủ của bất cứ search engine nào cũng có thể thấy không ít thì nhiều hướng dẫn cách 'search', em nên đọc kỹ hướng dẫn để dùng cho hiệu quả. Sở dĩ ai cũng nhắc đến 'google' vì hiện nay nó là 'máy tìm' số một. Thật ra không có nhiều người thực sự sử dụng đúng mức chức năng của google để tìm thông tin và phần lớn là do không chịu đọc hướng dẫn của google đưa ra. Anh thấy gần đây đám O'Reilly còn xuất bản cả cuốn "google hack" nữa. Anh chưa đọc cuốn này nhưng anh đoán là nó giới thiệu những thủ thuật tìm kiếm trên google và những thủ thuật này đi từ phần hướng dẫn của google mà ra. 

Riêng việc biết thông tin nào cần lấy hay không thì đây là vấn đề kinh nghiệm. Em phải cần thời gian để bồi đắp kinh nghiệm này. Kinh nghiệm bản thân thì anh không 'tin' ngay vào nguồn thông tin anh kiếm được. Anh thường tìm cả tìm nguồn thông tin khác để đối chứng và khi có điều kiện, anh tự tay 'táy máy' để xác thực giá trị của thông tin anh tìm được. Lâu ngày tự nhiên có kinh nghiệm nhiều hơn, mình có thể xác định được nguồn tin nào đáng tin và nguồn tin nào cần xét lại. Cũng từ kinh nghiệm, đôi khi đọc một đoạn thông tin em có thể xác định thông tin này đáng tin hay không dựa trên tính logic của nó, dựa trên sự liền lạc và sự vững vàng trong cấu trúc của nó." 

'cuti' rên rỉ: 
"Ôi trời, sao mà khó quá vậy anh? . Bọn em đọc tiếng Anh chưa nên thân mà anh còn bắt phải 'dính' vào chỗ xem nội dung thông tin để đánh giá và thu lượm chúng thì làm sao làm nổi? Hoạ may bọn em có tiếng Anh thật chiến, có khả năng đọc, nhớ và phân tích nhanh như... điện." 

'haothu' chêm vào thêm: 
"Em cũng thấy như vậy đó. Đưa em một cuốn sách của OReilly, của Wiley hay của Syngress đã xuất bản, đã biên tập và chọn lựa hẳn hòi, em đọc mà thấy muốn chảy... mỡ ra, huống hồ chi thông tin tản mạn trên net. Anh có cách gì khác không anh?" 

Tôi cười, đáp: 
"Hì hì, bởi thế mấy nhà xuất bản mới kiếm sống được chớ em? trên 90% những gì được in trên sách đi từ những thông tin có trên Internet. Thông tin được trao đổi từ các newsgroup, từ các forums, từ những nhóm bug track, từ các security articles, từ trường đại học, từ các nhóm nghiên cứu... được thu thập, lọc lựa, tuyển chọn và được viết lại bằng sách một cách có hệ thống, có logic, bằng thứ ngôn ngữ ai cũng có thể tiếp nhận được. Tuy nhiên, không phải sách nào cũng có nội dung hoàn toàn chính xác và một điều quan trọng là khi sách được in ra thì những thông tin này gần như đã lỗi thời so với thực tế. Nhất là với lĩnh vực công nghệ thông tin và đặc biệt là bảo mật." 

'haothu' tiếp tục: 
"Vậy anh nghĩ bọn em phải làm sao bây giờ?" 

Tôi đáp: 
"Làm sao? Thì em vẫn đi học, vẫn đọc sách giáo khoa cho cẩn thận, vẫn đào luyện cho mình khả năng tiếp nhận thông tin theo dạng 'hàn lâm' ở trường và bắt đầu làm quen với mớ 'hỗn độn' trên Internet chớ sao? " 

'cuti' nhăn nhó: 
"Anh cứ trêu hoài . Em hỏi thật mà. Em cũng cảm thấy y hệt như thằng Khoa vậy." 

Tôi cười phá lên rồi đáp: 
"Thì anh nói thật mà. Câu vừa rồi anh nói hoàn toàn nghiêm túc. Em cứ thử nghiệm xem đi. Thông tin là thức ăn cho tinh thần, không ai có thể ép em phải 'ăn' cái gì cả. Họ chỉ có thể đề nghị em nên chọn thức ăn ra sao và cách tổng quát để 'tiêu hoá' thức ăn mà thôi." 

'docco' tiu nghỉu: 
"Chắc phải vậy rồi. Em chợt nhớ một chi tiết mình 'đà khía' trước đây: đều đặn và điều độ; nguyên tắc '4 đê' đó anh. Phải có '4 đê' thì hoạ may mới hình thành được mớ kỹ năng cần thiết để 'chọn thức ăn và tiêu hoá thức ăn' phải không anh?" 

Tôi đáp: 
"Đúng rồi đó em. Chắc chắn phải cần '4 đê'. Thôi khuya rồi, anh phải đi ngủ mai còn đi làm sớm. Lần sau mình 'đà khía' vài chi tiết về 'reconnaissance' cho vui nha?" 

'cuti' nhanh nhảu: 
"Dạ, quá đã đó anh." 

'docco' kỳ nèo: 
"Hứa đó nhe anh. Lần nào mình cũng sa đà vào những chuyện khác." 

'haothu' hóm hỉnh: 
"Em thì cái gì cũng được hết. Miễn sao ngồi đà khía như thế này là vui rồi." 

Tôi đáp: 
"Ừa, nhất định mình sẽ bàn chuyện này mà Duy. Anh chỉ thấy nó chưa quá sức quan trọng lúc này thôi. Anh muốn em có 'right set of mind' trước khi đi vào chỗ đó . OK, bye mấy ku." 

và tôi logoff. Đồng hồ cũng vừa gõ mười tiếng. 


7/9/2005 

12. Information... What for? - I 
Mấy tuần qua tôi quá bận rộn nên đã 'lờ' khá nhiều mail và offline messages từ bộ ba 'cuti', 'haothu' và 'docco' và tất nhiên tôi cũng lờ khá nhiều mail từ những người khác. Tôi được nghỉ bù liên tiếp ba ngày (cộng với hai ngày cuối tuần là năm ngày). Dự định sẽ đưa gia đình đi chơi đâu đó, không ngờ trời đổ mưa tầm tã cho nên đành phải thúc thủ trong nhà. Tôi quyết định online để đọc mail, trả lời mail và xem offline messages. Như dự đoán, tôi có hàng trăm email trong inbox và hàng 'tấn' offline messages. Đang trong lúc thong thả đọc và trả lời từng cái (đáng trả lời), YIM bỗng nhiên báo 'cuti' vừa vào. Tôi hết sức ngạc nhiên vì lúc này bên VN mới có 7 giờ sáng. Không hiểu 'cuti' làm gì mà mò vào YIM sáng tinh mơ như thế. Tôi bèn gởi anh chàng một message: 
"Hello Hưng, làm gì mà mò lên đây sớm quá vậy?" 

Trong tích tắc, tôi nhận được hồi báo: 
"Ui trời, hôm nay là ngày gì mà đặc biệt vậy? Sao giờ này anh lên đây, bộ anh không đi làm sao?" 

Tôi đáp: 
"À, anh được mấy ngày nghỉ bù, định đi chơi đâu đó nhưng trời đang mưa tầm tã nên lên web dạo chơi . Còn em làm gì mà dậy sớm vậy?" 

'cuti' trả lời có vẻ uể oải: 
"Dạ, đáng lẽ hôm nay em đi học nhưng bị cúm mấy hôm nay, trong người còn thấy nhừ quá nên ở nhà. Em dậy hồi sớm à. Nằm hoài trong giường buồn quá nên mò lên net chơi. Vậy anh em mình 'đà khía' lai rai được hông anh?" 

Tôi cười, đáp: 
"Nếu trời cứ mưa thì anh em mình tha hồ mà 'đà khía' nhưng trời tạnh mưa thì anh sẽ dẫn mấy thằng nhóc đi chơi. Em muốn 'đà khía' gì đây?" 

'cuti' khoái chí: 
"Hi hi, em muốn trời mưa hoài. Anh em mình 'đà khía' chuyện gì mà không được anh? Chuyện trên trời, dưới đất cho vui mà. À, em có một chuyện cũng buồn cười lắm. Anh muốn nghe không?" 

Tôi ngần ngừ: 
"Èm... cũng tùy chuyện đó là chuyện gì nữa em. Nếu em nghĩ là anh thích nghe thì em kể đi." 

'cuti' bẽn lẽn" 
"Cũng chẳng có gì đặc biệt đâu anh. Chuyện em với con 'ghệ' bồ đó mà." 

Tôi đáp: 
"Ui trời, 'nàng tiên của lòng anh' mà sao gọi là 'con ghệ' vậy em? " 

'cuti' cười, trả lời câu hỏi của tôi: 
"Anh không biết đó thôi, đó là cách gọi thân mật và âu yếm đó thôi mà." 

Tôi trả lời: 
"Ái chà... có lẽ anh lỗi thời rồi. Anh mà gọi bà xã anh là 'con ghệ' thì chắc nguy to . Ừa, em kể đi, có chuyện gì với 'con ghệ' mà em có vẻ phấn khởi vậy?" 

'cuti' bắt đầu: 
"Anh còn nhớ hồi bữa, lần cuối cùng bốn anh em mình 'đà khía' hông? Thật ra hôm đó em có hẹn với 'con ghệ' nhưng em quyết định cho nó leo cây. Ai biểu tắt di động làm chi, em gọi hoài không được nên... xù." 

Tôi thắc mắc: 
"Tắc di động là tắc thế nào em? anh không hiểu lắm." 

'cuti' phát biểu: 
"Kiểu này anh phải về VN làm một khóa tu từ đi anh, 'di động' là điện thoại di động đó. Hì hì." 

Tôi đáp: 
"À... hoá ra là thế. Anh cứ ngỡ con mèo di động hay con chuột di động gì đó " 

'cuti' tiếp tục: 
"Em phải dùng từ cẩn thận không thì lại bị anh kê cho. Tối hôm đó, 'con ghệ' đợi hoài không thấy em đến nên nổi 'khùng' lên. Điện thoại di động em thì hết pin mà cũng chưa kịp sạc nữa. Thế là ẻm bèn phóng xe đến nhà em. Chưa giáp mặt, đã mắng em xối xả vì em đã cho bả leo cây." 

Tôi xen vào: 
"Vậy là tốt rồi, 'nường' còn chịu khó phóng xe đến nhà em để mắng thì không có gì trầm trọng. Rồi sao nữa." 

'cuti' cười, nói tiếp: 
"Hì hì, anh không rõ đó thôi. Con bồ em tánh nóng như lửa, có gì là huỵch toẹt ra hết. Lúc đó nghe thì cũng ngứa con ráy lắm nhưng riết cũng quen. Nó buộc tội em là mê net, mê chat với 'con quỷ cái' nào đến nỗi phải cho nó leo cây. Em cố sức phân trần nhưng không hiệu quả. Rốt cuộc em phải cho nó xem nội dung mấy anh em mình 'đà khía' nó mới chịu yên." 

Tôi cười: 
"Hì hì, hoá ra trước đó em chưa hề kể cho 'con ghệ' nghe về mối quan hệ 'bất chính' của mấy anh em mình sao?" 

'cuti' trả lời: 
"Dạ, em định kể cho nó nghe nhiều lần nhưng cứ mỗi lần đi chơi mà đề cập đến tin học, đến máy tính là nó gạt phăng đi. Nó nói "bộ ôm máy cả ngày, cả tuần chưa đã nư sao mà hễ mở miệng ra là máy tính, máy tính" nên em... im luôn." 

Tôi đáp: 
"Thú vị lắm. Vậy sau đó thế nào em?" 

'cuti' cười hớn hở: 
"Dạ sau đó thì tụi em đi uống nước một chút rồi về. Lúc mấy anh em mình kết thúc thì bên đây mới có 7 giờ tối chớ mấy anh. Thế là trong lúc đi uống nước, 'con ghệ' cứ đem chuyện mấy anh em mình 'đà khía' ra hỏi dồn. Em nói với nó là em có lưu lại nội dung anh em mình chat, để em cho nó một bản để đọc cho khỏi thắc mắc." 

Tôi đáp: 
"Ừa, con gái là chúa tò mò mà em. Cái gì càng dấu, càng thích tò mò ." 

'cuti' cười hi hi, rồi nói tiếp: 
"Chưa hết. Sau khi em đưa cho nó cái file chứa nội dung anh em mình chat, mấy ngày sau nó nhất định đòi em phải giới thiệu anh cho nó. Nó cũng muốn tham gia 'đà khía' với mấy anh em mình luôn. Em nói là em sẽ chuyển lời nhưng em không hứa gì hết." 

Tôi cười ghẹo 'cuti': 
"Hì hì, được dịp trả đũa nên làm khó 'nường' hay sao đây? Hoá ra là chuyện con bé muốn tham gia . Thì cứ dẫn 'nường' lên 'đà khía' chung chớ có gì quan trọng đâu em?" 

'cuti' trả lời: 
"Em nói thiệt mà anh. Em không thể hứa gì nó vì em không biết hay sẽ nói gì. Lỡ may em đề nghị và anh phán con gái, con lứa mà bày vẽ, lắm chuyện thì có quê cả đám hông à." 

Tôi đáp: 
"Có gì mà không ok em. Kêu nó tham gia cho vui chớ có sao đâu à." 

"cuti" trả lời: 
"Dạ, để em báo cho nó biết. 'Con gái, con lứa' mệt lắm anh ơi, khi thế này, khi thế kia, chẳng biết đường nào mà mò." 

Bên ngoài mưa đã ngớt. Tôi đoán mấy thằng nhóc của tôi sắp sửa vòi vĩnh chuyện đi chơi đây. Cho nên tôi cho 'cuti' biết: 
"Có lẽ anh sẽ đi chơi với mấy thằng nhóc. Trời bên này đã tạnh mưa rồi em. Chiều tối nay anh ở nhà, nếu thích em rủ đám Khoa, Duy và 'con ghệ' vào đà khía cho vui." 

"cuti" hớn hở: 
"Dạ, vậy thì vui quá. Em bệnh nằm nhà hoài chán quá. Được đà khía vậy thì quá đã. Để em điện cho tụi nó liền. Vậy khoảng mấy giờ anh lên?" 

Tôi phỏng chừng: 
"Anh đoán khoảng 4, 5 giờ chiều bên em đó, có tiện không?" 

'cuti' chậc lưỡi đáp: 
"Chậc chậc... hơi kẹt đó anh. Bọn em thì dễ nhưng con Như chắc kẹt vì em đoán giờ đó nó phải nấu cơm chiều rồi. Thôi kệ nó vậy. Khi khác cho nó tham gia cũng được." 

Tôi 'chỉnh' 'cuti': 
"Hèm... nó là girl friend của em mà cứ 'con' với 'nó' nghe hông 'ngọt' tí nào hết em. Vậy ngày mai khoảng 2 giờ trưa bên em được hông?" 

'cuti" trả lời: 
"Dạ, 2 giờ trưa thì chắc ok rồi anh. Nó có lên trễ một tí cũng không sao. Còn chuyện 'nó' với 'con' em bị quen miệng rồi anh ơi. Gọi thế nào cho ổn đây anh?" 

Tôi đáp: 
"Kêu bằng tên đi em và cũng không cần phải đệm thêm chữ 'con' . Rồi, 2 giờ trưa bên em hả? Anh đi đây." 

'cuti' phàn nàn: 
"Dạ chào anh. Đúng là anh già khó tính, thêm chữ 'con' cũng không được ." 

Tôi logoff. 

---------------------------- 

Chiều hôm sau, như đã hẹn, tôi lại logon YIM. Khi vào, tôi thấy hai khuôn mặt 'vàng khè' của 'cuti' và 'docco' cộng thêm một 'request for accept' của một người có cái nick khá ngộ nghĩnh và bí hiểm là ccxx kèm theo thông điệp ngắn gọn: "Dạ em là Như đây, bạn của Hưng, Khoa và Duy đó anh. Anh add em được không ạ?". Hiển nhiên là 'cô bồ' của 'cuti' nhà mình. Tôi nhấn nút "accept" và một khuôn mặt 'vàng khè' trên cái nick ccxx hiện ra trên danh sách YIM của tôi. Chẳng thấy 'haothu' đâu cả, hay anh chàng đang 'invisible'? 

Trong tích tắc, một "conference invitation" được ccxx gởi đến. Trong khi nhấn nút "Accept", tôi thầm nghĩ "chà, cô bé này có vẻ nhậm lẹ đây". 

Trong 'conference room' có 'cuti', 'docco' và 'ccxx' nhưng chẳng thấy bóng dáng 'haothu' đâu cả. 'ccxx' lên tiếng: 
"Chào 'anh già khó tính' ạ. Em xin tự giới thiệu em là Như. Rất vui được làm quen với anh." 

Tôi mỉm người, tự nhủ "con bé liếng quả nhỉ" và đáp lễ: 
"Chào Như, cũng bắt chước cu Hưng gọi anh là 'anh già khó tính' sao? Còn 'haothu' đâu rồi mấy đứa?" 

'ccxx' trả lời lẹ làng: 
"Dạ, em nghe nói nó bị kẹt. Không rõ bị kẹt gì mà không online được anh." 

Lúc này 'cuti' và 'docco' mới lên tiếng: 
"Chào anh già khó tính, anh đi chơi với mấy nhóc có vui không?" 

"Chào anh D, mới có vài tuần mà em thấy như hàng tháng vậy. Anh khoẻ không?" 

Tôi đáp: 
"Ừa, đi chơi cũng vui lắm em. Anh cũng khỏe, còn em dạo này sao Duy?" 

'docco' trả lời: 
"Dạ em cũng bình thường anh. Dạo này em đọc nhiều hơn và ít đi chơi hơn " 

Tôi đáp: 
"Tốt quá vậy? Anh tin là em 'luyện' được mấy 'tầng nội công' rồi đó . Ừa, nãy giờ anh thử đoán cái nick ccxx là cái gì. Anh nghĩ là đoán đúng hông chừng." 

'ccxx' cười khoái chí: 
"Anh đoán ra được em phục lăn liền đó. Hồi giờ chưa có ai đoán ra được cái 'bí ẩn' đằng sau cái nick này đó anh." 

Tôi cười, đáp: 
"Ừa, nếu vậy dám anh đoán sai lắm đó. Anh nghĩ ccxx là 'công chúa xấu xí' phải không?" 

Cả ba 'cuti', 'docco' và 'ccxx' cùng trả lời gần một lượt: 
"Ồ" 
"wow" 
"độc thiệt" 

và 'ccxx' nói tiếp: 
"Sao anh đoán một cái là trúng phóc liền dzị? Em thiệt là phục lăn đó. Mấy người trên mạng toàn liên tưởng cái nick của em đến những thứ bậy bạ không à." 

Tôi đáp: 
"Chắc là mấy 'anh chàng' trên mạng đoán được nhưng không dám nói, sợ em giận vì nó có hai chữ 'xấu xí' bên trong. Anh nhìn qua chữ ccxx tự nhiên anh liên tưởng ngay đến 'công chúa xấu xí' liền. Nhưng mà, ccxx có gì mà liên tưởng đến những thứ bậy bạ vậy em?" 

'ccxx' phụng phịu: 
"Anh không biết đó thôi. cc là credit card chùa đó anh, còn xx là mấy thứ... ùm.... à... tầm bậy tầm bạ đó. Thôi, em không nói nữa. À nhưng mà anh không sợ em giận sao mà nói thẳng hai chữ 'xấu xí' dzị? " 

'docco' xen vào: 
"Thì xấu thì chấp nhận xấu chớ có gì mà giận cà." 

'ccxx' phản công: 
"Còn ông nữa, còn chừng ông nghe ông." 

Tôi cắt ngang: 
"Hì hì, anh nghĩ hai chữ 'xấu xí' đó thật ra hàm chứa một chút kiêu hãnh ngầm đó thôi. Có ai tự cho mình 'xấu xí' bao giờ? Nếu có thì cũng 'ngầm' khen mình 'xinh đẹp' . Bởi vậy, anh chẳng ngại nói ra hai chữ này. Riêng với những người liên tưởng cái nick của em thành những thứ bậy bạ thì chính họ thiệt thòi thôi. Đừng để ý làm gì." 

'ccxx' thốt: 
"Kinh khủng, kinh khủng. Em đọc những lời anh đối thoại với đám Hưng, Khoa, Duy đã thấy miệng lưỡi của anh kinh khủng. Giờ trực tiếp nói chuyện mới thấy quả là không sai . Thôi, em nghĩ ngoài việc 'đà khía' chuyện tin học, máy tính, anh nên huấn luyện ông Duy một khoá 'ái tìn' đi anh. Ông này cũng tốt mã, học giỏi mà sao vẫn chưa có một 'miểng tìn rách rưới' nào hết. Em bảo đảm anh huấn luyện cho ổng một khoá là thành công ngay." 

'docco' luống cuống: 
"Thôi.. thôi.. đi bà. Cho tui xin mà. Nhưng không cái gì mà 'tìn tìn' trong này. Thôi anh, mình nói chuyện tin học vui hơn." 

'ccxx' cười ré lên: 
"hi hi hi, tui đoán mặt ông Duy lúc này đang đỏ như 'mặt trời bé con' đó. Thôi, tha cho ông một lần đó. Vậy mấy anh em mình nói chuyện gì đây?" 

'cuti' lúc này mới lên tiếng: 
"Anh thấy... anh thấy Như hoạt bát hông anh? Hay để Như chọn đề tài được đó." 

Tôi cười, đáp: 
"Hì hì, anh thấy 'nhà' em hoạt bát lắm, muốn 'lăng xê' nàng liền hả? Hy vọng sẽ có nhiều chuyện lý thú đây ." 

'ccxx' phát biểu một câu thật ngắn rồi bỏ dở: 
"Em công nhận anh nói chuyện 'kinh' thiệt.... [/i] 

'docco' cười thích thú: 
"Hi hi, cám ơn anh D gỡ dùm em một quả. Em dám chắc lúc này mặt bà Như đỏ hơn 'mặt trời bé cha' nữa " 

Chỉ qua vài câu đối thoại, bọn tôi đã trở nên thoải mái như đã quen thân nhau từ lâu. 'docco' hình như muốn cắt ngắn những chuyện cà rỡn để bắt đầu 'đà khía' những chuyện cu cậu thắc mắc. 'docco' lên tiếng: 
"Thôi, 'đả qua đả lại' một hồi coi chừng thế chiến thứ III bắt đầu bây giờ. Mình nói chuyện khác đi hả bà con?" 

'docco' nói tiếp: 
"Em có tham khảo qua các vấn đề thuộc về reconnaissance rồi đó anh nhưng em thấy có nhiều điểm lờ mờ quá. Em thấy có cái thì gọi là 'enumeration', cái thì gọi là 'interrogation', cái lại gọi là "reconnaissance". Em thử so sánh thì thấy rằng chúng cùng phục vụ cho mục đích thăm dò. Vậy cái nào là cái nào đây anh?" 

Tôi cười, đáp: 
"Hì hì, nhảy ngay vào kỹ thuật hả? Chắc em sợ mình lại 'lạc đề' sang những chuyện khác chớ gì? Đúng là những thuật ngữ em liệt kê ra ở đây đều tựu trung vào tinh thần chung: thăm dò. Reconnaissance dịch sát nghĩa là 'khai thác thông tin' và 'interrogate' và 'enumerate' dính líu trong tiến trình khai thác này. Trong đó, 'interrogate' dịch sát nghĩa là 'hạch hỏi' và 'enumerate' là 'đếm'. Nắm được những thuật ngữ này cũng có ích để hiểu sâu từng phân đoạn của quá trình thăm dò. Tuy nhiên, nếu em cảm thấy bối rối với những thuật ngữ này thì khoan hẵng tìm cách 'dịch' chúng sang tiếng Việt vì có những từ dịch không được hoặc không đủ lột tả tinh thần. Cứ tiếp nhận chúng như những thuật ngữ vậy thôi. Sau này em sẽ rõ hơn." 

'ccxx' xen vào: 
"Thôi để anh già và Duy đối thoại hén? Em với Hưng ngồi nghe. Có gì thắc mắc bọn em tham gia sau." 

'docco' trả lời gọn lỏn: 
"Ừa, vậy càng tốt. Đỡ bị loãng." 

Rồi hỏi tiếp: 
"Vậy tóm lại quá trình thăm dò bao gồm những bước chính nào vậy anh? Và tại sao phải thực hiện những bước này?" 

Tôi đáp: 
"Đáng lẽ ra anh phải hỏi em câu hỏi này để giúp em tổng hợp những gì em đã đọc. Tuy nhiên, em có vẻ khá bối rối với những thuật ngữ kia. Anh e rằng em đang rối... tùng phè lên trong đó nên để anh tóm tắt luôn vậy. 

Thật ra không có một luật nào bắt buộc phải thao tác đúng từng bước để phục vụ mục đích thăm dò cả. Tùy mục tiêu và tùy khả năng phòng bị và thắt chặt của mục tiêu mà khai triển kế hoạch thăm dò cho thích hợp. Anh nghĩ mình có thể tóm gọn chúng lại thành ba phần chính: 
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát 
- rà quét (scanning) --> xác định các dịch vụ tổng quát 
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể. 

Em thử suy luận xem, tại sao phải tìm dấu ấn? tại sao phải rà quét và tại sao phải thu thập thông tin cụ thể?" 

'docco' rụt rè: 
"Dạ... em nói đại nghe? Tìm dấu ấn để xác định hệ điều hành nào mình đang đối diện nhằm thu hẹp biên độ dò tìm và khai triển bước kế tiếp được chính xác hơn. Còn rà quét thì em nghĩ... đã tiến tới một bước rất cụ thể là tìm xem có những dịch vụ nào đang được cung cấp trên mục tiêu mình muốn thăm dò để thiết lập kế hoạch thâm nhập. Còn lấy số liệu cụ thể... ùmm... à... em không biết nữa." 

Tôi cười, cổ vũ 'docco': 
"Em trả lời hai phần đầu vậy là súc tích và chính xác lắm rồi. Tất nhiên phần thứ ba là phần lấy kết quả, là phần kết thúc quá trình thăm dò chớ còn gì nữa em? Bước này càng cụ thể hơn bước thứ nhì là mình dùng nó để thiết lập bước thâm nhập. Vậy mình có thể thêm vào bảng liệt kê ở trên như sau: 
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát --> thu hẹp biên độ thăm dò 
- rà quét (scanning) --> xác định các dịch vụ tổng quát --> thiết lập kế hoạch thâm nhập 
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể --> thiết lập bước thâm nhập 

Em thấy có gì đặc biệt với bảng liệt kê này không?" 

'ccxx' xen vào: 
"Càng lúc càng cụ thể phải không anh?" 

Tôi đáp: 
"Đúng rồi đó em. Càng lúc càng cụ thể và càng cụ thể càng tốt. Thật ra 3 'bước' ở trên có thể kết hợp lại thành 1 'bước', cũng có thể tách rời ra làm 2 'bước' hoặc mở rộng ra thành... mấy chục bước. Với mục đích dò tìm thông tin thì miễn sao tìm được thông tin cụ thể và chính xác là được, không nhất thiết phải theo... 'bước'." 

'cuti' thắc mắc: 
"Nhưng tại sao tìm footprint lại quan trọng thế anh? Em thấy một web server apache chạy trên Windows 2000 và một web server apache chạy trên Linux đâu có khác gì đâu anh?" 

Tôi đáp: 
"Nếu nhìn một cách tổng quát trên phương diện người dùng thì nhận định của em không sai nhưng nếu xét cẩn thận về mặt kỹ thuật thì nhận định của em chưa.... hoàn toàn đúng. Trên phương diện người dùng, cả hai apache (em đưa ra) đều nhận request, xử lý request, đều có thể gắn với asp, jsp, php, cgi... để tạo trang động nhưng xét cho cặn kẽ thì cơ chế quản lý bộ nhớ lẫn cơ chế điều tác process trên hai hệ điều hành khác nhau rất xa. Những khác biệt này dẫn tới chiến lược phòng thủ hay tấn công rất khác nhau. Việc nhận diện dấu ấn của mục tiêu không chỉ giúp giới hạn biên độ thăm dò và khai thác mà nó còn trực tiếp ảnh hưởng đến việc: 
- quyết định 'tấn công' hay 'rút lui' (nói theo phương diện tấn công) hoặc, 
- quyết định 'thắt chặt thêm' hay 'xây dựng lại từ đầu' (nói theo phương diện phòng thủ)." 

'cuti' vẫn thắc mắc: 
"Em vẫn thấy vấn đề này hơi mù mờ đó anh. Nếu cần tấn công một webserver apache có chạy php chẳng hạn thì cũng bấy nhiêu kỹ thuật như sql inject, xss... vậy thì chạy trên Windows hay trên *nix đâu có khác gì?" 

Tôi trả lời: 
"Em nói đúng nhưng cái đúng này bị áp đặt trong một giới hạn khá hẹp. Tấn công và thâm nhập một dịch vụ (web chẳng hạn) không chỉ dừng lại ở sql inject và xss. Đây là những kỹ thuật phổ biến và dễ thực hiện, hơn nữa những lỗi này lại thường thấy nên thường được chú trọng. Nếu 'tấn công' chỉ dừng lại ở chỗ 'chôm' được admin password của một forum hay đưa lên một thông điệp trên một trang web để 'deface' thì mấy kỹ thuật em đề cập đã đủ dùng. Nếu thế thì phạm vi reconnaissance ở đây rất nhỏ hoặc không cần thiết nữa. Những điều anh đưa ra ở đây có thể dùng để ứng dụng nhiều khả năng và kỹ thuật thâm nhập hơn nữa, cho nên reconnaissance trở nên cần thiết. Ví dụ, em muốn chạy shellcode đến dịch vụ web của server để lấy một cái 'shell' cho mục đích thâm nhập sâu hơn nhưng không xác định chính xác hệ điều hành của mục tiêu thâm nhập là gì thì không có cách gì tạo shellcode được. Lý do, shellcode của mỗi hệ điều hành mỗi khác. 

Nếu mục tiêu thâm nhập càng sâu thì quá trình reconnaisance đòi hỏi càng phải cẩn thận và chi tiết. Ngay cả những 'màn' tấn công thuộc loại 'dơ' như DoS chẳng hạn, để thực sự 'giết' mục tiêu mình muốn DoS, em phải hiểu rất rõ điểm yếu của hệ điều hành và dịch vụ đang chạy. DoS 'chết' một Windows server chạy Apache + php (dùng prefork) và không có database connection pool nhanh hơn DoS chết một Linux server chạy Apache + jsp (dùng worker) và có connection pool hẳn hòi. Những chi tiết này ở đâu ra? Đó chính là kết quả quả 'reconnaissance' đó em. 

Năm ngoái, một server do anh quản lý (chạy Linux) bị mấy 'ông thần' nào đó dùng 'ping of death' để tấn công. Điều buồn cười là dạng 'ping of death' này dành cho Windows phiên bản cũ, bị lỗi ở phần giới hạn packet size của ICMP làm treo máy khi bị tấn công. Anh không hiểu sao nhóm này cứ hè nhau mà tấn công Linux server của anh bằng một thứ công cụ dành để tấn công Windows. Hơn nữa, Linux server của anh hoàn toàn cản mọi inbound ICMP và UDP. Các gói tin ICMP và UDP chỉ có thể đi vào khi chúng mang vai trò trả lời cho các request đi từ bên trong Linux server mà thôi. Điều này có nghĩa những gói ICMP họ 'tia' vào server của anh bị huỷ ngay khi đụng firewall. Vậy mà nhóm này vẫn nhắm mắt, nhắm mũi 'tia' đến mấy tiếng liên tục rồi mới chịu ngưng. Tất nhiên dạng tấn công như thế chẳng làm suy suyển server của anh mảy may nào hết. Điều đáng nói là nguồn tấn công hoàn toàn đi từ VN ra và điều đáng buồn là những 'ông thần' này không thèm tìm hiểu xem 'ping of death' là gì, thật sự đã tạo ra tác hại gì đến server của anh không. Có lẽ mấy 'ông thần' này tìm đâu ra mấy cái script viết sẵn trên Internet rồi hè nhau mà 'ria' vào server của anh chăng?" 

'docco' lè lưỡi (một biểu tượng được dùng trên YIM) rồi lên tiếng: 
"Ái chà, bây giờ em mới hiểu lý do tại sao reconnaissance lại quan trọng như thế. Lúc đọc tài liệu, em cứ ngỡ đây là những bước cần phải làm cho đúng nguyên tắc và chẳng thấy có phân tích mấu chốt của reconnaissance là gì hết. Em cũng có đọc sơ sơ qua về shellcoding và thấy hoàn toàn mù tịt. Còn chuyện mấy 'ông thần' tìm đồ chơi trên mạng rồi đi 'ria' là chuyện thường ngày mà anh? " 

Tôi đáp: 
"Anh nghĩ sách vở thường giới thiệu những điểm chung nhất và dễ tiếp nhận nhất. Sau khi thử nghiệm, tự nhiên em sẽ 'ngộ' ra lý do của từng phân đoạn trong cả một quá trình thực hiện. Những người càng kinh nghiệm về bảo mật thì bước thăm dò của họ càng chiếm nhiều thời gian. Đối với một kẻ có chủ trương 'tấn công', hắn phải dò xét hết sức cẩn thận trước khi bắt tay vào thực hiện ý định của mình để đạt được mục đích, ít tốn thời gian, ít có cơ hội bị... tóm. Cũng lắm lúc, kẻ này bỏ cuộc vì sau khi dò xét cẩn thận, hắn cảm thấy không đáng để mất thời gian. Đối với người phòng thủ, quá trình 'dò xét' lại càng khó hơn bởi vì người phòng thủ phải đặt mình vào vị trí khách quan, phải test hệ thống của mình y như một 'black box' thật sự rồi từ đó mới đi đến việc kiện toàn bảo mật." 

'cuti' nhận xét: 
"Nhưng làm sao mình có thể dò xét ra một server nào đó đang chạy Windows, dùng php và dùng prefork chớ không phải nó đang chạy Linux, dùng jsp và dùng worker vậy anh? Bộ 'reconnaissance' có thể cung cấp thông tin ở mức độ này luôn sao?" 

Tôi cười, đáp: 
"Cái này tùy vào khả năng thăm dò của em. Có nhiều yếu tố để giúp em đi đến chỗ kết luận là mục tiêu thăm dò của em có cái gì. Bởi vậy, như anh đã nói, giai đoạn reconnaissance có thể là giai đoạn mất thời gian nhất. Riêng chi tiết Windows chạy apache với php hay Linux chạy apache với jsp thì phần lớn em cần có một số kiến thức và dùng khả năng suy luận để đưa về một kết luận nào đó có lý nhất." 

'cuti' càng thêm tò mò: 
"Vậy có nghĩa là sao anh? anh nói sâu hơn một tí được không anh?" 

Tôi đáp: 
"Hèm... ok, để anh thử tóm gọn xem sao. Nếu em rành php, em hẳn biết là php trước phiên bản 5.x hoàn toàn không thread-safe. Ngay cả những người đang dùng php 5.x không không mấy ai 'dám' dùng ở chế độ 'thread-safe' cả. Nếu em dò một website và biết rằng nó chạy bằng php trên apache, em có thể đoán 99% là nó chạy ở chế độ prefork. Nếu em chịu khó dò thêm footprint của hệ điều hành và xác định được nó chạy trên Windows server thì em có thể xác định nó chạy php trên apache với chế độ prefork. Tương tự, nếu em dò một website và biết nó chạy bằng jsp, em có thể đoán 99% là nó chạy ở chế độ worker. Nếu xác định được thêm hệ điều hành là Linux thì em càng có thể khẳng định nó chạy jsp trên apache với chế độ worker. Tất nhiên, thu thập càng nhiều thông tin, càng giúp em khẳng định phỏng đoán của em chính xác và để thu thập nhiều thông tin thì 'reconnaissance' càng mất thời gian là vậy. Nên nhớ là luôn luôn có những sai số trong 'reconnaissance' vì người phòng thủ cố tình dấu footprint hoặc đánh lừa các công cụ em dùng để lấy footprint. Những sai số này càng nhiều thì kết quả càng ít đáng tin cậy." 

'cuti' gật gù: 
"Hoá ra đây là cả một nghệ thuật chớ chẳng đùa. Những kiến thức và kinh nghiệm cho việc xác định 'nó' chạy php hay jsp cũng đủ đã điên cái đầu rồi. Dân không đụng những chuyện này thì biết đường nào mà mò anh? Như vậy rõ ràng kiến thức có sẵn tuyệt đối quan trọng. Nếu không có thì ngay cả việc thăm dò cũng không thể được. Biết gì mà thăm dò?" 

Lần này 'ccxx' góp chuyện: 
"Thì bởi, em đọc những mẩu đối thoại của anh già khó tính và mấy ông tướng này, em thấy anh nhấn mạnh rất nhiều lần cái gọi là 'ngọn ngành'. Những mẩu thông tin nho nhỏ đều đi từ 'ngọn ngành' ra phải không anh?" 

Tôi cười, đáp: 
"Đúng đó 'công chúa xinh đẹp' . Anh có lặp đi lặp lại nhiều lần: 'muốn bảo vệ hay tấn công, mình phải nắm rõ mục tiêu' là vậy đó. 'reconnaissance' chính là bước để giúp 'nắm rõ mục tiêu' ở khuôn khổ 'blackbox' vậy." 

'docco' xen vào hỏi thêm: 
"Khái niệm 'blackbox' là sao anh? Với lại 'prefork' khác gì với 'worker' vậy anh?" 

Tôi đáp: 
"Em chưa từng nghe qua 'blackbox' và 'whitebox' sao? Sẵn đây mình nên làm quen với khái niệm này luôn. 'blackbox' chỉ cho hoàn cảnh thử nghiệm một server mình hoàn toàn không biết gì về nó; mình chỉ ở bên ngoài, chọc ngoáy nó để tìm thông tin mà thôi. Trong khi đó, 'whitebox' là một server mình nắm rõ nó có những gì, nó hoạt động ra sao và cung cấp những gì. Những công ty tư vấn về bảo mật thường thử nghiệm độ bảo mật của hệ thống theo dạng 'blackbox' là chính. Họ không biết gì về hệ thống của khách hàng cả nhưng họ vận dụng mọi phương tiện để thẩm định độ bảo mật của hệ thống này. Sau khi hoàn thành giai đoạn 'blackbox' rồi họ mới đi đến giai đoạn 'whitebox' và mới giới thiệu phương án phòng thủ. 'whitebox' test thường dùng để thử nghiệm tính năng và hoạt động của hệ thống dựa trên một số thước đo nào đó. 

Riêng 'prefork' và 'worker' thì thế này. Đúng ra mình phải dùng thuật ngữ 'process' và 'thread' thì thích hợp với tinh thần mình bàn ở đây hơn. Lý do anh dùng 'prefork' và 'worker' là vì mình đang nói về webserver apache và những thuật ngữ này là những thuật ngữ của apache. 'prefork' là cơ chế xử lý request của apache bằng cách tạo process. Process thì thường nặng nề, tốn tài nguyên và kém hiệu xuất nhưng được một điểm là rất bền, ít bị sự cố. Trong khi đó, 'worker' là cơ chế xử lý request của apache bằng cách tạo thread. Thread thì nhẹ nhàng, ít hao tốn tài nguyên hơn, hiệu xuất hơn nhưng lại có nhược điểm là kém bền bỉ, dễ bị sự cố. Nói trên bình diện bảo mật và đặc biệt là tính hiệu xuất cũng nhưng tính bền bỉ của một dịch vụ, mỗi chọn lựa đều có điểm ưu và khuyết. Tuỳ nhu cầu và hoàn cảnh mà chọn cho thích hợp." 

'cuti' diễu: 
"He he, đừng bắt bọn em phải học kỹ về thread và process đó nha anh. Chết tụi em đó " 

Tôi đáp: 
"Lại 'bắt' . Anh chẳng bao giờ 'bắt' em phải làm gì cả. Đến một lúc nào đó, tự nhiên em cảm thấy cần phải hiểu về 'thread' và 'process' thì tự nhiên em tìm hiểu thôi. Lúc ấy anh có 'bắt' em không tìm hiểu cũng chả được. Nói đùa vậy thôi, nếu siêng, em nên tìm hiểu dần dần về 'thread' và 'process'. Theo anh, đây là một trong những 'đơn vị' nền tảng của những điều em đang làm quen đó." 

'docco' cảm thán: 
"Không ngờ từ chuyện này lại dẫn đến bao nhiêu là chuyện khác. Đúng là 'bể học mênh mông, dục tốc bất đạt' thật không sai tí nào." 

Tôi cười, động viên 'docco': 
"Thong thả thôi em, việc gì phải 'dục tốc' để rồi 'bất đạt'? Đừng tham quá mà đi đến chỗ 'bội thực' mà thôi." 

'docco' hỏi tiếp: 
"Vậy khái niệm 'active' và 'passive' recconnaissance mà anh đề cập lần trước liên quan thế nào đến 3 bước ở trên vậy anh?" 

Tôi ngẫm nghĩ "chà, các 'bước' là các bước còn 'active' hay 'passive' là dạng. Làm thế nào để cu cậu đừng lẫn lộn đây nhỉ?", thế rồi tôi trả lời: 
"Thế này, 'active' hay 'passive' là các dạng thăm dò, còn 3 bước ở trên là cụ thể các bước khai triển. Em có thể dùng dạng 'active' hoặc 'passive' hoặc cả hai dạng này để thực hiện 3 bước ở trên. Đây là mối liên quan mà em thắc mắc đó." 

'cuti' nhanh nhảu: 
"Vậy... ví dụ bước một, khi nào mình dùng 'active', khi nào mình dùng 'passive' anh?" 

Tôi hỏi ngược lại: 
"Vậy em còn nhớ mục đích của việc dùng 'active' và 'passive' để thăm dò không?" 

'cuti' đáp: 
"Dạ nhớ chớ anh. 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơn. Nhưng ý em là trong lúc tìm footprint, khi nào thì thao tác 'passive', khi nào thì dùng 'active' đó mà." 

Tôi chỉnh 'cuti' ngay vì không chịu suy nghĩ mà chỉ hỏi 'trơn': 
"Em vừa trả lời ngay câu hỏi của em đó thôi. Nếu đã nắm được 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơnthì tại sao không dùng nó mà ứng dụng? Anh nghĩ em nên động não hơn một tí đó Hưng." 

'ccxx' xen vào: 
"Anh nói đúng đó, ông Hưng này có cái tật dễ thì đâm lười đó anh. Anh quay ổng như 'dế' thì ổng sẽ động não thôi, đừng trả lời mọi câu hỏi của ổng là cách hay nhất. Em biết lắm mà ." 

Tôi cười, đáp: 
"Ừa, em mà không biết cu Hưng 'lắm' thì còn ai biết nữa em? Thôi... em 'quay nó như dế' dùm anh nha?" 

'ccxx' cười thích chí: 
"Hi hi hi, anh hông biết đó thôi, em quay ổng như cơm bữa mà không thì 'dễ hoá lười' liền thôi." 

'docco' có vẻ bồn chồn với những đối thoại thuộc dạng chit chat, cu cậu xen vào: 
"E hèm... hơi bị... lạc đề á. Anh già ơi, cho em hỏi thêm cái này nha? Có bao nhiêu cách để xác định footprint vậy anh? Em đọc sách thấy có khá nhiều công cụ, vậy theo anh mình nên dùng cái nào?" 

Tôi đáp: 
"Anh không thể nói rõ có bao nhiêu cách vì anh không biết thật sự có bao nhiêu cách. Cái này tùy vào tính linh động và khả năng sáng tạo thôi em. Anh cũng không thể trả lời em là nên dùng công cụ nào. Chỉ có chính em tự tay dùng rồi chọn lấy một hoặc nhiều công cụ em thích mà thôi. Có những công cụ 'gom' luôn các công đoạn xác định hệ điều hành, xác định các dịch vụ đang chạy (open ports) thậm chí lấy luôn cả phiên bản của software cung cấp dịch vụ. Tuy nhiên, công cụ nào cũng có ưu khuyết điểm cả. Ví dụ nmap là một port scanner rất độc đáo, nó có thể thực hiện ba điều ở trên cùng một lúc nhưng nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' vì nó không những 'active' mà 'extremely active'. Những hệ thống có trang bị IDS, IPS sẽ phát hiện ngay là có nmap đang dò dẫm và đây là điều bất lợi cho việc thăm dò." 

'docco' phát biểu: 
"À, vậy nmap là công cụ thuộc dạng 'active' rồi. Em phải ghi nhớ chuyện này." 

Tôi cười, nói: 
"Không hẳn là như vậy đâu em. Anh nói là nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' cơ mà. Nếu em dùng nó đúng mức, nó không còn 'extremely active' nữa. Nó không phải 'passive' nhưng cũng không hẳn là 'active' bởi vì em không tạo ra nhiều 'tiếng ồn' trong khi rà (nếu dùng đúng mức)." 

'cuti' cảm thán: 
"Chẹp... chỉ có chuyện 'rà' không mà cũng lắm nguyên tắc và công phu đến thế. Chắc lại phải học thêm nmap roài." 

Tôi đáp: 
"Em có vẻ bồn chồn với chuyện làm quen với những công cụ mới hay sao vậy Hưng? người ta viết hàng ngàn dòng code, xây dựng hàng trăm signature, viết manual sẵn. Em chỉ có việc đọc và dùng mà còn rên rỉ sao em? Kiểu này bắt đầu nguy rồi đó." 

'cuti' đính chính lia lịa: 
"Hông, hông có đâu anh. Em thức sáng đêm để quậy còn được mà. Ý em sau mỗi lần nói chuyện với anh là có thêm hàng loạt thông tin mới, cả đống công cụ mới để thử, để làm quen. Em cảm thấy có một phần sức ép nào đó để đuổi bắt với thông tin anh đưa ra thôi anh." 

Tôi cười: 
"Hì hì, vậy em còn muốn 'hack' không? Anh cũng cảm thấy điều đó nên mấy anh em mình 'đà khía' ít thường xuyên hơn là thế. Em không nên nghĩ và tự tạo sức ép cho mình là phải thông thạo, phải nắm vững các thông tin mới mẻ ngay lập tức. Từ từ, thong thả thôi em." 

'docco' hỏi tiếp: 
"Hồi nãy anh nói đến vấn đề 'ồn', ồn ở đây là những dấu hiệu mà hệ thống phát hiện phải không anh?" 

Tôi đáp: 
"Đúng rồi đó em. 'Ồn' ở đây chính là những thông tin được ghi nhận trong các log files của hệ thống hay các hệ thống phát hiện gần như 'real time' như IDS/IPS đó. Mỗi dạng thăm dò thường có tính chất đặc thù và những đặc thù đó được ghi nhận trên các hệ thống phòng thủ, còn gọi là 'signature'. Nếu admin của hệ thống ấy bất thình lình thấy có hàng loạt cú 'rà' trên hệ thống của mình thì coi như mục đích thăm dò và thâm nhập của ai đó bị hỏng. Nếu admin không nhận thấy những dấu hiệu này mà IDS/IPS nhận thấy thì tình hình cũng chẳng khác gì mấy. Không riêng gì nmap mà tất cả các software em dùng, cái nào cũng 'ồn' cả thôi. Chỉ có cái khác là em 'thấy' hay 'không thấy' được cái 'ồn' đó thôi . Để rà một máy con của một người đang duyệt web thì chẳng phải lo mấy đến cái 'ồn' cả vì họ hiếm khi 'thấy' được sự 'ồn' đó. Tuy nhiên, để rà và thăm dò một máy chủ, một mục tiêu đáng để thâm nhập hay đáng để bảo vệ thì mỗi chi tiết 'ồn' đều là dấu hiệu quan trọng." 

'ccxx' thắc mắc: 
"Để khỏi bị 'ồn', mình không cần thăm dò kỹ mà chỉ tấn công thẳng vào dịch vụ web thì sao anh?" 

Tôi cười, đáp: 
"Thì mình nắm phần thất bại nhiều hơn là thành công 'công chúa xinh đẹp' ạ." 

'ccxx' phụng phịu: 
"Ứ ừ, em hỏi thật mà anh cứ đùa hoài." 

Tôi cười phá lên và tiếp tục: 
"Á à, anh trả lời thật mà em cứ ngỡ anh đùa hoài. Mình tấn công thẳng vào dịch vụ web là tấn công thế nào em? Mình không nắm được nó mạnh, yếu chỗ nào thì mình chỉ 'đấm đá' kiểu 'bịt mắt' thôi thì có trúng trật vào đâu nào? Cái này cũng giống như trường hợp 'ping of death' anh nói hồi nãy thôi em. Nó cũng giống như muốn đục cánh cửa sắt của két tiền mà cứ dùng dùi đục bằng gỗ mà phang vào cửa sắt thì chừng nào thủng được cái tủ? " 

'ccxx' giả lã: 
"Hi hi, anh già vui tính ghê. Chắc em hỏi hơi ngớ ngẩn thật đa. Lần sau em sẽ uốn lưỡi 7 lần trước khi hỏi cho chắc ăn." 

Tôi đáp: 
"Không em, em cứ nói chuyện thoải mái. Có bất cứ ý nghĩ nào nảy ra trong đầu cứ phát biểu. Chuyện đúng, sai, ngớ ngẩn không quan trọng mà quan trọng ở chỗ em rút tỉa được những gì trước và sau khi đưa ra câu hỏi. Nếu em e dè quá thì cuộc đối thoại của mấy anh em mình sẽ 'khô' như rơm thôi." 

'ccxx' trả lời: 
"Dạ. Em cứ thế mà phang, anh chuẩn bị tinh thần đó nha." 

'docco' xen vào: 
"Không biết em nhận xét những cái này có đúng hông, anh xem thử nha. Ví dụ muốn khám phá các chi tiết thuộc về domain name của một host nào đó, mình có thể dùng một công cụ online để xem mà không cần tiếp xúc trực tiếp từ máy của mình đến DNS server của mục tiêu. Cái này gọi là thăm dò ở dạng 'passive' phải không anh?" 

Tôi đáp: 
"Đúng lắm. Nó hoàn toàn 'passive' bởi vì em chỉ 'query' thông tin một domain, một host nào đó trên một DNS database công cộng. Có thể DNS em đang query sẽ liên hệ với authoritative DNS server của mục tiêu em đang thăm dò để lấy thông tin, cũng có thể là không vì nó dùng thông tin có sẵn trong cache không chừng. Dù gì đi chăng nữa, đây vẫn là dạng 'passive' bởi vì admin cũng như hệ thống IDS của mục tiêu em muốn thăm dò đều không có cách gì biết được em đang thăm dò. Những thông tin này thường ở dạng tổng quát và dành cho công cộng. Nó cũng có ích để xác định một số điều. Tuy nhiên, để thăm dò DNS và hình thành cấu trúc mạng của mục tiêu, đôi khi em phải chuyển sang dạng thăm dò 'active'." 

'docco' hỏi tiếp: 
"Anh ví dụ một kiểu thăm dò DNS ở dạng 'active' được không anh?" 

Tôi trả lời: 
"Được chớ em. Thông thường, em dùng nslookup trên windows chẳng hạn, thì thế này: 
C:>\> nslookup 
Cách này query dùng default DNS server chính là DNS server nào em khai báo trên máy dùng để phân giải tên miền. DNS server này có thể là DNS riêng do em tạo ra hoặc DNS server do ISP cung cấp. Ở dạng đó, những điều được query cũng chỉ là những thông tin dành cho công cộng mà thôi (cái này còn tùy thuộc vào sự chặt chẽ của người thiết kế DNS, có những DNS chứa cả thông tin dàng cho công cộng lẫn thông tin dành riêng cho nội mạng và đây là điều nên tránh). Tuy nhiên, nếu em 'chịu khó' hơn một tí, thử như sau: 

C:\> nslookup 
> set type=ns 
> domain.com 
Server: [172.16.114.163] 
Address: 172.16.114.163 
domain.com nameserver = ns1.domain.com 
domain.com nameserver = ns2.domain.com 
ns1.domain.com internet address = 172.16.114.163 
ns2.domain.com internet address = 172.17.124.174 
> server ns1.domain.com 
> ls -d domain.com 
[[172.16.114.163]] 
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560) 
domain.com. NS ns1.domain.com 
domain.com. NS ns2.domain.com 
domain.com. MX 0 mail.domain.com 
www A 172.16.114.160 
white A 172.16.114.161 
mail A 172.16.114.162 
ns1 A 172.16.114.163 
ns2 A 172.17.124.174 
domain.com. A 172.16.114.160 
blue A 172.16.114.163 
red A 172.17.124.174 
domain.com. TXT "v=spf1 a mx ptr -all" 
mail TXT "v=spf1 a -all" 
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560) 


Có gì đặc biệt ở đây vậy em?" 

'docco' ngần ngừ: 
"Ùm... à.... hình như anh cố tình dùng chính DNS của chính mục tiêu để query phải không anh?" 

Tôi đáp: 
"Bravo! Đúng như thế, nó nằm ở đây: 

> server ns1.domain.com 
> ls -d domain.com 
. 
Em biết lý do tại sao không? Ngày nay, hầu hết các authoritative DNS đều không cho 'zone transfer' một cách rộng rãi nữa vì quá nguy hại. Tuy nhiên, vẫn có các DNS server cho phép những DNS server được 'tin cậy' thực hiện 'zone transfer'. Bởi thế, mình mới 'láu cá' bằng cách mượn tay DNS server được 'tin cậy' để query thông tin cho mình . Nên nhớ là có những DNS server (primary và secondary) hiện nay không còn cho phép thực hiện bước ở trên nữa vì họ không cho 'zone transfer' ngay cả giữa primary và secondary." 

'cuti' thắc mắc: 
"Query DNS có gì mà quan trọng đến thế hở anh? Nãy giờ em ráng theo dõi nhưng bắt đầu bị ù ù cạc cạc rồi đó. Có nhiều thông tin hoàn toàn mới mẻ đối với em cho nên tóm gọn lại, em không rõ tại sao phải thu thập những thông tin này và để có thể thu thập thông tin thì phải nắm bao nhiêu là kiến thức " 

'ccxx' xen vào: 
"Trong khi anh nói, em cũng thử và thấy quả thật mình có thể thâu thập khá nhiều thông tin qua DNS. Có khi query được, có khi không. Hình như mình có thể xác định một cách tổng quát có bao nhiêu servers trong mô hình mạng mình muốn thăm dò. Em chưa rõ bước kế tiếp thế nào nhưng em hình dung mình sẽ làm gì đó với những thông tin thu thập được. Có thể dùng để phác thảo một mô hình mạng chăng?" 

Tôi cười, đáp: 
"Công chúa nhận xét đúng lắm. Tất nhiên là mọi thông tin đều cần thiết cả, nếu không mình mất thời gian với chúng làm gì? Để hình thành mô hình mạng của mục tiêu mình muốn thăm dò, việc thăm dò DNS chỉ cung cấp một phần thông tin mà thôi. Em cần phải kết hợp với một số thông tin khác nữa. Cái này mình sẽ bàn sau. Anh lấy ví dụ đơn giản thế này nha. Giả sử em muốn tấn công một host X nhưng host này 'thủ' chặt quá. Thông thường thì em bó tay và bỏ cuộc. Tuy nhiên, nếu em thăm dò rộng ra (bằng cách hình thành mô hình mạng) thì thấy rằng host X nằm trong một nhóm host khác và một vài host ấy có thể thâm nhập được. Nếu thâm nhập được một trong các host này thì cơ hội 'nhảy' sang host X thành công cao hơn. 

Cho dù em không thể thâm nhập bất cứ host nào đi chăng nữa nhưng qua thông tin dò xét và thu thập được trong quá trình recconnaissance, em có thể đi đến kết luận là nên tiếp tục hay nên bỏ cuộc (để đỡ tốn thời gian). Nếu thấy mô hình mạng chặt chẽ quá, thấy có firewall vững vàng, cách tốt nhất là bỏ cuộc để đỡ mất thời gian. Thật ra, nếu đã thông thạo thì việc dò tìm thông tin xuyên qua DNS không mất quá nhiều thời gian đâu. Đây chỉ là một bước rất nhỏ trong quá trình thăm dò. Vấn đề mình bàn ở đây là để nhấn mạnh một điều quan trọng: tìm thông tin có rất nhiều cách, cách nào nhanh nhất, có thông tin cụ thể nhất thì đó là cách thích hợp nhất." 

'docco' cảm thán: 
"Không ngờ bên trong recconnaissance đã có những điều lý thú đến như thế. Em định hỏi thêm anh một số chi tiết về kết quả lấy được ở trên nhưng chợt nhớ ask me why, don't ask me what nên em đã ghi chú một loạt thông tin mà em cần phải tìm hiểu chi tiết sau. Cũng như Hưng, em bắt đầu thấy lùng bùng rồi đó anh. Như anh nói, vậy là recconnaissance cũng sẽ dính với chuyện dò dẫm cả firewall luôn sao anh? và đối với người phòng thủ thì nên làm thế nào? Về việc anh đề cập tới host X ở trên, hình như anh muốn nói đến khía cạnh kiện toàn bảo mật?" 

Tôi trả lời: 
"Chuyện dò dẫm firewall là chuyện không thể thiếu nếu như firewall nằm trên đường thâm nhập rồi đó em. Thong thả rồi mình sẽ bàn các chi tiết này sau, không thì em càng lùng bùng nữa. Chuyện phòng thủ thì mình cũng sẽ bàn sau khi em đã 'thông' những chi tiết mình vừa 'đà khía'. Nên nhớ rằng, 'thủ' ở đây là thực sự phòng thủ chớ không phải là những kỹ thuật nho nhỏ dùng để dấu footprint không thôi nha. Mình sẽ đào sâu từ từ những chuyện này (nếu bọn em còn hứng thú  )." 

'cuti' lên tiếng ngay lập tức: 
"Làm sao mà không còn hứng thú được anh? Những thông tin này là tổng hợp của bao nhiêu điều lý thú. Chắc em sẽ không bao giờ thâm nhập ai nhưng những kiến thức này chắc sẽ ích lợi trong công việc về sau. Anh đừng lo tụi em hết hứng thú " 

'docco' cũng chêm thêm: 
"Hay là anh .... nản thì có. Nói chuyện với bọn em cái gì anh cũng phải giải thích. Gặp em, chắc em nản từ lâu rồi." 

Tôi đáp: 
"Hì hì, nản hả? có gì mà nản em? Thỉnh thoảng vào 'đà khía' thế này vui mà. Thôi, anh phải logoff đây. Ngồi dính một chỗ lâu quá rồi. Anh vẫn còn ở nhà vài ngày tới, trưa trưa anh sẽ vào check mail mỗi ngày, đứa nào muốn 'đà khía' thì offline message cho anh một cái ha." 

'ccxx' cười, pha trò: 
"Í cha, anh già rút... đẹp thiệt à nha. Ảnh rào câu áp chót, chuyển qua câu chót là bye bye liền . Mai em cũng rảnh á, em sẽ online chờ anh." 

'cuti' hùa theo: 
"Em cũng vậy." 

'docco' thận trọng: 
"Nếu không có gì đột xuất, em cũng sẽ online luôn." 

Tôi đáp: 
"Ừa, cũng khoảng giờ này hoặc sớm hơn vào ngày mai hả? Chào mấy đứa." 


26/9/2005 

13. Information... What for? - II 

Chiều nay như đã hẹn, tôi log vào YIM. Mấy 'khuôn mặt' YIM của cuti, ccxx, haothu và docco đều "trắng bệch". Tôi thầm nghĩ, "chà, mấy trự này vẫn chưa lên hay có trục trặc gì rồi". Tôi quyết định gởi cùng một offline message cho cả bốn 'trự' để khi nào có ai lên thì cho tôi biết. Chỉ trong vài giây tôi nghe bốn tiếng "Knock, knock", "Knock, knock" và hai khuôn mặt "vàng choé" của docco và ccxx online. 'docco' chào trước: 
"Chào anh, anh lên lâu chưa vậy?" 

'ccxx' chào tiếp theo: 
"Ý chà, anh đúng giờ khủng khiếp luôn á. Em chuyển chế độ 'invisible' để khỏi phiền chớ em lên đây từ trưa á." 

Lần này tôi gởi 'conference invitation' kèm theo câu trả lời: 
"Hì hì, anh 'hên' nên đúng giờ thôi em. Anh đâu biết khi nào mấy đứa lên đâu à. Còn cuti với haothu đâu rồi?" 

'ccxx' nhanh nhảu: 
"Dạ em cũng không biết nữa anh. Em gọi di động cho ông Hưng mà chẳng thấy trả lời. Còn ông Khoa thì em chẳng thấy tung tích từ hôm qua đến giờ." 

'docco' tiếp lời: 
"À, hồi sáng em có gặp Hưng mà. Nó nói thế nào nó cũng lên. Còn thằng Khoa thì chẳng biết nó ở đâu mà mò nữa anh." 

Tôi cười, đáp: 
"Ừa, khi nào tụi nó thấy tiện thì lên thôi. Anh em mình đà khía lai rai cũng được. Hay em muốn chờ tụi nó lên luôn?" 

'docco' trả lời: 
"Dạ mình 'làm' lai rai đi anh. Chừng nào tụi nó lên thì nhập cuộc luôn cũng được." 

'ccxx' cũng hùa theo: 
"Đúng đó. Mấy ông đó chẳng biết đâu mà chờ anh ơi." 

Tôi đáp: 
"Xong ngay. Vậy mình tiếp tục câu chuyện lần trước hả? hay mấy đứa thích nói chuyện gì khác hông?" 

'docco' trả lời ngay: 
"Dạ tiếp tục chuyện lần trước đi anh. Chuyện này 'đã' hơn những chuyện tầm phào khác " 

Tôi cười đáp: 
"Nhào ngay vô liền hả? OK. Lần trước mình đang nói đến chuyện tìm 'footprint' phải hông? Anh muốn đề cập thêm một chi tiết nhỏ trong việc query DNS khá quan trọng. Hầu hết các DNS server trên Internet hiện nay dùng BIND, chạy trên UNIX. Những DNS server không thiết kế và điều chỉnh cẩn thận thường có các giá trị HINFO (Host Information) chứa những thông tin khá cụ thể về vị trị của host này, hệ điều hành đang chạy trên host này... những thông tin đó hết sức quan trọng cho việc 'thăm dò'. Anh đề cập đến chuyện này vì muốn nhấn mạnh sự quan trọng của việc thiết kế hệ thống trên phương diện bảo mật; tránh để lộ những thông tin nhạy cảm và không cần thiết trên các hệ thống tiếp diện với 'untrused networks'." 

'ccxx' hỏi ngay: 
"Phải 'untrusted networks" là Internet hông anh?" 

Tôi đáp: 
"Ừa, Internet là một trong những 'untrusted network'. Ngay cả mạng riêng của công ty vẫn có những phần thuộc dạng 'untrusted' nếu như các thông tin nhạy cảm đi xuyên qua hoặc mở rộng trong các phần này. Nói chung, 'untrusted networks' là những mạng em không thể kiểm soát được." 

'docco' thắc mắc: 
"Như anh nói ở trên, vậy HINFO chứa những thông tin nào mà nguy hiểm như vậy anh? Thật tình em chưa bao giờ thấy thông tin này." 

'ccxx' chêm vào: 
"Dạ em cũng thắc mắc điểm này luôn đó." 

Tôi đáp: 
"Ừa, em phải đụng đến nó thì mới biết . HINFO là một 'query type' khi em query DNS, tương tự như A, MX, NS, CNAME, SOA... mấy cái này em nên tham khảo chi tiết sau vì nó dính khá nhiều thứ trong đó. Mình tập trung vào HINFO ở đây để em nắm chi tiết quan trọng này thôi. Tổng quát mà nói thì HINFO chứa giá trị (và sẽ trả về giá trị nếu mình query nó) ở dạng như: 
"sparc20" "lp & fax comm room" chẳng hạn. Nó thường chứa các thông tin khá chi tiết để sysadmin dễ nhận diện host này là host gì trong mạng. Nó tiện dụng cho sysadmin nhưng lại khá nguy hiểm trên phương diện bảo mật. Bọn em đoán thử với giá trị trong ngoặc kép, nó nguy hiểm ở đâu?" 

'docco' và 'ccxx' im lặng một đỗi. 'docco' lên tiếng trước: 
"Dạ em đoán nó chỉ cho kẻ thăm dò biết server đó loại gì và vị trí server đó ở đâu . Nhưng.... vị trí 'comm room' cũng đâu giúp được gì đâu anh?" 

'ccxx' nói tiếp: 
"Hình như sparc20 là một loại server của công ty Sun phải hông anh? Em chưa thấy nó bao giờ nhưng em có nghe đến. Nếu mình biết được loại máy chắc mình có thể đoán được hệ điều hành nào đang chạy trên nó?" 

Tôi cười, đáp: 
"Cả hai đứa đoán đúng hết nhưng mỗi đứa chỉ đúng 1/3 thôi " 

'docco' bẽn lẽn: 
"Sao anh? em chỉ đoán bừa thôi mà " 

Tôi trả lời: 
"Ừa, thì em đoán ra vị trí + loại server, cái này cho 1/3 thông tin. Cô bé Như đoán được 'có thể lấy hệ điều hành' nếu biết loại máy được thêm 1/3 nữa. 1/3 còn lại cho thấy chức năng chính của máy chủ này cung cấp dịch vụ in và fax. Bấy nhiêu thông tin cũng đủ giúp cho kẻ thăm dò hình thành ít nhiều kế hoạch. Ví dụ, Solaris thường bị những điểm yếu nào? nếu máy chủ này cung cấp dịch vụ in (lp) và fax thì nó thường bị lỗ hổng ở chỗ nào? Nếu nó nằm trong 'comm room', liệu từ máy này có thể truy cập đến các máy chủ khác cũng trong 'comm room' hay không? và hàng loạt các câu hỏi khác. Độ nguy hiểm càng tăng khi kẻ đang thăm dò có nhiều kinh nghiệm." 

'docco' thắc mắc: 
"Công nhận anh phân tích ra thì thấy lý thú nhưng em vẫn chưa hình dung được độ nguy hiểm ở chỗ nào hết anh?" 

Tôi cười, chậm rãi đáp: 
"Anh cũng hiểu được tại sao em chưa hình dung ra sự nguy hiểm. Thế này, để anh kể cho nghe một mẩu chuyện ngắn, hy vọng em sẽ hiểu. Cách đây vài năm, khi anh còn làm ở một công ty khác, anh phát hiện mail server của cty anh bị spam quá nhiều. Sau khi truy ra nguồn mail được gởi đi và tổng kết số lượng mail nhận được, anh nghi rằng mail server đó bị open relay. Anh bắt tay vào kiểm tra mail server ấy thì thấy quả thật nó open relay. Anh quyết định gởi thông báo cho tay sysadmin của mail server dùng làm phương tiện để spam mail server của cty anh. Tay này năm lần, bảy lượt cố làm ngơ. Rốt cuộc hắn trả lời anh là mail server của hắn không bị cái gì hết, anh thử chứng minh xem để hắn thấy. 

Anh bèn mở cuộc thăm dò thì thấy mạng này khá lớn, có rất nhiều servers. Các servers đều dùng static IP và chỉ có một border router cho cả nội mạng. Tất nhiên là anh chứng minh cho hắn thấy mail server của hắn bị 'open relay'. Trong quá trình thăm dò, qua phương tiện query DNS, anh tìm thấy có rất nhiều servers trong nội mạng này có tên ở dạng test, ví dụ như testbed, teststage, testserver. Chỉ cần nháy mắt, anh log vào một trong những server này với account test/test một cách dễ dàng. Từ server thứ nhất, anh có thể đi vào các server còn lại bằng những phương tiện truy nhập thông thường. Anh còn thấy vô số lỗi cho phép leo thang từ user test thành root một cách không mấy khó khăn. Chỉ trong khoảng thời gian ngắn, anh gần như làm chủ mạng đó." 

'ccxx' cảm thán: 
"Wow... cool thiệt đó nha. Làm dễ như vậy sao anh? Sau đó anh làm gì nữa?" 

Tôi cười, đáp: 
"Có gì mà 'cool' em. Đây chỉ là lối thâm nhập do hệ thống bảo mật quá kém. sysadmin không có kiến thức về bảo mật hoặc quá lười biếng mà thôi. Sau đó anh chẳng làm gì hết. Anh dò dẫm qua một vòng và khám phá ra anh không phải là người đầu tiên dò dẫm trong hệ thống này mà đã có vài người khác nữa. Anh bèn tạo một số files trên vài servers rồi gởi mail (từ một trong những server trong mạng ấy) đến tay sysadmin để cảnh báo hắn. Một tuần sau anh thử quay lại thì hệ thống này đã được thắt chặt. Vậy, hai đứa rút ra được gì từ câu chuyện trên?" 

'docco' cười, trả lời: 
"Hì hì, hình như anh đổi rơ hay sao đó. Mấy bữa trước anh cho tụi em hỏi thoải mái, hôm nay em thấy anh hỏi tụi em không à. Phần em thì em thấy có mấy chi tiết anh nhấn mạnh ở điểm test. Nếu không có các chi tiết này chắc anh không máy mó thêm phải không anh?" 

'ccxx' cũng xen vào: 
"Hi hi... em thấy cái vụ 'test/test' này đúng là hay tỉ luôn đó. Em có đi làm thêm ở một công ty và thấy cái gì cũng 'test/test'. Bây giờ anh kể chuyện này, hoá ra ở đâu cũng có thói quen này." 

Tôi đáp: 
"Em tinh mắt lắm. Chỉ vì 'test/test' mà làm anh tò mò và 'thử' thêm cho nên mới dẫn đến chỗ anh vào gần như mọi server của mạng đó. Tay sysadmin này lười biếng nên hắn set mọi server đều 'trusted' nên dùng 'rlogin' là vào tuồn tuột, khỏi password, khỏi gì hết. Điều cần nhấn mạnh ở đây là những thông tin trông có vẻ nhỏ nhưng có thể dẫn đến hậu quả khó lường. Người dùng, ngay cả sysadmin, mà lười biếng và thiếu cẩn thận thì ở đâu cũng 'test/test'. Em có tin rằng nếu anh không thử thăm dò, không query DNS và không thấy 'test' hiện lên thì chẳng có chuyện gì xảy ra không? Đây là anh không có ý định thâm nhập, còn đối với kẻ thật sự có ý muốn thâm nhập thì những thông tin này còn quý hơn... vàng . Vậy, mấy đứa thử nghĩ xem, đứng trên phương diện bảo mật, mình rút tỉa được điều gì ở đây?" 

'ccxx' đáp lời ngay: 
"Bỏ hết mấy cái 'test/test' phải không anh?" 

'docco' thêm vào: 
"Thắt chặt hệ thống phải không anh?" 

Tôi cười xoà: 
"Ái chà, một đứa thì quá cụ thể, một đứa thì quá tổng quát. Cả hai đứa đều đúng nhưng ráng suy nghĩ thêm một chút để tìm một câu trọn vẹn xem sao?" 

Cả hai 'ccxx' và 'docco' im lặng hồi lâu. 'docco' lên tiếng trước: 
"Em nghĩ là hệ thống ấy cần phải dấu hết những gì không cần công bố với công cộng. Phải thiết kế lại mạng và hệ thống phòng thủ." 

'ccxx' nói tiếp: 
"Gặp em thì em đuổi cổ cái tay sysadmin đó vì cái tội lười biếng hoặc thiếu khả năng. Nếu hắn cẩn thận và chịu khó thì có lẽ anh không dễ dàng thâm nhập đến như thế đâu." 

Tôi đáp: 
"E hèm... cả hai đứa đều đúng hết. Chỉ có 'công chúa xinh đẹp' hơi... hung dữ một tí thôi . Nếu gom hai câu trả lời thành một thì hoàn chỉnh rồi đó. Tuy nhiên, 'đuổi cổ' hắn như thế có thể hơi oan vì sysadmin chưa hẳn là chuyên viên bảo mật đâu em. Có thể công tác chính của hắn là làm sao cho hệ thống chạy ổn định là được rồi. Cái này cũng cho thấy một điều là làm chuyên viên bảo mật hay chuyên viên 'thâm nhập' còn phải kinh nghiệm và có khả năng nhìn sâu, rộng hơn sysadmin bình thường." 

'docco' cảm thán: 
"Bây giờ em mới hiểu được việc thăm dò quan trọng như thế nào. Quả thật những điều này hết sức lý thú. Có thể em đọc chưa nhiều nhưng em có cảm giác những điều anh nói ở đây toàn là 'kinh nghiệm xương máu' chớ chẳng thấy trong sách." 

Tôi đáp: 
"Anh đoan chắc là những người khác cũng 'thấy' những điều anh 'thấy' và hơn nữa. Điều quan trọng ở đây là khả năng nhận xét một cách nhạy bén. Càng nhạy bén càng tốt. Từ thông tin trong HINFO đến những chi tiết rất nhỏ bé khác trong quá trình thăm dò có thể dẫn đến những điều không thể ngờ trước được. Đây cũng là điều giúp cho mình thấy là không có một công thức cụ thể nào cho việc thâm nhập cả. Mọi chuyện là do tính nhạy bén và sáng tạo của mình mà ra thôi." 

'ccxx' hỏi thêm: 
"Có một số chi tiết anh đi lướt qua như 'open relay', 'rlogin', 'trusted'.... em thấy lạ hoắc à. Đây có phải là những kiến thức căn bản không anh? Em chưa hề nghe qua những cái này bao giờ." 

Tôi đáp: 
"Căn bản thì cũng không hẳn đâu em. Anh nhớ anh có đề cập đến r series cho rlogin, rsh, rexec và 'trusted network' ... trong một lần 'đà khía' trước đây. Em hỏi cu Hưng bản lưu của lần trò chuyện đó về đọc. Những cái này chỉ thấy trên UNIX là chính. Nó mang lại tính tiện dụng nhưng làm hỏng tính bảo mật của hệ thống. Riêng khái niệm 'open relay' thì chỉ khi nào em thiết kế một MTA (mail transfer agent), hay còn gọi là mail server thì mới đụng đến vấn đề 'mail relay'. Ngay cả chỉ thiết kế nó cho chạy đưọc cũng không đụng tới mail relay đâu. Chỉ khi nào em cần bảo mật nó thì mới đụng tới phương diện này. Đại khái 'mail relay' là một cơ chế cho phép máy con thuộc mạng này dùng mail server của mạng kia. Trên mặt nguyên tắc thì nó tiện dụng nhưng lại nguy hiểm vì từ tiện dụng hoá thành... lạm dụng . 'mail relay' là phương tiện chính cho nạn spamming đang lan tràn trên Internet." 

'docco' cười thích thú: 
"Chắc bà Như chưa quen đó thôi. Anh D đi xuyên qua những vấn đề được đặt ra rất tốc độ. Tui rút kinh nghiệm và viết xuống hết những từ khóa quan trọng rồi về tự tìm hiểu sau. Có gì kẹt thì lần sau hỏi ảnh tiếp. Có những 'từ khoá' mở ra thành nhiều trăm trang tài liệu, thành nhiều cuốn sách luôn đó bà ơi. Lúc trước tui hơi ngỡ ngàng vì anh ấy chỉ thường giải thích các thắc mắc dựa trên điều kiện là mình phải nắm ít nhiều căn bản. Dần dà, tui ngộ ra được điều này, hi hi." 

'ccxx' đáp: 
"Vậy hả? có lẽ Như chưa đọc kỹ chi tiết của những lần đối thoại trước. Chắc kỳ này phải đọc lại thật kỹ. Cám ơn ông 'chỉ điểm' dùm nhe Duy." 

'ccxx' nói tiếp: 
"Bây giờ em mới hiểu lý do tại sao ông Hưng lại 'nghiện' những cuộc 'đà khía' đến như vậy. Em có quan niệm là cả ngày đã 'ôm' cái máy thì ban đêm nên dành thời gian cho chuyện khác nên mỗi lần ông Hưng mà đề cập đến máy tính là em gạt ngang. Không ngờ anh em mình nói chuyện kỹ thuật nhưng em cảm thấy thích thú và dễ chịu như đang trao đổi những chuyện bình thường trong đời sống vậy." 

Tôi cười và đáp: 
"Hì hì, 'skeptic blinds h(im)erself'. Nên bước vào một sự việc với tinh thần và thái độ mở rộng không thì em tự động hạn chế mình đó 'công chúa xinh đẹp'." 

'ccxx' đáp gọn: 
"Dạ, cám ơn anh. Em sẽ suy gẫm thêm." 

'docco' tiếp tục khai triển: 
"Vậy query DNS là một bước của quá trình thăm dò. Những gì tiếp sau đó vậy anh? À, em nhớ có một quyển sách nói về chuyện thăm dò có dùng từ 'profiling' nữa. Có phải đây cũng là một loại thăm dò?" 

Tôi đáp: 
"Profile tạm dịch là 'sơ yếu lý lịch' và profiling có nghĩa là 'hành động hình thành sơ yếu lý lịch' đó em. Đây cũng là một thuật ngữ được dùng trong công tác thăm dò. Ví dụ em muốn thăm dò một máy (host profiling), một mạng (network profiling) hoặc một tổ chức (organisation profiling) thì em cần hình thành một bảng 'sơ yếu lý lịch' cho từng mục tiêu. Trong bảng sơ yếu lý lịch này em điền vào những thông tin tìm được trong quá trình thăm dò." 

Đang trò chuyện tới đây thì 'cuti' vào. Cu cậu xuýt xoa vì vào trễ và gởi cho tôi một thông điệp: 
"Chào anh già khó tính . Em đi công chuyện, gởi xe nhưng làm mất thẻ gởi nên đủ thứ chuyện phiền phức, mất thời giờ. Anh với mấy đứa kia nói chuyện lâu chưa anh?" 

Tôi đáp lời 'cuti' bằng cách mời 'cuti' tham gia 'conference', kèm theo câu trả lời: 
"Cũng khá lâu rồi em. Không sao đâu, mình còn lai rai được vài chục phút nữa." 

'cuti' vào 'conference' và xin lỗi mọi người vì vào trễ. Tôi tiếp tục trả lời 'docco': 
"Tùy theo mục tiêu của em là một host, một network hay cả một organisation, profiling sẽ cần nhiều hay ít thông tin. Nguyên tắc căn bản áp dụng cho các mục tiêu đều như nhau. 
- thứ nhất: em cần biết mục tiêu đang ở đâu, đang thuộc network nào. 
- thứ hai: em cần biết từ nơi em đang thực hiện thăm dò đến mục tiêu cần thăm dò sẽ đi qua những chặng network nào. 
- thứ ba: em cần biết mục tiêu có những dịch vụ nào. 
- thứ tư: em cần biết mục tiêu được bảo vệ như thế nào. 

Từ những thông tin thu thập được, em sẽ hình thành một cái gọi là profile." 

'cuti' xen vào: 
"Hay là anh cho bọn em một ví dụ cụ thể đi anh? Em thấy cách này dễ 'tiêu hoá' nhất đó." 

Tôi đáp: 
"Cũng được thôi em. Tuy nhiên, anh muốn tránh lối khai triển rập khuôn, theo từng bước cho nên em đừng theo ví dụ mà thực hiện nếu em muốn thăm dò. Nên vận dụng trí tưởng tượng của mình. Tất nhiên là em cần phải trau dồi một số kiến thức căn bản về giao thức mạng, dịch vụ trên mạng và công cụ kiểm tra / khắc phục sự cố cho mạng." 

Tôi nói tiếp: 
"Tiếp theo ví dụ lần trước về việc thông tin lấy được từ DNS, anh biết một host anh đang thăm dò thuộc network 172.16.114.0. Tất nhiên chuỗi IP này là private IP dùng để làm ví dụ thôi nha. Bọn em thừa biết mà phải không? Giả sử anh quyết định thăm dò kỹ lưỡng host white từ thông tin lấy được xuyên qua DNS lần trước. Anh muốn xem từ máy của anh (hoặc một terminal nào đó anh đang làm việc) đến host white.domain.com qua bao nhiêu hops, nó có thể có firewall bảo vệ hay không? thì anh dùng thử traceroute (tracert trên windows): 

Code:

$ traceroute white.domain.com
traceroute to white.domain.com (172.16.114.161), 30 hops max, 38 byte packets
1 redback (192.168.1.100) 0.538 ms 0.408 ms 0.355 ms 2
2 cobweb (192.168.2.1) 13.528 ms 11.439 ms 10.712 ms
3 reptile (172.16.100.1) 
3 border.domain.com(172.16.114.10) 16.052 ms 14.238 ms 13.118 ms
4 * * *
5 * * *
.....
.....
$

Kết quả trên cho thấy gì nhỉ?" 

'ccxx' trả lời ngay: 
"Em thì bó tay rồi đó anh. Em chẳng biết gì về mấy cái network hết á." 

'cuti' nối tiếp: 
"Hình như anh chạy lệnh traceroute để tìm xem có bao nhiêu hops đến host white.domain.com, còn những kết quả thì em không rõ lắm. Hình như nó in ra thông tin mỗi khi nó đến một network router phải không anh?" 

Tôi đáp: 
"Đúng rồi. Nếu em đọc kỹ TCP/IP Illustrated của Richard Stevens em sẽ nhận ra ngay những giá trị ở trên." 

'docco' lên tiếng: 
"Em cũng hiểu man mán như thằng Hưng vậy. Điều em không nắm rõ là tại sao nó in ra những dấu hoa thị ở mấy dòng cuối." 

Tôi trả lời: 
"Đây là những kiến thức thông thường về mạng. Nói một cách khác, traceroute là một công cụ thông dụng và là một phương tiện thẩm định network quan trọng. Anh có thể giải thích một cách vắn tắt như sau: 
- dòng đầu tiên: traceroute cho biết là nó dò tuyến đi đến white.domain.com sau khi phân giải tên thành IP 172.16.114.161. Theo mặc định, nó chỉ dò đến 30 hops và dùng gói tin có kích thước là 38 bytes. 

- dòng 1: đây là hop thứ nhất traceroute đi qua. redback là tên của host, nó là một router dùng để định tuyến gói tin từ network 192.168.1.0 sang network 102.168.2.0. Gói tin này mất thời gian tối đa, trung bình và tối thiểu như đã hiển thị. 

- dòng 2: đây là hop thứ nhì traceroute đi qua. cobweb là một router khác định tuyến gói tin từ network 192.168.2.0 đến network 172.16.100.0. 

- dòng 3: đây là hop thứ ba của traceroute. reptile là một router hay một firewall của network 172.16.114.0, network này chứa mục tiêu white.domain.com của mình. 

- dòng thứ 4 trở đi: không có mấy thông tin. Điều này chứng tỏ những hop kế tiếp không động tĩnh gì cả và traceroute hoàn toàn không nắm bắt được thông tin gì cụ thể." 

'cuti' thiếu kiên nhẫn: 
"Em vẫn chưa thấy có gì là bảo mật hay thâm nhập ở đây cả vậy anh? Mấy cái này chỉ là kiến thức cần thiết cho một network admin thôi mà? Với lại nữa, tại sao mình cần biết có bao nhiêu hops đến mục tiêu làm chi vậy anh?" 

'ccxx' lên tiếng: 
"Cái ông này lại láu táu nữa rồi. Anh D đưa ra những chi tiết này chắc chắn sẽ dẫn đến một điểm nào đó cần nắm. Sao ông hông thử kiên nhẫn thêm một tí nữa coi sao?" 

Tôi đỡ lời: 
"Hì hì, anh vẫn biết 'cuti' vẫn còn ám với những thứ gọi là 'thâm nhập' bằng một công cụ mầu nhiệm nào đó. Để anh cắt nghĩa tiếp cho nó đỡ bồn chồn." Tôi nói tiếp: 
"Mình cần biết số hops có nhiều lý do cần thiết sau này, tùy theo ý định thâm nhập nữa. Ví dụ từ máy mình đến mục tiêu phải đi xuyên qua nhiều hops quá thì các kỹ thuật rà tìm sau này phải điều chỉnh lại cho thích hợp để đỡ mất thời gian hoặc để có kết quả chính xác hơn (vì có thể có những trường hợp gói tin bị mất). Sở dĩ những thông tin thâu thập được rất quan trọng bởi vì chúng giúp em xác định tổng quát mức bảo mật của mục tiêu em thăm dò. Trong trường hợp mình đang bàn ở đây, nó tiết lộ một chi tiết rất quan trọng là ở hop thứ 3, border.domain.com có thể hủy các gói UDP đi vào nhưng không hủy các gói ICMP đi ra để trả lời. Chứng tỏ border.domain.com là một router rất chặt chẽ hoặc nó phải là một firewall có những ấn định cụ thể. Tại sao mình biết nó hủy các gói UDP đi vào nhưng không hủy các gói ICMP đi ra để trả lời?" 

'ccxx' thốt lên: 
"Em thua." 

'cuti' nối tiếp: 
"Em chẳng khá gì hơn." 

'docco' chậm rãi đáp: 
"Hình như cái này có liên quan đến cơ chế làm việc của traceroute phải không anh? Tường tận vấn đề thì em đầu hàng rồi đó." 

Tôi đáp: 
"Cu Duy đoán đúng rồi đó. traceroute gởi gói tin UDP đến mục tiêu và tự động chọn cổng UDP nó gởi đến. Chuỗi cổng này thường nằm trên dãy 30000. Nếu mục tiêu của mình (white.domain.com) hoàn toàn không có gì bảo vệ (như một máy bình thường), chắc chắn traceroute có thể liên hệ với nó qua các cổng trên dãy 30000 trở lên. Nếu chính white.domain.com có cơ chế cản UDP hoặc host nào nằm bên ngoài (bảo vệ cho nó) cản UDP giúp nó thì em thấy ngay mục tiêu em đang thăm dò không dễ dàng tí nào." 

'cuti' phát biểu: 
"Vậy thì cũng chưa có gì cụ thể cho việc thâm nhập cả." 

Tôi hơi cáu khi 'cuti' cứ nhấm nhẳn chuyện thâm nhập trong khi đang bàn ở bước thăm dò. Tôi trả lời: 
"Hưng à, hình như em quên là mình đang nói chuyện thăm dò hay sao đó. Sao em cứ đeo mãi cái chuyện thâm nhập vậy? Em chưa biết mục tiêu của em thế nào thì em thâm nhập cái con khỉ gì? Điều anh muốn phân tích ở đây là muốn cho em thấy những kỹ năng và kiến thức cần thiết để ước lượng tình thế. Từ đó, tránh việc phí thời gian để cố thâm nhập vào một mục tiêu quá vững hoặc nghiêm trọng hơn nữa là tránh bị 'tóm' nếu mò mẫm không có căn. Giả sử anh muốn thâm nhập một mục tiêu và ước lượng được tình thế khó khăn hoặc nguy hiểm (vì dễ bị phát hiện), anh sẽ không phí thời gian hoặc liều lĩnh làm chuyện này. Cái khổ là anh phải thẩm định và thăm dò trước khi đi đến chỗ quyết định nên thâm nhập hay không nên thâm nhập. Không phải mục tiêu nào cũng có thể thâm nhập và em nên gột rửa khỏi cái đầu em chuyện này: không có một thứ công cụ mầu nhiệm nào giúp em thâm nhập một hệ thống và cũng chẳng có công thức cụ thể nào cho việc thâm nhập cả. Thâm nhập được hay không là tùy thuộc ở mức phòng thủ của mục tiêu và kiến thức, khả năng sáng tạo của em cho từng trường hợp." 

Thấy tôi có vẻ cáu, 'ccxx' đỡ lời: 
"Thôi anh, anh đừng cáu làm gì. Em thấy mấy bữa nay ông Hưng làm sao đó. Hay mình nói chuyện khác cho vui rồi quay lại chuyện này sau?" 

Tôi đáp: 
"Không sao đâu em. Anh hơi cáu thật bởi vì anh không hiểu sao dạo này cu Hưng lại có vẻ rất thiếu kiên nhẫn. Những điều mình bàn ở đây là phương pháp khai triển vấn đề chớ không phải lối "đút từng muỗng" cho từng lệnh một. Anh muốn mấy đứa hiểu một điều tối quan trọng là bảo mật, thâm nhập hay bất cứ thứ gì khác cũng cần phải có kiên nhẫn, căn cơ, ngọn ngành. Anh nghĩ rằng anh lặp đi, lặp lại điểm này rất nhiều lần nhưng hình như khái niệm này... khó tiêu hay sao đó . Ngay cả chuyện đơn giản như chuyện nấu cơm chẳng hạn. Nếu em muốn nấu cho nhanh và cố nổi lửa lên cho lớn để mong cơm mau chín thì chỉ tổ làm cho cơm khê khét ở dưới nhưng lại sống nhăn ở trên thôi. Em làm toán, cộng trừ nhân chia chưa vững thì làm sao đụng đến căn số, lũy thừa và những thứ cao cấp hơn? Còn chuyện cụ thể mình đang bàn ở đây là chuyện thăm dò. Chưa thăm dò xong thì biết gì mà thâm nhập? Chỉ có mấy ông nhóc script kiddie mới chơi trò lôi ở đâu ra một cái tool rồi nhắm mắt, nhắm mũi mà phang đại thôi. Cái này y hệt như chuyện 'ping of death' đến Linux server mà anh đã kể thôi." 

'docco' lên tiếng: 
"È... èm... em thấy anh cáu là đúng nhưng anh thông cảm cho thằng Hưng và bọn em nha anh? Dù sao bọn em cũng còn trẻ, cũng còn bồng bột. Đâu có điềm đạm và kiên nhẫn như anh được. Riêng em thì em thấy mỗi điểm anh nói đều mở ra những điều mới mẻ mà em cần phải tham khảo, nghiên cứu và học hỏi. Không phải khái niệm "căn cơ, ngọn ngành" khó tiêu đâu anh mà là vì, đôi khi bọn em hơi thiếu kiên nhẫn tí thôi." 

Tôi đáp lời: 
"Hì hì, anh có cáu thì chỉ thoáng qua vậy thôi. Anh có 'care' thì mới cáu. Anh không 'care' thì không cáu." 

Không khí trong phòng 'conference' trở nên ngột ngạt. Mọi người im lặng như thể chẳng ai còn chuyện gì để nói. Sau hồi lâu, tôi định lên tiếng thì đột nhiên 'cuti' phát biểu gọn lỏn: 
"Đúng là 'anh già khó tính'." 

Tôi không kềm được, phá lên cười: 
"Hì hì hì." 

rồi cả ba đứa 'cuti', 'ccxx' và 'docco' cũng cười rộ: 
"Hi hi hi" 
"Ha ha ha" 
"Khẹc khẹc khẹc... tếu thật." 

Không khí trở lại bình thường một cách nhanh chóng. Tôi lên tiếng: 
"Bây giờ anh đề nghị mấy đứa làm một bài tập để lần sau mình nói chuyện dễ dàng hơn." 

'ccxx' thốt lên: 
"Bài tập?" 

'cuti' nối tiếp: 
"Bài tập gì đó anh?" 

'docco' vẫn chậm rãi như mọi khi và hỏi sau cùng: 
"Bài tập cho chuyện gì vậy anh?" 

Tôi đáp: 
"Nói là bài tập thì cũng không đúng. Thật ra nó chỉ là một vài điểm nhỏ cần tham khảo thôi. Anh muốn mấy đứa, nếu rảnh, nên tìm hiểu xem traceroute (trên UNIX) và tracert (trên Windows) làm việc ra sao. Chúng gởi cái gì đi và nhận cái gì về trong các trường hợp thông thường. Biên độ tìm hiểu sâu / rộng thế nào là tùy bọn em. Nếu siêng hơn nữa thì tìm hiểu (hoặc xem lại) thật kỹ cơ chế '3-way handshaking' của tcp. Đặc biệt chú tâm đến những đặc điểm: khi nào thì gói tcp dùng syn flag, khi nào dùng ack, khi nào dùng ack-psh, khi nào dùng fin, khi nào dùng rst... Nắm những cái này thì lần tới mình 'đà khía' sẽ thông suốt hơn."

Lần này 'docco' lên tiếng trước: 
"Ái chà, anh có vẻ cụ thể hơn những lần trước rồi đây. Chắc là chuyện này có gì quan trọng nên anh yêu cầu bọn em tham khảo?" 

Tôi đáp: 
"Quan trọng thì kiến thức nào cũng quan trọng hết cả nhưng cụ thể trong nội dung mình đang bàn, anh muốn bọn em thấu đáo hơn bằng cách tham khảo thêm. Có vậy thì mới vui chớ?  ). 

'cuti' nói: 
"Dạ, chuyện này dễ thôi mà. Để em lục trong kho e-book của em thế nào cũng có cả đống thông tin cho mà xem." 

'ccxx' giận dỗi: 
"Kìa, kìa, có cả 'kho' e-book mà dấu người ta phải hông? Sao hồi giờ giữ khư khư cái 'kho' đó vậy? " 

'cuti' biết ngay là cô bé Như đang dỗi, bèn cuốn quýt lên tiếng: 
"Ùm.. è... anh đây có giấu Như hồi nào đâu à. Tại vì mỗi lần nói đến chuyện máy tính là Như gạt ngang đó thôi. Trời, cái gì anh còn 'dâng' hết cho Như được huống hồ chi mấy quyển e-book quèn đó? " 

'docco' xen vào trêu: 
"Thôi thôi, hai ông bà muốn ca cải lương thì vô phòng kín mà ca dùm. Tui nghe "anh, anh, Như, Như" tự nhiên cứ nổi gai liên hồi đây." 

Tôi cười, chêm thêm: 
"Ừa, bây giờ anh cũng phải dọt luôn. Anh em mình chuồn đi Duy, để hai đứa nó cứ tha hồ mà "anh, anh, Như, Như" cho tiện. Khi nào rảnh mấy anh em mình lại đà khía hả? Chào mấy đứa." 

Tôi logoff, thầm nghĩ "hèm... không biết mấy trự có chịu chuẩn bị gì cho lần tới không đây?" 

17/10/2005 

14. Banner, thật hay giả?: 
Một tuần lễ trôi qua. Tôi nhận được vài e-mail của bộ tứ cuti, ccxx, docco và haothu với nội dung phần lớn là những thắc mắc về lý do tại sao việc xác định "footprint" của mục tiêu lại quan trọng đến như vậy. Tôi quá bận rộn nên chỉ hồi đáp một cách tổng quát và hẹn lần 'đà khía' kế tiếp sẽ trả lời chi tiết hơn. Tôi cũng không quên nhắc mấy 'trự' nên xem kỹ cơ chế truyền tải thông tin của giao thức TCP vì nó sẽ dẫn đến một bước sâu hơn trong việc tìm "footprint" của mục tiêu. Bộ tứ đề nghị hoãn lại cuộc 'đà khía' thêm một tuần để đủ thời gian chuẩn bị và tất nhiên là tôi đồng ý. 

Thêm một tuần lễ trôi qua. Tôi nhận được một offline message của 'cuti' hẹn cuối tuần gặp nhau trên YIM. Tôi đồng ý. 

Chiều thứ bảy, lúc 2 giờ trưa tôi vào YIM thì bộ tứ đã có mặt đầy đủ. Trong chốc lát tôi nhận được lời mời tham gia "conference". 

'cuti nhanh nhảu: 
"Chào anh, anh khoẻ hông? Bọn em lên đây cả tiếng đồng hồ rồi. Đang nói chuyện tầm phào cho vui trong khi chờ anh đó." 

Tôi chào bộ tứ: 
"Chào mấy đứa. Khoẻ hết chớ? Sao lên sớm vậy? Khoa có chuyện gì mà vắng mặt lâu vậy em?" 

'haothu' đáp: 
"Dạ em kẹt một số chuyện gia đình nhưng mọi chuyện xong hết rồi. Bây giờ em sẽ tham gia 'đà khía' đều đặn hơn. Em cũng lấy nội dung mấy lần trước để xem hết rồi anh." 

'ccxx' đi ngay vào vấn đề: 
"Em có gởi mail hỏi anh lý do tại sao việc xác định 'footprint' lại quan trọng như vậy và anh hứa là anh sẽ giải thích chi tiết. Vậy bây giờ anh tiện giải thích không anh?" 

'docco' chêm vào: 
"Ui, không ngờ bà Như lanh thiệt. Tui chưa kịp hỏi bà đã hỏi rồi. Anh D ơi, em đọc kỹ lại mấy bài anh em mình 'đà khía' thì thấy việc dò tìm và xác định 'footprint' của mục tiêu rất quan trọng. Như anh đã đề cập trước đây muốn khai thác một mục tiêu thì phải nắm rõ mục tiêu. Tuy nhiên, em vẫn chưa hoàn toàn nắm được vấn đề một cách xác thực. Anh nói rõ hơn được không anh?" 

Tôi đáp: 
"Ừa, việc xác định 'footprint' quan trọng và mất thời gian bởi vì nó quyết định cho sự thành công hay thất bại của việc thâm nhập. Nói trên bình diện bảo mật, che dấu hoặc thay đổi 'footprint' sẽ phần nào đánh lạc hướng hoặc làm chậm kẻ muốn tấn công. Những hệ thống, những máy chủ không có gì bảo vệ thì chẳng có gì đáng nói; chỉ cần một vài thao tác là em đã có thể xác định 'footprint' của nó cho nên việc xác định 'footprint' không còn đáng kể nữa. Tuy nhiên, có những trường hợp admin của hệ thống nào đó cố tình thay đổi 'footprint' của hệ thống để đánh lừa kẻ muốn tấn công thì sự thể hoàn toàn khác." 

'haothu' hỏi tiếp: 
"Cụ thể như thế nào anh? Em thấy khó hình dung quá " 

Tôi trả lời: 
"Ừa, quả thật là hơi khó hình dung nếu em chưa 'kinh qua' những chuyện này. Hãy thử 'đào xới' một tí xem sao? Anh nhớ đã có lần anh đề cập đến chuyện 'các trình độ thâm nhập' rồi phải không?" 

'cuti' đáp: 
"Dạ, có phải ý anh là chuyện 'dân hacker thứ thiệt' tự thử nghiệm và tìm lỗi để thâm nhập, 'dân hacker bán chuyên' thì dựa vào lỗi đã được công bố trên bug-track và dân 'kiddie' thì chỉ dùng công cụ có sẵn' không vậy?" 

Tôi đáp: 
"Ừa, đúng vậy. Hãy thử nghĩ xem, trường hợp 'dân hacker thứ thiệt tự thử nghiệm và tìm lỗi', chuyện 'footprint' dính líu gì ở đây?" 

'ccxx' đáp: 
"Em nghĩ chuyện 'footprint' chẳng còn quan trọng với trường hợp 'hacker thứ thiệt' nữa." 

Tôi hỏi tiếp: 
"Em giải thích thêm một tí được không?" 

'ccxx' đáp: 
"Em thấy quá hiển nhiên mà anh? Nếu như 'hacker thứ thiệt' tự nghiên cứu và tìm lỗi thì hẳn nhiên anh ta phải làm việc cụ thể trên một hệ điều hành, trên một môi trường nào đó. Em hình dung là anh ta phải lập một máy chủ có hệ điều hành cụ thể, có phiên bản chương trình cụ thể rồi mới thử nghiệm và tìm lỗi. Cho nên, 'footprint' nằm trong tay anh ta là chuyện hiển nhiên." 

Tôi cười, đáp: 
"Rồi, cuti, haothu, docco nghĩ sao với nhận định này của 'ccxx'?" 

Cả ba im lặng hồi lâu. Sau cùng, 'haothu' lên tiếng: 
"Em nghĩ 'ccxx' nói đúng lắm nhưng nó chỉ giới hạn trong trường hợp tay 'hacker thứ thiệt' đó tìm lỗi trên chính máy chủ do mình thiết lập. Còn trường hợp tìm lỗi trên một server nào đó thì sao? Tay 'hacker thứ thiệt' ấy vẫn phải xác định 'footprint' như thường. Không biết em nói có đúng không?" 

'docco' lên tiếng: 
"Ý em cũng giống như ý thằng Khoa đó anh." 

'cuti' góp phần: 
"Đúng rồi. Tự thiết lập một máy chủ, cài soft rồi tìm lỗi cụ thể thì chuyện 'footprint' là chuyện không cần thiết vì mình đã thiết lập mọi thứ theo ý. Trường hợp các tay 'hacker thứ thiệt' thử dò tìm lỗi trên các máy chủ không phải do họ làm chủ có xảy ra không anh?" 

Lúc này tôi mới lên tiếng: 
"Anh tin rằng nhận định của 'ccxx' rất hữu lý. Hầu hết các trường hợp thử nghiệm và tìm lỗi xảy ra trên chính server mà tay 'hacker thứ thiệt' ấy thiết lập. Cho nên, chuyện xác định 'footprint' ở đây không còn là một việc cần thiết nữa. Riêng trường hợp thử nghiệm trên server không phải do mình thiết lập thì anh không thể xác định được vì chẳng có số liệu nào cho chuyện này. Tuy nhiên, anh hình dung rằng trường hợp 'thử trên server mình không làm chủ' vẫn có thể xảy ra nhưng khá ít. Lý do là thử nghiệm và tìm lỗi như thế khá mơ hồ và kém hiệu xuất. Hơn nữa, để thử nghiệm và tìm lỗi một cách đúng mức, em cần phải sử dụng hàng loạt công cụ như debugging, tracing... em phải lặp đi, lặp lại một test case với nhiều biến số khác nhau để tìm kết quả. Những thao tác này nằm trong khuôn khổ 'local', có nghĩa là em phải có quyền sử dụng và thực thi các công cụ ngay trên máy chủ để tìm lỗi." 

Tôi dừng lại vài giây và hỏi tiếp: 
"Vậy, trường hợp các 'hacker bán chuyên' dựa vào bug-track để thâm nhập thì dính líu gì đến chuyện 'footprint'?" 

Lần này 'cuti' nhanh nhảu trả lời: 
"Em nghĩ nó 'dính líu' nhiều lắm chứ. Em thấy trên bug-track ghi rõ lỗi trên hệ điều hành nào, cho phiên bản của software nào. Điều này chứng tỏ, nếu tìm cách áp dụng nó để exploit trên một hệ điều hành khác, trên phiên bản software khác thì cơ hội thành công hầu như không có. Bởi vậy, dân 'bán chuyên' phải đi qua chặng đường xác định xem mục tiêu của mình có rơi vào 'phạm vi' con bug đã được công bố hay không thì mới có kết quả khả quan." 

Tôi đáp: 
"Hay lắm. Mấy đứa còn ý kiến nào khác không?" 

'docco' lên tiếng: 
"Em nghĩ Hưng nói đúng quá rồi. Chỉ có điều 'dân bán chuyên' xác định 'footprint' ra sao đây?" 

Tôi cười, đáp: 
"Đó. Bây giờ em đã nhận ra tầm quan trọng của việc xác định 'footprint' chưa? Chuyện 'dân bán chuyên' xác định 'footprint' ra sao thì mình sẽ bàn đến." 

'haothu' trả lời: 
"Chuyện này thì quá rõ rồi. Nếu không xác định được 'footprint' thì chỉ có nước làm... mò mà thôi." 

Tôi đẩy thêm: 
"Rồi, mình đã xác định được hai trường hợp. Nếu vậy thì trường hợp các 'kiddie' tìm đâu ra vài món đồ nghề thì dính líu gì đến 'footprint' nhỉ?" 

'ccxx' cười xoà: 
"Hi hi hi, em nghĩ là anh đang hỏi mẹo cái gì đây rồi. Nếu dựa trên khái niệm thế nào là 'kiddie' mà anh đưa ra trước đây thì mấy tay này có sá gì 'footprint' hay không đâu anh? Vả lại, liệu họ có kiên nhẫn hoặc kiến thức để tìm 'footprint' hoặc quý trọng kết quả mình tìm được ở mức độ thăm dò hay không?" 

'docco' phản đối: 
"Tui không đồng ý với bà Như điểm này. Hiện nay có quá nhiều công cụ từ thương mại đến mã nguồn mở và những công cụ này rất mạnh, rất dễ dùng và cũng rất nguy hiểm. Nếu 'kiddie' chịu khó một tí thì chuyện gì cũng có thể được cả." 

'ccxx' phản đòn: 
"Vậy ý ông 'kiddie' đủ khả năng và kinh nghiệm xác định 'footprint' bằng cách dùng công cụ nào đó một cách dễ dàng? Tui không tin như vậy. Cho dù có dùng tool nào đó, dù dễ đến đâu, ông cũng cần có ít nhiều kiến thức trong lãnh vực này trước khi có thể dùng nó một cách hiệu quả. Liệu 'kiddie' có chịu khó đọc hướng dẫn một cách cẩn thận trước khi dùng không? và liệu sau khi lấy được thông tin nào đó, họ có đủ sức đối chiếu với thông tin được công bố hay tìm cách xác định lại thông tin tìm được xem chúng có đáng tin cậy hay không?" 

'haothu' xen vào: 
"Hì hì, bà Như đánh giá 'kiddie' thấp quá vậy? Bản thân tui thì quả thật tui thấy hơi oải khi phải dùng một công cụ chạy trên dòng lệnh và phải đọc hướng dẫn sử dụng. Loại công cụ này thường có hướng dẫn quá ngắn gọn, đọc xong phải vận dụng, suy nghĩ thì mới dùng được. Tuy vậy, nếu tui mà 'kết' một cái gì thì tui sẵn sàng bỏ công ra để lãnh hội nó thôi." 

'cuti' góp chuyện: 
"Em cũng thấy Khoa nói đúng đó. Bản thân em cũng bị dính vào cảm giác này." 

Tôi hướng câu chuyện về trọng điểm: 
"OK, cứ cho là có 'kiddie' có thể dùng các công cụ để xác định 'footprint' một cách không khó khăn, vậy, mình có thể thấy được tầm quan trọng của việc xác định 'footprint' rồi chứ? 'haothu', em thấy sao?" 

'haothu' lững lờ: 
"Dạ, trên mặt nguyên tắc thì sự thể rõ ràng hơn rồi nhưng cái này chắc phải bắt tay vào làm thì mới đánh giá đúng mức được tầm quan trọng của việc tìm 'footprint' thôi." 

Tôi cười, cố gút vấn đề lại: 
"OK, em thử hình dung xem, có bao nhiêu phần trăm 'hacker chuyên', bao nhiêu phần trăm 'hacker bán chuyên' và bao nhiêu phần trăm là 'kiddie'?" 

'haothu' trả lời: 
"Số lượng chính xác thì em không có rồi đó nhưng em nghĩ rằng số 'kiddie' chắc là chiếm đa số, sau đó là đến nhóm 'hacker bán chuyên'. Nhóm 'hacker chuyên' thì có lẽ chỉ chiếm thiểu số mà thôi." 

Tôi hỏi tiếp: 
"Vậy, em thử hình dung có bao nhiêu phần trăm 'kiddie' sẽ tìm tòi 'footprint' khi vớ phải một công cụ dùng để tấn công nào đó? Có bao nhiêu phần trăm dân 'bán chuyên' phải mó tới chuyện 'footprint'? Và nếu họ (cả 'kiddie' lẫn 'dân bán chuyên') không mó đến chuyện 'footprint' thì tỉ lệ thành công sẽ nằm ở mức nào?" 

Không đợi 'haothu' trả lời, 'docco' chen vào: 
"Theo em thì tỉ lệ thành công gần như không có. Nếu cứ nhắm mắt mà phang đại thì chẳng khác gì chó ngáp nhằm ruồi cả." 

Tôi đúc kết điểm thắc mắc của 'haothu': 
"Vậy thì xét trên căn bản, việc tìm 'footprint' là việc rất cần thiết cho quá trình thậm nhập chớ gì? Đồng ý với nhau điểm này rồi chứ?" 

'ccxx' đáp ngay: 
"Em thì thấy điều này sáng tỏ như con thỏ vậy. Chỉ có điều em còn hơi ấm ức là vì em muốn 'đào xới' thêm cho ông Khoa thấy là muốn dùng công cụ nào đó đúng mức thì mình phải có kiến thức căn bản cho vấn đề này." 

'cuti' tiếp theo: 
"Em cũng vậy." 

'docco' cũng cho cảm nghĩ và đưa ra vấn đề kế tiếp: 
"Chắc chắn là việc tìm 'footprint' là việc cần thiết rồi. Bây giờ em muốn hỏi anh là tìm 'footprint' bao gồm những điểm chính nào. Anh cũng hiểu là em chưa dám đặt bọn em ở vị trí là 'dân chuyên', cũng chẳng muốn đặt bọn em ở vị trí là 'kiddie' nên có lẽ bọn em cần hiểu nguyên tắc tìm 'footprint' nhưng đám 'bán chuyên' vậy " 

Tôi trả lời, không quên ghẹo 'cuti': 
"OK 'ccxx', anh nghĩ em sẽ có dịp thực hiện ý định thôi. Chắc chắn mình sẽ đụng đến chuyện này. Còn 'cuti', em cũng vậy có nghĩa là 'bà tiền hô, ông hậu ủng' hả? ." 

Tôi tiếp tục: 
"Anh nhớ hồi nãy em có nhận xét là dân 'bán chuyên' thường dựa vào bug-track và trên bug-track thường có ghi rõ hệ điều hành, phiên bản của nó và phiên bản software của dịch vụ. Nếu vậy, theo em nghĩ, xác định 'footprint' là xác định những cái gì một cách cụ thể?" 

'docco' liền đáp lời: 
"Oài... quá hiển nhiên mà anh? Tất nhiên là mình xác định ba điều chính: 
- mục tiêu chạy trên hệ điều hành nào 
- phiên bản của hệ điều hành đó 
- software tạo dịch vụ là software gì, có phiên bản nào 
phải không anh?" 

Tôi cười, đáp: 
"Đúng rồi. Nhưng... em nên tự tin hơn. Cố gắng đừng kèm thêm đoạn 'phải không anh' làm chi . Nếu 'không phải' hoặc chưa đầy đủ thì anh sẽ ý kiến liền. Đừng lo. 

Rồi, vậy thì mình khai triển ba điều 'docco' đưa ra vậy. Câu hỏi thứ nhất được đặt ra: làm sao xác định được mục tiêu chạy trên hệ điều hành nào?" 

'bộ tứ' im lặng, trầm ngâm hồi lâu. Sau đó 'cuti' lên tiếng: 
"Em nhớ là em đã có đọc qua vài đoạn về chuyện này nhưng lúc đó em không cho là quan trọng nên không ghi nhận nó. Hình như là 'banner' cái gì gì đó." 

'docco' chêm vào: 
"À, đúng rồi, 'banner grabbing'. Đây là một cách lấy thông tin mình cần về hệ điều hành và phiên bản của mục tiêu phải không anh?" 

Tôi đáp: 
"Đúng rồi, đây là một cách dễ nhất, thông dụng nhất và có thể có kết quả cực kỳ chính xác hoặc cực kỳ sai lạc." 

'ccxx' ngạc nhiên: 
"Sao kỳ vậy anh? làm sao mà vừa có thể chính xác và sai lạc?" 

Tôi cắt nghĩa: 
"Thông thường banner grabbing như thế này, giả sử mục tiêu có dịch vụ telnet đang lắng nghe, em thử: 
Code:

$ telnet myhost.mydomain.com
Red Hat Linux release 9 (Shrike) myhost.mydomain.com
myhost login:

cho mình thấy ngay mục tiêu đang chạy trên RedHat và phiên bản là 9.0. Thông tin này có thể hoàn toàn chính xác nếu như admin của server này hoàn toàn không thay đổi, che dấu footprint của hệ thống. Nếu vậy thì thông tin cần biết đã có một cách dễ dàng. Tuy nhiên, làm sao xác định được thông tin này xác thực? Nếu mục tiêu không mở dịch vụ telnet thì có thể làm gì khác để xác định thông tin này?" 

'haothu' không trực tiếp trả lời câu hỏi của tôi mà lại hỏi tiếp một câu khác: 
"Ủa, sao anh không cho thông số giá trị cổng dịch vụ ở trên vậy? Em thấy thường thường lệnh telnet đi theo thông số địa chỉ và cổng mà?" 

Tôi đáp: 
"À, nhiều người bối rối chi tiết rất nhỏ này. Khi em dùng lệnh telnet và chỉ có thông số thứ nhất là địa chỉ nhưng không kèm theo thông số thứ hai là cổng thì telnet dùng cổng (đích) mặc định là 23 (cổng telnet). Nói một cách khác, nếu em không cung cấp giá trị cổng thì telnet client (chương trình telnet em dùng trên command prompt là telnet client) sẽ tự động truy cập đến địa chỉ đã cho ở cổng 23. Nếu em cung cấp địa chỉ và cổng thì telnet client sẽ truy cập đến địa chỉ ấy ở cổng được ấn định. Ví dụ, em gõ 
Code:

$ telnet www.mysite.com 80

thì telnet client sẽ truy cập đến địa chỉ là www.mysite.com ở cổng 80. Rõ rồi chứ?" 

'haothu' ậm ừ: 
"Dạ... nhưng... ùm... mỗi lần em dùng telnet trên windows để telnet đến cổng nào đó, sau em chẳng thấy có chữ gì hết, chỉ có cái command prompt đen ngòm vậy anh? Hay em làm gì sai?" 

Tôi đáp, hơi thiếu kiên nhẫn: 
"À, mấy cái này là do telnet trên Windows không có 'echo' đó thôi. Nếu em gõ Run/cmd rồi trên dos-prompt này em mới gõ telnet thì Windows sẽ dùng telnet client bên trong command window (DOS-console) và em không set 'echo' được cho nên nó... đen ngòm. Nếu em thử gõ Run/C:\Winnt\system32\telnet.exe thì Windows sẽ tạo một process riêng biệt cho telnet client và nó ở trong tình trạng tạm gọi là "full mode", lúc ấy em có thể set 'echo' được. Trong chế độ này, em có thể set biến LOCAL_ECHO và nó sẽ hiện ra chữ mỗi khi em gõ thôi. Mấy cái này có trong phần "help" của Windows cả. Em chịu khó tìm hiểu chi tiết chớ mình mà đào sâu mấy thứ này thì đi xa trọng tâm đó em." 

'haothu' trả lời: 
"Dạ. Chắc do em chưa mày mò đúng mức thôi." 

'cuti' chen vào: 
"Mấy cái này đúng nghĩa là 'hiểu rõ', 'hiểu ngọn ngành' đây. Ui... biết chừng nào mới 'ngọn ngành' mọi thứ đây trời?" 

Tôi tiếp tục: 
"Thằng này cứ than với thở. Từ từ thì sẽ ngọn ngành thôi em. Em phải đụng đến nó, phải chịu khó thì mới nắm được nhiều. Thôi mình tiếp tục chuyện hồi nãy đi hả?" 

'docco' hỏi ngay: 
"Vậy nếu mục tiêu ấy không có dịch vụ telnet thì mình telnet vào một dịch vụ khác phải không anh?" 

Tôi cười, đáp: 
"Đúng rồi. Nhưng lý do tại sao mình telnet vào một dịch vụ khác?" 

'docco' trả lời: 
"Hình như dịch vụ nào cũng có cái 'banner' hết phải không anh? Nếu vậy, khi mình telnet vào dịch vụ, có nghĩa là mình muốn kết nối với dịch vụ ấy thì nó thường 'chào' mình bằng một biểu ngữ?" 

Tôi đáp: 
"Đúng lắm. Hình như em có ngâm cứu qua mấy cái này rồi phải không Duy?" 

'docco' đáp: 
"Hì hì, đúng là không qua mặt anh nổi. Đúng là em có 'ngâm' qua vài thông tin về chuyện 'footprint' đó anh vì lần trước mình có bàn qua về chuyện này. Em nghĩ chắc nó phải quan trọng nên anh mới khai triển nó, cho nên em đọc thêm để nắm thêm thông tin." 

Rất hài lòng với sự chuyên tâm của docco, tôi đáp: 
"Hay lắm. Nếu em chuyên tâm như vậy thì em sẽ nắm được chìa khoá của vấn đề một cách nhanh chóng đó Duy " 

'docco' lúng túng: 
"Dạ... ùm... à.... em chỉ cố quan sát và rút kinh nghiệm từ những lần mấy anh em mình 'đà khía' thôi anh. Em rút ra một điều là anh luôn luôn có dụng ý gì đó khi đưa ra một vấn đề cho nên lần này em lo 'rào' trước, hì hì." 

'cuti' xen vào: 
"Em cũng ráng 'rào' nhưng hình nhưng em chưa vững tâm bằng thằng Duy. Em vẫn chưa có thể xác định là tự nên làm cái gì tiếp." 

'haothu' trêu 'cuti': 
"Tao thấy mày nên lấy vợ là chuyện tiếp theo mày nên làm... tiếp " 

Tôi thầm nghĩ, mấy ông tướng này làm sao tránh khỏi chit chat. Vậy cũng vui nhưng phải 'điều tác' một tí không thì sa đà, mất thời gian. Tôi bèn lên tiếng: 
"Ừa, nó mà lấy vợ thì chắc khỏi thấy mặt nó luôn. Thôi, mình 'khoá' cái vấn đề đang lở dỡ kia rồi anh phải dọt á." 

'ccxx' lên tiếng: 
"Dạ... cám ơn anh cứu bồ, chớ hông thì mấy ổng chọc đến mai cũng không chịu ngưng đâu . Em muốn hỏi anh là nếu mấy ông admin biết trước chuyện những tay thâm nhập cố tìm thông tin từ banner để tìm cách tấn công, họ tháo hết mấy cái banner đi thì lấy đâu mà thăm dò hả anh? Em thì không rõ họ tháo mấy cái banner bằng cách nào nhưng em hình dung là nếu gắn lên được thì phải tháo xuống được." 

Tôi cười, đáp: 
"Ái chà, con bé nói chuyện phòng thủ hả? Đúng là bản năng tự nhiên của phụ nữ . Em đưa ra một điểm hết sức lý thú. Đúng rồi, ngày nay các admin có quan tâm đến bảo mật đều thực hiện việc 'dấu' banner để giảm thiểu thông tin về máy bị tiết lộ. Có nhiều admin còn cực đoan hơn nữa là họ chẳng những dấu mà còn cố tình thay đổi từ A thành B để đánh lừa những kẻ thăm dò nữa." 

'cuti' xen vào: 
"Nhưng mà khoan, cho em hỏi một chi tiết này một tí anh? Hình như mình chỉ thấy được cái banner của một dịch vụ khi mình cố tình truy cập nó ở mức độ thấp hơn phải không anh? Ví dụ em dùng Outlook Express để gởi và nhận mail thì làm sao mình thấy được mấy cái banner kia?" 

Tôi đáp: 
"Em thắc mắc một điểm rất có lý. Thật ra mail client như Outlook Express 'thấy' hết những cái banner nhưng nó thường 'dấu'. Ngoại trừ em muốn xem cái 'header' của nó. Em thử tìm tòi xem trong mấy cái 'header' của smtp mà mail client nhận được, nó có chút ít 'footprint' không? . Những dịch vụ khác như ftp, khi em dùng ftp client để truy cập ftp server, nếu ftp server này không dấu banner thì em sẽ thấy ngay cái banner trong lúc truy cập. Dịch vụ http thì lại khác, em không thấy mấy cái banner bởi các trình duyệt ứng dụng để 'hiển thị' những thông tin mà người dùng bình thường cần xem mà thôi. Tuy nhiên, nếu em truy cập http service ở dạng 'raw' (như đi qua telnet) thì em có thể thấy rất nhiều thông tin nếu như server này không dấu banner. 

Nên nhớ một điều là không phải banner nào cũng chứa đựng thông tin về hệ điều hành và phiên bản của nó. Thông thường nó chỉ chứa tên software tạo dịch vụ (mình telnet vào) và phiên bản của nó. Tuy vậy mình cũng có thể phần nào đoán được hệ điều hành dựa trên thông tin này." 

'cuti' đáp một cách thoả mãn: 
"À, vậy thì tùy dịch vụ mà tìm banner phải không anh? Nhưng hình như cách dùng telnet là chắc ăn nhất. Nhưng mà em thấy chi tiết 'có thể phần nào đoán được hệ điều hành' có vẻ không được chắc ăn vậy anh?" 

Tôi đáp: 
"Ừa, nếu như banner đó là banner thứ thiệt, không hề bị thay đổi. Còn chuyện chắc ăn thì chẳng có gì mà chắc ăn đâu em. Mỗi người có thể tìm kết quả mỗi khác trong quá trình thăm dò bởi vì có quá nhiều thông tin và tùy vào đương sự mà phân tích, chọn lọc thông tin nào logic nhất, đáng tin cậy nhất. Nên nhớ rằng thăm dò không phải là 'hack' nha em. 'Thăm dò' là 'thăm dò', là một quá trình tìm tòi, phân tích những dữ kiện có thể lấy được dựa vào những công cụ, phương tiện cho phép. 

Quay lại nhận định của 'ccxx' một tí cho trót hả? Em nghĩ thế nào khi em thử telnet vào một server và nó cho em thông tin như sau: 

Code:

$ telnet www.mydomain.com 80
Trying
www.mydomain.com...
Connected to www.mydomain.com.
Escape character
is '^]'.
HEAD /somefile.txt HTTP/1.0

HTTP/1.1 404 Not Found
Date: Thu, 25 Apr 2004 14:29:46 GMT
Server: Microsoft-IIS/5.0
Connection: close
Content-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.

" 

'ccxx' ngẫm nghĩ rồi trả lời: 
"Dạ thông tin ở đây cho thấy server là một con IIS 5.0, em tin chắc đây là một web server chạy trên hệ điều hành Windows 2000." 

Tôi khơi mào: 
"Còn mấy đứa có ý kiến gì khác không vậy?" 

Ba trự kia im lặng khá lâu. Sau đó 'cuti' rụt rè lên tiếng: 
"Èm... à.... em nghĩ có cái gì tàng ẩn ở đây hay sao đó. Em cũng nghĩ cái này là một con IIS 5.0, mà đã là IIS 5.0 thì nó chạy trên Windows 2000. Không biết có cái gì ẩn khuất ở đây không nhỉ?" 

'docco' cũng lên tiếng: 
"Hì hì, thằng Hưng cũng bắt đầu có bịnh hoài nghi rồi. Em cũng nghĩ như Hưng vậy. Tuy nhiên, tự nhiên em cũng hơi hoài nghi vì nếu nó đơn giản và rõ ràng như thế thì anh đưa nó ra làm chi?" 

'haothu' cũng tham gia: 
"Chắc chắn là Windows 2000 rồi. Thông tin rõ mười mươi thế kia mà." 

Tôi không trả lời mà đưa ra thêm một ví dụ khác: 
"Được rồi, để anh đưa ra thêm một ví dụ khác để tụi em tìm xem có gì đặc biệt không hả? Đây: 

Code:

$ telnet www2.mydomain.com 80
Trying
www2.mydomain.com...
Connected to www2.mydomain.com.
Escape character
is '^]'.
HEAD /somefile.txt HTTP/1.0

HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Thu, 25 Apr 2004 14:35:23 GMT
Content-Length: 460
Content-Type: text/html
Connection closed by foreign host.

" 

Bộ bốn hoàn toàn im lặng nhiều phút đồng hồ. Hồi lâu, 'docco' lên tiếng: 
"Em thấy rõ cái thứ nhì khác cái thứ nhất một chút là cái thứ nhì có thêm Content-Length và Content-Type thì hơi khác một chút vì không có đoạn 'charset=iso-8859-1'. Tại sao chúng lại khác nhau ở mấy điểm này? Chắc chắn chúng là 2 server riêng biệt vì một cái là www.mydomain.com, cái kia là www2.mydomain.com. Em chỉ không hiểu được lý do tại sao chúng khác nhau mặc dù cả hai đều là IIS 5.0." 

'ccxx' nhận định: 
"Hay là một trong hai server trên có banner giả? Dám lắm đó. Anh đang khai triển việc thay đổi banner phải không nào? Vậy chắc chuyện này có thể lắm." 

'cuti' và 'haothu' cùng cảm thán: 
"Ái chà." 
"Đúng rồi." 

Tôi cười, thong thả đáp 
"Bé Như nhà mình tinh tế lắm. Rõ ràng là mình đang khai thác chuyện thay đổi banner mà. Quả thật một trong hai server trên giả dạng banner đó. Nếu vậy làm sao mình xác định được cái nào thiệt, cái nào giả?" 

'docco' xuýt xoa: 
"Ái chà, thật là lý thú. Em không ngờ đào xới mấy cái HTTP header ở tầng này lại có những điều lý thú đến như vậy. Làm sao mình xác định được cái nào thiệt, cái nào giả bây giờ anh?" 

Tôi đáp: 
"Hì hì, anh hỏi em, em hỏi lại anh? Cái này để em suy nghĩ trước cái đã. Anh trả lời liền thì mất hay đi. Em tìm cách thử một cái xem nào?" 

'ccxx' thốt lên: 
"A... có rồi, có rồi. Trường mình có một con server chạy Windows 2000 và IIS 5. Cứ thử telnet vào nó và chạy y hệt dòng HEAD như trên ví dụ thì sẽ biết ngay thôi." 

'cuti', 'haothu', 'docco' đồng cảm thán: 
"Đúng rồi." 
"Ờ hớ." 
"Sao mình không nghĩ ra nhỉ? Đúng là đàn bà, con gái tinh tế mấy chuyện này." 

Sau vài phút, 'cuti' lên tiếng trước. Quả thật mấy ông đực rựa nhanh nhảu hơn trong chuyện 'động tay, động chân' nhưng lại chậm hơn mấy cô khoản 'nhận xét tinh tế' 
"Thằng thứ nhì đúng là thằng IIS 5.0" 

Tiếp theo đó là 'docco', 'haothu' và 'ccxx' đồng xác nhận: 
"Đúng rồi, chắc chắn server thứ nhì chạy con IIS 5.0 thứ thiệt." 
"Hết đường thoát." 
"Em đã nói thế." 

và nhiều câu trao đổi khác. 

Cái YIM 'conference' bé nhỏ trở nên rộn rã bằng những câu cảm thán. Tôi hiểu sự rộn rã này không phải tính quan trọng hay mới mẻ của những điều bộ bốn tìm thấy mà ở chỗ chính ở chỗ bộ bốn nhúng tay vào việc quan sát, phân tích, thao tác, so sánh và đúc kết ra được. Tôi lên tiếng: 
"Trong hai ví dụ trên, còn có chi tiết nào khác nhau giữa hai server? Chi tiết này hết sức đặc biệt. Bọn em xem thử?" 

Như tôi dự phỏng, chính 'ccxx' lại tìm ra điểm khác biệt trước tiên trong bộ bốn. 'ccxx' đáp: 
"Em tìm ra rồi. Cái khác nhau là 'HTTP/1.1 404 Not Found' và 'HTTP/1.1 404 Object Not Found' phải không anh? Server thứ nhất chỉ thông báo là 'không tìm thấy' còn con IIS thì lại thêm chữ 'object' vào trong thông điệp." 

'haothu' đáp, vẻ tiếc rẻ: 
"Công nhận bà Như lanh thiệt. Tui cũng vừa tìm ra, chưa kịp nói thì bà đã làm xong rồi." 

Tôi hỏi tiếp: 
"Vậy bọn em nghĩ điểm khác nhau mà Như đưa ra có gì quan trọng?" 

'cuti' láu táu lên tiếng: 
"Em thấy điểm khác biệt này chẳng ích lợi gì cả. Mấy ông Microsoft hay có thói làm cho khác người vậy thôi à." 

'ccxx' nguýt 'cuti': 
"Hứ... cũng là chứng nào tật nấy. Chưa suy nghĩ cho kỹ đã đôm đốp nữa rồi. Trong khuôn khổ 'nhận diện', điểm khác biệt kia hẳn phải có một giá trị nào đó chớ?" 

'cuti' lúng búng với 'ccxx': 
"Èm... thì anh có nói gì đâu à." 

Tôi can gián ngay: 
"Thôi thôi. 'ccxx' nhận định vậy là chính xác. Điểm khác biệt ở đây giúp chúng ta dễ dàng nhận ra đâu là IIS thật, đâu là IIS giả mạo. Trên *nix, apache thường được dùng làm web service nhất. Những ai rành rõi với chuyện biên dịch thường tải mã nguồn của apache về và sửa lại thông tin của banner trong nguồn. Gần đây, những ai dùng apache còn có thêm mod_security cho phép 'giả' banner nữa. Tuy vậy, có dấu banner vẫn không dấu được những đặc điểm khác. Với ví dụ thứ nhất, mình biết ngay đây là banner 'giả mạo'. Chuyện xác định banner thật của nó là gì là chuyện khác nữa nhưng trước mắt mình có thể xác định phần nào đó hệ điều hành đang chạy web server đó không hẳn là Windows 2000. Điều tiếp theo là phải xác định rõ hơn nếu muốn tiếp tục thăm dò." 

'haothu' hỏi: 
"Nếu vậy em thấy chuyện giả mạo banner để dấu danh tánh đâu có ích lợi gì cho lắm đâu anh?" 

Tôi cười, hỏi sang 'docco', 'cuti' và 'ccxx': 
"Bọn em nghĩ sao về nhận định của 'haothu'?" 

'docco' trả lời trước: 
"Em thấy trước tiên nó đánh lừa được mấy ông kiddie. Đây cũng là chuyện ích lợi." 

'cuti' ngần ngừ: 
"Em.... em thì thấy nó có lợi khá nhiều. Ngoài chuyện đánh lừa kiddie, nó có thể đánh lừa được cả đống công cụ dùng để tự động thăm dò hông chừng. Em thấy có khá nhiều công cụ dành riêng cho công tác này, cả thương mại lẫn mã nguồn mở. Ví dụ chương trình tự động kia 'nhìn' thấy dịch vụ là IIS thì nó chỉ dùng các lỗi của IIS có trong database của nó mà... nện. Mà nện thế này thì trật lất hết vì thật sự dịch vụ này đâu phải là IIS. Em thấy đây cũng là một điểm hay." 

'ccxx' phát biểu: 
"Em thấy tùy mức độ kinh nghiệm của kẻ thăm dò. Nếu thăm dò kiểu như anh nói ở đây thì có ma nào mà dấu nổi. Tuy nhiên, em nghĩ là 'cuti' rất có lý với ý kiến dùng nó để lừa các công cụ tự động." 

Tôi đáp: 
"Hay lắm, ráng 'động não' đều đều hả . Quả thật, dùng phương pháp thay đổi banner chỉ có thể đánh lừa những người chưa đủ kinh nghiệm và một số tools tự động hoá chưa đủ tinh vi. Tuy vậy, đánh lừa được nhóm 'thăm dò' ở dạng hoàn toàn phó mặc vào công cụ cũng đã là đáng kể vì nhóm này chiếm đa số. Vậy, trên phương diện phòng thủ, liệu mình có nên ứng dụng phương cách 'giả' banner không?" 

'cuti' đáp: 
"Em nghĩ là nên. Lừa được chút nào hay chút đó chớ anh? " 

'docco' lên tiếng: 
"Em nghĩ cũng nên làm nhưng nếu nó không thật sự tác dụng thì không nên quá tốn công sức với nó." 

Tôi đáp: 
"Đúng rồi. Nếu có thể 'giả' để giảm thiểu những màn thăm dò chung chung thì tại sao không làm? Em nên biết, chỉ có chừng dưới 10% các cú rà tự động được tiếp tục bằng quá trình 'rà' bằng tay để xác định thêm thông tin mục tiêu. Thông thường, quá trình rà tự động chỉ để thu thập một số mục tiêu có thông tin cụ thể mà kẻ thâm nhập muốn tìm. Tuy nhiên, đối với kẻ có quyết tâm thăm dò một mục tiêu cụ thể nào đó thì chuyện 'giả' có lẽ không tác dụng gì mấy. 

Bọn em có nghe đến khái niệm security through obscurity chưa?" 

'docco' đáp: 
"Em có thấy nhắc đến nhiều nơi nhưng em không đào sâu lắm vì không rõ tác dụng của nó. Nó là gì vậy anh?" 

Tôi nói tiếp: 
"Ừa, security through obscurity dịch nôm na ra tiếng Việt là bảo mật bằng tính bất khả định. Hay nói một cách khác, vì mục tiêu không được rõ ràng nên nó có vẻ bảo mật hơn. Có hẳn một trường phái rất chuộng security through obscurity nhưng bản thân anh thì anh không chuộng bởi vì nó thuộc về cái vỏ bên ngoài mà thôi. Đối với những ai thật sự muốn thâm nhập thì cái 'vỏ' này mỏng manh lắm. Nếu có thời gian và điều kiện thì thêm cái vỏ này cũng tốt nhưng nếu chỉ phó mặc vào nó để 'bảo mật' thì rất phiến diện." 

'cuti' thắc mắc: 
"Họ làm sao gọi là 'chuộng' vậy anh?" 

Tôi đáp: 
"À, 'chuộng' ở đây là họ dành nhiều thời gian, công sức để tạo một lớp vỏ 'giả' để đánh lừa kẻ tấn công. Có thể lớp vỏ này làm chậm bước thâm nhập vì kẻ muốn tấn công vì họ mất thời gian xác định thật tính của mục tiêu. Tuy vậy, thiếu bảo mật từ bên trong ra, thiếu bảo mật thật sự thì lớp vỏ này tan vỡ nhanh chóng." 

'cuti' hỏi tiếp: 
"Em nghĩ là chuyện giả một cái banner đâu có mất thời gian đâu anh?" 

Tôi đáp: 
"Ừa, đối với mã nguồn mở thì đây là chuyện không mất thời gian cho lắm. Tuy vậy, ít nhất em phải cần thời gian để biên dịch lại software. Đối với software thương mại thì đây là chuyện hoàn toàn khác. Nó dính đến chuyện bản quyền, chuyện giới hạn thay đổi software nên rất phiền phức. Trên mức độ banner thì thế, nhưng chuyện 'đánh lừa' còn đi sâu xuống tcp/ip stack nữa. Họ 'chuộng' phương pháp này đến độ tìm cách thay đổi tcp/ip stack để dấu những đặc tính của các gói tin đi ra / đi vào từ các cổng dịch vụ bởi vì các gói tin này mang những đặc điểm có thể dùng để xác định 'footprint' nữa. 

Nếu em chỉ quản lý một vài máy chủ thì có lẽ không quá phiền phức nhưng nếu em phải quản lý cả một hệ thống chằng chịt có nhiều máy chủ, nhiều thiết bị thì sự thể rất khác. Ngay cả em chỉ quản lý một vài máy chủ mà không cẩn thận, tỉ mỉ thì cũng vô ích bởi vì em có thể 'dấu' đầu này nhưng để lộ đầu kia thì cũng chẳng phục vụ được ý định 'dấu'." 

'cuti' cảm thán: 
"Chà... chuyện phức tạp vậy sao anh? Hoá ra bảo mật cũng có năm bảy đường. Em thấy chuyện 'giả' này có vẻ thú vị lắm." 

'docco' xen vào: 
"Cho em hỏi một chi tiết nha anh? Anh nói là trên *nix người ta thường thay đổi source của apache hay dùng mod_security để giả banner. Vậy trên Windows và dùng IIS thì có phương cách nào tương tự không anh? Em nghĩ IIS thì không thể điều chỉnh mã nguồn rồi đó." 

Tôi cười, đáp: 
"Chà chà, bộ em cũng muốn theo trường phái 'security through obscurity' sao? . Trên Windows thì có một số soft. Anh không nhớ chính xác vì anh không 'chuộng' mấy cái này nhưng anh biết Windows có một cái gọi là urlscan. Nó làm việc trên tầng ISAPI của dịch vụ web của IIS và cho phép em 'giả' banner đó. Nếu thích thì vào site của Microsoft mà tham khảo thêm. Anh nghĩ em có thể táy máy đến mấy các dll của inetsrv của Windows để đổi banner nhưng chắc sẽ mất thời gian. Hơn nữa, đã dấu thì dấu cho trót, phải đổi hết trọn bộ error pages của IIS không thì banner một nơi mà error pages một nẻo." 

'haothu' thắc mắc: 
"Anh vừa nói chuyện thay đổi tcp/ip stack để che dấu 'footprint', em thấy cái này lạ ghê. Anh nói rõ hơn một tí được không anh?" 

Tôi đáp: 
"Ừa, đó cũng là một trong những lý do anh đề nghị bọn em đọc kỹ về tcp/ip lần trước để dễ hình dung hơn đó nhưng mấy anh em mình sa đà ở mức banner nên chưa đề cập đến level này. Chắc chắn mình sẽ đụng đến khoảng đó thôi. Em an tâm." 

Tôi tiếp tục phần đang khai triển ở trên: 
"OK, nếu mình biết 'thằng' thứ nhất ở trên là giả mạo, làm sao mình xác định được danh tánh thật sự của nó là gì?" 

Bộ bốn lại im lặng. Sau vài phút, 'docco' lên tiếng: 
"Ái chà, cái này mới vui á. Em mghĩ chẳng dễ tí nào." 

'haothu' nhận định: 
"Em nghĩ chắc phải dùng phương pháp so sánh như kiểu mình so sánh với một IIS server như hồi nãy thôi anh. Anh thấy chuyện này khả thi không?" 

Tôi đáp: 
"Khả thi chớ sao không em? Em nên nhớ rằng, bước thăm dò bằng tay tuy chậm nhưng nó luôn luôn cho em kết quả xác thực hơn bước thăm dò tự động bằng công cụ nào đó. Vậy, để so sánh thì mình cần có cái gì?" 

'haothu' trả lời: 
"Nhất định là mình phải có các bản mẫu 'xịn' rồi cứ dùng cái mình đang thăm dò mà so sánh với bản 'xịn' là xong." 

Tôi khơi mào: 
"Vậy mình cần phải thu thập hết các bản mẫu 'xịn' . Cái này còn gọi là 'footprint database'. Tùy mỗi người có cách lưu trữ và so sánh nhưng điểm cốt lõi là: dù có 'rà' bằng tay hay 'rà' tự động, em phải có một số thông tin mẫu nào đó để làm chuẩn. Nếu không, em không thể so sánh cái mình thấy (từ việc thăm dò) với một cái gì khác cả." 

'haothu' hỏi tiếp: 
"Vậy mình phải 'thăm dò' hết các loại web server để lấy 'footprint' thứ thiệt để dành hay sao anh? Cực quá vậy? Có database nào có sẵn mấy cái này không anh?" 

Tôi đáp: 
"Anh nghĩ là có nhưng chưa thấy phổ biến ở bên ngoài như một database bình thường mà nó thuộc một công cụ thăm dò ở dạng mình đang bàn. Bởi vậy, ngay từ đầu anh đã nói: muốn thâm nhập một cách đúng nghĩa, em phải rất kiên nhẫn, phải có căn cơ và phải hiểu mục tiêu của mình là vậy đó." 

Tôi nói tiếp: 
"Ở đây anh muốn nói đến phương hướng tiếp cận vấn đề chớ không phải cách giải quyết cụ thể cho từng trường hợp, từng khúc mắc. Hướng tiếp cận ở đây là: tìm và thu thập các 'footprint' của các web server để làm tư liệu cho việc so sánh về sau. Còn chuyện giải quyết thế nào thì mình đã bàn qua phần nguyên tắc. Anh chỉ 'khơi mào' cho em để khởi động còn muốn chạy xa, chạy nhanh thì tuỳ ở em . 

Với hai ví dụ trên, anh còn muốn nhắc đến một điểm khác rất quan trọng. Bọn em thử copy và paste chúng vào hai cột cạnh nhau để dễ so sánh, dùng soft nào cũng được, cách nào cũng được, miễn sao có thể đặt chúng bên cạnh nhau để so sánh. Chắc chắn em sẽ tìm ra thêm điểm khác nhau nữa." 

Vài phút trôi qua, 'ccxx' lại lên tiếng trước tiên: 
"Em thấy rồi. Vị trí thứ tự của các HTTP header khác nhau phải không anh?" 

Tôi đáp: 
"Chính xác. Chúng khác nhau đó. Trước đây anh cũng thắc mắc chuyện này nhưng sau khi xem mấy các RFC cho HTTP thì mới thấy là chẳng có áp đặt cụ thể nào về thứ tự trình bày của các HTTP header cả. Bởi thế, mỗi nơi implement mỗi khác và đây là một điểm đặc thù giúp mình phân tích và phân biệt 'footprint' nữa." 

'cuti' thắc mắc: 
"Sao anh biết được những chi tiết tinh vi và khó thấy như thế vậy anh? Có tài liệu nào đó hướng dẫn mấy chuyện này không anh?" 

'docco' cũng lên tiếng: 
"Dạ, em cũng thắc mắc như thằng Duy vậy. Em chưa hề thấy ở đâu nói đến những chi tiết lý thú như thế này về chuyện nhận diện 'footprint'." 

Tôi đáp: 
"Có thể có những tài liệu phân tích những chuyện này. Anh không chắc vì anh chưa hề đọc được cái nào cả. Để trả lời thắc mắc của 'cuti', anh vô tình tìm ra những khác biệt đó trong khi 'táy máy' và test một web application viết bằng java. Application này được deploy trên cả Windows lẫn Unix nhưng có web-tier khác nhau. Trên Windows thì dùng IIS và trên *nix thì dùng Apache và iPlanet (của Sun). Anh phải bắt lấy hết các header của từng loại web server để tạo bộ luật mapping cho cái reverse proxy nên mới thấy được những cái khác nhau kia. Kinh nghiệm xương máu đó! " 

'haothu' rên rỉ: 
"Ôi trời, anh 'Việt-hóa' đoạn trên dùm em được không anh? cái gì mà 'web-tier', rồi đến 'deploy', 'mapping', rồi 'reverse proxy'... Em đọc thấy muốn... tẩu hoả luôn " 

Tôi cười, đáp: 
"Ái chà... anh cũng chẳng biết phải dịch ra sao nữa. Nếu em có đụng chạm đến các ứng dụng web hạng... nặng thì hẳn sẽ biết được khái niệm 'mutlti-tier' application. Cái này có nghĩa là một ứng dụng có nhiều tầng như: tầng web, tầng logic, tầng dữ liệu (database). Còn chữ 'deploy' thì có nghĩa đại loại như cài đặt, thiết lập một chương trình mới trên một máy chủ. 'deploy' mang nghĩa rộng hơn 'install' (là cài đặt). Riêng 'mapping' thì anh không biết phải dịch ra sao. Nó có nghĩa nhưng là so sánh, biên dịch 2 phía thông tin. Ví dụ, phía A có thông tin là 1 có thể được 'map' thành Z ở phía B chẳng hạn. Chữ 'reverse proxy' có nghĩa là 'proxy ngược'. Người dùng trong LAN muốn truy cập Internet thì đi xuyên qua 'forward proxy', còn người dùng từ Internet muốn vào web server của em thì đi qua 'reverse proxy'. Những khái niệm này khá dễ hiểu, em chịu khó tham khảo thêm trên net." 

'cuti' nhận xét: 
"Ra vậy. Có quá nhiều kiến thức đi ra từ kinh nghiệm bản thân, trong môi trường làm việc thật sự chớ chẳng phải cái gì cũng có trong sách." 

Tôi đáp: 
"Đúng thế. Anh đã có lần đề cập trước đây, sách là nguồn thông tin tổng quát. Nó giúp em hình thành một cái 'sườn' của vấn đề. Tùy vào em mà hình thành cái 'ruột'. Những điều mấy anh em mình 'đà khía' ở đây có rất nhiều điều đi từ 'kinh nghiệm xương máu' mà có. Anh biết có những cái lạ lẫm, khó hình dung bởi vì em chưa gặp qua. Tuy nhiên, đến một lúc em đụng phải điều gì đó mình đã bàn ở đây thì tự nhiên sự việc sẽ sáng tỏ, dễ dàng thôi." 

'cuti' thắc mắc: 
"Vậy anh muốn bọn em đi thu thập mấy cái header 'xịn' để làm tư liệu hả anh?" 

Tôi đáp: 
"Tùy em thôi. Nếu em thấy thích thú chuyện này thì em có thể dành thời gian để đào xới chúng. Anh dám chắc em sẽ thu thập được nhiều điều lý thú. Tuy nhiên, điểm cốt lõi anh muốn bọn em ghi nhận ở đây là điểm khác cơ. Em có biết đó là gì không?" 

'cuti' đáp: 
"Điểm gì cà? Ái chà, căng à nha." 

'haothu' lên tiếng: 
"Anh mổ xẻ chuyện 'footprint' với bọn em rồi để cho bọn em tùy chọn muốn đào thêm hay dừng lại mà không tỏ vẻ quan trọng chuyện này. Vậy chuyện gì quan trọng nhỉ?" 

'docco' lên tiếng: 
"Em nghĩ là em đoán được. Ý anh là muốn giới thiệu đường hướng và lối khai triển một cách logic phải không ạ?" 

Tôi đáp: 
"Anh không nói là những chuyện mình vừa bàn không quan trọng. Anh chỉ nói rằng tùy người, tùy nhu cầu mà nó quan trọng nhiều hay ít. 'docco' nói đúng đó, nhưng còn gì nữa?" 

'ccxx' cũng tham gia: 
"Không biết em nghĩ có đúng không nhưng xem lại mạch chuyện từ nãy giờ, em thấy một điểm khá quan trọng là ngoài tính logic còn có tính tập trung và sự tinh tế trong khi nhận xét vấn đề. Phải không anh?" 

Hết sức hoan hỉ, tôi đáp: 
"Voila! chính xác. Logic tối cần thiết nhưng tính tập trung và sự tinh tế không thể thiếu được. Sau này, khi em đi đến chỗ viết shellcode, dò stack mà lại thiếu sự tinh tế thì sẽ không thể đạt kết quả được. Đối với 'hacker', mỗi chi tiết bé nhỏ đều có thể mang một giá trị lớn lao. Chúng có thể làm em mất ăn, mất ngủ, mất thời gian để rồi, đến lúc nào đó em sẽ vò đầu và tự rủa mình vì đã 'sót' chúng trong khi phân tích. Thật ra, logic + tập trung + tinh tế là ba đức tính cần thiết không riêng gì trong bảo mật mà nó cần thiết trong các ngành khoa học." 

'docco' nói: 
"Em sẵn sàng tiếp nhận quan điểm này. Đừng nói đi đâu xa, những lúc làm bài tập hoặc viết một đoạn code đơn giản mà thiếu tập trung thì có chuyện ngay. Đặc biệt là lúc bị 'có chuyện' mà thiếu tinh tế thì tìm lỗi muốn... khùng luôn." 

Tôi muốn kết thúc buổi 'đà khía' nên rút ngắn: 
"Thôi, mấy anh em mình ngồi dính một chỗ đã quá lâu. Có lẽ lần sau mình mới đi vào chi tiết OS 'footprint' trên tcp/ip vì mình bị... 'cháy' kế hoạch rồi. Điều này cũng tốt vì bọn em có thêm thời gian để xem kỹ hơn về tcp/ip. Mấy đứa cũng nên đọc lại nội dung 'đà khía' lần này và ráng đúc kết vấn đề để làm nền cho lần tới." 

'docco' đáp: 
"Dạ, vậy cũng tốt mà anh. Em vẫn còn lủng củng nhiều điểm trên tcp/ip nên hoãn lại thêm một tí thì tiện hơn." 

'ccxx' nhấm nhẳng: 
"Em còn muốn cãi với ông Khoa về chuyện 'kiddie' dùng công cụ khó hay dễ vậy mà anh phải đi rồi. Thôi vậy, để em về chuẩn bị thêm để 'đấu' với ổng một trận. Anh làm trọng tài cho tụi em nha?" 

Tôi cười, đáp: 
"Ừa, miễn sao 'đấu' để đem lại một kết quả nào đó ích lợi thì anh làm trọng tài liền." 

'cuti' phát biểu: 
"Em rút kinh nghiệm những lần trước, lần này em sẽ in ra nội dung 'đà khía' để đọc lại và suy gẫm kỹ hơn. Em bị cảm giác là càng ngày càng bị tụt đằng sau." 

'docco' đáp: 
"Thì tui làm như vậy từ lâu rồi ông Hưng. Chẳng những thế, tập bài tui in ra bây giờ chằng chịt với những dòng gạch dưới, đóng khung, tự chú thích.... tá lã luôn. Không thì không nhớ xuể đâu á." 

Tôi trả lời: 
"Tùy mỗi đứa, tùy cách phân tích và chọn lọc thông tin cho mình thôi. Miễn sao rút tỉa được vài điều là tốt rồi. Nếu không hiểu thì sẽ thấy nặng nề và nếu kéo dài ở tình trạng 'không hiểu' này thì sẽ thì thấy... chán. Cái đó mới là hoài của nói theo lối nói người miền Bắc . Thôi, anh phải đi. Hẹn mấy đứa tuần sau nếu rảnh." 

và tôi logoff.. 

18/11/2005 

15. tcp/ip info, thật hay giả? - II: 
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>

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>

17. Những điều xem chừng vụn vặt: 
Dạo này bọn tôi, 'cuti', 'haothu', 'docco', 'ccxx' và tôi ít có dịp trò chuyện như trước. Có lẽ mấy cô cậu phải vùi đầu vào sách vở và phần tôi cũng không kém phần căng thẳng. Hàng loạt dự án đã được phê chuẩn và ông trưởng dự án nào cũng muốn dự án của mình có ưu tiên cao nhất. Nói thế tôi hy vọng bạn hình dung được nổi thống khổ của một kẻ 'làm công cho thiên hạ'. 

Đã gần một tháng trôi qua, tôi chỉ nhận được một e-mail từ 'docco' hỏi thăm tình hình công việc một cách chung chung. Tôi quyết định sẽ lấy 1, 2 ngày nghỉ bù (vì đã làm quá nhiều giờ). Nhẩm tính chiều thứ năm tới tôi sẽ rảnh ranh, để hỏi thăm đám 'cuti' có rảnhh không thì tụ lại đà khía một chặp cho vui. Thế là tôi gởi mail đến bốn trự. Mãi chiều hôm kế tiếp tôi mới nhận được thư hồi báo của cả bọn. Thế là chúng tôi hẹn nhau chiều thứ năm. 

Một giờ hai mươi lăm trưa, tôi log vào YIM. 
'docco' đang "vàng khè" online. Tôi không muốn bị "oanh tạc" nên đã cẩn thận logon ở dạng ẩn cho nên 'docco' vẫn không biết tôi đã logon. Tôi gởi cu cậu một thông điệp: 
"Hù... vào lâu chưa em?" 

'docco' không kém phần dí dỏm: 
"Oái oái, có ma, có ma.... hì hì. Khoẻ không anh? dạo này bọn em phê quá, bài vở nhiều hơn trước. Với lại em ráng tìm hiểu những chi tiết mấy anh em mình đà khía và càng tìm hiểu em càng thấy mênh mông." 

Tôi đáp: 
"Ừa, lúc đầu thường bị cảm giác choáng ngợp đó em. Từ từ sẽ dễ dàng hơn thôi. Mấy đứa kia đâu rồi em?" 

'docco' trả lời: 
"Tụi thằng Hưng, con Như nói là tụi nó sẽ vào chặng này nhưng em chưa thấy đâu. Để em gọi di động cho tụi nó thử. Còn thằng quái vật Khoa thì biến mất hút. Em nghe mấy đứa bạn nói là dạo này nó đắm chìm vào game. Kiểu này chắc hết học với hành (" 

Tôi chắc lưỡi, đáp: 
"Ừa, sao dạo này anh thấy game nở rộ, đi đâu cũng game, thậm chí lên báo om sòm. Chơi game không có gì sai hết nhưng chơi quên ngày giờ, quên học hành, quên mọi sinh hoạt khác thì kẹt lắm." 

Ngay khi đó, 'ccxx' vào. Cô bé nhanh nhảu gởi một thông điệp: 
"Tụi em đây. Ông Hưng đang ở nhà em, tụi em chat chung hén?" 

Lần này tôi gởi một request để thảo luận và cả bọn cùng vào conference. 'ccxx' lên tiếng: 
"Anh ui, em tìm nát nước mà không thấy có thông tin gì về SE hết anh?" 

Tôi đáp: 
"SE gì em? Software Engineering đó hả?" 

'ccxx' trả lời: 
"E hèm... anh đúng là già rồi nên lẫn ). Thì cái TCP flag SE lần trước em thắc mắc đó?" 

Tôi cười phì: 
"Mô phật... làm sao anh nhớ cho xuể em. Mà anh nhớ thằng Hưng thắc mắc vụ này mà? Đâu phải em đâu Như?" 

'ccxx' cười: 
"Hì hì, em đây, Hưng đây. Tụi em chat chung mà ). Em vừa thắc mắc chớ hổng phải Như đâu." 

Tôi đáp: 
"Mèn ơi... vậy thì em nên dùng H: hay N: để anh phân biệt đứa nào là đứa nào không thì lộn tùng phèo lên hết. OK, cái vụ SE nếu em chưa tìm ra thì anh cho cái RFC để mà xem. Thử tìm rfc3168 mà đọc nha em. Nó có một phần nói về SE trong đó." 

'cuti' than thở: 
"H: ặc ặc, anh đúng là ác thiệt là ác (. Hẹn cho đã rồi thảy cho cái RFC bắt phải đọc nữa." 

Tôi đáp: 
"Khì khì, vậy mà ác sao em? anh đưa cho em chính xác RFC để em tìm mà đọc là rút ngắn cho em khối thời gian để tìm rồi đó, vậy mà còn than với thở. Em không cần phải đọc liền, chỉ ghi chú ở đâu đó rồi lúc nào thanh thản hẵng tìm mà đọc không thì bội thực ráng chịu )." 

'ccxx' xen vào: 
"N: Ổng lúc nào cũng vậy đó anh. Thấy cái gì cũng ham. Lúc nào cũng ôm đồm đủ thứ rồi nản. Em nói hoài không chịu nghe. Hồi trước thấy thiên hạ đua nhau sưu tầm e-book cũng bắt chước thức khuya thức hôm để download cho được. Mang về cả gi -2- rồi có bao giờ đụng tới đâu? Vô mấy cái forum, thấy người ta kháo cái ngôn ngữ lập trình nào là hăm hở về lục đục cả đêm, Python cũng cài, Ruby cũng đặt, lại còn php, đèo bồng thêm Java rồi khệ nệ bưng cả đống CD mua ngoài tiệm về cho mấy cái .NET gì đó... Vậy mà em chưa thấy ổng code cho ra một cái gì cho rõ ràng hết. Tụi em cãi nhau hoài về chuyện này anh ơi (." 

Tôi cười, chậm rãi đáp: 
"Thế này.... 
Cu Hưng nó thích táy máy, cái thì thấy, nghe cũng ham là chuyện tốt, có thông minh mới có như thế. Nếu nó thụ động, chẳng ham cái gì thì mới nguy. Việc cần làm là 'đốc' làm sao để nó thực hiện một công trình nho nhỏ nào đó. Khi nó bắt tay vào công trình đó, tự nhiên đống e-book kia sẽ hữu dụng và tự nhiên nó sẽ master một ngôn ngữ lập trình nó chọn. Em nên khuyến khích nó, đừng cãi làm chi cho.... rắc rối thêm )." 

'ccxx' trả lời: 
"N: Em đâu muốn cãi với ổng, em chỉ góp ý để tốt cho ổng thôi mà ổng bướng thầy chạy luôn á. Với lại cái gì em cũng phải nhắc ổng, có bao giờ ổng quan sát mà nhắc em cái này cái kia đâu anh? Bữa nay nhân dịp này em muốn anh can thiệp dùm em cái. Hay là anh ra bài gì cho ổng làm đi anh? Ổng chỉ nghe lời anh thôi." 

Tôi cười phá lên và đáp: 
"Ha ha, đến giờ này anh đã lấy vợ mười mấy năm mà bà xã anh vẫn nhắc anh đủ chuyện, có bao giờ anh nhắc bà xã anh cái gì đâu em? Đàn ông, con trai vậy là bình thường thôi em. Để anh thử xem cu Hưng nó thích làm cái gì đã." 

'ccxx' nguýt: 
"N: Hứ... mấy ông con trai cứ hở ra là bênh nhau thôi. Em chỉ thấy ổng biết lung tung thứ nhưng hầu hết là những thứ lặt vặt, chắp vá. Mai mốt ra trường, đi kiếm việc người ta hỏi có khả năng gì, biết làm gì? Chả lẽ khai ra mấy cái kinh nghiệm mạng lặt vặt sao anh?" 

Tôi đáp: 
"Hì hì, em nói chí lý lắm bé Như. Anh không bênh cu Hưng chuyện này đâu. Để xem cu Hưng nghĩ sao. Nè, ku Hưng, em nghĩ là em muốn làm gì hở?" 

"cuti" lên tiếng: 
"H: Đó, bả ỷ có anh ở đây nên ăn hiếp em túi bụi. Tại vì em chỉ muốn tìm hiểu xem mình thích hợp với cái gì rồi mới quyết định thôi mà anh. Em nghĩ là em thích cả quản lý mạng và lập trình. Làm sao mình trau dồi được cả hai hở anh?" 

Tôi trầm ngâm, tìm cách trả lời 'cuti'. Sau một đỗi, tôi đáp: 
"Thế này... anh thấy trong mạng có lập trình và trong lập trình có mạng. Tuy nhiên, trong quá trình đi sâu và master mỗi nhánh này, nó đòi hỏi một số điểm chung và điểm riêng. 

1) nếu em chọn mạng làm sở trường, em đi sâu vào việc học và làm quen các thiết bị mạng, các ứng dụng software chuyên về mạng, các giao thức mạng và các kỹ năng phân tích + thiết kế môi trường mạng. Chọn lựa này không đòi hỏi kỹ năng lập trình sâu và chuyên như nhánh lập trình. Tuy nhiên, em cần khả năng lập trình để hỗ trợ công việc quản trị mạng này. Ví dụ, em cần thiết lập một hệ thống theo dõi các nodes trong mạng, hoặc thu thập logs của các services để phân tích tình trạng hoạt động của mạng, em không nhất thiết phải lập trình ở mức độ chuyên để tạo ra một software đa năng, mạnh mẽ, ít bugs mà em chỉ cần code bằng ngôn ngữ nào đó dễ học, gọn nhẹ để thực hiện mục đích. Tất nhiên, nếu em có thời gian và khả năng để code một công cụ thật chuyên thì càng tốt hơn. Mạng ở đây là cung cấp phương tiện giao chuyển thông tin một cách hiệu suất, ổn định bằng các thiết bị, môi trường cho phép. 

2) nếu em chọn lập trình làm sở trường, em đi sâu vào việc học và làm quen với tính logic, khả năng lập luận, phân tích, cú pháp của ngôn ngữ lập trình, API em dùng và thậm chí cả cơ chế làm việc của một hệ điều hành hoặc một chuỗi hệ thống. Mạng sẽ dính đến lập trình ở một lúc nào đó bởi về không có hệ thống nào ngày nay mà không đụng đến mạng. Tuy nhiên, biên độ mạng ở đây không trực tiếp và cụ thể đến từng thiết bị của từng hãng nào đó mà nó thường nằm ở tầng thấp hơn (socket) hoặc tầng cao hơn (application xuyên qua API). 

'docco' xen vào: 
"Em cũng đã hình dung lờ mờ những điểm ở trên và cảm thấy những ham muốn 'cả hai' là những ham muốn hơi quá trớn bởi vì không thể thực hiện một cách vẹn toàn được. Cái gì cũng muốn, cái gì cũng quơ quào thì một hồi sẽ lõng bõng thôi." 

Tôi đáp: 
"Đúng đó em. Anh nghĩ, khởi đầu nên đi vào chiều sâu. Khi đã vững thì tự nhiên nó sẽ mở ra chiều rộng. Nếu sâu không đủ mà rộng không tới thì chắc chắn sẽ bị 'lõng bõng' như em nói." 

'cuti' chống chế: 
"H: Em không đồng ý. Chớ anh thì sao? Anh cũng làm về mạng, cũng lập trình được vậy? Em muốn làm theo kiểu anh làm thôi." 

Tôi đáp: 
"Thật sự mà nói, nói về mạng, anh không phải là tay thật chuyên về mạng, nói về lập trình, anh cũng chẳng phải là một tay chuyên chú lập trình. Bởi thế, anh vẫn học thêm vào đào sâu từng mảng kiến thức mỗi ngày đó thôi. Anh đi vào ngành này không được chính quy, có trường lớp như bọn em nên sự thể như thế cũng không đáng ngạc nhiên. Nếu em muốn làm theo 'kiểu anh làm' thì cực nhọc lắm đó vì em phải chuyên cần và kiên nhẫn." 

'cuti' nhấm nhẵng: 
"H: Được rồi, được rồi, em nhất định sẽ chuyên cần và kiên nhẫn." 

'ccxx' châm thêm: 
"N: Ừa, thì làm đi rồi hẵng nói. Lần nào cũng 'em sẽ thế này, em sẽ thế kia' nhưng được ba bữa là đâu lại vào đấy thôi." 

'cuti' nói: 
"H: Em thấy mấy anh em mình bàn càng lúc càng xa khỏi biên độ hacking và security hay sao đó. Mình nói chuyện cụ thể hơn được không anh?" 

Tôi cười, đáp: 
"Cụ thể thế nào em? Anh nhớ có lần mình đã đồng ý với nhau rằng, hacker là một user có kiến thức sâu dày, hiểu rõ và nắm rõ những gì anh ta muốn hack và cần hack rồi mà. Cho đến chừng nào em thật sự có kiến thức sâu dày, hiểu rõ và nắm rõ những gì em muốn hack và cần hack thì tự nhiên em thấy nó hết sức cụ thể. Những kiến thức bao quanh cái gọi là 'sâu dày', cho đến nay em vẫn chưa đạt tới thì làm sao mình nói chuyện cụ thể?" 

'cuti' cụt hứng: 
"H: Ờ hén... em cứ bị vướng víu chuyện này mãi. Ý em nói là sau khi mình xác định được foot print đầy đủ hết rồi, mình sẽ làm gì nữa anh?" 

Tôi đáp: 
"Em muốn đóng vai trò em là tester hay đóng vai trò em là perpetrator?" 

'cuti' đáp: 
"H: Em không biết nữa anh. Miễn sao em hiểu được các bước thâm nhập gồm có cái gì để thoả mãn cái tò mò là được." 

Tôi đáp: 
"E hèm... vắng mặt mới có một tháng mà nó đã quên hết ráo. Không có các bước thâm nhập nào hết đâu em. Một ngàn hệ thống có một ngàn tính chất khác nhau. Ngay cả cũng chính hệ thống đó, ngày hôm trước có thể khác ngày hôm sau. Bởi thế, không thể có 'các bước' cụ thể nào cả. Vả lại, trước giờ mình bàn về cái nhìn từ hai phiá bảo mật + thâm nhập chớ chưa bao giờ mình nói đến chuyện 'các bước' nào hết." 

'cuti' tiếp tục: 
"Ùm... nhưng em ức ở chỗ sao nhiều người có thể dạo một vòng, làm cái gì đó là có ngay 'hacked by xyz...', rồi nào là hack local, nào là up shell... Em hỏi mà chả có ai thèm trả lời em hết." 

Tôi đáp: 
"À, ra thế. Nếu em thắc mắc những chuyện đó thì anh sẽ cố gắng giải thích trong giới hạn cho phép. Tuy nhiên, em cần xác định rõ là những gì mình trao đổi bấy lâu nay không phải để hướng về những chuyện như thế." 

'cuti' hớn hở: 
"Dạ em biết mà. Anh giải thích dùm em mấy cái đó là cái gì đi?" 

Tôi đáp: 
"Sở dĩ một ai đó có thể vào site của một ai khác để trưng lên dòng 'hacked by...' là vì hắn có đủ chủ quyền để thay đổi nội dung một trang nào đó trên web site này. Em còn nhớ lần anh em mình cá độ và em chịu thua không? Nguồn gốc vấn đề nằm ở chỗ thư mục có chứa file mang nội dung 'hacked by... " kia cho phép một ai đó có chủ quyền thích ứng thay đổi nội dung file như thế." 

'cuti' đáp: 
"Em biết rồi, nhưng làm sao có thể đổi ngang xương như vậy anh? Em thử ngay chính con Linux của em rồi mà không được. Ví dụ thư mục đó chứa index.html và do B làm chủ, em là A, em chỉ có quyền đọc nó thôi, không có quyền chỉnh nó." 

Tôi đáp: 
"Anh nghĩ em nên nhớ lại những gì mình trao đổi trước đây, có lẽ em quên khá nhiều rồi đó. Nếu em là A, em không thể thay đổi nội dung file do B làm chủ. Để có thể thực hiện hành động thay đổi nội dung đó, em có thể: 
- biến mình thành B 
- biến mình thành C nếu C thuộc nhóm với B và có cùng chủ quyền 
- biến mình thành X nếu X có chủ quyền hơn cả B 

Em nghĩ xem, trên Linux server của em đó, em là A, B là chủ của thư mục, vậy C là ai và X là ai?" 

'cuti' ngần ngừ: 
"H: Em chẳng biết nữa (.... để em coi lại thử." 

Tôi nói thêm: 
"Trên *nix, tổng quát mà nói, một thư mục có A làm chủ, có nhóm users gán cho thư mục ấy và có chủ quyền rwx. Một file trong thư mục cũng tương tự. Nếu A là owner thì A có thể làm bất cứ điều gì mình muốn đến thư mục và file trong thư mục ấy. Nếu thư mục và files có ấn định là nhóm users gán cho nó có cùng chủ quyền thì mọi người trong nhóm đều có thể thực hiện công việc y hệt như A. Ngoài ra, root cũng có thể làm tương tự. Đây là kiến thức căn bản không thể thiếu được." 

'cuti' cãi lại: 
"H: Em không tin là mấy đứa trên mạng có đầy đủ các kiến thức như vậy đâu anh. Hổm bữa em chat với một thằng, nó biểu diễn cho em coi nhưng em hỏi nó về Linux thì nó nói là nó không biết gì nhiều về Linux hết. Vậy sao nó vẫn làm được?" 

Tôi hỏi: 
"Nó làm những gì, nó có cho em biết không?" 

'cuti' đáp: 
"Dạ, nó dấu nghề mà anh. Làm gì cho em biết. Nó chỉ nói thao thao nào là up shell, rồi đổi index... cái gì, cái gì đó... Em rối tung, rối mù lên." 

Tôi cười đáp: 
"À, anh hiểu rồi. Mấy cái 'shell' mà em nói ở đây không phải OS's shell thông thường -3- mà chỉ là những script được viết bằng Perl hay Python hay thậm chí php. Nó có khả năng thực thi một số công việc định sẵn và nó chạy ở trên web service được tạo bằng Apache chẳng hạn. Tất nhiên là những cái shell này chỉ có thể làm việc nếu cấu hình của Apache cho phép và tất nhiên chúng chỉ có thể chạy với chủ quyền tối đa là chủ quyền admin đã ấn định cho Apache. Anh nghĩ nếu em thích thì em nên xem cách những cái shell này được viết thế nào để hiểu chúng làm việc thế nào thì mới lý thú và đáng thời gian bỏ ra. Còn nếu chỉ dùng một cái 'shell' do ai đó viết để xem files, delete files hay làm những chuyện khác trong giới hạn có thể được thì em chỉ dừng lại ở mức độ người dùng mà thôi, thậm chí còn kém hơn người dùng bởi vì người dùng cần shell để quản lý hệ thống, còn em cần 'shell' để phá hệ thống." 

'cuti' rên rỉ: 
"H: đó đó, ông thầy ổng lại lên lớp rồi đó. Em chỉ muốn biết thôi mà (." 

Tôi đáp: 
"Thì anh đã nói, em muốn biết thì nên sưu tầm vài cái 'shell', chúng có đầy trên web đó. Tải về và xem chúng được viết thế nào. Nếu muốn biết chúng làm việc thế nào thì cài lên cái Linux server của em mà vọc. Anh đâu có cản gì đâu? Anh chỉ muốn nhắc em là đừng sa đà vào những trò vớ vẩn bởi vì upload một cái shell lên server của người khác rồi delete files, rồi thay thế index.html có nội dụng 'hacked by cuti' thì chẳng có gì vui và sáng tạo cả. Mấy cái trò này dành cho những đừa 'teen' -4- dư thời gian và thiếu định hướng mà thôi. Em đã qua cái thời này rồi thì đừng nên đi thụt lùi lại." 

'docco' xen vào: 
"Em có một thắc mắc với câu ở trên của anh. Anh nói là Tất nhiên là những cái shell này chỉ có thể làm việc nếu cấu hình của Apache cho phép và tất nhiên chúng chỉ có thể chạy với chủ quyền tối đa là chủ quyền admin đã ấn định cho Apache là sao anh?" 

Tôi cười và trả lời: 
"À... có lẽ em chưa dùng Apache nhiều nên thắc mắc. Câu ở trên có hai phần riêng biệt trong đó. 

- phần một: Apache có một directive gọi là AddType dùng để phủ định một loại MIME nào đó đã được ấn định trong file "mime.types". Nếu trong file "mime.types" không có ấn định nào cho php chẳng hạn và cũng không có ấn định nào từ directive AddType trong cấu hình của Apache thì một file php nào đó, khi được access trên trình duyệt, nó sẽ được hiển thị như một text file bởi vì Apache cho rằng nó là một text file và cung cấp nó đến trình duyệt như một text file. Ở tình trạng này, cái 'shell' php đó không thể thực thi gì cả. 

- phần hai: Nếu php được ấn định cụ thể ở một AddType directive nào đó, khi người dùng access nó bằng trình duyệt, nó sẽ thực thi các function có trong file này và nó chạy bằng chủ quyền y hệt như chủ quyền đã ấn định cho Apache." 

'docco' ậm ừ: 
"Ùm... à... em hơi hiểu hiểu rồi đó. Chỉ có phần chủ quyền ấn định cho Apache em chưa hiểu." 

Tôi cười và đáp: 
"Khì khì, lại có màn 'hơi hiểu hiểu' nữa hả? Em thắc mắc phần chủ quyền ấn định cho Apache là một thắc mắc rất lý thú. Nó gắn liền với những cơ chế sâu xa trên hệ điều hành đó. Điều em cần nắm là nguyên tắc tạo ra một process trên hệ điều hành. Ở đây mình giới hạn trên Linux để tránh lan man. 

Ở những phiên bản sơ khai của Apache, khi em khởi động Apache, nó tạo ra một process do root làm chủ. Sở dĩ em phải khởi động Apache ở chế độ là root là vì Apache sẽ tạo một LISTENING port 80. Port 80 là port nằm trong chuỗi "low ports" (dưới 1024) và để tạo một port trong chuỗi này em phải là root thì mới tạo được. Sau này Apache hình thành cơ chế 'chuyển quyền' sau khi khởi động. Nói một cách nôm na là sau khi khởi động và tạo xong port 80 ở tình trạng LISTEN, nó hạ chủ quyền từ root xuống thành chủ quyền của một account nào đó em gán trong cấu hình của Apache. Em biết lý do tại sao không?" 

'ccxx' reo lên: 
"N: Em biết, em biết. Có phải đây là lý do an toàn không anh? Nếu Apache chạy ở chủ quyền root và ai đó load một con 'shell' nào đó lên thì con shell này cũng sẽ chạy với chủ quyền root, phải không anh?" 

Tôi đáp: 
"Em thông minh lắm. Lý do chính xác là như thế. Trên *nix, root là account có quyền hạn tuyệt đối và nếu một dịch vụ nào đó cho phép một script nào đó... 'chạy ké' như mấy con 'shell' mà cu Hưng thắc mắc ở đây ở quyền hạn tuyệt đối như thế thì bảo mật coi như là con zero to tướng. Này Duy, nếu em thích đào sâu, em có thể tìm thông tin về 'process forking' trên *nix để nghiên cứu thêm. Riêng với phần 'hạ chủ quyền' thì em có thể tìm thông tin về setuid mà đọc." 

'cuti' xuýt xoa: 
"E hèm... em hỏi rùa rùa mấy con shell vậy mà cũng có chuyện thật là lý thú. Cũng không phí anh nhỉ? )" 

Tôi đáp: 
"Ừa, bất cứ điểm nhỏ bé nào đi chăng nữa, khi mình nhìn nó một cách cẩn thận và ngọn ngành để có thể hiểu rõ về nó thì anh tin rằng lúc nào cũng có chuyện lý thú cả." 

'ccxx' trầm ngâm: 
"Có ai ngờ mấy cái 'directive' nhỏ bé và đơn giản của Apache mà lại quan trọng đến thế." 

Tôi đáp: 
"Tất cả các chức năng, ấn định trên một ứng dụng đều có vai trò của chúng. Nếu không, chúng không tồn tại và những gì không cần thiết hoặc không đúng chức năng thì từ từ sẽ bị biến mất. Đối với những chương trình cung cấp dịch vụ, người quản lý cần biết lý do tại sao chúng tồn tại và chúng làm việc thế nào, người bảo mật hay tấn công chẳng những nắm vững những điều người quản lý nắm mà còn đi sâu hơn để biết mặt yếu của chúng." 

'cuti' lên tiếng: 
"Quay trở lại mấy cái shell, anh nói là mấy cái đó không có gì đáng để học sao?" 

Tôi trả lời: 
"Em dùng thanh trượt để kéo lên phía trên xem lại đi em. Những 'con' script đó có điểm đáng để học là nội dung của nó, cách nó được code chớ không phải là cách cài nó và dùng nó. Mục đích nó được code ra để làm việc tốt hay việc xấu mình không bàn nhưng nó được code như thế nào thì đáng để học hỏi. Anh thấy đọc code cũng là một cách học rất hay bởi vì xuyên qua code, mình không những học được những góc độ kỹ thuật trong đó mà còn học được cách tư duy, logic, sắp xếp của người đã code." 

'cuti' gỡ gạc: 
"H: Nhưng mình cài nó lên rồi quậy quậy tí tí cũng vui mà anh. Em biết ý anh nói gì rồi. Ý anh là tụi em học thêm Perl, Python hay cái gì gì nữa phải không? )" 

Tôi đáp: 
"Ừa, để em có thể đọc được code do ai đó viết và nhất là 'cảm' được cái hay của nó, em phải thông thạo ngôn ngữ được dùng để viết nó ra." 

'docco' hỏi tiếp: 
"Anh có thể cho em một đoạn code minh hoạ được không anh?" 

Tôi đáp: 
"Code minh hoạ thì có đầy dẫy trên mạng mà em. Nhưng được rồi, chờ anh một tí. 

Tôi lục lọi trong mớ "disclosed exploit" nhận được từ newsgroup và trả lời: 
"Hãy thử xem một đoạn cho vui, đoạn này anh lấy từ newsgroup do Matthew Murphy viết: 

Code:

$f = IO::Socket::INET->new(Proto=>"tcp", PeerAddr=>"127.0.0.1");
print STDOUT "Exploiting a proxy server \[Y/N\]? ";
$line = <STDIN>;
$char = mychomp($line);
if ($char == "Y" || $char == "y") {
	print $f "GET / HTTP/1.1\x0d\x0a";

	for ($i = 0; $i < 10; $i++) {
		print $f "Host: ".("A"x2000)."\r\n";
	}
	if (defined($base64)) {
		print $f "Proxy-Authorization: Basic ".$base64."\r\n";
	}
	print $f "\r\n";
} else {
	print STDOUT "What resource should be probed: ";
.........
}

" 

Tôi hỏi tiếp: 
"Nếu quen với Perl, em sẽ thấy đoạn code trên hết sức đơn giản nhưng cái lý thú là Perl được dùng để exploit một chỗ hở của Apache một cách dễ dàng và gọn gàng. Em xem cho biết." 

Cả ba im lặng hồi lâu. Rốt cuộc 'docco' lên tiếng: 
"Em thì bó tay rồi đó anh vì em chẳng biết perl. Chắc hai đứa kia cũng vậy thôi (. Anh giải thích một tí được không anh?" 

Tôi đáp: 
"Đại khái là thế này. Exploit trên nhằm qua mặt cơ chế giới hạn số lượng và kích thước của HTTP header mà Apache (giả định đã) kiểm soát. Nó in ra 9 dòng ($i = 0; $i < 10; $i++) "Host: AAAAA...." mỗi dòng có 2000 chữ A. Với kích thước này, phiên bản Apache bị lỗi sẽ crash vì giới hạn header chỉ là 8190 bytes." 

'cuti' xuýt xoa: 
"H: Ái chà, chỉ có vài dòng đơn giản như thế mà crash được cả apache server thì quả là đỉnh ), nhưng làm sao người viết đoạn script này biết được ngay cái chỗ để ngoáy vào cho nó chết vậy anh?" 

Tôi đáp: 
"Tay Matt này không trình bày quá trình test cụ thể của mình nhưng anh đoán có ít nhất hai hướng để test và tìm lỗi: 

1) thử dạng 'blackbox': bằng cách chọc ngoáy vào cái HTTP header cho đến khi Apache có "thái độ" khác thường. Cách này thì lâu và càng lâu hơn nếu không nắm được giao thức HTTP và cách làm việc của nó. 

2) thử dạng rà code: mã nguồn của Apache là mã nguồn mở. Nếu muốn máy mó thì download nó về mà soi. Tuy nhiên để làm được chuyện này, ngoài việc nắm vững giao thức HTTP, em còn phải rất rành C thì mới rà được." 

'ccxx' hỏi tiếp: 
"Ùm... em hơi bị lơ mơ rồi đây (. Làm sao mình có thể xác định khu vực hoặc thu hẹp khu vực có tiềm năng bị hở mà khai thác anh? Em nghĩ một soft như Apache chắc phải có vài trăm nghìn dòng code là ý. Dò như vậy chắc chết." 

Tôi cười, đáp: 
"Em nói đúng. Không mấy ai dò từng dòng một, ngoại trừ người dò đó là tay lo về quality assurance cho code của Apache ). Dẫu tay ấy có rà kiểu như vậy, cơ hội bị sót hoặc không nhận ra chiều sâu của lỗ hổng bảo mật rất cao. Theo kinh nghiệm anh rút tỉa được, những điểm nhận INPUT và kiểm soát, xác thực, giới hạn giá trị INPUT của một software là điểm đầu tiên nên được xét bởi vì ở những điểm này, dữ liệu có tính chất và kích thước nằm ngoài giới hạn dự tưởng nhất định sẽ tạo 'thái độ' bất bình thường cho software đó. Đối với một ứng dụng cung cấp dịch vụ web như Apache, điểm nhận INPUT quan trọng là mớ HTTP header. RFC cho giao thức HTTP có những quy định tổng quát nhưng bỏ ngỏ nhiều điểm tùy vào người ứng dụng. Bởi thế, điển hình là Apache quyết định giới hạn tối đa của header field có kích thước là 8190 bytes mặc dù RFC tiêu chuẩn không ép buộc giới hạn này." 

Tôi ngừng lại một chút rồi hỏi tiếp: 
"Em theo kịp không Như?" 

'ccxx' đáp: 
"Dạ kịp anh. Có gì em lưu lại nội dung chat này để về đọc offline thêm. Anh an tâm )." 

Tôi nói tiếp: 
"Giả sử anh là người lo về việc kiểm tra tính bảo mật và chất lượng cho code của Apache, hoặc anh có ý định thử nghiệm để exploit Apache, anh bèn lôi tài liệu kỹ thuật của Apache ra mà ngâm, so sánh các ứng dụng của nó với RFC, tìm và rà những đoạn code liên quan đến những điểm INPUT, liên quan đến HTTP header. Sau đó xoáy sâu và cụ thể vào từng điểm một của cơ chế quản lý và kiểm soát dữ liệu nhập. Ví dụ, Apache ấn định mỗi header field chỉ tối đa là 8190 bytes, cái này thì đã rõ nhưng.... cơ chế nào kiểm soát chuyện này và nó kiểm soát như thế nào? có cách nào lừa nó để đi quá giới hạn đã ấn định hay không?.... Sau đó mới thử nghiệm bằng tay để xác định." 

Ngừng lại một giây, tôi nói tiếp: 
"Khả năng exploit các HTTP headers trên một ứng dụng tạo dịch vụ web rất rộng bởi vì có một mớ headers và mỗi header mình có thể thử nhiều thứ khác nhau. Ví dụ như tạo một loạt header fields như nhau, kích thước header fields khác nhau, chèn code vào header field, thử nghiệm các dạng encode khác nhau trên header field.... Nói chung, làm những cái này phải kiên nhẫn và có hệ thống để liệt kê những gì đã thử và chưa thử. Hình thành cả một cái test plan hẳn hòi càng tốt )" 

'cuti' lên tiếng: 
"Trời, nghe thấy cực quá vậy anh? Em không ngờ hack lại mất thời gian và phức tạp như vậy." 

Tôi đáp: 
"Hì hì, nếu lấy sẵn script của ai viết để mà 'hack' thì dễ nhưng tự tìm tòi xuyên qua việc nghiên cứu, thử nghiệm để rồi viết code exploit không dễ tí nào. Những điều mình bàn bây giờ thật ra cũng còn đơn giản đó. Đi đến mức độ exploit một dịch vụ bằng shellcode để chiếm chủ quyền chẳng hạn thì còn phức tạp hơn rất nhiều. Bởi thế, 'hack' không phải là dùng code của người khác để mà chạy rồi xem kết quả mà 'hack' là một quá trình tìm tòi, nghiên cứu, thử nghiệm dai dẳng."

'docco' xen vào: 
"Em muốn hỏi là mỗi script dùng để exploit thường hướng về một phiên bản nào đó của software mà mình muốn exploit thôi phải không anh? Em hỏi câu này là vì em liên tưởng đến vấn đề footprint mà mình đã 'đà khía' trước đây." 

Tôi đáp: 
"Hay lắm, em liên hệ đến footprint và phiên bản có nghĩa là em đã thấm cái gọi là 'giềng mối' rồi đó ). Đúng vậy. Hầu hết các exploit đều nhắm vào một phiên bản hoặc vài phiên bản gần nhau mà thôi bởi vì phiên bản cách xa thì code đã (hoặc chưa) thay đổi và bị dính những cái lỗi đáng bị exploit kia. Nếu em soi kỹ mấy cái exploit scripts / tools, em sẽ thấy rằng, càng nhiều test được thực hiện trong đó, giá trị và cơ hội thành công của chúng càng cao. Lý do là vì chúng loại bỏ những trường hợp không thích hợp và thoát ra nếu thấy kết quả test không thoả mãn đòi hỏi exploit. Điểm lý thú có thể học từ các scripts / tools đó là cách tư duy và cách kết nối, ứng dụng thông tin tìm được từ RFC, từ tài liệu kỹ thuật cụ thể của software đó vào khung exploit." 

'docco' gật gù: 
"Thật tình em chưa bao giờ hình dung những thứ bé nhỏ như mấy cái directive của Apache, mấy cái HTTP header của HTTP mà có thể dẫn đến những tìm tòi, exploit phức tạp và công phu đến thế." 

Tôi đáp: 
"Ừa, và chính vì vậy mà 'hacking' thật sự mới lý thú. Những thứ dường như bé nhỏ, vụn vặt nhưng chúng đều có vai trò riêng. Bất cứ sụp đổ của mỗi điểm 'vụn vặt' đó đều có thể dẫn đến sự sụp đổ trọn bộ của một cơ chế. Nếu phản chiếu giữa hai phía bảo mật và tấn công, em sẽ thấy rằng: cùng một điểm 'vụn vặt' người chống đỡ, kẻ tấn công khai thác cho mục đích khác nhau. Theo anh, diểm lý thú nằm trên con đường tìm tòi và ứng dụng những điều đã được tìm thấy thay vì dùng ứng dụng để thấy kết quả nếu như em muốn trở thành dân bảo mật." 

Nhìn đồng hồ, thấy đã đến giờ phải đi. Tôi chào bộ ba: 
"Thôi, anh phải đi công chuyện. Mấy đứa có rảnh và thích thì hãy tìm hiểu về những cái 'xem chừng như vụn vặt' kia nha. Có gì mình liên lạc sau." 

27/08/2007 
<còn tiếp> 


Chú thích: 
-2- 'gi' là cách nói tắt của Gigabyte. 

-3- các shell trên UNIX là phương tiện để thao tác trực tiếp với hệ thống và kernel của hệ thống. Những shell thường thấy là bash, c và bourne. 

-4- lứa tuổi mười mấy, lấy từ chữ 'teen' trong tiếng Anh (từ thirteen là 13 đến nineteen là 19).