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.
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
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 | 🔴 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 |
| 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, and can be filtered on this criteria |
| Least Privilege egress | 🟠 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 micro-segmentation | 🟢 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 |
| 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 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 | 🔴 no but in the FAQ, the question is at Can AWS Network Firewall inspect encrypted traffic? and a workaround that would only work in very specific cases is suggested | 🔴 no at this time, DiscrimiNAT does not implement decryption of the full payload or installation of CA keys; the boundary of unencrypted data does not move to this gateway – which is at the Internet/public edge of your network |
| 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. If you'd like to see more supported logging destinations, get in touch with our support |
| 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 difficult to imagine this can be configured safely without expert help | 🟢 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: 1.1.1.1" 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