Recommended network policies

We recommend you add the following network policies to build an Internet and SaaS app security strategy for your organization.

For more information on building network policies, refer to Network policies.

Quarantined-Users-NET-Restricted-Access

Restrict access for users included in an identity provider (IdP) user group for risky users. This policy ensures your security team can restrict traffic for users of whom malicious or suspicious activity was detected.

Selector	Operator	Value	Logic	Action
Destination IP	not in list	Quarantined-Users-IPAllowlist	Or	Block
SNI	not in list	Quarantined-Users-HostAllowlist	Or
Domain SNI	not in list	Quarantined-Users-DomainAllowlist	And
User Group Names	in	Quarantined Users

Posture-Fail-NET-Restricted-Access

Restrict access for devices where baseline posture checks have not passed. If posture checks are integrated with service providers such as Crowdstrike or Intune via the API, this policy dynamically blocks access for devices that do not meet predetermined security requirements.

Selector	Operator	Value	Logic	Action
Destination IP	not in list	Posture-Fail-IPAllowlist	Or	Block
SNI	not in list	Posture-Fail-HostAllowlist	Or
Domain SNI	not in list	Posture-Fail-DomainAllowlist	And
Passed Device Posture Checks	not in	Windows 10 or higher (OS version)

You can add a number of WARP client device posture checks as needed, such as Disk encryption and Domain joined. For more information on device posture checks, refer to Enforce device posture.

FinanceUsers-NET-HTTPS-FinanceServers (example)

Allow HTTPS access for user groups. For example, the following policy gives finance users access to any known financial applications:

Selector	Operator	Value	Logic	Action
Destination IP	in list	Finance Servers	And	Allow
User Group Names	in	Finance Users

All-NET-Internet-Blocklist

Block traffic to destination IPs, SNIs, and domain SNIs that are malicious or pose a threat to your organization.

You can implement this policy by either creating custom blocklists or by using blocklists provided by threat intelligence partners or regional Computer Emergency and Response Teams (CERTs). Ideally, your CERTs can update the blocklist with an API automation to provide real-time threat protection.

Selector	Operator	Value	Logic	Action
Destination IP	in list	IP Blocklist	Or	Block
SNI	in list	Host Blocklist	Or
Domain SNI	in list	Domain Blocklist

Note

The Detected Protocol selector is only available for Enterprise users. For more information, refer to Protocol detection.

All-NET-SSH-Internet-Allowlist

Allow SSH traffic to specific endpoints on the Internet for specific users. You can create a similar policy for other non-web endpoints that required access.

Optionally, you can include a selector to filter by source IP or IdP group.

Selector	Operator	Value	Logic	Action
Destination IP	in list	SSHAllowList	Or	Allow
SNI	in list	SSHAllowlistFQDN	And
Detected Protocol	is	SSH	And
User Group Names	in	SSH-Allowed-Users

All-NET-NO-HTTP-HTTPS-Internet-Deny

Block all non-web traffic towards the Internet. By using the Detected Protocol selector, you will ensure alternative ports for HTTP and HTTPS are allowed.

Selector	Operator	Value	Logic	Action
Destination IP	not in list	InternalNetwork	And	Block
Detected Protocol	not in	HTTP, HTTP2

All-NET-InternalNetwork-ImplicitDeny

Implicitly deny all of your internal IP ranges included in a list. We recommend you place this policy at the bottom of your policy list to ensure you explicitly approve traffic defined in the above policies.

Selector	Operator	Value	Action
Destination IP	in list	Internal Network IPs	Block

All-NET-ApplicationAccess-Allow

Only allow network traffic from known and approved devices.

In the following example, you can use a list of device serial numbers to ensure users can only access an application if they connect with the WARP client from a company device:

Dashboard

Selector	Operator	Value	Logic	Action
Passed Device Posture Checks	not in	Device serial numbers	And	Block
SNI Domain	is	internalapp.com

API

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --data '{
  "name": "All-NET-ApplicationAccess-Allow",
  "description": "Ensure access to the application comes from authorized WARP clients",
  "precedence": 5000,
  "enabled": false,
  "action": "block",
  "filters": [
    "l4"
  ],
  "traffic": "any(net.sni.domains[*] == \"internalapp.com\")",
  "device_posture": "not(any(device_posture.checks.passed[*] in {\"<DEVICE_SERIAL_NUMBERS_LIST_UUID>\"}))"
}'

To get the UUIDs of your device posture checks, use the List device posture rules endpoint.

Terraform

resource "cloudflare_zero_trust_gateway_policy" "dns_resolvedip_blocklist_rule" {
  account_id  = var.account_id
  name        = "All-NET-ApplicationAccess-Allow"
  description = "Ensure access to the application comes from authorized WARP clients"
  precedence  = 5000
  enabled     = false
  action      = "block"
  filters     = ["l4"]
  traffic     = "any(net.sni.domains[*] == \"internalapp.com\")"
  posture      =  "not(any(device_posture.checks.passed[*] in {\"${"$"}${cloudflare_zero_trust_list.allowed_devices_sn_list.id}\"}))"
}