Tìm hiểu, thử nghiệm tường lửa ứng dụng web modsecurity

HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA AN TOÀN THÔNG TIN
----------

BÀI TẬP LỚN
Đề tài: Tìm hiểu, thử nghiệm tường lửa ứng dụng web
modsecurity
Lớp: L02
Sinh viên thực hiện:
Phạm Thị Quỳnh
Phạm Bảo Yến

Giảng viên: Bùi Việt Thắng

Hà Nội, 11/201

1


MỤC LỤC
MỤC LỤC .......................................................................................................... 1
DANH SÁCH HÌNH ẢNH ................................................................................ 3
LỜI MỞ ĐẦU .................................................................................................... 5
CHƯƠNG I – GIỚI THIỆU VỀ TẤN CÔNG SQL INJECTION .................... 6
1.1. Khái niệm ................................................................................................. 6
1.2. Một số dạng tấn công thường gặp với các ứng dụng ............................... 6
1.2.1. Dạng tấn công vượt qua kiểm tra lúc đăng nhập ............................... 6
1.2.2. Dạng tấn công sử dụng câu lệnh SELECT ........................................ 6
1.2.3. Dạng tấn công sử dụng câu lệnh INSERT ......................................... 6
1.2.4. Dạng tấn công sử dụng stored-procedures......................................... 6
1.3. Các dạng lỗi thường gặp .......................................................................... 7

1.3.1. Không kiểm tra ký tự thoát truy vấn .................................................. 7
1.3.2. Xử lý không đúng kiểu ...................................................................... 7
1.3.3. Lỗi bảo mật bên trong máy chủ sơ sở dữ liệu ................................... 7
1.3.4. Blind SQL Injection ........................................................................... 8
1.3.5. Thay đổi giá trị điều kiện truy vấn..................................................... 8
1.3.6. Điều kiện lỗi....................................................................................... 8
1.3.7. Thời gian trễ ....................................................................................... 8
CHƯƠNG II – GIỚI THIỆU VỀ MODSECURITY ......................................... 9
2.1. Khái niệm ................................................................................................. 9
2.2. Các khả năng của ModSecurity ............................................................... 9
2.3. Cách xử lý một yêu cầu ModSecurity ................................................. 10
2.4. Cách viết một tập luật cho ModSecurity ............................................. 11
2.4.1. Cơ bản về Regular Expression –biểu thức chính quy ................... 12

1


2.4.2. Chỉ dẫn SecRule ............................................................................ 13
2.4.3. Biến trong ModSecurity ................................................................ 13
2.4.4. Operator ......................................................................................... 14
2.4.5. Action ............................................................................................ 16
2.4.6. Lưu trữ giữ liệu giữa các request .................................................. 19
2.4.7. Tạo chain rule- chuỗi các luật ....................................................... 19
CHƯƠNG III – TRIỂN KHAI CÀI ĐẶT CẤU HÌNH MODSECURITY CHO
MÁY CHỦ WEB APACHE ............................................................................ 21
3.1. Chuẩn bị ................................................................................................. 21
3.2. Xây dựng kịch bản ................................................................................. 21
3.3. Các bước thực hiện ................................................................................ 21
3.4. Cài đặt website có lỗ hổng bảo mật ....................................................... 21
3.4.1. DVWA ............................................................................................. 21

3.4.2. Thực hiện ......................................................................................... 22
3.5. Thực hiện tấn công SQL Injection lên máy chủ web ............................ 23
3.6. Cài đặt mod_security lên máy chủ Linux CentOS ................................ 24
3.6.1. Cài đặt và cấu hình mod_security .................................................... 24
3.6.2. Thiết lập luật cho mod_security ...................................................... 25
3.6. Kiểm tra.................................................................................................. 26
KẾT LUẬN ...................................................................................................... 27
PHỤ LỤC ......................................................................................................... 28
1. Cài đặt Apache ........................................................................................ 28
2. Cài đặt MariaDB ..................................................................................... 28
3. Cài đặt PHP............................................................................................. 29
4. Cài đặt phpMyAdmin ............................................................................. 29
TÀI LIỆU THAM KHẢO................................................................................ 31

2


DANH SÁCH HÌNH ẢNH

Hình 2.1: Quá trình xử lý yêu cầu của ModSecurity ....................................... 10
Hình 3.1: Mô hình triển khai ............................................................................ 21
Hình 3.2: DVWA ............................................................................................. 22
Hình 3.3: Giao diện trang web có lỗ hổng bảo mật ......................................... 23
Hình 3.4: Giao diện khai thác thông tin ........................................................... 23
Hình 3.5: Cài đặt modsecurity ......................................................................... 24
Hình 3.6: File cấu hình ..................................................................................... 25
Hình 3.7: File mod_security.conf .................................................................... 25
Hình 3.8: Nội dụng rule ................................................................................... 26
Hình 3.9: Kết quả kiểm tra ............................................................................... 26

3


DANH MỤC BẢNG

Bảng 2.1: Một số biểu thức chính quy ............................................................. 12
Bảng 2.2: Các ký tự meta thường dùng ........................................................... 13
Bảng 2.3: Các giá trị toán tử so trùng chuỗi .................................................... 15
Hình 2.4: Các giá trị toán tử hỗ trợ so sánh ..................................................... 15
Hình 2.5: Các giá trị toán tử kiểm tra .............................................................. 15
Hình 2.6: Các giá trị toán tử hỗn độn............................................................... 16
Hình 2.7: Các giá trị disruptive actions ........................................................... 17
Hình 2.8: Các giá trị flow actions .................................................................... 17
Hình 2.9: Các giá trị metadata actions ............................................................. 17
Hình 2.10: Các giá trị variable actions............................................................. 18
Hình 2.11: Các giá trị logging actions ............................................................. 18
Hình 2.12: Các giá trị special actions .............................................................. 18
Hình 2.13: Các giá trị miscellaneous actions ................................................... 19

4


LỜI MỞ ĐẦU
Ngày nay khi công nghệ thông tin phát triển, nhu cầu xây dựng cho mình
một website riêng với mục đích giải trí, quảng bá sản phẩm, …. của các cá
nhân, tổ chức ngày càng gia tăng thì vấn đề bảo mật các website này ngày
càng được quan tâm. Hiện nay, nhiều tổ chức đã nghiên cứu và cung cấp các
giải pháp giúp cho mỗi cá nhân, tổ chức có thể xây dựng website riêng và vấn
đề bảo mật được đặt lên hàng đầu.
Trên Dự án về kiểm thử các lỗ hổng của ứng dụng web (Open Web

Application Security Project - OWASP), các tổ chức, các công ty đã xây dựng
lên tường lửa ứng dụng web (Web Application Firewall - WAF) để bảo vệ hệ
thống máy chủ web như sản phẩm Imperva, CheckPoint hay Modsecurity.
Trong khi Imperva và CheckPoint là sản phẩm thương mại thì Modsecurity là
một sản phẩm mã nguồn mở và có nhiệm vụ ngăn chặn một số dạng tấn công
nhằm vào web và cơ sở dữ liệu. Do đó, chúng em lựa chọn đề tài: “Tìm hiểu,
thử nghiệm tường lửa ứng dụng web modsecurity”.
Bản báo cáo này gồm 3 phần:
Chương 1 – Giới thiệu về tấn công SQL Injection: Chương này sẽ giới
thiệu về các khái niệm, các dạng tấn công, một số lỗi thường gặp trong tấn
công SQL Injection.
Chương 2 - Giới thiệu về Modsecurity: Chương này sẽ giới thiệu về các
khái niệm, các viết một tập luật, … và các vấn đề khác liên quan đến
Modsecurity.
Chương 3 - Triển khai mô hình : Chương này sẽ triển khai cài đặt, cấu
hình rule cho modsecurity để chống lại tấn công SQL Injection.
Mặc dù đã cố gắng nhưng do kiến thức có hạn và thời gian còn nhiều hạn
chế nên chắc chắn bản báo cáo còn nhiều thiếu sót, chúng em rất mong nhận
được những ý kiến đóng góp của thầy cô và các bạn sinh viên để chúng em có
thể tìm hiểu sâu hơn về vấn đề này.
Chúng em xin chân thành cảm ơn!

5


CHƯƠNG I – GIỚI THIỆU VỀ TẤN CÔNG SQL INJECTION
1.1. Khái niệm
SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ
hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông
báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các

câu lệnh SQL bất hợp pháp. SQL injection có thể cho phép những kẻ tấn công
thực hiện các thao tác, delete, insert, update, v.v. trên cơ sở dữ liệu của ứng
dụng, thậm chí là server mà ứng dụng đó đang chạy. SQL injection thường
được biết đến như là một vật trung gian tấn công trên các ứng dụng web có dữ
liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL,
Oracle, DB2, Sysbase...
1.2. Một số dạng tấn công thường gặp với các ứng dụng
1.2.1. Dạng tấn công vượt qua kiểm tra lúc đăng nhập
Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng
nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của
ứng dụng web. Thông thường để cho phép người dùng truy cập vào các trang
web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu
người dùng nhập thông tin về tên đăng nhập và mật khẩu. Sau khi người dùng
nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ
hay không để quyết định cho phép hay từ chối thực hiện tiếp.
1.2.2. Dạng tấn công sử dụng câu lệnh SELECT
Dạng tấn công này phức tạp hơn. Để thực hiện được kiểu tấn công này,
kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo
lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công.
1.2.3. Dạng tấn công sử dụng câu lệnh INSERT
Thông thường các ứng dụng web cho phép người dùng đăng ký một tài
khoản để tham gia. Chức năng không thể thiếu là sau khi đăng ký thành công,
người dùng có thể xem và hiệu chỉnh thông tin của mình. SQL injection có thể
được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào.
1.2.4. Dạng tấn công sử dụng stored-procedures
Việc tấn công bằng stored-procedures sẽ gây tác hại rất lớn nếu ứng dụng
được thực thi với quyền quản trị hệ thống 'sa'. Ví dụ, nếu ta thay đoạn mã tiêm
vào dạng: '; EXEC xp_cmdshell ‘cmdd.exe dir C: '. Lúc này hệ thống sẽ thực
hiện lệnh liệt kê thư mục trên ổ đĩa C:\ cài đặt server. Việc phá hoại kiểu nào
tuỳ thuộc vào câu lệnh đằng sau cmd.exe.

6


1.3. Các dạng lỗi thường gặp
1.3.1. Không kiểm tra ký tự thoát truy vấn
Đây là dạng lỗi SQL injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu
đầu vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện
một số truy vấn không mong muốn đối với cơ sở dữ liệu của ứng dụng. Dòng
mã sau sẽ minh họa lỗi này:
statement = "SELECT * FROM users WHERE name =
'" + userName + "';"
Câu lệnh này được thiết kế để trả về các bản ghi tên người dùng cụ thể từ
bảng những người dùng. Tuy nhiên, nếu biến "userName" được nhập chính
xác theo một cách nào đó bởi người dùng ác ý, nó có thể trở thành một câu
truy vấn SQL với mục đích khác hẳn so với mong muốn của tác giả đoạn mã
trên. Ví dụ, ta nhập vào giá trị của biến userName như sau:
a' or 't'='t
Khiến câu truy vấn có thể được hiểu như sau:
SELECT * FROM users WHERE name = 'a' or
't'='t';
Nếu đoạn mã trên được sử dụng trong một thủ tục xác thực thì ví dụ trên
có thể được sử dụng để bắt buộc lựa chọn một tên người dùng hợp lệ bởi 't'='t'
luôn đúng.
1.3.2. Xử lý không đúng kiểu
Lỗi SQL injection dạng này thường xảy ra do lập trình viên hay người
dùng định nghĩa đầu vào dữ liệu không rõ ràng hoặc thiếu bước kiểm tra và
lọc kiểu dữ liệu đầu vào. Điều này có thể xảy ra khi một trường số được sử
dụng trong truy vấn SQL nhưng lập trình viên lại thiếu bước kiểm tra dữ liệu
đầu vào để xác minh kiểu của dữ liệu mà người dùng nhập vào có phải là số
hay không.

1.3.3. Lỗi bảo mật bên trong máy chủ sơ sở dữ liệu
Đôi khi lỗ hổng có thể tồn tại chính trong phần mềm máy chủ cơ sở dữ
liệu, như là trường hợp hàm mysql_real_escape_string() của các máy chủ
MySQL. Điều này sẽ cho phép kẻ tấn công có thể thực hiện một cuộc tấn công
SQL injection thành công dựa trên những ký tự Unicode không thông thường
ngay cả khi đầu nhập vào đang được thoát.

7


1.3.4. Blind SQL Injection
Lỗi SQL injection dạng này là dạng lỗi tồn tại ngay trong ứng dụng web
nhưng hậu quả của chúng lại không hiển thị trực quan cho những kẻ tấn công.
Nó có thể gây ra sự sai khác khi hiển thị nội dung của một trang chứa lỗi bảo
mật này, hậu quả của sự tấn công SQL injection dạng này khiến cho lập trình
viên hay người dùng phải mất rất nhiều thời gian để phục hồi chính xác từng
bit dữ liệu. Những kẻ tấn công còn có thể sử dụng một số công cụ để dò tìm
lỗi dạng này và tấn công với những thông tin đã được thiết lập sẵn.
1.3.5. Thay đổi giá trị điều kiện truy vấn
Dạng lỗi này khiến cho kẻ tấn công có thể thay đổi giá trị điều kiện trong
câu truy vấn, làm sai lệch sự hiển thị của một ứng dụng chứa lỗi này.
1.3.6. Điều kiện lỗi
Lỗi SQL injection dạng này dẫn tới việc buộc cơ sở dữ liệu chỉ được
phép đánh giá khi mà giá trị của câu lệnh WHERE là đúng. Ví dụ:
SELECT 1/0 from users where username='Ralph';
Phép chia cho 0 chỉ được đánh giá là lỗi khi mà người dùng có tên
"Ralph" tồn tại trong cơ sở dữ liệu.
1.3.7. Thời gian trễ
Lỗi SQL injection dạng này tồn tại khi thời gian xử lý của một hay nhiều
truy vấn SQL phụ thuộc vào dữ liệu logic được nhập vào hoặc quá trình xử lý

truy vấn của SQL engine cần nhiều thời gian. Tin tặc có thể sử dụng lỗi SQL
injection dạng này để xác định thời gian chính xác mà trang cần tải khi giá trị
nhập vào là đúng.

8


CHƯƠNG II – GIỚI THIỆU VỀ MODSECURITY
2.1. Khái niệm
ModSecurity là một bộ máy phát hiện và phòng chống xâm nhập dành
cho các ứng dụng web (hay một web application firewall). ModSecurity hoạt
động như một module của máy chủ web Apache, mục đích của ModSecurity
là tăng cường bảo mật cho các ứng dụng web, bảo vệ chúng trước các cuộc tấn
công vào ứng dụng web. ModSecurity chỉ hoạt động khi được tích hợp với
Apache.
ModSecurity được phát triển bởi Ivan Ristic – Chuyên gia bảo mật ứng
dụng năm 2002 – Tác giả cuốn Apache Web Security.
Hiện tại mod_security sử dụng giấy phép GPL, hoàn toàn miễn phí.
2.2. Các khả năng của ModSecurity
ModSecurity có các khả năng sau:
- ModSecurity có khả năng thanh tra các thông điệp HTTP request
trước khi nó được xử lý hoàn toàn bởi Apache.
- Thanh tra, lưu trữ và tùy chỉnh các file được tải lên server.
- Thực thi các hành động anti-evasion một cách tự động. Hầu hết
các Web Application Firewalls là signature-based, chúng sẽ xem
xét HTTP Traffic và tìm kiếm các dấu hiệu được định nghĩa sẵn.
Nếu thấy HTTP Traffic có sự trùng khớp với một dấu hiệu nào đó
thì Firewall sẽ tiến hành sàn lọc. Nhưng nếu kẻ tấn công thay đổi
dữ liệu tấn công (attack payload) bằng nhiều cách mà vẫn cho
cùng một kết quả và sự thay đổi này không trùng khớp với bất cứ

một signature nào của Firewall thì Request đó sẽ vượt qua được
Firewall. Kỹ thuật thay đổi attack payload để tránh sự phát hiện
gọi là evasion techniques.
- Có khả năng phân tích tỉ mỉ và ghi nhật ký toàn bộ các hoạt động
của giao thức HTTP như thanh tra các thông điệp Request,
Response.
- Có khả năng theo dõi lưu lượng gói tin HTTP (HTTP Traffic) theo
thời gian thực để sớm phát hiện ra các cuộc tấn công.
- Chủ động theo dõi những yêu cầu để phát hiện những điểm bất
thường, sau đó thực hiện hành động ghi log hoặc loại bỏ gói tin
theo luật đã được thiết lập.

9


- Cuối cùng là trung tâm của ModSecurity sẽ bảo vệ Apache Server
và các ứng dụng Web chạy trên Apache trước các cuộc tấn công,
trong đó phả kể đến là các cuộc tấn công từ chối dịch vụ vào ứng
dụng Web.
2.3. Cách xử lý một yêu cầu ModSecurity
ModSecurity sẽ được thành phần con HTTP_REQUEST (nằm trong
Apache core) gọi ra khi cần thiết. Việc xử lý yêu cầu HTTP của ModSecurity
tuân theo vòng đời xử lý yêu cầu của Apache. ModSecurity có thể được gọi ra
ở 5 thời điểm trong chu trình xử lý của Apache tương ứng với 5 pha sau:
request headers, request body, response headers, response body và logging.

Hình 2.1: Quá trình xử lý yêu cầu của ModSecurity
- Request Headers: Luật đặt tại đây sẽ được thực hiện ngay sau khi
Apache đọc phần request header, lúc này request body vẫn chưa được
đọc.

10


- Request Body: Đây là thời điểm các thông tin chức năng chung đưa
vào được phân tích và xem xét, các luật mang tích applicationoriented thường được đặt ở đây. Ở thời điểm này Apache đã đọc
xong phần request body.
- Response Headers: Đây là thời điểm ngay trước khi phần response
header được gửi trả về cho client. Đặt luật ở đây nếu muốn giám sát
quá trình response sau đó. Chú ý rằng một số thông tin response
header được thêm vào bởi Apache như Date, Server, Connection mà
chúng ta cũng không thể thay đổi ở thời điểm này.
- Response Body: Ở thời điểm này có thể viết các luật truy nhập vào
response body. Đặt luật ở đây nếu muốn kiểm tra những dữ liệu
HTML gửi trả về cho client.
- Logging: Đây là thời điểm các hoạt động log được thực hiện, các luật
đặt ở đây sẽ định rõ việc ghi 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ặn các kết nối không mong muốn, kiểm tra các response header mà
bạn không thể kiểm tra ở pha 3 và pha 4.
2.4. Cách viết một tập luật cho ModSecurity
Rule – luật là phần quan trọng nhất đối với tường lửa nói chung và
ModSecurity nói riêng. Để viết được các luật cho ModSecurity thì người quản
trị cần phải có hiểu biết về giao thức HTTP và có thể sử dụng Regular
Expression (việc thành thạo giao thức HTTP và các biểu thức chính quy giúp
cho việc tối ưu hóa các rule và cũng là tối ưu hóa hoạt động của Apache).
Các luật của ModSecurity được viết hoàn toàn dựa vào các trường trong
thông điệp HTTP. Giả sử một luật đơn giản như sau:
SecRule REQUEST_HEADERS:Referer “.swf”\
“log,deny,phase:1,status:403,msg:’x-flash’”

Trong đó:
- REQUEST_HEADERS: Referer là một trường trong HTTP header
- “.swf” là biểu thức chính quy – Regular Expression
Như vậy để viết các luật một cách hiệu quả thì người quản trị phải biết rõ
như thế nào là một thông điệp HTTP bình thường đối với Web Server của
mình, như thế nào thì bị thay đổi để phục vụ các ý đồ xấu.

11


2.4.1. Cơ bản về Regular Expression –biểu thức chính quy
ModSecurity sử dụng Regular Expression để so khớp với các luật.
Regular Expression được điều khiển bởi các thư viện PCRE (Perl Compatible
Regular Expression). Regular Expression là công cụ, ngôn ngữ cực mạnh
dùng để mô tả văn bản và các thao tác trên văn bản. Một Regular Expression
thường được ứng dụng lên một chuỗi.
Ví dụ: Luật sau sẽ phù hợp với bất kỳ Request Protocol nào chứa chuỗi
HTTP như HTTP/1.0 hoặc HTTP/1.1.
SecRule REQUEST_PROTOCOL “HTTP”
Một Regular Expression gồm 2 phần: Literal (trực kiện) và metacharacter
(siêu ký tự - các ký tự đặc biệt).
- Literal: Là một ký tự (a-z) mà bạn muốn đem so khớp với chuỗi đích.
- Metacharacter: Là một ký tự đặc biệt hoạt động như một mệnh lệnh
đối với bộ phận phân tích ngữ pháp (parser) của RE.
Một số ví dụ về Regular Expression:
Regex
Ý nghĩa –kết quả
Tìm bất kỳ chuỗi nào chứa chuỗi “joy”. Ví dụ enjoy, nhưng
joy
không khớp với Joyfull

Tìm bất kỳ chuỗi nào chứa Joy hoặc joy. Ví dụ enjoy, Joy
[Jj]oy
,enJoy
[0-9]
Tìm bất kỳ chuỗi nào chứa bất kỳ số nào từ 0 đến 9
[a-zA-Z]
Bất kỳ ký tự nào từ a-z hoặc A-Z
^Host$
Chuỗi chỉ chứa Host
p.t
Bất kỳ chuỗi nào có dạng pxt. Ví dụ pat, pet, pzt
Bảng 2.1: Một số biểu thức chính quy
Các ký tự meta thường dùng:
Metacharacter
Ý nghĩa
Khớp với đứng trước từ 0 lần trở lên. Ví dụ: A*B khớp
*
với B, AB, AAB
Khớp với đứng trước từ 0 hay 1 lần. Ví dụ: A?B khớp với
?
B hay AB
Khớp với đứng trước từ 1lần trở lên. Ví dụ: A+B khớp với
+
AB, AAB

12


Bắt đầu/ kết thúc 1 chuỗi hay 1dòng/
Ký tự ngăn cách so trùng tương đương với phép OR

Xác định 1 biểu thức con xem như nó là một yếu tố đơn lẻ
0
trong pattern. Ví dụ ((a(b))c) sẽ khớp với b, ab, abc
Không so trùng với bất kỳ một ký tự nào nằm trong nhóm.
[^abc]
Ví dụ không so trùng với a hay b hay c
Bảng 2.2: Các ký tự meta thường dùng
2.4.2. Chỉ dẫn SecRule
SecRule là chỉ dẫn chính để tạo luật cho ModSecurity. Nó được sử dụng
để phân tích dữ liệu và thực thi các hành động dựa trên các kết quả tìm được.
Cú pháp: SecRule Variables Operator [Action]
Ví dụ: SecRule REQUEST_URI”sercet”
- Variables: Là biến - phần của thông điệp request hoặc response. Biến
có thể là một biến chuẩn – standard variable (ví dụ: REQUEST_URI
chứa URI của request trên server để định danh và block truy cập tới
vị trí/secret.html) hoặc biến tập hợp – collection (ví dụ:
REQUEST_HEADERS chứa tất cả các giá trị của request header).
Có trên 70 biến có thể sử dụng để tạo luật cho ModSecurity.
- Operator: Chỉ rõ phương thức để so sánh và dữ liệu để so sánh với
biến. Mặc định là @rx – nếu không chỉ rõ. Rule engine sẽ thể hiện
chuỗi như biểu thức chính quy để so khớp với biến cụ thể.
ModSecurity hỗ trợ 22 toán tử phục vụ cho việc so khớp với chuỗi.
- Action: Liệt kê các hành động sẽ xảy ra khi khớp với luật. Action bao
gồm cho phép hoặc từ chối request và chỉ rõ trạng thái trả về. Nếu
không có Action nào được chỉ rõ thì Action mặc định được thực thi.
Action mặc định được thiết lập ở chỉ dẫn SecDefaultAction.
Ví dụ: SecDefaultAction “phase:2,deny,log, status:403”
2.4.3. Biến trong ModSecurity
ModSecurity có 77 loại biến 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.
^/$
|

13


Read/write collections: Nhóm này được sử dụng trong các 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 CSDL nội bộ của ModSecurity. Trong
các tác vụ theo dõi như 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.
2.4.4. Operator
Các toán tử trong ModSecurity có nhiệm vụ phân tích các biến đầu vào
để ra quyết định. Hầu hết các rule sẽ sử dụng các regulax expression cho việc
phân tích, nhưng trong một số trường hợp cụ thể thì các phân nhóm toán tử
khác sẽ hữu ích hơn. Các toán tử bắt đầu với nhãn “@” chỉ ra phương thức để
so khớp.
Trong trường hợp ta cần so sánh các giá trị là số thì việc sử dụng regulax
expression là khá bất lợi cho việc tao rule và tài nguyên thực thi khi so sánh
rule. Modsecurity hỗ trợ một nhóm phương thức so sánh khác nhau nhằm tăng
hiệu năng cho phần kiểm tra. Trong một số trường hợp thì việc sử dụng các
toán tử về số học sẽ hiệu quả hơn nhiều so với regulax expression.
Modsecurity hỗ trợ 4 nhóm:

- String-matching operators
- Numerical operators
- Validation operators
- Miscellanreous operators
String-matching operators
Các toán tử so trùng chuỗi được dùng phân tích các đầu dữ liệu vào các
biến. Toán tử @rx và @pm thường được sử dụng nhiều trong các rule phân
tích, bởi vì tính linh ddoognj của @rx và tốc độ xử lý của @pm. Trong một số
trường hợp khác thì các toán tử còn lại sẽ hỗ trợ bạn phát triển các rule tùy
theo mục đích chi tiết.

14


Bảng 2.3: Các giá trị toán tử so trùng chuỗi
Numerical operators
Trong bảng dưới đây liệt kê các toán tử hỗ trợ so sánh các giá trị số.
Trong phiên bản Modsecurity trước 2.5.12 thì việc so sánh các giá trị số học
phải thông qua regulax expression, việc này làm ảnh hưởng lớn đến hiệu năng
hoạt động của server.

Hình 2.4: Các giá trị toán tử hỗ trợ so sánh
Validation operators
Các toán tử kiểm tra mà ModSecurity hỗ trợ được liệt kê trong bảng sau:

Hình 2.5: Các giá trị toán tử kiểm tra
Miscellanreous operators
Phân nhóm này cho phép bạn tạo ra một số rule với chức năng lọc khá
hữu dụng như: Phát hiện lộ thông tin credit card (@verifyCC), kiểm tra vùng
địa lý của IP người dùng (@geoLookup),…

15


Hình 2.6: Các giá trị toán tử hỗn độn
2.4.5. Action
Các hành vi là điểm mạnh của ModSecurity cho phép hệ thống web có
khả năng miễn dịch với một số loại khai thác đã biết đến. Các action là thành
phần cuối cùng trong một rule, Apache sẽ quyết định kết quả trả về phía người
dùng (Thông báo lỗi, hủy kết quả hoặc che phép truy cập)
ModSecurity chia các action thành 7 phân mục:
- Disruptive actions
- Flow actions
- Metadata actions
- Variable actions
- Logging actions
- Special actions
- Miscellaneous actions
Disruptive actions
Trong phân nhóm này, các action được sử dụng nhằm mục đích ngăn
chặn hoặc chuyển hướng kết nối trong trường hợp ModSecurity phát hiện mẫu
tấn công trùng khớp

16


Hình 2.7: Các giá trị disruptive actions
Flow actions

Hình 2.8: Các giá trị flow actions

Metadata actions
Phân nhóm này cho phép bạn định nghĩa các thông tin mô tả về rule. Các
thông tin này thường được dùng để mô tả thông báo lỗi (error message), giải
thích nguyên nhân xuất hiện lỗi hoặc cách khắc phục đề nghị.

Hình 2.9: Các giá trị metadata actions
Variable actions
Các hành vi trong nhóm này được liên hệ với các giá trị biến, các action
này cho phép gán các giá trị (set), thay đổi (change) và xóa (remove) giá trị
mà các biến lưu trữ.

17


Hình 2.10: Các giá trị variable actions
Logging actions
Các action trong phân nhóm ghi log chỉ dẫn ModSecurity phưng pháp và
nơi lưu trữ log. Các action ảnh hưởng đến việc ghi log trong rule là auditlog,
log, noauditlog và nolog. Để điều khiển quá trình ghi log, bạn cần tham khảo
ctlaction.

Hình 2.11: Các giá trị logging actions
Special actions

Hình 2.12: Các giá trị special actions

18


Miscellaneous actions

Hình 2.13: Các giá trị miscellaneous actions
2.4.6. Lưu trữ giữ liệu giữa các request
Thông thường sử dụng hành động setvar để tạo và gán giá trị cho biến,
tuy nhiên các biến này sẽ bị hết hạn khi xử lý xong request, ModSecurity hỗ
trợ một số kiểu biến tập hợp để lưu trữ dữ liệu giữa các request và có thể truy
cập sau này như:
- IP: Lưu trữ thông tin về địa chỉ IP của client. Thường được sử
dụng để lưu trữ số lần cố gắng truy cập tài nguyên bị lỗi, số
request của một người dùng.
- SESSION: Biến này chỉ có thể sử dụng sau khi hành động setsid
được thực thi. Lưu trữ dữ liệu của phiên kết nối.
Trước khi sử dụng các biến này thì cần phải khởi tạo giá trị cho nó sử
dụng hành động initcol và cấu hình thư mục lưu trữ dữ liệu của ModSecurity.
SecAction initcol:ip=%{REMOTE_ADDR},nolog,pass
SecDataDir /usr/local/apache2/log/modsec_data
Ví dụ về sử dụng biến
SecRule ARGS|REQUEST_HEADERS “park” deny
Luật trên sẽ thực hiện deny các đối số request hoặc các
REQUEST_HEADERS chứa chuỗi “park”.
2.4.7. Tạo chain rule- chuỗi các luật
Chain là một action được đặt bên trong các luật khi muốn tạo ra chuỗi
các luật.
Xét ví dụ sau: bạn là chủ một website, bạn muốn block một số trình
download gây hại cho website của bạn từ một số client. Tuy nhiên bạn không
thể block tất cả các client sử dụng trình duyệt download đó.

19

Sau khi phân tích các request bạn thấy các request gây hại cho website có
các chuỗi user-agent chứa “Red Bullet” và có địa chỉ IP thuộc về lớp mạng
192.168.1.0/24.
Như vậy bạn có thể thiết lập các luật là:
- Luật deny các request có User-Agent chứa “Ret Bullet”
SecRule REQUEST_HEADERS:User-Agent “Red Bullet”
“deny”
- Và client có địa chỉ IP thuộc về lớp mạng 192.168.1.0/24
SecRule REMOTE_ADDR “192\.168\.1.\”
Kết hợp các luật lại như sau:
SecRule REQUEST_HEADERS:User-Agent “Red Bullet” “chain,deny”
SecRule REMOTE_ADDR “192\.168\.1.\”
Khi tạo chain rules cần chú ý:
- Các action như deny, log, msg, id, rev, tag, severity, logdata chỉ
được đặt trong luật đầu tiên của chain.
- Các rule của cùng một chain viết liền sau và đặt action chain
trong các luật của chain (trừ luật cuối cùng).
Tiếp tục với ví dụ trên, nếu bạn chỉ muốn thực hiện chain trước 6 giờ tối
thì chain rules là:
SecRule REQUEST_HEADERS:User-Agent “Red Bullet” “chain,deny”
SecRule REMOTE_ADDR “192\.168\.1.\” “chain”
SecRule TIME_HOUR “@LT 18”

20


CHƯƠNG III – TRIỂN KHAI CÀI ĐẶT CẤU HÌNH MODSECURITY
CHO MÁY CHỦ WEB APACHE
3.1. Chuẩn bị
- Máy ảo chạy hệ điều hành CentOS 7 đã cấu hình và cài đặt

website sử dụng Apache, PHP, MariaDB.
- Máy ảo chạy hệ điều hành Kali.
3.2. Xây dựng kịch bản

Hình 3.1: Mô hình triển khai
- Máy ảo Web linux CentOS chạy website: Apache, PHP,
MariaDB, Mod_security.
- Máy ảo Windows 7 thực hiện tấn công SQL Injection.
3.3. Các bước thực hiện
Thực hiện trên máy CentOS
- Xây dựng website có lỗ hổng bảo mật
- Từ máy Windows 7 thực hiện tấn công SQL Injection vào máy
chủ web
- Cài đặt mod_security lên máy chủ web
- Thực hiện tấn công lại và kiểm tra kết quả
3.4. Cài đặt website có lỗ hổng bảo mật
3.4.1. DVWA
Damn Vulnerable Web Application (DVWA) là một ứng dụng mã nguồn
PHP/MySQL tập hợp sẵn các lỗi logic về bảo mật ứng dụng web trong mã
nguồn PHP. Lỗi logic khi lập trình có thể áp dụng đối với các loại ngôn ngữ
lập trình nhằm giảm thiểu khả năng tạo ra lổ hổng bảo mật từ tư duy lập trình
chưa cẩn thận.

21


Hình 3.2: DVWA
Mục tiêu chính của DVWA đó là tạo ra một môi trường thực hành
pentest hợp pháp. Giúp cho các nhà phát triển ứng dụng web hiểu hơn về hoạt
động lập trình an toàn và bảo mật hơn. Bên cạnh đó DVWA cũng cung cấp

cho các pentester phương pháp học và thực hành tấn công khai thác lỗi bảo
mật ứng dụng web ở mức cơ bản và nâng cao.
Dự án DVWA đã được khai sinh từ tháng 12/2008 và phát triển rất nhanh
chóng cũng như sớm nổi tiếng.
3.4.2. Thực hiện
Ở đây, ta sử dụng DVWA làm trang web có lỗ hổng bảo mật cài trên máy
chủ Web Linux CentOS đã cài sẵn: Apache, MariaDB, PHP, PHPMyAdmin.
Sau khi download và cấu hình, ta có giao diện web như sau:

22


Hình 3.3: Giao diện trang web có lỗ hổng bảo mật
3.5. Thực hiện tấn công SQL Injection lên máy chủ web
Ta truy cập từ máy ảo Windows đến máy chủ web server thông qua
putty, lựa chọn giao thức ssh.
Thực hiện tấn công SQL Injection lên trang web có lỗ hổng bảo mật và
khai thác được các thông tin như hình sau:

Hình 3.4: Giao diện khai thác thông tin

23


3.6. Cài đặt mod_security lên máy chủ Linux CentOS
3.6.1. Cài đặt và cấu hình mod_security
Đầu tiên ta phải cài đặt các thư viện cần thiết:
yum install httpd-devel libxml2-devel pcre-devel apr-devel
apr-util-devel curl-devel –y

Tiếp theo, ta tiến hành cài đặt modsecurity với câu lệnh sau:
yum install mod_security

Hình 3.5: Cài đặt modsecurity
Sau khi đã cài đặt xong, ta tiến hành cấu hình modsecurity:
Đầu tiên, ta tìm file config mà ta cần với câu lệnh:
cd /etc/httpd/conf.d

24