Gateway DNS filtering: lớp đầu tiên của Secure Web Gateway

TL;DR

Gateway DNS filtering là lớp đơn giản nhất của Cloudflare’s Secure Web Gateway (SWG): chặn phân giải domain độc hại hoặc không được phép trước khi client mở kết nối. Không cần giải mã, không cần cài agent ở tầng ứng dụng, không phá vỡ nhiều ứng dụng.

Ba chế độ triển khai chính:

DoH theo thiết bị (qua WARP): gắn identity, cho người dùng đi lại.
DNS location: resolver IP cố định trên internet, cho chi nhánh/wifi khách/mạng OT.
Resolver policy qua IPv4/IPv6: allowlist IP cũ, ít dùng.

Bài này đi qua:

4 lớp của Gateway và vị trí DNS trong đó.
Thứ tự đánh giá chính sách: rule nào thắng khi xung đột.
Categories (threat intelligence), custom lists, chính sách theo identity.
DoH theo thiết bị vs DNS location: khi nào dùng cái nào.
Ngoại lệ cho cập nhật OS, captive portal, DNS nội bộ.
Đường ống log: Gateway logs → Logpush → SIEM/R2.

Luận điểm chính:

DNS filtering là bước đầu tiên chi phí thấp, phạm vi rộng. Triển khai trước HTTP filtering. Chặn 60-80% phishing/malware C2 chỉ bằng bộ lọc category, không cần giải mã TLS. Nhưng đừng coi đây là bảo mật hoàn chỉnh, malware hiện đại dùng DNS over HTTPS trực tiếp tới resolver khác để vượt qua. Cần kết hợp chặn L4/L7 ở tầng Network/HTTP (Part 12).

Bài này là Part 11 của Cloudflare One Handbook, mở block Policy & Filtering (Part 11-13).

Dành cho ai

Kỹ sư bảo mật xây Secure Web Gateway từ đầu.
IT admin muốn chặn malware/phishing nhẹ nhàng thay cho OpenDNS/Umbrella.
Nhóm mạng đánh giá Cloudflare Gateway thay Zscaler ZIA/Netskope SWG.

Bạn nên đã đọc:

Part 3, Mental model 4 tầng (Client, Identity, Policy, Resource).
Part 9, WARP (client đưa DNS query đến Cloudflare).

Sau bài này bạn sẽ:

Hiểu Gateway DNS đặt ở đâu trong stack SWG.
Biết cấu hình chính sách theo category, custom list, identity.
Chọn đúng chế độ (DoH qua WARP vs DNS location).
Tránh cạm bẫy: cập nhật OS fail, captive portal, split DNS nội bộ.
Có đường ống gửi DNS logs sang SIEM.

Bài này không nói về gì

HTTP filtering + giải mã TLS: Part 12.
Network policy (L4, non-HTTP): Part 13.
DLP + CASB: block sau trong series.
1.1.1.1 consumer resolver: dù cùng hạ tầng, 1.1.1.1 bản consumer không có chính sách/logging.
Cloudflare for Families: DNS filtering cho gia đình, khác phạm vi enterprise.

Khái niệm

Gateway: Cloudflare’s Secure Web Gateway. 4 lớp: DNS, Network, HTTP, Browser Isolation.
DNS policy: rule cho phép/chặn dựa trên tên domain hoặc category.
DoH: DNS over HTTPS. WARP client dùng DoH để gửi query đến Gateway.
DNS location: tập hợp IP/dải IP mà Gateway biết là từ site của bạn. Query đến từ IP đó sẽ áp dụng chính sách.
Category: phân loại domain từ threat intel (malware, phishing, gambling, adult, v.v.).
Custom list: danh sách domain tự định nghĩa (allowlist/blocklist).
Identity: user identity từ IdP (qua WARP enrollment). Chính sách có thể dựa trên người dùng/group.
Block page: trang HTML trả về khi phân giải bị chặn (NXDOMAIN hoặc redirect).
Logpush: dịch vụ Cloudflare đẩy logs sang đích (R2, S3, Splunk, Sumo Logic, v.v.).

Gateway 4 lớp

Gateway SWG stack: DNS (Layer 1 thấp nhất) → Network L4 → HTTP L7 → Browser Isolation (Layer 4 cao nhất). Mỗi layer có đầu vào, loại chính sách, đầu ra, trường hợp sử dụng riêng.

Lớp 1: DNS

Đầu vào: DNS query (qua DoH hoặc resolver IP trực tiếp).
Chính sách: khớp domain, khớp category.
Đầu ra: allow, block (NXDOMAIN), safe-search redirect.
Trường hợp sử dụng: lớp phòng thủ đầu tiên. Chi phí thấp, chạy được cho mọi protocol (HTTP, SMTP, ứng dụng IP trực tiếp) vì hầu hết bắt đầu bằng DNS.

Lớp 2: Network (L4)

Đầu vào: kết nối L4 (TCP/UDP + IP + port).
Chính sách: IP, port, protocol, app (non-HTTP).
Đầu ra: allow, block, route.
Trường hợp sử dụng: traffic non-HTTP (SMTP, SSH, RDP), traffic thiết bị IoT, ứng dụng cloud đi vòng HTTP.

Lớp 3: HTTP (L7)

Đầu vào: HTTP/HTTPS request (sau khi giải mã TLS nếu bật).
Chính sách: URL, method, header, body (kèm DLP), loại file.
Đầu ra: allow, block, warn, isolate.
Trường hợp sử dụng: bộ lọc web chi tiết, DLP, CASB.

Lớp 4: Browser Isolation

Đầu vào: HTTP request khớp chính sách isolation.
Đầu ra: render trong browser từ xa ở CF edge, truyền pixel/DOM đến người dùng.
Trường hợp sử dụng: zero-day web threat, chặn click phishing, BYOD chỉ đọc.

Tại sao DNS đầu tiên

Rẻ: không giải mã, không kiểm tra payload.
Rộng: ứng dụng/protocol/endpoint nào cũng cần phân giải domain.
Sớm: chặn phân giải = chặn toàn bộ kết nối phía sau.
Khôi phục đơn giản: DNS là stateless, revert rule trong vài giây.

Nhưng DNS một mình không đủ:

Ứng dụng dùng IP trực tiếp (không DNS) sẽ đi vòng qua.
Malware dùng DoH độc lập (Google DoH, Cloudflare DoH public) sẽ đi vòng qua.
Phishing dùng domain hợp pháp (link Google Docs), DNS không thấy nội dung nguy hại.

Đó là lý do vẫn cần Network + HTTP ở bên trên.

Kiến trúc phân giải DNS qua Gateway

DNS query luồng: Client → DoH tunnel → Cloudflare edge → policy engine (identity + location + categories) → resolver → response (allow/block)

Luồng theo bước

Client gửi DNS query, qua DoH (TLS/443) nếu WARP được bật, hoặc UDP/53 trực tiếp nếu ở chế độ DNS location.
Cloudflare edge nhận query.
Policy engine đánh giá:
- Identity (ai): từ WARP session hoặc null nếu DNS location.
- Location (ở đâu): IP location hoặc WARP client location.
- Khớp domain/category: đối chiếu threat intel + custom list.
Quyết định: allow sẽ chuyển tiếp resolver; block sẽ trả NXDOMAIN hoặc redirect IP.
Nếu allow: resolver recursive của Cloudflare (1.1.1.1 backbone) phân giải upstream.
Phản hồi trả về client.
Log query + quyết định vào kho Gateway logs.

Tốc độ

Đánh giá chính sách ở edge, cùng DC với resolver.
Độ trễ thêm thường < 5ms so với resolver thường.
Người dùng không cảm nhận được khác biệt so với 1.1.1.1 trực tiếp.

Mã hóa

WARP dùng DoH (HTTPS), mã hóa từ client đến CF.
Từ resolver đến upstream: CF dùng DoT (DNS over TLS) nếu upstream hỗ trợ.

Thành phần chính

Component	Purpose	Plan
WARP client	Gửi DoH query lên Gateway	Free+
DNS locations	Ánh xạ public IP → tenant, áp dụng chính sách	Standard+
Categories	100+ nhóm từ Cloudflare Radar + 3rd-party feeds	Standard+
Custom lists	Danh sách allow/block tự định nghĩa, hỗ trợ bulk import	Standard+
Block page	Trang HTML hiển thị khi block, tuỳ biến được	Standard+
Identity provider	Gắn chính sách với user/group từ IdP	Advanced
Logs	Mỗi query + quyết định, lưu 30 ngày (mở rộng được)	Standard+
Logpush	Stream logs đến R2/SIEM/object store	Advanced

Thứ tự đánh giá policy

Policy evaluation: input query → list 1 allow → list 2 block → security categories → content categories → default action. First match wins.

Thứ tự quan trọng

Cloudflare Gateway đánh giá chính sách theo thứ tự danh sách. First match wins, không phải theo độ ưu tiên.

Thứ tự khuyến nghị:

Trust list (allow), domain bạn PHẢI KHÔNG chặn dù category gì (SaaS đối tác, payroll, update server).
Block list tường minh, domain chắc chắn chặn (chính sách nội bộ, đối thủ nếu cần).
Security categories, Malware, Phishing, Command & Control, Spam, Suspicious, Cryptomining.
Content categories (theo chính sách tổ chức), Adult, Gambling, Weapons, Streaming, v.v.
Rule theo identity, ví dụ nhóm nhân sự thuê ngoài không được truy cập dev tools.
Mặc định, cho phép tất cả phần còn lại.

Cạm bẫy: sai thứ tự dẫn tới chặn nhầm

Ví dụ: bạn muốn allow salesforce.com cho toàn bộ. Nhưng rule 1 là “block Business category” và Salesforce rơi vào Business. Nếu không đặt danh sách allow trước, Salesforce bị chặn.

Toán tử identity + location

user.email in ["contractor@..."]: match người dùng cụ thể.
user.groups in ["Contractor"]: match group từ IdP.
location in ["HQ", "Branch-A"]: match DNS location.
Toán tử kết hợp: (user.groups in ["Engineering"]) AND (dns.query matches "*.internal.prod.*"): kỹ sư truy cập prod nội bộ.

DoH theo thiết bị vs DNS location

Two modes: WARP DoH (left, per device, user identity) vs DNS location (right, per site, IP-based). Comparison axes: enrollment, identity binding, bypass resistance, deploy target.

Chế độ 1: DoH theo thiết bị (qua WARP)

Thiết lập:

Thiết bị người dùng cài WARP client (Part 9).
Client gửi DoH query (HTTPS/443) đến 1.1.1.1 với DoH endpoint riêng cho tenant.
Chính sách áp dụng theo user identity.

Ưu:

Gắn identity, chính sách chi tiết theo người dùng/group.
Theo người dùng: WFH, café, mobile.
Khó đi vòng qua (resolver OS chuyển hướng lên WARP).

Nhược:

Cần enrollment mỗi thiết bị.
Không phủ thiết bị không chạy WARP (IoT, thiết bị cũ, khách).

Dùng cho: knowledge worker, kỹ sư, nhóm sales.

Chế độ 2: DNS location

Thiết lập:

Cấu hình public IP/dải IP của site trong Gateway thành “DNS location”.
Router site trỏ DNS resolver về Cloudflare 1.1.1.1 hoặc IP Gateway chuyên dụng.
Chính sách áp dụng theo tên location.

Ưu:

Không cần triển khai client.
Bao phủ mọi thiết bị trên mạng (IoT, khách, máy in).
Đơn giản: chỉ cần đổi thiết lập DNS trên DHCP.

Nhược:

Không có identity (chỉ biết “query từ HQ”).
Người dùng rời site thì chính sách không theo.
Dễ đi vòng qua nếu người dùng set DNS thủ công (mobile hotspot, VPN).

Dùng cho: chi nhánh, wifi khách, mạng OT, kiosk.

Chế độ 3: Kết hợp (khuyến nghị)

Thực tế: dùng cả hai.

Laptop/phone người dùng qua WARP (gắn identity).
Desktop/văn phòng/khách/IoT trên mạng qua DNS location.
Chính sách chồng lấn: người dùng rời site vẫn có WARP; người dùng ở site có cả hai (WARP đè lên).

Cloudflare Gateway xử lý thứ tự ưu tiên: query WARP dùng user identity; DNS location chỉ khi không có WARP session.

Category và custom list

Category dựng sẵn

Cloudflare tuyển chọn 100+ categories. Khuyến nghị CHẶN:

Security: high confidence: Malware, Phishing, Command and Control, Cryptomining, Spyware, DGA, DNS Tunneling.
Security: medium: Suspicious, Spam, Newly Registered Domain (NRD < 30 days).
Adult: Adult Themes, Gore, Violence.
Cybersecurity threat intel feeds (tight threat intel, high confidence).

Khuyến nghị CHO PHÉP (bất kể category):

Một số “Proxy/Anonymizer” nếu nhân viên cần test.
“Questionable Legality” nếu quốc gia vận hành hợp pháp, rà soát từng trường hợp.
Ad tracking: nhạy cảm, có thể phá site quan trọng. Chặn tracking ở lớp Network/HTTP thay vì DNS (nội dung quảng cáo vẫn hiển thị nhưng không bị theo dõi).

Danh sách tuỳ chỉnh

Format: CSV, một domain mỗi dòng. Hỗ trợ:

Khớp chính xác: malicious.example.com
Wildcard: *.malicious.example.com
Root + subdomain (khớp cả tên gốc lẫn các subdomain tuỳ cấu hình): example.com (matches *.example.com tùy config).

Tự động đồng bộ:

Nền tảng threat intel MISP/OpenCTI, qua script, gọi Cloudflare API /accounts/{id}/gateway/lists/{id}/items.
Lịch hàng giờ: IoC mới được chặn trong 60 phút.

Ví dụ API

# Add IoC domain to blocklist
curl -X PATCH \
  "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/gateway/lists/${LIST_ID}" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "append": [
      {"value": "phish-campaign-2026.example.net"},
      {"value": "c2-cluster.badactor.io"}
    ]
  }'

Cấu hình ngoại lệ: cái gì không chặn

Bộ lọc DNS có thể gây lỗi bất ngờ nếu không loại trừ các trường hợp sau.

Cập nhật OS

*.windowsupdate.com, *.microsoft.com: Windows Update.
*.apple.com: cập nhật macOS/iOS.
*.ubuntu.com: Ubuntu.
*.googleapis.com: Android.

Nếu chặn những domain này, endpoint sẽ không nhận patch, vấn đề bảo mật còn tệ hơn DNS filter ban đầu.

Captive portal

Wifi khách sạn/sân bay chặn bắt DNS để chuyển hướng. WARP client phát hiện captive portal rồi đi vòng tạm.

Cài đặt: Gateway → WARP policy → “Allow captive portal”. Tự động.

Nếu ở chế độ DNS location: người dùng tự tắt DNS override khi kết nối captive portal. Ghi rõ cạm bẫy này trong runbook người dùng.

DNS nội bộ / split DNS

Domain nội bộ công ty: *.prod.int.
Không thể phân giải qua public (không tồn tại trong DNS global).

Giải pháp:

Resolver policy trong Gateway: domain nội bộ chuyển tiếp tới resolver nội bộ qua Magic WAN/Tunnel.
Local resolver, cấu hình endpoint dự phòng về DNS local cho domain nội bộ. WARP client hỗ trợ cấu hình split DNS.

SaaS với domain xoay

Office 365 dùng nhiều subdomain xoay. Chặn domain thuộc Microsoft sẽ phá Outlook/Teams. Dùng danh sách IP+domain công bố của Microsoft làm tham chiếu cho phép.

Cấu hình tham khảo

Policy pack: khởi điểm

# Policy 1 — TRUST: allow critical SaaS regardless of category
- name: "Trust critical SaaS"
  action: allow
  expression: |
    any(dns.content.category[*].name in {
      "Microsoft Office 365", "Google Workspace", "Salesforce"
    })

# Policy 2 — BLOCK: explicit bad
- name: "Block internal bad domain list"
  action: block
  expression: |
    any(dns.resolved_ips.domains[*] in $BAD_LIST)

# Policy 3 — SECURITY: block high-confidence threat
- name: "Block security threats"
  action: block
  expression: |
    any(dns.content.category[*].id in {
      80,  # Command and Control & Botnet
      117, # Malware
      131, # Phishing
      153, # Spyware
      83   # Cryptomining
    })

# Policy 4 — SECURITY: block newly registered + DGA
- name: "Block NRD and DGA"
  action: block
  expression: |
    any(dns.content.category[*].id in {175, 176})  # DNS Tunneling, DGA
  # Custom block page: "This domain is newly registered and may be unsafe."

# Policy 5 — CONTENT: block adult for all except specific
- name: "Block adult — except Security team"
  action: block
  expression: |
    any(dns.content.category[*].id in {2, 9}) # Adult, Gambling
    and not (identity.email_domain == "security-research.corp")

# Policy 6 — DEFAULT
- name: "Default allow"
  action: allow
  expression: "true"

DNS location (branch HQ)

name: HQ-Hanoi
networks:
  - 203.0.113.0/24
  - 198.51.100.0/24
# Optional: dedicated resolver IP
dedicated_resolvers:
  - 172.64.36.1
policies_apply:
  - Trust critical SaaS
  - Block security threats
  - Block NRD and DGA
  # skip Identity-bound policy

Block page: redirect vs NXDOMAIN

NXDOMAIN: app phía client báo lỗi chung chung “can’t resolve host”. Gọn nhưng người dùng không biết tại sao.
Redirect IP: CF trả về IP của block page. Browser hiện trang giải thích + hướng dẫn yêu cầu ngoại lệ.

Khuyến nghị redirect cho người dùng cuối, NXDOMAIN cho headless/API.

Cân nhắc bảo mật

Việc CF đảm nhận

Cập nhật threat intel feed (category): hàng giờ.
Hạ tầng DNS resolver (anycast, được bảo vệ DDoS).
DoH endpoint TLS cert, xoay khóa.
Cô lập đánh giá chính sách (theo tenant).

Việc bạn vẫn phải lo

Đúng chính sách: thứ tự rule, phạm vi phủ, quản lý ngoại lệ.
Retention log & SIEM: mặc định chỉ 30 ngày, cần Logpush cho dài hạn.
Tính toàn vẹn identity: IdP bị compromise = chính sách bị compromise. Bảo vệ tài khoản admin IdP.
Vệ sinh custom list: IoC cũ phình list. Tự động dọn > 90 ngày.
Giáo dục người dùng: khi họ thấy block page, biết cách yêu cầu ngoại lệ qua helpdesk chứ không tự tìm cách đi vòng qua.

Cân nhắc chống bypass

Attacker hiện đại biết về bộ lọc DNS:

DoH trực tiếp: malware gửi DNS query tới 1.1.1.1 hoặc dns.google HTTPS trực tiếp. Chặn resolver DoH ở Network policy (Part 13). Chỉ allowlist DoH endpoint của WARP.
IP cứng: C2 dùng IP cố định, không DNS. Chặn IP ở Network policy + threat intel cho dải IP.
IP-over-DNS (DNS tunneling): exfil qua DNS. Chặn category “DNS Tunneling” + phát hiện bất thường (độ dài query > ngưỡng).
ESNI/ECH: mức DNS không thấy SNI, cần giải mã ở tầng HTTP inspection.

Ánh xạ compliance

ISO 27001: A.8.23 Web filtering.
NIST CSF: PR.DS-5, DE.CM-1 (continuous monitoring network).
PCI DSS 4.0: 1.4.4 (traffic restriction), 10.4 (audit log).
CIS: 9.3 (application layer filtering), 13.3 (monitor URL traffic).

Vận hành và giám sát

Chỉ số

Tổng queries/s: baseline, cảnh báo nếu tụt đột ngột (có thể resolver gặp vấn đề).
Tỉ lệ chặn: 2-5% là bình thường, tăng vọt = chiến dịch mới hoặc rule sai cấu hình.
Số domain duy nhất bị chặn/ngày: theo dõi xu hướng.
Top category bị chặn: bức tranh toàn cảnh threat.
Top người dùng bị chặn (có identity): ứng viên đào tạo hoặc nạn nhân bị compromise.

Cảnh báo

Tỉ lệ chặn > 10% so với baseline trong 1 giờ, pager (có thể bùng phát hoặc cấu hình sai).
Category Malware/C2 chặn cùng một người dùng 3x/giờ, cảnh báo SOC (có thể đang bị compromise).
Tỉ lệ lỗi resolver Gateway > 1%, mở ticket CF support.

Đường ống log

DNS query logs luồng: Gateway → logs store (30d hot) → Logpush → R2 / S3 / Splunk / SIEM for long-term retention and correlation

Các trường log quan trọng

{
  "Timestamp": "2026-05-12T09:15:23Z",
  "UserID": "u_xyz",
  "Email": "alice@company.com",
  "DeviceID": "d_abc",
  "DNSQuestion": "phish.example.com",
  "DNSQueryType": "A",
  "Location": "HQ-Hanoi",
  "Action": "block",
  "PolicyID": "p_sec_threats",
  "Categories": ["Phishing", "Newly Registered"],
  "ResolverDecision": "NXDOMAIN"
}

Thiết lập Logpush

# Create Logpush job to R2
curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/logpush/jobs" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "name": "gateway-dns-to-r2",
    "dataset": "gateway_dns",
    "destination_conf": "r2://gateway-logs/dns/{DATE}?account-id=${ACCOUNT_ID}&access-key-id=${R2_KEY}&secret-access-key=${R2_SECRET}",
    "output_options": {
      "output_type": "ndjson",
      "timestamp_format": "rfc3339"
    }
  }'

Chiến lược lưu trữ

Hot (CF native): 30 ngày, truy vấn trong dashboard.
Warm (R2/S3): 1 năm, truy vấn qua Athena/BigQuery.
Cold (archive): 7 năm, compliance.

Truy nguyên thường gặp

”Người dùng báo site không tải”: rule chặn nhầm

Lấy domain + timestamp từ người dùng.
Gateway → Logs → DNS → lọc theo email người dùng + khoảng thời gian.
Xem log: bản ghi có Action: block, PolicyID: <xxx>, Categories: [...].
Kiểm tra rule, xác nhận phân loại category có đúng không (CF có thể phân loại sai, báo cho CF).
Sửa: thêm domain vào danh sách allow trước rule security block.

”Cập nhật OS fail”

Log endpoint (Windows Update, apt, brew), lỗi “cannot resolve”.
Gateway DNS logs, lọc host (windowsupdate.com, v.v.).
Có bản ghi block, sửa: thêm category “Software Updates” vào allow trước rule Security.

”Độ trễ DNS tăng vọt”

Kiểm tra baseline: bình thường 10-30ms phân giải.
Trang Cloudflare Status, có sự cố không?
Phía endpoint: dig +stats phishtest.com, đo.
Nếu chỉ 1 khu vực: PoP có vấn đề, liên hệ CF support.

”WARP không chuyển hướng DNS”

Kiểm tra: warp-cli status: phải là Connected.
Kiểm tra: DoH endpoint phân giải: dig @1.1.1.1 +tls phishtest.com, nếu Gateway chặn phải fail.
DNS dự phòng mức OS: một số cấu hình Windows đi vòng qua DoH khi Wi-Fi quick-check. Sửa: WARP profile “Override DNS”, áp dụng.

”Block page không hiển thị, chỉ lỗi kết nối”

Kiểu hành động block: kiểm tra dùng “Block” (NXDOMAIN) vs “Safe Search” (redirect).
Browser hiện đại bật DoH sẽ đi vòng qua resolver cục bộ, không thấy redirect IP. Giải pháp: tắt DoH mức browser hoặc cấu hình WARP override.

”Log không hiện trong dashboard”

Có độ trễ 1-3 phút trước khi log render.
Kiểm tra plan account: Free plan không có DNS log chi tiết.
Trạng thái Logpush job: GET /accounts/{id}/logpush/jobs: status “active” và last_complete gần đây.

Đánh đổi và quyết định thiết kế

Quyết định	Phương án A	Phương án B	Khuyến nghị
Chế độ triển khai	Chỉ WARP DoH	Chỉ DNS location	Kết hợp, WARP cho người dùng, location cho site. Không either-or.
Độ sâu category	Chặn càng nhiều càng tốt	Chỉ chặn tối thiểu (security)	Bắt đầu tối thiểu, security categories. Category nội dung theo dõi 2 tuần trước khi chặn. False positive cao.
Kiểu phản hồi khi chặn	NXDOMAIN	Redirect sang block page	Redirect cho người dùng cuối (giáo dục). NXDOMAIN cho automation/API/server.
Nguồn custom list	Thủ công	Tự động threat intel	Tự động bắt buộc ở quy mô. Thủ công chỉ dùng cho ngoại lệ.
Lưu trữ	30 ngày (native)	Logpush 1+ năm	Logpush nếu cần compliance/forensic. R2 rẻ, dùng R2 thay S3.
Áp dụng DoH endpoint	Mềm (người dùng có thể tắt)	Cứng (MDM áp đặt)	Cứng cho thiết bị công ty. Mềm cho BYOD.
Split DNS nội bộ	Chỉ Gateway public	Conditional forwarder	Conditional forwarder cho TLD `.internal`, `.corp`. Gateway public cho phần còn lại.

Playbook chuyển đổi: từ OpenDNS / Umbrella / Infoblox

Giai đoạn 1: Rà soát hiện tại (1-2 tuần)

Xuất chính sách DNS hiện có từ hệ thống cũ.
Ánh xạ tên category (OpenDNS vs Cloudflare: không 1:1).
Xác định nguồn custom list (đăng ký threat intel).
Đo baseline tỉ lệ chặn hiện tại.

Giai đoạn 2: Shadow mode (2-4 tuần)

Cấu hình Cloudflare Gateway song song với hệ thống cũ.
WARP client trỏ DoH về Cloudflare; hệ thống cũ vẫn chạy.
Log mọi thứ, chưa chặn. So sánh: cái nào CF chặn nhưng hệ thống cũ không, và ngược lại.
Lấp khoảng trống: thêm rule cho trường hợp CF bỏ lọt.

Giai đoạn 3: Cutover theo site/group (4-8 tuần)

Bật chặn ở 1 group (ví dụ nhóm IT) trước.
Giám sát 1 tuần, sửa vấn đề.
Mở rộng từng group.

Giai đoạn 4: Gỡ hệ thống cũ

Hủy đăng ký hệ thống cũ (tiết kiệm chi phí).
Lưu trữ log hệ thống cũ sang R2.

Danh sách kiểm tra: trước khi production Gateway DNS

Phạm vi & chính sách:

DNS location cấu hình cho mọi site.
WARP enrollment cho thiết bị người dùng.
Rà soát thứ tự chính sách (Trust → Block → Security → Content → Identity → Default).
Trust list có: Microsoft, Google, domain cập nhật của Apple, SaaS nghiệp vụ quan trọng.
Chặn security category: Malware, Phishing, C2, Cryptomining, DGA, DNS Tunneling.
Quy trình xử lý ngoại lệ đã ghi lại.

Identity & IdP:

IdP đã kết nối (Part 5).
Đồng bộ group người dùng (Part 7).
Rule gắn identity đã test theo từng group.

Ngoại lệ:

Hành vi captive portal đã test (laptop vào wifi khách sạn).
Resolver split DNS nội bộ đã cấu hình.
Domain cập nhật OS đã đưa vào allowlist.

Giám sát:

Bật Logpush sang R2/SIEM.
Cảnh báo khi tỉ lệ chặn tăng vọt.
Cảnh báo category malware mỗi người dùng > N/giờ.
Dashboard top category + người dùng bị chặn nhiều nhất.
Lưu trữ ≥ 1 năm.

Vận hành:

Runbook: “người dùng báo bị chặn”, các bước xác nhận + bỏ chặn.
Runbook: “dính category malware”, các bước triage SOC.
Block page tuỳ chỉnh với thương hiệu công ty + liên hệ helpdesk.
Test: luồng yêu cầu ngoại lệ đầu cuối.

Bài học thực tế

Bắt đầu bằng category chỉ về bảo mật. Chặn content category (Social Media, Streaming) từ ngày đầu sẽ tạo bão helpdesk. Mở rộng rule content sau 1-2 tháng khi rule security đã ổn định.
Allowlist trước blocklist. Lỗi thứ tự rule: security block áp dụng trước trust list khiến Salesforce/Office365 bị chặn ngẫu nhiên khi category bị phân loại sai.
Giám sát sát tỉ lệ chặn tuần đầu. Tăng 10x baseline = rule quá mạnh tay. Tụt về 0 = rule không khớp (resolver cấu hình sai).
NRD (Newly Registered Domain) false positive cao. Nhưng NRD là tín hiệu mạnh cho phishing. Đánh đổi: chặn + allowlist ngoại lệ cho đối tác mới.
Đi vòng qua WARP bằng DoH của browser rất phổ biến. Firefox/Edge mặc định bật DoH. Phải đè qua GPO/MDM cho thiết bị công ty.
Đừng log mọi thứ mãi mãi. DNS logs khổng lồ (10M-100M/ngày enterprise). Lấy mẫu 10% nếu không phải trường hợp compliance, giữ 100% cho người dùng compliance-critical.
Phân loại category không hoàn hảo. CF đôi khi phân loại sai; báo cáo false positive qua dashboard. Cloudflare sửa trong 24-48h.

Kết luận

DNS filtering là lớp rẻ nhất, phạm vi cao nhất, là điểm khởi đầu tốt nhất của Secure Web Gateway. Triển khai trước khi đụng đến giải mã HTTP. Mỗi lần chặn đúng tiết kiệm 1 sự cố; mỗi lần chặn sai tạo 1 ticket helpdesk, cân bằng bằng thứ tự rule + quy trình ngoại lệ.

Nếu phải nhớ một câu:

DNS filtering là bước đầu, không phải bước cuối. Chặn 60-80% threat phổ thông bằng category, nhưng phải kết hợp bộ lọc Network/HTTP để bịt đường vòng DoH và C2 dùng IP trực tiếp.

Trong Part 12 tiếp tục block Policy & Filtering với HTTP filtering + giải mã TLS: khi nào nên giải mã, cách triển khai CA cert trên endpoint, mẫu DLP/CASB, và các cân nhắc pháp lý/quyền riêng tư.

Tài liệu tham khảo

Trong series này:

← Part 10: Magic WAN, BGP peering và multi-cloud
Tiếp theo → Part 12: Gateway HTTP filtering và TLS decryption
Xem toàn bộ: Series Cloudflare One Handbook