HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN

----------

BÀI TẬP LỚN

AN TOÀN WEB VÀ CƠ SỞ DỮ LIỆU
Đề tài: TÌM HIỂU VỀ TƯỜNG LỬA ỨNG DỤNG WEB
(WEP APPLICATION FIREWALLS) VÀ TÌM HIỂU KIẾN
TRÚC HOẠT ĐỘNG, TẠO LUẬT CỦA MODSECURITY.

Giảng viên: Hoàng Xuân Dậu

Nhóm 2: Cao Ngọc Dũng
Nguyễn Thị Duyên
Nguyễn Thùy Dương
Vũ Hồng Dương
Phạm Thành Đạt

Hà Nội, ngày 29 tháng 9 năm 2019

Page | 0
 MỤC LỤC
PHẦN I: TÌM HIỂU KHÁI QUÁT VỀ TƯỜNG LỬA ỨNG DỤNG WEB (WEB
APPLICATION FIREWALL) .................................................................................................... 2
1.1. Giới thiệu tổng quan về web application firewall ....................................................... 2
1.2. Mô hình bảo mật của WAF ........................................................................................... 3
1.2.1. Mô hình Positive: ..................................................................................................... 3
1.2.2. Mô hình Negative: ................................................................................................... 3
1.3. Mô hình hoạt động của WAF ........................................................................................ 4
1.3.1. Reverse Proxy: ........................................................................................................ 4
1.3.2. Layer 2 Brigde: ....................................................................................................... 4
1.3.3. Out-of-Band: ........................................................................................................... 5
1.3.4. Server Resident: ...................................................................................................... 5
1.3.5. Internet Hosted / Cloud: ......................................................................................... 6
1.4. Các phiên bản WAF mã nguồn mở phổ biến .................................................................. 6
PHẦN II: TÌM HIỂU VỀ ỨNG DỤNG MODSECURITY....................................................... 7
2.1. Tổng quan ............................................................................................................................ 7
2.2. Hoạt động............................................................................................................................. 8
2.3. Tạo luật .............................................................................................................................. 10
2.4. Cài đặt ModSecurity ........................................................................................................ 17
2.4.1. Cài đặt trên môi trường windows ............................................................................... 17
2.4.2. Cài đặt trên môi trường Ubuntu ................................................................................. 18
2.4.3. Cài đặt trên CentOS ..................................................................................................... 19
2.5. Demo Mod security trên Apache Windows ................................................................... 20
Kết Luận ...................................................................................................................................... 22
Tài Liệu Tham Khảo .................................................................................................................. 23

Page | 1
PHẦN I: TÌM HIỂU KHÁI QUÁT VỀ TƯỜNG LỬA ỨNG
DỤNG WEB (WEB APPLICATION FIREWALL)

1.1. Giới thiệu tổng quan về web application firewall

Trong những năm gần đây, xu hướng tấn công vào ứng dụng web đang ngày càng
trở nên phổ biến. Các kỹ thuật tấn công chủ yếu là: Cross-site scripting, SQL injection và
nhiều các kỹ thuật khác… Tất cả các kỹ thuật này đều nhắm vào lớp ứng dụng trong mô
hình OSI. Các lỗ hổng trong ứng dụng web chủ yếu xảy ra do người lập trình, cấu hình hệ
thống và các lỗ hổng trong các nền tảng, thư viện
Tường lửa ứng dụng web (Web Application Firewall – WAF) là một giải pháp
nhằm bảo vệ cho ứng dụng web tránh khỏi các lỗi bảo mật web nói trên. WAF là một
thiết bị phần cứng hoặc phần mềm được cài lên máy chủ có chức năng theo dõi các thông
tin được truyền qua giao thức http/https giữa trình duyệt của người dùng và máy chủ web
tại lớp 7. Một WAF có khả năng thực thi các chính sách bảo mật dựa trên các dấu hiệu
tấn công, các giao thức tiêu chuẩn và các lưu lượng truy cập ứng dụng web bất thường.
Đây là điều mà các tường lửa mạng khác không làm được.
Tường lửa ứng dụng web ( web application firewalls – web ) được thiết kể để bảo
vệ web application tránh khỏi các lỗi bảo mật và các cuộc tấn công từ hacker. WAF như là
một cái khiên, như là một cái lá chắn để bảo vệ web application chạy trên giao thức HTTP
(giao thức không an toàn).
WAF được đặt ở phía trước của web application, nó sẽ giám sát các hoạt động ứng
dụng và cảnh bảo hoặc block traffic nếu phát hiện ra nguy hiểm. Mục đích là để nắm bắt
các cuộc tấn công vào ứng dụng web như là : SQL injection, xss,…

Hình 1.1. Mô hình của một hệ thống Tường lửa ứng dụng Web (WAF)

Page | 2
1.2. Mô hình bảo mật của WAF
WAFs so sánh dấu hiệu của 1 cuộc tấn công với chính sách an toàn của ứng dụng
cho ứng dụng web đang được bảo vệ để cảnh báo hoặc ngăn chặn sự vi phạm đó.
WAF có thể dùng theo 1 trong 2 mô hình negative hoặc positive để phát triển các
chính sách bảo mật cho một ứng dụng.
Mô hình Positive (whitelist) chỉ cho phép các lưu lượng hợp lệ được định nghĩa
sẵn đi qua và chặn tất cả các lưu lượng còn lại. Mô hình Negative sẽ cho phép tất cả các
lưu lượng vượt qua và chỉ chặn các lưu lượng được mà WAF cho là nguy hại. Đôi khi
cũng có các WAF cung cấp cả 2 mô hình trên, tuy nhiên thông thường WAF chỉ cung cấp
1 trong 2 mô hình. Với mô hình Postitive thì đòi hỏi nhiều cấu hình và tùy chỉnh, còn mô
hình Negative chủ yếu dựa vào khả năng học hỏi và phân tích hành vi của lưu lượng
mạng.
Tóm lại :
1.2.1. Mô hình Positive:

 Bạn cho phép lưu lượng hợp lệ đi qua, tất cả lưu lượng còn lại bị chặn
 Ưu điểm: Độ bảo mật , an toàn cao hơn mô hình Negative.
 Khuyết điểm: Yêu cầu phải có sẵn “Danh sách hợp lệ” (Whitelisting) để không
nhầm lẫn trong việc chặn những người truy cập hợp pháp.

1.2.2. Mô hình Negative:

 Bạn chủ động chặn những lưu lượng bất hợp pháp, tất cả lưu lượng còn lại đều
được cho phép đi qua.
 Ưu điểm: Dễ dàng triển khai thực hiện trong hầu hết trường hợp.
 Khuyết điểm: Dễ dàng bị tấn công khi người dùng bất hợp pháp không có trong
danh sách bị chặn

Page | 3
1.3. Mô hình hoạt động của WAF
WAF có thể hoạt động ở các mô hình riêng biệt, dưới đây là một số mô hình:

1.3.1. Reverse Proxy:

Đây là chức năng được sử dụng phổ biến khi triển khai WAF. Trong mô hình này,
WAF giám sát tất cả các lưu lượng đi đến ứng dụng web, sau đó thay vì cho các địa chỉ IP
bên ngoài gửi yêu cầu trực tiếp đến máy chủ web thì WAF đứng ra làm trung gian để gửi
các yêu cầu này đến máy chủ web thay cho trình duyệt gốc rồi gửi trả lại kết quả cho các
địa chỉ IP kia. Mô hình này có nhược điểm là tạo ra độ trễ khi kết nối từ trình duyệt đến
ứng dụng web.

Hình 1.2. Reverse Proxy

1.3.2. Layer 2 Brigde:
Ở mô hình này, WAF đứng giữa tường lủa mạng và máy chủ web, nhưng
hoạt động giống như một thiết bị Switch ở lớp 2. Mô hình này giúp mạng hoạt động
với hiệu năng cao và mạng thay đổi không đáng kể, tuy nhiên nó lại không thể cung
cấp các dịch vụ cao cấp khác mà các mô hình WAF khác có thể.

Hình 1.3. Layer 2 Brigde

Page | 4
1.3.3. Out-of-Band:
Ở mô hình này, WAF không trực tiếp đứng giữa tường lửa mạng và mày chủ
web như 2 mô hình kia nữa. Nó sẽ nhận được một bản copy của các lưu lượng đi
đến ứng dụng web thông qua cổng giám sát trên thiết bị mạng. Nhược điểm của mô
hình này là khả năng block traffic còn rất hạn chế do nó chỉ gửi cái gói tin TCP-
reset để làm gián đoạn traffic.

Hình 1.4. Out-of-Band

1.3.4. Server Resident:

Là một phần mềm được cài đặt trong máy chủ web. Nó có thể hoạt động như
là một ứng dụng độc lập hoặc như là một web server plug-in.

Hình 1.5. Server Resident

Page | 5
1.3.5. Internet Hosted / Cloud:
Đây là một mô hình mới tuy nhiên nó càng ngày càng trở lên phổ biến. Mô
hình này sử dụng công nghệ điện toán đám mây để thực hiện các giải pháp WAF.
Nó hoạt động giống như tùy chọn proxy ngược – public DNS được cấu hình để trỏ
tới nhà cung cấp đám mây, sau đó tạo một kết nối khác với thuộc tính web.

Hình 1.6. Internet Hosted / Cloud

1.4. Các phiên bản WAF mã nguồn mở phổ biến

ModSecurity: Đây là phần mềm nguồn mở có thể hoạt động như một module trong
máy chủ Apache hoặc là một thành phần độc lập. ModSecurity sử dụng biểu thức chính
quy trong việc bảo vệ máy chủ web từ các cuộc tấn công được xác định trước dựa theo các
dấu hiệu hoặc các cuộc tấn công bất thường khác. Bên cạnh đó, ModSecurity cũng có khả
năng lọc các siêu ký tự do người dùng chèn vào ứng dụng web.

URLScan: Đây là một sản phẩm của Microsoft dành riêng cho các máy chủ web
IIS. URL scan không chỉ bảo vệ máy chủ IIS 6 khỏi các điểm yếu từ các phiên bản cũ hơn
mà còn cung cấp thêm các biện pháp bảo vệ khác như lọc dữ liệu mã hóa trên URL hoặc
lọc các siêu ký tự do người dùng chèn vào để chống lại các loại tấn công như XSS, SQL
Injection,…

WebKnight: Đây cũng là 1 sản phẩm dành cho các máy chủ web IIS.
Page | 6
PHẦN II: TÌM HIỂU VỀ ỨNG DỤNG MODSECURITY

2.1 . Tổng quan

- ModSecurity là một web application firewall (WAF) được Ivan Ristic phát triển
dành cho Apache Web Server. Giống như những firewall thông thường khác, nó lọc những
lưu lượng dữ liệu vào và ra để có thể quyết định chặn lại những lưu lượng mà nó nghi ngờ
là độc hại dựa theo tập lệnh nó định nghĩa. Nó còn có nhiều tính năng vượt trội khác như:
HTTP transaction logging và content injection…
- Các luật được tạo và chỉnh sửa sử dụng một định dạng văn bản đơn giản, nó làm
cho việc viết rules trở nên đơn giản hơn. Một khi đã quen với cú pháp của ModSecurity,
chúng ta có thể nhanh chóng viết được những rules để block một exploit mới hoặc ngăn
chặn một lỗ hổng.
- Có thể hình dung ModSecurity như là một trạm trung gian giữa HTTP request và
HTTPD (dịch vụ web server). Khi phát hiện ra một cuộc tấn công, những chi tiết về vụ tấn
công sẽ được lưu vào log file hoặc một email có thể được gửi tới người quản trị viên để
báo hiệu có một cuộc tấn công xảy ra trên hệ thống.
- ModSecurity cho phép bạn bảo vệ server của mình thông qua việc viết các luật
nhằm bao phủ một dải các viễn cảnh tấn công có thể. Do đó, ModSecurity là một lớp bổ
sung có thể giúp bạn bảo vệ theo một cách không cần bản vá.

Hình 2.1. ModSecurity đặt trước web server

Page | 7
 - ModSecurity giải quyết các vấn đề giám sát : nó giúp bạn nhìn thấy lưu lượng web
của mình. Đó là chìa khóa trong security: mỗi khi bạn có thế nhìn thấy HTTP traffic, bạn
có thể phân tích nó trong thời gian thực, record nó khi cần thiết và phàn ứng lại với các sự
kiện. Điểm nổi bật ở đây là bạn có thể làm tất cả mà không tác động gì tới các ứng dụng
web. Thậm chí tốt hơn, nó còn có thể áp dụng với bất kì ứng dụng nào, ngay cả khi bạn
không thể truy được vào source code.

2.2 . Hoạt động

 Quá trình xử lý các request của Apache và ModSecurity :
- Trong ModSecurity, mỗi phiên phân tích sẽ được thực hiện lần lượt qua 5 bước
(phase), 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.

Hình 2.2. Quá trình xử lý các request của Apache và mod security

Page | 8
  ModSecurity cho phép bạn đặt rule tại một trong năm thời điểm trong chu kỳ
xử lý của Apache như sau :
- Phase Request Header: rule được đặt tại đây sẽ được thực hiện ngay sau khi
Apache đọc request header, lúc này phần request body vẫn chưa được đọc. Đâ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 …
- Phase 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 rule mang tính application-oriented thường được đặt ở đây.
Bước này 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ư Stored XSS, Ajax Injection...
ModSecurity hỗ trợ ba loại mã hóa 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ữ l iệu XML.
- Phase Response Header: 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ề.
- Phase Response Body: 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 ở
phase request header và phase request body không phát hiện được tấn công.

Page | 9
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.
- Phase Logging : đây 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 để bạn chặn các connection không mong muốn, kiểm tra
các response header mà bạn không thể kiểm tra ở phase response header và phase response
body.

2.3 . Tạo luật

2.3.1. Xây dựng luật như thế nào ?
 HTTP request
GET /books/search.asp?q=example HTTP/1.1
Host: example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Accept: image/gif, image/xxbitmap, image/jpeg, image/pjpeg,
application/xshockwaveflash, application/vnd.msexcel,
application/vnd.mspowerpoint, application/msword, */*
Accept-Language: en-gb,en-us;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://example.com/books/default.asp
Cookie: lang=en; JSESSIONID=0000tI8rk7joMx44S2Uu85nSWc_:vsnlc502
Toàn bộ thông tin của HTTP request thể hiện thông qua một số trường :
Dòng đầu tiên : cho biết đang sử dụng phương thức GET. Phiên bản HTTP được sử dụng
là 1.1.
- Referer : cho biết URL đang sử dụng có nguồn gốc từ địa chỉ nào. Ở ví dụ trên
Referer cho thấy truy vấn /books/search.asp?q=example được gửi từ địa chỉ
http://example.com/books/default.asp.
- Host : cho biết đang gửi truy vấn đến host nào.

Page | 10
 - User-Agent : cung cấp cho web server biết ta đang dùng trình duyệt nào.
- Cookie : được gửi lại lên webserver nếu trước đây đã từng truy cập địa chỉ này.
- ModSecurity sẽ sử dụng thông tin trong các luật của nó để càn lọc các requests. Và
không chỉ trong header, ModSecurity cũng có thể xem xét cả POST payload như đã
nhắc tới ở trên,…
Chẳng hạn chúng ta có thể cấm request có Referer là www.abc.com bằng luật sau :
SecRule HTTP_Referer “www\.abc\.com”
2.3.2. Cấu trúc rules
SecRule VARIABLES OPERATOR [ACTIONS]

Variables
REMOTE_ADDR : Địa chỉ IP của client.
REMOTE_HOST : Hostname của client (nếu tồn tại) .
REMOTE_USER : Authenticated username (nếu tồn tại) .
REMOTE_IDENT : Remote Username (lấy từ inetd, ít dùng) .
REQUEST_METHOD : Request Method (GET, HEAD, POST..) .
SCRIPT_FILENAME : Đường dẫn đầy đủ của script được thực thi.
PATH_INFO : Phần mở rộng của URI phía sau tên của một script.
Ví dụ: /archive.php/5 thì PATH_INFO là /5
QUERY_STRING : URI phía sau dấu ?.
Ví dụ /index.php?i=1 thì QUERY_STRING là i=1.
AUTH_TYPE : Basic hoặc Digest Authentication.
DOCUMENT_ROOT : Đường dẫn đến documentroot.
SERVER_ADMIN : Email của Server Administrator.
SERVER_NAME : Hostname của Server.
SERVER_ADDR : Địa chỉ IP của Server.
SERVER_PORT : Server port.
SERVER_PROTOCOL : Protocol, (ví dụ HTTP/1.1).
SERVER_SOFTWARE : Apache version.
TIME_YEAR : Năm hiện tại (2014).
Page | 11
 TIME_MON : Tháng hiện tại (12).
TIME_DAY : Ngày.
TIME_HOUR : Giờ.
TIME_MIN : Phút.
TIME_SEC : Giây.
TIME_WDAY : Thứ tự ngày trong tuần (ví dụ 4 - Thursday).
TIME : Thời điểm hiện tại được viết theo cấu trúc : YmdHMS.
ví dụ: 20060220144530 : 20/02/2006 14h 45' 30''.
API_VERSION
THE_REQUEST : Dòng đầu tiên của request. vd: GET / HTTP/1.1.
REQUEST_URI : Request URI.
FILENAME : Tên file được yêu cầu đến.
IS_SUBREQ

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.
Biểu thức Ý nghĩa phù hợp
[Jj]oy Thể hiện mọi chuỗi có chứa Joy hoặc joy
[0-9] Bất kỳ số nào từ 0 đến 9
[a-zA-Z] Mọi chữ từ a đên z và từ A đến Z
^ Bắt đầu một chuỗi
^Host Từ Host khi tìm thấy ở đầu 1 chuỗi
$ Kết thúc một chuỗi
^Host$ Chuỗi chỉ gồm từ Host
. Một từ bất kỳ

Page | 12
 p.t Ví dụ như pot,pet,pat,…

Toán tử Tác dụng Ví dụ

@beginsWith Khớp các chuỗi bắt đầu với chuỗi chỉ SecRule REQUEST_LINE
định “!@beginsWith GET”
@containts Khớp các chuỗi có chứa chuỗi chỉ định SecRule REQUEST_LINE
tại bất cứ vị trí nào “@contains select”
@containsWord Khớp xâu chứa từ được chỉ định. “Từ” ở SecRule
đây được hiểu là đoạn xâu được ngăn bởi ARGS “@containsWord
một hoặc nhiều ký tự không phải chữ, số. 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à một so SecRule REMOTE_USER
khớp xảy ra khi biến cần so xuất hiện bên “@within cuong,nam,an”
trong xâu được chỉ định (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 SecRule ARGS "@pm red
nó green blue" deny
@pmFromFile Nếu có quá nhiều chuỗi muốn đặt vào, ta SecRule ARGS
có thể liệt kê các chuỗi này vào một file “@pmFromFile
và dùng @pmFromFile /usr/log/alo.txt”

Toán tử Toán tử đại số Ví dụ

tương đương
@eq = SecRule RESPONSE_STATUS “@eq 200”

Page | 13
 @ge ≥ SecRule RESPONSE_STATUS “@ge 400”
@gt > SecRule RESPONSE_STATUS “@gt 399”
@le ≤ SecRule RESPONSE_STATUS “@le 199”
@lt < SecRule RESPONSE_STATUS “@lt 200”

Actions
Khi request vi phạm một rule nào đó thì ModSecurity 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ó 4 primary actions :
Deny : Request sẽ bị ngắt, ModSecurity 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ì ModSecurity 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.

Page | 14
 nolog : không ghi log
pause : n : ModSecurity 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 : ModSecurity 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"
2.3.3. Logs

Debug Log
Sử dụng SecDebugLog directive lựa chọn file để ghi lại các thông tin debug
SecDebugLog logs/modsec-debug.log
Bạn có thể thay đổi mức độ chi tiết các thông tin được log thông qua directive :
SecDebugLogLevel 4
Giá trị log có thể thay đổi từ 0-9 :
0 - no logging.
1 - errors (intercepted requests) only.
2 - warnings.
3 - notices.
4 - details of how transactions are handled.
5 - as above, but including information about each piece of information handled.
9 - log everything, including very detailed debugging information.

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. ModSecurity hỗ trợ audit loging với đầy đủ thông tin và từ đó có thể

Page | 15
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
Ngoài ra còn có
SecAuditLog2 logs/audit2.log : Chỉ ra file lưu trữ log phụ
Đây là một ví dụ của audit log :
==378bfd37==============================
Request: conmaz.com 203.160.1.170 - - [20/Feb/2006:02:21:52 --0600]
"GET /favicon.ico HTTP/1.1" 403 285 "-" "-" - "-"
----------------------------------------
GET /favicon.ico HTTP/1.1
Cookie: rocker=r0xker
Host: conmaz.com
Connection: Keep-Alive
mod_security-message: Access denied with code 403. Pattern match
"^$" at HEADER("User-Agent")
mod_security-action: 403
HTTP/1.1 403 Forbidden
Content-Length: 285
Keep-Alive: timeout=5, max=29
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--378bfd37—

Tùy biến log

SecAuditEngine chấp nhận 3 giá trị sau :
On : Log tất cả các requests.

Page | 16
 Off : Không log.
RelevantOnly : Chỉ log những gì được sinh ra bởi các bộ lọc rules.
Ngoài ra ModSecurity còn hỗ trợ log dựa vào status code , ví dụ bạn cần log lại
những requests gây ra lỗi 5xx :
SecAuditLogRelevantStatus ^5

2.4. Cài đặt ModSecurity

2.4.1. Cài đặt trên môi trường windows
Bước 1: Download gói trên trang chủ XAMPP

Bước 2: Cài đặt gói vào thư mục mặc định C:\Xampp

Bước 3: Download Mod Security 2.8

https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz

Trên trang này đã có các file thư viện và các file liên quan tới ModSecurity đã được biên
dịch, nếu các bạn muốn có các file này có thể tự dùng môi trường Visual Studio và Linux
để biên dịch cho Apache trên Windows

Bước 4:
Cấu hình ModSecurity

Sau khi download ta giải nén và đọc file readme.1st.txt và làm theo các bước sau:
– Cài đặt thư viện Visual C++ 2012 Redistributable Package theo các phiên bản của hệ
điều hành 32b hoặc 64bit trên trang Microsoft.
– Copy mod_security2.so vào C:\xampp\apache\modules
– Copy and libxml2.dll và pcre.dll vào C:\xampp\apache\bin
– Mở file httpd.conf tại C:\xampp\apache\conf và thêm dòng sau:
LoadModule security2_module modules/mod_security2.so
Đồng thời bỏ dấu # trước dòng:
LoadModule unique_id_module modules/mod_unique_id.so

Bước 5:
Thêm các lệnh sau vào file httpd.conf phía dưới các lệnh đã thực hiện ở trên
– SecRuleEngine DetectionOnly

Ta thêm dòng lệnh sau để kích hoạt chế độ hoạt động cho các luật

Page | 17
– SecRuleEngine On

Và thêm câu lệnh dưới đây để kiểm tra sự hoạt động của Mod hay chưa

– SecRule ARGS, “hack” phase:1,log,deny,status:503,id:1

Lệnh trên sẽ được kích hoạt khi ta gõ trên thanh địa chỉ của trình duyệt như sau
http://localhost/a=hack
Vì trên Mod sẽ phân tích request và so khớp hack trong luật và đưa ra cảnh báo có mả 503
(cấm)
Như vậy Mod Security đã được cài đặt thành công trên Apache Windows

2.4.2. Cài đặt trên môi trường Ubuntu

Đầu tiên, tiến hành update và upgrade hệ thống bằng 2 dòng lệnh:
apt-get upgrade
apt-get update
Sau đó gõ dòng lệnh cài đặt gói build-essential:
apt-get install build-essential
Sau đó tiến hành cài đặt apache trên Ubuntu:
apt-get install apache2
Tiếp theo, các tải các gói bắt buộc phải có để có thể cài đặt Modsecurity trên Ubuntu:
apt-get install libxml2-dev libcurl4-openssl-dev liblua5.1-0 liblua5.1-0-dev
Bước kế tiếp, các bạn tải gói source code Modserity 2.8 về từ trang chủ bằng dòng lệnh:
wget https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz
Tiếp theo, các bạn tải gói rule của Modsecurity về bằng dòng lệnh :
wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/master.zip
Các bạn tiến hành giải nén 2 gói đã tải về để cài đặt:
tar -xzf modsecurity-2.8.0.tar.gz
unzip master.zip
Tiếp theo các bạn di chuyển đến file modsecurity đã giải nén bằng dòng lệnh:
cd modsecurity-2.8.0
Ta tiến hành build và cài đặt:
./configure
make && make install
Sau khi cài đặt xong, ta tiến hành tích hợp modsecurity vào apache bằng các dòng lệnh:
cp modsecurity.conf-recommended /etc/apache2/conf.d/modsecurity.conf
touch /etc/apache2/conf.d/unicode.mapping
Các bạn di chuyển ra ngoài file modsecurity và tiến hành copy file rule mà các bạn đã giải
nén khi nãy (file master.zip):
cd ../
mv owasp-modsecurity-crs-master/ /etc/apache2/modsecurity-crs
Các bạn đổi tên file modsecurity_crs_10_setup.conf.example trong thư mục
/etc/apache/modsecurity-crs:

Page | 18
 cd /etc/apache2/modsecurity-crs/
cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
Sau đó các bạn tiến hành chỉnh sửa file modsecurity.conf (Ở đây tôi dùng trình soạn thảo
gedit để chỉnh sửa).
gedit /etc/apache2/conf.d/modsecurity.conf
Các bạn sửa dòng:
gine DetectionOnly
Thành:
SecRuleEngine On
Các bạn tạo file modsecurity riêng của mình để chứa rule mình viết (để tiện cho việc chỉnh
sửa):
mkdir /etc/apache2/modsecurity
Tiếp theo các bạn thêm đoạn dưới đây vào cuối file apache2.conf ở đường dẫn
/etc/apache2/apache2.conf
<IfModule security2_module>
Include modsecurity-crs/modsecurity_crs_10_setup.conf
Include modsecurity-crs/base_rule/*.conf
Include modsecurity/*.conf
</IfModule>
Các bạn tạo một file mod_seucurity2.load và thêm vào nội dung vào file mới tạo:
gedit /etc/apache2/mods-available/mod_security2.load

Và thêm vào file nội dung:

LoadModule security2_module /usr/lib/apache2/modules/modsecurity2.so
Các bạn tiến hành thêm dòng lệnh:
cd /etc/apache2/mods-enabled && ln –s ../mods-available/mod_security2.load
mod_security2.load
cd /etc/apache2/mods-enable && ln –s ../mods-available/unique_id.load
unique_id.load.

2.4.3. Cài đặt trên CentOS

- Cài đặt các gói cần thiết trước khi cài đặt Modsecurity
yum install gcc c++ libxml2 libxml2-devel httpd-devel pcre-devel curl-devel
yum install zlib-devel
yum install glibc-static
yum install libz*
yum install expat-devel

- Tải và cài đặt Modsecurity

cd /usr/src
wget https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz
gunzip modsecurity-2.8.0.tar.gz

Page | 19
tar -xvf modsecurity-2.8.0.tar
cd modsecurity-2.8.0
./configure
make
make install

2.5. Demo Mod security trên Apache Windows

Bước 1: Download gói trên trang chủ XAMPP
Bước 2: Cài đặt gói vào thư mục mặc định C:\Xampp
Bước 3: Download Mod Security 2.8 (bản mới nhất 7/2014) cho Apache 2.4.x trên trang
(http://achehaus.com/)
Trên trang này đã có các file thư viện và các file liên quan tới Modsecurity đã được biên
dịch, nếu các bạn muốn có các file này có thể tự dùng môi trường Visual Studio và Linux
để biên dịch cho Apache trên Windows
Bước 4: Cấu hình Mod
Sau khi download ta giải nén và đọc file readme.1st.txt và làm theo các bước sau:
- Cài đặt thư viện Visual C++ 2012 Redistributable Package theo các phiên
bản của hệ điều hành 32b hoặc 64bit trên trang Microsoft.
- Copy mod_security2.so vào C:\xampp\apache\modules
- Copy and libxml2.dll và pcre.dll vào C:\xampp\apache\bin
- Mở file httpd.conf tại C:\xampp\apache\conf và thêm dòng sau:
LoadModule security2_module modules/mod_security2.so
Đồng thời bỏ dấu # trước dòng:
LoadModule unique_id_module modules/mod_unique_id.so

Bước 5: thêm các lệnh sau vào file httpd.conf phía dưới các lệnh đã thực hiện ở trên
- SecRuleEngine DetectionOnly

Ta thêm dòng lệnh sau để kích hoạt chế độ hoạt động cho các luật

Page | 20
 - SecRuleEngine On

Hình 2.3. Cài đặt modsecurity trong apache

Và thêm câu lệnh dưới đây để kiểm tra sự hoạt động của Mod hay chưa

- SecRule ARGS, “hack” phase:1,log,deny,status:503,id:1

Lệnh trên sẽ được kích hoạt khi ta gõ trên thanh địa chỉ của trình duyệt như sau
http://localhost/?a=hack
Vì trên Mod sẽ phân tích request và so khớp hack trong luật và đưa ra cảnh báo có mả
503 (cấm)

Page | 21
 Hình 2.4. Lỗi sau khi cài đặt luật không thể truy cập được

Khi kiểm tra file error trong log apache sẽ thấy báo lỗi.

Hình 2.5. Kiểm tra file log trong apache

Kết Luận
Qua bài viết trên chúng em đã tìm hiểu về tường lửa trong ứng dụng web. Các khái niệm,
các loại ứng dụng của Web application firewall và kiến trúc hoạt động, tạo luật trong
modsecurity.
Tường lửa ứng dụng web (Web Application Firewall – WAF) là một giải pháp nhằm bảo
vệ cho ứng dụng web tránh khỏi các lỗi bảo mật Cross-site scripting, SQL injection và nhiều các
kỹ thuật khác… WAF là một thiết bị phần cứng hoặc phần mềm được cài lên máy chủ có chức
năng theo dõi các thông tin được truyền qua giao thức http/https giữa trình duyệt của người dùng
và máy chủ web tại lớp 7.
Modsecurity là một Web application firewall, cũng giống như những firewall thông
thường khác, nó lọc những lưu lượng dữ liệu vào và ra để có thể quyết định chặn lại những lưu
lượng mà nó nghi ngờ là độc hại dựa theo tập lệnh nó định nghĩa. Nó còn có nhiều tính năng

Page | 22
vượt trội khác như : HTTP transaction logging và content injection… Các luật được tạo và chỉnh
sửa sử dụng một định dạng văn bản đơn giản, nó làm cho việc viết rules trở nên đơn giản hơn.

Tài Liệu Tham Khảo

[1] SANS Institude, “Web application firewalls,” 2015.
[2] “Tìm hiểu về Modsecurity.” [Online]. Available:
http://scorpionit.blogspot.com/2016/03/toc-h-z-t-chuongi-gioi-thieu-ve-mod.html.
[3] anninhmang.net, “Giới thiệu và cài đặt Mod_security.” [Online]. Available:
https://anninhmang.net/bao-mat/gioi-thieu-va-cai-dat-mod_security-phan-1/.
[4] Nguyễn Hồng Hải Đăng, “Modsecurity - Cài Đặt Modsecurity Từ Source Code,” 2015.
[Online]. Available: https://www.stdio.vn/articles/modsecurity-cai-dat-modsecurity-tu-
source-code-178.
[5] “Cài đặt cấu hình Modsecurity trên CentOS 6.5.” [Online]. Available:
https://portal.kdata.vn/knowledgebase.php?action=displayarticle&id=11.

Page | 23