Bảo mật máy chủ ứng dụng Web với ModSecurity

Bảo mật máy chủ ứng dụng Web với ModSecurity

MỤC LỤC
MỤC LỤC.................................................................................................................... 1
DANH MỤC HÌNH ẢNH............................................................................................3
DANH MỤC CÁC BẢNG..........................................................................................3
CHƯƠNG I –TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ VẤN ĐỀ VỀ BẢO MẬT
HIỆN NAY................................................................................................................... 4
1.1. Khái niệm ứng dụng web...................................................................................4
1.2. Cấu trúc cơ bản và mô tả hoạt động của ứng dụng web..................................4
1.2.1. Cấu trúc cơ bản của một ứng dụng web..............................................5
1.2.2. Mô tả hoạt động của một ứng dụng web.............................................5
1.3. Các nguy cơ mất an toàn ứng dụng web và vấn đề bảo mật hiện nay............7
CHƯƠNG II - MODSECURITY...............................................................................9
2.1. Tìm hiểu về ModSecurity...................................................................................9
2.1.1. Khái niệm Modsecurity........................................................................9
2.1.2. Các khả năng của ModSecurity...........................................................9
2.1.3. Quá trình xử lý các request của Apache và ModSecurity ...............10
2.2. Các luật (Rules).................................................................................................12
2.2.1. ModSecurity Core Rule......................................................................12
2.2.2. Cấu hình các chỉ thị (Directive).........................................................12
2.2.3. Biến (Variables ) và bộ chọn lọc (Collection)....................................15
2.2.4. Chức năng chuyển đổi........................................................................17
2.2.5. Toán tử (Operators)............................................................................18
2.2.6. Hành động (Actions)...........................................................................19
2.3. Logging..............................................................................................................21
2.3.1. Debug Log............................................................................................21
2.3.2. Audit logging.......................................................................................21
Học viện Kỹ thuật Mật Mã

- Trang 1 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

2.3.3. Tuỳ biến thông tin log.........................................................................22
2.4. Biểu thức chính quy (Regular expressions)....................................................23
2.4.1. Giới thiệu về biểu thức chính quy......................................................23
2.4.2. Ứng dụng của biểu thức chính quy trong Modsecurity...................24
2.5. Viết và phân tích một số luật cơ bản...............................................................24
CHƯƠNG III - XÂY DỰNG CHÍNH SÁCH TRÊN MODSECURITY CHỐNG
LẠI MỘT SỐ TẤN CÔNG LÊN ỨNG DỤNG WEB.............................................26
3.1. Mô hình triển khai ModSecurity và xây dựng kịch bản Demo.....................26
3.1.1. Xây dựng kịch bản demo....................................................................26
3.1.2. Cài đặt ModSecurity trên máy chủ CentOS.....................................27
3.1.3. Cấu hình cơ bản..................................................................................28
3.2. Xây dựng chính sách trên ModSecurity chống lại một số tấn công lên ứng
dụng Web...............................................................................................................29
3.2.1. Ngăn chặn HTTP Fingerprinting......................................................29
3.2.2. Ngăn chặn tấn công Brute Force........................................................31
3.2.3. Ngăn chặn tấn công Cross-Site Scripting (XSS)...............................32
3.2.4. Ngăn chặn tấn công SQL injection....................................................34
TÀI LIỆU THAM KHẢO.........................................................................................38

Học viện Kỹ thuật Mật Mã

- Trang 2 -

Khoa Công Nghệ Thông Tin

Bảo mật máy chủ ứng dụng Web với ModSecurity

DANH MỤC HÌNH ẢNH

DANH MỤC CÁC BẢNG

LỜI MỞ ĐẦU
Trong những năm gần đây, Việt Nam ngày càng phát triển và nhất là về mặt
công nghệ thông tin. Đặc biệt là về ứng dụng Web, hầu như mọi người ai cũng từng
nghe và làm việc trên ứng dụng web. Website trở nên phổ biến và trở thành một phần
quan trọng của mọi người nhất là các doanh nghiệp, tổ chức. Ứng dụng Web càng phổ
biến thì các cuộc tấn công ứng dụng Web cũng trở nên hết sức phức tạp. Điều này đặt
ra vấn đề về sự cần thiết của bảo mật ứng dụng web. Nhiều tổ chức, công ty đã xây
dựng tường lửa ứng dụng web để bảo vệ hệ thống máy chủ ứng dụng web như sản
phẩm Imperva, CheckPoint hay ModSecurity. Trong đó Imperva và Checkpoint là sản
phẩm thương mại, còn ModSecurity là một sản phẩm mã nguồn mở.
Do đó trong đề tài này nhóm em xin thực hiện triển khai “Bảo mật máy chủ ứng
dụng web với ModSecurity”. Với mục đích xây dựng nên các chính sách để phòng
chống một số tấn công phổ biến lên ứng dụng Web hiện nay như tấn công HTTP
Fingerprinting, tấn công Brute Force, Cross Site Scripting (XSS), SQL Injection …
Trong giới hạn của đề tài này, nhóm em xin trình bày chuyên đề gồm 3 chương chính,
như sau:
Chương 1: Tổng quan về ứng dụng web và vấn đề bảo mật hiện nay
Chương này nhóm em xin trình bày khái quát về ứng dụng web, các nguy cơ
mất an toàn ứng dụng web và vấn đề bảo mật hiện nay. Từ đó thấy tầm quan trọng của
bảo mật ứng dụng web hiện nay.
Chương 2: ModSecurity
Ở phần này nhóm em xin giới thiệu tổng quan về ModSecurity cách thức

ModSecurity hoạt động cũng như quá trình xử lý request của Apache và Modsecurity.
Đồng thời giới thiệu cú pháp của một rule và các thành phần trong đó.

Học viện Kỹ thuật Mật Mã

- Trang 3 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Chương 3: Xây dựng chính sách trên ModSecurity chống lại một số tấn công lên
ứng dụng web.
Trong quá trình thực hiện đề tài này, nhóm em xin gửi lời cảm ơn chân thành
đến các thầy cô trong Học viện Kỹ thuật Mật Mã nói chung và các thầy cô khoa Công
nghệ thông tin đã truyền đạt những kiến thức quý báu cho nhóm em trong suốt thời
gian qua. Đặc biệt, nhóm em xin gửi lời cảm ơn sâu sắc tới thầy giáo Ths. Nguyễn Đào
Trường đã nhiệt tình hướng dẫn nhóm em hoàn thành đề tài này. Do thời gian chuẩn bị
còn hạn chế nên đề tài không tránh khỏi thiếu sót. Nhóm em rất mong nhận được sự
đánh giá, những ý kiến quý báu từ phía thầy cô và các bạn để hoàn thiện hơn.
Hà Nội, ngày 18 tháng 12 năm 2013

CHƯƠNG I –TỔNG QUAN VỀ ỨNG DỤNG WEB VÀ VẤN ĐỀ VỀ BẢO
MẬT HIỆN NAY
1.1. Khái niệm ứng dụng web
Ứng dụng web là một ứng dụng khách/chủ truy cập qua mạng Internet hay
intranet sử dụng giao thức HTTP/HTTPS để tương tác với người dùng hay hệ thống
khác.
Trình khách dành cho người sử dụng là một phần mềm phổ biến và chung cho

các ứng dụng web như là Internet Explorer, Nescape, Firefox … Ứng dụng web rất
phổ biến bởi sự cập nhật và duy trì mà không cần phần mềm phân phối, cài đặt tại
hàng nghìn máy tính của người sử dụng. Các ứng dụng web phổ biến hiện nay là:
webmail, bán hàng trực tuyến, đấu giá, mạng xã hội và nhiều chức năng khác.
Trước đây ứng dụng web được xây dựng trên mô hình tập trung, nghĩa là ứng
dụng chạy trên một máy chủ và kết nối vào cơ sở dữ liệu ngay trên máy chủ đó. Hiện
nay các ứng dụng web được xây dựng theo mô hình phân tán, nhiều máy chủ đáp ứng
yêu cầu và kết nối tới nhiều nguồn cơ sở dữ liệu. Trình chủ được viết bằng các ngôn
ngữ như : PHP, ASP, ASP.NET, JSP….

1.2. Cấu trúc cơ bản và mô tả hoạt động của ứng dụng web
1.
1.1.

Học viện Kỹ thuật Mật Mã

- Trang 4 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

1.
1.1.
1.2.
1.2.1.

Cấu trúc cơ bản của một ứng dụng web

Cấu trúc đơn giản của một ứng dụng Web được chia thành 3 tầng: Model –
View - Controller, mỗi tầng đảm nhận một nhiệm vụ chuyên biệt.
- Tầng truy vấn (Model): Chứa các mã lệnh kết nối tới database, truy vấn, thêm,
xóa sửa dữ liệu.
- Tầng nhập và hiển thị (View): Chứa code tạo giao diện tương tác với người
dùng, tái hiện dữ liệu và dẫn dắt người dùng các tương tác với dữ liệu.
- Tầng điều khiển (Controller): Chứa code điều khiển dòng dữ liệu, gắn kết tầng
Model và tầng View lại với nhau.
Cấu trúc này giúp chia nhỏ quá trình xử lý, có thể làm việc trên từng thành phần
riêng lẻ trong khi các thành phần khác sẽ không bị ảnh hưởng tới. Chẳng hạn chúng ta
muốn ứng dụng có thể truy xuất trên di động thì chỉ cần tạo một tầng View mới mà
tầng Model và Controller không thay đổi. Hay nếu ta muốn thay đổi database ta chỉ
cần tạo ra một tầng Model mới, phần View và Controller không bị ảnh hưởng.

Hình 1.1 Mô hình phân tầng đơn giản trong cấu trúc ứng dụng Web

1.2.2.

Mô tả hoạt động của một ứng dụng web

Hoạt động của ứng dụng web được biểu diễn như hình sau:

Học viện Kỹ thuật Mật Mã

- Trang 5 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Hình 1.2 Mô tả hoạt động của ứng dụng web

Một ứng dụng web bao gồm hai phía:
- Phía Client: là trình duyệt web
- Phía Server: kiến trúc ứng dụng web bao gồm 2 lớp: lớp logic (Web Server,
Web Application Server) và lớp dữ liệu (Database Server)
- Ngoài ra tường lửa được sử dụng để chống lại sự truy cập trái phép, bảo vệ các
nguồn thông tin nội bộ cũng như hạn chế sự xâm nhập vào hệ thống.
Mô tả hoạt động như sau:
Đầu tiên Client sẽ gửi một yêu cầu (request) đến Web Server thông qua các
lênh cơ bản GET, POST… của giao thức HTTP/HTTPS, Web Server lúc này có thể
thực thi một chương trình được xây dựng từ nhiều ngôn ngữ như Perl, C/C++… hoặc
nó sẽ yêu cầu bộ diễn dịch thực thi các trang ASP, JSP… theo yêu cầu của trình duyệt.
Tùy theo các tác vụ của chương trình được cài đặt mà nó xử lý, tính toán, kết nối đến
cơ sở dữ liệu, lưu các thông tin do trình duyệt gửi đến và từ đó trả về cho Client một
luồng dữ liệu có định dạng theo giao thức HTTP, nó gồm 2 phần:
- Header: mô tả các thông tin về gói dữ liệu và các thuộc tính, trạng thái trao đổi
giữa trình duyệt và Web Server.
- Body: là phần nội dung dữ liệu mà Server gửi về Client, nó có thể là một file
HTML, một hình ảnh, video hay một văn bản bất kỳ.
Theo hình 1.2, với Firewall luồng thông tin giữa trình duyệt và Web Server là
luồng thông tin hợp lệ, vì thế nếu hacker tìm thấy vài lỗ hổng trong ứng dụng web thì
firewall không còn hữu dụng trong việc ngăn chặn hacker này. Do đó các kỹ thuật tấn
công vào một hệ thống mạng ngày nay chủ yếu là tập trung vào những lỗ hổng trong
quá trình tạo ứng dụng của nhà phát triển web hơn là tấn công trực tiếp vào hệ thống
mạng.

Học viện Kỹ thuật Mật Mã

- Trang 6 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

1.3. Các nguy cơ mất an toàn ứng dụng web và vấn đề bảo mật hiện nay
Ngày nay rất nhiều doanh nghiệp, tổ chức sử dụng ứng dụng web để cung cấp
dịch vụ thương mại trực tuyến, kết nối khách hàng, đối tác và nhân viên một cách hiệu
quả nhất. Tuy nhiên, ứng dụng web cũng đem đến những rủi ro đáng kể cho hệ thống
và dữ liệu. Đa số ứng dụng web có thể bị những lỗi mà các phương pháp và cách
phòng chống mạng thông thường không bảo vệ được. Sau đây là một số nguy cơ tạo
điểm yếu (lỗ hổng) trong ứng dụng web phổ biến hiện nay
Nguy cơ đầu tiên xuất phát từ phiên bản máy chủ web và máy chủ cơ sở dữ liệu
mà chúng ta đang sử dụng. Ở mỗi phiên bản sử dụng đều có những lỗ hổng mà nhờ đó
kẻ tấn công có thể thâm nhập vào hệ thống của chúng ta. Để khắc phục nguy cơ này,
người quản trị cần phải cập nhật các bản vá từ nhà cung cấp sản phẩm. Dễ dàng để trả
lời là chưa an toàn, vì mỗi hệ thống sẽ có một cấu hình riêng, do đó sau khi cập nhật
nó có thể làm cho hệ thống hoạt động không ổn định vì sự không tương thích này.
Nguy cơ thứ hai xuất phát từ mã nguồn của Website. Với nguy cơ này ta có thể
sửa đổi mã nguồn để hạn chế những lỗ hổng phát sinh do mã nguồn.
Nguy cơ thứ ba xuất phát từ bên ngoài gồm có:
- Nguy cơ tấn công từ chối dịch vụ (DoS, DDoS) làm cho hệ thống ngưng trệ, không
có khả năng phục vụ các yêu cầu chính đáng
- Nguy cơ bị thay đổi nội dung trang web, làm giảm uy tín hoặc bôi nhọ tổ chức
- Nguy cơ đánh cắp các thông tin nhạy cảm như: thông tin tài khoản, mật khẩu truy
cập hệ thống và thông tin thẻ tín dụng …
- Nguy cơ do người lập trình chưa kiểm soát được dữ liệu đầu vào. Các tấn công phổ
biến ở dạng này bao gồm

o Cross site scripting
o Lỗi tràn bộ đệm
o Tấn công Format string
o SQL injection
o Cookie poisoning
Hiện nay có rất nhiều cách khắc phục các điểm yếu trong ứng dụng web và đảm
bảo cho máy chủ ứng dụng web vận hành an toàn và liên tục như
- Kết nối bên ngoài bao gồm các thiết bị định tuyến kết nối ADSL, Lease-line…
cùng các thiết bị cân bằng tải
- Kết nối bảo mật: các thiết bị tường lửa, các hệ thống phòng chống tấn công IDS
(Intrusion detection system), IPS (Intrusion prevention system) và phần mềm giám
sát hệ thống mạng
- Hệ thống máy chủ: các máy chủ cài phần mềm diệt virut, chống spam mail (thư
rác), loại bỏ các dịch vụ không cần thiết…
- Hệ thống lưu trữ: các thiết bị lưu trữ dữ liệu tích hợp SAN (Storage Area Network)

Học viện Kỹ thuật Mật Mã

- Trang 7 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Trong đề tài này nhóm em xin đi sâu vào phần bảo mật máy chủ ứng dụng web
bằng Modsecurity

Học viện Kỹ thuật Mật Mã

- Trang 8 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

CHƯƠNG II - MODSECURITY
2.1. Tìm hiểu về ModSecurity
2.1.1.

Khái niệm Modsecurity

ModSecurity là một open source web application firewall được Ivan Ristic phát
triển dành cho Apache Web Server. Nó được xem 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. Hoạt động như một module của Web
Server Apache hoặc có thể đứng độc lập một mình như một reverse proxy để bảo vệ
nhiều loại webserver như là IIS, Tomcat, Apache.

Hình 2.1 Mô hình tổng quan ModSecuriy

ModSecurity được sử dụng dưới hai hình thức là Open source hoặc thương mại
với nhiều hỗ trợ từ nhà cung cấp. Nó có thể hoạt động tốt trên hàng loạt các hệ điều
hành như: Linux, Windows, Solaris, FreeBSD, Mac OS.
2.1.2.
-

-

-

Các khả năng của ModSecurity

Lọc các request (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ý
Chống các kỹ thuật tấn công (Anti-evasion techniques): đường dẫn (paths) và
thông số (parameters) được chuẩn hóa trước khi phân tích để chống các kỹ thuật
tấn công.
Hiểu giao thức HTTP (Understanding of the HTTP protocol): ModSecurity là một
tường lửa ứng dụng nên nó có khả năng hiểu được giao thức HTTP. ModSecurity
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 thông số hay cookies của các request...

Học viện Kỹ thuật Mật Mã

- Trang 9 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

-

-

Phân tích nội dung của phương thức POST (POST payload analysis): Ngoài việc
cản lọc dựa trên HTTP Header, ModSecurity có thể dựa trên nội dung (payload)
của POST requests.

Tự động ghi log (Audit logging): Mọi requests đều có thể được ghi lại (bao gồm cả
POST) để người quản trị có thể theo dõi nếu cần.
Lọc giao thức HTTPS (HTTPS filtering): ModSecurity có thể phân tích HTTPS.
Phân tích những yêu cầu được nén (Compressed content filtering) ModSecurity sẽ
phân tích sau khi đã giải nén các các dữ liệu được yêu cầu.
2.1.3.

Quá trình xử lý các request của Apache và ModSecurity

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

ModSecurity cho phép chúng ta đặ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 (phase 1): Các luật được đặt tại đây sẽ được thực hiện ngay
sau khi Apache đọc request header (Post-read-request), lúc này phần request body
vẫn chưa được đọc. 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, Local file include, Cross
Site Script (XSS)…

Học viện Kỹ thuật Mật Mã

- Trang 10 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

-

Phase Request Body (phase 2): Đâ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 luật mang tính ứng dụng hướng kết nối
(application-oriented) thường được đặt ở đây. Ở thời điểm này, Server đã nhận đủ
các thông số của request và phần request body đã được đọc. Mục đích chung của
phase này là phân tích đầu vào dữ liệu, dịch URI, kiểm tra header, kiểm tra truy
cập, xác thực…
ModSecurity hỗ trợ ba loại mã hoá request body sau:
o Application/x-www-form-urlencoded: Dùng để truyền form dữ liệu
o Multipart/form-data: Dùng để truyền file
o Text/xml: Dùng để phân tích dữ liệu XML
- Phase Response Header (phase 3): Đây là thời điểm ngay sau khi phần response
header được gửi trả về cho client. Chúng ta đặt luật ở đây nếu muốn giám sát quá
trình sau khi phần response được gửi đi.
- Phase Response Body (phase 4): Sau khi ModSecurity đã hoàn thành việc kiểm tra
tại response 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 khá hiệu quả để phát hiện và phòng chống xâm nhập trong
trường hợp 1 và 2 không phát hiện tấn công.
Ví dụ: trong khai thác SQL Injection, nếu hacker cố gắng sử dụng một số kỹ
thuật nhằm ẩn đi 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 (phase 5): 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 log sẽ như thế nào, nó sẽ kiểm tra các thông báo lỗi của
Apache. Đây cũng là thời điểm cuối cùng để chúng ta chặn các kết nối không mong
muốn, kiểm tra các response header mà chúng ta không thể kiểm tra ở phase 3 và
phase 4.
Một luật được thực đúng từng phase theo thứ tự. Điều này có nghĩa là
ModSecurity sẽ duyệt tất cả các luật trong phase 1, sau đó đến phase 2, phase 3, phase
4 và cuối cùng là phase 5. Trong mỗi phase, các luật được xử lí theo thứ tự mà chúng
xuất hiện trong các tập tin cấu hình. Chúng ta có thể hiểu khi có request, ModSecurity

sẽ duyệt các tệp tin năm lần, mỗi lần cho một phase. Trong thời gian xử lý
ModSecurity chỉ xem xét các luật thuộc pha đang xử lý.
Phase logging đặc biệt ở chỗ nó luôn luôn được thực hiện cả khi request đã
được cho phép hay từ chối trong các phase trước đó. Ngoài ra, một khi phase logging
bắt đầu, chúng ta không thể thực hiện bất kỳ một hàng động ngăn chặn nào vì khi đó
response đã được gửi cho người truy cập
Vì vậy, cần phải cẩn thận không để cho bất kỳ hành động nào trái quy định được
truyền vào luật ở phase 5. Nếu không sẽ lỗi làm cho Apache không khởi động được.
Học viện Kỹ thuật Mật Mã

- Trang 11 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Để khắc phục điều này ta có thể đặt luật sau đây trước các luật thuộc phase 5 (nhưng
cần phải đặt sau các luật của phase trước đó)
SecDefaultAction “phase:5,pass”
2.2.

Các luật (Rules)
2.2.1.

ModSecurity Core Rule

ModSecurity là một tường lửa ứng dụng do vậy bản thân nó mặc định cũng
không có khả năng chống các tấn công nếu không có các luật đã được cấu hình cẩn
thận. Để tận dụng triệt để những tính năng của Modsecurity, tập đoàn Breach Security

đã xây dựng sẵn một tập luật khá chặt chẽ và đầy đủ, và miễn phí. Khác với hệ thống
phát hiện xâm nhập khác, chỉ dựa trên những dấu hiệu, đặc điểm cụ thể từ những tấn
công trước, các core rule này được cung cấp sự bảo vệ chung nhất từ những tổn hại
chưa được biết tới thường thấy ở các ứng dụng web. Core rule mới nhất được tìm thấy
tại website của ModSecurity tại website www.modsecurity.org/projects/rules/
Để cung cấp sự bảo vệ ứng dụng web một cách bao quát, core rule bao gồm
những nội dung sau:
- Bảo vệ luồng dữ liệu HTTP – phát hiện các hành vi vi phạm của các giao thức
HTTP và chính sách sử dụng được định nghĩa
- Phòng chống các tấn công phổ biến vào web server – phát hiện các tấn công vào
ứng dụng web server.
- Tự động phát hiện – phát hiện bots, các công cụ dò tìm và các mã độc hại
- Phòng chống Trojan – phát hiện truy cập của Trojan horses
- Các lỗi ẩn – các thông báo từ web server
Cấu hình luật của ModSecurity bao gồm các thông tin khác nhau các thiết đặt
khác nhau về nhiều nội dung.
- Cấu trúc Core Rule bao gồm chỉ thị, các biến, các hàm chuyển đổi, các chữ ký
(signature) và các hành động (Action) tương ứng cho phép, không cho phép, ghi
log.
- Yêu cầu về logic là phát hiện các cuộc tấn công.
- Thiết đặt chính sách đưa ra hành động xử lý nếu phát hiện ra tấn công
- Thông tin về các cuộc tấn công
2.2.2.

Cấu hình các chỉ thị (Directive)

ModSecurity là một tường lửa ứng dụng thuộc loại rules-based, nghĩa là người
quản trị cần thiết lập các luật. Khi ModSecurity chạy sẽ căn cứ vào luật này để thực
hiện các yêu cầu, đảm bảo cho hệ thống được an toàn. Các luật này được thể hiện dưới

Học viện Kỹ thuật Mật Mã

- Trang 12 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

dạng các directives (chỉ thị) và có thể đặt trực tiếp trong file cấu hình Apache (thông
thường là httpd.conf).
ModSecurity định nghĩa 9 loại chỉ thị để người dùng có thể triển khai các tính
năng lọc linh động cho hệ thống web.
Directive

Description

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
SecRuleRemoveByMsg

Removes the rule with the given ID.
Removes the rule whose message matches the
given regular expression.

SecRuleScript

Creates a rule implemented using Lua.

SecRuleUpdateActionById

Updates the action list of the rule with the given ID.

Bảng 2.1 Các loại chỉ thị trong Modsecurity

Các chỉ thị này đóng vai trò rất quan trọng trong các luật. Tương ứng với mỗi

yêu cầu cần thiết cho một luật là các chỉ thị tương ứng được sử dụng. Một trong số chỉ
thị được dùng rất nhiều là SecRule, SecAction, SecRuleEngine. Các request sẽ bị từ
chối nếu phạm vào một trong các chị thị này như request phạm vào giao thức HTTP,
các request có nội dung bất thường. Những luật này, cùng với các file core rule không
nên đặt cùng file cấu hình http.conf của Apache. Điều này sẽ làm cho việc nâng cấp dễ
hơn vì những file core rule mới đều được công ty Breach Security public ở trang web
của ModSecurity.Dưới đây là một số các chỉ thị quan trọng.
• SecRuleEngine

Học viện Kỹ thuật Mật Mã

- Trang 13 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Mặc định thì trong filtering 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
Chỉ thị này dùng để điều khiền filter engine, người quản trị có thể thiết đặt các tùy
chọn là On, Off hoặc DynamicOnly.
- On: Các luật của ModSecurity được áp dụng cho tất cả các nội dung
- Off: Vô hiệu hóa Modsecurity
- DynamicOnly: Các luật của ModSecurity không được áp dụng cho nội dung tĩnh
(static content) như các file.html mà chỉ áp dụng cho các request trả về nội dung
động như request đến các file php…
• SecAction
Mô tả: Sec Action sẽ xử lý vô điều kiện danh sách các hành động mà nó nhận được

như tham số đầu tiên và duy nhất. Nó chấp nhận một tham số, cú pháp của tham số
này giống tham số thứ ba của SecRule.
Cú pháp: SecAction action1, action2, action3
Ví dụ:

SecAction "log,deny,msg:'chan truy cap'"

SecAction sử dụng tốt nhất khi thực thi một hành động vô điều kiện. Bình thường các
hành dộng này được kích hoạt có điều kiện cơ bản trên dữ liệu yêu cầu và trả lời
(request/reponse)
• SecRule
Mô tả: SecRule là chỉ thị chính của Modsecurity. Nó được sử dụng để phân tích dữ
liệu và thực hiện các hành động cơ bản và đưa ra kết quả.
Cấu trúc chuẩn của một luật trong ModSecurity như sau:
SecRule VARIABLES OPERATOR [ACTION]
Ví dụ:
SecRule ARGS “<script>” log,deny,status:404
- VARIABLES: Xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu. Trong ví
dụ trên, tham số ARGS nhằm chỉ định tìm kiếm mẫu trong tất cả các tham số trong
request.
- OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu. Các toán tử được
dùng theo dạng biểu thức chính quy nhằm tạo nên cơ chế phân tích linh động cho
các luật
- ACTION: chỉ định hành động mà modsecurity sẽ thực hiện khi có một mẫu được
so trùng. Trong ví dụ trên, phần action được viết log, deny, status:404 có nghĩa là
khi trùng mẫu <script> trong gói tin thì thực hiện gi log, chặn gói tin bằng các sử
dụng mã trạng thái 404 (Not found).
Ví dụ: dưới đây là một HTTP request
Học viện Kỹ thuật Mật Mã

- Trang 14 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

GET /document/index.html HTTP/1.1
Host=www.kmasecurity.net
User-Agent=Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language=vi-vn,vi;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding=gzip, deflate
Content-Type=application/x-www-form-urlencoded; charset=UTF-8
Referer= />Content-Length=20
Cookie=xf_session=9e9b13d4955a3e03f46d173e5bc02935
POSTDATA=rndval=1386222108554

Từ request ở trên thấy các HTTP Header như là: GET, Host, User-Agent,
Accept, Referer, Content – Length, Cookie, POSTDATA …
Chẳng hạn ta viết rules để cấm các request có chức từ “admin”
SecRule REQUEST_URI "admin" "phase:2,deny,log,msg:'khu vuc cam truy cap'"

Hay không cho phép User-Agent có từ Mozilla
SecRule HTTP_User-Agent "Mozilla" "phase:1,deny,log,msg:'deny mozilla'"

2.2.3.

Biến (Variables ) và bộ chọn lọc (Collection)

Hiện nay có khoảng hơn 70 biến có sẵn trong ModSecurity. ModSecurity sử
dụng 2 loại biến: biến standard (đơn giản chỉ chứa một giá trị duy nhất) và biến
Collection (có thể chứa nhiều hơn một giá trị). Một ví dụ về Collection là
REQUEST_HEADERS, trong đó chứa tất cả các trường trường trong thông điệp
header mà Client gửi tới Server, chẳng hạn như User-agent, hoặc Referer.
Để truy cập vào một trường trong collection, chúng ta ghi tên collection, tiếp
theo là dấu hai chấm và sau đó là tên của trường hoặc tùy chọn mà chúng ta muốn truy
cập. ví dụ:
SecRule REQUEST_HEADERS:User-agent "hacker" "log,deny,status:404"
Với trường hợp trên ta chỉ có thể kiểm tra dữ liệu trên trường User-agent. Để có thể
kiểm tra toàn bộ dữ liệu trên tất cả các collection ta sử dụng biên ARGS. Ví dụ ta
muốn kiểm tra sự hiện diện của chuỗi hacker trên tất cả collection ta sử dụng luật sau:
SecRule ARGS “hacker” “log,deny,status:404”
Dưới đây là một số biến và collection được hỗ trợ:
- HTTP: Biến này là một tiền tố đặc biệt đi theo sau phần đầu của header và có thể
được sử dụng để chặn truy cập vào các request header. Ví dụ:
SecRule HTTP_referer "192.168.1.99/index.php" "phase:2,deny,nolog,status:404"
- ARGS: ARGS giống như QUERY_STRING | POST_PAYLOAT là URI phía sau
dấu ? Ví dụ:
Học viện Kỹ thuật Mật Mã

- Trang 15 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

/index.php?i=10 thì QUERY_STRING là i=10
- REMOTE_HOST: Nếu HostnameLookUps được thiết lập là On, thì biến này sẽ

nắm giữ tên host remote được phân giải bởi DNS. Nếu nó được thiết lập Off thì nó
sẽ giữ các địa chỉ IP. Có thể sử dụng các biến này để từ chối các client nguy hiểm,
các mạng đã đưa vào blacklist, hoặc ngược lại cho phép xác thực các host.
- REMOTE_PORT: Biến này chứa thông tin về cổng nguồn mà client đã sử dụng
khi bắt đầu cho kết nối đến Web Server.
- ARGS_COMBINED_SIZE: Biến này cho phép biết thêm nhiều kết luận về giá trị
trên tổng dung lượng của các đối số, so với bình thường thì chỉ thị cuả Apache là
có giới hạn.
- ARGS_NAMES: là một tập hợp các đối số. Có thể tìm kiếm, cụ thể tên đối số mà
người quản trị muốn cấm. Trong một kịch bản với chính sách rõ ràng, người quản
lý có thể thiết lập một danh sách trắng.
- AUTH_TYPE: Biến này chứa các phương pháp xác thực được sử dụng để xác
nhận tính hợp lệ của người sử dụng. Ví dụ:
SecRule AUTH_TYPE "basic" log,deny,phase:1
- FILES: Chứa một tập hợp các tên tập hợp các tập tin ban đầu. Chú ý: Chỉ sẵn sàng
khi các file được trích từ request body. Ví dụ:
SecRule FILES "\.conf$" log,deny,status:404,phase:2
- FILES_COMBINED_SIZE: Giá trị đơn. Tổng dung lượng của 1 file upload. Chú
ý: Chỉ sẵn sàng khi các file được trích xuất từ request body.
- QUERY_STRING: Biến này chứa sữ liệu mẫu thông qua script/header bằng cách
nối thêm dữ liệu vào sau câu hỏi đã được đánh dấu. Ví dụ:
SecRule QUERY_STRING "or" "phase:1,log,deny,status:403"
- REMOTE_ADDR: Biến này chứa các địa chỉ IP của các client từ xa. Ví dụ:
SecRule REMOTE_ADDR "^192\.168\.1\.15$" "deny"
- REMOTE_USER: Biến này giữ các tên người sử dụng xác thực.
- REQBODY_PROCESSOR: Xây dựng xử lý các URL đã được mã hóa
MULTIPART và XML.
- REQBODY_PROCESSOR_ERROR: 0 (no error) hoặc 1 (error) Nếu người quản
lý muốn quá trình xử lý một lỗi phải đặt luật này trong phase 2. Ví dụ:
SecRule REQBODY_PROCESSOR_ERROR "@eq 1" deny,log,phase:2

- REQUEST_BASENAME: Biến này chỉ là một phần của tập tin tên
REQUEST_FILENAME. Ví dụ:
SecRule REQUEST_BASENAME "^login\.php$" "allow,log,msg:'dang nhap',phase:2"
- REQUEST_BODY: Biến này chứa dữ liệu trong request body ( Bao gồm cả
POST_PAYLOAD data). REQUEST_BODY nên được sử dụng. Ví dụ:
SecRule REQUEST_BODY "^username=\w{25,}\&password=\w{6,}\&Login=
Login$" "phase:2,log,deny,msg:'truy cap tu choi'"
- REQUEST_COOKIES: biến này bao gồm tập hợp tất cả dữ liệu cookie. Ví dụ:
SecRule REQUEST_COOKIES "@eq 1" "phase:2,deny,log"
Học viện Kỹ thuật Mật Mã

- Trang 16 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

-

REQUEST_COOKIES-NAME: Biến này là tập hợp các tên Cookie trong các
request header.
SecRule REQUEST_COOKIES_NAMES:PHPSESSID "@eq 1" "phase:2,deny"
2.2.4.

Chức năng chuyển đổi

ModSecurity cung cấp một số chức năng chuyển đổi mà chúng ta có thể áp
dụng cho các biến và các collection. Những biến đổi được thực hiện trên một bản sao
của dữ liệu được kiểm tra, có nghĩa là các HTTP request hoặc response ban đầu vẫn

được giữ nguyên không thay đổi. Chức năng này rất quan trọng. Nếu chúng ta muốn
phát hiện tấn công XSS, chúng ta phải phát hiện mã JavaScript bất kể trường hợp nó
được viết in hay viết thường. Để làm điều này chức năng chuyển đổi có thể được áp
dụng để so sánh một chuỗi viết hoa với chuỗi viết thường. Ví dụ:
SecRule ARGS “<script>” “deny,t:lowercase”
Luật trên sẽ chặn tất cả các URL chứa chuỗi >, <, script bất kể chữ hoa hay thường
sCript, ScRipt, SCRIPT…
Các chức năng chuyển đổi của ModSecurity như sau
Chức năng chuyển đổi

Mô tả

Base64Encode

Mã hóa chuỗi sang base64

Base6Decode

Giải mã từ base64

compressWhitespace

Chuyển tab, dòng mới, space, và nhiều space liên tiếp sang
một dấu space

cssDecode

Giải mã ký tự CSS

escapeSeqDecode

Giải mã ANSI C escape sequences (\n,\r,\\,\?,\”” …)

hexEncode

Mã hóa chuỗi bằng cách sử dụng mã Hex

hexDecode

Giải mã chuỗi hex

htmlEntityDecode

Giải mã HTML (ví dụ: chuyển < thành <)

jsDecode

Giải mã JavaScript escape sequences

Length

Chuyển một chuỗi thành độ dài của chuỗi đó

Lowercase

Chuyển chuỗi sang tất cả ký tự thường

Md5

Chuyển ký tự nhập vào sang MD5

Học viện Kỹ thuật Mật Mã

- Trang 17 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

urlDecode

Giải mã một chuỗi URL

urlDecodeUni

Giống urlDecode, nhưng xử lý được mã hóa kiểu ký tự
Unicode
Bảng 2.2 Các chức năng chuyển đổi của Modsecurity

2.2.5.

Toán tử (Operators)

Các toán tử kiểm tra trong ModSecurity có nhiệm vụ phân tích các biến đầu vào
Variables để ra quyết định. Hầu hết các rule sẽ sử dụng các biểu thức chính quy cho
việc phân tích, nhưng trong một số trường hợp cụ thể thì các phân tính toán tử khác sẽ
hữu ích hơn.
Ta xét trường hợp cần so sánh các giá trị là số thì việc sử dụng biểu thức chính
quy là khá bất lợi cho việc tạo rule và tài nguyên khi thực thi 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 hợp này thì này việc sử dụng các toán tử về số học sẽ hiệu
quả hơn so với biểu thức chính quy.
ModSecurity hỗ trợ 4 nhóm sau:
- Toán tử String – matching: toán tử này dùng phân tích các dữ liệu đầu vào từ 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.
Operator

Description

@begins With

Input begins with parameter

@contains

Input contains parameter

@ends With

Input ends with parameter

@rx

Regular patterns match in input

@pm

Parallel patterns matching, with patterns read from a file
Bảng 2.3 Các toán tử String –matching

-

Toán tử Numerical: Các toán tử hỗ trợ so sánh các giá trị số
Operator

Description

@eq

Equal

@ge

Greater or equal

@gt

Greater than

@le

Less or equal

@lt

Less than

Học viện Kỹ thuật Mật Mã

- Trang 18 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Bảng 2.4 Các toán tử hỗ trợ so sánh

-

Toán tử Validation: Các toán tử kiểm tra mà ModSecurity hỗ trợ được liệt kê sau
Operator

Description

@validateByteRange

Validates that parameter consists only of allowed byte
values

@validateSchema

Vallidates XML payload against a schema

@validateDTD

Validates XML payload against a DTD

@validateUrlEncoding

Validates an URL-encoder string

@validateUtf8Encoding Validates an UTF-8-encoded string
Bảng 2.5 Các toán tử kiểm tra

-

Toán tử Miscellaneous: toán tử này cho phép bạn tạo ra một số rule với các 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)…
Operator
@geoLookup
@inspectFile
@rbl
@verifyCC
@verifyCPF
@verifySSN
@ipMatch

Description
Determines the physical location of an IP address
Nvokes an external script to inspect a file
Looks up the parameter against a RBL (real- time block list)
Checks whether the parameter is a valid credit card number
Checks Whether the parameter is a valid brazilian social security
number
Checks wherther the parameter is a valid US social security
number
Matches input against one or more IP addresses or network

segment
Bảng 2.6 Toán tử Miscellaneous

2.2.6.

Hành động (Actions)

Khi request vi phạm một luật nào đó thì ModSecurity sẽ thực thi một hành
động (action). Khi action không được chỉ rõ trong luật thì luật đó 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 luật chỉ có
một Primary Actions. Có 5 Primary Actions :
Học viện Kỹ thuật Mật Mã

- Trang 19 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

-

Deny: Request sẽ bị ngắt, ModSecurity sẽ trả về HTTP status code 500 hoặc là
status code của người quản trị thiết lập chỉ thị status. Ví dụ:
SecRule REQUEST_URI “hacker” “deny,status:403”

-

Pass: Cho phép request tiếp tục được xử lý ở các luật tiếp theo. Ví dụ:
SecRule secret “log,pass”

-

Allow: Cho phép truy cập ngay lập tức và bỏ qua các phase khác (trừ pha 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 phase sau. Chỉ cho phép truy cập tới các request.
Ví dụ:
SecRule REMOTE_ADDR "^192\.168\.1\.15$" "allow"

-

Redirect: Redirect một request đến một url nào đó. Ví dụ:
SecRule ARGS “<script>” Redirect:/noxss.html

-

Drop: Ngay lập tức kết nối, hành động dừng một kết nối TCP và gửi một gói FIN
• Secondary Actions

Secondary Actions sẽ bổ sung cho Primary Actions, một luật có thể có nhiều
Secondary Actions.
-

Status: Khi một Request vi phạm một luật nào đó thì ModSecurity có thể trả về các
HTTP status code n thay vì status code 500 mặc định. Người quản trị có thể tạo
riêng một trang trả lời với status code, khi request vi phạm các luật.

-

Exec: Thực thi một lệnh nào đó nếu một request vi phạm

-

Log: Ghi nhận những request vi phạm luật

-

Nolog: Không ghi log

-

Pause: ModSecurity sẽ đợi một thời gian n (mili giây) rồi mới trả về kết quả
• Flow Actions

-

Chain: Kết nối 2 hay nhiều luật lại với nhau

-

Skipnext: ModSecurity sẽ bỏ qua n luật theo sau nó
• Default Action

Khi một luật không chỉ rõ action thì luật đó sẽ dùng default action được thiết
lập trong SecDefaultAction.
Học viện Kỹ thuật Mật Mã

- Trang 20 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Giả sử, sau khi thực hiện cấu hình trong tập tin Modsecurity.conf, giá trị của
SecDefaultAction là phase:2,log,auditlog,pass. Ta có một rule đơn giản không được
chỉ định action như sau:
SecRule REQUEST_BASENAME "^login\.php$"
Khi ModSecurity hoạt động, thì luật trên sẽ được hiểu như sau:
SecRule REQUEST_BASENAME "^login\.php$" “phase:2,log,auditlog,pass”
Bằng cách này, ModSecurity giúp bạn triển khai một rule dễ dàng hơn mà không cần
chỉ định một action lặp đi lặp lại nhiều lần
SecDefaultAction phase:2,log,deny,status:404
SecRule ARGS “X1”
SecRule ARGS “X2”
…
SecRule ARGS “Xn”
2.3. Logging
2.3.1.

Debug Log

Sử dụng chỉ thị SecDebugLog lựa chọn file để ghi lại các thông tin debug:
SecDebugLog logs/modsec_debug_log
Người quản trị có thể thay đổi mức độ chi tiết các thông tin được log thông qua chỉ thị:
SevDebuglevel 9
Giá trị log có thể thay đổi từ 0-9:
0 – không ghi log.

1 –Chỉ liệt kê các request bị chặn.
2 –Cảnh báo.
3 – Thông báo cho admin
4 – Chi tiết về các transaction được xử lý.
5,6,7,8 – Cũng như số 4 như thêm những thông tin chi tiết hơn đã được xử lý
9 – Ghi lại mọi thứ, rất chi tiết và đầy đủ về toàn bộ thông tin.
Ví dụ:
[11/Dec/2013:23:36:22
--0800]
[192.168.1.99/sid#f0cfa0][rid#b6972c18]
[/vulnerabilities/csrf/] [1] Access denied with code 403 (phase 2). Match of "rx
^192\\.168\\.1\\.16"
against
"REMOTE_ADDR"
required.
[file
"/etc/httpd/conf.d/Modsecurity.conf"] [line "104"]
2.3.2.

Audit logging

Học viện Kỹ thuật Mật Mã

- Trang 21 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

Apache log ít thông tin vì thế nó không cho phép người quản trị có thể lần
ngược các bước của kẻ tấn công. ModSecurity hỗ trợ audit logging 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
luật cho hợp lý tránh bị “false positive”. Có 2 directives:
- SecAuditEngine On
- SecAuditlog logs/audit_log
Ví dụ về Audit log:
--e2456e72-A-[11/Dec/2013:23:36:22
--0800]
UqlndsCoAWMAADUbGHEAAAAA
192.168.1.15 54625 192.168.1.99 80
--e2456e72-B-GET /vulnerabilities/csrf/ HTTP/1.1
Host: 192.168.1.99
User-Agent: hacker (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: vi-vn,vi;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.99/vulnerabilities/sqli/
Cookie: PHPSESSID=ssj74gomhhnbaeg88eabnu3t50; security=high
Connection: keep-alive
--e2456e72-F-HTTP/1.1 403 Forbidden
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1
--e2456e72-H-Message: Access denied with code 403 (phase 2). Match of "rx
^192\\.168\\.1\\.16"
against
"REMOTE_ADDR"
required.
[file

"/etc/httpd/conf.d/Modsecurity.conf"] [line "104"]
Action: Intercepted (phase 2)
Stopwatch: 1386833782214868 4718 (2035 2927 -)
Producer: ModSecurity for Apache/2.5.12 ( />Server: Apache/2.2.15 (CentOS)
2.3.3.

Tuỳ biến thông tin log

SecAuditEngine chấp nhận 4 giá trị sau:
- On – log tất cả các request
- Off – không ghi log
- RelevantOnly – chỉ log những gì được sinh ra bởi các filtering rules
- DynamicOrRelevanl – log những request tạo ra nội dung hoặc những request được
sinh ra bởi các filtering rules.

Học viện Kỹ thuật Mật Mã

- Trang 22 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

2.4.

Biểu thức chính quy (Regular expressions)
2.4.1.

Giới thiệu về biểu thức chính quy

Biểu thức chính quy (regular expression) là một biểu thức mà nó sẽ đại diện cho
một tập hợp các chuỗi ký tự, theo những quy tắc cú pháp nhất định. Nó thường được
dùng trong các trình biên tập văn bản và các tiện ích tìm kiếm và xử lý văn bản dựa
trên các mẫu được quy định. Nhiều ngôn ngữ lập trình cũng hỗ trợ biểu thức chính quy
trong việc xử lý chuỗi, chẳng hạn như Perl có bộ máy mạnh mẽ để xử lý biểu thức
chính quy được xây dựng trực tiếp trong cú pháp của chúng
Cơ bản biểu thức chính quy có 5 loại sau:
-

Ký hiệu (sysbol): Dùng để diễn đạt một thành ngữ chỉ chứa duy nhất ký tự đó mà
thôi. Thể loại này thường được dùng để diễn đạt những chữ viết thường hay một
nhóm chữ đã được xác định.

Ví dụ: biểu thức chính quy “a” diễn tả thành ngữ chỉ chứa một chữ cái là “a”. hay
biểu thức chính quy “abc” diễn tả thành ngữ chứa “abc”
-

Thay thế (Alternation): Dùng để diễn đạt tính cái này hoặc cái kia (OR). Ký tự |
được dùng để diễn tả thay

Ví dụ: Giả sử biểu thức chính quy A nhận ký tự a và biểu thức chính quy B
nhận ký tự b, thì thay thế thế của A và B hay A | B sẽ là một biểu thức chính quy mới
và nhận a hoặc b. Viết ngắn gọn A | B mô tả thành ngữ {“a”,”b”}
-

Kết hợp (Concatenation): Dùng để diễn đạt tính chất AND. Dấu chấm (.) được
dùng để diễn tả AND

Ví dụ: Giả sử A and B là 2 biểu thức chính quy, thì kết hợp của A và B hay là

A.B. Ở đây kết hợp là dấu chấm (.). Nếu biểu thức chính quy A nhận ký tự a và biểu
thức chính quy B nhận ký tự b, thì kết hợp của A và B hay A.B sẽ là một biểu thức
chính quy mới nhận a và b
-

Epsilon: Dùng để diễn đạt chuỗi kí tự trống. dấu €(epsilon) được dung để diễn tả
chuỗi kí tự trống
Ví dụ: (“ab” | e) mô tả thành ngữ (“”,”ab”)

-

Lặp đi lặp lại (Repetition): Dùng để diễn đạt sự lặp đi lặp lại của ký tự. Có vài dấu
hiệu dùng để diễn tả sự lặp lại

Học viện Kỹ thuật Mật Mã

- Trang 23 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

2.4.2.

Ứng dụng của biểu thức chính quy trong Modsecurity

Qua trên ta thấy được việc sử dụng biểu thức chính quy trong việc lập trình và
đặc biệt là ứng dụng vào việc thiết lập các luật cho ModSecurity là rất hữu ích. Biểu
thức chính quy giúp cho việc tối ưu hóa các luật một cách đơn giản nhất mà vẫn đảm

bảo được khả năng kiểm tra luồng dữ liệu. Bình thường dựa vào các mẫu không phải
là biểu thức chính quy thì số ký tự sẽ phải đầy đủ, do đó độ dài của một luật sẽ lớn.
Dẫn tới việc xử lý sẽ chậm đi rất nhiều.
2.5.

Viết và phân tích một số luật cơ bản

Ví dụ 1: cấm các request có chưa từ “script”
SecRule REQUEST_URI "script" "phase:2,deny,status:404"
Với biểu thức so sánh như trên thì ModSecurity thực thi kiểm tra dữ liệu trong URI từ
phía người dùng và xác định có sự tồn tại của chuỗi “script” hay không. Nếu như
chuỗi “script” xuất hiện trong URI thì các hành động (action) được thực hiện. Trong
trường hợp này, ta sử dụng 2 hành động là deny và status để cấm các truy cập đấy tới
server và đưa ra thông báo mã trạng thái lỗi 404 (Not found).
Chú ý: Một rule có thể không tồn tại action hoặc nhiều hơn một action. Nếu ta
sử dụng nhiều action trong một rule, ta có thể phân cách bằng dấu phẩy (,) hay khoảng
trắng giữa các action
-

Liên kết các luật (chain) và Sử dụng toán tử phủ định

ModSecurity cho phép liên kết các SecRule riêng lẽ với nhau thành một
SecRule duy nhất thông qua từ khóa “chain”. Liên kết này sẽ giảm thiểu các tình
huống cảnh báo không chính xác, giúp đơn giản hóa việc viết luật trong trường hợp
cần kiểm tra các điều kiện mang tính tuần tự. Ngoài ra ModSecurity còn cho phép sử
dụng phương pháp phủ định một thành phần bất kỳ trong rule.
Ví dụ 2: Người quản trị web server muốn chặn tất cả người dùng truy cập có UserAgent là “hacker” , Trừ địa chỉ IP 192.168.1.15 là được truy cập ta viết như sau:
SecRule HTTP_User-Agent "hacker" "chain,deny"
SecRule REMOTE_ADDR "!^192\.168\.1\.15"
Trong ví dụ trên ta sử dụng “chain” để liên kết 2 luật với nhau. Luật thứ nhất ta

sử dụng biến HTTP_User-Agent để lọc User-Agent có tên là “hacker”. Và thực hiện
Học viện Kỹ thuật Mật Mã

- Trang 24 -

Khoa Công Nghệ Thông Tin


Bảo mật máy chủ ứng dụng Web với ModSecurity

hành động deny để chặn truy cập nếu User-Agent đó là hacker. Luật thứ 2 sử dụng
biến REMOTE_ADDR để chỉ định ra địa chỉ IP và ở trường hợp này là 192.168.1.15.
Sử dụng dấu (!) ở đây có chức năng phủ định lại luật trên. Giả sử như ở luật thứ 2 ta
không sử dụng dấu chấm than (!) thì 2 luật đấy sẽ có ý nghĩa là User-Agent là
“hacker” từ địa chỉ IP 192.168.1.15. Còn khi ta sử dụng dấu chấm than (!) ở luật thứ 2
khi đó địa chỉ IP 192.168.1.15 nếu có User-agent là “hacker” sẽ vẫn được truy cập tới
server, còn lại các địa chỉ IP khác nếu có User-Agent là “hacker ” sẽ bị cấm
Ví dụ 3: Khi hacker sử dụng kỹ thuật biến đổi dữ liệu nhằm thực hiện câu truy vấn
trong tấn công SQL Injection như sau
“id=1&UniON%20SeLeCT%201,2,3,4,5,6”
Trong trường hợp này ta cần chuyển đổi các ký tự sang chữ thường (lowercase) trước
khi kiểm tra. Ví dụ ta sử dụng luật sau:
SecRule ARGS "@contains union
t:compressWhitespace,deny,status:404"

select

"

"phase:2,t:lowercase,

Ở luật trên ta đưa ra chuỗi “union select” đây không phải là một biểu thức so sánh, bởi
vì chúng không chứa ký tự đặc biệt để xác định đây là một mẫu biểu thức. Để tối ưu
hơn ta sử dụng toán tử @contains. Khi sử dụng các hành động như lowercase,
compressWhitespace ModSecurity sẽ thực hiện lọc các tự khóa có dạng sau:
union select
uNioN SeLect
…
UNION SELECT

Học viện Kỹ thuật Mật Mã

- Trang 25 -

Khoa Công Nghệ Thông Tin