Thứ Hai, 5 tháng 11, 2012
Những cuộc đối thoại với rookie - Phần 8
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
<còn tiếp> Đọc Thêm
Những cuộc đối thoại với rookie - Phần 7
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ất hợ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
<còn tiếp>
Đọc Thêm
Những cuộc đối thoại với rookie - Phần 6
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
<còn tiếp>
Đọc Thêm
Đăng ký:
Bài đăng (Atom)