This blog talks about Fully Qualified Domain Name (FQDN) Egress filtering, its purpose and the solutions available in the market.
First, let us understand FQDN Egress filtering. It is the practice of monitoring and potentially restricting the flow of information outbound from one network to another. Typically, it is information from a private EC2 instance to the internet that is controlled.
Cloud applications with unrestricted access to internet-based services expose your environment to attacks. Best practices limit applications communicating to known internet-based services. Native cloud constructs such as the internet and NAT gateways filter traffic based on IP addresses, but not on FQDN. FQDN “allows” lists, reduces an attacker’s ability to exfiltrate data and limits the ability for malicious traffic to communicate with cloud services.
Businesses with stringent compliance requirements like Payment Card Industry (PCI) and Health Insurance Portability and Accountability Act (HIPAA) benefit from using FQDN lists. Specific outbound internet traffic may need to be blocked. Let us take an example. If a hacker gets into a server and manages to decrypt payment data, they would not be able to send it to their desired place as it is not included in the allowed list.
For administrators to maintain a list of blocked IP addresses and update security groups on multiple servers will be an impractical burden, especially during audits and deployment. FQDN lists allow administrators and others to see the names of allowed domains in a single place. Rules can be automatically maintained and deployed from a central controller to virtual private clouds.
Let us see the SaaS solutions for FQDN Egress filtering.
DiscrimNAT Firewall is a solution that blocks traffic to destinations that are not allowed by hostname over HTTPS / TLS and SSH / SFTP connections. It works by monitoring data flow using a custom-built deep packet inspection engine integrated as a NAT instance in the output of the Virtual Private Cloud (VPC). It is a paid solution.
Image source: https://chasersystems.com/docs/discriminat/aws/installation-overview
This SaaS solution is available in four types that can be implemented into the existing environment or get the discrimNAT with the network already setup.
The HTTPS/TLS and SSH/SFTP modes in discrimiNAT are blocking configurations that only allow FQDNs set in the allow list. Destination protocols and FQDNs are added to the description fields of outbound rules of the protected applications. This is where we can specify all the FQDNs that can be allowed. We cannot create a blocking list.
Configuration: Specify allowed protocol and hostnames within the Security Group rules description fields of the respective applications, and the firewall will take care of the rest.
Deployment: We can have complete multi-zone configurations that work with a single click or DIY deployments where we can configure the networking around it. We get the entire IaC ready to go in our CloudFormation library / Terraform Registry.
The firewall logs each connection that is allowed and disallowed directly into AWS CloudWatch with rich metadata for analysis. Again, no configuration or setup is required.
The logs consist of Flow logs that keep track of destination hostname/FQDN, packet origin – client or server, source IP address and port, destination IP address and port, and protocol, among others. Config logs can be found in CloudWatch under the discrimiNAT log group, in the config log stream. They form an audit trail of changes made to rules and Security Group attachments as clients come and go.
Terraform Scripts can be used to create security groups. For information, visit this page.
discrimiNAT DevSecOps can be contacted at devsecops@chasersystems.com at any stage. They also provide chat support.
Aviatrix FQDN Egress Filtering is a multi-cloud service specially designed for centralized internet traffic management from a VPC or VNet using FQDN filtering. This solution meets organizational and regulatory requirements to restrict exits to the internet such as PCI, HIPAA, SOC2, etc. It reduces the complexity of manually creating instance-level filtering rules with an ever-changing list of IP addresses. Driven by the Aviatrix cloud networking platform, this solution offers enterprise-class visibility, centralized management, and multi-cloud options. It is a paid solution.
Image source: https://aws.amazon.com/quickstart/architecture/aviatrix-fqdn-egress-filtering/
This SAAS solution is available in two options – one that can be implemented into the existing environment or the other option with the network set up for us.
Using the policy-based approach, either a “Block all but allow a few FQDNs” or an “Allow all but block a few FQDNs” approach can be implemented.
It provides the GUI to connect and configure the policies and gateways. This makes it easy to manage as we have the UI to manage all gateways and create filters.
Out-of-the-box integration is supported for the following logging services: Elastic Filebeat, Splunk Enterprise/Cloud, Sumo Logic, Datadog, Netflow, and AWS CloudWatch.
Deployment and updates easily fit into existing CI/CD pipelines with Terraform and the Aviatrix API.
Email support@aviatrix.com for support. We can schedule a meeting with the technical support team.
Squid is an open-source proxy that implements a “transparent proxy” to instances in a private subnet, but can limit both outbound HTTP and HTTPS traffic to a specific set of internet domains. It is an Open Source Solution.
Image source: https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/
A pre-built CloudFormation template of the entire Squid environment is available, which includes the VPC and the Squid instances.
Only FQDN allow lists can be created. A text file with the allowed FQDNs needs to be uploaded to an S3 bucket. The Squid instance picks up the allowed FQDN list from the S3 bucket.
Deployment is simple as we can use CloudFormation template to deploy the VPC, subnets, two AZ networking, S3 bucket, IAM roles, Lambda function, and the Squid Instances.
The CloudFormation template creates a log group in CloudWatch where all logs will be stored.
We can use terraform automation for installing and configuring Squid.
No support is available as it is an open source tool. You can post questions in the community.
AWS Network Firewall is a highly available managed network firewall service for Amazon VPC. You can easily deploy and manage stateful inspection, intrusion prevention and detection, and web filtering to protect virtual networks on AWS. AWS network firewalls automatically scale with traffic to ensure high availability without additional customer investment in your security infrastructure.
You can deploy the AWS Network Firewall to all your VPCs that need protection. Each VPC is protected individually, and the separation of the VPCs reduces the blast radius. Each VPC does not require connectivity to any other VPC or AWS Transit Gateway.
Each AWS Network Firewall can have its own firewall policy or share a policy through common rule groups (reusable collections of rules) across multiple firewalls. This allows each AWS Network Firewall to be managed independently, which reduces the possibility of misconfiguration and limits the scope of impact. It is a pay-as-you-go solution.
Image source: https://networkfirewall.workshop.aws/setup/distributedmodel.html
As it is a service provided by AWS, it can be set up using the AWS console or CLI.
Using the network firewall rule group, rule groups can be created to allow and block access to domains.
As it is an AWS service, it is very easy to configure and manage.
The logs can be set up for the firewalls and integrated with S3 buckets, CloudWatch, Amazon Kinesis and other partner solutions.
As it is an AWS service, it can be automated using Terraform or through the CloudFormation templates.
The AWS support is based on your AWS account.
SaaS solutions for FQDN Egress filtering are very much dependent on the use-case, be it open source or a multi-cloud based application.
To learn more about these technologies & real time industry applied best practices, follow our LinkedIn Page. To explore our services, visit our website.
CloudifyOps Pvt Ltd, Ground Floor, Block C, DSR Techno Cube, Survey No.68, Varthur Rd, Thubarahalli, Bengaluru, Karnataka 560037
Indiqube Vantage, 3rd Phase, No.1, OMR Service Road, Santhosh Nagar, Kandhanchavadi, Perungudi, Chennai, Tamil Nadu 600096.
CloudifyOps Inc.,
200, Continental Dr Suite 401,
Newark, Delaware 19713,
United States of America
