Hacking Security Sites part 18 potx

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 ở:
/> (cho Apache 1.3.x)
và
/> (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 ở:
/> (cho Apache 1.3.x)
và
/> (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.
