aws network firewall
How AWS Network Firewall compares with DiscrimiNAT for egress filtering
Egress filtering has long been a challenge in AWS environments. In Nov 2020, AWS introduced the Network Firewall, which promised to address this gap. The documentation discloses upfront that it's built upon a well-regarded IPS.
info
Network Firewall uses the open source intrusion prevention system (IPS), Suricata, for stateful inspection.
Source: https://docs.aws.amazon.com/network-firewall/.../what-is-aws-network-firewall
tip
An article that covers the "idiosyncrasies" and "gotchas" as a result of this repurposing is Secure Internet Access (Egress Filtering) with AWS Network Firewall by Karl Maier.
COMPARISON
So, how does DiscrimiNAT compare to AWS Network Firewall then?
| AWS Network Firewall | DiscrimiNAT | |
|---|---|---|
| Spoofing Prevention (without TLS decryption) | 🔴 no trivial to bypass – see example† below. By AWS' own admission, it does not conduct "out-of-band DNS lookups", so clients can present an allowed hostname in the headers while making the connection to any arbitrary IP address | 🟢 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 |
| Owned Full Stack | 🔴 no uses the open source intrusion prevention system (IPS) Suricata – which is primarily a monitoring tool. | 🟢 yes written completely in-house in Rust. Delivers great end-user experience with quick iteration on features & usability improvements. |
| FQDN Discovery | 🔴 no per-application policies are difficult to accomplish and even then very limited (discussed below), therefore, any relaxation of enforcement (so logs can be collected) puts the entire VPC in open mode | 🟢 yes the see-thru monitoring mode is able to capture and generate filterable logs for specific applications, therefore, keeping policies enforced for the rest of the VPC. Logs also indicate whether current rules would cover the traffic seen or not (dry-run), and can be filtered on this criteria |
| Narrow Allowlists | 🟠 potentially maximum of five IP set references (based on resource tags) per rule group, and those would have to be in a Suricata-compatible format. This introduces friction and puts limits on your multi-cloud micro-segmentation designs | 🟢 yes integrates with the Cloud providers' native application-level constructs such as Security Groups in AWS and Firewall Rules in GCP, deriving egress policies from these resources' built-in fields, with no limits |
| SSH (or SFTP) Protocol Support | 🔴 no not natively but general IP address rules can be created with use of EventBridge and a Lambda Function to try and keep resolved IPs up to date, as is explained in this blog post by AWS | 🟢 yes FQDNs are supported and determination of the protocol is carried out regardless of port numbers. Our Wormhole DNS technology easily keeps up with low-TTL, round-robin, etc. DNS responses as well |
| TLS (or HTTPS) Protocol Support | 🟢 yes a rudimentary support is provided through 'Stateful domain list rule groups' but protocol version level checks would have to be written in Suricata syntax | 🟢 yes TLS v1.2 or better bidirectional enforcement, and along with SNI, ECH (formerly ESNI) and DNS checks are built-in with nothing to configure |
| Safe Wildcards | 🟠 prefix domain names can be added with a leading . to allow everything to the left of the dot character, potentially and often allowing all tenants on a CSP or a CDN | 🟢 yes precise patterns can be configured with use of glob characters and flexible positioning to only allow tenant subdomains you trust. See our philosophy at Wildcards and System 2 Thinking |
| CRL URLs pass-through | 🟠 proxied only when TLS decryption is configured and CA certificates imported into all your apps, CRL tests are initiated by this firewall. See notes on caching and latency here. Direct, app-level access 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 |
| Free Data Processing | 🔴 no there are data processing charges and when used with AWS NAT, the charge for only NAT is discounted | 🟢 yes there is no data processing charge |
| Protocol Downgrade Protection | 🟠 potentially such a capability must be explicitly configured in Suricata-compatible language for TLS v1.2 or better and SSH v2 | 🟢 yes enforces minimum protocol level versions (such as 1.2 for TLS), as per contemporary standards, for both sides of a handshake |
| Instant Connection Denied Feedback | 🔴 no due to the use of Suricata's packet dropping features when using stateful Domain List rule groups, 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 when denied, so applications have instant feedback and do not stall when all their outbound connections are not allowed |
| TLS Decryption | 🟠 yes launched in March 2023, this feature comes with noteworthy limitations and, of course, requires importing the CA certificate into all your apps. Checking for decrypted HTTP specifics such as header values, payload size, etc. would require writing rules in Suricata syntax. | 🟠 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 full performance, and continuing to work transparently as the TLS protocol evolves with Post-Quantum Cryptography (Kyber in Chrome works, for example) |
| Prevent Unencrypted Traffic | 🔴 no allows plaintext HTTP and checks only the easily spoofable Host header (client-settable) | 🟢 yes 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 |
| Cloud-Native Rules Management | 🟢 yes AWS Network Firewall has a dedicated API and web console presence for rule management. These are supported in Terraform and CloudFormation as well | 🟢 yes config is pulled from fields in Security Groups therefore enabling the use of web consoles, and any existing infrastructure as code tools such as Terraform and CloudFormation |
| Stateless Rules | 🟢 yes for a very large number of stateless rules, this could be useful | 🔴 no we recommend the use of the free Network ACLs in any VPC for this, unless the list won't fit in those |
| Stateful Rules | 🟢 yes for very complex protocol-level detail rules, for SNI in TLS and the Host header in HTTP, this is useful. Otherwise, Security Groups should suffice for simpler requirements | 🟢 yes for SSH and TLS connections to FQDNs. Otherwise, native Security Groups should suffice for Protocol, IP and Port based rules |
| Cloud-Native Logging | 🟢 yes CloudWatch, S3 and Kinesis are supported directly with structured logs that have a whole lot of protocol-level detail | 🟢 yes CloudWatch is supported directly with structured logs that make more sense for human-operability. Agents from Splunk, Rapid7, etc. can be installed directly in the instances |
| 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 |
| Transparent Operation | 🟢 yes since this is an additional hop in the routing before or after AWS NAT Gateway, and AWS Internet Gateway, it's transparent to clients | 🟢 yes since this replaces the NAT, packets are naturally routed via it at an IP level, and the routing is simpler than AWS Network Firewall's, with less hops too |
| Indicators Of Compromise (IoC) Support | 🟢 yes since this is actually an IPS under the hood, this feature is supported and to a reasonable number of indicators | 🔴 no since this is not an IPS but a NAT gateway with only an allowlist mode and a default of deny, it does not support general IoC monitoring |
| Price per Hour | 🟢 yes and when used with AWS NAT, the price for only NAT is completely discounted | 🟢 yes simple hourly pricing with NAT functionality built-in, no need for AWS NAT |
| High Availability | 🟢 yes built on the GWLB technology, these Suricata "appliances" should have cross-zone load balancing and if a target fails, there will be at least 70 seconds ‡ of intermittent failures before the traffic is entirely sent to a stable AZ | 🟢 yes uses the same underlying Gateway Load Balancer (GWLB) technology from AWS and has health checks set to 2 consecutive failures at 5 seconds apart |
| Safe to Operate | 🔴 no with complex evaluation order among the stateless and stateful rules, within the stateful rules with overlapping domain names, complex routing and default stance of 'allow', it is no surprise it scored a Security Effectiveness rating of 5.39% at cyberratings.org | 🟢 yes has been designed upfront to not have features that can downgrade the security stance expected of egress filtering, has simple routing, safe defaults and allowlists live with applications. No specialised knowledge is required to configure and operate it; can be handed over for self-service operation |
‡ The minimum duration to start re-routing new flow is up to 70 seconds. It is a sum of 20 seconds for health checks (Min. Interval: 10s, Min. threshold: 2) and 50 seconds for GWLB backend to detect and re-route. Source: https://aws.amazon.com/.../best-practices-for-deploying-gateway-load-balancer/
LITMUS TEST
Generally, is your FQDN egress firewall effective at all?
You can test with these curl commands, inspired by the infamous line 525 of the Codecov breach.
Say your firewall allows HTTPS connections to api.github.com, then this curl command, unsurprisingly, should work:
curl -v https://api.github.com/
† However, the following should not work, since it tries to connect to an arbitrary IP address under the guise of connecting to api.github.com:
curl -v --connect-to "api.github.com:443:1.1.1.1:443" -k -H "Host: one.one.one.one" https://api.github.com/
The AWS Network Firewall nevertheless allows it 🤦. And its documentation explains why it does.
For HTTPS traffic, Network Firewall uses the Server Name Indication (SNI) extension in the TLS handshake to determine the hostname, or domain name, that the client is trying to connect to. For HTTP traffic, Network Firewall uses the HTTP host header to get the name. In both cases, Network Firewall doesn't pause connections to do out-of-band DNS lookups. It uses the SNI or host header, not the IP addresses, when evaluating domain list rule groups. If you want to inspect IP addresses, to mitigate situations where the SNI or host headers have been manipulated, write separate rules for that and use them in conjunction with or in place of your domain list rules.
Source: https://docs.aws.amazon.com/network-firewall/...domain-names