WAF không phải control “bật một lần rồi để đó”. Managed rules thay đổi, application thêm endpoint mới, custom rule tích lũy, exception mở rộng và traffic pattern dịch chuyển theo thời gian. Nếu không có maintenance, WAF có thể dần rơi vào hai trạng thái xấu: protection không còn đủ hoặc policy ngày càng dễ gây false positive.
WAF Maintenance nên được xem là configuration-drift review: so trạng thái hiện tại với mục tiêu bảo vệ đã phê duyệt, kiểm tra rule/exception còn cần thiết không, xác minh managed protection vẫn cập nhật và chứng minh critical flow vẫn hoạt động đúng sau các thay đổi của provider hoặc application.
Maintenance WAF cần kiểm tra những gì?
| Nhóm | Câu hỏi chính | Evidence nên có |
|---|---|---|
| Managed Rules | Version/rule mới có thay đổi coverage hoặc action? | Changelog, version, Security Events |
| Custom Rules | Rule còn owner, use case và scope đúng? | Rule inventory, match count, ticket |
| Exceptions | Exception còn cần và có quá rộng? | Expression, rule ID, review date |
| Rate Limiting | Threshold còn phù hợp baseline? | RPS, 429/challenge, false positive |
| Origin | Traffic có bypass edge? | Firewall log, direct-origin test |
| Functional Health | Login/API/checkout/webhook vẫn hoạt động? | Regression test, business metrics |
| Telemetry | Có đủ log để điều tra? | Retention, event fields, alert |
Không dùng một lịch cố định cho mọi website
Tần suất review nên phụ thuộc vào mức thay đổi và mức rủi ro. Website release nhiều lần mỗi tuần, API public hoặc WAF thường xuyên thay rule cần review dày hơn một site ít thay đổi. Thay vì coi “mỗi tháng” hay “mỗi quý” là chuẩn bắt buộc, hãy gắn maintenance với trigger thực tế:
- sau application release lớn;
- sau khi thêm endpoint/API/provider mới;
- sau incident hoặc false positive;
- khi managed ruleset có release/changelog quan trọng;
- trước hoặc sau campaign traffic lớn;
- khi CDN/WAF plan hoặc feature thay đổi;
- theo cadence định kỳ phù hợp risk profile.
Review drift theo từng lớp
1. Review Managed Rules và changelog
Managed Rules được provider cập nhật để tăng coverage, sửa false positive hoặc phản ứng với threat mới. Điều này có lợi nhưng cũng có nghĩa behavior có thể thay đổi dù đội của bạn không sửa config.
Cloudflare hiện công bố WAF changelog và release cycle; rule mới/được cập nhật thường có giai đoạn logging trước khi chuyển action mạnh hơn. Đây là khoảng thời gian hữu ích để review Security Events và phát hiện match bất thường trước khi enforcement.
- đang dùng managed ruleset nào;
- rule/tag nào bị disable hoặc override;
- có rule mới liên quan technology stack không;
- action có thay từ Log sang Block/Challenge;
- provider có scheduled change không;
- có event false positive mới sau release không.
2. Nếu dùng versioned managed rules, kiểm tra version lifecycle
Một số nền tảng cho phép dùng default version hoặc pin static version của managed rule group. AWS WAF hiện khuyến nghị theo dõi notification, test version mới và tránh để static version hết hạn. Version cũ có thể bị thay đổi cách xử lý khi provider kết thúc support.
- default hay static version đang dùng;
- version có sắp hết hạn không;
- đã subscribe notification/changelog chưa;
- version mới đã được test ở count/staging chưa;
- override/exclusion có còn tương thích version mới;
- rollback version có còn khả dụng không.
3. Inventory Custom Rules: mỗi rule phải có lý do tồn tại
Custom Rules dễ trở thành technical debt vì chúng phản ánh application context tại một thời điểm. Sau vài release, path, integration hoặc threat có thể đã thay đổi nhưng rule vẫn còn.
- rule name có mô tả rõ purpose;
- owner còn tồn tại;
- problem statement/ticket/incident còn truy được;
- scope hostname/path/method còn đúng;
- action còn phù hợp confidence;
- rule có match traffic gần đây không;
- có rule trùng hoặc conflict không;
- priority/order còn đúng;
- emergency rule có expiry/review date không.
Anatomy và lifecycle của custom rule được phân tích tại WAF Rule là gì?.
4. Review Exception: nơi drift nguy hiểm nhất
Exception được tạo để giải quyết false positive, nhưng nếu tồn tại vô thời hạn hoặc scope quá rộng, nó có thể tạo blind spot. Cloudflare hiện cho phép exception skip một rule, nhiều rule hoặc cả managed ruleset tùy expression và scope; vì vậy maintenance phải xác minh chính xác thứ đang bị skip.
- exception tạo vì false positive nào;
- rule/ruleset nào bị bỏ qua;
- hostname/path/method/parameter scope;
- có skip rộng hơn nhu cầu hiện tại không;
- application đã thay đổi khiến exception không còn cần;
- exception có owner và review date;
- account-level và zone-level order có tạo hiệu ứng khác dự kiến;
- attack traffic có đang lọt qua exception.
Nếu cần quy trình điều tra trước khi sửa exception, xem WAF False Positive là gì?. Một failure mode thực tế là WAF False Positive làm Checkout/API trả 403, cho thấy exception cần được thu hẹp và retest thay vì disable protection rộng.
5. Kiểm tra Rule Order và feature interoperability
Custom rules, rate limiting, DDoS protection, bot controls và managed rules có thể chạy ở phase khác nhau. Application hoặc provider thay đổi có thể khiến một rule sớm hơn kết thúc request và rule phía sau không bao giờ chạy.
- rule nào terminate request;
- skip rule nằm trước đúng ruleset cần skip;
- rate limit có bị custom allow/skip làm vô hiệu;
- challenge có ảnh hưởng API/webhook;
- account-level và zone-level policy chạy theo thứ tự nào;
- managed-rule update có làm thay flow hiện tại không.
6. Re-baseline Rate Limiting
Threshold đúng sáu tháng trước có thể không còn đúng sau khi traffic tăng, campaign thay đổi hoặc client architecture mới xuất hiện. Rate limiting cần được so với baseline hiện tại, đặc biệt ở login, search, API và endpoint tốn tài nguyên.
- normal RPS hiện tại;
- peak RPS hợp lệ;
- shared-IP/NAT pattern;
- 429/challenge rate;
- legitimate user impact;
- bot/abuse pattern mới;
- counting key còn phù hợp;
- penalty duration có quá dài/ngắn.
Với WordPress login, tham khảo WAF + Rate Limiting cho wp-login.php. Khi so rule giữa provider, dùng Cloudflare vs AWS WAF Rate Limiting để kiểm tra counting, aggregation, time window và enforcement trước khi kết luận threshold tương đương.
7. Kiểm tra False Positive và False Negative
Maintenance không chỉ xem số request bị block. Cần tìm cả hai chiều:
- False positive: legitimate request bị mitigated.
- False negative: malicious request vẫn tới origin.
Cloudflare hiện khuyến nghị dùng Security Events để điều tra false positive và origin HTTP logs để tìm false negative. Nếu attack traffic tới origin trực tiếp, đó có thể là vấn đề proxy/origin protection chứ không phải thiếu WAF signature.
8. Xác minh Origin Protection chưa bị drift
Firewall allowlist, provider IP ranges, DNS records và infrastructure thay đổi theo thời gian. Một migration hoặc subdomain mới có thể vô tình mở lại direct-origin path. Case Attacker Bypass CDN/WAF bằng Origin IP là failure mode cần dùng để kiểm tra direct-origin exposure định kỳ.
- mọi hostname public cần bảo vệ còn được proxy;
- không có DNS-only record trỏ cùng origin ngoài scope;
- 80/443 chỉ nhận edge source hợp lệ;
- provider IP ranges còn cập nhật;
- mTLS/origin authentication còn hoạt động;
- direct-origin verification vẫn bị deny;
- management ports không bị mở nhầm.
Checklist chi tiết nằm tại Origin Protection.
9. Regression test các Critical Flow
Security Events “trông bình thường” không chứng minh website còn hoạt động đúng. Sau managed-rule update, custom-rule change hoặc exception cleanup, cần test các flow quan trọng.
- login, logout, MFA, password reset;
- checkout/payment callback;
- REST/GraphQL/API;
- webhook;
- upload/import;
- admin save/update;
- search/filter;
- health check/monitoring;
- bot/crawler hợp lệ nếu business phụ thuộc.
Rollout ban đầu nên theo observe → test → enforce → verify; maintenance cũng phải giữ cùng nguyên tắc khi policy thay đổi.
10. Review telemetry, retention và alert
Nếu log không đủ chi tiết hoặc retention quá ngắn, incident xảy ra sẽ không có evidence để điều tra. Kiểm tra dashboard/log pipeline có trả lời được:
- rule ID và action;
- host/path/method;
- source IP/ASN/country nếu được phép lưu;
- matched payload hoặc field khi nền tảng hỗ trợ;
- rate-limit/challenge event;
- origin status/latency;
- timestamp/request identifier;
- retention đủ cho incident workflow.
11. Gỡ rule chết, rule trùng và exception không còn owner
Nhiều rule hơn không đồng nghĩa bảo vệ tốt hơn. Rule không còn match, rule trùng với managed protection hoặc exception không ai hiểu làm hệ thống khó audit và tăng rủi ro change.
- không match trong khoảng review hợp lý;
- use case đã được sửa ở application;
- managed provider đã có coverage tương đương;
- emergency incident đã đóng;
- path/API đã decommission;
- owner/ticket không còn;
- duplicate expression/action.
Không xóa chỉ vì rule ít match. Trước khi gỡ phải xác minh use case và có rollback/config snapshot.
12. Snapshot và version-control trước maintenance change
Mỗi đợt cleanup/tuning nên có before-state. Nếu nền tảng hỗ trợ Terraform/IaC/API export, dùng version control để review diff. Nếu chỉ dùng dashboard, tối thiểu lưu export/screenshot/config record đủ để phục hồi.
- rule expression và action;
- priority/order;
- managed ruleset/version;
- override và exception;
- rate limit threshold;
- origin allowlist;
- timestamp và người thay đổi;
- rollback procedure.
Suggested cadence theo risk, không phải chuẩn bắt buộc
| Trigger/cadence gợi ý | Review trọng tâm |
|---|---|
| Sau mỗi major release | Critical flows, custom rules, exceptions |
| Sau incident/false positive | Root cause, emergency rules, exception scope |
| Khi provider có WAF release | Managed-rule changes và Security Events |
| Định kỳ ngắn với site rủi ro cao | Top blocks, rate limits, origin exposure |
| Định kỳ dài hơn với site ít thay đổi | Full inventory, dead rules, lifecycle |
Đây là cadence tham khảo. Site có release dày, payment/API hoặc attack thường xuyên nên review sớm hơn; site tĩnh, ít thay đổi có thể giãn cadence nếu vẫn có alert tốt.
Checklist WAF Maintenance
- Managed ruleset/version còn supported?
- Đã review changelog/release gần nhất?
- Rule mới ở Log có match legitimate traffic?
- Custom rule nào không còn owner/use case?
- Emergency rule có hết hạn?
- Exception nào quá rộng hoặc không còn cần?
- Rate-limit threshold còn phù hợp baseline?
- False positive/false negative có tăng?
- Rule order/skip behavior còn đúng?
- Origin còn chặn direct traffic?
- Critical flows đã regression test?
- Telemetry/log retention đủ?
- Config đã snapshot/version-control?
- Rollback đã được kiểm tra?
Kết luận
WAF Maintenance là công việc giữ protection đúng với application hiện tại, không phải chỉ kiểm xem WAF còn “bật”. Managed rules, custom rules, exceptions, rate limits, origin policy và telemetry đều có thể drift theo thời gian.
Maintenance tốt phải trả lời được ba câu hỏi: protection nào đang hoạt động, traffic hợp lệ có bị ảnh hưởng không, và traffic malicious có đường nào bypass không. Mọi thay đổi sau review vẫn cần snapshot, test, read-back và rollback như một deployment mới.