Breaking News
Loading...
Thứ Hai, 14 tháng 1, 2013

Info Post
9. "Hai mặt" của vấn đề - cơ chế làm việc:
Không ngoài dự phỏng, tôi liên tục nhận mail từ bộ ba Khoa, Duy, Hưng. Một lần nữa, tôi cố trả lời hầu hết các e-mail từ bộ ba này bằng thông điệp ngắn gọn:

"Em nghĩ điều em thắc mắc là 'what' hay là 'why'? Anh nghĩ nó là 'what' chớ chẳng phải là 'why' cho nên em nên xem sách đi rồi hỏi anh cái 'why' :)"

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

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

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

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

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

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

Thân,
Khoa."

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

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

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

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

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

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

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

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

Thân."

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

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

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

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

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

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

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

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

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

Em chào anh.

Duy."

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

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

Thân."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. nói về chuyện điều chỉnh sshd_config, hãy xem thử cấu hình chung chung như sau:
Code:
 Port 22
 ListenAddress 203.210.205.200
 HostKey /etc/ssh/ssh_host_key
 HostKey /etc/ssh/ssh_host_dsa_key
 HostKey /etc/ssh/ssh_host_rsa_key
 ServerKeyBits 768
 LoginGraceTime 60
 KeyRegenerationInterval 3600
 PermitRootLogin yes
 IgnoreRhosts no
 IgnoreUserKnownHosts yes
 StrictModes no
 X11Forwarding yes
 PrintMotd yes
 KeepAlive yes
 SyslogFacility AUTH
 LogLevel INFO
 RhostsAuthentication yes
 RhostsRSAAuthentication yes
 RSAAuthentication yes
 PasswordAuthentication yes
 PermitEmptyPasswords yes
 Subsystem sftp /usr/libexec/openssh/sftp-server
 


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

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

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

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

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

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

Tôi đáp:
"Được chớ em. Hãy thử 'đào xới' giá trị thứ nhất Port 22. Ai cũng biết đây là cổng chính thức của dịch vụ ssh. Nếu muốn táy máy, anh chỉ cần thử một dòng nmap đã đủ có thể xác định xem có dịch vụ ssh trên máy chủ hay không rồi:
Code:
 [conmeo@home conmale]# /usr/local/bin/nmap -sT someserver.somedomain.com -p 22 -v
 
 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:04 EST
 Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:04
 Discovered open port 22/tcp on xx.xx.xx.xx
 The Connect() Scan took 0.23s to scan 1 total ports.
 Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
 Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
 PORT      STATE SERVICE
 22/tcp open  SSH
 Nmap finished: 1 IP address (1 host up) scanned in 1.464 seconds
                Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
 


Nếu cần, anh có thể thêm một thông số để xác định phiên bản của ssh:
Code:
 [conmeo@home conmale]# /usr/local/bin/nmap -sT -sV someserver.somedomain.com -p 22 -v
 
 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:03 EST
 Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:03
 Discovered open port 64321/tcp on xx.xx.xx.xx
 The Connect() Scan took 0.23s to scan 1 total ports.
 Initiating service scan against 1 service on someserver.somedomain.com (xx.xx.xx.xx) at 17:03
 The service scan took 0.47s to scan 1 service on 1 host.
 Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
 Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
 PORT      STATE SERVICE VERSION
 22/tcp open  ssh     OpenSSH 3.5p1 (protocol 2.0)
 
 Nmap finished: 1 IP address (1 host up) scanned in 2.481 seconds
                Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
 


Hoặc đơn giản hơn nữa:
Code:
 $ telnet someserver.somedomain.com 22
 Trying someserver.
Comments
0 Comments
Facebook Comments by Ho Duc Tin

0 nhận xét:

Đăng nhận xét