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:



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:



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:



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



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