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.

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. We highly recommend reading it.

So, how does discrimiNAT compare to AWS Network Firewall then?

 AWS Network FirewalldiscrimiNAT
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 an 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🟠 maybe
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🟠 maybe
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🟠 maybe
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, alongwith SNI, ESNI/ECH and IP Address 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 few 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 that
Stateful Rules🟢 yes
for very complex protocol-level detail rules, and for SNI in TLS and the Host Header in HTTP, this is useful. Otherwise, Security Groups should suffice for simpler specifications
🟢 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 Concierge
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 some tens of seconds of intermittent failures before the traffic is entirely sent to a stable AZ
🟢 yes
RTO as of today is just under 2 minutes since each instance is wrapped in an Auto Scaling Group. Egress data is buffered by monitoring & logging clients, general EC2 failures are quite rare, and if an AZ fails altogether – you’re not likely to need egress! We are working on lowering this substantially and if you are interested in knowing more, get in touch with our DevSecOps Concierge
Hops to the Internet🟠 at least two
this can only be inserted after AWS NAT and before the Internet Gateway for filtering egress traffic. It is unclear what additional network delay/hops does the GWLB VPC Endpoint that this runs behind ensue
🟢 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 capabilities, 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

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