Cách triển khai WAF an toàn, không làm lỗi website

Triển khai WAF an toàn không bắt đầu bằng việc bật càng nhiều rule càng tốt. Mục tiêu đầu tiên là đưa WAF vào đúng traffic path, quan sát được request thật, kiểm thử các luồng quan trọng và có rollback rõ ràng trước khi chuyển từ log/count sang challenge hoặc block.

Rủi ro lớn nhất khi rollout không kiểm soát là false positive: login, checkout, API, webhook, upload hoặc trang quản trị có thể bị chặn dù request hoàn toàn hợp lệ. AWS hiện khuyến nghị test và tune WAF ở môi trường thử nghiệm trước, sau đó tiếp tục dùng count mode trên production traffic trước khi enforcement. Cloudflare cũng khuyến nghị review Security Events và chỉ điều chỉnh đúng rule/scope gây false positive thay vì tắt cả ruleset.

Nguyên tắc triển khai: observe → test → enforce → verify

Observe: hiểu traffic bình thường và critical flow.
Test: bật rule ở staging hoặc log/count mode để xem match.
Enforce: chuyển từng nhóm rule sang challenge/block với scope nhỏ.
Verify: test lại chức năng, kiểm tra telemetry và origin.
Maintain: review false positive, exception và rule change theo thời gian.

Chuẩn bị trước rollout

Bước 1: Lập inventory trước khi bật WAF

Trước khi tạo rule, hãy liệt kê những hostname, route và workflow mà WAF sẽ nhìn thấy. Nếu không biết ứng dụng có những flow nào, bạn cũng không biết một event WAF là attack hay request hợp lệ.

website chính và subdomain;
login, register, reset password, admin;
checkout, cart, coupon, payment callback;
REST/GraphQL/API endpoints;
webhook và machine-to-machine traffic;
upload file, import/export;
search và endpoint có query phức tạp;
health check, uptime monitor và crawler hợp lệ;
các endpoint không được cache và tốn tài nguyên.

Nếu chưa chắc website có thực sự cần WAF, quay lại framework đánh giá nhu cầu WAF trước khi triển khai.

Bước 2: Xác định đường đi của request và origin

Internet
  ↓
DNS / CDN / Reverse Proxy
  ↓
WAF
  ↓
Load Balancer / Web Server
  ↓
Application / API
  ↓
Database

WAF chỉ bảo vệ traffic thực sự đi qua nó. Nếu DNS trỏ qua CDN/WAF nhưng origin IP vẫn nhận request trực tiếp từ Internet, attacker có thể bypass edge. Vì vậy rollout WAF cần một workstream riêng cho origin protection: firewall/security group, proxy source ranges, origin authentication hoặc control tương đương tùy kiến trúc. Case attacker bypass CDN/WAF bằng Origin IP cho thấy vì sao kiểm direct-origin access phải nằm trong validation sau rollout.

Bước 3: Chụp baseline trước thay đổi

Trước khi bật enforcement, lưu baseline đủ để so sánh sau thay đổi:

RPS và traffic theo hostname/path;
tỷ lệ 2xx, 3xx, 4xx, 5xx;
latency p50/p95 hoặc metric tương đương;
login success/failure rate;
checkout conversion hoặc transaction success;
API error rate;
webhook/payment callback success;
upload success và file-size distribution;
cache hit/miss nếu có CDN;
origin CPU, worker, connection và database load.

Không cần một threshold cố định cho mọi website. Baseline phải phản ánh traffic thật của ứng dụng và giờ cao điểm của chính bạn.

Bước 4: Bật managed protection theo stack, không bật mọi rule

Managed rules là điểm khởi đầu thực tế vì nhà cung cấp duy trì coverage cho nhiều attack pattern và CVE. Nhưng “enable all” không phải mặc định tốt. Cloudflare hiện khuyến nghị bật rule/tag phù hợp với technology stack và cảnh báo rằng bật toàn bộ rule bằng override có thể ảnh hưởng legitimate traffic.

Hãy bắt đầu với rule set mặc định hoặc nhóm rule có liên quan tới stack thật: WordPress, PHP, framework, API type… Sau đó dùng telemetry để quyết định có cần mở rộng coverage hay không. Phân biệt sâu hơn tại Managed Rules vs Custom Rules.

Quan sát và kiểm thử trước enforcement

Bước 5: Dùng log/count mode trước enforcement

Trong giai đoạn quan sát, mục tiêu là biết rule nào match traffic thật mà chưa làm thay đổi response. Tên mode khác nhau theo nhà cung cấp: log, count, simulate hoặc override action. Ý nghĩa chung là ghi nhận match trước khi chặn.

Review ít nhất theo các chiều: rule ID, hostname, path, method, source, user-agent, response code, frequency và thời điểm. Một rule có nhiều match không tự động có nghĩa là rule tốt; phải xác minh request match là malicious hay legitimate.

Bước 6: Test các critical flow có chủ đích

Flow	Test tối thiểu	Failure thường gặp
Login	đúng/sai password, MFA, reset password	challenge loop, rate limit quá chặt
Checkout	cart → checkout → payment → success	body/query bị rule match
Payment callback	webhook từ provider	challenge hoặc IP policy chặn machine traffic
REST/API	GET/POST/PUT theo schema thật	JSON body bị false positive
Upload	file hợp lệ nhiều kích thước/type	binary content kích hoạt rule
Admin	save post/settings/plugin workflow	payload quản trị bị xem là code injection
Search	query có ký tự đặc biệt hợp lệ	SQLi/XSS rule chặn nhầm

Cloudflare lưu ý upload binary và một số payload quản trị có thể tạo false positive trong managed rules. Vì vậy test chức năng không thể chỉ dùng homepage và một request GET đơn giản.

Enforce, verify và rollback

Bước 7: Chuyển enforcement theo scope nhỏ

Khi telemetry đã đủ tin cậy, chuyển từng rule hoặc nhóm rule từ log/count sang action mạnh hơn. Ưu tiên những match có confidence cao và scope rõ. Không nên thay đổi nhiều lớp cùng lúc vì khi xảy ra lỗi sẽ khó xác định control nào gây ra.

một hostname trước toàn account;
một nhóm rule trước toàn ruleset;
challenge trước block nếu phù hợp user flow;
một endpoint nhạy cảm trước sitewide policy;
rollout vào thời điểm có người theo dõi;
ghi lại ai thay đổi, rule nào, action nào và lý do.

Bước 8: Xử lý false positive bằng exception hẹp

Khi request hợp lệ bị chặn, đừng vội tắt cả WAF hoặc allowlist toàn IP/site. Trước tiên xác định chính xác rule ID, hostname, path, parameter/body và loại traffic bị ảnh hưởng. Sau đó tạo exception nhỏ nhất đủ để flow hoạt động và kiểm thử lại attack case.

Cloudflare hiện khuyến nghị nếu chỉ một managed rule gây false positive thì xử lý đúng rule đó thay vì disable toàn ruleset. Quy trình chi tiết nằm ở WAF False Positive là gì?; case WAF False Positive làm Checkout/API trả 403 minh họa cách khoanh đúng rule và tạo scoped exclusion mà không tắt WAF.

Bước 9: Read-back sau mỗi thay đổi

rule/action thực tế có đúng với change plan không;
Security Events có match như kỳ vọng không;
critical flows còn hoạt động;
4xx/5xx và latency có tăng;
origin load có giảm hay tăng;
request malicious có còn tới origin;
exception có rộng hơn dự kiến không;
traffic có bypass WAF không.

API trả thành công hoặc dashboard báo rule “enabled” chưa đủ để kết luận deployment thành công. Thành công phải được xác minh bằng traffic và chức năng thực tế.

Rollback plan nên chuẩn bị trước khi block

Mỗi thay đổi WAF production nên có cách quay lại trạng thái trước đó. Tối thiểu cần biết:

rule/ruleset nào vừa đổi;
previous action/scope là gì;
cách disable hoặc revert nhanh;
ai có quyền rollback;
metric nào kích hoạt rollback;
cách xác minh dịch vụ phục hồi sau rollback.

Nếu dùng IaC/API, version-control cấu hình giúp review và rollback dễ hơn. Nếu dùng dashboard, ít nhất phải export/snapshot rule hoặc lưu change record trước khi sửa.

Không quên thứ tự thực thi giữa các security feature

Trên nhiều nền tảng, custom rules, rate limiting, DDoS protection và managed rules chạy ở các phase khác nhau. Một action kết thúc request ở phase sớm có thể khiến rule phía sau không bao giờ được đánh giá. Cloudflare hiện công bố execution order riêng cho các security phase. Khi debug, cần biết request bị xử lý ở lớp nào trước.

Đây cũng là lý do không nên nhìn một rule riêng lẻ mà bỏ qua toàn bộ request path. Phần thiết kế expression, action, priority và exception được tách riêng tại WAF Rule là gì?.

Checklist trước khi chuyển từ Log sang Block

Đã inventory critical flows?
Đã có baseline traffic/error/latency?
Đã xác nhận origin không bypass?
Đã chạy rule ở log/count mode?
Đã review top matches và false positives?
Đã test login, checkout, API, webhook và upload?
Exception có scope tối thiểu?
Rollback có người chịu trách nhiệm?
Monitoring có đủ để thấy lỗi ngay sau change?
Change có được ghi lại và có thời điểm review lại?

Sau rollout: WAF vẫn cần maintenance

Ứng dụng thay đổi, managed rules được cập nhật và traffic pattern cũng thay đổi. Cloudflare hiện có changelog/release cycle cho managed rules; những thay đổi mới có thể được đưa vào logging trước enforcement. Vì vậy đội vận hành cần review định kỳ thay vì coi WAF là cấu hình “một lần rồi xong”.

Owner cho công việc định kỳ là WAF Maintenance Checklist. Trước khi chuyển enforcement, dùng checklist ngay trong mục “Checklist trước khi chuyển từ Log sang Block” của bài này để xác minh critical flow, exception, monitoring và rollback.

Kết luận

Triển khai WAF không làm lỗi website phụ thuộc nhiều hơn vào change-control và testing hơn là số lượng rule. Hãy inventory application, chụp baseline, bật log/count trước, test critical flow, enforce từng scope nhỏ, read-back telemetry và luôn có rollback.

Một WAF an toàn là WAF mà đội vận hành biết rule nào đang chạy, vì sao nó tồn tại, request nào bị tác động và cách phục hồi dịch vụ nếu policy sai.

Nguồn tham khảo

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem WAF & DDoS Protection.