ModSecurity là một tường lửa dành cho ứng dụng Web dạng nguồn mở. ModSecurity giúp chống lại các tấn công vào ứng dụng web, theo dõi các truy cập thời gian thực mà không ảnh hưởng đến kiến trúc phần cứng đã triển khai. Nhân của nó sử dụng các tập luật để kiểm tra các lỗ hổng web thường thấy.
ModSecurity hoạt động với chương trình máy chủ web (ví dụ: Apache) sẽ thực hiện các tác vụ như sau:
Parsing: ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu trúc dữ liệu mà ModSecurity định nghĩa sẵn. Cấu trúc này sẽ được chuyển qua cơ chế so trùng mẫu trong tập rule để phân tích nguy cơ.
Buffering: Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt động của ModSec. Việc này có ý nghĩa khi các request gởi đến ứng dụng web thì phải thông qua ModSecurity trước khi đến ứng dụng xử lý và những response cũng sẽ được phân tích trước khi trả về phía client. Cơ chế này là cách duy nhất để có thể ngăn chặn các cuộc tấn công thời gian thực, các dữ liệu mà ModSecurity nhận được và phân tích sẽ được lưu trữ trong RAM (bao gồm request body và response data)
Logging: ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers, request body, response header, response body nhằm hỗ trợ người quản trị phân tích nguy cơ mà hệ thống đang gặp phải để có thể ra quyết định kiểm soát.
Rule Engine: Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát hiện các dạng tấn công và thực hiện phòng chống. ModSecurity cùng phát triển với dự án OWASP phát triển các mẫu để phân tích và phòng chống các tấn công hệ thống web đó là bộ luật OWASP_ModSecurity_Core_Rule_Set_Project. (Tham khảo tại www.owasp.org)
Các phân nhóm mà Core_Rule_Set hỗ trợ: - HTTP Protection
- Real-time Blacklist Lookups - Web-based Malware Detection - HTTP Denial of Service Protections - Common Web Attacks Protection - Automation Detection
- Integration with AV Scanning for File Uploads - Tracking Sensitive Data
- Trojan Protection
- Identification of Application Defects - Error Detection and Hiding
2.1. Cấu trúc luật của ModSecurity
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 operator được dùng theo dạng Regular expression nhằm tạo nên cơ chế phân tích linh động cho các rule. ACTIONS: 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 ghi log, deny gói tin bằng cách sử dụng mã trạng thái 404 (Not found).
2.2. Quy trình xử lý trong ModSecurity
Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước, 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.1: Quy trình xử lý của ModSecurity
Bước 1 Request Header: Đâ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 yêu cầu 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 …
Bước 2 Request body: Bước 2 là quá trình kiểm tra chính trong quá trình máy kháchgửi yêu cầu đến máy chủ, 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 để tải tập tin lên phía máy chủ. Việc kiểm tra này bảo đảm dữ liệu đưa
lên máy chủ là an toàn, tránh tình trạng tải mã độc hoặc các dạng tấn công như: Stored XSS, Ajax Injection …
Bước 3 Response headers: Những yêu cầu đã được xử lý tại máy chủ 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 luật để 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ề.
Bước 4 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 bước 1 và 2 không phát hiện được tấn công.
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.
Bước 5 Logging: Việc ghi nhật ký log sẽ ghi nhận các cảnh báo cũng như quy trình làm việc của ModSecurity.
2.3. Kiểu biếncủa ModSecurity
ModSecurity sử dụng hai loại biến, loại thứ nhất là các biến chuẩn (standard variable) chỉ chứa một giá trị đơn ứng với mỗi biến, và loại thứ hai là các biến tập (collection variable) có thể chứa nhiều giá trị ứng với một biến. Ví dụ về biến tập như REQUEST_HEADER, nó chứa tất cả giá trị trường header của một thông điệp HTTP.
Để truy cập vào các trường trong biến tập, sử dụng cấu trúc tên_biến: tên_trường, ví dụ luật sau:
SecRule REQUEST_HEADER:Referer “acb.vn”
Hầu hết các biến tập có thể được sử dụng độc lập mà không cần chỉ định trường cụ thể. Khi sử dụng tên biến tập độc lập tương đương với việc truy cập tới mọi trường trong tập đó.
Một số biến tập có các trường cố định (vd: GEO có country_name, city,...) nhưng một số lại có các trường không cố định, tùy thuộc vào nội dung máy khách gửi đến. Trong các biến tập, có thể truy cập tới các trường không tồn tại hoặc trường đó không được gán giá trị mà không phát sinh lỗi. Điều này cần ghi nhớ trong trường hợp sửa lỗi, có thể bỏ qua khả năng trường giá trị trong biến tập không tồn tại hoặc không được gán giá trị.
Bảng 2.1: Biến chuẩn của ModSecurity
Biến chuẩn Ý nghĩa
REMOTE_ADDR Địa chỉ IP của máy khách
REMOTE_HOST hostname của máy khách (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 Phần mềm trên server
TIME_YEAR Năm hiện tại
TIME_MON Tháng hiện tại
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ụ: 2015013075030 : 30/01/2015 07h 50' 30'' API_VERSION Phiên bản các API
THE_REQUEST Dòng đầu tiên của request. vd: GET / HTTP/1.1
REQUEST_URI Yêu cầu URI
REQUEST_FILENAME Tên file được yêu cầu đến.
Biến lưu trữ dữ liệu giữa các yêu cầu.
Có ba loại biến tập trong ModSecurity có thể được sử dụng để lưu trữ lâu dài. Thông thường, các biến sẽ hết hiệu lực mỗi khi yêu cầu hiện thời được xử lý hoàn tất. Tuy nhiên trong một số trường hợp, chúng ta lại cần lưu giữ chúng lại và sử dụng chúng khi thao tác với các yêu cầu sau này. Ba loại biến tập có thể được sử dụng cho mục đích lưu trữ là ip, session, user.
Biến tập “ip” được dùng để lưu thông tin về một người dùng thông qua địa chỉ ip. Chúng ta có thể sử dụng nó cho một số mục đích như phát hiện ra người dùng nào yều cầu nhiều lần vào một tài nguyên, hoặc số lần yêu cầu của một người dùng, giả sử để chống tấn công từ chối dịch vụ (DoS). Trước khi sử dụng các biến trên, chúng ta cần khởi tạo chúng, ví dụ:
SecAction initcol:ip=%{REMOTE_ADDR},nolog,pass
Trong đó, REMOTE_ADD là biến lưu địa chỉ ip của máy khách gửi yêu cầu. Để lưu trữ biến, chúng ta cũng cần cấu hình một thư mục dữ liệu cho ModSecurity thông qua chỉ thị SecDataDir, ví dụ:
SecDataDir /var/log/apache2/modsec_data
Điều cần lưu ý đó là thư mục được chỉ định trong chỉ thị nêu trên phải cho phép người dùng Apache ghi dữ liệu lên. Sau khi cấu hình thư mục lưu trữ dữ liệu, khởi tạo biến, ta có thể thao tác với giá trị của biến, gán giá trị thông qua hành động tên là setvar.
Biến tập giao tác (transaction collection)
Biến tập giao tác (TX) là một dạng biến tập giao tác, các biến này được gán giá trị trong một vòng đời của một “yêu cầu/đáp ứng”. Chúng ta có thể sử dụng TX để tạo các biến của riêng mình nhằm lưu dữ liệu trong vòng một chu kỳ giao tác. Xét một số luật sau:
SecRule REQUEST_URI “select” “pass,setvar:tx.score=+1” SecRule REQUEST_URI “passwd” “pass,setvar:tx.score=+2” SecRule TX:SCORE “@gt 3” deny
Bộ luật trên mô tả như sau, thực hiện kiểm tra các URI trong yêu cầu, nếu phát hiện có chứa “select” thì tăng biến SCORE lên 1, nếu phát hiện thấy có “passwd” thì tăng biến SCORE lên 2, và nếu kiểm tra thấy biến SCORE lớn hơn hoặc bằng 3 thì chặn yêu cầu đó lại.
Cấu trúc hành động setvar ở trên cho phép tạo và cập nhật một biến. Để hủy một biến, cũng sử dụng hành động setvar nhưng thêm dấu chấm than phía trước biến, cụ thể: setvar:!tx.score.
Biến tập TX có thể chứa các trường định nghĩa sẵn như TX:0, TX:1, ... cho đến TX:9. Với trường hợp TX:0 đó là giá trị được khớp khi sử dụng toán tử @rx hoặc @pm, các biến TX:1 đến TX:9 chứa các giá trị kiểu biểu thức chính quy thu được khi ước lượng một biểu thức chính quy kèm theo hành động capture.
2.4. Toán tử của ModSecurity
Sử dụng @ để chỉ ra đây là một toán tử SecRule ARGS "@rx dirty"
Sử dụng !@ để chỉ ra một toán tử phủ định SecRule &ARGS "!@rx ^0$"
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.
Regex là biểu thức chínhquy định các thể hiện:
Bảng 2.2: Biểu thức chính quy của ModSecurity
Biểu thức Ý nghĩa
Joy Bất kỳ chuỗi nào trong đó có j sau đó đến o và sau đó đến y, có thể là joy hoặc enjoy, v.v. nếu là Joy thì không đúng trong trường hợp này bởi Joy bắt đầu bằng chữ J in hoa.
[Jj]oy Bất kỳ chuỗi nào trong đó có j sau đó đến o và sau đó đến y, có thể là joy, enjoy, Joy, enJoy đều đúng.
[0-9] Bất kỳ số nào từ 0 đến 9
[a-zA-Z] Bất kỳ chữ cái nào từ a đến z cả chũ thường lẫn in hoa ^ Bắt đầu một chuỗi
$ Kết thúc một chuỗi
^abc$ Chuỗi chỉ bao gồm từ abc
. Ký tự bất kỳ
p.t Chuỗi dạng pot, pet, put,.v.v.
Một số biểu thức khác:
* : Hợp lệ cho bất kỳ ký tự hoặc chuỗi ký tự nào. ? : Hợp lệ cho bất kỳ 1 ký tự nào.
+ : Hợp lệ với hơn 1 ký tự.
Sử dụng biểu thức chính quy trong luật
# luật 1
SecRule REMOTE_HOST "@rx \.abc\.vn$" deny # luật 2
SecRule REMOTE_HOST "\.abc\.vn$" deny
Với ví dụ trên, nó sẽ chặn tất cả các kết nối đến trang web abc.vn Bảng 2.3: Toán tử của ModSecurity
Toán tử Ý nghĩa
@beginsWith Khớp các chuỗi bắt đầu với chuỗi chỉ định
Ví dụ: SecRule REQUEST_LINE “!@beginsWith GET”
@containts Khớp các chuỗi có chứa chuỗi chỉ định tại bất cứ vị trí nào
Ví dụ: SecRule REQUEST_LINE “@contains select”
@containsWord Khớp xâu chứa từ được chỉ định. “Từ” ở đây được hiểu là đoạn
xâu được ngăn bởi một hoặc nhiều ký tự không phải chữ,số
Ví dụ: SecRule ARGS “@containsWord from”
@endsWith Khớp xâu kết thúc bởi xâu chỉ định
Ví dụ: SecRule ARGS “@endsWith --”
@streq Khớp xâu giống hoàn toàn xâu chỉ định
Ví dụ: SecRule REMOTE_HOST “@streq victim\.com”
@within Khá giống @contains, chỉ khác là một so khớp xảy ra khi biến cần
so xuất hiện bên trong xâu được chỉ định
Ví dụ: SecRule REMOTE_USER “@within bien,quynh”
(sẽ khớp nếu remote user là bien hoặcquynh)
@pm Khớp với một trong những cụm từ đi sau nó
Ví dụ: SecRule ARGS "@pm red green blue" deny
@pmFromFile Nếu có quá nhiều chuỗi muốn đặt vào, ta có thể liệt kê các chuỗi này vào một file và dùng @pmFromFile
Bảng 2.4: Toán tử đại số của ModSecurity
Toán tử Toán tử đại số
tương đương
Ví dụ
@eq =
(bằng)
SecRule RESPONSE_STATUS “@eq 200”
@ge ≥
(lớn hơn hoặc bằng)
SecRule RESPONSE_STATUS “@ge 400”
@gt >
(lớn hơn)
SecRule RESPONSE_STATUS “@gt 399”
@le ≤
(nhỏ hơn hoặc bằng)
SecRule RESPONSE_STATUS “@le 199”
@lt < (nhỏ hơn)
SecRule RESPONSE_STATUS “@lt 200”
2.5. Hành động của ModSecurity (Actions)
Khi một yêu cầu vi phạm một luật nào đó thì ModSecurity sẽ thực thi một hành động. Khi hành động không được chỉ rõ trong luật thì sẽ sử dụng hành động trong luật mặc định. Có 3 loại hành động:
Hành động cấp 1 (Primary Actions): Hành động cấp 1 sẽ quyết định cho phép yêu cầu tiếp tục hay không. Mỗi luật chỉ có một hành động cấp 1. Có nămhành động cấp 1 là:
Bảng 2.5: Hành động cấp 1 của ModSecurity
Hành động Ý nghĩa
Deny Yêu cầu sẽ bị ngắt, ModSecurity sẽ trả về mã trạng thái 500 hoặc là mã trạng thái của bạn thiết lập trong chỉ thị trạng thái.
Pass Cho phép yêu cầu tiếp tục được xử lý ở các luật tiếp theo.
Allow
Cho phép truy cập ngay lập tức và bỏ qua các giai đoạn khác (trừ phases logging). Nếu muốn chỉ cho qua giai đoạn 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 giai đoạn sau. Chỉ cho phép truy cập tới các giai đoạn yêu cầu
allow:request, nó sẽ cho qua giai đoạn 1,2 và vẫn kiểm tra ở giai đoạn 3 trở đi.
cách gửi một gói tin TCP FIN. Hành động này rất hữu ích khi ứng phó với các cuộc tấn công từ chối dịch vụ, khi đó nó sẽ bảo vệ các nguồn tài nguyên máy chủ như là hạn chế kích thước các bảng kết đến mức tối đa có thể.
Redirect
Hành động này ngay lập tức dừng tất cả quá trình xử lý tiếp theo và gửi một chuyển hướng đáp ứng trạng thái HTTP 302 tới máy khách. Có thể là chuyển hướng một yêu cầu đến một địa chỉ url nào đó. Ví dụ: SecRule REQUEST_BASENAME "search.php" "redirect:http://www.google.com"
Cũng có thể chuyển hướng cuộc tấn công về honeypot web server. Ví dụ: SecRule IP:Attacker "1" proxy:http://10.10.10.101/
Hành động cấp 2 (Secondary Actions): Các hành động cấp 2 sẽ bổ sung cho các hành động cấp 1, một luật có thể có nhiều hành động cấp 2.
Bảng 2.6: Hành động cấp 2 của ModSecurity
Hành động Ý nghĩa
Status: n Khi một yêu cầu vi phạm một luật nào đó thì ModSecurity có thể trả về các mã trạng thái HTTP n thay vì mã trạng thái 500 mặc định. Exec Thực thi một lệnh nào đó nếu một request vi phạm
Log Ghi nhật ký những yêu cầu vi phạm luật. Nolog Không ghi nhật ký
Pause : n mod_security sẽ đợi một thời gian n mili giây rồi mới trả về kết quả.
Hành động luồng (Flow Actions)
Bảng 2.7: Hành động luồng của ModSecurity
Hành động Ý nghĩa
chain Kết nối 2 hay nhiều luật lại với nhau. skipnext:n ModSecurity sẽ bỏ qua n luật theo sau nó.
Hành động mặc định (Default Action)
Khi một luật không chỉ rõ hành động thì sẽ dùng hành động mặc định được thiết lập trong SecDefaultAction.
Ví dụ : SecDefaultAction "phase:2,deny,log,status:403"
2.6. Ghi nhật ký của ModSecurity
Nhật ký sửa lỗi (Debug Log): Sử dụng SecDebugLog chỉ thị lựa chọn tập tin để ghi lại các thông tin sửa lỗi.
SecDebugLog logs/modsec-debug.log
Bạn có thể thay đổi mức độ chi tiết các thông tin được nhật ký thông qua chỉ thị:
SecDebugLogLevel giá_trị_log
Giá trị log có thể thay đổi từ 0-9 : 0 - Không ghi
1 - Các lỗi 2 – cảnh báo 3 – thông báo
4 - Chi tiết làm thế nào để xử lý các ngoại lệ.
5 - Như trên, nhưng bao gồm cả thông tin về từng đoạn thông tin được xử lý. 9 - Ghi tất cả mọi thứ bao gồm cả thông tin gỡ lỗi rất chi tiết.