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>
Những cuộc đối thoại với rookie - Phần 7
4/
5
Oleh
Unknown
