Article:
Đối thoại với Rookie - Phần bảy: Hai mặt của vấn đề - nhu cầu cụ thể
720
Chưa phân loại
 |
phananhvu.myopenid.com  125Over 4 years ago |
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.
[..] 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."
[..] 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."
[..] 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.
[..] Nhu cầu cụ thể là một yếu tố quan trọng để hình thành việc bảo mật
Xin xem phần mục lục của series này ở bài giới thiệu.
"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 suấ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 suấ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õ:
$ ssh myserver
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
