Cloudflare WAF là gì? Cách bảo vệ website khỏi các request độc hại
Bùi Tấn Lực - 109
- 06/09/2026
Khi website bắt đầu có lượng truy cập lớn, vấn đề bảo mật không còn nằm ở việc đặt một mật khẩu quản trị đủ mạnh hay cài thêm một plugin bảo mật. Mọi request gửi đến website đều có thể trở thành điểm bắt đầu cho một hành vi bất thường: dò đường dẫn quản trị, quét lỗ hổng, thử payload SQL Injection, chèn mã JavaScript, gửi hàng loạt request hoặc tìm cách làm máy chủ phải xử lý quá nhiều tác vụ.
Đây là lý do Cloudflare WAF được sử dụng phổ biến trong hệ thống bảo vệ website. WAF có nhiệm vụ đứng trước máy chủ, phân tích request trước khi request đó được chuyển tiếp đến website và áp dụng các quy tắc để cho phép, thử thách hoặc chặn những yêu cầu có dấu hiệu nguy hiểm.
Điểm quan trọng là WAF không đơn thuần là một danh sách IP bị chặn. Một hệ thống WAF hiệu quả cần xem xét nhiều yếu tố của request như URL, phương thức HTTP, tham số, header, nguồn truy cập, tần suất gửi request và các mẫu dữ liệu thường xuất hiện trong những cuộc tấn công web.
Cloudflare WAF hoạt động như thế nào?
WAF là viết tắt của Web Application Firewall, có thể hiểu là tường lửa dành cho ứng dụng web. Nếu firewall truyền thống thường tập trung vào việc kiểm soát kết nối mạng, port hoặc địa chỉ IP thì WAF đi sâu hơn vào lớp HTTP/HTTPS, nơi các request tương tác trực tiếp với ứng dụng.
Trong mô hình sử dụng Cloudflare, DNS của tên miền được cấu hình để lưu lượng web đi qua hệ thống Cloudflare trước khi tới máy chủ gốc. Khi người dùng truy cập website, request sẽ được Cloudflare tiếp nhận và xử lý theo các lớp bảo vệ đã được cấu hình.
- Người dùng gửi request tới tên miền.
- Cloudflare tiếp nhận request tại mạng lưới của mình.
- Các lớp bảo mật phân tích request dựa trên những tín hiệu và quy tắc phù hợp.
- Request hợp lệ được chuyển tiếp về máy chủ gốc.
- Request vi phạm chính sách có thể bị chặn hoặc yêu cầu xác minh trước khi tiếp tục.
Nhờ vị trí nằm trước máy chủ, Cloudflare WAF có thể loại bỏ nhiều request không mong muốn trước khi chúng tiêu tốn tài nguyên của hosting hoặc server. Đây là điểm rất quan trọng đối với website PHP, WordPress, website bán hàng hoặc các hệ thống có tài nguyên máy chủ hạn chế.
Ví dụ, nếu một bot liên tục gửi request tới các URL không tồn tại với mục đích dò tìm lỗ hổng, việc để toàn bộ request đi thẳng vào PHP rồi mới xử lý sẽ tạo thêm tải cho web server. Nếu request có thể được nhận diện và chặn ngay tại lớp Cloudflare, máy chủ gốc sẽ không phải xử lý phần lớn lượng truy cập đó.
WAF khác gì với việc chặn IP?
Chặn IP là một biện pháp đơn giản: xác định một địa chỉ hoặc nhóm địa chỉ đáng ngờ rồi không cho truy cập. Cách này hữu ích trong nhiều trường hợp nhưng không đủ để bảo vệ một website hiện đại.
Kẻ tấn công có thể thay đổi IP, sử dụng nhiều nguồn truy cập khác nhau hoặc gửi request có cấu trúc bất thường từ những IP chưa từng bị chặn. Vì vậy, WAF cần phân tích cả nội dung và đặc điểm của request, thay vì chỉ dựa vào địa chỉ IP.
Chẳng hạn, một request tới trang sản phẩm bình thường có thể chứa tham số tìm kiếm hợp lệ. Trong khi đó, một request khác tới cùng URL có thể chứa chuỗi dữ liệu bất thường nhằm khai thác câu truy vấn hoặc chèn JavaScript. Hai request có thể đến từ hai IP hoàn toàn khác nhau nhưng hành vi của request thứ hai vẫn có thể là dấu hiệu cần kiểm tra.
Những loại request độc hại WAF có thể giúp ngăn chặn
Không phải mọi request bất thường đều đồng nghĩa với một cuộc tấn công thành công. Tuy nhiên, WAF giúp giảm đáng kể lượng request có đặc điểm giống các kỹ thuật tấn công phổ biến trước khi chúng tiếp cận ứng dụng.
SQL Injection
SQL Injection xảy ra khi dữ liệu do người dùng kiểm soát bị đưa vào câu truy vấn cơ sở dữ liệu mà không được xử lý an toàn. Kẻ tấn công có thể lợi dụng điểm yếu này để thay đổi logic truy vấn, truy xuất dữ liệu trái phép hoặc thực hiện những thao tác mà ứng dụng không cho phép.
WAF có thể phát hiện nhiều mẫu request mang đặc điểm của SQL Injection dựa trên các rule bảo mật. Tuy nhiên, WAF không nên được xem là cách duy nhất để xử lý SQL Injection. Ứng dụng vẫn phải sử dụng prepared statement, parameterized query và kiểm soát dữ liệu đầu vào đúng cách.
Nói cách khác, WAF tạo thêm một lớp phòng thủ bên ngoài, còn lập trình an toàn mới là lớp bảo vệ cốt lõi bên trong ứng dụng.
Cross-Site Scripting
Cross-Site Scripting, thường được gọi là XSS, liên quan đến việc đưa mã JavaScript hoặc nội dung có khả năng thực thi vào những vị trí mà ứng dụng dự kiến chỉ nhận dữ liệu thông thường.
Một request chứa các chuỗi đặc biệt liên quan đến script, event handler hoặc HTML bất thường có thể là dấu hiệu cần được kiểm tra. WAF có thể sử dụng các rule để phát hiện nhiều mẫu XSS phổ biến và ngăn request tiếp tục tới ứng dụng.
Tương tự SQL Injection, không nên phụ thuộc hoàn toàn vào WAF. Website vẫn cần escape output, validate input và triển khai các cơ chế bảo vệ phù hợp với ngữ cảnh hiển thị dữ liệu.
Request dò quét và tìm đường dẫn nhạy cảm
Một website thường xuyên bị bot tự động quét các đường dẫn như khu vực quản trị, file cấu hình, thư mục backup, endpoint cũ hoặc những URL thường xuất hiện trong các phần mềm có lỗ hổng.
Không phải mọi request tới một URL nhạy cảm đều là tấn công. Quản trị viên hoặc công cụ giám sát hoàn toàn có thể truy cập những đường dẫn này trong quá trình vận hành. Vì vậy, thay vì chặn cứng tất cả, nên kết hợp nhiều điều kiện để xác định request thực sự bất thường.
Bot gửi request với tần suất cao
Một bot có thể gửi hàng trăm hoặc hàng nghìn request trong thời gian ngắn để dò dữ liệu, thử mật khẩu, tìm sản phẩm hoặc gây áp lực lên server.
Trong trường hợp này, vấn đề không nhất thiết nằm ở nội dung của từng request. Một request riêng lẻ có thể hoàn toàn hợp lệ, nhưng tần suất và hành vi lặp lại mới là dấu hiệu đáng chú ý.
Đây là lý do bảo vệ website thường cần kết hợp WAF với rate limiting và các cơ chế kiểm soát bot thay vì chỉ sử dụng một nhóm rule phát hiện payload độc hại.
Cloudflare WAF có thể bảo vệ website ở những lớp nào?
Một cấu hình WAF tốt không nên được xây dựng theo tư duy “thấy gì lạ thì chặn”. Website cần xác định rõ loại lưu lượng nào được phép, loại nào cần kiểm tra và loại nào có thể loại bỏ ngay.
| Lớp kiểm soát | Mục đích |
|---|---|
| IP và mạng | Kiểm soát các nguồn truy cập có dấu hiệu nguy hiểm hoặc không được phép. |
| URL và path | Bảo vệ các khu vực nhạy cảm như trang quản trị hoặc endpoint đặc biệt. |
| HTTP method | Kiểm soát GET, POST và các phương thức không cần thiết đối với website. |
| Query và body | Phát hiện dữ liệu có dấu hiệu chứa payload tấn công. |
| Header | Đánh giá thêm thông tin do client gửi trong request. |
| Tần suất | Phát hiện nguồn gửi quá nhiều request trong một khoảng thời gian ngắn. |
| Bot behavior | Phân biệt những hành vi truy cập tự động đáng ngờ với lưu lượng thông thường. |
Các lớp này không nhất thiết phải được triển khai cùng một lúc. Với website nhỏ, việc bắt đầu từ những khu vực có rủi ro cao thường hiệu quả hơn việc tạo hàng chục rule phức tạp ngay từ đầu.
Managed Rules và Custom Rules khác nhau thế nào?
Đây là hai khái niệm quan trọng khi bắt đầu cấu hình Cloudflare WAF.
Managed Rules là các bộ quy tắc được xây dựng sẵn nhằm phát hiện những nhóm hành vi hoặc mẫu tấn công phổ biến. Ưu điểm của cách này là quản trị viên không phải tự xây dựng toàn bộ logic phát hiện từ đầu.
Custom Rules cho phép người quản trị tự xác định điều kiện và hành động dựa trên nhu cầu thực tế của website. Đây là phần đặc biệt hữu ích khi website có những khu vực riêng cần bảo vệ.
Ví dụ, một website có đường dẫn quản trị riêng có thể tạo rule yêu cầu xác minh hoặc chặn những request không đáp ứng điều kiện nhất định. Một website có API lại có thể cần các điều kiện hoàn toàn khác so với website chỉ có các trang nội dung.
Điểm quan trọng không phải là tạo càng nhiều rule càng tốt. Một hệ thống WAF tốt là hệ thống có rule rõ mục đích, điều kiện dễ kiểm tra và hành động phù hợp với mức độ rủi ro.
Khi nào nên dùng Managed Rules?
Managed Rules phù hợp khi website cần một lớp bảo vệ nền tảng trước những nhóm tấn công phổ biến mà không muốn tự xây dựng từng mẫu phát hiện.
Đặc biệt với người mới triển khai Cloudflare, đây thường là điểm khởi đầu hợp lý. Sau khi theo dõi log và hiểu lưu lượng thực tế của website, quản trị viên có thể bổ sung Custom Rules cho những tình huống đặc thù.
Khi nào nên tạo Custom Rules?
Custom Rules phát huy hiệu quả khi website có yêu cầu bảo mật cụ thể mà rule chung không thể mô tả chính xác.
Ví dụ, bạn muốn kiểm soát một đường dẫn nhất định, chỉ cho phép một số phương thức HTTP, áp dụng chính sách riêng cho API hoặc xử lý một nhóm request có đặc điểm đặc biệt. Khi đó, Custom Rules cho phép biến yêu cầu bảo mật của website thành điều kiện cụ thể.
Tuy nhiên, rule càng phức tạp thì nguy cơ cấu hình sai càng cao. Một điều kiện viết quá rộng có thể chặn nhầm khách hàng thật, trong khi điều kiện quá hẹp lại bỏ lọt lưu lượng đáng ngờ.
Vì sao không nên bật chế độ chặn mọi request đáng ngờ?
Đây là một trong những sai lầm phổ biến khi cấu hình WAF. Người quản trị thường nghĩ rằng nếu website bị tấn công thì chỉ cần tăng mức độ chặn lên cao nhất là an toàn. Trên thực tế, cách làm này có thể khiến website tự chặn chính khách hàng của mình.
Request hợp lệ đôi khi có cấu trúc rất giống những mẫu mà hệ thống bảo mật đánh giá là đáng ngờ. Website bán hàng, hệ thống tìm kiếm, form đăng nhập, API hoặc các ứng dụng sử dụng nhiều tham số động càng dễ gặp tình huống này.
Ví dụ, một tham số tìm kiếm có thể chứa ký tự đặc biệt hoàn toàn hợp lệ đối với chức năng của website. Nếu một rule được viết quá rộng để tìm các ký tự đó và lập tức chặn request, người dùng thật có thể gặp lỗi dù họ không thực hiện hành vi nguy hiểm.
Do đó, khi xây dựng WAF nên ưu tiên quy trình:
- Xác định loại request cần kiểm soát.
- Viết điều kiện càng cụ thể càng tốt.
- Quan sát request thực tế trong log.
- Kiểm tra khả năng xảy ra false positive.
- Chỉ chuyển sang hành động chặn khi đã có đủ cơ sở.
Với những rule mới và chưa chắc chắn, hành động có mức độ can thiệp thấp hơn có thể phù hợp để kiểm tra trước. Sau khi xác nhận rule hoạt động đúng, mới áp dụng chính sách nghiêm ngặt hơn.
WAF có thay thế hoàn toàn bảo mật trên máy chủ không?
Không. WAF chỉ là một lớp trong kiến trúc bảo mật tổng thể.
Nếu website tồn tại lỗ hổng trong mã nguồn, tài khoản quản trị sử dụng mật khẩu yếu, phần mềm lỗi thời hoặc máy chủ được cấu hình không an toàn thì việc bật WAF không thể biến hệ thống thành tuyệt đối an toàn.
Một website nên được bảo vệ theo nhiều lớp. Ở phía ứng dụng cần kiểm tra dữ liệu đầu vào, xử lý session an toàn, phân quyền đúng và truy vấn cơ sở dữ liệu an toàn. Ở máy chủ cần cập nhật hệ điều hành, web server, PHP và các thành phần liên quan. Ở lớp mạng có thể sử dụng firewall, giới hạn dịch vụ và các chính sách truy cập phù hợp. Cloudflare WAF bổ sung thêm một lớp kiểm soát request ở phía trước.
WAF nên được xem là lớp phòng thủ bổ sung, không phải lý do để bỏ qua việc sửa lỗ hổng trong mã nguồn và cấu hình máy chủ.
Đối với website được xây dựng bằng PHP, nguyên tắc này càng quan trọng. Một request bị WAF chặn sẽ giúp giảm rủi ro, nhưng nếu người dùng hợp lệ vẫn có thể gửi dữ liệu độc hại tới một endpoint mà ứng dụng xử lý không an toàn thì vấn đề gốc vẫn tồn tại.
Vì vậy, mục tiêu của Cloudflare WAF không phải là làm cho website “không thể bị tấn công”, mà là giảm bề mặt tấn công, loại bỏ nhiều request nguy hiểm từ sớm và giảm áp lực lên hệ thống phía sau.
Cách xây dựng quy tắc WAF phù hợp cho từng website
Không có một bộ quy tắc WAF duy nhất phù hợp với mọi website. Website giới thiệu doanh nghiệp, website bán hàng, hệ thống đặt hàng, API hay website quản trị nội bộ đều có đặc điểm request khác nhau. Vì vậy, cách cấu hình hiệu quả nhất là bắt đầu từ kiến trúc và hành vi thực tế của website.
Trước khi tạo rule, nên xác định những khu vực có giá trị hoặc có khả năng bị lạm dụng cao. Thông thường đó là trang đăng nhập, trang quản trị, form gửi dữ liệu, chức năng tìm kiếm, API, các endpoint xử lý POST và những URL có khả năng tiêu tốn nhiều tài nguyên.
Sau khi xác định được các khu vực này, hãy đặt câu hỏi: request hợp lệ trông như thế nào và request bất thường khác nó ở điểm nào? Cách suy nghĩ này giúp tạo rule chính xác hơn rất nhiều so với việc tìm một chuỗi ký tự rồi chặn toàn bộ.
Bảo vệ khu vực quản trị
Trang quản trị thường là một trong những mục tiêu đầu tiên của bot tự động. Việc một bot liên tục truy cập trang đăng nhập không nhất thiết có nghĩa nó đã khai thác được lỗ hổng, nhưng hành vi này có thể là bước chuẩn bị cho việc dò mật khẩu hoặc tìm cách vượt qua cơ chế xác thực.
Với khu vực quản trị, có thể xây dựng chính sách riêng thay vì áp dụng cùng một mức bảo vệ với toàn bộ website. Tùy mô hình vận hành, quản trị viên có thể giới hạn nguồn truy cập, yêu cầu xác minh bổ sung hoặc áp dụng giới hạn tần suất đối với endpoint đăng nhập.
Nếu website chỉ có một nhóm quản trị viên cố định, việc giới hạn truy cập vào khu vực quản trị theo IP hoặc một lớp xác thực bổ sung có thể mang lại hiệu quả cao. Ngược lại, nếu quản trị viên thường xuyên làm việc từ nhiều mạng khác nhau, chính sách quá cứng có thể gây khó khăn trong quá trình vận hành.
Kiểm soát các request POST
POST thường được sử dụng cho những chức năng có khả năng thay đổi dữ liệu như đăng nhập, đăng ký, gửi biểu mẫu, thêm sản phẩm, đặt hàng hoặc gọi API. Vì vậy, đây là một lớp request cần được quan sát kỹ.
Tuy nhiên, không nên hiểu rằng POST là nguy hiểm và GET là an toàn. GET cũng có thể chứa tham số độc hại, trong khi nhiều chức năng hợp lệ bắt buộc phải sử dụng POST.
Thay vì chặn POST một cách chung chung, nên xác định POST tới URL nào, từ nguồn nào, với tần suất bao nhiêu và có hành vi gì bất thường. Đây mới là cơ sở để tạo chính sách phù hợp.
Tạo Custom Rule để chặn request đáng ngờ
Custom Rule cho phép biến một yêu cầu bảo mật cụ thể thành điều kiện mà Cloudflare có thể đánh giá trên từng request. Đây là công cụ rất hữu ích khi quản trị viên đã hiểu rõ website của mình và muốn kiểm soát một hành vi cụ thể.
Một rule thường có ba thành phần chính: điều kiện, logic kết hợp điều kiện và hành động.
Ví dụ về mặt tư duy, bạn có thể xây dựng một rule theo cấu trúc:
URL thuộc khu vực cần bảo vệ
AND
request có đặc điểm bất thường
AND
nguồn truy cập không thuộc nhóm được phép
=> thực hiện hành động bảo vệ
Cách viết này tốt hơn việc chỉ đặt một điều kiện rất rộng như “nếu request tới website thì chặn”, bởi website vẫn cần phục vụ người dùng bình thường.
Trong quá trình xây dựng rule, nên ưu tiên những điều kiện có ý nghĩa rõ ràng. Ví dụ một URL cụ thể, một HTTP method cụ thể, một nhóm IP, một đặc điểm của request hoặc một ngưỡng tần suất. Khi kết hợp nhiều điều kiện bằng AND, phạm vi ảnh hưởng của rule sẽ được thu hẹp và giảm khả năng chặn nhầm.
Ví dụ logic bảo vệ một endpoint
Giả sử website có một endpoint dùng để nhận dữ liệu đặt hàng. Endpoint này cần nhận POST từ khách hàng nhưng không cần chấp nhận những phương thức HTTP khác.
Thay vì chặn toàn bộ request tới website, có thể thiết kế chính sách theo hướng chỉ kiểm soát endpoint đó và kiểm tra method không phù hợp.
request path = /dat-hang
AND
request method không phải POST
=> áp dụng hành động bảo vệ
Đây chỉ là ví dụ về logic rule, không phải đoạn cấu hình có thể sao chép nguyên trạng cho mọi website. Đường dẫn thực tế, method được sử dụng và hành động cần áp dụng phải dựa trên hệ thống đang vận hành.
Chặn theo quốc gia, IP và ASN có nên sử dụng không?
Cloudflare cho phép xây dựng chính sách dựa trên thông tin mạng của request. Trong đó, IP, quốc gia và ASN là những tín hiệu thường được sử dụng để giới hạn hoặc phân loại lưu lượng.
Chặn IP phù hợp khi bạn đã xác định một nguồn truy cập thực sự có vấn đề. Đây thường là biện pháp nhanh để xử lý một nguồn gây quá nhiều request hoặc liên tục thực hiện hành vi đáng ngờ.
Chặn theo quốc gia có thể hữu ích đối với những hệ thống chỉ phục vụ một phạm vi thị trường nhất định. Tuy nhiên, không nên mặc định rằng request đến từ một quốc gia nào đó là nguy hiểm. Người dùng thật có thể sử dụng VPN, proxy hoặc dịch vụ trung gian; đồng thời bot cũng có thể xuất hiện ở nhiều khu vực khác nhau.
ASN cũng cần được sử dụng cẩn trọng. Một ASN có thể đại diện cho mạng doanh nghiệp, nhà cung cấp hosting, ISP hoặc nhiều loại hạ tầng khác nhau. Chặn cả ASN chỉ vì phát hiện một số request xấu có thể làm mất một lượng lớn traffic hợp lệ.
Vì vậy, IP, quốc gia và ASN nên được coi là tín hiệu để tăng hoặc giảm mức độ tin cậy, thay vì luôn là căn cứ duy nhất để chặn.
Kết hợp WAF với Rate Limiting để chống request dồn dập
WAF và Rate Limiting giải quyết hai vấn đề có liên quan nhưng không giống nhau.
WAF tập trung nhiều vào việc xác định request có dấu hiệu vi phạm chính sách hoặc chứa mẫu hành vi nguy hiểm. Rate Limiting lại tập trung vào số lượng request trong một khoảng thời gian.
Điều này rất quan trọng vì một request có thể hoàn toàn hợp lệ nhưng nếu một client gửi hàng nghìn request tương tự trong thời gian ngắn thì hệ thống vẫn có thể bị ảnh hưởng.
Ví dụ, một endpoint tìm kiếm sản phẩm có thể cho phép người dùng thực hiện tìm kiếm bình thường. Nhưng nếu một bot liên tục gọi endpoint này với tốc độ rất cao, PHP và cơ sở dữ liệu phía sau có thể phải xử lý hàng loạt truy vấn không mang lại giá trị cho website.
Trong trường hợp này, việc tạo một rule chỉ tìm payload độc hại có thể không giải quyết được vấn đề. Cần có cơ chế giới hạn tần suất phù hợp với endpoint.
Không nên đặt một ngưỡng giống nhau cho toàn website
Đây là điểm thường bị bỏ qua khi triển khai rate limiting. Mỗi URL có đặc điểm tài nguyên khác nhau.
| Loại endpoint | Đặc điểm cần quan tâm |
|---|---|
| Trang nội dung | Thường có thể chịu lượng request lớn hơn và ít tạo thao tác ghi dữ liệu. |
| Đăng nhập | Cần kiểm soát mạnh hơn vì có thể bị lạm dụng để dò thông tin xác thực. |
| Tìm kiếm | Có thể tạo truy vấn cơ sở dữ liệu liên tục nếu bị bot khai thác. |
| API | Cần giới hạn dựa trên hành vi và nhu cầu của từng client. |
| Gửi biểu mẫu | Có thể bị spam hoặc tạo dữ liệu rác nếu không kiểm soát. |
Do đó, thay vì đặt một giới hạn cực thấp cho tất cả request, nên xác định endpoint nào thực sự cần giới hạn mạnh. Cách này vừa bảo vệ server vừa giảm ảnh hưởng đến người dùng bình thường.
Bảo vệ API bằng WAF như thế nào?
API thường khác website HTML truyền thống ở cách client tương tác với server. Một API có thể nhận request từ ứng dụng di động, website frontend, phần mềm bên thứ ba hoặc hệ thống nội bộ. Vì vậy, việc áp dụng rule quá cứng có thể làm gián đoạn những client hợp lệ.
Trước tiên cần lập danh sách các endpoint API quan trọng và xác định method, header, authentication và dữ liệu mà từng endpoint chấp nhận.
Ví dụ, một endpoint chỉ dùng để nhận dữ liệu có thể yêu cầu POST và một loại content type nhất định. Khi đó, những request không phù hợp có thể được đưa vào chính sách kiểm tra riêng.
API endpoint
+
HTTP method hợp lệ
+
Content-Type phù hợp
+
xác thực hợp lệ
+
tần suất request trong ngưỡng cho phép
Cách tiếp cận này giúp WAF trở thành một lớp kiểm soát có hiểu biết về ứng dụng thay vì một hệ thống chỉ tìm kiếm những chuỗi ký tự đáng ngờ.
Đối với API công khai, rate limiting đặc biệt quan trọng. Nếu API được sử dụng bởi đối tác hoặc ứng dụng bên ngoài, nên xác định rõ giới hạn sử dụng và cơ chế nhận diện client trước khi triển khai chính sách chặn.
Kiểm tra rule trước khi áp dụng chặn thực tế
Một rule bảo mật tốt nhưng đặt sai điều kiện vẫn có thể gây sự cố. Vì vậy, quá trình kiểm thử quan trọng không kém việc tạo rule.
Trước khi chuyển một rule sang chế độ chặn, hãy kiểm tra các tình huống phổ biến của website: người dùng đăng nhập, tìm kiếm, gửi form, thêm sản phẩm vào giỏ hàng, thanh toán, quản trị viên cập nhật nội dung và các request API nếu có.
Nếu website có hệ thống log hoặc công cụ theo dõi request, hãy đối chiếu request bị rule tác động với hành vi thực tế. Mục tiêu là trả lời được hai câu hỏi: rule có bắt đúng loại traffic cần xử lý không và có khả năng ảnh hưởng đến traffic hợp lệ không?
Đặc biệt cần kiểm tra các URL động và tham số có ký tự đặc biệt. Đây là những nơi dễ xuất hiện false positive nhất nếu điều kiện được xây dựng quá rộng.
Ưu tiên độ chính xác thay vì số lượng rule
Một website không trở nên an toàn hơn chỉ vì có rất nhiều rule. Nếu các rule chồng chéo, điều kiện mâu thuẫn hoặc không ai hiểu rõ mục đích của từng rule, việc xử lý sự cố sau này sẽ khó khăn hơn.
Mỗi rule nên có một mục tiêu cụ thể. Khi cần thay đổi, quản trị viên phải biết rule đang bảo vệ URL nào, ngăn hành vi nào và lý do tại sao hành động đó được áp dụng.
Đây cũng là lý do nên bắt đầu với một số rule có tác động rõ ràng, theo dõi kết quả rồi mới mở rộng. Một cấu hình đơn giản nhưng chính xác thường có giá trị hơn một cấu hình phức tạp mà không được kiểm tra thường xuyên.
Những sai lầm thường gặp khi cấu hình Cloudflare WAF
Chặn theo một dấu hiệu duy nhất
Một IP, quốc gia hoặc user agent riêng lẻ chưa chắc đủ để kết luận request là độc hại. Nếu dùng một tín hiệu duy nhất làm điều kiện chặn tuyệt đối, nguy cơ false positive sẽ tăng lên.
Chặn quá rộng toàn bộ website
Một rule áp dụng cho tất cả URL có thể vô tình ảnh hưởng tới trang sản phẩm, form, API hoặc chức năng quản trị. Phạm vi rule nên được giới hạn vào khu vực thực sự cần bảo vệ.
Chỉ quan tâm tới request mà bỏ qua ứng dụng
WAF không thể sửa một lỗ hổng nằm trong PHP, JavaScript hoặc cơ sở dữ liệu. Nếu ứng dụng xử lý dữ liệu không an toàn, việc chỉ tăng mức độ WAF không giải quyết được nguyên nhân gốc.
Không theo dõi sau khi bật rule
Website thay đổi theo thời gian. Một chức năng mới, API mới hoặc chiến dịch marketing có thể tạo ra kiểu traffic khác trước. Rule từng hoạt động tốt vẫn cần được kiểm tra khi kiến trúc website thay đổi.
Dùng WAF để xử lý mọi vấn đề về hiệu năng
WAF có thể giảm request không mong muốn nhưng không thay thế việc tối ưu website. Nếu PHP xử lý chậm, truy vấn cơ sở dữ liệu kém hoặc server thiếu tài nguyên, cần giải quyết nguyên nhân hiệu năng thay vì cố chặn traffic để che giấu vấn đề.
Theo dõi hoạt động của WAF sau khi cấu hình
Cấu hình WAF không phải công việc làm một lần rồi bỏ đó. Sau khi rule được triển khai, điều quan trọng là phải biết Cloudflare đang chặn những request nào, nguồn truy cập đến từ đâu và liệu có request hợp lệ nào bị ảnh hưởng hay không.
Thông qua khu vực theo dõi sự kiện bảo mật, quản trị viên có thể quan sát các request đã bị xử lý bởi những lớp bảo vệ. Những dữ liệu này giúp trả lời một vấn đề rất thực tế: rule đang thực sự ngăn được hành vi nào?
Thay vì chỉ nhìn vào tổng số request bị chặn, nên quan sát cả đường dẫn, phương thức HTTP, nguồn truy cập và đặc điểm của request. Một lượng lớn request bị chặn tới một URL không tồn tại có thể là hoạt động quét tự động. Ngược lại, nếu hàng loạt request tới chức năng tìm kiếm của khách hàng bị chặn thì cần kiểm tra khả năng rule đang quá rộng.
Những thông tin nên kiểm tra trong log
- URL hoặc endpoint mà request truy cập.
- HTTP method được sử dụng.
- Thời điểm request xảy ra.
- IP hoặc thông tin mạng của nguồn truy cập.
- Rule nào đã tác động tới request.
- Request được cho phép, thử thách hay chặn.
- Request có đặc điểm gì khiến hệ thống đánh giá là đáng ngờ.
Việc xem log theo từng nhóm hành vi thường hữu ích hơn việc chỉ nhìn từng request riêng lẻ. Nếu hàng nghìn request có cùng kiểu URL, cùng đặc điểm và xuất hiện liên tục trong một khoảng thời gian, đó có thể là dấu hiệu của một hoạt động tự động.
Xử lý khi Cloudflare WAF chặn nhầm người dùng
Không có hệ thống phát hiện tự động nào đảm bảo không bao giờ xảy ra false positive. Một request hợp lệ đôi khi có thể giống với mẫu dữ liệu thường xuất hiện trong một cuộc tấn công.
Khi người dùng báo rằng website không truy cập được hoặc một chức năng đột nhiên bị lỗi sau khi bật WAF, không nên lập tức tắt toàn bộ hệ thống bảo vệ. Cách tốt hơn là xác định chính xác request nào bị tác động và rule nào đã tạo ra quyết định đó.
Quy trình xử lý nên đi theo hướng:
- Xác định URL hoặc chức năng mà người dùng gặp lỗi.
- Kiểm tra request tương ứng trong dữ liệu sự kiện bảo mật.
- Xác định rule đã tác động tới request.
- Đối chiếu request đó với logic hoạt động thực tế của website.
- Thu hẹp điều kiện của rule nếu rule đang quá rộng.
- Kiểm tra lại chức năng sau khi điều chỉnh.
Ví dụ, nếu một rule kiểm soát một chuỗi dữ liệu xuất hiện trong tham số tìm kiếm nhưng website thực tế cần cho phép người dùng nhập chuỗi đó, giải pháp tốt hơn là điều chỉnh phạm vi rule thay vì tắt WAF trên toàn website.
Không nên tạo ngoại lệ quá rộng
Khi gặp false positive, một cách xử lý nhanh là tạo ngoại lệ cho toàn bộ IP hoặc toàn bộ URL. Tuy nhiên, đây có thể trở thành điểm yếu mới.
Nếu ngoại lệ áp dụng cho quá nhiều request, một nguồn truy cập đáng ngờ có thể lợi dụng chính ngoại lệ đó để vượt qua lớp bảo vệ. Vì vậy, ngoại lệ nên được giới hạn ở mức cần thiết.
Ví dụ, thay vì bỏ qua toàn bộ chính sách bảo mật cho một URL, có thể xem xét ngoại lệ cho một điều kiện cụ thể hoặc chỉ loại trừ một trường hợp hợp lệ đã được xác minh. Mục tiêu là giải quyết false positive nhưng vẫn giữ lại càng nhiều lớp bảo vệ càng tốt.
Bảo vệ website PHP bằng nhiều lớp thay vì chỉ dùng WAF
Đối với website PHP, Cloudflare WAF nên được đặt trong một kiến trúc bảo mật nhiều lớp. Mỗi lớp xử lý một nhóm rủi ro khác nhau.
| Lớp | Vai trò |
|---|---|
| Cloudflare | Lọc request, giảm traffic độc hại và áp dụng chính sách truy cập. |
| Web server | Kiểm soát dịch vụ, cấu hình domain và giới hạn tài nguyên. |
| PHP | Xử lý request an toàn và kiểm soát dữ liệu đầu vào. |
| Cơ sở dữ liệu | Giới hạn quyền và sử dụng truy vấn an toàn. |
| Ứng dụng | Phân quyền, session, xác thực và validation. |
| Quản trị viên | Bảo vệ tài khoản, cập nhật phần mềm và giám sát hệ thống. |
Ví dụ, nếu một form nhận dữ liệu từ người dùng, WAF có thể giúp phát hiện những request có đặc điểm bất thường. Nhưng ứng dụng PHP vẫn phải kiểm tra dữ liệu, giới hạn độ dài, xác thực kiểu dữ liệu và xử lý output đúng cách.
Đối với truy vấn cơ sở dữ liệu, không nên xây dựng câu SQL bằng cách nối trực tiếp dữ liệu người dùng vào chuỗi truy vấn rồi kỳ vọng WAF sẽ bảo vệ toàn bộ hệ thống.
Ví dụ nguyên tắc xử lý an toàn nên nằm ở tầng ứng dụng:
<?php
$stmt = $pdo->prepare("SELECT * FROM products WHERE id = ?");
$stmt->execute([$productId]);
$result = $stmt->fetch();
?>
Trong ví dụ trên, prepared statement giúp ứng dụng xử lý dữ liệu theo cách an toàn hơn. Đây là lớp bảo vệ mà WAF không thể thay thế.
WAF có chống được DDoS không?
Cloudflare cung cấp nhiều cơ chế bảo vệ trước lưu lượng tấn công quy mô lớn, nhưng cần phân biệt giữa WAF và DDoS protection.
WAF chủ yếu tập trung vào việc phân tích và áp dụng chính sách đối với request web. DDoS lại có thể diễn ra ở nhiều lớp khác nhau và có quy mô rất lớn. Một cuộc tấn công DDoS không nhất thiết phải chứa payload SQL Injection hay XSS để gây ảnh hưởng tới hệ thống.
Do đó, không nên nói rằng “bật WAF là website sẽ không bị DDoS”. Cách hiểu chính xác hơn là Cloudflare có thể cung cấp nhiều lớp bảo vệ, trong đó WAF là một thành phần quan trọng dành cho traffic ứng dụng web.
Đối với website thông thường, việc đưa traffic qua Cloudflare có thể giúp giảm đáng kể lượng request không mong muốn tới máy chủ gốc. Tuy nhiên, server origin vẫn cần được cấu hình phù hợp và không nên để lộ quá dễ dàng cho các nguồn truy cập trực tiếp.
Bảo vệ máy chủ gốc khi sử dụng Cloudflare
Một sai lầm thường gặp là chỉ cấu hình WAF nhưng vẫn để IP máy chủ gốc công khai và cho phép mọi nguồn truy cập trực tiếp. Trong trường hợp đó, kẻ tấn công có thể tìm cách bỏ qua Cloudflare và gửi request trực tiếp tới origin.
Về mặt kiến trúc, mục tiêu nên là để traffic web thông thường đi qua Cloudflare, đồng thời hạn chế khả năng truy cập trực tiếp không được phép vào máy chủ gốc.
Đây là vấn đề cần được xử lý ở firewall hoặc cấu hình mạng của server. Cách triển khai cụ thể phụ thuộc vào nhà cung cấp hosting, VPS, cloud server và mô hình dịch vụ đang sử dụng.
Nếu website có các dịch vụ khác cần truy cập trực tiếp như SSH, FTP, API nội bộ hoặc hệ thống giám sát thì không nên áp dụng chính sách chặn toàn bộ một cách máy móc. Cần phân biệt dịch vụ web và những dịch vụ quản trị khác.
Checklist cấu hình Cloudflare WAF cho website
Đối với một website đang vận hành thực tế, có thể sử dụng checklist dưới đây để rà soát cấu hình theo từng bước.
- Xác định các URL và endpoint quan trọng.
- Xác định khu vực quản trị và các chức năng đăng nhập.
- Bật lớp rule bảo mật phù hợp với ứng dụng.
- Kiểm tra các request bị tác động sau khi triển khai.
- Tạo Custom Rules cho những trường hợp đặc thù của website.
- Không tạo rule quá rộng khi chưa kiểm tra traffic thực tế.
- Áp dụng rate limiting cho các endpoint có nguy cơ bị spam hoặc lạm dụng.
- Kiểm soát riêng các API có giá trị hoặc tiêu tốn nhiều tài nguyên.
- Kiểm tra false positive trước khi mở rộng phạm vi chặn.
- Hạn chế việc tạo ngoại lệ cho toàn bộ website hoặc toàn bộ IP nếu không cần thiết.
- Cập nhật mã nguồn, PHP và các thành phần máy chủ thường xuyên.
- Sử dụng prepared statement và validation ở tầng PHP.
- Bảo vệ tài khoản quản trị bằng mật khẩu mạnh và cơ chế xác thực phù hợp.
- Kiểm tra cấu hình máy chủ gốc để hạn chế việc bypass Cloudflare.
- Theo dõi log và điều chỉnh rule khi hành vi truy cập của website thay đổi.
Cloudflare WAF phù hợp với website nào?
WAF đặc biệt hữu ích với những website có dữ liệu người dùng, form, tài khoản đăng nhập, chức năng tìm kiếm, API hoặc các endpoint xử lý dữ liệu động. Website bán hàng, website doanh nghiệp, hệ thống đặt hàng và các ứng dụng PHP đều có thể hưởng lợi từ một lớp lọc request đặt trước server.
Tuy nhiên, mức độ cấu hình nên phụ thuộc vào giá trị và đặc điểm của website. Một trang giới thiệu đơn giản không nhất thiết cần hàng chục rule phức tạp. Ngược lại, một hệ thống có đăng nhập, thanh toán, API và nhiều dữ liệu quan trọng cần một chính sách bảo vệ chi tiết hơn.
Điều quan trọng nhất là xác định đúng rủi ro thay vì chạy theo số lượng rule.
Giải pháp bảo mật website nên bắt đầu từ đâu?
Đối với doanh nghiệp đang xây dựng hoặc nâng cấp website, bảo mật nên được tính đến ngay từ giai đoạn thiết kế kiến trúc thay vì chờ tới khi xuất hiện cuộc tấn công mới xử lý.
Cloudflare WAF có thể đảm nhận một lớp bảo vệ quan trọng ở phía trước website, giúp lọc nhiều request đáng ngờ trước khi chúng tới máy chủ. Nhưng hiệu quả thực sự chỉ xuất hiện khi WAF được kết hợp với mã nguồn an toàn, máy chủ được cấu hình đúng và quy trình giám sát thường xuyên.
Với các website PHP được phát triển theo yêu cầu, Web Mới có thể chủ động thiết kế cấu trúc website, endpoint và cơ chế xử lý dữ liệu theo hướng phù hợp với yêu cầu bảo mật ngay từ đầu. Khi đó, Cloudflare không chỉ được thêm vào sau khi website hoàn thiện mà có thể được xem như một thành phần trong toàn bộ kiến trúc vận hành.
Nếu doanh nghiệp cần một website được xây dựng theo yêu cầu riêng, có khả năng mở rộng và cần kiểm soát tốt phần mã nguồn, có thể tham khảo dịch vụ lập trình website PHP theo yêu cầu của Web Mới.
Tóm lại, Cloudflare WAF không phải một nút bấm có thể giải quyết toàn bộ vấn đề bảo mật. Giá trị lớn nhất của WAF nằm ở khả năng tạo thêm một lớp kiểm soát giữa Internet và ứng dụng, giúp giảm request độc hại, hạn chế hành vi bất thường và giảm áp lực lên máy chủ. Khi được cấu hình dựa trên hành vi thực tế của website, kết hợp với rate limiting, bảo mật PHP và bảo vệ server origin, WAF sẽ trở thành một phần quan trọng trong chiến lược bảo vệ website lâu dài.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
