Đồ án: Nghiên cứu ứng dụng modsecurity để bảo vệ web server

DRAFT1



MỤC LỤC

2


I.

PHIẾU GIAO ĐỀTÀI

Tên đề án:

Nghiên cứu ứng dụng Mod Security để bảo vệ web
server

Người hướng dẫn:

Lưu Thanh Trà

Thời gian thực hiện: 14 tuần
Số lượng SV
I.

2

Mục đích

Các firewall truyền thống không đủ mạnh để để bảo vệ các web server. ModSecurity cho phép

bảo vệ web server (một/nhiều) thông qua cơ chế can thiệp trực tiếp ở mức độ ứng dụng.
Đồ án này nhằm nghiên cứu và ứng dụng ModSecurity để bảo vệ hệ thống web bất kỳ.
II.

II.

Yêu cầu đối với sinh viên thực hiện

 Sinh viên có kiến thức cơ bản về Linux, web
 Sinh viên có kiến thức về security, html, lập trình web
III.
yêu cầu
 Sinh viên nắm rõ hoạt động của hệ điều hành Linux
 Sinh viên nắm rõ web, html, http, PhP.
IV.
Sản phẩm
 Hệ thống Mod Security triển khai hoàn chỉnh để bảo vệ hệ thống web
V.
Tài liệu tham khảo

Các giáo trình do giảng viên đề nghị, Internet
Ngày 28 tháng 02 năm 2013
Ký tên

TS. Lưu Thanh Trà

3


II.

NHẬP ĐỀ

Ngày nay, ứng dụng web trong doanh nghiệp và cơ quan chính phủ phải đối mặt với hai
thách thức lớn là: giảm thiểu nguy cơ bảo mật và bảo đảm quy trình trong công nghiệp và/hoặc
những quy định chính phủ. May mắn thay khi tồn tại một giải pháp an toàn thông tin sẵn sàng
hỗ trợ các tổ chức CNTT đạt được cả hai tiêu chí trên tại cùng một thời điểm. OWASP cho
phép các chuyên gia an ninh CNTT giảm thiểu được các cuộc tấn công bằng các chủ động và
liên tục củng cố các cấu hình cấu hình an ninh của OS, ứng dụng web và Web Application
Firewall. Đồng thời, các dự án thuộc chuẩn OWASP cho phép các kiểm soát viên giám sát việc
tuân thủ các chính sách bắt buộc trong tổ chức, doanh nghiệp.
ModSecurity là một sản phẩm thuộc dự án OWASP, cho phép người dùng cấu hình, tùy
chỉnh các phương thức phát hiện tấn công vào web server. Phiên bản ModSecurity hiện tại đã
hỗ trợ Apache, Nginx và IIS. Cùng với dự án ModSecurity Core Rule Set thì việc triển khai hệ
thống WAF càng dễ dàng hơn cho nhân viên hệ thống cũng như các chuyên viên bảo mật.
III.

4


IV.

GIỚI THIỆU MOD_SECURITY

Mod_Security là một module mở rộng cho các chương trình web server như Apache, Nginx,
IIS và hoạt động như một firewall tại lớp ứng dụng web. Cùng với sự gia tăng về phương pháp
tấn công web thì mod_security cũng đã cập nhật những rule và đưa ra nhiều cách phòng chống
trong mã nguồn của chương trình. Một số tính chất mà mod_security có thể dùng làm Web
Application Firewall:
Tính linh động (Flexibility)

Việc phân tích luồng HTTP theo một tiêu chí nhất định trong thực tế thường gặp vấn đề là
làm sao để có thể so trùng mẫu mà bạn muốn. Ngoài ra, do nhu cầu của từng hệ thống web là
khác nhau dẫn đến việc phân tích trên từng loại ứng dụng cũng khác nhau. Mod_security đã kết
hợp với OWASP phát triển các tập rule mẫu (Core Rule Set) nhằm tạo ra tính linh động cho
từng mô hình web khác nhau, hỗ trợ người quản trị phân tích theo nhu cầu thực tế của hệ thống
đang quản trị.
Tính thụ động (Passivity)
ModSecurity sẽ không thực thi các tác vụ nếu như người quản trị viên không chỉ định công
việc cụ thể cho chương trình, việc này là khá quan trọng trong một ứng dụng có nhiệm vụ phân
tích nguy cơ như ModSecurity. Mọi cảnh báo sẽ được thực hiện thông qua cơ chế phân tích và
quyết định tương tác với hệ thống sẽ do người quản trị thực hiện.
CHỨC NĂNG
ModSecurity hoạt động với chương trình web server (ví dụ: Apache) sẽ thực hiện các tác vụ
như sau:
Parsing
ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu trúc dữ liệu mà
ModSecurity định nghĩa sẵn. Cấu trúc này sẽ được chuyển qua cơ chế so trùng mẫu trong tập
rule để phân tích nguy cơ.
Buffering
Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt động của ModSec.
Việc này có ý nghĩa khi các request gởi đến ứng dụng web thì phải thông qua ModSecurity
trước khi đến ứng dụng xử lý và những response cũng sẽ được phân tích trước khi trả về phía
client. Cơ chế này là cách duy nhất để có thể ngăn chặn các cuộc tấn công thời gian thực, các
dữ liệu mà ModSecurity nhận được và phân tích sẽ được lưu trữ trong RAM (bao gồm request
body và response data)
Logging
ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers, request body, response
header, response body nhằm hỗ trợ người quản trị phân tích nguy cơ mà hệ thống đang gặp
phải để có thể ra quyết định kiểm soát.
5

Rule Engine
Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát hiện các dạng tấn
công và thực hiện phòng chống. ModSecurity cùng phát triển với dự án OWASP phát triển các
mẫu để phân tích và phòng chống các tấn công hệ thống web (Tham khảo
/>Các phân nhóm mà CRS hỗ trợ:
•
•
•
•
•
•
•
•
•
•
•

HTTP Protection
Real-time Blacklist Lookups
Web-based Malware Detection
HTTP Denial of Service Protections
Common Web Attacks Protection
Automation Detection
Integration with AV Scanning for File Uploads
Tracking Sensitive Data
Trojan Protection
Identification of Application Defects
Error Detection and Hiding

CẤU TRÚC RULE TRONG ModSecurity
Tất cả các hoạt động trong ModSecurity hầu hết sẽ liên quan đến hai phần chính là: cấu hình
(configuration) và các tập luật (rule). Phần cấu hình chỉ định cách thức xử lý dữ liệu, trong khi
các rule sẽ quyết định thực hiện các hành vi (action) với dữ liệu đã được xử lý.
Một ví dụ về rule: SecRule ARGS "<script>" log,deny,status:404
Cấu trúc chuẩn của một rule trong ModSecurity bao gồm 3 phần chính:
SecRule VARIABLES OPERATOR ACTIONS
VARIABLES: xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu. Trong ví dụ trên,
tham số ARGS nhằm chỉ định tìm kiếm mẫu trong tất cả các tham số trong request.
OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu. Các operator được dùng theo
dạng Regular expression nhằm tạo nên cơ chế phân tích linh động cho các rule.
ACTIONS: chỉ định hành động mà ModSecurity sẽ thực hiện khi có một mẫu được so trùng.
Trong ví dụ trên, phần action được viết log,deny,status:404 có nghĩa là: khi trùng mẫu <script>
trong gói tin thì thực hiện ghi log, deny gói tin bằng cách sử dụng mã trạng thái 404 (Not
found).
QUY TRÌNH XỬ LÝ TRONG ModSecurity
Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước (pha), tại mỗi bước
ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các khai thác.

6


Hình 1: Quy trình xử lý của ModSecurity (nguồn www.Modsecurity.org)
Request Header (1)
Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin. Mục đích của bước này
nhằm cho phép người viết rule tương tác với các request trước khi thực hiện các yêu cầu trong
phần HTTP body. Phần này khá quan trọng để phân tích các khai thác dựa vào HTTP method
cũng như dựa vào URL như SQL Injection, Reflect XSS, Local file include …
Request body (2)

Bước 2 là quá trình kiểm tra chính trong quá trình client gởi request đến server, phần này sẽ
có hiệu quả khi người dùng cố sử dụng phương thức POST hoặc PUT để upload tập tin lên phía
server. Việc kiểm tra này bảo đảm dữ liệu đưa lên server là an toàn, tránh tình trạng upload mã
độc hoặc các dạng tấn công nhưng Stored XSS, Ajax Injection …
Response headers (3)
Những request đã được xử lý tại server sẽ được trả về cho ModSecurity kiểm tra trạng thái
trong phần respone header. Trước khi phần respone body được đọc thì ModSecurity sẽ dựa vào
tập rule để xác định có cần kiểm tra nội dung dữ liệu trong phần body hay không.
Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần kiểm tra nội dung gói
tin trả về.

7


Response body (4)
Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì nội dung trong phần
body sẽ được kiểm tra so trùng với mẫu trong tập lệnh. Việc này là khá hiệu quả để phát hiện
và phòng chống xâm nhập trong trường hợp bước 1 và 2 không phát hiện được tấn công.
Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số công nghệ evasion
thì việc phát hiện khi request là khó khăn. Khi khai thác thành công, ModSecurity sẽ phân tích
kết quả trong gói tin trả về để phát hiện nếu như câu truy vấn thành công.
Logging (5)
Việc ghi log sẽ ghi nhận các cảnh báo cũng như quy trình làm việc của ModSecurity.
KHUYẾN CÁO KHI TRIỂN KHAI THỰC TẾ
Nhằm bảo đảm tính tính linh động trong việc phát hiện cũng như bảo vệ theo thời gian thực,
ModSecurity cần sử dụng một lượng tài nguyên CPU và RAM để bảo đảm hoạt động đúng
mục đích khi triển khai. Việc sử dụng tài nguyên phụ thuộc nhiều vào phần cấu hình và cách
triển khai trên từng hệ thống khác nhau. Dưới dây là một số điểm chính cần chú ý:
ModSecurity sẽ phân tích các cú pháp mà apache sẽ thực hiện, vì thế hệ thống của bạn sẽ có
thể tăng tiêu thụ tài nguyên CPU để thực hiện tác vụ.

Việc phân tích linh động trong một số trường hợp sẽ cần một lượng tài nguyên khá lớn để
phân tích. Ví dụ: XML, JSON, AJAX …
Việc quản lý dữ liệu upload từ phía client yêu cầu thêm tài nguyên I/O (như HDD), trong
một số trường hợp sẽ gây ra tình trạng trùng lặp dữ liệu trên hệ thống.
Dữ liệu trong request và resopone được lưu trữ đệm trong RAM để thực hiện các tác vụ chặn
theo thời gian thực.
Mỗi rule trong phần cấu hình sẽ sử dụng CPU (cho phần operartor) và RAM (dùng để
chuyển đổi dữ liệu đầu vào trước khi qua phiên phân tích)
Việc sử dụng các Regular expression sẽ tốn các tài nguyên nhiều hơn.
Các hoạt động I/O sẽ tăng cao cho việc ghi nhật ký trong quá trình hoạt động của
ModSecurity (full transaction loging).
Khi triển khai thực tế ModSecurity, bạn cần chú ý đến những điều trên để có thể xác định
được tài nguyên cần thiết để ModSecurity hoạt động ổn định. Trong trường hợp bạn không thể
thay đổi tài nguyên phần cứng, thì tôi khuyên bạn nên thường xuyên theo dõi trạng thái hoạt
động của hệ thống, rút ra những kinh nghiệm nhằm điều chỉnh hoặc giảm bớt chức năng,
ruleset phù hợp mà vẫn đảm bảo an toàn cho việc hoạt động. Nếu như tổ chức mà bạn đang
quản lý sử dụng một số công nghệ ảo hóa thì việc điều chỉnh tài nguyên sẽ thuận tiện hơn để
ModSecurity hoạt động.
Một cách khác để triển khai ModSecurity trên thực thế là dùng như một reverse proxy, trong
trường hợp này tài nguyên cho ModSecurity sẽ ổn định hơn so với hệ thống tích hợp (CPU,
RAM, I/O hoạt động ở trạng thái cao).
8


V.

TỐNG QUAN VỀ TIÊU CHUẨN OWASP TOP TEN

OWASP (Open Web Application Security Project) là một dự án phi lợi nhuận, tập trung vào
việc cải thiện tính bảo mật của ứng dụng web. Thành viên của dự án là các cá nhân, tổ chức,

chuyên gia … cùng đóng góp các mã nguồn, công cụ hỗ trợ kiểm tra lỗ hổng ứng dụng web.
Năm 2010, cộng đồng OWASP xuất bản “Tài liệu hướng dẫn kiểm tra ứng dụng Web” phiên
bản 3 (OWASP Testing Guide v3: />Tài liệu liệt kê và phân nhóm các lỗ hổng bảo mật đã được biết đến trong ứng dụng web. Đồng
thời nội dung của tài liệu này mô tả các dự án được cộng đồng phát triển, bao gồm dự án WAF
ModSecurity.
OWASP phân loại các lỗ hổng thành 10 phân nhóm chính:
A1-Injection
A2-Cross Site Scripting (XSS)
A3-Broken Authentication and Session Management
A4-Insecure Direct Object References
A5-Cross Site Request Forgery (CSRF)
A6-Security Misconfiguration
A7-Insecure Cryptographic Storage
A8-Failure to Restrict URL Access
A9-Insufficient Transport Layer Protection
A10-Unvalidated Redirects and Forwards
Dự án OWASP ModSecurity Core Rule Set (CRS) sử dụng bản quyền ASLv2. Các tập rule
trong CRS được phân loại theo tiêu chuẩn OWASP để có thể bảo vệ máy chủ web theo từng
loại tấn công. Các rule này hoạt động tốt với phiên bản ModSecurity 2.5 trở lên.
Các vấn đề về triển khai ModSecurity CRS và phương pháp kiểm tra lỗ hổng sau khi triển
khai, bạn có thể tham khảo tại mục OWASP MODSECURITY CORE RULE SET và PHỤ
LỤC.

VI.

CÀI ĐẶT MODSECURITY

Trước khi bạn tiến hành cài đặt ModSecurity cho hệ thống, bạn cần biết những phương thức
cài đặt cũng như một số ưu điểm và khuyết điểm cho từng loại:
CÁCH CÀI ĐẶT

Dựa vào phiên bản của
hệ điều hành

ƯU ĐIỂM
• Tự động cài đặt
• Dễ dàng bảo trì

NHƯỢC ĐIỂM
• Có thể là phiên bản cũ

Gói cài đặt của bên thứ

• Tự động cài đặt

• Có thể là phiên bản cũ
• Yêu cầu tải và cập nhật

ba

thường xuyên
• Không tin tưởng vào gói cài
đặt đã đóng gói
9


Cài đặt từ mã nguồn

• Bảo đảm là phiên bản mới

nhất

• Có thể sử dụng phiên bản
thử nghiệm
• Có thể tùy biến, sử dụng các
bản vá khẩn cấp trong
tình huống phát hiện lỗi
bảo mật

• Có thể gặp các vấn đề khi

quản trị viên muốn sử
dụng lại phiên bản cũ
trước đó

Trong phần này, tôi sẽ hướng dẫn biên dịch từ mã nguồn. ModSecurity được tải tại trang
web www.Modsecurity.org.
Trước khi cài đặt ModSecurity trên nền tảng Linux, bạn cần cài đặt một số thư viện hỗ trợ
như sau: Apache Portable Runtime (APR), APR-util, bật module mod_unique_id trong Apache,
libcurl, libxml2, Lua 5.1 (tùy chọn), PCRE.
# yum install openssl openssl-devel pcre pcre-devel libxml2 libxml2-devel curl-devel pcre
pcre-devel
Tải phiên bản ModSecurity mới nhất tại trang chính của sản phẩm.
# wget /># wget />
Kiểm tra gói tin đã tải về
Hình 2: Kiểm tra MD5 tập tin cài đặt

# md5sum –c Modsecurity-apache_2.7.3.tar.gz.md5
Thực hiện giải nén
# tar xvf Modsecurity-apache_2.7.3.tar.gz
# cd Modsecurity-apache_2.7.3
Biên dịch cài đặt chương trình

# ./configure
10


# make
# make install
Sau khi cài đặt thành công, ta cần cấu hình LoadModule trong tập tin cấu hình của Apache
(mặc định trên CentOS là /etc/httpd/conf/httpd.conf)
Bỏ comment cho unique_id_module
LoadModule unique_id_module modules/mod_unique_id.so
Thêm dòng
LoadModule security2_module modules/mod_security2.so

Sau khi chỉnh tập tin httpd.conf, ta save lại và tiến hành kiểm tra tập tin cấu hình, bảo đảm
Apache hoạt động bình thường.
# httpd –t

Khởi động lại dịch vụ httpd trên hệ thống, đồng thời kiểm tra log file để bảo đảm dịch vụ
hoạt động tốt.
# service httpd restart
#tail –f /var/logs/httpd/error_log

11


Hình 3: Log thông báo trạng thái khởi động của Apache
Apache đã hoạt động bình thường với mod_security.

VII.

CẤU HÌNH

Cấu hình thư mục
Trước khi thực hiện cấu hình ModSecurity, tôi sẽ tạo một danh sách các thư mục theo một
định dạng sẵn. Việc này giúp tôi quản lý dễ dàng các dữ liệu mà ModSecurity tạo ra, đồng thời
hỗ trợ trong việc bảo trì và cập nhật các rule mới cho ModSecurity.
Binaries: /opt/modsecurity/bin
Configuration files: /opt/modsecurity /etc
Audit logs: /opt/modsecurity /var/audit
Persistent data: /opt/modsecurity/var/data
Logs: /opt/modsecurity/var/log
Temporary files: /opt/modsecurity/var/tmp
File uploads: /opt/modsecurity/var/upload
Location
/opt/modsecurity
/opt/modsecurity/bin
/opt/modsecurity/etc
/opt/modsecurity/var
/
opt/modsecurity/var/audit
/
opt/modsecurity/var/data
/
opt/modsecurity/var/log
/
opt/modsecurity/var/tmp
/
opt/modsecurity/var/uploa
d

Owner
root
root
root
root
apache

Group
apache
apache
root
apache
root

Permissions
rwxr-x--rwxr-x--rwx-----rwxr-x--rwx------

apache

root

rwx------

root

root

rwx------

apache

apache

rwxr-x---

apache

root

rwx------

Các tập tin cấu hình
12


Tập tin
main.conf
rules-first.conf
rules.conf
rules-last.conf

Mô tả
Tập tin cấu hình chính
Tập lệnh thực hiện đầu tiên
Tập lệnh thực hiện chính
Tập lệnh thực hiện cuối cùng

Thực hiện tạo tập tin Modsecurity.conf trong thư mục /etc/httpd/conf.d với nội dung:
<IfModule mod_security2.c>
Include /opt/modsecurity/etc/main.conf

Include /opt/modsecurity/etc/rules-first.conf
Include /opt/modsecurity/etc/rules.conf
Include /opt/modsecurity/etc/rules-last.conf
</IfModule>
Tạo một tập tin cấu hình mẫu cho ModSecurity dựa vào tập tin đề nghị có sẵn, tại thư mục
chứa mã nguồn Modsecurity thự hiện lệnh sao chép như sau:
#cp Modsecurity.conf-recommended /opt/modsecurity/etc/main.conf
Các chỉ thị trong tập tin cấu hình
Chỉ thị
SecArgumentSeparator
SecCookieFormat
SecDataDir
SecRequestBodyAccess
SecRequestBodyInMemoryLimit
SecRequestBodyLimit
SecRequestBodyLimitAction
SecRequestBodyNoFilesLimit
SecResponseBodyAccess
SecResponseBodyLimit
SecResponseBodyLimitAction
SecResponseBodyMimeType
SecResponseBodyMimeTypesClear
SecRuleEngine
SecTmpDir

Mô tả
Sets the application/x-www-form-urlencoded
parameter separator
Sets the cookie parser version
Sets the folder for persistent storage

Controls request body buffering
Sets the size of the per-request memory buffer
Sets the maximum request body size
ModSecurity will accept
Controls what happens once the request body
limit is reached
Sets the maximum request body size,
excluding uploaded files
Controls response body buffering
Specifies the response body buffering limit
Controls what happens once the response body
limit is reached
Specifies a list of response body MIME types
to inspect
Clears the list of response body MIME types
Controls the operation of the rule engine
Sets the folder for temporary files

13


Quản lý Request Body
Request bao gồm hai thành phần: request header mặc định luôn được bật trong ModSecurity
và request body là tùy chọn để theo dõi. Trong trường hợp quản trị viên cần theo dõi nội dung
request body thì cầu cấu hình như sau:
# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On

Khi chức năng quản lý request body được sử dụng, thì ModSecurity không những sẽ theo
dõi nội dung gói tin mà còn sẽ lưu trữ nội dung trong bộ đệm (buffer) để phân tích trong trường
hợp dữ liệu gởi đến server cần nhiều hơn một gói tin HTTP. Nhằm tránh tình trạng gây quá tải
cho bộ nhớ RAM, quản trị viên cần điều chỉnh tham số giới hạn phù hợp. Có ba phần cấu hình
chỉ định hoạt động của buffer. Hai chỉ thị đầu tiên dùng để giới hạn của các request:
# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
Trong phiên bản trước 2.5, ModSecurity chỉ hỗ trợ SecRequestBodyLimit dùng để giới hạn
kích thước gói tin request đến server, bao gồm gói tin với POST method bình thường (ví dụ:
nhập username, password) và các gói tin dùng POST method để upload tập tin. Nhưng nhóm
phát triển ModSecurity thấy rằng: khi client dùng POST để upload tập tin, thì quá trình này
không sử dụng đến RAM để xử lý gói tin mà chỉ dùng I/O để truyền dữ liệu. Vì lý do này, trong
phiên bản sau 2.5 thì chức năng SecRequestBodyNoFilesLimit được thêm vào nhằm phân biệt
gói tin dùng để upload tập tin và gói tin dùng để nhập dữ liệu từ client.
Chỉ thị thứ ba trong phần này là SecRequestBodyInMemoryLimit, dùng điều khiển hoạt
động lưu trữ nội dung của gói tin vào bộ nhớ RAM. Tham số trong phần này chỉ có hiệu quả
với các gói tin có nhiệm vụ upload tập tin (multipart/form-data)
# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072
Những gói tin có kích thước trong khoảng giới hạn tại mục SecRequestBodyInMemoryLimit
sẽ được lưu trữ trong RAM. Những gói tin có kích thước lớn hơn sẽ được chuyển vào vùng nhớ

swap trên ổ cứng để lưu trữ và phân tích.
14


Quản lý Response Body
Tương tự như gói tin request, các gói tin respone cũng bao gồm hai phần là header và body
(trong một số trường hợp gói tin respone không tồn tại nội dung trong phần body). Ta cấu hình
việc theo dõi nội dung trong repone tại mục SecResponseBodyAccess.
# Allow ModSecurity to access response bodies.
# You should have this directive enabled in order to identify errors
# and data leakage issues.
#
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
#SecResponseBodyAccess On
SecResponseBodyAccess Off
Tôi khuyến cáo nên tắt chức năng theo dõi respone nhằm giảm thiểu tài nguyên CPU và
RAM trên máy chủ. Hơn nữa, hầu hết các cuộc tấn công thường xuất hiện bên ngoài hệ thống,
nên việc theo dõi các repone đôi khi là không cần thiết.Trong trường hợp bạn cần theo dõi dữ
liệu phản hồi từ server, đơn giản là thiết lập thành giá trị thành On.
Trong dữ liệu mà phía server trả về phía client thường bao gồm nhiều thành phần và kiểu
khác nhau như: html, css, js, jpg, xml … Trong hầu hết các trường hợp, thì các dữ liệu tĩnh
(javascript, css …) không tạo ra nguy cơ bảo mật nào cho hệ thống, do vậy trong ModSecurity
ta cần chỉ định rõ kiểu dữ liệu cần theo dõi trong phần SecResponseBodyMimeType
# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

Filesystem Locations
Trong phần cấu hình này, ta cần chỉ định thư mục lưu trữ tạm thời nhằm phục vụ cho chức
năng theo dõi nội dung tập tin đăng tải lên phía server. Ngoài ra, thư mục này bao gồm việc lưu
trữ các session_cookie trong trường hợp phục vụ cho các rule chống khai thác thông qua
session_fixation hoặc session_hijacking.
#-- Filesystem configuration -----------------------------------------------# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
#
# This default setting is chosen due to all systems have /tmp available however,
# this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir /tmp/
15


# The location where ModSecurity will keep its persistent data. This default setting
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir /tmp/
File Uploads
Tại phần cấu hình quản lý upload tập tin, ta cần chỉ định thư mục chứa dữ liệu tạm thời trong
trường hợp có tập tin được upload. Thư mục này sẽ chứa tập tin tạm thời để ModSecurity kiểm
tra trước khi đưa quan Apache xử lý nội dung tiếp theo.
Khuyến cáo: việc sử dụng chức năng theo dõi tập tin upload có thể là nguyên nhân của việc
làm tăng dung lượng lưu trữ do có nhiều tập tin trùng lặp nội dung, đồng thời việc này sẽ làm
giảm hiệu suất của ModSecurity. Vì lý do này, bạn chỉ nên sử dụng chức năng này khi thật sự
cần thiết.
# The location where ModSecurity will store intercepted
# uploaded files. This location must be private to ModSecurity.

SecUploadDir /opt/modsecurity/var/upload/
# By default, do not intercept (nor store) uploaded files.
SecUploadKeepFiles Off
Debug Log
Debug log sẽ hỗ trợ quản người trị trong việc theo dõi hoạt động của ModSecurity. Log level
trong phần này được khuyến cáo thiết lập ở mức 3, nhằm giới hạn việc tăng kích thước của log
mà vẫn bảo đảm cho việc theo dõi hệ thống.
# Debug log
SecDebugLog /opt/modsecurity/var/log/debug.log
SecDebugLogLevel 3
Audit Log
Audit log được sử dụng với mục đích ghi lại các phiên (transaction) làm việc. Audit log có 3
mức độ khác nhau để chỉ định cách thức hoạt động trong ModSecurity: SecAuditEngineare On
(ghi log tất cả phiên làm việc), Off (tắt audit log) và RelevantOnly (chỉ ghi log dựa vào mẫu mà
người dùng chỉ định).
# Thực hiện ghi log cho các yêu cầu có mã lỗi từ 500-599 (lỗi từ phía server).
RelevantOnly
SecAuditLogRelevantStatus ^5
# Use a single file for logging.
SecAuditLogType Serial
SecAuditLog /opt/modsecurity/var/log/audit.log
# Specify the path for concurrent audit logging.
SecAuditLogStorageDir /opt/modsecurity/var/audit/

16


Default Rule Match Policy
Phần cấu hình rule mặc định cho ModSecurity là khá quan trọng, vì phần này sẽ quyết định
hệ thống mà bạn sẽ theo dõi có bị bỏ sót các tấn công trong trường hợp các tập rule không thể

phát hiện được. Tuy nhiên, ModSecurity khuyến cáo bạn nên cấu hình không nên chặn tất cả
các kết nối khi ModSecurity hoạt động.
SecDefaultAction "phase:1,log,auditlog,pass"
Verifying Installation
Sau khi hoàn thành phần cấu hình, tôi sẽ kiểm tra hoạt động của ModSecurityuriy bằng một
rule đơn giản như sau:
#vi /opt/modsecurity/etc/rules.conf
SecRule REQUEST_URI "dangerous" "id:'900721'phase:1,deny,status:406"
Rule trên hoạt động trong trường hợp khi một người dùng cố truy cập vào URI có chứa mẫu
dangerous, thì Modsecurity sẽ trả về mã lỗi 406.
[root@mod_security ~]# curl -I />HTTP/1.1 406 Not Acceptable
Date: Thu, 30 May 2013 22:56:06 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

VIII.

OWASP MODSECURITY CORE RULE SET

Giới thiệu
ModSecurity sau khi đã được cài đặt thành công cần được cấu hình các tập rule để có thể
hoạt động như một WAF. Tuy nhiên, việc tự viết và triển khai các rule là khá phức tạp và tốn
thời gian để tối ưu các chức năng trong rule.
Nhóm nghiên cứu Truswave SpiderLabs đã phát triển một nhóm các tập lệnh có tên là
OWASP ModSecurity CRS, bao gồm các nội dung gói tin của kiểu tấn công đã được biết đến.
Một tính năng mạnh mẽ của CRS là có thể bảo vệ những ứng dụng web phổ biến cũng như
những ứng dụng web tự phát triển riêng biệt.
Nhằm mục đích bảo vệ các ứng dụng web phổ biến, CRS phân loại nội dung các rule dựa
trên các phương pháp tấn công:

HTTP Protection: phát hiện các nguy cơ dựa trên giao thức HTTP như Method (
GET HEAD POST …), phiên bản HTTP ( 1.0, 1.1)
• Real-time Blacklist Lookups: lọc các dãy IP nguy hiểm dựa vào một bên thứ 3.
• Web-based Malware Detection: xác định các mã độc trong nội dung trang web
bằng cách sử dụng Google Safe Browsign API.
• HTTP Denial of Service Protections: chống lại dạng tấn công từ chối dịch vụ
như HTTP Flooding và Slow HTTP DoS.
•

17


Common Web Attacks Protection: phát hiện một số dạng tấn công phổ biếtn
vào ứng dụng web Automation Detection: phát hiện các bots, crawler, chương trình quét
(scanner) và các hoạt động thu thập thông tin.
• Integration with AV Scanning for File Uploads: phát hiện các mã độc,
webshell, 0days thông qua các chức năng upload tập tin.
• Tracking Sensitive Data: theo dõi các hoạt động và chặn lộ thông tin thẻ tín
dụng (trong trường hợp website có hoạt động thương mại điện tử).
• Trojan Protection: phát hiện các mẫu trojan.
• Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy hình
ứng dụng webserver.
• Error Detection and Hiding: gởi các mã thông báo lỗi giả về phía người dùng.
•

Triển khai OWASP ModSecurity CRS
Tiến hành tải gói tin SpiderLabs-owasp-modsecurity-crs phiên bản mới nhất tại:
Định dạng
GitHub
Repository

TAR/GZ
Archive
ZIP
Archive

Liên kết
/> /> />
#tar xvf SpiderLabs-owasp-modsecurity-crs-2.2.7-28-g9a715d8.tar.gz
#cd SpiderLabs-owasp-modsecurity-crs-2.2.7-28-g9a715d8
#cp modsecurity_crs_10_setup.conf.example
/opt/modsecurity/etc/modsecurity_crs_10_setup.conf
#mkdir -p /opt/modsecurity/etc/crs/activated_rules
#cp base_rules/* /opt/modsecurity/etc/crs/activated_rules/
#vi /etc/httpd/conf.d/modsecurity.conf
<IfModule mod_security2.c>
#START COMMON CONFIGURATION
Include /opt/modsecurity/etc/main.conf
#Include /opt/modsecurity/etc/rules-first.conf
#Include /opt/modsecurity/etc/rules.conf
#Include /opt/modsecurity/etc/rules-last.conf
#STOP COMMON CONFIGURATION
18


#START OWASP MODSECURITY CORE RULE SET
Include /opt/modsecurity/etc/modsecurity_crs_10_setup.conf
Include /opt/modsecurity/etc/crs/activated_rules/*.conf
#STOP OWASP MODSECURITY CORE RULE SET
</IfModule>
#/etc/init.d/httpd restart

Kiểm tra kết quả
Ta thực hiện kiểm tra tấn công SQL injection với URI sau trong trường hợp trước và sau khi
triển khai OWASP CRS: />
Hình 4: Tấn công SQLI trước khi triển khai OWASP CRS

19


Hình 5:Tấn công SQLI sau khi triển khai OWASP CRS
Cảnh báo ghi nhận tấn công:
[Tue Jun 04 18:40:39 2013] [error] [client 192.168.149.1] ModSecurity: Access denied
with code 403 (phase 2). Pattern match "\\\\b(?i:having)\\\\b\\\\s+(\\\\d{1,10}|'[^=]
{1,10}')\\\\s*?[=<>]|(?i:\\\\bexecute(\\\\s{1,5}[\\\\w\\\\.$]{1,5}\\\\s{0,3})?\\\\()|\\\\bhaving\\\\b
?(?:\\\\d{1,10}|[\\\\'\\"][^=]{1,10}[\\\\'\\"]) ?[=<>]+|(?i:\\\\bcreate\\\\s+?table.{0,20}?\\\\()|(?
i:\\\\blike\\\\W*?char\\\\W*?\\\\()|(?i:(?:(select(.* ..." at ARGS:p. [file
"/opt/modsecurity/etc/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
[line "130"] [id "959070"] [rev "2"] [msg "SQL Injection Attack"] [data "Matched Data:
order by found within ARGS:p: 1 order by 1,2,4"] [severity "CRITICAL"] [ver
"OWASP_CRS/2.2.7"] [maturity "9"] [accuracy "8"] [tag
"OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag
"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname
"www.modsec.com"] [uri "/"] [unique_id "Ua3SN38AAAEAAAcbBfsAAAAA"]

IX.

TỔNG QUAN VỀ RULE

Giới thiệu
Modsecurity định nghĩa 9 loại chỉ thị để người dùng có thể triển khai các tính năng lọc linh
động cho hệ thống web.

Directive
SecAction
SecDefaultAction
SecMarker
SecRule

Description
Performs an unconditional action. This directive is
essentially a rule that always matches.
Specifies the default action list, which will be used in
the rules that follow.
Creates a marker that can be used in conjunction with
the skipAfteraction. A marker creates a rule that does
nothing, but has an ID assigned to it.
Creates a rule.
20


SecRuleInheritance
SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleScript
SecRuleUpdateActionB
yId
SecRuleUpdateTargetB
yId

Controls whether rules are inherited in a child
configuration context.
Removes the rule with the given ID.

Removes the rule whose message matches the given
regular expression.
Creates a rule implemented using Lua.
Updates the action list of the rule with the given ID.
Updates the target list of the rule with the given ID.

Cú pháp rule trong ModSecurity:
SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]
Trong một rule ModSecurity có 4 thành phần, trong đó hai thành phần cuối của cú pháp là
tùy chọn. Nếu trong một rule mà bạn định nghĩa không sử dụng 2 thành phần
TRANSFORMATION_FUNCTIONS và ACTIONS thì ModSecurity sẽ dùng các giá trị mặc
định được thiết lập trong SecDefaultAction.
Biến (Variables)
Trong ModSecurity, biến được sử dụng cho việc trích xuất (etract) các thành phần khác nhau
của gói tin HTTP. được Bạn cần chú ý rằng các dữ liệu tương tác trong quá trình hoạt động của
ModSecurity là dữ liệu thô (raw bytes of data) bao gồm các ký tự đặc biệt. Mặc dù ứng dụng
web mà bạn xây dựng chỉ tương tác với các dữ liệu dạng văn bản (text), nhưng bạn không thể
chắc chắn được chuyện gì đang xảy ra nếu như các đối thủ sử dụng những cách để vượt qua các
kiểm soát logic.
Trong phiên bản hiện tại, ModSecurity đã hỗ trợ 77 loại biến khác nhau để tăng tính linh
động chống lại các kiểu khai thác nâng cao.
Operators
Tại mục này, ModSecurity sẽ xác định các thức mà một biến được xử lý. Các regular
expresstion được sử dụng phổ biến, tuy nhiên ModSecurity định nghĩa sẵn các operator nhằm
hỗ trợ bạn có thể tự xây dựng một rule cho mục đích cá nhân.
Transformation_functions
Chức năng này cho phép chuyển đổi dữ liệu đầu vào trước khi đưa qua cơ chế kiểm tra
(chuyển chữ hoa thành chữ thường, decode base64 …)
Actions
Chỉ rõ hành động sẽ thực hiện khi một rule đã được so trùng mẫu.

21


Variables
Có 77 loại biến trong phiên bản ModSecurity hiện tại và chúng được phân loại như sau:
Scalar variables: Chứa một phần thông tin dữ liệu, có thể là chuỗi hoặc số. Ví dụ,
REMOTE_ADDR luôn chứa địa chỉ IP của người dùng,
Collections: Nhóm các biến lại với nhau thành một nhóm.
Read-only collections: Nhóm các biến không thể thay đổi trong quá trình thực hiện tương tác
giữa ModSecurity và Apache.
Read/write collections: Nhóm này được sử dụng trong trường hợp bạn cần triển khai các rule
có sự thay đổi trong dữ liệu đầu vào.
Special collections: Nhóm các biến đặc biệt được dùng trong việc trích xuất dữ liệu đầu vào
dưới dạng XML.
Persistent collections: Khi các rule sử dụng các thành phân trong nhóm này, thì dữ liệu sẽ
được lưu trữ trong cơ sở dữ liệu nội bộ của ModSecurity. Trong các tác vụ như theo dõi IP,
phiên làm việc hoặc theo dõi người dùng đăng nhập thì việc lưu trữ sẽ được sử dụng.
Request variables
Các biến trong phân nhóm này chịu trách nhiệm trích xuất các giá trị trong HTTP request
header để đưa vào phần phân tích. Các trường giá trị ModSecurity hỗ trợ trong các biến được
thu thập từ các URI, method (GET HEAD POST PUT …), protocol information ( HTTP 1.1,
HTTP 1.0).
Bảng sau liệt kê các giá trị biến (Request variable) mà ModSecurity hỗ trợ:
Variable
ARGS
ARGS_COMBINED_SIZE
ARGS_NAMES
ARGS_GET
ARGS_GET_NAMES

ARGS_POST
ARGS_POST_NAMES
FILES
FILES_COMBINED_SIZE
FILES_NAMES
FILES_SIZES
FILES_TMPNAMES
PATH_INFO
QUERY_STRING

Description
Request parameters (read-only collection)
Total size of all request parameters combined
Request parameters’ names (collection)
Query string parameters (read-only collection)
Query string parameters’ names (read-only
collection)
Request body parameters (read-only collection)
Request body parameters’ names (read-only
collection)
File names (read-only collection)
Combined size of all uploaded files
File parameter names (read-only collection)
A list of file sizes (read-only collection)
A list of temporary file names (read-only
collection)
Extra path information
Request query string
22

REMOTE_USER
REQUEST_BASENAME
REQUEST_BODY
REQUEST_COOKIES
REQUEST_COOKIES_NA
MES
REQUEST_FILENAME
REQUEST_HEADERS
REQUEST_HEADERS_N
AMES
REQUEST_LINE
REQUEST_METHOD
REQUEST_PROTOCOL
REQUEST_URI
REQUEST_URI_RAW

Remote user
Request URI basename
Request body
Request cookies (read-only collection)
Request cookies’ names (read-only collection)
Request URI file name/path
Request headers (collection, read-only)
Request headers’ names (read-only collection)
Request line
Request method
Request protocol
Request URI, convert to exclude hostname
Request URI, as it was presented in the request

Server variables
Các biến trong phân nhóm này dùng phân tích các thành phần do người dùng gởi đến máy
chủ, và một số khác liên quan đến dữ liệu trả về người dùng.
Bảng sau liệt kê các giá trị biến (server variable) mà ModSecurity hỗ trợ:
Variable
AUTH_TYPE
REMOTE_ADDR
REMOTE_HOST
REMOTE_PORT
SCRIPT_BASENAME
SCRIPT_FILENAME
SCRIPT_GID
SCRIPT_GROUPNAM

Description
Authentication type
Remote address
Remote host
Remote port
Script basename
Script file name/path
Script group ID
Script group name

SCRIPT_MODE
SCRIPT_UID
SCRIPT_USERNAME
SERVER_ADDR
SERVER_NAME

SERVER_PORT

Script permissions
Script user ID
Script user name
Server address
Server name
Server port

E

Response variables
Các biến trong phân nhóm này được dùng cho việc xác định các dữ liệu trả về người dùng.
Phần lớn các giá trị này được sử dụng trong pha thứ 3 Response headers (3). Một số thành
phần liên quan đến nội dung gói tin HTTP (body) thì sẽ được dùng trong pha thứ 4 Response
body (4).
23


Bảng sau liệt kê các giá trị biến (respone variable) mà ModSecurity hỗ trợ:
Variable
RESPONSE_BODY
RESPONSE_CONTENT_LE
NGTH
RESPONSE_CONTENT_TY
PE
RESPONSE_HEADERS
RESPONSE_HEADERS_NA
MES
RESPONSE_PROTOCOL

RESPONSE_STATUS

Description
Response body
Response content length
Response content type
Response headers (read-only collection)
Response headers’ names (read-only collection)
Response protocol
Response status code

Miscellaneouse variables
Bảng sau liệt kê các giá trị biến (miscellaneouse variable) mà ModSecurity hỗ trợ:
Variable
HIGHEST_SEVERITY
MATCHED_VAR
MATCHED_VARS

Description
Highest severity encountered
Contents of the last variable that matched
Contents of all variables that matched int the most
recent rule
MATCHED_VARS_NAM
Names of all variables that matched in the most
ES
recent rule
MATCHED_VAR_NAME
Name of the last variable that matched
MODSEC_BUILD

ModSecurity build version (e.g., 02050102)
SESSIONID
Session ID associated with current transaction
UNIQUE_ID
Unique transaction ID generated by mod_unique_id
USERID
User ID associated with current transaction
WEBAPPID
Web application ID associated with current
transaction
WEBSERVER_ERROR_
Error messages generated by Apache during current
LOG
transaction
Parsing flags
Variable
MULTIPART_BOUNDARY_QUOTED
MULTIPART_BOUNDARY_WHITESP
ACE
MULTIPART_CRLF_LF_LINES

Description
Multipart parsing error: quoted
boundary encountered
Multipart parsing error: whitespace in
boundary
Multipart parsing error: mixed line
endings used
24

MULTIPART_DATA_BEFORE
MULTIPART_DATA_AFTER
MULTIPART_FILE_LIMIT_EXCEEDE

Multipart parsing error: seen data
before first boundary
Multipart parsing error: seen data
after last boundary
Multipart parsing error: too many files

D
MULTIPART_HEADER_FOLDING
MULTIPART_INVALID_HEADER_FO
LDING
MULTIPART_LF_LINE
MULTIPART_MISSING_SEMICOLON
MULTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUND
ARY
REQBODY_PROCESSOR
REQBODY_PROCESSOR_ERROR
REQBODY_PROCESSOR_ERROR_M
SG

Multipart parsing error: header
folding used
Multipart parsing error: invalid header
folding encountered
Multipart parsing error: LFline ending

detected
Multipart parsing error: missing
semicolon before boundary
At least one multipart error except
unmatched boundary occurred
Multipart parsing error: unmatched
boundary detected
Request processor that handled
request body
Request processor error flag (0 or 1)
Request processor error message

Collections variables
Các biến trong nhóm này có thể chứa biến của các nhóm khác, nhằm phục vụ việc thu thập
dữ liệu để đưa qua cơ chế phân tích hành vi trong ModSecurity.
Variable
ENV
GEO
GLOBAL
IP
TX
RULE
SESSION
USER
XML

Description
Environment variables (read-only collection,
although it’s possible to use setvar
to change it)

Geo lookup information from the last
@geoLookupinvocation (read-only collec
tion)
Global information, shared by all processes
(read/write collection)
IP address data storage (read/write collection)
Transient transaction data (read/write
collection)
Current rule metadata (read-only collection)
Session data storage (read/write collection)

25