Ngày nay khi công nghệ thông tin phát triển, nhu cầu xây dựng cho mình một website riêng với mục đích giải trí, quảng bá sản phẩm, …. của các cá nhân, tổ chức ngày càng gia tăng thì vấn đề bảo mật các website này ngày càng được quan tâm. Hiện nay, nhiều tổ chức đã nghiên cứu và cung cấp các giải pháp giúp cho mỗi cá nhân, tổ chức có thể xây dựng website riêng và vấn đề bảo mật được đặt lên hàng đầu. Trên Dự án về kiểm thử các lỗ hổng của ứng dụng web (Open Web Application Security Project OWASP), các tổ chức, các công ty đã xây dựng lên tường lửa ứng dụng web (Web Application Firewall WAF) để bảo vệ hệ thống máy chủ web như sản phẩm Imperva, CheckPoint hay Modsecurity. Trong khi Imperva và CheckPoint là sản phẩm thương mại thì Modsecurity là một sản phẩm mã nguồn mở và có nhiệm vụ ngăn chặn một số dạng tấn công nhằm vào web và cơ sở dữ liệu. Do đó, chúng em lựa chọn đề tài: “Tìm hiểu, thử nghiệm tường lửa ứng dụng web modsecurity”.
Trang 1HỌC VIỆN KỸ THUẬT MẬT MÃ KHOA AN TOÀN THÔNG TIN
Giảng viên: Bùi Việt Thắng
Hà Nội, 11/201
Trang 2MỤC LỤC
MỤC LỤC 1
DANH SÁCH HÌNH ẢNH 3
LỜI MỞ ĐẦU 5
CHƯƠNG I – GIỚI THIỆU VỀ TẤN CÔNG SQL INJECTION 6
1.1 Khái niệm 6
1.2 Một số dạng tấn công thường gặp với các ứng dụng 6
1.2.1 Dạng tấn công vượt qua kiểm tra lúc đăng nhập 6
1.2.2 Dạng tấn công sử dụng câu lệnh SELECT 6
1.2.3 Dạng tấn công sử dụng câu lệnh INSERT 6
1.2.4 Dạng tấn công sử dụng stored-procedures 6
1.3 Các dạng lỗi thường gặp 7
1.3.1 Không kiểm tra ký tự thoát truy vấn 7
1.3.2 Xử lý không đúng kiểu 7
1.3.3 Lỗi bảo mật bên trong máy chủ sơ sở dữ liệu 7
1.3.4 Blind SQL Injection 8
1.3.5 Thay đổi giá trị điều kiện truy vấn 8
1.3.6 Điều kiện lỗi 8
1.3.7 Thời gian trễ 8
CHƯƠNG II – GIỚI THIỆU VỀ MODSECURITY 9
2.1 Khái niệm 9
2.2 Các khả năng của ModSecurity 9
2.3 Cách xử lý một yêu cầu ModSecurity 10
2.4 Cách viết một tập luật cho ModSecurity 11
2.4.1 Cơ bản về Regular Expression –biểu thức chính quy 12
Trang 32.4.2 Chỉ dẫn SecRule 13
2.4.3 Biến trong ModSecurity 13
2.4.4 Operator 14
2.4.5 Action 16
2.4.6 Lưu trữ giữ liệu giữa các request 19
2.4.7 Tạo chain rule- chuỗi các luật 19
CHƯƠNG III – TRIỂN KHAI CÀI ĐẶT CẤU HÌNH MODSECURITY CHO MÁY CHỦ WEB APACHE 21
3.1 Chuẩn bị 21
3.2 Xây dựng kịch bản 21
3.3 Các bước thực hiện 21
3.4 Cài đặt website có lỗ hổng bảo mật 21
3.4.1 DVWA 21
3.4.2 Thực hiện 22
3.5 Thực hiện tấn công SQL Injection lên máy chủ web 23
3.6 Cài đặt mod_security lên máy chủ Linux CentOS 24
3.6.1 Cài đặt và cấu hình mod_security 24
3.6.2 Thiết lập luật cho mod_security 25
3.6 Kiểm tra 26
KẾT LUẬN 27
PHỤ LỤC 28
1 Cài đặt Apache 28
2 Cài đặt MariaDB 28
3 Cài đặt PHP 29
4 Cài đặt phpMyAdmin 29
TÀI LIỆU THAM KHẢO 31
Trang 4DANH SÁCH HÌNH ẢNH
Hình 2.1: Quá trình xử lý yêu cầu của ModSecurity 10
Hình 3.1: Mô hình triển khai 21
Hình 3.2: DVWA 22
Hình 3.3: Giao diện trang web có lỗ hổng bảo mật 23
Hình 3.4: Giao diện khai thác thông tin 23
Hình 3.5: Cài đặt modsecurity 24
Hình 3.6: File cấu hình 25
Hình 3.7: File mod_security.conf 25
Hình 3.8: Nội dụng rule 26
Hình 3.9: Kết quả kiểm tra 26
Trang 5DANH MỤC BẢNG
Bảng 2.1: Một số biểu thức chính quy 12
Bảng 2.2: Các ký tự meta thường dùng 13
Bảng 2.3: Các giá trị toán tử so trùng chuỗi 15
Hình 2.4: Các giá trị toán tử hỗ trợ so sánh 15
Hình 2.5: Các giá trị toán tử kiểm tra 15
Hình 2.6: Các giá trị toán tử hỗn độn 16
Hình 2.7: Các giá trị disruptive actions 17
Hình 2.8: Các giá trị flow actions 17
Hình 2.9: Các giá trị metadata actions 17
Hình 2.10: Các giá trị variable actions 18
Hình 2.11: Các giá trị logging actions 18
Hình 2.12: Các giá trị special actions 18
Hình 2.13: Các giá trị miscellaneous actions 19
Trang 6LỜI MỞ ĐẦU
Ngày nay khi công nghệ thông tin phát triển, nhu cầu xây dựng cho mình một website riêng với mục đích giải trí, quảng bá sản phẩm, … của các cá nhân, tổ chức ngày càng gia tăng thì vấn đề bảo mật các website này ngày càng được quan tâm Hiện nay, nhiều tổ chức đã nghiên cứu và cung cấp các giải pháp giúp cho mỗi cá nhân, tổ chức có thể xây dựng website riêng và vấn
đề bảo mật được đặt lên hàng đầu
Trên Dự án về kiểm thử các lỗ hổng của ứng dụng web (Open Web Application Security Project - OWASP), các tổ chức, các công ty đã xây dựng lên tường lửa ứng dụng web (Web Application Firewall - WAF) để bảo vệ hệ thống máy chủ web như sản phẩm Imperva, CheckPoint hay Modsecurity Trong khi Imperva và CheckPoint là sản phẩm thương mại thì Modsecurity là một sản phẩm mã nguồn mở và có nhiệm vụ ngăn chặn một số dạng tấn công nhằm vào web và cơ sở dữ liệu Do đó, chúng em lựa chọn đề tài: “Tìm hiểu, thử nghiệm tường lửa ứng dụng web modsecurity”
Bản báo cáo này gồm 3 phần:
Chương 1 – Giới thiệu về tấn công SQL Injection: Chương này sẽ giới thiệu về các khái niệm, các dạng tấn công, một số lỗi thường gặp trong tấn công SQL Injection
Chương 2 - Giới thiệu về Modsecurity: Chương này sẽ giới thiệu về các khái niệm, các viết một tập luật, … và các vấn đề khác liên quan đến Modsecurity
Chương 3 - Triển khai mô hình : Chương này sẽ triển khai cài đặt, cấu hình rule cho modsecurity để chống lại tấn công SQL Injection
Mặc dù đã cố gắng nhưng do kiến thức có hạn và thời gian còn nhiều hạn chế nên chắc chắn bản báo cáo còn nhiều thiếu sót, chúng em rất mong nhận được những ý kiến đóng góp của thầy cô và các bạn sinh viên để chúng em có thể tìm hiểu sâu hơn về vấn đề này
Chúng em xin chân thành cảm ơn!
Trang 7CHƯƠNG I – GIỚI THIỆU VỀ TẤN CÔNG SQL INJECTION
1.1 Khái niệm
SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác, delete, insert, update, v.v trên cơ sở dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy SQL injection thường được biết đến như là một vật trung gian tấn công trên các ứng dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase
1.2 Một số dạng tấn công thường gặp với các ứng dụng
1.2.1 Dạng tấn công vượt qua kiểm tra lúc đăng nhập
Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web Thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người dùng nhập thông tin về tên đăng nhập và mật khẩu Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp
1.2.2 Dạng tấn công sử dụng câu lệnh SELECT
Dạng tấn công này phức tạp hơn Để thực hiện được kiểu tấn công này,
kẻ tấn công phải có khả năng hiểu và lợi dụng các sơ hở trong các thông báo lỗi từ hệ thống để dò tìm các điểm yếu khởi đầu cho việc tấn công
1.2.3 Dạng tấn công sử dụng câu lệnh INSERT
Thông thường các ứng dụng web cho phép người dùng đăng ký một tài khoản để tham gia Chức năng không thể thiếu là sau khi đăng ký thành công, người dùng có thể xem và hiệu chỉnh thông tin của mình SQL injection có thể được dùng khi hệ thống không kiểm tra tính hợp lệ của thông tin nhập vào
1.2.4 Dạng tấn công sử dụng stored-procedures
Việc tấn công bằng stored-procedures sẽ gây tác hại rất lớn nếu ứng dụng được thực thi với quyền quản trị hệ thống 'sa' Ví dụ, nếu ta thay đoạn mã tiêm vào dạng: '; EXEC xp_cmdshell ‘cmdd.exe dir C: ' Lúc này hệ thống sẽ thực hiện lệnh liệt kê thư mục trên ổ đĩa C:\ cài đặt server Việc phá hoại kiểu nào tuỳ thuộc vào câu lệnh đằng sau cmd.exe
Trang 81.3 Các dạng lỗi thường gặp
1.3.1 Không kiểm tra ký tự thoát truy vấn
Đây là dạng lỗi SQL injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu vào trong câu truy vấn SQL Kết quả là người dùng cuối có thể thực hiện một số truy vấn không mong muốn đối với cơ sở dữ liệu của ứng dụng Dòng
mã sau sẽ minh họa lỗi này:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Câu lệnh này được thiết kế để trả về các bản ghi tên người dùng cụ thể từ bảng những người dùng Tuy nhiên, nếu biến "userName" được nhập chính xác theo một cách nào đó bởi người dùng ác ý, nó có thể trở thành một câu truy vấn SQL với mục đích khác hẳn so với mong muốn của tác giả đoạn mã
trên Ví dụ, ta nhập vào giá trị của biến userName như sau:
a' or 't'='t
Khiến câu truy vấn có thể được hiểu như sau:
SELECT * FROM users WHERE name = 'a' or
't'='t';
Nếu đoạn mã trên được sử dụng trong một thủ tục xác thực thì ví dụ trên
có thể được sử dụng để bắt buộc lựa chọn một tên người dùng hợp lệ bởi 't'='t' luôn đúng
1.3.2 Xử lý không đúng kiểu
Lỗi SQL injection dạng này thường xảy ra do lập trình viên hay người dùng định nghĩa đầu vào dữ liệu không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ liệu đầu vào Điều này có thể xảy ra khi một trường số được sử dụng trong truy vấn SQL nhưng lập trình viên lại thiếu bước kiểm tra dữ liệu đầu vào để xác minh kiểu của dữ liệu mà người dùng nhập vào có phải là số
hay không
1.3.3 Lỗi bảo mật bên trong máy chủ sơ sở dữ liệu
Đôi khi lỗ hổng có thể tồn tại chính trong phần mềm máy chủ cơ sở dữ liệu, như là trường hợp hàm mysql_real_escape_string() của các máy chủ MySQL Điều này sẽ cho phép kẻ tấn công có thể thực hiện một cuộc tấn công SQL injection thành công dựa trên những ký tự Unicode không thông thường ngay cả khi đầu nhập vào đang được thoát
Trang 91.3.5 Thay đổi giá trị điều kiện truy vấn
Dạng lỗi này khiến cho kẻ tấn công có thể thay đổi giá trị điều kiện trong câu truy vấn, làm sai lệch sự hiển thị của một ứng dụng chứa lỗi này
1.3.6 Điều kiện lỗi
Lỗi SQL injection dạng này dẫn tới việc buộc cơ sở dữ liệu chỉ được phép đánh giá khi mà giá trị của câu lệnh WHERE là đúng Ví dụ:
SELECT 1/0 from users where username='Ralph'; Phép chia cho 0 chỉ được đánh giá là lỗi khi mà người dùng có tên
"Ralph" tồn tại trong cơ sở dữ liệu
1.3.7 Thời gian trễ
Lỗi SQL injection dạng này tồn tại khi thời gian xử lý của một hay nhiều truy vấn SQL phụ thuộc vào dữ liệu logic được nhập vào hoặc quá trình xử lý truy vấn của SQL engine cần nhiều thời gian Tin tặc có thể sử dụng lỗi SQL injection dạng này để xác định thời gian chính xác mà trang cần tải khi giá trị
nhập vào là đúng
Trang 10CHƯƠNG II – GIỚI THIỆU VỀ MODSECURITY
2.1 Khái niệm
ModSecurity là một bộ máy phát hiện và phòng chống xâm nhập dành cho các ứng dụng web (hay một web application firewall) ModSecurity hoạt động như một module của máy chủ web Apache, mục đích của ModSecurity
là tăng cường bảo mật cho các ứng dụng web, bảo vệ chúng trước các cuộc tấn công vào ứng dụng web ModSecurity chỉ hoạt động khi được tích hợp với Apache
ModSecurity được phát triển bởi Ivan Ristic – Chuyên gia bảo mật ứng dụng năm 2002 – Tác giả cuốn Apache Web Security
Hiện tại mod_security sử dụng giấy phép GPL, hoàn toàn miễn phí
2.2 Các khả năng của ModSecurity
ModSecurity có các khả năng sau:
- ModSecurity có khả năng thanh tra các thông điệp HTTP request trước khi nó được xử lý hoàn toàn bởi Apache
- Thanh tra, lưu trữ và tùy chỉnh các file được tải lên server
- Thực thi các hành động anti-evasion một cách tự động Hầu hết các Web Application Firewalls là signature-based, chúng sẽ xem xét HTTP Traffic và tìm kiếm các dấu hiệu được định nghĩa sẵn Nếu thấy HTTP Traffic có sự trùng khớp với một dấu hiệu nào đó thì Firewall sẽ tiến hành sàn lọc Nhưng nếu kẻ tấn công thay đổi
dữ liệu tấn công (attack payload) bằng nhiều cách mà vẫn cho cùng một kết quả và sự thay đổi này không trùng khớp với bất cứ một signature nào của Firewall thì Request đó sẽ vượt qua được Firewall Kỹ thuật thay đổi attack payload để tránh sự phát hiện gọi là evasion techniques
- Có khả năng phân tích tỉ mỉ và ghi nhật ký toàn bộ các hoạt động của giao thức HTTP như thanh tra các thông điệp Request,
Trang 11- Cuối cùng là trung tâm của ModSecurity sẽ bảo vệ Apache Server
và các ứng dụng Web chạy trên Apache trước các cuộc tấn công, trong đó phả kể đến là các cuộc tấn công từ chối dịch vụ vào ứng dụng Web
2.3 Cách xử lý một yêu cầu ModSecurity
ModSecurity sẽ được thành phần con HTTP_REQUEST (nằm trong Apache core) gọi ra khi cần thiết Việc xử lý yêu cầu HTTP của ModSecurity tuân theo vòng đời xử lý yêu cầu của Apache ModSecurity có thể được gọi ra
ở 5 thời điểm trong chu trình xử lý của Apache tương ứng với 5 pha sau: request headers, request body, response headers, response body và logging
Hình 2.1: Quá trình xử lý yêu cầu của ModSecurity
- Request Headers: Luật đặt tại đây sẽ được thực hiện ngay sau khi Apache đọc phần request header, lúc này request body vẫn chưa được đọc
Trang 12- Request Body: Đây là thời điểm các thông tin chức năng chung đưa vào được phân tích và xem xét, các luật mang tích application-oriented thường được đặt ở đây Ở thời điểm này Apache đã đọc xong phần request body
- Response Headers: Đây là thời điểm ngay trước khi phần response header được gửi trả về cho client Đặt luật ở đây nếu muốn giám sát quá trình response sau đó Chú ý rằng một số thông tin response header được thêm vào bởi Apache như Date, Server, Connection mà chúng ta cũng không thể thay đổi ở thời điểm này
- Response Body: Ở thời điểm này có thể viết các luật truy nhập vào response body Đặt luật ở đây nếu muốn kiểm tra những dữ liệu HTML gửi trả về cho client
- Logging: Đây là thời điểm các hoạt động log được thực hiện, các luật đặt ở đây sẽ định rõ việc ghi log sẽ như thế nào, nó sẽ kiểm tra các error message log của Apache Đây cũng là thời điểm cuối cùng để chặn các kết nối không mong muốn, kiểm tra các response header mà bạn không thể kiểm tra ở pha 3 và pha 4
2.4 Cách viết một tập luật cho ModSecurity
Rule – luật là phần quan trọng nhất đối với tường lửa nói chung và ModSecurity nói riêng Để viết được các luật cho ModSecurity thì người quản trị cần phải có hiểu biết về giao thức HTTP và có thể sử dụng Regular Expression (việc thành thạo giao thức HTTP và các biểu thức chính quy giúp cho việc tối ưu hóa các rule và cũng là tối ưu hóa hoạt động của Apache) Các luật của ModSecurity được viết hoàn toàn dựa vào các trường trong thông điệp HTTP Giả sử một luật đơn giản như sau:
SecRule REQUEST_HEADERS:Referer “.swf”\
“log,deny,phase:1,status:403,msg:’x-flash’”
Trong đó:
- REQUEST_HEADERS: Referer là một trường trong HTTP header
- “.swf” là biểu thức chính quy – Regular Expression
Như vậy để viết các luật một cách hiệu quả thì người quản trị phải biết rõ như thế nào là một thông điệp HTTP bình thường đối với Web Server của mình, như thế nào thì bị thay đổi để phục vụ các ý đồ xấu
Trang 132.4.1 Cơ bản về Regular Expression –biểu thức chính quy
ModSecurity sử dụng Regular Expression để so khớp với các luật Regular Expression được điều khiển bởi các thư viện PCRE (Perl Compatible Regular Expression) Regular Expression là công cụ, ngôn ngữ cực mạnh dùng để mô tả văn bản và các thao tác trên văn bản Một Regular Expression thường được ứng dụng lên một chuỗi
Ví dụ: Luật sau sẽ phù hợp với bất kỳ Request Protocol nào chứa chuỗi HTTP như HTTP/1.0 hoặc HTTP/1.1
SecRule REQUEST_PROTOCOL “HTTP”
Một Regular Expression gồm 2 phần: Literal (trực kiện) và metacharacter (siêu ký tự - các ký tự đặc biệt)
- Literal: Là một ký tự (a-z) mà bạn muốn đem so khớp với chuỗi đích
- Metacharacter: Là một ký tự đặc biệt hoạt động như một mệnh lệnh đối với bộ phận phân tích ngữ pháp (parser) của RE
Một số ví dụ về Regular Expression:
không khớp với Joyfull
,enJoy
Bảng 2.1: Một số biểu thức chính quy
Các ký tự meta thường dùng:
với B, AB, AAB
B hay AB
AB, AAB
Trang 14^/$ Bắt đầu/ kết thúc 1 chuỗi hay 1dòng/
trong pattern Ví dụ ((a(b))c) sẽ khớp với b, ab, abc
Ví dụ không so trùng với a hay b hay c
Bảng 2.2: Các ký tự meta thường dùng
2.4.2 Chỉ dẫn SecRule
SecRule là chỉ dẫn chính để tạo luật cho ModSecurity Nó được sử dụng
để phân tích dữ liệu và thực thi các hành động dựa trên các kết quả tìm được
Cú pháp: SecRule Variables Operator [Action]
Ví dụ: SecRule REQUEST_URI”sercet”
- Variables: Là biến - phần của thông điệp request hoặc response Biến
có thể là một biến chuẩn – standard variable (ví dụ: REQUEST_URI chứa URI của request trên server để định danh và block truy cập tới
vị trí/secret.html) hoặc biến tập hợp – collection (ví dụ: REQUEST_HEADERS chứa tất cả các giá trị của request header)
Có trên 70 biến có thể sử dụng để tạo luật cho ModSecurity
- Operator: Chỉ rõ phương thức để so sánh và dữ liệu để so sánh với biến Mặc định là @rx – nếu không chỉ rõ Rule engine sẽ thể hiện chuỗi như biểu thức chính quy để so khớp với biến cụ thể ModSecurity hỗ trợ 22 toán tử phục vụ cho việc so khớp với chuỗi
- Action: Liệt kê các hành động sẽ xảy ra khi khớp với luật Action bao gồm cho phép hoặc từ chối request và chỉ rõ trạng thái trả về Nếu không có Action nào được chỉ rõ thì Action mặc định được thực thi Action mặc định được thiết lập ở chỉ dẫn SecDefaultAction
Ví dụ: SecDefaultAction “phase:2,deny,log, status:403”
2.4.3 Biến trong ModSecurity
ModSecurity có 77 loại biến và chúng được phân loại như sau:
Scalar_variables: Chứa một phần thông tin dữ liệu, có thể là chuỗi hoặc
số Ví dụ: REMOTE_ADDR luôn chứa địa chỉ IP của người dùng
Collections: Nhóm các biến lại với nhau thành một nhóm
Read-only collections: Nhóm các biến không thể thay đổi trong quá
trình thực hiện tương tác giữa ModSecurity và Apache
Trang 15Read/write collections: Nhóm này được sử dụng trong các trường hợp
bạn cần triển khai các rule có sự thay đổi trong dữ liệu đầu vào
Special collections: Nhóm các biến đặc biệt được dùng trong việc trích
xuất dữ liệu đầu vào dưới dạng XML
Persistent collections: Khi các rule sử dụng các thành phần trong nhóm
này, thì dữ liệu sẽ được lưu trữ trong CSDL nội bộ của ModSecurity Trong các tác vụ theo dõi như IP, phiên làm việc hoặc theo dõi người dùng đăng nhập thì việc lưu trữ sẽ được sử dụng
2.4.4 Operator
Các toán tử trong ModSecurity có nhiệm vụ phân tích các biến đầu vào
để ra quyết định Hầu hết các rule sẽ sử dụng các regulax expression cho việc phân tích, nhưng trong một số trường hợp cụ thể thì các phân nhóm toán tử khác sẽ hữu ích hơn Các toán tử bắt đầu với nhãn “@” chỉ ra phương thức để
so khớp
Trong trường hợp ta cần so sánh các giá trị là số thì việc sử dụng regulax expression là khá bất lợi cho việc tao rule và tài nguyên thực thi khi so sánh rule Modsecurity hỗ trợ một nhóm phương thức so sánh khác nhau nhằm tăng hiệu năng cho phần kiểm tra Trong một số trường hợp thì việc sử dụng các toán tử về số học sẽ hiệu quả hơn nhiều so với regulax expression
Trang 16Bảng 2.3: Các giá trị toán tử so trùng chuỗi
Numerical operators
Trong bảng dưới đây liệt kê các toán tử hỗ trợ so sánh các giá trị số Trong phiên bản Modsecurity trước 2.5.12 thì việc so sánh các giá trị số học phải thông qua regulax expression, việc này làm ảnh hưởng lớn đến hiệu năng hoạt động của server
Hình 2.4: Các giá trị toán tử hỗ trợ so sánh
Validation operators
Các toán tử kiểm tra mà ModSecurity hỗ trợ được liệt kê trong bảng sau:
Hình 2.5: Các giá trị toán tử kiểm tra
Miscellanreous operators
Phân nhóm này cho phép bạn tạo ra một số rule với chức năng lọc khá hữu dụng như: Phát hiện lộ thông tin credit card (@verifyCC), kiểm tra vùng địa lý của IP người dùng (@geoLookup),…