Lời bàn và mở rộng: Configuration trên của Artur Maj triển khai theo lối "blank paper", có nghĩa là bắt đầu từ trang giấy trắng. Ðây là lối khai triển rất hay cho các config đòi hỏi tính bảo mật cao. Lý do: dùng config mặc định có sẵn của Apache sẽ có nhiều cơ hội thiếu sót những điểm quan trọng vì config mặc định của Apache chứa quá nhiều thông tin, mở cửa cho quá nhiều thứ có thể tạo lỗ hổng. Ðiều đáng nêu ra là configuration này rấ t gọn gàng và khoa học cho các phần của cấu hình. Khi cần phải thêm bớt và thay đổi, một cấu hình gọn gàng giúp cho vấn đề quản lý dễ dàng và chính xác hơn, tất nhiên cũng sẽ giảm thiểu những lỗi (ít khi nhận thấy được) trong quá trình chỉnh định. Một điểm quan trọng khác cũng nên nhắc đến là các chi tiết về "Directives" tác giả bài viết đề cập trong phần giải thích. Tác giả đã không khai triển và giả i thích chi tiết tác dụng của các "directives" này, có lẽ, ông ta giả định người dùng ở mức độ quan tâm đến bảo mật cho Apache hẳn phải nắm vững cơ chế làm việc của Apache và những "directives" dùng trong configuration của Apache. Ở điểm này, cá nhân tôi cho rằng việc tham khảo và nghiên cứu kỹ lưỡng các "directives" dùng trong Apache là một việc tối cần thiết nếu muốn bảo đảm hoạt tính và mật tính của Apache. Bạn có thể tham khảo chi ti ết các "directives" trên website của Apache ở: http://httpd.apache.org/docs/mod/directives.html (cho Apache 1.3.x) và http://httpd.apache.org/docs-2.0/mod/quickreference.html (cho Apache 2.x) Ứng dụng các directives trong cấu hình của Apache một cách khoa học và thích hợp với nhu cầu là một điều không đơn giản. Việc đầu tiên giúp cho quá trình ứng dụng này là tạo cho mình một thói quen chuẩn bị cẩn thận và chính xác những phần tố cần dùng. Nếu bạn đã quen cách chỉnh định một server cho "nhanh" và có để "chạy liền" thì nên điều chỉnh lại thói quen này một khi đã dấn thân vào những điều thuộc về bảo mật. Apache cũng cung cấp một số tài liệu cho vấn đề kiện toàn bảo mật cho Apache server, bạn nên tham khảo thêm ở: http://httpd.apache.org/docs/misc/security_tips.html (cho Apache 1.3.x) và http://httpd.apache.org/docs-2.0/misc/security_tips.html (cho Apache 2.x) Hai tài liệu trên gần giống nhau, tuy nhiên có những tiểu tiết quan trọng cần tham khảo kỹ lưỡng. Bước cuối Cuối cùng chúng ta nên tạo một đoạn "script" khởi động "apache.sh" với nội dung tương tự như sau: Code: #!/bin/sh CHROOT=/chroot/httpd/ HTTPD=/usr/local/apache/bin/httpd PIDFILE=/usr/local/apache/logs/httpd.pid echo -n " apache" case "$1" in start) /usr/sbin/chroot $CHROOT $HTTPD ;; stop) kill `cat ${CHROOT}/${PIDFILE}` ;; *) echo "" echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 Ðoạn script trên nên được đưa vào đúng thư mục (tùy hệ thống UNIX nào), nơi các script khởi động mặc định được cất giữ. Trong trường hợp dùng FreeBSD, script này nằm ở thư mục /usr/local/etc/rc.d Lời bàn và mở rộng: Ðối với những ai quen dùng *nix, đoạn script trên có lẽ rất đơn giản và dễ hiểu. Ðiều đáng đề cập ở đ ây là một cái script đơn giản nhưng lại quan trọng vì nó "ép" Apache khởi động trong môi trường "jail", dùng binary và tạo log thuộc môi trường "jail" này. Trên Linux và một số system V thì "startup script" này nên đặt trong /etc/rc.d/init.d (hoặc /etc/init.d) và tạo symbolic link vào đúng "run level", bạn có thể tham khảo thêm chi tiết tùy loại *nix nào đang dùng. Tất nhiên bạn có thể điều chỉnh tùy thích "startup script" này nhưng điều quan trọng là phải nắm vững tinh thần "jail" được nêu ra ở trên. Tổng kết Các phương pháp trên cho phép t ạo nên mức bảo mật chặt chẽ hơn cho Apache so với cấu hình mặc định có sẵn sau khi cài đặt. Bằng phương pháp chỉ cho phép những modules tuyệt đối cần thiết cho Apache hoạt động, server của chúng ta không hẳn bị nhân nhượng khi một yếu điểm nào đó bị khám phá trong nhóm các modules của Apache. Dấu version number của Apache, "chrooting" và hạn chế cấu hình của Apache làm cho các trường hợp đột phá đến server trở nên rất khó khăn. Một môi trường "chrooted" còn có thêm một ưu điểm quan trọng - miễn nhiễm đến số lớn các loại tấn công, lý do chính là vì thiếu "shell" (/bin/sh, /bin/csh vâng vâng ). Ngay cả nếu tin tặc thao tác thành công các lệnh trên hệ thống, nhưng để thoát ra kh ỏi môi trường "chroot" là vấn đề không đơn giản. Lời bàn và mở rộng: Ngoài những điểm Artur Maj tổng kết ở trên, có lẽ điều cần mở rộng vài vấn đề bên ngoài phạm vi Apache. Trên thực tế, việc kiện toàn chính Apache phải đi song song với việc kiện toàn trọn bộ server mà Apache chạy. Nếu tin tặc không tấn công và đột nhập được qua môi trường "chrooted" của Apache, vẫn có thể đột nhậ p qua ngõ khác nếu server chạy Apache không được kiện toàn. Cực đoan hơn, cho dù Apache server được một firewall bảo vệ vẫn không thể phó mặc cho firewall mà lơ là chuyện kiện toàn server mà Apache chạy. Kiện toàn bảo mật đúng nghĩa là một công tác đòi hỏi một cách nhìn tổng quát cho trọn bộ môi trường hoạt động. Trước khi kết thúc, tôi xin nhấn mạnh một điều quan trọng cho vấn đề bảo mật nói chung đó là: luôn luôn theo dõi, cập nh ật software và thường xuyên kiểm soát cấu hình cũng như hoạt động của server. Không có software nào không có bugs và yếu điểm. Cho nên, việc theo dõi và bảo trì là một công tác hàng đầu trong vấn đề bảo mật. Kiện toàn bảo mật không thích hợp với tư duy "set and forget" (chỉnh lý rồi phó mặc). Kiện toàn bảo mật có lẽ cũng không nên theo tư duy theo kiểu "marketing hype" (quảng cáo sản phẩm một cách quá đáng ) ví dụ như "keep intruders at bay" hoặc "unbreakable systems" Ðiều chắc chắn b ạn có thể thực hiện là làm chậm bước tấn công và đột phá của tin tặc để có thể đối phó kịp thời. Mọi góp ý xin gởi lên Diễn Đàn Tin Học - VNInformatics. Hẹn gặp lại các bạn! 1. Đặt vấn đề Bảo mật hệ thống *nix với PAM (linet) Chắc hẳn bạn đã từng tự hỏi tại sao các chương trình ftp, su, login, passwd, sshd, rlogin … lại có thể hiểu và làm việc v ới shadow password; hay tại sao các chương trình su, rlogin lại đòi hòi password; tại sao một số hệ thống chỉ cho một nhóm nào đó có quyền su, hay sudo, hay hệ thống chỉ cho phép một số người dùng, nhóm người dùng đến từ các host xác định và các thiết lập giới hạn cho những người dùng đó, …Tất cả đều có thể lý giải với PAM. Ứng dụng của PAM còn nhiều hơn những gì tôi vừa nêu nhiều, và nó bao gồm các module để tiện cho ng ười quản trị lựa chọn. 2. Cấu trúc PAM - Các ứng dụng PAM được thiết lập trong thư mục /etc/pam.d hay trong file /etc/pam.conf ( login, passwd, sshd, vsftp, …) - Thư viện các module được lưu trong /lib/security ( pam_chroot.so, pam_access.so, pam_rootok.so, pam_deny.so, … ) - Các file cấu hình được lưu trong /etc/security ( access.conf, chroot.conf, group.conf ,… ) + access.conf – Điều khiển quyền truy cập, được sử dụng cho thư viện pam_access.so. + group.conf – Điểu khiển nhóm người dùng, sử dụng bởi pam_group.so + limits.conf – thiết lập các giới hạn tài nguyên hệ thống, được sử dụng bởi pam_limits.so. + pam_env – Điểu khi ển khả năng thay đổi các biến môi trường, sử dụng cho thư viện pam_env.so . + time – Thiết lập hạn chế thời gian cho dịch vụ và quyền người dùng, sử dụng cho thư viện pam_time.so. 3. Cách hoạt động của PAM Thuật ngữ - Các chương trình login, pass, su, sudo, … trên được gọi là privilege-granting application ( chương trình trao đặc quyền ). - PAM-aware application: là chương trình giúp các privile-granting application làm việc với thư viện PAM. Các bước hoạt động: 1. Ng ười dùng chạy một ứng dụng để truy cập vào dịch vụ mong muốn, vd login. 2. PAM-aware application gọi thư viện PAM để thực hiện nhiệm vụ xác thực. 3. PAM library sẽ dựa vào file cấu hình của chương trình đó trong /etc/pam.d ( vd ở đây là login -> file cấu hình /etc/pam.d/login ) xác định loại xác thực nào được yêu cầu cho chương trình trên. Trong trường hợp không có file cấu hình, thì file /etc/pam.d/other sẽ được sử dụng. 4. PAM library sẽ load các module yêu cầu cho xác thực trên. 5. Các modules này sẽ tạo một liên kế t tới các hàm chuyển đổi ( conversation functions ) trên chương trình. 6. Các hàm này dựa vào các modules mà đưa ra các yêu cầu với người dùng, vd chúng yêu cầu người dùng nhập password. 7. Người dùng nhập thông tin vào theo yêu cầu. 8. Sau khi quá trình xác thực kết thúc, chương trình này sẽ dựa vào kết quả mà đáp ứng yêu cầu người dùng ( vd cho phép login vào hệ thống ) hay thông báo thất bại với người dùng. 4. Bây giờ chúng ta sẽ nghiên cứu file config The /etc/pam.d/rlogin file #%PAM-1.0 auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth Các dòng trong file config có dạng sau: module-type control-flag module-path module-args MODULE TYPE auth: thực hiện xác thực. Thông thường, một auth module sẽ yêu cầu password để kiểm tra, hay thiết lập các định danh như nhóm người dùng, hay thẻ kerberos. Account điều khiển sự kiểm tra “bề mặt” với yêu cầu xác thực. Ví dụ, nó có thể kiểm tra người dùng truy c ập dịch vụ từ một host và trong thời gian cho phép hay không. Password: thiết lập password. Thông thường, nó luôn có sự tương ứng giữa một module auth và một module password Session: điều khiển các nhiệm vụ quản lý session. Được sử dụng để đảm bảo rằng người dùng sử dụng tài khoản của họ khi đã được xác thực PAM MODULE CONTROL FLAGS Require: cờ điều khiển này nói với PAM library yêu cầu sự thành công của modules t ương ứng, vd “auth required /lib/security/pam_securetty.so” à module pam_securetty.so phải thành công. Nếu module đó không được thực hiện thành công thì quá trình xác thực thất bại. Nhưng lúc đó, PAM vẫn tiếp tục với các module khác, tuy nhiên nó chỉ có tác dụng nhằm tránh khỏi việc người dùng có thể đoán được quá trình này đã bị thất bại ở giai đoạn nào. . auth required /lib /security/ pam_securetty.so auth sufficient /lib /security/ pam_rhosts_auth.so auth required /lib /security/ pam_stack.so service=system-auth auth required /lib /security/ pam_nologin.so. /lib /security/ pam_nologin.so account required /lib /security/ pam_stack.so service=system-auth password required /lib /security/ pam_stack.so service=system-auth session required /lib /security/ pam_stack.so service=system-auth. nên tham khảo thêm ở: http://httpd.apache.org/docs/misc /security_ tips.html (cho Apache 1.3.x) và http://httpd.apache.org/docs-2.0/misc /security_ tips.html (cho Apache 2.x) Hai tài liệu trên