Why dedicated Firewall Event logging matters
On the busiest sites behind Cloudflare, only a fraction of the total requests typically trip security rules. The rest are legitimate traffic that never touches WAF or custom firewall logic. In the past, getting security event data into a SIEM meant pulling the entire HTTP request stream and filtering out the noise on your side. That approach wastes bandwidth and storage, and it forces security analysts to wade through irrelevant data to find the signal.
Cloudflare Logs now offers a more direct route. You can create Logpush jobs that deliver only Firewall Events, and those events arrive faster than ordinary HTTP request logs—usually within 60 seconds of the response being sent to the client. This cuts costs for log-line-based pricing and gives your security team a cleaner feed to work with.
This guide walks through the setup using Terraform and Sumo Logic as the destination. The same pattern works with other analytics partners or any logging platform that consumes from AWS S3, Azure Blob Storage, or Google Cloud Storage.
Building the pipeline
The configuration is split into two halves: first, stand up a Sumo Logic collector and HTTP source to receive the logs; second, create a Cloudflare Logpush job that sends Firewall Events to that endpoint. Terraform handles both halves, and the Cloudflare provider used here is version 2.6.0 or later, which is when Logpush job support was added.
Before starting, install Terraform and Go. Go is needed because the Sumo Logic provider is a community plugin that must be built manually rather than pulled from the Terraform Registry. On macOS, Homebrew installs both quickly.
You'll also need a Sumo Logic account with an Access Key, generated from the Security > Access Keys page. Save the Access ID and Access Key as environment variables rather than committing them to source control.
On the Cloudflare side, generate a scoped API token from your profile page. The token needs Zone-level Logs Edit permissions. Give it a descriptive name like "Logpush - Firewall Events", and optionally restrict it to specific zones or IP ranges.
Configure Sumo Logic
Create a working directory for the Terraform project. The first configuration file defines the Sumo Logic collector and HTTP source, and a separate variables file holds the credentials Terraform needs to talk to Sumo Logic.
After writing those files, run terraform init followed by terraform plan to preview the changes. When the plan looks correct, apply it. At this point, the collector and source exist in Sumo Logic, but no data is flowing yet.
Verify the destination with a challenge token
Before Cloudflare will send logs, you must demonstrate that you can read from the destination. This prevents misconfigurations from silently overrunning your log storage. Sumo Logic's livetail utility handles this verification and is also handy for watching events arrive later.
Start livetail in a separate shell window, pointed at the HTTP source you created. Then use Terraform to retrieve the receiver URL of that source, converting the scheme from https:// to sumo:// as Cloudflare expects. Request a challenge token from Cloudflare using that URL; when livetail receives it, copy the returned content value into an environment variable for the next step.
Create the Logpush job
With the challenge token verified, you can define the Logpush job itself. First, enumerate the available log fields by querying the dataset so you can choose which ones to include. Then append the Cloudflare configuration to your Terraform files, adding the job definition and its variables.
After updating the files, re-run terraform init to fetch the Cloudflare provider, then run plan and apply to create the job. Once it's live, test end-to-end.
Confirming events arrive
For the test, make sure the WAF is enabled or that a firewall rule will match your request. With livetail still running, send a request like https://example.com/<script>alert()</script> from a browser. You'll see a block page in response, and within a minute the Firewall Events for that request will appear in livetail.
One malicious request can generate multiple events. In the example used here, a single XSS attempt triggered six distinct Managed Rules—#958051, 958052, 973300, 973307, 973331, and 981176—each producing its own log entry. That granular detail is exactly what a SIEM needs for correlating and investigating attack patterns.
