Bảo mật cho máy chủ web Apache doc

Bảo mật cho máy chủ web Apache
trang này đã được đọc lần
Theo thống kê tháng 9 của Netcraft, Apache là máy chủ web được
dùng nhiều nhất trên Internet (chiếm đến 64,52% thị phần). Tuy
nhiên, để cấu hình một máy chủ web Apache sao cho bảo mật không
phải là một chuyện đơn giản và ai cũng có thể làm được. Bài viết
"Bảo mật cho máy chủ web Apache" (Securing Apache: Step-by-
Step) do anh hnd dịch sẽ giúp cho việc xây dựng một máy chủ web
có tính an tòan bảo mật cao dễ dàng hơn.

Bảo mật Apache: từng bước một

Tác giả: Artur Maj)
Chào các fan quan tâm đến bảo mật cho Apache.

Tôi quyết định dịch bài này và thêm vào phần "Lời bàn và mở rộng"
cho các đoạn quan trọng trong bài viết, hy vọng phần nào giúp các
bạn ứng dụng những vấn đề này trong môi trường thật sự. Mời các
bạn xem phần thứ nhất.

Tài liệu này theo dạng chỉ dẫn từng bước cách cài đặt và chỉnh lý
Apache 1.3.x web server với mục đích xử lý và phòng tránh các
trường hợp đột nhập lúc những yếu điểm của chương trình này được
khám phá.

Chức năng

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:
erviews/MVC.htm

cleview/19/1/1/




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ư hoặc



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ỏ;
- server 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 ).

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. Nếu phần thiết lập trên
cung cấp user Apache một $HOME và cho phép dùng một shell nào
đó thì đã không mang giá trị gì trên quan điểm "kiện toà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 (). 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) có ở:

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:


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 and 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"