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ế
Trang 1Lờ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
Trang 2
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
Trang 3độ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
Trang 42 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
Trang 54 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
Trang 6phả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