Centralized Egress
Overview of Egress Control Filter
![egress_overview](_images/security-egress-overview.png)
For Internet-bound egress traffic, specifying an outbound policy at the IP address level is not sufficient, as the domain names of a site can be translated to many different IP addresses.
An NAT gateway does not offer security group functions; it relies on security groups by each instance. An NAT instance’s security group does not have enough entries to support the large set of IP address lists. The egress filtering needs to happen at Layer 7.
On the other hand, workloads in AWS are mostly applications or programs where it is deterministic which outbound APIs the application program calls. For example, an application runs API queries to www.salesforce.com for data retrieving and runs API queries to www.google.com for app authentication. In these cases, making sure that only these sites are allowed for egress traffic is sufficient from a security point of view. Note that this is very different from on-prem situations where end user traffic and application traffic are mingled together; you may need a full-fledged firewall for Internet-bound traffic.
Another use case is for PCI DSS compliance. PCI DSS specifies that if you handle any payment and sensitive data, there must be firewall policy enforcement at the egress. In the cloud, the logical egress point is per VPC/VNet.
How does it work?
The function is transparent to individual instances and is carried out inline without requiring any certificate or keys to decrypt the traffic.
Non-HTTP/HTTPS traffic can also be filtered based on exact domain names. Use cases are secure file transfer (SFTP) to external sites, secure login in (SSH) to external sites.
A tag is defined as a list of FQDNs and it is created and managed on the Controller console. One or more gateways may be attached to a tag; each gateway can be attached to more than one tag. Any updates to a tag on the Controller automatically triggers updates to all gateways attached to the tag.
Multiple tags can be defined for the Controller. The domains in the tag are the destinations that are allowed for traffic to pass.
For configuration details, refer to this document.
How does Aviatrix Egress FQDN compare to Squid and other solutions?
Squid is a popular open-source software that can be configured to do transparent HTTP/HTTPS filtering. Squid does not process non-HTTP/HTTPS traffic. For example, if you need to filter on a SFTP site that runs on TCP port 22, Squid does not work. Below is a more comprehensive comparison between Aviatrix FQDN and Squid.
The table below also compares with other solutions such as AWS NAT Gateway, AWS Network Firewall, and Azure Firewall.
Functions | Aviatrix FQDN | AWS NAT Gateway | AWS Network Firewall | Azure Firewall | Squid |
---|---|---|---|---|---|
Requires instance configuration |
No |
No |
No |
No |
No |
HTTP and HTTPS FQDN filter |
Yes (support wildcard) |
No |
Yes |
Yes |
Yes |
non-HTTP/HTTPS FQDN filter |
Yes |
No |
No |
No |
No |
Requires dedicated subnet |
No |
No |
Yes |
Yes |
No |
Multi AZ High Availability |
Yes (load balanced) |
Yes |
Yes |
Yes |
No |
Centrally Managed |
Yes |
Yes |
Yes |
Yes |
No |
Egress Discovery |
No |
No |
No |
No |
|
API support |
Yes |
Yes |
Yes |
Yes |
No |
Terraform support |
Yes |
Yes |
Yes |
No |
No |
Out-of-box log integration |
Yes |
No |
Yes |
Yes |
No |
Allow specified destination to bypass filter |
Yes |
No |
No |
No |
No |
Allow specified source CIDR to apply to rule |
Yes |
No |
No |
No |
No |
Allow specified source CIDR to bypass filter |
Yes |
No |
No |
No |
No |
Out of box visibility on sessions |
Yes |
No |
No |
No |
No |
Search a specified rule match history |
Yes |
No |
No |
No |
No |
Vendor product support |
Yes |
Yes |
Yes |
Yes |
No |