đề tài tìm hiểu mod_security và demo tính năng

Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
ĐỀ TÀI
TÌM HIỂU MOD_SECURITY
VÀ DEMO TÍNH NĂNG
MSSV Họ Tên Lớp
10348551 Nguyễn Đức Lợi DHTH4ATLT
10321271 Dương Hiễn Lãm DHTH4BTLT
10356381 Nguyễn Phạm Hoàng Duy DHTH4BTLT
10244481 Trịnh Minh Tiến DHTH6C
09076271 Trần Công Chính DHTH5C
11234421 Trần Anh Thiện DHTH7B
11262121 Từ Kỷ DHTH7B
1
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Mục Lục
Mục Lục 2
Chương 1: Giới thiệu 3
Chương 2: Modsecurity 4
I. Các khả năng của mod_security 5
II. Cài đặt 7
III. Cấu hình cơ bản 8
IV. Rules 9
V. Logging 13
VI. Xây dựng chính sách trên Modsecurity chống lại một số tấn công 15
Chương 3: Kịch bản demo 20
Tài liệu tham khảo 21
2
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Chương 1: Giới thiệu
Tường lửa ứng dụng web không phổ biến như tường lửa mạng, nhưng nó
đã được đề cập đến trong các tin tức, bài báo và hội thảo bảo mật hiện

nay. Các doanh nghiệp đã chấp nhận sử dụng công nghệ này bởi vì nó
nâng cao an toàn web một cách đáng kể. Nhưng cấu hình, triển khai và
duy trì công nghệ mới này không hề đơn giản. Để triển khai chúng thành
công, bạn cần phải hiểu rõ các hoạt động của ứng dụng một cách đầy đủ
và cấu hình các quy tắc tường lửa một cách cẩn thận. Hơn nữa, chi phí để
mua được sản phẩm thương mại là rất đắt đỏ, chúng tôi khuyến khích bắt
đầu sử dụng với các sản phẩm mã nguồn mở, chẳng hạn ModSecurity, do
đó bạn có thể đưa ra quyết định, nếu giải pháp này là thích hợp với ngân
sách và môi trường mạng của bạn.
Trong vài năm gần đây, các lỗ hổng ứng dụng web đã trở thành mối đe
dọa lớn nhất trong môi trường công nghệ thông tin. Theo cơ sở dữ liệu lổ
hổng mã nguồn mở (OSVDB), các mối đe dọa ứng dụng web chiếm hơn
50% tất cả các lỗ hổng trong năm 2010. Bạn không phải một chuyên gia
trong lĩnh vực IT để cấu hình các ứng dụng web đã trở nên sử dụng rộng
rãi trong cuộc sống cũng như trong kinh doanh. Do đó, bảo mật các ứng
dụng web đã trở thành một vấn đề quan trọng nhất mà bạn cần phải chú ý
như người dùng cuối hoặc một người kinh doanh.
Tường lửa ứng dụng web (WAF) là một dạng tường lửa nhằm lọc các lưu
lượng HTTP dựa trên một tập quy tắc. Nó kiểm tra ở mức ứng dụng vì
vậy nó thường đi kèm như một thiết bị hoặc một mô đun trong máy chủ,
có chức năng xác định và ngăn chặn các tấn công web phổ biến như
cross-site scritpting (XSS) và SQL injection bằng việc tùy chỉnh các quy
tắc. Do đó, việc tùy chỉnh các quy tắc này là rất đáng quan tâm và yêu
cầu bảo trì cao.
Có nhiều cách để bảo vệ ứng dụng web, chẳng hạn như thực hiện một
đoạn mã an toàn, quản lý cấu hình an toàn, thực hiện đánh giá lỗ hổng và
triển khai tường lửa ứng dụng web, nhưng không có một giải pháp nào là
hoàn hảo, việc sử dụng tường lửa ứng dụng web chỉ là một phương thức
bảo mật ứng dụng. Kỹ thuật này tương đối mới so với các công nghệ
khác, nhưng nó có thể trở thành một giải pháp hữu hiệu khi bạn cấu hình

và sử dụng nó đúng cách.
Trong bài giới thiệu này, Modsecurity sẽ được sử dụng để minh hoạ làm
thế nào bảo mật ứng dụng web sử dụng WAF. Modsecurity bảo vệ các
3
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
ứng dụng web từ nhiều cuộc tấn công và cho phép giám sát lưu lượng
HTTP với sự can thiệp không nhiều của cơ sở hạ tầng hiện có. Nó là một
mô đun mã nguồn mở của ứng dụng máy chủ web Apache và nó đã được
bảo trì bởi SpiderLabs, Trustwave. Từ khi nó là một sản phẩm mã nguồn
mở, nó mặc nhiên là miễn phí và nhiều người dùng sử dụng đã góp phần
cải thiện và duy trì sản phẩm này.
WAF không phải là một công cụ mà chỉ nhằm ngăn chặn các hoạt động
nguy hiểm tại lớp ứng dụng. Nó cũng có thể được sử dụng để phân tích
và phát hiện các lưu lượng nguy hiểm tấn công vào các ứng dụng. Do đó,
phần sau của loạt bài viết này sẽ minh họa làm thế nào phân tích các tấn
công web phổ biến sử dụng WAF để phát hiện và ghi lại các khả năng
cùng với nhật ký máy chủ Web Apache.
Chương 2: Modsecurity
Mod_security là một opensource web application firewall được Ivan
Ristic phát triển dành cho Apache Web Server. Ivan Ristic là tác giả
quyển sách.Ông là một người có rất nhiều kinh nghiệm trong bảo vệ
Apache Web Server. Ông đã có nhiều thời gian nghiên cứu Web
Application Security, Web Intrusion Detection, và Security Patterns.
Trước khi chuyển sang lĩnh vực security, Ivan đã có nhiều năm làm việc
như một developer, system architect, technical director trong phát triển
phần mềm. Ông là người sáng lập ra công ty ThinkingStone làm các dịch
vụ liên quan đến web application security.
Hiện tại mod_security sử dụng giấy phép GPL, hoàn toàn miễn phí.
Ngoài ra nếu muốn có sự hỗ trợ thì bạn có thể mua nó tại công ty
ThinkingStone của ông ()

4
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
I. Các khả năng của mod_security
- Request filtering : tất cả các request gửi đến web server đều được phân
tích và cản lọc (filter) trước khi chúng được đưa đến các modules khác để
xử lý.
- Anti-evasion techniques: paths và parameters được chuẩn hoá trước khi
phân tích để chống evasion techniques. Kỹ thuật này sẽ được thảo luận ở
phần sau.
- Understanding of the HTTP protocol: mod_security là web application
firewall nên nó có khả năng hiểu được HTTP protocol. Mod_security có
khả năng cản lọc dựa trên các thông tin ở HTTP Header hay có thể xem
xét đến từng parameters hay cookies của các requests vv
- POST payload analysis: ngoài việc cản lọc dựa trên HTTP Header,
mod_security có thể dựa trên nội dung (payload) của POST requests.
- Audit logging : mọi requests đều có thể được ghi lại (bao gồm cả POST )
để chúng ta có thể xem xét sau nếu cần.
- HTTPS filtering: mod_security có thể phân tích HTTPS.
- Compressed content filtering: mod_security sẽ phân tích sau khi đã
decompress các request data.
Quá trình xử lý các request của Apache và mod_security
5
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
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.
Phase Request Body: đây là thời điểm các thông tin chức năng chung
đưa vào vào được phân tích và xem xét, các rule mang tính application-

oriented thương được đặt ở đây. Ở thời điểm này bạn đã nhận đủ các
request argument và phần request body đã được đọc.Modsecurity hỗ trợ
ba loại mã hoá request body
+ application/x-www-form-urlencoded dùng để truyền form dữ liệu
+ multipart/form-data dùng để truyền file
+ text/xml dùng để phân tich dữ liệu XML
6
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Phase Response Header: đây là thời điểm ngay sau khi phần response
header được gửi trả về cho client. Bạn đặt rule ở đây nếu muốn giám sát
quá trình sau khi phần response được gửi đi.
Phase Response Body: đây là thời điểm bạn muốn kiểm tra những dữ
liệu HTML gửi trả về
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 cung 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 3 và phase 4.
II. Cài đặt
1. Download mod_security:
#wget
/>apache_2.5.13.tar.gz
2. Trước khi cài đặt
Cần các thư viện apxs, libxml2 và cần file mod_unique_id.so
Cài đặt thư viện
#yum install httpd-devel (cài apxs)
#yum install libxml2-devel
Thêm dòng sau vào file http.conf (file nằm trong /etc/httpd/conf) dòng
sau
LoadModule unique_id_module modules/mod_unique_id.so

(Chú ý: thêm vào đoạn có nhiều LoadModule đầu dòng)
3. Giải nén
#tar xzvf modsecurity-apache_2.5.13.tar.gz
4. Biên dịch
Tại thư mục apache2 gõ các lệnh sau
#./configure
7
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
#make
#make install
5. Tích hợp modsecurity vào apache
Thêm dòng sau vào file httpd.conf
LoadModule security2_module modules/mod_security2.so
6. Khởi động lại apache
#service httpd restart
III. Cấu hình cơ bản
1. File cấu hình
Modsecurity là application firewall thuộc loại rules-based, nghĩa chúng ta
cần thiết lập các luật (rules) để mod_security hoạt động. Các rules này
được thể hiện dưới dạng các chỉ thị (directives) và có thể đặt trực tiếp
trong file cấu hình Apache (thông thường là httpd.conf).
Ngoài ra có thể đặt các cấu hình này vào một file riêng, chẳng hạn
modsecurity.conf trong thư mục conf.d và sau đó chúng ta cần thêm vào
httpd.conf
Include conf.d/modsecurity.conf
(mặc định trong httpd.conf đã có dòng include conf.d/*.conf với dòng này
nó sẽ thực hiện tất cả các file có phần mở rộng là .conf)
2. Turning Rule on and off
Theo mặc định thì rule engine bị disable. Để kích hoạt modsecurity ta cần
thêm chỉ thị sau vào file cấu hình

SecRuleEngine On
Directive này dùng để điều khiển rule engine, chúng ta có thể sử dụng các
tuỳ chọn là On, Off hoặc DynamicOnly.
Off : Vô hiệu hoá modsecurity
DetectionOnly : Khi nó phù hợp một luật nào đó thì nó cũng không thực
hiện bất kì action nào. (nó rất có ích trong trường hợp muốn test một luật
nào đó mà không muốn nó block bất kì request nào có vấn đề với luật)
8
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
On : Các rules của modsecurity được áp dụng cho tất cả các nội dung
3. SecDefaultAction
Dùng để tạo các action mặc định. Khi tạo 1 luật mà không chỉ rõ hành
động cho luật đó nó sẽ thực hiện hành động mặc định
Ví dụ: SecDefaultAction "phase:2,deny,log,status:403"
IV. Rules
1. Xây dựng rules như thế nào?
HTTP request
GET /documentation/index.html HTTP/1.1
Host: www.modsecurity.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1)
ecko/20060124 Firefox/1.5.0.1
Accept:
text/xml,application/xml,application/xhtml+xml,
text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: />Cookie:__utmz=129890064.1139909500.1.1.utmccn=(direct)|

utmcsr=(direct)|utmcmd=(none);
__utma=129890064.347942152.1139909500.
1140275483.1140425527.13;
__utmb=129890064; __utmc=129890064
Xem xét request ở trên chúng ta có thể thấy các HTTP Header sau :
9
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
GET – Đây là request method
Host
User-Agent
Accept
Accept-Language
Accept-Encoding
Accept-Encoding
Keep-Alive
Connection
Referer
Modsecurity sẽ sử dụng thông tin này trong các rules 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 ta có cấm request có Referer là www.abc.com ta có rule sau:
SecRule HTTP_Referer “www\.abc\.com”
Không cho phép User-Agent có từ HotBar:
SecRule HTTP_User-Agent “HotBar”
2. Cấu trúc của rules
SecRule VARIABLES OPERATOR [ACTIONS]
2.1. Variables
SecRule ARGS dirty
Có thể dùng 1 hay nhiều variables
SecRule ARGS|REQUEST_HEADERS:User-Agent dirty

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,
10
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
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 (2006)
TIME_MON : Tháng hiện tại (2)
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
REQUEST_FILENAME : Tên file được yêu cầu đến.
IS_SUBREQ
2.2. Collections
Một variables có thể bao gồm 1 hay nhiều phần dữ liệu. Khi
variable có nhiều hơn 1 giá trị thì ta gọi nó là collection
Ví dụ: với variable ARGS ta có 2 thông số p, và q
SecRule ARGS:p dirty
11
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
SecRule ARGS:q dirty
2.3. Operators
Sử dụng @ để chỉ ra đây là một operation
SecRule ARGS "@rx dirty"
Sử dụng !@ để chỉ ra một operation negation
SecRule &ARGS "!@rx ^0$"
Ở đây chúng ta đề cập đến một operation là rx (regular expression).
RX quy định các thể hiện
[Jj]oy : thể hiện mọi chuỗi có chứa Joy hoặc joy
[0-9] : mọi số từ 0 tới 9
[a-zA-Z] : mọi chữ từ a đến z cả chũ thường lẫn in hoa
^ : bắt đầu một chuỗi
$ : kết thúc chuỗi
^abc$ : chuỗi chỉ bao gồm từ abc
. :mọi kĩ tự
p.t : ví dụ như pat,pet, pzt….
2.4. Actions
Khi request vi phạm một rule nào đó thì mod_security sẽ thực thi một
hành động (action). Khi action không được chỉ rõ trong rule thì rule đó sẽ

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

Khi một rule không chỉ rõ action thì rule đó sẽ dùng default action
được thiết lập trong SecDefaultAction.
Ví dụ : SecDefaultAction "phase:2,deny,log,status:403"
V. Logging
1. 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.
13
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
5 - as above, but including information about each piece of
information handled.
9 - log everything, including very detailed debugging information
2. Audit logging
Apache log ít thông tin vì thế nó không cho phép chúng ta có thể lần
ngược các bước của kẻ tấn công. Mod_security hỗ trợ audit loging với
đầy đủ thông tin và từ đó có thể lần ngược lại quá trình của kẻ tấn công,
cũng như là chỉnh sửa các rules cho hợp lý tránh bị “false positive”. Có 2
directives:
SecAuditEngine On : bật audit log lên
SecAuditLog logs/audit.log : chỉ ra file lưu trữ log chính

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
14
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Content-Type: text/html; charset=iso-8859-1
378bfd37—
3. Tuỳ biến thông tin log
SecAuditEngine chấp nhận 3 giá trị sau :
On – log tất cả các requests
Off – không log
RelevantOnly – chỉ log những gì được sinh ra bởi các bộ lọc
rules

Ngoài ra mod_security 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
VI. Xây dựng chính sách trên Modsecurity chống lại một số tấn công
1. SQL Injection
Các từ khóa chính thường sử dụng trong tấn công SQL Injection và các
regular expressions tương ứng
UNION SELECT union\s+select
UNION ALL SELECT union\s+all\s+select
INTO OUTFILE into\s+outfile
DROP TABLE drop\s+table
ALTER TABLE alter\s+table
LOAD_FILE load_file
SELECT * select\s+*
\s : được định nghĩa trong PCRE là một regular expression cho phép phát
hiện mọi khoảng trắng và cả các mã thay thế (%20)
Để chống lại tấn công SQL Injection, ta dựa vào các đặc điểm trên từ đó
đưa ra rule sau:
SecRule ARGS "union\s+select" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "union\s+all\s+select" "t:lowercase,deny,msg:'SQL
Injection'"
SecRule ARGS "into\s+outfile" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "drop\s+table" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "alter\s+table" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "load_file" "t:lowercase,deny,msg:'SQL Injection'"
SecRule ARGS "select\s+from" "t:lowercase,deny,msg:'SQL Injection'"
2. XSS Attack
15
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
2.1 Định nghĩa

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS
để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ
thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI,
JSP ) những thẻ HTML hay những đoạn mã script nguy hiểm có thể
gây nguy hại cho những người sử dụng khác. Trong đó, những đoạn mã
nguy hiểm được chèn vào hầu hết được viết bằng các Client-Site Script
như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.
Kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi
phổ biến nhất của Web Applications và mối đe doạ của chúng đối với
người sử dụng ngày càng lớn.
2.2 Hoạt động của XSS
Về cơ bản XSS cũng như SQL Injection hay Source Injection (sẽ được
giới thiệu ở phần sau), nó cũng là các request được gửi từ các máy client
tới server nhằm chèn vào đó các thông tin vượt quá tầm kiểm soát của
server. Nó có thể là một request được gửi từ các form dữ liệu hoặc cũng
có nằm trong request URI, ví dụ:
was
found !');</script>
Nếu truy cập vào địa chỉ trên, rất có thể trình duyệt sẽ hiện lên một thông
báo XSS was found !. Các đoạn mã trong thẻ <script> không hề bị giới
hạn bởi chúng hoàn toàn có thể thay thế bằng một file nguồn trên một
server khác thông qua thuộc tính src của thẻ <script>. Cũng chính vì lẽ
đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS.
Nhưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ
liệu nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS
chỉ gây tổn hại đối với website ở phía client mà nạn nhân trực tiếp là
những người khách duyệt site đó. Tất nhiên đôi khi các hacker cũng sử
dụng kĩ thuật này đề chiếm quyền điều khiển các website nhưng đó vẫn
chỉ tấn công vào bề mặt của website. Thật vậy, XSS là những Client-Side
Script, những đoạn mã này sẽ chỉ chạy bởi trình duyệt phía client do đó

XSS không làm ảnh hưởng đến hệ thống website nằm trên server.
16
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Mục tiêu tấn công của XSS không ai khác chính là những người sử dụng
khác của website, khi họ vô tình vào các trang có chứa các đoạn mã nguy
hiểm do các hacker để lại, họ có thể bị chuyển tới các website khác, đặt
lại homepage, hay nặng hơn là mất mật khẩu, mất cookie thậm chí máy
tính người truy cập có thể sẽ bị cài các loại virus, backdoor, worm
2.3 Ngăn chặn tấn công XSS
Đề ngăn chặn tấn công XSS, chúng ta phải đảm bảo tất cả dữ liệu mà
người dùng gởi lên đều được cản lọc. Cụ thể, chúng ta có thể thay thế
hoặc loại bỏ các ký tự, các chuỗi thường được dùng trong tấn công XSS
như đấu ngoặc góc (< và >), script
Dưới đây là danh sách các ký tự nên mã hoá khi được client cung cấp để
lưu vào cơ sở dữ liệu.
Bảng 3.1 Các ký tự nên mã hoá để ngăn chặn tấn công XSS
Nếu chúng ta muốn ngăn chặn tấn công với ModSecurity, dưới đây là
các đoạn script XSS phổ biến và các biểu thức chính quy để ngăn chặn
người dùng request chứa các chuỗi này.
17
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Bảng 3.2 Các script XSS và biểu thức chính quy
Sau đây là rule thực hiện:
SecRule ARGS "alert\s+*\(" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "&\{.+\}" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "<.+>" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "javascript:" "t:lowercase,deny,msg:'XSS'"
SecRule ARGS "vbscript:" "t:lowercase,deny,msg:'XSS'"
3. Tấn công BRUTE FORCE
Với tấn công Brute Force, hacker thực hiện đoán các thông tin đăng nhập

như tên người dùng, mật khẩu, email… và thực hiện đăng nhập liên tục
đến khi nào thông tin đăng nhập là đúng. Hầu hết người dùng đều sử
dụng thông tin đăng nhập giống nhau trên tất cả các website mà họ
thường đăng nhập, dẫn đến tài khoản của họ bị xâm nhập trên hàng loạt
các website khi thông tin đăng nhập bị lộ bởi một website khác.
Cách tốt nhất để ngăn chặn hình thức tấn công này là giới hạn số lần
đăng nhập không đúng. Ví dụ nếu người sử dụng đăng nhập không đúng
quá 3 lần, thực hiện khoá đăng nhập của người này trong 5 phút.
Dưới đây là các rule của ModSecurity cho phép chúng ta thực hiện điều
này:
# Khoa dang nhap sau 3 lan dang nhap khong thanh cong
#
<LocationMatch ^/login>
# Khoi tao collection ip
SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"
# Phat hien dang nhap khong thanh cong
SecRule RESPONSE_BODY "Username does not exist"
"phase:4,pass,setvar:
ip.failed_logins=+1,expirevar:ip.failed_logins=300"
# Khoa dang nhap khi so lan dang nhap khong thanh cong bang 3
SecRule IP:FAILED_LOGINS "@gt 3" deny
</Location>
18
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
Các rule trên dựa vào đặt điểm trả về của website khi người truy cập đăng
nhập không thành công: Username does not exist.
Các rule trên sẽ khởi tạo collection IP và tăng giá trị
biến ip.failed_login lên một đơn vị sau mỗi lần đăng nhập không thành
công. Action expirevar sẽ thiết lập biến ip.failed_login về 0 sau 5 phút. Vì
vậy, khi biến ip.failed lớn hơn hoặc bằng 3, rule cuối sẽ khoá đăng nhập

của người dùng trong 5 phút.
Hoặc chúng ta có thể thực hiện trì hoãn (hay dừng) request của người
dùng khi số lần đăng nhập sai vượt quá quy định. Do đó, không cần phải
từ chối truy cập như các rule được nêu ở trên. Sau đây là rule thực hiện
điều trên:
# tri hoan request 3 giay sau 3 lan dang nhap khong thanh cong
<LocationMatch ^/login>
SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"
SecRule RESPONSE_BODY "Username does not exist"
"phase:4,pass,setvar:
ip.failed_logins=+1,expirevar:ip.failed_logins=10"
SecRule IP:FAILED_LOGINS "@gt 3" "phase:4,allow,pause:3000"
</Location>
Thời gian trì hoãn được tính bằng mili giây, các rule trên sẽ trì hoãn
response trong 3 giây khi số lần truy cập không thành công lớn hơn hoặc
bằng 3.
4. HTTP FINGERPRINTING
Chỉ có những hacker nghiệp dư mới thực hiện tấn công một server mà
không biết server đó có hoạt động hay không. Phức tạp hơn, hacker sẽ
thu thập càng nhiều thông tin càng tốt về kiến trúc mạng và phần mềm
đang chạy trên server. Cụ thể với web server, phương thức tìm kiếm
thông tin này gọi là HTTP Fingerprinting (dấu vân tay HTTP).
HTTP Fingerprinting hoạt động bằng cách kiểm tra các đặc tính riêng
của web server bằng các response khi được thăm dò và lấy “dấu vân tay”
của server từ những thông tin thu thập được. Sau đó dấu vân tay này
19
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
được so sánh với một cơ sở dữ liệu về “dấu vân tay” cho các web server
được biết đến để xác định tên web server và phiên bản mà nó đang chạy.
Sử dụng ModSecurity để ngăn chặn HTTP Fingerprinting

Chúng ta sẽ cung cấp đầy đủ các thông tin cho hacker tìm hiểu, nhưng
không phải là thông tin chính xác. ModSecurity cho phép chúng ta tuỳ
chỉnh và đánh lừa các công cụ HTTP Fingerprinting. Ví dụ:
- Chặn các request không chứa Host header
- Đặt chữ ký là Microsoft-IIS/6.0.
- Thêm X-Powered-By: ASP.NET 2.0 header.
- Gỡ bỏ Etag header.
Dưới đây là các rule để thực hiện:
# Thay doi chu ky server
SecServerSignature "Microsoft-IIS/6.0"
# Them X-Powered-By header
Header set X-Powered-By "ASP.NET 2.0"
# Go bo ETag header
Header unset ETag
Chương 3: Kịch bản demo
Thông tin cấu hình demo và phiên bản phần mềm:
- Victim:
+ Network interface: VirtualBox Host-only Ethernet Adapter IP:
192.168.56.101
+ Open port 80
+ Disable firewall
+ OS: Centos 5.0
+ Webserver: Apache 2
+ WAF(Web Application Firewall): mod_security 2.5.13
+ php version 5.1.6
20
Windows 7
(attacker)
Centos 5.0
(Victim)

Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
+ DBMS: MySQL
+ Damn Vulnerable Web App (DVWA) 1.0.7
- Attacker:
+ OS: Windows 7 Ultimate
+ Network interface: Virtual Host-only network IP: 192.168.56.1
***Kịch bản tấn công:
- Attaker sẽ dùng công cụ SuperScan4 để thực hiện HTTP FingerPrinting
nhằm khai thác thông tin về web server sau đó Attacker sẽ thực hiện phân
tích các lỗ hổng có thể có trên website DVWA (website này được viết với
mục đích để lộ ra các lỗ hổng để tiến hành demo), attacker thực hiện các
cuộc tấn công SQL injection, XSS, Burte Force.
- Victim khi phát hiện website đặt trên web server củng mình bị tấn công
liền cài đặt mod_security và tiến hành thiết lập các Rule như đã trình bày
ở trên nhằm ngăn chặn các cuộc tấn công tương tự có thể xảy ra sau này.
Tài liệu tham khảo
[1] ModSecurity for Apache User Guide
/>1.9.2.html
[2] ModSecurity Rules Project
/>[3] Gotroot mod_security rules
/>[4] Ivan Ristic, Apache Security – O'reilly 2005 , ISBN 0-596-00724-8
21
Khoa CNTT – ĐH Công nghiệp thành phố Hồ Chí Minh Tìm hiểu Modsecurity & demo tính năng
[5] Ryan C. Barnett, Preventing Web Attack with Apache , Addison Wesley
Professional 2006, ISBN 0-321-32128-2
[6] Magnus Mischel, Modsecurity 2.5, 2009 Packt Publishing
[7] ModSecurity® Reference Manual, Version 2.5.12 (Feb 3, 2010)
Copyright © 2004-2010 Breach Security, Inc. ()
22