DRAFT1
[email protected]
MỤC LỤC
2
I. PHIẾU GIAO ĐỀTÀI
Tên đề án: 

Người hướng dẫn: 
Thời gian thực hiện: 14 tuần
Số lượng SV 2
I. !
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. ""# $%&'(
 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. %
 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. )*+
 Hệ thống Mod Security triển khai hoàn chỉnh để bảo vệ hệ thống web
V.  ,+-
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

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
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project)
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

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ó

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:
454647"89 :;8"< 6:=48"<
Dựa vào phiên bản của
hệ điều hành
• Tự động cài đặt
• Dễ dàng bảo trì
•Có thể là phiên bản cũ
Gói cài đặt của bên thứ
ba

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
Hình 2: Kiểm tra MD5 tập n cài đặt
# 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.

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
4BC A
SecArgumentSeparator Sets the application/x-www-form-urlencoded
parameter separator
SecCookieFormat Sets the cookie parser version
SecDataDir Sets the folder for persistent storage
SecRequestBodyAccess Controls request body buffering
SecRequestBodyInMemoryLimit Sets the size of the per-request memory buffer
SecRequestBodyLimit Sets the maximum request body size
ModSecurity will accept
SecRequestBodyLimitAction Controls what happens once the request body
limit is reached
SecRequestBodyNoFilesLimit Sets the maximum request body size,
excluding uploaded files
SecResponseBodyAccess Controls response body buffering
SecResponseBodyLimit Specifies the response body buffering limit
SecResponseBodyLimitAction Controls what happens once the response body
limit is reached
SecResponseBodyMimeType Specifies a list of response body MIME types
to inspect
SecResponseBodyMimeTypesClear Clears the list of response body MIME types
SecRuleEngine Controls the operation of the rule engine

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.
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.
14
# 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.

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.

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:
• 633: 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)
• D,E+F,-,-): lọc các dãy IP nguy hiểm dựa vào một bên thứ 3.
• GE,H: xác định các mã độc trong nội dung trang web
bằng cách sử dụng Google Safe Browsign API.
• 63H,I3: chống lại dạng tấn công từ chối dịch vụ
như HTTP Flooding và Slow HTTP DoS.
• 4++GJ-3: 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.
• "JKI0,;),: phát hiện các mã độc,
webshell, 0days thông qua các chức năng upload tập tin.
• -H: 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ử).
17
• L3: phát hiện các mẫu trojan.
• "IIJ)),HI: cảnh báo các lỗi trong quản lý cấy hình
ứng dụng webserver.
• MH6: 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 Liên kết
GitHub
Repository
https://github.com/SpiderLabs/owasp-modsecurity-crs
TAR/GZ
Archive
https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master

[Tue Jun 04 18:40:39 2013] [error] [client 192.168.149.1] ModSecurity: Access denied
19
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.
H H)
SecAction Performs an unconditional action. This directive is
essentially a rule that always matches.
SecDefaultAction Specifies the default action list, which will be used in
the rules that follow.
SecMarker 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.
SecRule Creates a rule.
SecRuleInheritance Controls whether rules are inherited in a child
configuration context.
SecRuleRemoveById Removes the rule with the given ID.
SecRuleRemoveByMsg Removes the rule whose message matches the given

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.
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.
21
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 Description
ARGS Request parameters (read-only collection)
ARGS_COMBINED_SIZE Total size of all request parameters combined
ARGS_NAMES Request parameters’ names (collection)
ARGS_GET Query string parameters (read-only collection)

22
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 Description
AUTH_TYPE Authentication type
REMOTE_ADDR Remote address
REMOTE_HOST Remote host
REMOTE_PORT Remote port
SCRIPT_BASENAME Script basename
SCRIPT_FILENAME Script file name/path
SCRIPT_GID Script group ID
SCRIPT_GROUPNAM
E
Script group name
SCRIPT_MODE Script permissions
SCRIPT_UID Script user ID
SCRIPT_USERNAME Script user name
SERVER_ADDR Server address
SERVER_NAME Server name
SERVER_PORT Server port
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).
Bảng sau liệt kê các giá trị biến (respone variable) mà ModSecurity hỗ trợ:
K, H)
RESPONSE_BODY Response body

transaction
WEBSERVER_ERROR_L
OG
Error messages generated by Apache during
current transaction
Parsing flags
K, H)
MULTIPART_BOUNDARY_QUOTED Multipart parsing error: quoted
boundary encountered
MULTIPART_BOUNDARY_WHITESPAC
E
Multipart parsing error:
whitespace in boundary
MULTIPART_CRLF_LF_LINES Multipart parsing error: mixed line
endings used
MULTIPART_DATA_BEFORE Multipart parsing error: seen data
before first boundary
MULTIPART_DATA_AFTER Multipart parsing error: seen data
after last boundary
MULTIPART_FILE_LIMIT_EXCEEDED Multipart parsing error: too many
files
MULTIPART_HEADER_FOLDING Multipart parsing error: header
folding used
MULTIPART_INVALID_HEADER_FOLD
ING
Multipart parsing error: invalid
header folding encountered
MULTIPART_LF_LINE Multipart parsing error: LFline
ending detected
MULTIPART_MISSING_SEMICOLON Multipart parsing error: missing

Time variables
Các biến về thời gian dùng để xác định thời gian khi một phiên làm việc trên ModSecurity
được thực hiện.
K, H)
TIME Time (HH:MM:SS)
TIME_DAY Day of the month (1–31)
TIME_EPOCH Seconds since January 1, 1970 (e.g.,
1251029017)
TIME_HOUR Hour of the day (0–23)
TIME_MIN Minute of the hour (0–59)
TIME_MON Month of the year (0–11)
TIME_SEC Second of the minute (0–59)
TIME_WDAY Week day (0–6)
TIME_YEAR Year
25