Bảo Mật Cho Apache Toàn Tập

Trước khi bắt đầu kiện toàn bảo mật Apache, chúng ta phải xác định rõ chức năng cần thiết nào của server sẽ được xử dụng. Tính đa năng của Apache tạo ra những khó khăn để thực hiện một mô thức tổng quát với mục đích kiện toàn bảo mật cho server trong mọi trường hợp có thể được. Ðây là lý do tài liệu này dựa trên các chức năng sau:

* Web server có thể truy cập từ Internet; và,
* Chỉ những trang HTML tĩnh (static HTML pages) sẽ được phục vụ,
* Server hỗ trợ tên miền cho cơ chế dịch vụ ảo,
* Các trang web đã ấn định chỉ có thể truy cập từ các cụm IP addresses hoặc người dùng (khai báo căn bản),
* Server sẽ tường trình trọn bộ các thỉnh cầu (bao gồm những thông tin về các web browsers).

Ðiều đáng nhấn mạnh ở đây là mô hình trên không hỗ trợ PHP, JSP, CGI hoặc bất cứ công nghệ nào khác có thể tạo cơ hội tương tác đến các dịch vụ Web. Ứng dụng cho những công nghệ trên có thể dẫn đến những đe dọa to lớn cho vấn đề bảo mật, dù chỉ là một đoạn script nhỏ, kín đáo cũng có thể giảm thiểu mức triệt để bảo mật của server. Tại sao? trước hết, các ứng trình ASP/CGI có thể chứa những yếu điểm bảo mật (ví dụ SQL injection, cross-site-scripting). Kế tiếp, chính các kỹ nghệ ấy có thể nguy hiểm (các yếu điểm trong PHP, các module của Perl v..v..). Ðó là lý do tại sao tôi mạnh mẽ đề nghị xử dụng những công nghệ ấy chỉ khi nào nhu cầu tương tác với một web site hoàn toàn cần thiết mà thôi.

Lời bàn và mở rộng:
Việc kiện toàn bảo mật cho một web server liên quan đến nhiều thủ thuật ở nhiều mức độ khác nhau. Tác giả chuộng nguyên tắc "tối thiểu" để giảm thiểu những lỗ hổng bảo mật có thể hiện diện trên một web server. Lý thuyết mà nói, nguyên tắc này đưa đến những ứng dụng và chỉnh định chặt chẽ hơn cho vấn đề bảo mật. Tuy nhiên, hoạt tính và nhu cầu làm việc của một web server không thể dừng lại ở khuôn khổ "tối thiểu" và bị áp đặt trong giới hạn các trang static HTML được. Thiết kế một chương trình làm việc cho web với yêu cầu đa năng và đa hoạt là một trong những yêu cầu hàng đầu. Một web site chỉ chuyên chú ở khuôn khổ các trang static HTML không những giới hạn tính năng của các trang web này một cách đáng kể, mà còn sa lầy trên mặt thực dụng và giá trị kinh tế lẫn giá thành xây dựng và bảo trì cho website. Giải pháp tối ưu có lẽ là sự cân bằng giữa kiến thức kiện toàn bảo mật cho web server cộng với khả năng thiết kế web một cách khoa học và vững chãi về mặt tính năng, hoạt động lẫn mặt giảm thiểu lỗi thiết kế, lỗi lập trình.

Một trong những hạn chế hay đúng hơn là lối mòn thường gặp trong các thiết kế ứng dụng web là việc pha trộn lẫn lộn các phân đoạn làm việc với nhau. Nói một cách khác, các thiết kế gia và các lập trình viên không đầu tư đủ thời gian để nghiên cứu, phân tích và áp dụng các mẫu thiết kế hợp lý cho công trình của mình mà thường đi thẳng vào bước thực hiện. Các bước "đi thẳng" thường thiếu độ chín chắn trong bước thiết kế, dẫn đến tính năng hạn hẹp và mở cửa cho các lỗi bảo mật nghiêm trọng. Trên thực tế, sự khác biệt giữa việc làm cho một web site chạy được và làm cho một web site chạy được, chạy có hiệu xuất, có khả năng mở rộng và bảo đảm mật tính là chuyện khác nhau một trời một vực. Thói quen "xào nấu" các lệnh điều tác cho một hệ điều hành hoặc các lệnh tương tác đến database trực tiếp từ một trang html trần trụi, nhúng các lệnh điều tác vào php, jsp, asp... là chuyện rất thường gặp. Ðây là một ví dụ điển hình cho cái gọi là "chạy được nhưng thiếu hiệu xuất, thiếu khả năng mở rộng và mở cửa cho các lỗi bảo mật quan trọng".

Vì khuôn khổ bài viết không tiện đi sâu vào các mẫu thiết kế cho những ứng dụng web, các bạn nên nghiên cứu thêm về những thiết kế này ở một số url sau tùy theo công nghệ bạn đang dùng:
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
http://www.enode.com/x/markup/tutorial/mvc.html
http://www.phppatterns.com/index.php/article/articleview/19/1/1/
http://www.dmbcllc.com/asp_mvc.aspx
http://www.jdance.com/jsparchitecture.shtm
http://www.redbooks.ibm.com/abstracts/sg245755.html
http://www.redbooks.ibm.com/abstracts/sg245754.html
Bạn có thể dùng google để search thêm các tài liệu về MVC với keyword: "MVC Pattern" hoặc tham khảo một số tài liệu chuyên ngành từ các website lớn như http://java.sun.comhoặc http://www.ibm.com.

Những trù bị bảo mật
Một trong những nhân tố quan trọng nhất cho mọi công trình điện toán là việc xác thực các trù bị bảo mật. Ðiều này phải được thoả mãn trước khi công trình được ứng tạo. Các trù bị bảo mật cho web server của chúng ta như sau:

* Hệ điều hành phải được kiện toàn càng chặt chẽ càng tốt, bao gồm việc phòng bị cho những tấn công từ bên ngoài lẫn bên trong,
* Server không được cung cấp bất cứ dịch vụ nào khác ngoại trừ HTTP: (80/TCP),
*
Truy cập từ xa đến server phải được khiển tác bởi tường lửa, thiết bị này chặn trọn bộ những tiếp nối cho lối ra và cho phép những tiếp nối cho lối vào đến cổng 80/TCP của web server mà thôi,
*
Web server Apache là dịch vụ duy nhất hiện hữu trên hệ thống,
*
Chỉ có những modules nào tuyệt đối cần thiết mới được cho phép hoạt động,
*
Các trang web dùng cho công tác chẩn xét và tự động hoá mục lục phải được tắt bỏ,
*
Srver nên giảm thiểu tối đa vấn đề tiết lộ những thông tin của chính server (mật tính qua ẩn tính),
*
Apache server phải chạy bằng UID/GID riêng biệt (tín chỉ cá nhân, tín chỉ nhóm), không được dùng bất cứ process nào khác của hệ thống,
*
Các process của Apache phải có giới hạn nhất định đến hệ thư mục (chrooting); và,
*
Không có bất cứ chương trình dạng shell nào hiện hữu trong môi trường chrooted (/bin/sh, /bin/csh, v..v..).

Lời bàn và mở rộng:
Một lần nữa tác giả đẩy mạnh tính "tối thiểu". Tuy nhiên, điểm khác biệt trong tính "tối thiểu" ở phần này thuộc bình diện môi trường hơn là giảm thiểu hoạt tính của web server Apache.

Bước kiện toàn bằng cách chỉ cho phép port 80/TCP trên server chạy Apache là thao tác căn bản cần phải làm vì nếu tấn công, tin tặc chỉ có một cổng để tấn công và để phòng thủ, người bảo vệ chỉ tập trung đến một cổng. Hơn thế, với cơ chế kiểm soát của tường lửa như tác giả đề nghị, tính bảo mật chắc chắn sẽ được nâng cao. Ở đây tác giả không đề cập một cách cụ thể loại tường lửa nào nên dùng vì quy trình chọn lựa, chỉnh định một tường lửa cho thích hợp phụ thuộc vào nhiều yếu tố khá phức tạp. Ðể mở rộng chi tiết này, tôi tin rằng sự hiện diện của một stateful firewall vừa có khả năng kiểm soát state ở tầng IP vừa có khả năng kiểm soát nội dung ở tầng application là cách tốt nhất. Nếu điều kiện tài chính cho phép, một stateful firewall như CheckPoint FW-1 hoặc Cisco PIX có thể đóng vai trò quan trọng này. Nếu điều kiện tài chính không cho phép, phương pháp tích hợp một số chương trình mở nguồn để đạt được khả năng tương tự vẫn có thể được, tuy nhiên sẽ mất nhiều nhân lực và thời gian hơn để điều chỉnh và thử nghiệm nếu chưa có nhiều kinh nghiệm trong lĩnh vực này.

Cài đặt hệ điều hành
Trước khi cài đặt Apache, chúng ta phải chọn lấy một hệ điều hành, đó là môi trường Apache sẽ hoạt động. Ở đây chúng ta có khá nhiều chọn lựa vì Apache có thể được biên dịch và cài đặt trên hầu hết các hệ điều hành. Phần còn lại của tài liệu này chỉ dẫn cách bảo mật Apache server trên nền FreeBSD (4.7), tuy nhiên các phương pháp được mô tả ở đây có thể ứng dụng trong hầu hết các hệ điều hành UNIX/LINUX. Chỉ có một hệ điều hành duy nhất tôi không giới thiệu là MS Windows - lý do chính là vì hệ điều hành này bị giới hạn khả năng kiện toàn bảo mật cho Apache.

Bước đầu tiên trong vấn đề bảo mật Web server là kiện toàn hệ điều hành. Các thảo luận kiện toàn hệ điều hành vượt quá khuôn khổ tài liệu này. Tuy vậy, có rất nhiều tài liệu trên Net miêu tả cách thực hiện vấn đề ấy. Ðộc giả được khuyến khích khai phá các vấn đề liên hệ đến phạm vi này.

Sau khi hệ thống được cài đặt và kiện toàn, chúng ta cần thêm một nhóm và một người dùng thông thường gọi là "apache" tương tự như thế này (một ví dụ từ FreeBDS):

pw groupadd apache
pw useradd apache -c "Apache Server" -d /dev/null -g apache -s /sbin/nologin

Theo mặc định, các process thuộc Apache chạy với chủ quyền của người dùng nobody (ngoại trừ process chính phải chạy với chủ quyền root) và GID thuộc nhóm nogroup. Ðiều này có thể dẫn đến những đe dọa bảo mật nghiêm trọng. Trong trường hợp đột nhập thành công, tin tặc có thể lấy được quyền truy dụng đến những process khác chạy cùng UID/GID. Bởi thế, giải pháp tối ưu là cho Apache chạy bằng UID/GID từ nhóm riêng biệt, chuyên chú đến software ấy thôi.

Lời bàn và mở rộng:
Ðối với những ai quen dùng *nix hẳn không lạ gì với khái niệm UID/GID thuộc chế độ "file permission". Tuy nhiên, chi tiết này nên mở rộng một tí cho những bạn đọc chưa quen thuộc với UID/GID. Phần tạo nhóm (group) và người dùng (user) riêng cho Apache ở trên có hai chi tiết cần chú ý là:
-d /dev/null: không cho phép user Apache có thư mục $HOME nhưng những user bình thường khác
-s /sbin/nologin: không cho user Apache dùng bất cứ một shell nào cả. Có một số trường hợp dùng -s /bin/true thay vì nologin ở trên, true là một lệnh không thực thi gì cả và hoàn toàn vô hại.

Lý do không cho phép user Apache có thư mục $HOME và không được cấp một "shell" nào cả vì nếu account Apache này bị nhân nhượng, tin tặc cũng không có cơ hội tiếp cận với system ở mức độ cần thiết cho thủ thuật gia tăng chủ quyền. Trên môi trường *nix nói chung, "shell" là giao diện giữa người dùng và hệ thống, không có shell thì không có cơ hội tiếp cận xa hơn.

Chuẩn bị software
Bước kế tiếp là bước tải phiên bản Apache mới nhất từ web site Apache http://httpd.apache.org). Chỉ có một số chọn lựa tiện ích được phép hoạt động trong quá trình biên dịch mà thôi, bởi thể, quyết định tải mã nguồn về biên dịch thay vì tải bản nhị phân (binary) là điều hết sức quan trọng.

Sau khi tải software về, chúng ta phải xả nén. Kế tiếp, chúng ta quyết định modules nào được phép hoạt động. Bản tường trình tổng quan về các modules hiện hữu cho phiên bản mới nhất của Apache 1.3.x (1.3.27 [1]) có ở:http://httpd.apache.org/docs/mod/

Những modules của Apache
Chọn lựa các modules là một trong những bước quan trọng nhất trong vấn đề bảo mật Apache. Chúng ta nên theo luật: càng ít càng tốt. Ðể thoả mãn chức năng và những trù bị bảo mật, các modules sau cần được cho phép:

Tên module
httpd_core: Chứa các chức năng cốt lõi của Apache, cần thiết cho bất cứ Apache nào.

mod_access: Cung cấp chế độ khiển tác dựa trên tên máy, địa chỉ IP, hoặc các tính chất yêu cầu thuộc về các clients. Bởi vì module này cần cho các chỉ phối (directive) "order", "allow" và "deny", nó cần được cho phép.

mod_auth: Cần thiết để ứng dụng vấn đề khai báo người dùng cho việc sử dụng các hồ sơ nguyên bản (khai báo căn bản cho HTTP), được chỉ định trong chức năng trù bị.

mod_dir: Cần thiết để tìm kiếm và phục vụ các hồ sơ thư mục: "index.html", "default.htm", v..v..

mod_log_config: Cần thiết để ứng hiệu báo cáo những yêu cầu thực hiện đến server.

mod_mime: Cần thiết để chỉnh lý nhóm chữ cái, mã hoá nội dung, tùy tác, ngôn ngữ nội dung và các loại MIME đại diện cho các loại tài liệu.

Tất cả các modules khác của Apache phải được tắt bỏ. Chúng ta có thể tắt bỏ chúng một cách an toàn bởi vì chúng ta không cần đến chúng. Do tắt bỏ những modules không cần thiết, chúng ta tránh được trường hợp có thể bị đột phá khi những yếu điểm bảo mật vừa được khám phá thuộc về một trong những modules này.

Cũng nên nhắc đến là có hai modules của Apache có thể nguy hiểm hơn các modules khác là: mod_autoindex và mod_info. Module thứ nhất cung cấp chức năng tự động sắp xếp thư mục và module này được phép chạy theo mặc định. Có thể dễ dàng dùng nó để xác định xem Apache được dùng trên một server nào đó hay không (ví dụ: http://server_name/icons/) và để lấy nội dung của các thư mục trên Web server dẫu không có các mục lục trong những thư mục này. Module thứ nhì, mod_info không nên cho phép truy cập từ Internet chính vì lý do nó tiết lộ cấu hình của Apache.

Câu hỏi kế tiếp là làm sao biên dịch các modules. Phương pháp tĩnh được xem là lựa chọn tốt hơn hết. Nếu những yếu điểm của Apache vừa được khám phá, có lẽ chúng ta sẽ không những tái biên dịch các modules bị lỗi mà sẽ tái biên dịch trọn bộ software. Chọn phương pháp tĩnh, chúng ta triệt tiêu nhu cầu của thêm một module nữa - mod_so.

Lời bàn và mở rộng:
Chọn lựa các modules cho Apache server thích hợp với từng nhu cầu là một việc khó khăn và mất thời gian. Chọn lựa đúng module và bảo đảm tính bảo mật lại càng khó khăn hơn. Ðể xác định module nào cần thiết và bảo đảm, việc chọn lựa và theo dõi "bug track" cho từng module là một điều rất cần thiết. Hiện nay có trên 200 modules lớn nhỏ, đủ loại chức năng cho Apache server. Bạn nên tham khảo thông tin ở website này cho công tác lựa chọn:http://modules.apache.org/

Website trên có sẵn search engine giúp bạn trong việc khảo sát và lựa chọn modules.

Biên dịch software
Trước tiên - nếu có bất cứ miếng vá (patch) nào cho bảo mật thì phải thực hiện ngay. Sau đó, server được biên dịch và cài đặt như sau:

./configure --prefix=/usr/local/apache --disable-module=all --server-uid=apache --server-gid=apache --enable-module=access --enable-module=log_config --enable-module=dir --enable-module=mime --enable-module=auth

(lệnh trên trải dài trong 1 dòng, không tách rời ra thành nhiều dòng)

make 
su 
umask 022 
make install 
chown -R root:sys /usr/local/apache 

Lời bàn và mở rộng:
Ðối với các bạn chưa làm quen hoặc chỉ mới bắt đầu làm quen đến *nix, khái niệm biên dịch software có lẽ khá mới mẻ và lạ lẫm. Tuy nhiên, cảm giác này chỉ ở bước đầu trong quá trình làm quen mà thôi. Hầu như các bước trong phân đoạn "biên dịch software" cho các software khác nhau đều tương tự như nhau.

Ðiều lý thú trong vấn đề "biên dịch software" trên phương diện bảo mật ở đây, ngoài cơ hội có thể xem mã nguồn, tìm lỗi, tìm lổ hổng từ mã nguồn, bạn còn có cơ hội thiết lập và biên dịch software mình cần theo ý muốn. Trong đoạn lệnh ./configure ở trên minh hoạ cụ thể tính "tự do" ở chỗ bạn có toàn quyền muốn thêm hoặc bớt module tùy thích. Tính linh động trong vấn đề biên dịch software và tính đóng kín khi dùng một "installshield" trở nên hiển nhiên khi đem ra so sánh. Khi bạn phải cài một software gồm các binaries đã được biên dịch (theo khuôn khổ nào đó) sẵn, bạn không có nhiều cơ hội quyết định hoặc chọn lựa theo ý muốn nữa. Ðây là một trong những nguyên tắc khá quan trọng cho những ai quan tâm hoặc làm việc trực tiếp đến vấn đề bảo mật.

Ðổi "root" của server
Bước kế tiếp giới hạn các process của Apache truy dụng vào các hệ thống hồ sơ. Chúng ta có thể thực hiện vấn đề này bằng cách "chrooting" phần daemon chính của server (httpd). Tổng thể mà nói, thủ thuật "chrooting" có nghĩa là tạo một cấu trúc nguồn thư mục mới, dời chuyển các hồ sơ daemon vào đó và chạy các daemon thích ứng trong môi trường mới này. Nhờ vào đó, daemon (và cái process con) chỉ sẽ truy dụng đến cấu trúc thư mục mới.

Chúng ta bắt đầu chu trình này bằng cách tạo ra một thư mục mới bên trong thư mục /chroot/httpd:

mkdir -p /chroot/httpd/dev 
mkdir -p /chroot/httpd/etc 
mkdir -p /chroot/httpd/var/run 
mkdir -p /chroot/httpd/usr/lib 
mkdir -p /chroot/httpd/usr/libexec 
mkdir -p /chroot/httpd/usr/local/apache/bin 
mkdir -p /chroot/httpd/usr/local/apache/logs 
mkdir -p /chroot/httpd/usr/local/apache/conf 
mkdir -p /chroot/httpd/www

Chủ nhân của các thư mục trên phải là root và quyền truy dụng nên chỉnh lý ở mức 0755. Kế tiếp, chúng ta tạo hồ sơ thiết bị đặc biệt /dev/null:

ls -al /dev/null 
(crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null) 
mknod /chroot/httpd/dev/null c 2 2 
chown root:sys /chroot/httpd/dev/null 
chmod 666 /chroot/httpd/dev/null

Một phương pháp khác cần dùng để tạo thiết bị /chroot/httpd/dev/log, thiết bị này cần thiết để server làm việc đúng mức. Trong trường hợp hệ thống FreeBSD, cần thêm dòng sau đây vào /etc/rc.conf:

syslogd_flags="-l /chroot/httpd/dev/log" 

Chúng ta phải tái khởi động hệ thống hoặc chính syslogd daemon để ứng tác các thay đổi. Ðể tạo thiết bị /chroot/httpd/dev/log trên các hệ điều hành khác, chúng ta phải xem các phần chỉ dẫn thích đáng (man syslogd).

Bước kế tiếp là bước sao chép chương trình httpd chính vào cấu trúc cây mới tạo ở trên, bao gồm các hồ sơ nhị phân và các thư viện cần thiết. Ðể thực hiện bước này, chúng ta phải chuẩn bị danh sách của các hồ sơ cần thiết. Chúng ta có thể tạo nên danh sách ấy bằng cách sử dụng lệnh như sau (tùy theo mỗi hệ điều hành mà các hồ sơ này hiện diện hay không):

ldd (All): lists dynamic dependencies of executable files or shared libraries
ktrace/ktruss/kdump (*BSD): Enables kernel process tracing, Displays kernel trace data
sotruss (Solaris): Traces shared library procedure calls
strace/ltrace (Linux): Traces system calls and signals
strings (All): Finds the printable strings in binary files
trace (AIX): Records selected system events
trace (freeware) (HP-UX <10.20): Print system call and kernal traces of processes
truss (FreeBSD, Solaris, AIX 5L, SCO Unixware): Traces system calls and signals
tusc (freeware) (HP-UX>11): Traces the system calls a process invokes in HP-UX 11

Ví dụ dùng các lệnh ldd, strings và truss như sau:

localhost# ldd /usr/local/apache/bin/httpd 
/usr/local/apache/bin/httpd: 
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280bd000) 
libc.so.4 => /usr/lib/libc.so.4 (0x280d6000) 

localhost# strings /usr/local/apache/bin/httpd | grep lib 
/usr/libexec/ld-elf.so.1 
libcrypt.so.2 
libc.so.4 

localhost# truss /usr/local/apache/bin/httpd | grep open 
(...) 
open("/var/run/ld-elf.so.hints",0,00) = 3 (0x3) 
open("/usr/lib/libcrypt.so.2",0,027757775370) = 3 (0x3) 
open("/usr/lib/libc.so.4",0,027757775370) = 3 (0x3) 
open("/etc/spwd.db",0,00) = 3 (0x3) 
open("/etc/group",0,0666) = 3 (0x3) 
open("/usr/local/apache/conf/httpd.conf",0,0666) = 3 (0x3) 
(...)

Các lệnh trên nên được áp dụng không cho chương trình httpd mà còn cho trọn bộ các thư viện và các nhị phân cần thiết (các thư viện thường đòi hỏi các thư viện khác). Ðối với trường hợp hệ thống FreeBSD, các hồ sau cần được sao chép vào cấu trúc thư mục mới:

cp /usr/local/apache/bin/httpd /chroot/httpd/usr/local/apache/bin/ 
cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/ 
cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/ 
cp /usr/lib/libc.so.4 /chroot/httpd/usr/lib/ 
cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/

Bằng cách sử dụng lệnh truss, chúng ta cũng có thể khám phá được các hồ sơ chỉnh dụng sau cần được hiện diện trong môi trường chrooted:

cp /etc/hosts /chroot/httpd/etc/ 
cp /etc/host.conf /chroot/httpd/etc/ 
cp /etc/resolv.conf /chroot/httpd/etc/ 
cp /etc/group /chroot/httpd/etc/ 
cp /etc/master.passwd /chroot/httpd/etc/passwords 
cp /usr/local/apache/conf/mime.types /chroot/httpd/usr/local/apache/conf/

Nên nhớ rằng từ hồ sơ /chroot/httpd/etc/passwords, chúng ta phải tháo bỏ hết các dòng ngoại trừ "nobody" và "apache". Tương tự, chúng ta cũng phải tháo bỏ hết các dòng ngoại trừ "nobody" và "apache" trong /chroot/httpd/etc/group. Kế tiếp chúng ta phải dựng database cho mật mã như sau:

cd /chroot/httpd/etc 
pwd_mkdb -d /chroot/httpd/etc passwords 
rm -rf /chroot/httpd/etc/master.passwd

Bước kế tiếp dùng để thử nghiệm httpd server xem nó chạy đúng mức trong môi trường chroot mới. Ðể thao tác vấn đề này, chúng ta phải sao chép hồ sơ chỉnh dụng mặc định của Apache và bản mẫu index.html:

cp /usr/local/apache/conf/httpd.conf /chroot/httpd/usr/local/apache/conf/ 
cp /usr/local/apache/htdocs/index.html.en /chroot/httpd/www/index.html 

Sau khi sao chép các hồ sơ đề cập trên, chúng ta phải thay đổi chỉ phối DocumentRoot như được trình bày bên dưới (trong /chroot/httpd/usr/local/apache/conf/httpd.conf):

DocumentRoot "/www" 

Tiếp theo chúng ta có thể thử chạy server:

chroot /chroot/httpd /usr/local/apache/bin/httpd 

Nếu có trở ngại gì, tôi đề nghị phương thức phân tích log của Apache một cách sâu sát (/chroot/httpd/usr/local/apache/logs). Một cách khác là dùng lệnh sau:

truss chroot /chroot/httpd /usr/local/apache/bin/httpd 

Chương trình truss chắc chắn sẽ chỉ ra nguyên nhân của các trở ngại. Sau khi triệt tiêu những lỗi còn lại, chúng ta có thể thiết lập Apache server.

Lời bàn và mở rộng:
Trên tinh thần bảo mật, đoạn trên là một trong những đoạn có thể cho là quan trọng nhất trong quá trình thiết lập một Apache web server. Câu hỏi được đặt ra: "tại sao chroot lại quan trọng đến thế?"

Ðối với những ai đã quen thuộc với cấu trúc filesystem trên một *nix nào đó, thì trả lời cho câu hỏi này khá dễ dàng. Tuy nhiên, đối với những ai chưa nắm rõ cấu trúc này thì hơi khó hơn một tí. Từ câu nói ở trên "Tổng thể mà nói, thủ thuật "chrooting" có nghĩa là tạo một cấu trúc nguồn thư mục mới, dời chuyển các hồ sơ daemon vào đó và chạy các daemon thích ứng trong môi trường mới này. Nhờ vào đó, daemon (và cái process con) chỉ sẽ truy dụng đến cấu trúc thư mục mới." có thể diễn giải như sau:

- cấu trúc filesystem của *nix nói chung (có những điểm tương đồng và dị biệt, nhưng ở đây chỉ đề cập đến những điểm khái quát mà thôi), root của filesystem là điểm khởi đầu của một cấu trúc "cây" (tree hierachy):

/
 |--bin
 |--boot
 |--dev
 |--etc
 |--lib
 |--mnt
 |--opt
 |--sbin
 |--tmp
 |--usr
 |--var
 |......

trong đó / (root của filesystem) chứa các thư mục khác và trong các thư mục này chứa các loại software, công cụ, thông tin, cấu hình... cho cả một *nix system.

- nếu một user có quyền truy cập đến / (root của filesystem) thì user ấy có cơ hội truy dụng các thông tin và công cụ trong những thư mục thuộc /. Ðể giảm thiểu và quản lý quyền truy cập của một user như Apache ở trên là điều rất khó kiện toàn cho nên "chroot" là phương tiện để ép người dùng chỉ được quyền truy cập và hoạt động trong một vùng nhất định nào đó, loại bỏ các trường hợp thiếu sót trong cơ chế quản lý quyền truy dụng.

- sau khi áp đặt "chroot" cho user Apache, thay vì "hắn" có thể thấy và truy cập vào các thư mục thuộc loại "cấm kị", "hắn" chỉ có thể làm việc trong khuôn khổ:

/apache-root
 |--httpd
  |--dev
  |--etc
  |--var
  |  |--run
  |--usr
  |  |--lib
  |  |--libexec
  |  |--local
  |  |  |--apache
  |  |  |  |--bin
  |  |  |  |--logs
  |  |  |  |--conf
  |--www

như quá trình xác định trong phần bài viết trên. User Apache không có cơ hội truy cập vào các thư mục quan trọng như /etc, /bin, /sbin... sau khi đã được "chroot". User Apache chỉ có thể xử dụng những thông tin nào cần thiết và vừa đủ để web server này hoạt động mà thôi. Thủ thuật "chroot" đôi khi còn được gọi là "jail" (cầm tù) theo đúng tinh thần chroot.

Chỉnh lý Apache
Bước đầu tiên là tháo bỏ hồ sơ /chroot/httpd/usr/local/apache/conf/httpd.conf và tạo một hồ sơ mới thay thế vào với nội dung tương tự như sau:

# =================================================
# Basic settings
# =================================================
ServerType standalone
ServerRoot "/usr/local/apache"
PidFile /usr/local/apache/logs/httpd.pid
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard
ResourceConfig /dev/null
AccessConfig /dev/null

# =================================================
# Performance settings
# =================================================
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0

# =================================================
# Apache's modules
# =================================================
ClearModuleList
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_dir.c
AddModule mod_access.c
AddModule mod_auth.c

# =================================================
# General settings
# =================================================
Port 80
User apache
Group apache
ServerAdmin Webmaster@www.ebank.lab
UseCanonicalName Off
ServerSignature Off
HostnameLookups Off
ServerTokens Prod
<IfModule mod_dir.c>
    DirectoryIndex index.html
</IfModule>
DocumentRoot "/www/vhosts"

# =================================================
# Access control
# =================================================
<Directory />
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>
<Directory "/www/vhosts/www.ebank.lab">
    Order allow,deny
    Allow from all
</Directory>
<Directory "/www/vhosts/www.test.lab">
    Order allow,deny
    Allow from all
</Directory>

# =================================================
# MIME encoding
# =================================================
<IfModule mod_mime.c>
    TypesConfig /usr/local/apache/conf/mime.types
</IfModule>
DefaultType text/plain
<IfModule mod_mime.c>
    AddEncoding x-compress Z
    AddEncoding x-gzip gz tgz
    AddType application/x-tar .tgz
</IfModule>

# =================================================
# Logs
# =================================================
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ErrorLog /usr/local/apache/logs/error_log
CustomLog /usr/local/apache/logs/access_log combined

# =================================================
# Virtual hosts
# =================================================
NameVirtualHost *
<VirtualHost *>
    DocumentRoot "/www/vhosts/www.ebank.lab"
    ServerName "www.ebank.lab"
    ServerAlias "www.e-bank.lab"
    ErrorLog logs/www.ebank.lab/error_log
    CustomLog logs/www.ebank.lab/access_log combined
</VirtualHost>
<VirtualHost *>
    DocumentRoot "/www/vhosts/www.test.lab"
    ServerName "www.test.lab"
    ErrorLog logs/www.test.lab/error_log
    CustomLog logs/www.test.lab/access_log combined
</VirtualHost>

Cấu hình trên chỉ có những lệnh cần thiết để thoả mãn chức năng hoạt động và các trù bị bảo mật. Trong cấu hình đưa ra ở trên có hai hosts ảo được Web server hỗ trợ:

- www.ebank.lab www.e-bank.lab) 
- www.test.lab

Nội dung của các Web site trên được chứa trong các thư mục:

- /chroot/httpd/www/vhosts/www.ebank.lab 
- /chroot/httpd/www/vhosts/www.test.lab

Mỗi Web site có riêng log files được chứa trong các thư mục:

- /chroot/httpd/usr/local/apache/logs/www.ebank.lab 
- /chroot/httpd/usr/local/apache/logs/www.test.lab

Các thư mục trên phải được tạo ra trước khi Apache hoạt động lần đầu tiên - nếu không Apache sẽ không làm việc đúng mức. Chủ nhân của các thư mục trên nên là root:sys, và chủ quyền nên chỉnh thành 0755.

So sánh với hồ sơ cấu hình mặc định của Apache, có những thay đổi sau:

* Số modules được ứng động đã giảm thiểu đáng kể,
* Apache không tiết lộ thông tin version number (phiên bản) (dùng các directives: ServerTokens, ServerSignature),
*
Các process của Apache (ngoại trừ process của root) được chỉnh định bằng chủ quyền riêng biệt của user/group bình thường (dùng các directives: User, Group),
*
Apache chỉ cho phép truy cập vào các thư mục, các thư mục con và các hồ sơ đã được quy định cụ thể trong hồ sơ cấu hình (dùng các directives: Directory, Allow); mọi requests khác đều bị từ chối theo mặc định,
*
Apache sẽ log nhiều thông tin hơn với các HTTP requests.

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:

#!/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.