Skip to content
Indus LeveL
GCP Security Log Analytics Firewall DNS

Correlating GCP Firewall Denies with DNS Logs using Log Analytics

Learn how to enable DNS logging, configure NGFW URL-based egress filtering, and use Log Analytics to find the domain names behind denied firewall connections.

2 min read
Correlating GCP Firewall Denies with DNS Logs using Log Analytics

When securing egress traffic in a cloud environment, Google Cloud's Next-Generation Firewall (NGFW) provides powerful URL-based filtering. However, standard firewall logs only show IP addresses, leaving administrators guessing which specific domains were blocked.

By combining DNS Logging, NGFW Egress Filtering, and the power of Log Analytics, you can uncover the exact domain names behind blocked connections.

In this post, we will cover:

  1. How to enable DNS logging in GCP.
  2. How to enable egress URL filtering using firewall policies.
  3. How to enable Log Analytics on the _Default bucket.
  4. A specialized Log Analytics query to correlate firewall denies with DNS requests.

1. How to Enable DNS Logging

To track which domains your instances are attempting to resolve, you must enable DNS logging for your VPC.

  1. Go to the Network Intelligence Center or Cloud DNS in the GCP Console.
  2. Navigate to DNS Server Policies.
  3. Create or edit a policy.
  4. Under Logging, toggle the switch to On.
  5. Apply the policy to the VPC network you want to monitor.

Using gcloud:

gcloud dns policies create "secure-dns-policy" \
  --networks="<VPC_NAME>" \
  --enable-logging \
  --description="Enable DNS logging for <VPC_NAME>" \
  --project="<PROJECT_ID>"

Once enabled, queries will be logged to Cloud Logging under the resource type dns_query.


2. How to Enable Egress URL Filtering using Firewall Policies

Next-Generation Firewall (NGFW) allows you to create rules based on URLs rather than just IP ranges.

  1. Go to VPC Network > Firewalls > Policies.
  2. Create a new Hierarchical Firewall Policy or Global Network Firewall Policy.
  3. Add a rule with the direction set to Egress.
  4. Set the target to your specific tags or service accounts.
  5. In the Match criteria, select URLs (this requires setting up a Secure Web Gateway or using enterprise tier capabilities).
  6. Define your allowed or denied URLs and set the action (e.g., DENY).
  7. Associate the policy with your VPC.

Using gcloud: To create an egress rule blocking specific FQDNs:

gcloud compute firewall-policies rules create 1000 \
  --firewall-policy="<FIREWALL_POLICY_NAME>" \
  --direction=EGRESS \
  --action=deny \
  --match="destFqdns=['raw.githubusercontent.com', 'deb.nodesource.com']" \
  --description="Block denied egress URLs" \
  --project="<PROJECT_ID>"

3. Enable Log Analytics on the _Default Bucket

To run complex SQL queries over your logs, you must upgrade your log bucket to use Log Analytics.

  1. Go to Logging > Log Storage.
  2. Find the _Default bucket (or the bucket where your VPC and DNS logs are routed).
  3. Click the three dots menu and select Upgrade to use Log Analytics.

Using gcloud:

gcloud logging buckets update _Default \
  --location=global \
  --enable-analytics \
  --project="<PROJECT_ID>"
  1. Confirm the upgrade. Note that this will allow you to query logs using BigQuery-standard SQL directly in the Logging console!

4. The Correlating Query

Now for the magic. Because firewall logs only show the destination IP, we must join them with the DNS query logs to see which domain resolved to that IP within a reasonable time window (e.g., 60 minutes before the connection attempt).

Run the following query in the Log Analytics page:

WITH
FirewallDenies AS (
  SELECT
    timestamp AS fw_time,
    JSON_VALUE(json_payload.connection.src_ip) AS src_ip,
    JSON_VALUE(json_payload.connection.dest_ip) AS dest_ip,
    JSON_VALUE(json_payload.connection.dest_port) AS dest_port,
    JSON_VALUE(json_payload.rule_details.reference) AS rule_name
  FROM
    `<PROJECT_ID>.global._Default._Default`
  WHERE
    log_name LIKE "%compute.googleapis.com%firewall"
    AND JSON_VALUE(json_payload.disposition) = "DENIED"
    AND JSON_VALUE(json_payload.rule_details.direction) = "EGRESS"
),
DNSQueries AS (
  SELECT
    timestamp AS dns_time,
    TRIM(JSON_VALUE(json_payload.queryName), '.') AS domain,
    REGEXP_EXTRACT(JSON_VALUE(json_payload.rdata), r'\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b') AS resolved_ip
  FROM
    `<PROJECT_ID>.global._Default._Default`
  WHERE
    log_name LIKE "%dns.googleapis.com%dns_queries"
    AND JSON_VALUE(json_payload.rdata) IS NOT NULL
    AND JSON_VALUE(json_payload.rdata) <> ""
)
SELECT
fw.fw_time,
fw.src_ip,
fw.dest_ip,
fw.dest_port,
dns.domain,
fw.rule_name
FROM
FirewallDenies fw
JOIN
DNSQueries dns
ON fw.dest_ip = dns.resolved_ip
WHERE
dns.dns_time <= fw.fw_time
AND dns.dns_time > TIMESTAMP_SUB(fw.fw_time, INTERVAL 60 MINUTE) 
QUALIFY 
ROW_NUMBER() OVER(PARTITION BY dns.domain ORDER BY fw.fw_time DESC) = 1
ORDER BY
fw.fw_time DESC;

The Result

The output of this query reveals the domains that were blocked by your egress policy, providing clear visibility into your network security posture:

fw_timesrc_ipdest_ipdest_portdomainrule_name
2026-05-11 04:17:00.678 PDT10.0.1.2185.199.108.133443raw.githubusercontent.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 04:14:38.854 PDT10.0.1.2104.20.45.190443deb.nodesource.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 04:13:58.691 PDT10.0.1.334.244.58.147443motd.ubuntu.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 04:13:47.142 PDT10.0.1.291.189.91.46443esm.ubuntu.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 03:44:55.046 PDT10.0.1.2140.82.113.422github.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 03:29:17.254 PDT10.0.1.4185.125.188.58443api.snapcraft.ionetwork:prod-vpc/firewallPolicy:secure-egress-policy
2026-05-11 03:06:46.406 PDT10.0.1.2185.125.190.48443changelogs.ubuntu.comnetwork:prod-vpc/firewallPolicy:secure-egress-policy

This data allows you to quickly identify false positives or unauthorized access attempts, making your firewall management significantly more effective.

Back to Blog
Share:

Follow along

Stay in the loop — new articles, thoughts, and updates.