Applications across datacenters and cloud environments are responsible for a vast amount of east-west traffic. This traffic is the result of communication between workloads, including bare-metal, virtual machines, and containers. However, many applications might need to communicate with services, such as SaaS, PaaS or external registries. These services are coupled with an IP address but that address might be unknown or the services might only be reachable by a URL because their IP addresses are frequently changing. This situation introduces a challenge to security teams because security policies are based on IP addresses or subnets. Administrators can allow outbound communication to any workload or to a broad range of IP addresses to overcome this challenge; however, this approach opens a security gap. To resolve this challenge, Illumio has added FQDN-based visibility and enforcement to its Illumio Core.
Benefits of FQDN-Based Rules
Implementing FQDN-based rules in the Illumio Core has the following benefits:
- Deeper visibility: Delivers visibility into communications from workloads to any workload reachable via a URL. For example, when a workload needs to pull an image from an unmanaged repository or use Amazon RDS for database services, Illumio provides visibility to those FQDNs and not just to the IP addresses behind them.
- Natural language policy: Automatically generate or write allowlist policies that allow workloads to consume services from FQDNs rather than IP addresses or subnets.
- Adaptive security: Using distributed DNS snooping at the workload, the Illumio Core dynamically conforms policy to any changes, such as a domain name resolving to a new IP address.
- Lock-down outbound communications and reduce risk: With FQDN-based enforcement, you decide which outbound services should be allow-listed for your application rather than allowing all outbound communications. This ability mitigates the risk of applications potentially communicating with a malicious IP address or domain name.
- Wildcard support: Enables you to write FQDN-based policy using wildcards, such as *.redhat.com.
Features of FQDN-Based Rules
Distributed DNS Snooping
The VEN performs DNS snooping for both visibility and enforcement purposes. Each time a workload sends out a DNS request, the VEN snoops for a DNS response for that request. The VEN collects data from the DNS response including the CNAMEs, and records and programs it into a DNS cache created by the VEN. The VEN does not generate control plane traffic, for example DNS requests. Additionally, the VEN does DNS-request tracking, which means when the workload receives a DNS response for an FQDN it did not send a request for, the VEN will not add the DNS response data into its cache.
DNS Visibility
One of the core elements of the Illumio Core is visibility into communications between workloads. The VEN periodically reports flow data to the PCE including IP addresses, ports, and protocols. With FQDN-based visibility, the VEN can report outbound communications to FQDNs in addition to IP addresses, ports, and protocols. As the VEN writes flows to its local traffic database, it also checks the VEN DNS cache and maps FQDNs with outbound flow data. When there is a match between the destination IP address in the flow logs and a record in the DNS cache, the VEN adds the FQDN to the outbound flow records. Once the VEN reports flow data to the PCE, the PCE presents the outbound DNS-based traffic flows in Illumination in near real-time as well as in Explorer for historical data retention.
DNS Enforcement
The Illumio Core allows security teams to write allowlist policies that allow communications across workloads or between workloads and IP addresses. FQDN-based enforcement allows users to control which DNS hostnames or FQDNs that each managed workload can communicate to without the user needing to understand the IP addresses tied to that FQDN. Once an FQDN gets allow-listed by the policy, the PCE sends firewall instructions to the VEN and the VEN creates an FQDN policy table. This policy table tracks the allow-listed FQDN as well as which ports and protocols the workload is allowed to use for outbound communication to the FQDN. The VEN also checks the local DNS cache table for IP listings.
Wildcards
The FQDN-based rules support wildcards such as *.google.com, s3*.aws.amazon.com, and proc1.azure*.com. Wildcards are expanded to zero or more of the characters in [a-z|A-Z|0-9|-]. Wildcards are allowed at the end of the FQDN, for example www.google.*.
Illumio recommends the use of wildcards for the same patterns. This will help reduce rather than increase the number of FQDN-based rules with the same patterns. For better performance, when you write FQDN-based rules, limit the number of rules to around a 100 entries.
FQDN-Based Rule Requirements and Limitations
FQDN-based visibility and enforcement is subject to the following requirements and limitations:
- Requires Illumio Core 19.1.0 or later.
- Supported for any Linux OS that is supported with the Illumio VEN 19.1.0 release.
- Supported for any Windows OS that is supported with the Illumio VEN 19.1.0 release.
- Solaris and AIX workloads are not supported.
- Visibility and enforcement for DNS-based traffic where the source is a DNS hostname is not supported.
- FQDNs can be described in IP lists or virtual services, but not in an unmanaged workload interface.
- When using virtual services, only one FQDN (wildcard supported) can be specified. IP lists can support a list or a group of FQDNs.
- A mix of virtual services and IP lists are supported.
- A period character is not supported in a wildcard. For example, www.server*.mycorp.com matches www.server1.mycorp.com but not www.server1.farm2.mycorp.com.
- A wildcard-only entry (namely, specifying only “*”) is not allowed.
FQDN Visibility
Illumio does not require any new configuration to gain visibility into outbound traffic towards FQDNs. However, you can create Illumio policy objects to represent an FQDN or a list of FQDNs. In the following example, Illumination presents outbound FQDN flows when there are no policy objects created. A web server is fetching updates from us-west-1.ec2.archive.ubuntu.com.
You can create an Illumio policy object, such as an IP list or a virtual service to represent the FQDN shown in this example.
Create Policy Objects for FQDNs
IP List
By default, you can leverage IP lists to describe IP ranges, groups, and subnets. From the 19.1.0 release on, you can use IP lists to describe FQDNs.
You can use the previous example (us-west-1.ec2.archive.ubuntu.com) to create an IP list for FQDNs:
- From the PCE web console menu, choose Policy Objects > IP Lists.
- Click Add.
- Enter a name (can be a custom name).
- In the IP Addresses and FQDNs field, enter one or multiple FQDNs (wildcards are supported).
- Click Save.
- Provision the changes.
Based on the example above, these methods of describing the specific FQDN are supported or unsupported.
Supported
- us-west-1.ec2.archive.ubuntu.com
- us-west-1.ec2.*.ubuntu.com
- *.ec2.*.ubuntu.com
- us-*.ec2.archive.ubuntu.com
The syntax below is supported; however, it does not describe the FQDN in the example.
- ubuntu.com
- *.ubuntu.com
You can use a wildcard in the IP list, such as *.ec2.archive.ubuntu.com as shown below.
Example of the traffic in Illumination:
Virtual Service
When you have created an IP list to describe the FQDN, you do not need to create a virtual service to describe the same FQDN.
You should only create a virtual service for an FQDN when you do not want to create an IP list:
- From the PCE web console menu, choose Policy Objects > Virtual Services.
- Click Add.
- Enter a name.
- Enter a service or port.
- Enter your R-A-E-L labels for the FQDN.
Click Add FQDN and enter an FQDN.
- Click Save.
- Provision the changes.
Based on the example above, these methods of describing the specific FQDN are supported or unsupported.
Supported
- us-west-1.ec2.archive.ubuntu.com
- us-west-1.ec2.*.ubuntu.com
- *.ec2.*.ubuntu.com
- us-*.ec2.archive.ubuntu.com
The syntax below is supported; however, it does not describe the FQDN in the example.
- ubuntu.com
- *.ubuntu.com
This example of a virtual service represents *.ec2.archive.ubuntu.com.
Example of traffic to the virtual service in Illumination:
Write Policies to Allowlist FQDNs
IP List
The syntax and ruleset structure for IP list policies does not change for FQDNs.
See the following example:
Virtual Service
Writing a policy against a virtual service for an FQDN is the same as writing a policy for an IP-based virtual service.
See the following example that uses the Ubuntu Repo (*.ec2.archive.ubuntu.com):
