WAF Rule là một policy dùng để nhận diện một nhóm request HTTP/HTTPS và quyết định hành động sẽ áp dụng khi request khớp điều kiện. Ở mức cơ bản, một rule có hai phần: match condition và action. Trong vận hành thực tế, một rule an toàn còn cần scope, priority/order, telemetry, exception và owner rõ ràng.
Rule tốt không phải rule “chặn được nhiều nhất”. Rule tốt là rule giải quyết một use case cụ thể, match đúng traffic cần xử lý, tác động tối thiểu tới người dùng hợp lệ và có bằng chứng để tune hoặc rollback.
Cấu trúc cơ bản của một WAF Rule
| Thành phần | Câu hỏi cần trả lời | Ví dụ |
|---|---|---|
| Match condition | Request nào thuộc scope? | host, path, method, header, IP, ASN, country, query, body |
| Action | Khi match thì làm gì? | log, allow, challenge, rate limit, block, skip |
| Scope | Rule áp dụng ở đâu? | chỉ /login, chỉ api.example.com |
| Order/Priority | Rule chạy trước hay sau rule nào? | exception trước managed rule cần skip |
| Telemetry | Làm sao biết rule đang hoạt động đúng? | event, rule ID, match count, response, path |
| Owner | Ai duyệt/tune/rollback? | security hoặc application owner |
| Review date | Khi nào kiểm tra lại? | sau release, sau incident, định kỳ |
Cloudflare mô tả custom rule bằng expression và action, đồng thời lưu ý custom rules được đánh giá theo thứ tự và một số action như Block có thể kết thúc xử lý khiến rule sau không chạy. Đây là lý do rule order phải được xem là một phần của logic, không phải chỉ là cách sắp xếp giao diện.
Thiết kế rule an toàn
Bắt đầu từ use case, không bắt đầu từ expression
Trước khi viết rule, hãy mô tả vấn đề bằng một câu có thể kiểm chứng. Ví dụ:
- “Chỉ webhook provider được phép gọi endpoint /payment/callback.”
- “Request tới /wp-login.php tăng bất thường và cần rate limit.”
- “Một exploit CVE cụ thể đang nhắm vào path X trong lúc chờ patch.”
- “Admin endpoint chỉ nên được truy cập từ VPN.”
- “Bot không xác minh đang scrape search endpoint quá nhanh.”
Nếu không thể mô tả use case rõ ràng, rule thường dễ trở thành policy rộng, khó test và khó biết khi nào nên gỡ.
Nguyên tắc 1: Scope càng hẹp càng dễ kiểm soát
Một rule sitewide dựa trên một tín hiệu yếu có thể tạo false positive lớn. Khi có thể, hãy kết hợp nhiều thuộc tính để giảm phạm vi: hostname + path + method + source hoặc tín hiệu attack score. Scope hẹp cũng giúp rollback và điều tra nhanh hơn.
Ví dụ, thay vì “skip rule SQLi trên toàn site”, cách an toàn hơn có thể là chỉ loại một parameter cụ thể trên một path đã xác minh là rich-text editor. OWASP Core Rule Set cũng khuyến nghị exclusion càng cụ thể càng tốt thay vì global rule removal.
Nguyên tắc 2: Chọn action theo độ tin cậy của tín hiệu
| Độ tin cậy | Action nên cân nhắc | Khi nào |
|---|---|---|
| Chưa biết | Log/Count | rule mới, chưa có baseline |
| Trung bình | Challenge hoặc rate limit | bot/abuse có khả năng lẫn user thật |
| Cao | Block | request chắc chắn vi phạm policy hoặc IOC rõ |
| Exception hợp lệ | Skip/Allow có scope | machine traffic hoặc flow đã xác minh |
Không có mapping action tuyệt đối cho mọi nền tảng. Mục tiêu là làm cho mức tác động tương xứng với confidence. Rule mới nên được quan sát trước enforcement nếu hệ thống hỗ trợ.
Nguyên tắc 3: Hiểu thứ tự thực thi
Rule đúng về expression vẫn có thể không chạy nếu request đã bị action khác xử lý trước đó. Trên Cloudflare hiện tại, security features chạy theo các phase như HTTP DDoS protection, custom rules, rate limiting rồi managed rules. Bên trong custom rules, thứ tự rule cũng ảnh hưởng kết quả.
Exception/skip rule đặt sai thứ tự có thể không có tác dụng. Tương tự, một Block rule quá sớm có thể che mất telemetry hoặc logic của rule phía sau. Khi debug, cần kiểm tra toàn bộ request processing path thay vì chỉ nhìn expression.
Nguyên tắc 4: Rule phải quan sát được
Mỗi rule production nên tạo đủ dữ liệu để trả lời:
- rule match bao nhiêu request;
- top hostname/path/method là gì;
- source nào bị tác động;
- action thực tế là log, challenge hay block;
- request hợp lệ có bị ảnh hưởng không;
- origin có còn nhận traffic mà rule định chặn;
- match tăng sau release hay incident nào;
- rule có còn cần thiết không.
Rule không có telemetry gần như không thể tune an toàn, vì không có evidence để phân biệt “không có attack” với “rule không match”.
Nguyên tắc 5: Test legitimate traffic và malicious case
Testing chỉ với payload tấn công là chưa đủ. Một rule cần hai phía:
- Positive security test: request hợp lệ quan trọng vẫn hoạt động.
- Negative/security test: request mà rule định chặn thực sự bị xử lý như kỳ vọng.
Với login, cần test browser thật, password sai/đúng, MFA và reset password. Với API, cần test các method và JSON schema hợp lệ. Với checkout, phải đi tới callback/payment success thay vì chỉ load trang checkout. Quy trình kiểm thử và rollout trước enforcement được mô tả tại Cách triển khai WAF cho website mà không làm lỗi chức năng.
Lifecycle, tuning và ownership
Một WAF Rule nên có metadata gì?
- Name: mô tả purpose, không dùng tên mơ hồ như “block bad traffic”.
- Owner: team hoặc người chịu trách nhiệm.
- Reason: incident, CVE, abuse pattern hay policy nào tạo ra rule.
- Scope: host/path/method/source.
- Action: log/challenge/block/skip.
- Created/changed date: phục vụ audit và review.
- Rollback: previous action hoặc cách disable.
- Expiry/review: đặc biệt quan trọng với virtual patch hoặc emergency rule.
Cách tune rule khi có false positive
- Xác định request hợp lệ cụ thể bị ảnh hưởng.
- Ghi rule ID, path, method, parameter/body và action.
- Xác minh đó thực sự là legitimate behavior.
- Tìm scope nhỏ nhất có thể loại trừ.
- Giữ phần protection còn lại thay vì tắt toàn rule/ruleset.
- Test lại request hợp lệ.
- Test lại malicious case để tránh tạo bypass.
- Đặt review date cho exception.
CRS documentation đưa ra cùng nguyên tắc: ưu tiên exclusion theo path/parameter thay vì remove rule toàn cục. Phần điều tra chuyên sâu được tách sang WAF False Positive là gì?. Một failure mode cụ thể là WAF False Positive làm Checkout/API trả 403, cho thấy vì sao cần khoanh đúng rule và exception thay vì tắt rộng.
Custom rule và Managed rule khác vai trò
Managed rule được nhà cung cấp duy trì để bao phủ attack pattern phổ biến; custom rule thể hiện context riêng của ứng dụng. Đừng copy toàn bộ logic managed rule sang custom rule nếu không có lý do. Custom rule nên lấp khoảng trống cụ thể như access policy cho admin, webhook source, endpoint abuse hoặc virtual patch tạm thời.
Chiến lược lựa chọn được phân tích riêng tại Managed Rules và Custom Rules: nên dùng loại nào?
Emergency rule và virtual patch cần ngày hết hạn
Trong incident, một rule có thể được tạo nhanh để chặn exploit cụ thể. Sau khi ứng dụng được vá, rule emergency có thể trở thành technical debt hoặc gây false positive về sau. Vì vậy rule tạm thời nên có owner, lý do, ticket/incident reference và review/expiry date.
Áp dụng rule theo context
Rule cho IP/Country có rủi ro gì?
IP hoặc country có thể là một tín hiệu nhưng hiếm khi nên được coi là bằng chứng tuyệt đối về malicious intent. Shared infrastructure, mobile carrier, VPN, NAT, proxy và cloud hosting khiến nguồn traffic thay đổi. Nếu block theo geography/IP, cần gắn với business requirement hoặc evidence, đồng thời có cách xử lý user hợp lệ bị tác động.
Rule cho login nên khác rule cho API
Browser flow có thể chịu challenge; webhook hoặc API machine-to-machine thường không thể giải challenge tương tác. Vì vậy cùng một tín hiệu abuse nhưng action phải phù hợp client type. Đừng áp sitewide challenge cho cả API và payment callback chỉ vì login đang bị brute force.
WordPress login là một use case riêng; xem Cách dùng WAF và Rate Limiting để bảo vệ wp-login.php.
Change-control và review
Anti-pattern khi xây WAF Rule
- block sitewide chỉ dựa trên user-agent dễ giả mạo;
- allowlist cả IP range quá rộng để “sửa” false positive;
- tắt toàn managed ruleset vì một rule lỗi;
- viết nhiều rule trùng mục tiêu nhưng không biết order;
- rule không có owner hoặc comment;
- rule emergency tồn tại vĩnh viễn sau khi patch;
- thay action trực tiếp từ log sang block mà không review match;
- không test API/webhook vì chỉ kiểm tra browser;
- không read-back sau deploy.
Quy trình change-control cho một rule mới
- Viết problem statement và success criteria.
- Xác định scope tối thiểu.
- Snapshot cấu hình hiện tại.
- Tạo rule với action quan sát nếu có thể.
- Review match trên traffic thật.
- Test critical flows và attack case.
- Chuyển enforcement theo scope nhỏ.
- Read-back telemetry và chức năng.
- Rollback nếu impact vượt ngưỡng đã định.
- Đặt owner và review date.
Quy trình rollout đầy đủ nằm ở Cách triển khai WAF cho website mà không làm lỗi chức năng.
Checklist review một WAF Rule
- Rule giải quyết vấn đề nào?
- Scope có thể hẹp hơn không?
- Tín hiệu có đủ tin cậy cho action hiện tại không?
- Rule chạy ở phase/order nào?
- Có xung đột với rate limit/managed rule/exception không?
- Critical flow đã được test chưa?
- Có log/event để theo dõi không?
- Exception có tạo bypass không?
- Ai là owner?
- Khi nào review/gỡ rule?
Kết luận
WAF Rule là đơn vị policy biến tín hiệu của request thành action. Chất lượng rule phụ thuộc vào scope, confidence, order, testing và telemetry chứ không chỉ expression. Hãy bắt đầu từ use case cụ thể, quan sát trước khi block, tune bằng exception hẹp và luôn giữ rollback.
Khi rule count bắt đầu tăng, chuyển trọng tâm từ “tạo rule mới” sang quản trị lifecycle: owner, duplication, exception, expiry và maintenance định kỳ. Đó là cách tránh WAF trở thành một lớp policy khó hiểu và khó thay đổi.