Tiểu luận an ninh mạng Bảo mật Web Server Apache

ĐẠI HỌC QUỐC GIA TP.HCM
ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
Bảo mật Web Server Apache
với Mod Security
Giáo viên hướng dẫn: ThS. Nguyễn Duy
Thành viên nhóm:
08520236 Nguyễn Văn Minh
08520579 Lê Đặng Quang
08520493 Hoàng Ngọc Giao
08520048 Lê Thế Công
CE03 - 5/2011
MMT03 – 4/2012
1. Giới thiệu:
Mô hình tổng quan của Mod Security
ModSecurity là một dạng Web Application Firewall (WAF) modules, với 70% các cuộc
tấn công là nhằm vào web application khiến cho việc bảo vệ chúng trở thành một vấn đề cần phải
quan tâm hàng đầu. Mod Security là open source,được phát triển bởi Ivan Ristic. Ông là một
người có rất nhiều kinh nghiệm trong bảo vệ Apache Web Server. Ông đã có nhiều thời gian
nghiên cứu Web Application Security, Web Intrusion Detection, và Security Patterns. Trước khi
chuyển sang lĩnh vực security, Ivan đã có nhiều năm làm việc như một developer, system
architect, technical director trong phát triển phần mềm. Ông là người sáng lập ra công ty
ThinkingStone làm các dịch vụ liên quan đến web application security.
Mod Security có khả năng chạy trên nhiều hệ điều hành Linux,Windows,
Solaris,FreeBSD,OpenBSD,NetSBD,AIX,Mac OS x và HP-UX
Hiện tại mod_security sử dụng giấy phép GPL, hoàn toàn miễn phí. Ngoài ra nếu muốn
có sự hỗ trợ thì bạn có thể mua nó từ công ty ThinkingStone của ông
()
Các tính năng của mod_security
• Request filtering: Tất cả các request gửi đến web server đều được phân tích và cản lọc (filter) trước
khi chúng được đưa đến các modules khác để xử lý
• Understanding of the HTTP protocol: ModSecurity là một tường lửa ứng dụng nên nó có khả năng

hiểu được giao thức HTTP. ModSecurity có khả năng cản lọc dựa trên các thông tin ở HTTP Header
hay có thể xem xét đến từng thông số hay cookies của các request vv
• POST payload analysis: Ngoài việc cản lọc dựa trên HTTP Header, ModSecurity có thể dựa trên nội
dung (payload) của POST requests.
• Audit logging: Mọi requests đều có thể được ghi lại (bao gồm cả POST) để người quản trị có thể theo
dõi nếu cần.
• HTTPS filtering: ModSecurity có thể phân tích HTTPS.
Compressed content filtering: ModSecurity sẽ phân tích sau khi đã giải nén các các dữ liệu được yêu
cầu.
Quy trình xử lý các request của Apache và Mod Security
1. Phase Request Header: Rule được đặt tại đây sẽ được thực hiện ngay say khi Apache đọc request header, lúc
này phần request body vẫn chưa được đọc.
2. Phase Request Body: Đây là thời điểm các thông tin chức năng chung đưa vào vào được phân tích và xem xét,
các rule mang tính ứng dụng hướng kết nối (application-oriented) thường được đặt ở đây. Ở thời điểm này, Server
đã nhận đủ các thông số của request và phần request body đã được đọc. Modsecurity hỗ trợ ba loại mã hoá request
body
+ application/x-www-form-urlencoded: Dùng để truyền form dữ liệu
+ multipart/form-data: Dùng để truyền file
+ text/xml: Dùng để phân tích dữ liệu XML
3. Phase Response Header: Đây là thời điểm ngay sau khi phần response header được gửi trả về cho client. Chúng
ta đặt rule ở đây nếu muốn giám sát quá trình sau khi phần response được gửi đi.
4. Phase Response Body: Đây là thời điểm chúng ta muốn kiểm tra những dữ liệu HTML gửi trả về.
5. Phase logging: Là thời điểm các hoạt động log được thực hiện, các rules đặt ở đây sẽ định rõ việc log sẽ như thế
nào, nó sẽ kiểm tra các error message log của Apache. Đây cũng là thời điểm cuối cùng để chúng ta chặn các kết nối
không mong muốn, kiểm tra các response header mà chúng ta không thể kiểm tra ở phase 3 và phase 4.
2. Cài đặt và cấu hình mod_security:
Trước khi cài đặt chúng ta cần cài các thư các thư viện apxs, libxml2 và load thêm
mod_unique_id.so
Cài đặt thư viện
yum install httpd-devel libxml2-devel pcre-devel curl-devel apr-devel

Load module mod_unique_id.so
- mod_unique_id : module của apache có nhiệm vụ phát sinh một unique indentifier cho mỗi
HTTP request (xem thêm tại e_id.html) . Module này
thường được compile sẵn khi ta build apache , để sử dụng được cần phải load module này lên
trong file httpd.conf . Mở file httpd.conf và thêm vào dòng sau ở phần LoadModule :
LoadModule unique_id_module modules/mod_unique_id.so
Download và giải nén source code :
- Download phiên bản stable mới nhất tại />[root@hungn src]# cd /usr/src
[root@hungn src]# wget ' />apache_2.6.0.tar.gz'
- Giải nén file vừa download :
[root@hungn src]# ls
debug kernels modsecurity-apache_2.6.0.tar.gz
[root@hungn src]# tar -xvzf 'modsecurity-apache_2.6.0.tar.gz'
Restart httpd và kiểm tra lại :
[root@hungn src]# httpd -t -D DUMP_MODULES

unique_id_module (shared)

Compile source code :
- cd vào thư mục chứa source code đã giải nén ở bước 1 :
[root@hungn /]# cd /usr/src/modsecurity-apache_2.6.0
[root@hungn modsecurity-apache_2.6.0]# ./configure
[root@hungn modsecurity-apache_2.6.0]# make
[root@hungn modsecurity-apache_2.6.0]# make install
Tích hợp mod_sec vào apache :
- Khi make xong sẽ tạo ra file mod_security2.so ở thư mục modsecurity-
apache_2.6.0/apache2/.libs . Bạn cần copy file này bỏ vào thư mục modules của apache :
[root@hungn modsecurity-apache_2.6.0]# cp apache2/.libs/mod_security2.so /etc/httpd/modules
- Thêm dòng sau vào file httpd.conf để load module mod_sec lên :
LoadModule security2_module modules/mod_security2.so

Restart httpd và kiểm tra lại :
[root@hungn /]# httpd -t -D DUMP_MODULES

security2_module (shared)

Tạo file config :
Chúng ta có thể cấu hình trực tiếp các thông số và rule của ModSecurity vào file httpd.conf.
Nhưng để cho rõ ràng và đảm bảo không sai sót trong quá trình thực hiện - gây ảnh hưởng
Apache, Chúng ta nên tạo một file cấu hình riêng và sau đó include vào.
Trong CentOS các file cấu hình riêng mặc định chứa trong /etc/httpd/conf.d/
#vi /etc/httpd/conf.d/modsecurity.conf
Thêm vào các thông số cấu hình cơ bản
<IfModule security2_module>
# Bat che do loc cua Modsecurity
SecRuleEngine On
# Thiet lap action mac dinh
SecDefaultAction "phase:2,deny,log,status:404"
# rule thu nghiem block tat ca request co uri chua "upload"
SecRule REQUEST_URI "upload"
</IfModule>
Kiểm tra hoạt động :
Thực hiện thử nghiệm để kiểm tra hoạt động của ModSecurity. Tiến hành tạo 2 floder trong thư
mục web, joomla và upload chẳng hạn. Khi chúng ta truy cập vào khi chúng ta truy câp vào thư
mục joomla thì trình duyệt trả về kết quả bình thường
Còn khi truy cập vào upload thì trình duyệt báo lỗi :
Đó là kết quả do ModSecurity đã chặn những URI có chứa chuỗi upload và cũng đồng nghĩa với
việc ModSecurity đã hoạt động.
3. Cấu trúc của rule và viết rule:
404 – Forbidden
a. Cấu trúc của rule:

SecRule TARGET OPERATOR [ACTIONS]
Target (mục tiêu): Quy định cụ thể mục tiêu của request hoặc response mà chúng ta muốn kiểm
tra. Trong ví dụ kiểm cơ bản được đưa ra trong phần trước, sử dụng biến có
tên REQUEST_URI, trong đó có các URI được request trên server, để nhận diện và chặn bất cứ
Client nào truy cập vào các vị trí /hacker.html. Hiện có hơn 70 biến có thể được sử dụng để tạo
rule.
Ngoài ra còn có một loại biến đặc biệt được gọi là biến collection có thể chứa nhiều đối số. Một
ví dụ về collection là ARGS, trong đó có chứa tất cả các đối số được truyền trong một chuỗi truy
vấn hoặc thông qua một request POST.
Phần Operator xác định phương pháp và so sánh khớp dữ liệu để kích hoạt Action. Với
Operator, mặc định là @rx
Cuối cùng, Actions (hành động) là một danh sách các hành động được thực hiện nếu phù hợp
(matching) rule. Action có thể là allow (cho phép) hoặc deny (từ chối) các request; và quy định
cụ thể các mã trạng thái (status code) khi trả về (response) cho client. Nếu không có action nào
được quy định, các action mặc định của action SecDefaultAction sẽ được sử dụng (rule chứa
action này thường được khai báo đầu tiên).
b. Bộ chọn lọc Collections
Các collection có sẵn trong ModSecutity 2.5
- ARGS
- ENV
- FILES
- FILES_NAMES
- FILES_SIZES
- FILES_TMPNAMES
- GEO
- IP
- REQUEST_COOKIES
- REQUEST_COOKIES_NAMES
- REQUEST_HEADERS
- REQUEST_HEADERS_NAMES

- RESPONSE_HEADERS
- RESPONSE_HEADERS_NAMES
- SESSION
- TX
- USER
TX Collection còn được gọi là các Transaction collection. Chúng ta có thể sử dụng nó để tạo ra các biến phục vụ
riêng cho mình.
Một variables có thể bao gồm 1 hay nhiều phần dữ liệu. Khi variable có nhiều hơn 1 giá trị thì ta
gọi nó là collection
Ví dụ: với variable ARGS ta có 2 thông số p, và q
SecRule ARGS:p dirty
SecRule ARGS:q dirty
Có thể dùng 1 hay nhiều variables
SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
Có ba loại collection trong ModSecurity được sử dụng để lưu trữ liên tục( persistent storage).
Như phần trước đã trình bày, setvar giúp tạo ra một biến và gán giá trị cho nó. Tuy nhiên, biến sẽ
hết hạn và không còn nữa khi các request hiện tại đã được xử lý. Trong một số trường hợp chúng
ta muốn lưu trữ giá trị biến và truy cập nó cho các request sau này, có thể sử dụng kiểu lưu trữ
này.
Có ba collection có thể được sử dụng cho mục đích này:
- IP
- SESSION
- USER
Collection IP được sử dụng để lưu trữ thông tin về IP của người sử dụng. Nó có thể được sử
dụng để lưu trữ IP ở các trường hợp như: Số lần truy cập không thành công vào tài nguyên trên
server, hoặc số lượng các request của người dùng…
c. Phases và sắp xếp rule
Điều quan trọng là hiểu được việc sắp xếp rule của ModSecurity. Điều này tránh các tình huống
mà mọi phương thức, hoạt động đều bất ngờ bị chặn(deny) hoặc cho phép (allow) trái với ý định.
Có 5 giai đoạn (phase)

1. REQUEST_HEADERS (phase 1)
2. REQUEST_BODY (phase 2)
3. RESPONSE_HEADERS (phase 3)
4. RESPONSE_BODY (phase 4)
5. LOGGING (phase 5)
Một rule được thực hiện đúng từng phase theo thứ tự . Điều này có nghĩa là ModSecurity duyệt
tất cả các rule trong phase 1 ("REQUEST_HEADERS"). Sau đó, đến phase 2…
Trong mỗi phase, rule được xử lý theo thứ tự mà chúng xuất hiện trong các tập tin cấu hình.
Chúng ta có thể hiểu khi có action, ModSecurity sẽ duyệt các tập tin năm lần, một lần cho từng
phase.
Trong thời gian xử lý ModSecurity chỉ xem xét rule thuộc pha hiện đang xử lý, và những rule
được áp dụng theo thứ tự chúng xuất hiện trong các tập tin cấu hình.
Phase LOGGING đặc biệt ở chỗ nó luôn luôn được thực hiện cả khi request đã được cho phép
hay từ chối trong các phase trước đó. Ngoài ra, một khi phase LOGGING bắt đầu, chúng ta
không thể thực hiện bất kỳ action ngăn chặn nào vì response đã được gửi cho người truy cập.
Vì vậy, chúng ta phải cẩn thận không để cho bất kỳ action nào trái quy định được truyền vào rule
ở phase 5. Nếu không sẽ gây lỗi làm Apache không khởi động được. Nếu chúng ta đặt rule sau
đây trước các rule thuộc phase 5 sẽ ngăn chặn được lỗi này xảy ra. (nhưng phải đặt sau các rule
của phase trước đó).
SecDefaultAction "phase:5,pass"
d. Chức năng chuyển đổi:
ModSecurity cung cấp một số chức năng chuyển đổi mà chúng ta có thể áp dụng cho các biến và
các collection. Những biến đổi được thực hiện trên một bản sao của dữ liệu được kiểm tra, có
nghĩa là các HTTP request hoặc response ban đầu vẫn được giữ nguyên, không thay đổi.
Chức năng này rất quan trọng. Nếu chúng ta muốn phát hiện tấn công XSS (cross-site scripting),
chúng ta phải phát hiện mã JavaScript bất kể trường hợp nó được viết in hay viết thường. Để làm
điều này, chức năng chuyển đổi có thể được áp dụng để so sánh một chuỗi viết hoa với chuỗi viết
thường.
SecRule ARGS "<script" "deny,t:lowercase"

Rule trên sẽ chặn tất cả các URL chứa chuỗi >;<;script bất kể chữ hoa thường, vd sCript;
>;<;scripT
e. Operators:
Sử dụng @ để chỉ ra đây là một operation
Sử dụng !@ để chỉ ra một operation negation
Toán tử @rx (regular expression) là một toán tử
mặc định, được sử dụng khi không có một toán tử nào khác được chỉ định.
Toán tử Tác dụng Ví dụ
@beginsWith Khớp các chuỗi bắt đầu với chuỗi
chỉ định
SecRule
REQUEST_LINE
“!@beginsWith GET”
@containts Khớp các chuỗi có chứa chuỗi chỉ
định tại bất cứ vị trí nào
SecRule
REQUEST_LINE
“@contains select”
@containsWor
d
Khớp xâu chứa từ được chỉ định.
“Từ” ở đây được hiểu là đoạn xâu
được ngăn bởi một hoặc nhiều ký tự
không phải chữ,số
SecRule ARGS
“@containsWord from”
@endsWith Khớp xâu kết thúc bởi xâu chỉ định SecRule ARGS
“@endsWith ”
@streq Khớp xâu giống hoàn toàn xâu chỉ
định

SecRule
REMOTE_HOST
“@streq victim\.com”
@within Khá giống @contains, chỉ khác là SecRule
một so khớp xảy ra khi biến cần so
xuất hiện bên trong xâu được chỉ
định
REMOTE_USER
“@within
cuong,nam,an”
(sẽ khớp nếu remote user
là cuong, nam hoặc an)
@pm Khớp với một trong những cụm từ đi
sau nó
SecRule ARGS "@pm red
green blue" deny
@pmFromFile Nếu có quá nhiều chuỗi muốn đặt
vào, ta có thể liệt kê các chuỗi này
vào một file và dùng @pmFromFile
SecRule ARGS
“@pmFromFile
/usr/log/alo.txt”
Toán tử Toán tử đại số
tương đương
Ví dụ
@eq = SecRule RESPONSE_STATUS “@eq 200”
@ge ≥ SecRule RESPONSE_STATUS “@ge 400”
@gt > SecRule RESPONSE_STATUS “@gt 399”
@le ≤ SecRule RESPONSE_STATUS “@le 199”
@lt < SecRule RESPONSE_STATUS “@lt 200”

f. Actions:
Khi request vi phạm một rule nào đó thì mod_security sẽ thực thi một hành động (action). Khi
action không được chỉ rõ trong rule thì rule đó sẽ sử dụng default action . Có 3 loại actions :
• Primary Actions
Primary actions sẽ quyết định cho phép request tiếp tục hay không. Mỗi rule chỉ có một
primary action. Có 5 primary actions :
deny : Request sẽ bị ngắt, mod_security sẽ trả về HTTP status code 500 hoặc là status
code của bạn thiết lập trong chỉ thị status:
pass : Cho phép request tiếp tục được xử lý ở các rules tiếp theo
Allow: Cho phép truy cập ngay lập tức và bỏ qua các phases khác (trừ phases logging).
Nếu muốn chỉ cho qua phase hiện tại thì cần chỉ rõ allow:phase Khi đó sẽ vẫn được kiểm
tra bởi các luật tại các phases sau. Chỉ cho phép truy cập tới các request phases:
allow:request, nó sẽ cho qua phase 1,2 và vẫn kiểm tra ở phase 3 trở đi
redirect : Redirect một request đến một url nào đó.
• Secondary Actions
Secondary actions sẽ bổ sung cho Primary actions, một rule có thể có nhiều Secondary
actions
status : n khi một Request vi phạm một rule nào đó thì mod_security có thể trả về các
HTTP status code n thay vì status code 500 mặc định.
exec : thực thi một lệnh nào đó nếu một request vi phạm
log : ghi log những request vi phạm rule
nolog : không ghi log
pause : n mod_security sẽ đợi một thời gian n ms rồi mới trả về kết quả.
Flow Actions
chain: kết nối 2 hay nhiều rules lại với nhau
skipnext:n mod_security sẽ bỏ qua n rules theo sau nó
• Default Action
Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action được thiết lập trong
SecDefaultAction.
Ví dụ : SecDefaultAction "phase:2,deny,log,status:403"

g. Audit logging
Apache log ít thông tin vì thế nó không cho phép chúng ta có thể lần ngược các bước của
kẻ tấn công. Mod_security hỗ trợ audit loging với đầy đủ thông tin và từ đó có thể lần ngược lại
quá trình của kẻ tấn công, cũng như là chỉnh sửa các rules cho hợp lý tránh bị “false positive”.
Có 2 directives:
SecAuditEngine On : bật audit log lên
SecAuditLog logs/audit.log : chỉ ra file lưu trữ log chính
h. Một vài rule cơ bản
• Local Attack
SecRequestBodyAccess On
SecRule REQUEST_BODY "ls" "phase:2,deny,log,status:500"
• Rule chống sql
SecRule ARGS "union\s+select" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "union\s+all\s+select" "t:lowercase,deny,msg:'SQLInjection'"
SecRule ARGS "into\s+outfile" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "drop\s+table" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "alter\s+table" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "load_file" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "select\s+*" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS|REQUEST_HEADERS|REQUEST_URI “@pm select update insert alter
drop union”
“deny,status:400,t:lowercase,t:replaceComments,t:removeWhitespace,t:removeNulls”
• XSS Attack
SecRule ARGS "alert\s+*\(" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "<.+>" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "javascript:" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "vbscript:" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "<script" "deny,t:lowercase"
• DIRECTORY TRAVERSAL Attack
SecRule REQUEST_URI "\.\./" "t:urlDecode,deny"

• NULL BYTE Attack
SecDefaultAction "phase:2,deny,log,status:403,t:removeNulls"
• Chống lại kiểu tấn công XSS thông qua PHP session cookie
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"
• Hạn chế MSSQL injection attack
SecFilter xp_enumdsn
SecFilter xp_filelist
SecFilter xp_availablemedia
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey
• Chống spam mail
<Location /cgi-bin/FormMail>
SecFilterSelective "ARG_recipient" "!@modsecurity\.org$"
</Location>
• Phát hiện xâm nhập
SecFilterSelective OUTPUT "Volume Serial Number"
SecFilterSelective OUTPUT "Command completed"
SecFilterSelective OUTPUT "Bad command or filename"
SecFilterSelective OUTPUT "file(s) copied"
SecFilterSelective OUTPUT "Index of /cgi-bin/"
SecFilterSelective OUTPUT ".*uid\=\("
• Lọc các kí tự hay dùng trong shell code
SecFilterForceByteRange 32 126
• chống lại kiểu tấn công XSS thông qua PHP session cookie
SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"
• Hạn chế sqlinjection attack

SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
4. Tổng kết:
Hoạt động như một module của máy chủ web Apache, Mod security đã tăng
cường bảo mật cho các ứng dụng web,bảo vệ chúng khỏi các cuộc tấn công
đã biết và chưa biết
Là open source và có nhiều chức năng tùy vào khả năng lập trình của admin
nên rất thích hợp cho các web nhỏ,không có các thiết bị tường lửa phần
cứng,chưa thể hoặc kiếm được ít doanh thu từ ứng dụng web. Tùy vào hệ
thống nên việc cấu hình Mod Security cũng rất linh động
Tài liệu tham khảo:
(1): Mod security toàn tập - [May 3
rd

2010]
(2): Phát hiện và chống xâm nhập Web Server với Mod Security-
/>Server-voi-Mod-Security.aspx [September 14
th
2005]
(3): Bảo mật Web Server Apache với Mod Security- />mat-web-server-Apache-voi-mod-Security-Phan-2.aspx [October 1
st
2011]
(4): Magnus Mischel .(2009) . Mod Security 2.5: Securing your Aphache installation and web
applications. [November 2009]