Skip to main content

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 FirewallDiscrimiNAT
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