Create your first HTTP policy
Now that you have considered which devices and applications TLS inspection should and should not apply to, it is time to create your first HTTP policy.
Use a standard naming convention when building all policies. Policy names should be unique across the Cloudflare account, follow the same structure, and be as descriptive as possible.
To create a new HTTP policy:
-
In Zero Trust ↗, go to Gateway > Firewall policies.
-
In the HTTP tab, select Add a policy.
-
Name the policy.
-
Under Traffic, build a logical expression that defines the traffic you want to allow or block.
-
Choose an Action to take when traffic matches the logical expression. For example, if you have configured TLS decryption, some applications that use embedded certificates may not support HTTP inspection, such as some Google products. You can create a policy to bypass inspection for these applications:
Selector Operator Value Action Application in Do Not Inspect Do Not Inspect Cloudflare also recommends adding a policy to block known threats such as Command & Control, Botnet and Malware based on Cloudflare's threat intelligence:
Selector Operator Value Action Security Categories in All security risks Block -
Select Create policy.
-
Create an API token with the following permissions:
Type Item Permission Account Zero Trust Edit -
(Optional) Configure your API environment variables to include your account ID and API token.
-
Send a
POSTrequest to the Create a Zero Trust Gateway rule endpoint. For example, if you have configured TLS decryption, some applications that use embedded certificates may not support HTTP inspection, such as some Google products. You can create a policy to bypass inspection for these applications:curl API HTTP policy example curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \--header "Content-Type: application/json" \--header "Authorization: Bearer <API_TOKEN>" \--data '{"name": "Do not inspect applications","description": "Bypass TLS decryption for unsupported applications","precedence": 0,"enabled": true,"action": "off","filters": ["http"],"traffic": "any(app.type.ids[*] in {16})","identity": "","device_posture": ""}'{"success": true,"errors": [],"messages": []}The API will respond with a summary of the policy and the result of your request.
Cloudflare also recommends adding a policy to block known threats such as Command & Control, Botnet and Malware based on Cloudflare's threat intelligence:
Block known risks HTTP policy curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \--header "Content-Type: application/json" \--header "Authorization: Bearer <API_TOKEN>" \--data '{"name": "Block known risks","description": "Block all default Cloudflare HTTP security categories","precedence": 0,"enabled": true,"action": "block","filters": ["http"],"traffic": "any(http.request.uri.security_category[*] in {68 178 80 83 176 175 117 131 134 151 153})","identity": "","device_posture": ""}'
For more information, refer to HTTP policies.
In most scenarios, Gateway evaluates HTTP policies in top-down order (like DNS policies). Because Do Not Inspect action policies are terminal actions, we recommend grouping them in logical order above all of your other policies because they will always functionally fire first regardless of where they are placed.
Once the Do Not Inspect policies are ordered correctly, Allow policies should follow, and the Allow policy descriptions should include any special considerations for Allow actions (such as header IDs, certificate mismatch handling, and non-isolate traffic).
Next, list your isolate and block policies. There may be scenarios in which you want to intermingle your block policies within your other policy outcomes. That is an acceptable approach, but you will need to ensure that you do not have overly permissive allows or overly restrictive block policies that will cause unintended effects.
Before instituting blocks or other actions that would impact your users, first measure impact by setting the policy as an Allow action. Monitor your users' actions and look in your logs, sorting by that explicit policy, to see what traffic actions matched against it. If the activity is exactly what you would expect for the policy, you are probably safe to implement it as its intended action.
If your policy matches unexpected traffic flows or destinations (such as unintended users or device groups), review your policy to ensure it is not overly permissive or restrictive. If the policy design looks correct, determine whether other policies are matching before the intended policy. You can review the order of enforcement for Gateway policies to ensure all of your policies are working together as intended.