Network policy L4: chặn non-HTTP, DoH bypass và app rule

TL;DR

Network policy là lớp 2 của Gateway, bộ lọc L4 giữa DNS (Part 11) và HTTP (Part 12). Kiểm tra kết nối TCP/UDP, không giải mã, không kiểm tra nội dung. Vai trò:

• Chặn lưu lượng non-HTTP: SSH, RDP, SMTP, MySQL, port tuỳ chỉnh.
• Ngăn DoH bypass: chặn DNS-over-HTTPS tới resolver khác (Google, Quad9) để DNS policy Part 11 không bị bỏ qua.
• Rule theo app: chặn/cho phép theo app (Dropbox, Bittorrent), Gateway có danh sách ánh xạ app → IP/port.
• Kết nối IP trực tiếp: malware dùng IP cố định không DNS → L4 chặn theo IP/CIDR.
• Bộ lọc Country/ASN: chặn theo vị trí địa lý.

Bài này đi qua:

• Lớp Network vs DNS vs HTTP: rule thuộc về lớp nào.
• DoH bypass là vấn đề lớn: cách phát hiện + chặn.
• Kiểm tra SNI: Gateway thấy SNI ngay cả khi không giải mã, dùng được cho rule.
• Rule theo app vs rule IP/port thô.
• Tunnel WARP vs DNS location: áp dụng khác nhau ở L4.
• Logs và tích hợp SIEM.

Luận điểm chính:

Lớp Network là chất kết dính giữa DNS và HTTP. Nó khép kẽ hở DoH, xử lý non-HTTP, và cung cấp phương án dự phòng khi giải mã HTTP bị ngoại lệ. Nếu bạn không cấu hình rule L4, kẻ tấn công sẽ vượt qua bộ lọc DNS bằng DoH/IP trực tiếp, hoàn toàn vô hình với Gateway.

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

---

Dành cho ai

• Kỹ sư bảo mật đã có rule DNS + HTTP, cần khép các kẽ hở còn lại.
• SOC analyst điều tra bất thường ở lớp L4.
• Kỹ sư nền tảng thiết lập kiểm soát egress cho khối lượng công việc cloud.

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

• Part 11, DNS filtering (lớp dưới).
• Part 12, HTTP filtering + TLS decrypt (lớp trên).
• Part 9, WARP: điểm áp dụng cho lưu lượng.

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

• Viết được rule chặn DoH bypass, lưu lượng non-HTTP.
• Hiểu SNI inspection vs giải mã đầy đủ: khi nào đủ.
• Cấu hình rule theo app cho shadow IT.
• Tích hợp log L4 vào SIEM với các trường hữu ích.
• Có danh sách kiểm tra production + lộ trình siết chặt.

---

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

• Magic WAN Magic Firewall: Part 10, khác ngữ cảnh (lưu lượng site-to-site).
• Gateway API connector cho egress cloud: chỉ nhắc qua.
• Browser Isolation: đặc thù L7.
• Chi tiết chế độ WARP: Part 9.
• Email security: khác sản phẩm (Area 1).

---

Khái niệm

• Network policy: rule L4 của Gateway: IP, port, giao thức, SNI, app, quốc gia.
• SNI (Server Name Indication): hostname trong TLS ClientHello, dạng rõ. Gateway thấy được không cần giải mã.
• DoH (DNS over HTTPS): DNS query qua HTTPS, bỏ qua bộ lọc DNS thường. Port 443 trên resolver (Google dns.google, Quad9 dns.quad9.net).
• DoT (DNS over TLS): DNS over TLS, port 853. Ít phổ biến nhưng tương tự.
• App (application): ánh xạ do Gateway duy trì: tên app → domain + dải IP. Ví dụ “Dropbox” = *.dropbox.com + danh sách IP.
• Egress: lưu lượng từ mạng nội bộ (WARP/Magic WAN) ra internet.
• ASN (Autonomous System Number): định danh mạng cho BGP; Gateway lọc theo ASN (chặn nguồn Nga, Iran, v.v.).
• Geo-IP: ánh xạ IP → quốc gia từ Cloudflare Radar.

---

3 tầng định vị: Network nằm ở đâu

Ma trận threat coverage

Threat	DNS	Network	HTTP
Domain-based malware	✓	✓ (SNI)	✓
IP-direct C2	✗	✓	n/a
DoH bypass	✗	✓	n/a
Non-HTTP protocol	✗	✓	✗
URL path exfil	✗	✗	✓
DLP body	✗	✗	✓
Country block	limited	✓	✓
Tor / VPN to bypass	partial	✓ (IP)	n/a
Cert-pinned app threat	✗	✓ (SNI)	✗

Network lấp kẽ hở: IP trực tiếp, DoH, non-HTTP, Tor.

SNI: giá trị thực của kiểm tra L4

SNI là hostname dạng rõ trong TLS handshake. Gateway thấy SNI kể cả không giải mã:

ClientHello → SNI: c2.badactor.io
           → Gateway match SNI against policy
           → Block before TLS completes

Rule SNI có ~70% giá trị của giải mã đầy đủ mà không có chi phí về quyền riêng tư/pháp lý. Nếu quy định tuân thủ không cho giải mã, rule SNI vẫn bắt được mối đe dọa theo domain.

Cạm bẫy: ECH (Encrypted ClientHello) mã hóa SNI. Trình duyệt/client hỗ trợ ECH sẽ ẩn SNI. Gateway cần phát hiện và chặn ECH nếu muốn rule theo SNI hoạt động.

---

DoH bypass: rủi ro lớn

Vấn đề

Bộ lọc DNS (Part 11) chặn malicious.com ở lớp DNS. Nhưng:

1. Malware không dùng resolver hệ thống.
2. Malware gửi request DoH tới dns.google/dns-query port 443.
3. Bộ lọc DNS của Gateway không thấy vì không phải DNS thường (UDP/53).
4. Malware phân giải domain độc hại → kết nối → exfiltrate dữ liệu.

Bộ lọc DNS bị bypass hoàn toàn.

Ai dùng DoH

• Trình duyệt hiện đại (Firefox, Edge, Chrome) có sẵn DoH.
• Malware nâng cao (từ 2022 trở đi) dùng DoH để né bộ lọc DNS.
• Người dùng rành kỹ thuật tự cấu hình resolver OS.

Giải pháp L4

Chặn các host đích DoH:

name: "Block third-party DoH resolver"
action: block
condition: |
  net.dns.over_https
  or net.sni in {
    "dns.google",
    "dns.quad9.net",
    "cloudflare-dns.com",
    "mozilla.cloudflare-dns.com",
    "doh.opendns.com",
    "dns.nextdns.io",
    "dns.adguard.com"
  }
  or net.host in {
    "8.8.8.8", "8.8.4.4",
    "9.9.9.9", "149.112.112.112",
    "1.1.1.1", "1.0.0.1",
    "208.67.222.222"
  }

Chỉ cho phép endpoint DoH riêng của tenant (CF WARP tạo URL tenant → cho phép URL đó):

name: "Allow tenant DoH only"
action: allow
condition: |
  net.dns.over_https
  and net.sni == "[tenant-id].cloudflareaccess.com"

Chặn DoT (DNS over TLS port 853)

name: "Block DoT"
action: block
condition: net.port == 853

Phát hiện: nỗ lực DoH trong logs

Gateway logs filter Action: block, Policy: doh_block:

• IP nguồn / người dùng.
• SNI / IP đích.
• Thời gian.

Tăng đột biến = điều tra endpoint bị xâm nhập hoặc người dùng tự cấu hình.

---

Rule theo SNI: ví dụ thực tế

Chặn SaaS shadow IT ở tầng SNI

name: "Block personal cloud storage"
action: block
condition: |
  net.sni in {
    "*.dropbox.com", "*.box.com",
    "*.drive.google.com",
    "www.icloud.com",
    "mega.nz", "*.mega.nz"
  }
# Exception: decrypt policy allow corporate Dropbox tenant via HTTP layer

Chặn sàn crypto (chính sách nội bộ)

name: "Block crypto exchanges"
action: block
condition: |
  net.sni in {
    "*.binance.com", "*.coinbase.com",
    "*.kraken.com", "*.kucoin.com"
  }

Chỉ cho phép dịch vụ AI đã được công ty duyệt

name: "Default block AI"
action: block
condition: |
  net.sni in {
    "*.openai.com", "*.anthropic.com",
    "gemini.google.com", "*.copilot.microsoft.com"
  }
  and not (identity.groups in {"AI-approved"})

---

Rule theo app: lối tắt cho app phổ biến

Vì sao cần rule theo app

Các app shadow IT có nhiều domain, CDN, dải IP. Duy trì danh sách thủ công → nhanh lỗi thời.

Cloudflare Gateway có app catalog: Tor, Bittorrent, Dropbox, WhatsApp, v.v. Mỗi app là một nhóm domain + IP + mẫu SNI.

Ví dụ rule

name: "Block Tor network"
action: block
condition: net.app == "Tor"
# Gateway translate to: Tor entry node IPs + Tor domains + Tor bridge relay
# Auto-updated by CF threat intel

name: "Block torrent"
action: block
condition: net.app in {"Bittorrent", "eDonkey", "Gnutella"}

name: "Allow corporate Dropbox tenant, block personal"
# HTTP layer handles tenant check
# Network layer: allow Dropbox app base: HTTP rule does fine-grain
action: allow
condition: net.app == "Dropbox"

Giới hạn

• Định nghĩa app do CF duy trì: kẽ hở cho app mới (các bản ra gần đây có thể chưa có entry).
• Phương án dự phòng: chuyển sang rule SNI/domain thủ công nếu app chưa có trong catalog.

---

Rule cho lưu lượng non-HTTP

Chặn SSH outbound trừ host đã duyệt

name: "Block outbound SSH to non-corporate"
action: block
condition: |
  net.port == 22
  and not (net.host in $corporate_ssh_hosts)
# $corporate_ssh_hosts = list of approved jumpbox, bastion, git.internal

Chặn RDP outbound

name: "Block outbound RDP"
action: block
condition: |
  net.port == 3389
  and net.protocol == "TCP"
# RDP to internet = likely lateral from compromised endpoint
# Corporate RDP should go through ZTNA/Cloudflare Tunnel, not direct outbound

Chặn SMTP trực tiếp (chống spam)

name: "Block direct SMTP"
action: block
condition: |
  net.port in {25, 465, 587}
  and not (net.host in $approved_email_gateway)
# Only approved gateway (e.g. Google Workspace MX) can send mail

Chặn kết nối DB trực tiếp

name: "Block direct database connection to internet"
action: block
condition: |
  net.port in {3306, 5432, 1433, 27017, 6379}
  and net.direction == "outbound"
# MySQL, PostgreSQL, MSSQL, MongoDB, Redis
# Internal DB access should go through Tunnel/Magic WAN

Chặn Tor

name: "Block Tor"
action: block
condition: |
  net.app == "Tor"
  or net.port in {9001, 9030}
# Tor ORPort + DirPort

---

Rule theo quốc gia / ASN

Chặn lưu lượng tới quốc gia bị cấm vận

name: "Block sanctioned country destinations"
action: block
condition: |
  net.geo.country in {"IR", "KP", "CU", "SY"}
# Compliance: OFAC list. Review quarterly.

Chỉ cho phép quốc gia cụ thể cho truy cập admin

name: "Admin tools only from office countries"
action: block
condition: |
  identity.groups in {"Admin"}
  and net.sni matches "*.admin.internal"
  and not (net.geo.country in {"VN", "SG", "US"})

---

WARP vs DNS location: L4 enforcement

Mô hình áp dụng khác nhau

WARP client:

• Tunnel toàn bộ lưu lượng mạng (split tunnel trừ danh sách) đến CF.
• Gateway thấy MỌI kết nối TCP/UDP → rule L4 áp dụng đầy đủ.
• Gắn identity → rule L4 theo từng người dùng.

DNS location:

• Chỉ DNS query được định tuyến tới CF.
• Lưu lượng non-DNS đi trực tiếp internet: CF không thấy.
• Rule L4 không áp dụng cho chế độ location.
• Kẽ hở: malware ở site vẫn có thể exfiltrate vì chỉ DNS được lọc.

Giải pháp cho chế độ site

Phương án 1: Magic WAN, site tunnel lên CF, kiểm tra toàn bộ lưu lượng → Magic Firewall (không phải Gateway), Part 10.

Phương án 2: Proxy endpoint trên site, định tuyến HTTP tới CF. Proxy tường minh không phải trong suốt → khối lượng công việc phải biết URL proxy.

Phương án 3: Nâng cấp lên WARP trên từng thiết bị, độ chi tiết tốt nhất.

Thực tế: doanh nghiệp kết hợp WARP (người dùng) + Magic WAN (site) + DNS location (khách/IoT). Độ phủ L4 đầy đủ cho WARP + Magic WAN; khách/IoT chỉ có DNS (chấp nhận được vì không xử lý dữ liệu nhạy cảm).

---

Cấu hình tham khảo: network policy khởi điểm

# Policy 1: allow tenant infrastructure (whitelist first)
- name: "Allow corporate tenant DoH"
  action: allow
  condition: |
    net.sni == "[tenant].cloudflareaccess.com"

# Policy 2: allow approved outbound
- name: "Allow approved outbound protocols"
  action: allow
  condition: |
    net.port in {80, 443, 53}
    or net.host in $approved_corp_hosts

# Policy 3: block DoH bypass
- name: "Block third-party DoH/DoT resolver"
  action: block
  condition: |
    net.dns.over_https
    or net.port == 853
    or net.sni matches "*.dns.google"
    or net.sni matches "*.quad9.net"
    or net.host in {"8.8.8.8","8.8.4.4","9.9.9.9","149.112.112.112","208.67.222.222"}

# Policy 4: block non-HTTP risky outbound
- name: "Block dangerous outbound protocols"
  action: block
  condition: |
    net.port in {22, 23, 3389, 445, 1433, 3306, 5432, 6379, 27017}
    and net.direction == "outbound"
  # SSH, Telnet, RDP, SMB, SQL variants, Redis, MongoDB
  # Exception: specific corporate bastion/DB routed via Tunnel (Part 8)

# Policy 5: block Tor, torrents, proxy apps
- name: "Block anonymizer/P2P"
  action: block
  condition: |
    net.app in {"Tor", "Bittorrent", "eDonkey", "UltraSurf", "Psiphon"}

# Policy 6: block personal cloud storage
- name: "Block personal storage"
  action: block
  condition: |
    net.sni in {
      "www.icloud.com","*.mega.nz","*.terabox.com",
      "*.zippyshare.com","*.mediafire.com"
    }

# Policy 7: block sanctioned country
- name: "Block sanctioned country"
  action: block
  condition: |
    net.geo.country in {"IR","KP","CU","SY"}

# Policy 8: identity-based admin geo
- name: "Admin tools geo-fence"
  action: block
  condition: |
    identity.groups in {"Admin-Prod"}
    and net.sni matches "*.admin.prod.*"
    and not (net.geo.country in {"VN","SG","US"})

# Policy 9: default allow
- name: "Default allow"
  action: allow
  condition: "true"

---

Lưu ý bảo mật

Mô hình tin cậy

• Phía Gateway: CF xác nhận độ chính xác của việc đánh giá policy.
• Phía khách hàng: độ chính xác của rule, vệ sinh ngoại lệ.
• Tính toàn vẹn endpoint: người dùng có quyền admin nội bộ có thể tắt WARP → bypass. MDM bắt buộc WARP chạy.

Điểm mù

• Ngoài phạm vi WARP: danh sách exclude của split tunnel, mạng ngoài WARP (IoT nhà).
• ECH / SNI mã hóa: chuẩn bị tương lai: lên kế hoạch chặn nỗ lực ECH cho tới khi có fingerprint.
• VPN bên trong WARP: người dùng chạy VPN trên WARP → lưu lượng đã mã hóa trước khi WARP thấy → Gateway không kiểm tra được. Chặn các app VPN ở mức người dùng qua rule theo app.
• Site không qua proxy CF: kẽ hở của chế độ DNS location: chỉ DNS.

Playbook chống bypass

• Chặn IP + SNI các resolver DoH/DoT (Policy 3 ở trên).
• Chặn Tor + anonymizer (Policy 5).
• Chặn app VPN (NordVPN, ExpressVPN, v.v.) qua rule theo app.
• MDM bắt buộc WARP chạy + tự khởi động.
• Cảnh báo khi WARP ngắt kết nối > 5 phút / người dùng.
• Rule gắn identity với posture check (tuân thủ thiết bị): xem Part 16.

Ánh xạ tuân thủ

• ISO 27001 A.8.20 Network security.
• NIST CSF PR.AC-5 (network integrity), DE.CM-1 (continuous monitoring).
• PCI DSS 4.0 1.2.5 (permitted connections), 1.4.2 (anti-spoofing).
• CIS 12.1 (secure network infra), 13.4 (perform traffic filtering).

---

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

Số đo

• Kết nối bị chặn/s: đường cơ sở + cảnh báo khi tăng đột biến.
• Các port bị chặn nhiều nhất: 22/3389/445 = nỗ lực di chuyển ngang.
• Các quốc gia bị chặn nhiều nhất: bản đồ mối đe dọa địa chính trị.
• Số lần chặn DoH: xu hướng. Tăng đột biến = endpoint bị xâm nhập hoặc trình duyệt bật DoH mặc định.
• Số hit của rule theo app: Tor/Bittorrent = vi phạm chính sách.

Cảnh báo

• Tăng 10x đường cơ sở trong 15 phút = sự cố.
• Cùng một người dùng chạm block outbound ≥ 3 lần/giờ = SOC triage.
• WARP ngắt kết nối > 10 phút = endpoint có vấn đề hoặc nỗ lực bypass.
• Chặn theo quốc gia từ nguồn bất thường (US → Nga kết nối ngẫu nhiên) = có thể là C2.

Pipeline logs

Trường quan trọng

{
  "Timestamp": "2026-05-14T10:15:42Z",
  "UserID": "u_abc",
  "Email": "alice@company.com",
  "DeviceID": "d_xyz",
  "SourceIP": "10.0.0.42",
  "DestinationIP": "8.8.8.8",
  "DestinationPort": 443,
  "Protocol": "TCP",
  "SNI": "dns.google",
  "App": "Google DNS",
  "DestinationCountry": "US",
  "DestinationASN": 15169,
  "Action": "block",
  "PolicyID": "p_block_doh",
  "PolicyName": "Block third-party DoH"
}

Dataset: gateway_network.

Tương quan SIEM

• Tương quan log DNS + log Network + log HTTP theo người dùng: nhận diện tấn công đa tầng.
• Ví dụ: log DNS “malicious.com blocked” + 5 phút sau “direct IP 1.2.3.4 blocked” → kẻ tấn công thử DNS, chuyển sang IP.
• Rule phát hiện trong SIEM (Splunk, Sentinel): khớp mẫu giữa các dataset.

---

Truy nguyên thường gặp

”Developer báo SSH tới GitHub fail”

$ git clone git@github.com:company/repo.git
Connection to github.com port 22 refused

1. Logs → Network → lọc người dùng + port 22.
2. Thấy chính sách chặn chạm “Block outbound SSH to non-corporate”.
3. Kiểm tra: GitHub cho SSH trong workflow dev là hợp lệ. Thêm github.com + ssh.github.com vào $approved_ssh_hosts.
4. Kiểm thử: thử lại clone → chạy được.

Phương án khác: GitHub hỗ trợ clone qua HTTPS, cân nhắc áp dụng chính sách chỉ HTTPS.

”Giám sát Redis từ jumpbox fail”

• Port 6379 bị chặn outbound.
• Định tuyến Redis qua Cloudflare Tunnel (Part 8): client nói với redis.corp.internal qua Gateway.
• Hoặc: thêm IP nguồn (jumpbox) vào ngoại lệ $internal_db_access.

”Cuộc gọi Zoom của người dùng rớt thường xuyên”

• Zoom dùng UDP port không chuẩn (8801-8810, TCP 80/443/3478).
• Kiểm tra: rule net.app == "Zoom" cho phép tường minh.
• Thêm rule app cho phép Zoom với thứ tự ưu tiên trước rule chặn UDP chung.

”Domain ECH không còn xuất hiện trong logs”

• Trình duyệt nâng cấp bật Encrypted ClientHello.
• Gateway không đọc được SNI → chuyển sang dựa trên IP.
• Giải pháp: chặn client cố dùng ECH (qua fingerprint) HOẶC giải mã toàn bộ HTTPS (Part 12).
• Theo dõi: lộ trình phát hành tính năng phát hiện ECH của Cloudflare.

”Endpoint DoH hợp lệ bị chặn”

• Trình duyệt doanh nghiệp dùng DoH của nhà cung cấp (không phải tenant công ty).
• Xác minh: cấu hình trình duyệt → áp dụng endpoint DoH doanh nghiệp hoặc tắt.
• GPO/MDM: đặt Firefox network.trr.uri thành endpoint tenant.
• Chrome: DnsOverHttpsMode = automatic + endpoint của công ty.

”Khối lượng log quá cao”

• Log Network chi tiết: mọi kết nối.
• Lấy mẫu 10% không bị chặn, 100% bị chặn.
• Cloudflare hỗ trợ lấy mẫu ở Logpush.

---

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

Quyết định	Phương án A	Phương án B	Khuyến nghị
Chặn DoH triệt để	Chặn tất cả bên thứ ba	Chặn resolver lớn + cho phép phần còn lại	Chặn tất cả bên thứ ba. Kẻ tấn công cũng dùng resolver DoH ít phổ biến. Chỉ cho phép DoH tenant.
Chặn SSH outbound	Chặn cứng	Cho phép với kiểm toán	Chặn cứng mặc định, cho phép cụ thể. SSH là vector ransomware.
Rule theo app vs IP thô	Danh sách IP/domain thô	Rule theo app (catalog CF)	Rule theo app cho shadow IT phổ biến. Thô cho IoC mối đe dọa tuỳ chỉnh.
Độ chi tiết khi chặn theo quốc gia	Chặn cả quốc gia	CIDR cụ thể	Quốc gia ban đầu (độ phủ), tinh chỉnh bằng CIDR để giảm cảnh báo sai.
Lấy mẫu log	100%	Lấy mẫu	Lấy mẫu không bị chặn (10%), 100% bị chặn. Cân bằng lưu trữ vs điều tra pháp chứng.
Kiểm tra SNI vs giải mã toàn bộ	Chỉ SNI (quyền riêng tư)	Giải mã toàn bộ	SNI + L4 cho phần lớn kiểm soát. Giải mã toàn bộ chỉ khi cần DLP/CASB.
Xử lý ECH	Cho phép (tương lai)	Chặn nỗ lực	Chặn ECH cho tới khi khả năng quan sát của CF bắt kịp. Ghi lại để bỏ chặn về sau.

---

Playbook triển khai

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

• Kiểm kê policy L4 hiện tại (rule firewall, block đang có).
• Phân tích lưu lượng: top port, SNI, quốc gia từ log hiện tại.
• Nhận diện kẽ hở hiện tại (DoH đi qua được? Tor? SSH outbound cho phép?).

Giai đoạn 2: Đường cơ sở chỉ log (2 tuần)

• Bật tất cả policy ứng viên ở chế độ chỉ log.
• Đo tỉ lệ cảnh báo sai.
• Nhận diện dịch vụ hợp lệ đang chạm rule (xây danh sách ngoại lệ).

Giai đoạn 3: Chặn theo từng bước

• Bắt đầu với độ tin cậy cao nhất: chặn DoH, chặn Tor, quốc gia bị cấm vận.
• Giám sát 1 tuần mỗi đợt.
• Đợt tiếp theo: non-HTTP outbound (chặn SSH, RDP, SMTP).
• Cuối cùng: rule theo app (Bittorrent, anonymizer), lưu trữ cloud cá nhân chi tiết.

Giai đoạn 4: Tinh chỉnh liên tục

• Rà soát hàng tháng: tỉ lệ chặn, ticket cảnh báo sai, mối đe dọa mới.
• Hàng quý: làm mới danh sách quốc gia, cập nhật catalog app, tích hợp feed IoC.

---

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

Độ phủ chính sách:

• Resolver DoH bên thứ ba đã chặn.
• DoT (port 853) chặn trừ khi cho phép.
• SSH/RDP/SMTP/DB outbound chặn trừ danh sách đã duyệt.
• App Tor + P2P đã chặn.
• Lưu trữ cloud cá nhân đã chặn.
• Quốc gia bị cấm vận đã chặn.
• App anonymizer/VPN đã chặn.

Áp dụng:

• WARP đã enroll trên mọi thiết bị người dùng.
• MDM bắt buộc WARP chạy + tự kết nối.
• Cảnh báo khi WARP ngắt kết nối > 10 phút.
• Magic WAN cho egress site (nếu có).
• WiFi khách / IoT định tuyến qua DNS location (chấp nhận độ phủ chỉ DNS).

Logs & SIEM:

• Logpush dataset gateway_network sang SIEM.
• Trường đã ánh xạ: user, IP nguồn, IP/SNI đích, port, hành động.
• Lưu giữ ≥ 1 năm.
• Rule tương quan SIEM (DNS+Network+HTTP đa tầng).
• Dashboard: bị chặn nhiều nhất, xu hướng, vị trí địa lý.

Giám sát:

• Số đo đường cơ sở: tỉ lệ chặn, khối lượng kết nối.
• Cảnh báo khi tăng 10x đường cơ sở.
• Ngưỡng chặn theo từng người dùng → SOC triage.
• Runbook: luồng xử lý ticket người dùng.

Vận hành:

• Quy trình xử lý yêu cầu ngoại lệ đã có tài liệu.
• Vệ sinh danh sách cho phép: rà soát hàng quý, gỡ entry lỗi thời.
• Danh sách ngoại lệ cert pin đồng bộ với lớp HTTP (Part 12).
• Danh sách quốc gia bị cấm vận làm mới hàng quý.

---

Bài học thực tế

• DoH bypass là ưu tiên số 1. Không chặn DoH = bộ lọc DNS phần lớn vô nghĩa. Trình duyệt mặc định DoH đang tăng, vấn đề ngày càng lớn.
• Chặn SSH làm vỡ workflow dev ngay. Truyền thông trước, cung cấp phương án thay thế (git qua HTTPS, Cloudflare Tunnel cho SSH nội bộ).
• Catalog app bị lỗi thời. SaaS mới ra mắt, CF chưa có entry. Chuyển sang rule SNI thủ công.
• Người dùng sẽ tìm cách bypass WARP. Hotspot mobile, ngắt WARP. Áp dụng MDM + posture check rất quan trọng.
• Khối lượng log bùng nổ. Lớp Network chi tiết hơn DNS 3-5 lần. Cần lấy mẫu + tinh chỉnh lưu giữ.
• Cảnh báo sai tuần đầu cao. Dịch vụ hợp lệ chạm rule. 2 tuần chỉ log là tối thiểu.
• ECH là quả bom hẹn giờ. Khi trình duyệt mặc định ECH, rule theo SNI suy giảm. Lên kế hoạch chuyển sang giải mã hoặc chặn ECH.
• Chặn theo vị trí địa lý là công cụ thô. Chặn quốc gia bao phủ 80% mối đe dọa nhưng miss kẻ tấn công nhảy VPN. Dùng kết hợp với ASN + CIDR.

---

Kết luận

Lớp Network đóng block Policy & Filtering. Cùng với DNS (Part 11) và HTTP (Part 12), tạo SWG 3 tầng:

• DNS: rộng, rẻ, tuyến đầu.
• Network (L4): khép kẽ hở DoH, non-HTTP, IP trực tiếp, vị trí địa lý.
• HTTP: URL chi tiết, DLP, CASB, kiểm tra nội dung.

Không lớp nào đủ một mình. Mỗi lớp xử lý nhóm mối đe dọa mà lớp khác không thấy. Bỏ qua lớp Network = mở cửa sau cho kẻ tấn công có kinh nghiệm.

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

Network policy không hào nhoáng như DLP/CASB, nhưng nếu không có, bộ lọc DNS + HTTP dễ bị bypass. Chặn DoH + kiểm soát non-HTTP là mức tối thiểu cho Gateway trong production.

Đến đây kết thúc block Policy & Filtering (Part 11-13). Part tiếp theo chuyển sang block Observability & Ops: pipeline logs end-to-end, tích hợp SIEM, DEX (Digital Experience Monitoring), và tín hiệu posture cho đánh giá liên tục.

---

Tài liệu tham khảo

• Cloudflare Gateway Network policies
• App identifiers (Gateway catalog)
• SNI inspection và ECH
• Block DoH bypass
• Gateway logs schema
• Block countries / ASN

Trong series này:

• ← Part 12: Gateway HTTP filtering và TLS decryption
• Tiếp theo → Part 14: Logs pipeline end-to-end
• Xem toàn bộ: Series Cloudflare One Handbook