③ Hoàn tất thiết lập ban đầu (Initial setup)

Linux hỗ trợ password injection: nhập root password ≥ 8 ký tự, có ít nhất 1 chữ hoa và 1 chữ số — không dùng lại mật khẩu từ hệ thống khác.

Windows hoặc custom OS: trường mật khẩu bị ẩn — sau khi tạo, mở VNC Console để hoàn tất setup và đặt Administrator password trực tiếp trong console.

⑥ Cấu hình Networking

Public NIC: bật khi instance cần kết nối internet trực tiếp — public web server, bastion/jump host. Dùng Auto-allocate trừ khi đã có IP reserved.

Private NIC: bật khi instance cần giao tiếp nội bộ — app-to-database, internal API, backend không nên lộ ra internet.

⑦ Chọn hoặc tạo Security Group

Bắt buộc phải có ít nhất 1 Security Group. Có thể chọn nhóm có sẵn hoặc bấm Create new ngay trên form tạo instance mà không cần rời trang.

⑧ Xem lại Summary & chi phí ước tính

Kiểm tra vCPU, RAM, OS volume, extra volume, network, security group, và chi phí ước tính theo giờ/tháng (dựa trên 720 giờ/tháng, billing thực tế tính theo giờ chạy thực). Nếu chi phí cao hơn dự kiến, giảm vCPU/RAM/disk size/public IP trước khi tạo.

⑨ Bấm Create Instance

Nút bị disable nếu thiếu trường bắt buộc (tên, image, mật khẩu hợp lệ, storage class, security group) hoặc vượt quota. Sau khi tạo, instance chuyển qua trạng thái pending/creating/starting trong vài phút.

Images (Snapshot → Image)

Chuyển một snapshot thành Image để dùng làm template khởi tạo Instance mới nhanh hơn. Phù hợp khi bạn đã cài đặt môi trường sẵn và muốn nhân bản.

Machine Images (toàn bộ Instance)

Sao lưu toàn bộ máy chủ bao gồm tất cả ổ đĩa. Khôi phục sẽ tạo ra một Instance hoàn toàn mới với đầy đủ dữ liệu — đây là giải pháp backup an toàn nhất.

Nên bắt đầu từ hướng dẫn nào?

Bắt đầu với phần “Tạo Cloud Server mới” ở mục 2 để có instance đầu tiên chạy được nhanh nhất.

Instance và Volume khác nhau thế nào?

Instance là máy chủ ảo. Volume là ổ đĩa lưu trữ bền vững. OS volume dùng để khởi động instance; data volume tách riêng lưu dữ liệu ứng dụng.

Nên chọn storage class nào?

Dùng Standard cho workload thông thường, Enterprise cho database và ứng dụng ghi nhiều, capacity/archive cho dữ liệu lạnh ít truy cập.

Vì sao không tạo được instance?

Nguyên nhân thường gặp: tên không hợp lệ, thiếu image/template, chưa có storage class, thiếu security group, mật khẩu chưa đạt yêu cầu, hoặc cấu hình vượt quota tài khoản.

Có nên lưu dữ liệu ứng dụng ngay trên OS disk?

Với production, nên dùng data volume riêng — giúp snapshot, khôi phục, di chuyển và thay thế máy chủ dễ dàng hơn nhiều so với gộp chung OS disk.

Làm sao kiểm soát chi phí hàng tháng?

Theo dõi đều đặn vCPU, RAM, public IP, dung lượng và tier storage, cùng số lượng snapshot đang lưu — tất cả đều hiển thị chi tiết tại mục Usage.

Bước 1 — Chuẩn bị domain

Trước khi bắt đầu, đảm bảo bạn đã sở hữu một domain hợp lệ (ví dụ: your-domain.com). Nếu chưa có, có thể đăng ký trực tiếp qua Cloudflare Registrar.

Lưu ý quan trọng: tắt DNSSEC tại nhà cung cấp domain hiện tại trước khi chuyển nameserver — nếu không tắt, việc chuyển đổi có thể gây gián đoạn truy cập tạm thời.

Bước 2 — Thêm website vào Cloudflare

Đăng nhập dash.cloudflare.com → bấm Add site → nhập tên domain của bạn → Continue.

Cloudflare sẽ yêu cầu chọn gói dịch vụ (Free, Pro, Business hoặc Enterprise) phù hợp với quy mô website.

Bước 3 — Quét và kiểm tra bản ghi DNS

Cloudflare tự động quét các bản ghi DNS hiện có (A, CNAME, MX, TXT…) và import vào DNS Zone. Hãy kiểm tra kỹ:

• Proxy status: Bản ghi nào nên “Proxied” (đi qua Cloudflare, hưởng CDN/bảo mật) và bản ghi nào chỉ cần “DNS only”
• TTL: Thời gian cache bản ghi — ảnh hưởng tốc độ cập nhật khi có thay đổi
• Nếu thiếu bản ghi nào, thêm thủ công bằng nút Add record

Bước 4 — Cập nhật Nameservers

Đây là bước quan trọng nhất — Cloudflare sẽ cấp cho bạn 2 nameserver riêng (ví dụ: xxx.ns.cloudflare.com). Bạn cần:

1. Đăng nhập vào nơi đăng ký domain hiện tại (registrar)
2. Xóa nameserver cũ đang sử dụng
3. Thay bằng 2 nameserver Cloudflare đã được cấp
4. Lưu lại thay đổi

⚠️ Quá trình cập nhật nameserver có thể mất tới 24 giờ để DNS lan truyền toàn cầu. Cloudflare sẽ gửi email xác nhận khi domain hoạt động.

Bước 5 — Kích hoạt lại DNSSEC

Sau khi nameserver hoạt động ổn định, kích hoạt lại DNSSEC để bảo vệ domain khỏi tấn công giả mạo:

• Vào DNS → Settings trên Cloudflare → bấm Enable DNSSEC
• Cloudflare hiển thị bản ghi DS Record (gồm Digest, Algorithm, Key Tag…)
• Copy thông tin này, quay lại registrar → mục DNSSEC → thêm DS Record tương ứng

Sau bước này, toàn bộ cấu hình Full DNS trên Cloudflare đã hoàn tất.

Bước 1 — Thêm domain vào Cloudflare và chọn kiểu Partial

Đăng nhập dash.cloudflare.com → Add site → nhập tên domain. Khi chọn gói dịch vụ, chỉ Business hoặc Enterprise mới hỗ trợ cấu hình CNAME setup.

Sau khi thêm site, vào Overview, kéo xuống mục Advanced Actions và chọn Convert to CNAME DNS Setup. Một hộp thoại xác nhận sẽ hiện ra — bấm Convert để tiếp tục.

Bước 2 — Xác minh quyền sở hữu domain bằng TXT record

Sau khi convert, Cloudflare hiển thị một Verification TXT Record (dạng cloudflare-verify.your-domain.com với nội dung là một chuỗi mã ngẫu nhiên). Hãy lưu lại thông tin này — bạn luôn có thể xem lại tại DNS → Records → Verification TXT Record nếu cần.

Truy cập giao diện quản trị DNS của nhà cung cấp DNS uỷ quyền hiện tại (ví dụ AWS Route 53), tạo một bản ghi mới: Type = TXT, Name = cloudflare-verify, Value = chuỗi mã được cấp.

Bước 3 — Đồng bộ DNS record sang Cloudflare và kích hoạt

Quan trọng: các bản ghi tại Cloudflare cho subdomain dùng Partial Setup phải khớp với bản ghi đang có tại DNS uỷ quyền. Trên Cloudflare → DNS → Records → Add record, tạo lại các record (A, AAAA, CNAME…) tương ứng và bật Proxy status = Proxied (icon mây màu cam) cho những record muốn đi qua Cloudflare.

Một số trường cần chú ý khi tạo record:

• Proxy status: Bật “Proxied” để traffic được CDN, WAF, Argo, DDoS protection của Cloudflare bảo vệ; chọn “DNS only” nếu chỉ muốn Cloudflare phân giải mà không proxy
• TTL: Thời gian cache của bản ghi, ảnh hưởng tốc độ cập nhật khi thay đổi
• Comment/Tag: Ghi chú để dễ quản lý sau này

Sau khi tạo record, quay lại nhà cung cấp DNS uỷ quyền → xác nhận lại bản ghi TXT đã propagate xong → trên Cloudflare bấm Re-activate và chờ vài phút để hệ thống xác thực.

Bước 4 — Trỏ CNAME tại DNS uỷ quyền về Cloudflare

Đây là bước cuối, hoàn thiện đường dẫn traffic. Tại DNS uỷ quyền:

1. Xoá toàn bộ record cũ (A, AAAA hoặc CNAME) của subdomain muốn proxy qua Cloudflare
2. Trên Cloudflare dashboard → DNS → Records, kéo xuống mục Partial Zone Suffix → bấm Copy để lấy chuỗi dạng {ten-mien}.cdn.cloudflare.net
3. Tại DNS uỷ quyền, tạo bản ghi CNAME mới: Name = subdomain (ví dụ www), Value = chuỗi vừa copy

Bước 1 — Kiểm tra điều kiện trước khi cấu hình

Trước khi đổi chế độ mã hoá, hãy chắc chắn 2 điều sau:

• Vào DNS → Records, kiểm tra các bản ghi A/AAAA/CNAME cần bảo vệ đang ở trạng thái Proxied (icon mây màu cam)
• Vào SSL/TLS → Edge Certificates, kiểm tra cột Status của chứng chỉ đang là Active

Nếu muốn chọn Full hoặc Full (strict), origin server cần có chứng chỉ SSL hợp lệ — được cấp bởi CA công khai hoặc Cloudflare Origin CA, còn hạn, và Common Name/SAN khớp với hostname.

Bước 2 — Chọn chế độ mã hoá

Đăng nhập Cloudflare dashboard → chọn domain → SSL/TLS → Overview → chọn chế độ mã hoá Full (strict).

Dashboard sẽ hiển thị trực quan sơ đồ Browser → Cloudflare → Origin Server kèm biểu tượng khoá ở từng đoạn, giúp bạn xác nhận đúng chế độ vừa chọn.

Bước 3 — Bật Always Use HTTPS

Vào SSL/TLS → Edge Certificates, tìm mục Always Use HTTPS và chuyển nút gạt sang bật. Cài đặt này tự động redirect mọi request có scheme http sang https cho toàn bộ zone — đảm bảo người dùng không bao giờ vô tình truy cập bản HTTP không mã hoá.

Vào Cloudflare dashboard → chọn Account → chọn domain → SSL/TLS → Edge Certificates → Upload Custom SSL Certificate. Dán nội dung SSL Certificate và Private Key vào 2 ô tương ứng (định dạng PEM, bắt đầu bằng -----BEGIN CERTIFICATE-----).

Ở Bundle Method, chọn một trong 3 tuỳ chọn:

• Compatible (recommended): tương thích với hầu hết trình duyệt và thiết bị, bao gồm cả thiết bị cũ
• Modern: chỉ tương thích các thiết bị/trình duyệt hiện đại, bảo mật cao hơn
• User Defined: tự định nghĩa chuỗi chứng chỉ trung gian theo yêu cầu riêng

Nếu gặp lỗi liên quan đến key không khớp với chứng chỉ, hãy liên hệ CA đã cấp chứng chỉ để kiểm tra lại cặp key/certificate.

Advanced Certificate phù hợp khi bạn cần nhiều quyền tuỳ chỉnh hơn Universal SSL nhưng vẫn muốn Cloudflare tự động cấp và gia hạn. Trước tiên cần mua thêm tiện ích Advanced Certificate Manager Add-on, sau đó vào SSL/TLS → Edge Certificates → Order Advanced Certificate.

Nếu thông tin thanh toán của tài khoản chưa có sẵn trên hệ thống Cloudflare, bạn sẽ cần nhập bổ sung trước khi tiếp tục.

Bạn cần điền 4 thông tin: Certificate Authority (CA cấp chứng chỉ), Certificate Hostnames (tối đa 50 hostname/wildcard), Validation method (chỉ TXT validation hỗ trợ wildcard và CA đã chọn) và Certificate Validity Period (3 tháng hoặc 1 tháng, tự gia hạn trước khi hết hạn). Sau khi điền đủ, bấm Save để hoàn tất.

Bước 1 — Tạo Origin Certificate

Đăng nhập Cloudflare dashboard → chọn domain → SSL/TLS → Origin Server → Create Certificate.

Chọn 1 trong 2 cách tạo private key/CSR: để Cloudflare tự sinh (chọn loại key RSA hoặc ECC), hoặc dán CSR tự tạo nếu bạn đã có sẵn.

Bước 2 — Khai báo hostname và thời hạn

Liệt kê các hostname (kể cả wildcard) mà chứng chỉ cần bảo vệ — mặc định đã bao gồm zone apex và wildcard *.example.com. Thêm thủ công các hostname con không nằm trong wildcard nếu cần.

Chọn thời hạn hiệu lực (mặc định 15 năm, có thể giảm xuống 7 ngày, 30 ngày, 90 ngày, 1-3 năm…) rồi bấm Create.

Bước 3 — Chọn Key Format và lưu lại Certificate/Private Key

Chọn định dạng key phù hợp với hệ điều hành máy chủ:

• PEM: dùng cho máy chủ chạy OpenSSL như Apache, Nginx (cũng tương thích file DER nhị phân)
• PKCS#7 (.p7b): dùng cho Windows và Apache Tomcat
• DER: định dạng nhị phân thay thế cho PEM

Sao chép nội dung Origin Certificate và Private Key ra 2 file riêng biệt và lưu lại ngay — vì lý do an toàn, Cloudflare sẽ không lưu trữ và không hiển thị lại Private Key sau khi bạn thoát khỏi màn hình này.

Bấm OK để hoàn tất tạo chứng chỉ.

Mở Internet Information Services (IIS) Manager từ Windows Start menu → tại cây Connections, click vào tên server → ở trang Homepage, mục IIS, double-click Server Certificates → tại khung Actions bên phải, chọn Complete Certificate Request.

Khai báo lần lượt: File name containing the certification authority’s response (đường dẫn tới file .cer) → Friendly name (tên gợi nhớ cho chứng chỉ) → Select a certificate store chọn Web Hosting → bấm OK.

Tại IIS Manager, mở rộng Sites → chọn website cần bảo mật → ở khung Actions bên phải, mục Edit Site, click Bindings… → trong cửa sổ Site Bindings, bấm Add.

Trong cửa sổ Add Site Binding, cấu hình: Type = https, IP address chọn IP cụ thể hoặc All Unassigned, Port = 443 (cổng chuẩn cho HTTPS), SSL certificate chọn chứng chỉ vừa cài (ví dụ yourdomain.com) → bấm OK.

Sau bước này, danh sách Site Bindings sẽ hiển thị thêm dòng https — 443 bên cạnh dòng http — 80 có sẵn, nghĩa là website đã được cấu hình chấp nhận kết nối an toàn.

Đăng nhập Cloudflare dashboard → chọn tài khoản → chọn domain cần cấu hình → vào Security → WAF → Managed rules.

Tại đây, hai ruleset mặc định thường đã có sẵn ở trạng thái Execute: Cloudflare Managed Ruleset và Cloudflare OWASP Core Ruleset. Để triển khai thêm ruleset khác (ví dụ Exposed Credentials Check Ruleset), kéo xuống mục Managed Rulesets và bấm Deploy bên cạnh ruleset mong muốn.

2.1 — Mở giao diện Configure deployment

Tại Managed rules, bấm vào tên ruleset (ví dụ Cloudflare Managed Ruleset) để mở trang Configure deployment. Trang này hiển thị phạm vi áp dụng (Execution scope — ví dụ “All incoming requests to domain.com”) và 2 lựa chọn cấu hình tổng quát: Ruleset action và Ruleset status, mặc định cả hai đều ở mức Default (giữ hành động gốc do Cloudflare định nghĩa cho từng rule).

2.2 — Tìm và chỉnh sửa từng quy tắc cụ thể

Dùng ô Search Rules để tìm theo mô tả, Rule ID hoặc lọc theo Tags (ví dụ: sqli, xss, wordpress, code-injection). Với mỗi rule trong kết quả, bạn có thể đổi Action qua dropdown — các lựa chọn thường gồm: Log (chỉ ghi nhận, không chặn), Block, Managed Challenge, JS Challenge, Interactive Challenge — hoặc bật/tắt toggle Status riêng cho rule đó.

Nếu lỡ đổi nhầm, mỗi rule có sẵn liên kết Reset to default để quay lại hành động gốc do Cloudflare định nghĩa.

2.3 — Custom filter expression (tuỳ chọn)

Nếu muốn các quy tắc trong ruleset chỉ áp dụng cho một tập con request — thay vì toàn bộ traffic — hãy check vào Custom filter expression và khai báo điều kiện lọc. Sau khi cấu hình xong, bấm Save để lưu lại.

Khi cần áp dụng cùng một hành động cho nhiều rule (ví dụ toàn bộ rule liên quan đến WordPress), việc sửa từng dòng sẽ rất mất thời gian. Cloudflare hỗ trợ chọn hàng loạt:

• Lọc rule theo tag (ví dụ “wordpress”) hoặc từ khoá tìm kiếm
• Tick checkbox ở từng dòng, hoặc tick checkbox tại header để chọn toàn bộ rule trên trang hiện tại
• Bấm Select all <TOTAL> rules để chọn toàn bộ rule khớp điều kiện trên tất cả các trang

Sau khi chọn xong, bấm Set action hoặc Set status để cập nhật đồng loạt cho tất cả rule đã chọn — các tuỳ chọn action gồm Managed Challenge, Block, JS Challenge, Interactive Challenge, Log, Default; status gồm Enabled, Disabled, Default. Bấm Next để xem lại danh sách, sau đó Save để áp dụng.

Lưu ý: nếu bạn lọc rule theo một tag cụ thể, hệ thống có thể hỏi liệu các rule mới được thêm vào tag đó trong tương lai (do Cloudflare cập nhật ruleset) có nên tự động áp dụng cùng cấu hình hay không.

5.1 — Mở giao diện Add exception

Vào Security → WAF → Managed rules → bấm nút Add exception ở góc trên bên phải. Form gồm 3 phần: Exception name (đặt tên gợi nhớ), When incoming requests match… (điều kiện áp dụng) và Then… (hành động bỏ qua).

5.2 — Khai báo điều kiện khớp request

Tại mục Field / Operator / Value, chọn trường cần lọc (ví dụ Hostname, URI, IP Source Address…) và điều kiện so khớp (contains, equals…). Có thể nối nhiều điều kiện bằng And/Or. Khung Expression Preview sẽ hiển thị biểu thức tương ứng dưới dạng Rules language, ví dụ: (http.host contains "vgsholding.com") or (http.host contains "sonic.com.vn").

5.3 — Chọn loại exception tại mục “Then…”

Hai lựa chọn chính, sắp theo mức ưu tiên giảm dần:

• Skip all remaining rules: bỏ qua toàn bộ rule còn lại của các bộ WAF managed ruleset cho request khớp điều kiện
• Skip specific rules from a Managed Ruleset: chỉ bỏ qua một hoặc nhiều rule cụ thể mà bạn chọn từ một ruleset nhất định — bấm Select ruleset rồi Select rules để tìm và tick chọn rule cần bỏ qua (tìm theo mô tả, Rule ID, hoặc tag, ví dụ tìm “920460” để ra rule 920460: Abnormal character escapes in request)

5.4 — Cấu hình Log matching requests và triển khai

Gạt toggle Log matching requests nếu muốn tắt việc ghi nhận log cho các request khớp với exception (khi tắt, request khớp sẽ không hiển thị tại Security overview). Sau khi hoàn tất, bấm Deploy để áp dụng ngay, hoặc Save as Draft nếu chưa muốn triển khai.

6.1 — Mở danh sách Managed rules

Vào Security → WAF → Managed rules, tìm đúng ruleset đang chứa rule mà bạn muốn ghi lại payload (ví dụ Cloudflare Managed Ruleset hoặc OWASP Core Ruleset) rồi bấm vào tên ruleset đó để mở trang chi tiết.

6.2 — Xác định rule muốn theo dõi

Trang chi tiết hiển thị toàn bộ rule con bên trong ruleset (ví dụ các rule dạng Anomaly:Header:User-Agent – Missing hay Anomaly:Method – Unknown HTTP Method) cùng action và trạng thái Enabled. Việc ghi log payload không cấu hình riêng cho từng rule mà áp dụng cho cả deployment hiện tại của ruleset.

6.3 — Mở liên kết Configure payload logging

Kéo xuống cuối trang cấu hình deployment, bấm Configure payload logging — liên kết này nằm cùng khu vực với các nút Delete deployment, Cancel và Save.

6.4 — Chọn cách tạo cặp khoá mã hoá

Hệ thống sẽ nhắc bạn đọc kỹ hậu quả của việc bật ghi log payload trước khi tiếp tục. Sau đó chọn một trong hai phương án:

• Generate key pair using your web browser: trình duyệt tự sinh cặp khoá public/private ngay tại máy bạn — private key không bao giờ được gửi lên Cloudflare
• Use my own public key: sử dụng public key được tạo sẵn từ công cụ dòng lệnh matched-data-cli, phù hợp khi team đã có quy trình quản lý khoá riêng

6.5 — Lưu lại Private key

Nếu chọn tạo khoá trong trình duyệt, hệ thống hiển thị cùng lúc Public key và Private key — copy và cất Private key vào nơi an toàn (password manager, vault nội bộ của công ty…) vì nó chỉ hiện đúng một lần. Bấm Next rồi Done để hoàn tất bước này.

6.6 — Triển khai cấu hình

Bấm Deploy nếu đây là lần đầu bạn triển khai ruleset kèm cấu hình payload logging, hoặc Save nếu đang cập nhật cấu hình cho một ruleset đã được triển khai từ trước đó.

7.1 — Mở Security → Events

Tại Activity log, tìm sự kiện được kích hoạt bởi rule cần kiểm tra và bấm vào để mở rộng chi tiết — các thông tin như Ray ID, Method, Host, Path, Query string, IP address, ASN, Country, Action taken… đều hiển thị đầy đủ tại đây.

7.2 — Tìm khu vực Payload match

Trong phần chi tiết sự kiện, kéo xuống mục Payload match — Cloudflare ghi rõ rằng phần request gây ra hành động của WAF đã được ghi nhận (ở dạng mã hoá), kèm liên kết Decrypt payload log để xem nội dung gốc.

7.3 — Nhập Private key để giải mã

Bấm Decrypt payload log, dán Private key đã lưu ở Bước 6.5 vào cửa sổ xuất hiện rồi bấm Decrypt. Nếu khoá đúng, nội dung payload — các tham số trong query string, request headers, body form values… — sẽ hiển thị ngay dưới dạng cleartext, giúp bạn xác định chính xác request đó là tấn công thật hay chỉ là false positive cần bổ sung exception.

Bước 1 — Chọn đúng tài khoản và domain

Đăng nhập dash.cloudflare.com, ở màn hình Accounts chọn tài khoản đang quản lý domain cần cấu hình, sau đó chọn đúng zone (domain) muốn thêm rule.

Bước 2 — Mở Custom rules và tạo mới

Vào Security → WAF → Custom rules → bấm Create rule. Trang Create rule sẽ hiện ra với 3 vùng chính: đặt tên rule, khai báo điều kiện khớp request, và chọn hành động thực hiện.

Bước 3 — Khai báo điều kiện (Field / Operator / Value)

Mỗi điều kiện gồm 3 phần: Field là thuộc tính của request (IP Source, Hostname, URI, User Agent, Country, Verified Bot…), Operator là phép so sánh (equals, contains, does not equal, is in list…), Value là giá trị tham chiếu. Có thể nối nhiều điều kiện bằng And/Or.

Tham khảo đầy đủ danh sách field tại Rules language fields và các toán tử so sánh tại Comparison operators.

Bước 4 — Chọn hành động & triển khai

Tại mục Then take action…, chọn hành động phù hợp rồi bấm Deploy để áp dụng ngay, hoặc Save as Draft nếu muốn xem lại trước khi kích hoạt chính thức.

Tại WAF → Custom rules → Create rule: đặt tên rule, thêm điều kiện Verified Bot equals true. Nếu muốn giới hạn thêm phạm vi (chỉ áp dụng cho một số đường dẫn cụ thể), nối thêm điều kiện bằng Or với field như ASN, URI Path, User Agent hoặc JA3 Fingerprint. Chọn action Skip → tick All remaining custom rules, All managed rules, All Super Bot Fight Mode Rules → Deploy.

4.1–4.2: Cho người dùng thật truy cập website và thao tác đầy đủ các tính năng trong vài ngày để tạo ra mẫu traffic đại diện. Sau đó vào Security → Events, dùng bộ lọc Managed rules để tách riêng những request đã bị bộ Managed Rules đánh dấu.

4.3: Mở từng event để xem chi tiết — Rule ID nào kích hoạt, request đến từ URI/hostname nào, qua HTTP Method gì, User Agent ra sao. Đây là dữ liệu để xác định request đó có thực sự nguy hiểm hay chỉ là hành vi hợp lệ của ứng dụng (ví dụ một API nội bộ dùng method PUT bất thường).

4.4: Với mỗi false positive xác định được, tạo Exception hoặc Custom Rule để bypass đúng rule đó cho đúng URI/hostname liên quan — lặp lại quá trình này nhiều vòng cho đến khi không còn false positive đáng kể.

5.1–5.4: Quy trình tương tự Mẹo 4 — tạo traffic sạch, vào Security → Events nhưng lần này lọc theo Cloudflare OWASP Core Ruleset, rồi mở chi tiết từng event để xem rule nào (ví dụ 949110: Inbound Anomaly Score Exceeded) cùng điểm OWASP score, URI, hostname, User Agent liên quan.

5.5 — Đọc Additional logs để thấy toàn bộ rule con bị kích hoạt

Một request thường kích hoạt cùng lúc nhiều rule OWASP nhỏ (ví dụ phát hiện ký tự bất thường trong header, dấu hiệu SQL injection probing…), mỗi rule cộng dồn một điểm số (+3, +5…) vào tổng Anomaly Score. Mở rộng mục Additional logs để xem đầy đủ danh sách này trước khi quyết định bypass rule nào.

Bước 1-2 — Chọn account và domain

Đăng nhập dash.cloudflare.com, chọn đúng tài khoản, sau đó chọn domain cần áp dụng rate limit.

Bước 3-4 — Mở tab Rate limiting rules và tạo mới

Vào Security → WAF → Rate limiting rules → bấm Create rule. Đây là tab riêng biệt nằm cạnh Custom rules và Managed rules, chuyên dùng cho các quy tắc giới hạn tốc độ truy cập.

Bước 5 — Đặt tên rule

Nhập tên gợi nhớ vào Rule name. Ví dụ một rule cho phép tối đa 5 lần đăng nhập thất bại trong 10 giây có thể đặt tên kiểu “Login_Fail_5_per_10s”.

Bước 6 — Khai báo điều kiện khớp request

Tại If incoming requests match…, chọn các field HTTP cần đối chiếu — thường gặp nhất là URI (đường dẫn endpoint cần bảo vệ, ví dụ /login) kết hợp And với Hostname để giới hạn đúng zone đang cấu hình.

Bước 7 (tùy chọn) — Cache status

Nếu chỉ muốn tính tốc độ truy cập dựa trên request thực sự chạm tới origin server (bỏ qua những request được phục vụ từ cache), tắt toggle Also apply rate limiting to cached assets.

Bước 8 — With the same characteristics

Đây là bước quyết định Cloudflare sẽ “đếm” theo đơn vị nào. Thêm một hoặc nhiều đặc điểm (ví dụ IP, Header value of…, hoặc field tùy chỉnh) — mỗi tổ hợp giá trị riêng biệt sẽ có một bộ đếm độc lập. Ví dụ chọn IP nghĩa là mỗi địa chỉ IP có một bộ đếm 5 request/10 giây của riêng nó.

Bước 9 (tùy chọn) — Custom counting expression

Nếu muốn chỉ tăng bộ đếm khi một điều kiện cụ thể được đáp ứng (kể cả dựa trên response header trả về), bật Use custom counting expression và khai báo biểu thức riêng tại Increment counter when…. Mặc định, biểu thức đếm sẽ giống hệt biểu thức rule ở Bước 6.

Bước 10 — When rate exceeds

Định nghĩa số lượng request tối đa (Requests) và khoảng thời gian xem xét (Period). Ví dụ: 5 request trong 10 seconds — nghĩa là một IP gửi quá 5 request trong vòng 10 giây sẽ kích hoạt rule.

Bước 11-12 — Then take action + Custom response

Tại Then take action, chọn hành động khi vượt ngưỡng — phổ biến nhất là Block để Cloudflare từ chối thẳng các request thừa. Có thể tùy chỉnh thêm phản hồi trả về: response type Custom Text, response code 429 (mã chuẩn cho “Too Many Requests”), response body ví dụ “Access Denied!”.

Bước 13 — Chọn hành vi chặn (With the following behaviour)

Đây là khoảng thời gian (mitigation timeout) Cloudflare áp dụng action đã chọn sau khi đạt ngưỡng. Có 2 lựa chọn:

• Block for the selected duration: một khi đạt ngưỡng, WAF chặn toàn bộ request trong suốt thời gian đã chọn (ví dụ 1 phút) trước khi bộ đếm reset
• Throttle requests over the maximum configured rate (chỉ dành cho gói doanh nghiệp): WAF chỉ chặn đúng phần request vượt rate đã cấu hình, các request còn lại trong giới hạn vẫn được phép đi qua bình thường

Bước 14 — Triển khai

Bấm Deploy để áp dụng rule ngay, hoặc Save as Draft nếu chưa muốn kích hoạt chính thức.

Bước 1 — Xác định phạm vi: vào Security → Analytics, chọn tab Traffic analysis, lọc theo một khoảng thời gian không cao điểm để thấy phân bổ traffic thông thường, sau đó đổi sang khung giờ trùng với đợt nghi ngờ bị tấn công để so sánh — chú ý các chỉ số Mitigated by WAF, Served by Cloudflare, Served by origin.

Bước 2 — Tìm kiếm tỷ lệ phù hợp: chuyển sang tab Rate limit analysis, chọn thuộc tính cần nhóm (Group by top) — IP address, hoặc JA3 fingerprint nếu zone có bật Bot Management — cùng khoảng thời gian (1 phút, 5 phút hoặc 1 giờ). Biểu đồ sẽ hiển thị phân phối số request của 50 IP/JA3 nhiều nhất, sắp theo thứ tự giảm dần.

Bước 3 — Kéo thanh trượt: di chuyển thanh trượt ngang trên biểu đồ lên xuống để xem trực quan tác động của từng mức ngưỡng — bao nhiêu IP sẽ rơi vào diện bị giới hạn nếu chọn mức đó. Có thể thu hẹp thêm bằng bộ lọc theo Path nếu chỉ muốn áp dụng cho một endpoint cụ thể (ví dụ /login).

Bước 1 — Mở CASB Integrations trên Zero Trust dashboard

Từ Zero Trust dashboard, truy cập tab CASB → chọn Add an integration → chọn Google Workspace trong danh sách ứng dụng hỗ trợ.

Bước 2 — Tạo Service Account trên Google Cloud Platform

Đặt tên cho tích hợp → Next → chọn Create a Service Account in your GCP Project. Khi tạo service account mới trên GCP:

• Nhập tên, mô tả và ID cho service account — ghi nhớ các giá trị này vì sẽ cần dùng lại sau
• Không gán bất kỳ role hay quyền truy cập nào cho account này ở bước tạo
• Không cấp quyền truy cập người dùng cho service account

Bước 3 — Tạo và tải JSON Key

Tại danh sách service account vừa tạo, mở menu (…) → chọn Manage keys → Add Key → Create new key → chọn định dạng JSON → Create. Trình duyệt sẽ tự động tải file khoá riêng tư về máy — hãy lưu trữ file này an toàn vì không thể khôi phục lại nếu làm mất.

Quay lại Cloudflare Zero Trust, upload đúng file JSON vừa tải về vào form Upload JSON Key.

Bước 4 — Kích hoạt các Google Workspace API cần thiết

Cloudflare cung cấp sẵn danh sách liên kết để bật từng API bắt buộc: Google Calendar API, Google Drive API, Google Admin SDK API, Gmail API. Mở lần lượt từng liên kết (khuyến nghị mở bằng tab mới) và bấm Enable cho từng API trên giao diện Google Cloud Console.

Lưu ý chuyển đúng sang tài khoản Google Cloud thuộc về tổ chức Workspace của bạn trước khi kích hoạt, tránh bật nhầm trên project cá nhân.

Bước 5 — Domain-Wide Delegation từ Admin Console

Đăng nhập vào Google Workspace Admin Console bằng tài khoản quản trị. Tại trang quản lý domain-wide delegation, Cloudflare sẽ hiển thị sẵn Client ID và danh sách Scopes cần copy chính xác — bao gồm các quyền đọc (readonly) đối với domain, user, calendar, drive và cấu hình cơ bản của Gmail. Cloudflare Zero Trust luôn áp dụng nguyên tắc cấp quyền tối thiểu cho các scope này.

Bước 6 — Xác nhận email quản trị và thêm DLP profile

Nhập chính xác địa chỉ email của tài khoản Google Workspace Administrator — email này phải khớp tuyệt đối với tài khoản admin thật, nếu không tích hợp sẽ không hoạt động.

Bước cuối (tuỳ chọn): chọn các DLP profile có sẵn như Credentials and Secrets, Financial Information, Health Information, Source Code… để CASB tự động quét toàn bộ file mới và file cũ tìm dữ liệu nhạy cảm. Lưu ý DLP chỉ quét file đã sửa đổi hoặc file mới sau khi profile được thêm — có thể bổ sung thêm profile sau này bất cứ lúc nào.

3️⃣ Advanced TCP Protection — Magic Transit

Công cụ kiểm tra TCP có trạng thái, dùng để phát hiện và giảm thiểu các cuộc tấn công TCP tinh vi kiểu out-of-state như randomized và spoofed ACK floods, SYN floods và SYN-ACK floods. Đặc điểm nổi bật là có thể theo dõi các kết nối TCP ngay cả khi chúng di chuyển giữa các trung tâm dữ liệu của Cloudflare, bảo vệ đồng thời cả tấn công nhắm vào một IP/port cụ thể lẫn tấn công rộng nhắm vào nhiều IP trong cùng một prefix.

Bước 1 — Chọn account và website

Đăng nhập dash.cloudflare.com, chọn đúng tài khoản và domain cần cấu hình.

Bước 2 — Vào Security → DDoS

Trang này hiển thị 2 mục chính: HTTP DDoS attack protection (ruleset tự động chặn HTTP floods, amplification, reflection attacks) và Network-layer and SSL/TLS DDoS attack protection. HTTP DDoS protection luôn được bật — bạn chỉ có thể tùy chỉnh hành vi bằng cách tạo override.

Bước 3 — Bấm “Deploy a DDoS override”

Tại mục HTTP DDoS attack protection, bấm nút Deploy a DDoS override ở góc phải để mở form tạo override mới.

Bước 4 — Đặt tên override

Nhập tên gợi nhớ vào Override name. Trang Configure override cũng hiển thị Override scope — mặc định là toàn bộ request đến zone hiện tại (“All incoming requests to your-domain.com”).

Bước 5 (Enterprise) — Điều chỉnh Override scope nếu cần

Với khách hàng Enterprise có Advanced DDoS Protection, có thể thu hẹp phạm vi áp dụng override thay vì áp dụng cho toàn zone. Bấm Edit scope và khai báo custom filter expression — tương tự cách viết biểu thức trong WAF Custom Rules — để chỉ định đúng nhóm request cần xử lý đặc biệt.

Bước 6 — Cấu hình Ruleset và Rule override

Phần cốt lõi của override, gồm 2 cấp độ có thể kết hợp trên cùng một cấu hình:

6.2 — Ghi đè từng rule cụ thể (Rule configuration)

Khi muốn tinh chỉnh riêng một số rule thay vì áp dụng đồng loạt, bấm Browse rules để mở danh sách toàn bộ rule trong ruleset. Có thể tìm kiếm theo từ khóa hoặc lọc theo Tags (ví dụ: botnets, unusual-requests, read-only, generic, advanced).

• Chọn từng rule và đổi Action hoặc Sensitivity riêng lẻ
• Tick nhiều rule rồi bấm Set action / Set sensitivity để cập nhật hàng loạt
• Bấm Select all X rules để áp dụng cho toàn bộ kết quả lọc
• Bấm Next để xem lại danh sách thay đổi trước khi lưu

Lưu ý: cấu hình theo tag hoặc rule riêng lẻ có độ ưu tiên cao hơn cấu hình ruleset tổng.

Bước 7 — Lưu lại cấu hình

Bấm Save để hoàn tất. Lưu ý: “Ruleset overrides will not affect read-only rules” — các rule có nhãn read-only trong danh sách sẽ không bị ảnh hưởng bởi cấu hình ghi đè này.