Egress Control Filter
Aviatrix Fully Qualified Domain Name (FQDN) is a security service specifically designed for workloads or applications in the public cloud. It filters Internet-bound egress traffic initiated from workloads in a VPC/VNet. This service is centrally managed by the Controller and executed by an Aviatrix Gateway instance in the VPC/VNet in the distributed architecture.
Aviatrix FQDN filters any TCP and UDP traffic including HTTP, HTTPS, and SFTP traffic. The filtering function allows only the destination host names (whitelist) specified in the list to pass and drop all other destinations.
Each destination is specified as a fully qualified domain name. For example, if you only allow Internet bound traffic to www.salesforce.com, you can list the domain name www.salesforce.com in the whitelist.
For HTTP/HTTPS (TCP port 80/443), the FQDN feature also supports wild cards, such as *. In this example, you can specify *.salesforce.com to allow traffic to any domain names that end in "salesforce.com."
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 |