aws network firewall
How does AWS Network Firewall compare 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 | |
|---|---|---|
| Sufficient Depth of Checks | 🔴 no trivial to bypass – see example†. 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 hostnames against IP addresses in the connections |
| Per-Application Policies | 🔴 no policies can only be applied at a VPC-level and with a workaround to CIDR blocks of other VPCs. Supported topology can only place it after AWS NAT so the true private IP of the client will never be known for granular policies | 🟢 yes integrates with the Cloud providers' native application-level firewall constructs such as Security Groups in AWS and Firewall Rules in GCP, deriving policies from these resources' built-in description fields |
| Protocol Downgrade Protection | 🟠 manual 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 |
| Monitor Flows | 🔴 no per-application policies cannot be made to work as discussed, therefore, any relaxation of enforcement (so logs can be collected) puts the entire VPC at risk. Also, because traffic arrives after NAT, impossible to tell which application or client sent it | 🟢 yes the see-thru 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 too |
| SSH (or SFTP) Protocol Support | 🟠 manual FQDNs are not supported for this protocol but the validity of this protocol on a given port may be checked with some Suricata syntax | 🟢 yes FQDNs are supported and determination of which protocol and at what version is carried out regardless of port numbers |
| 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 |
| 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 at the internet/public edge of your network |
| Plaintext HTTP Support | 🟢 yes HTTP Host Header (client-settable) is checked on unencrypted connections for compliance | 🔴 no unsafe protocols are simply not implemented – encouraging teams to fix the root cause and upgrade to encrypted protocols (HTTP over TLS, i.e. HTTPS) instead in their application configs |
| Cloud-Native Rules Management | 🟢 yes AWS Network Firewall has a dedicated API and web console presence for rule management, and recently support 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 DevSecOps Support |
| Application Config Required | 🟢 no 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 | 🟢 no 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 between AWS NAT 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 |
| 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 |
| 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 |
| 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 |
| Hops to the Internet | 🟠 two this can only be inserted after AWS NAT and before the Internet Gateway for filtering egress traffic | 🟢 one NAT is built-in like most firewalls. The routing is simple and direct |
| Instant Connection Denied Feedback | 🔴 no due to the use of Suricata's packet dropping features, applications need to wait for connections to timeout. This leads to poorer experience when setting things up | 🟢 yes connections are terminated gracefully when denied, so applications have instant feedback |
| 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 an internet gateway, has simple routing, safe defaults and allowlist contents map to application configs directly – no specialised knowledge is required to configure and operate it, and the security champions can confidently hand it 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