FTD FQDN objects

  • Post author:
  • Post category:Cisco / FTD

The FQDN ACL feature allows the Firepower Threat Defense (FTD) firewall to use FQDN objects in the Access Control Policies (ACP). For this functionality to work, the FTD must be able to resolve the FQDN’s to an IP address, the FTD stores these in its cache.

  • Wildcard like *.google.co.uk is NOT supported
  • FQDN resolution occurs when the FQDN object is deployed in an Access Control Policy.
  • Once the DNS TTL (Time-To Live) expires, the FQDN is resolved again.

FQDNs in Access Control Policies are supported on both FDM and FMC managed FTD devices. This post covers configuration using FDM, the GUI screenshots are slightly different using the FMC, but it’s the same procedure, the CLI commands are identical.

Configuration

  • Create a Network Object
  • Select FQDN and configure the domain name

  • Repeat for multiple FQDNs

  • Modify the Access Control Policy, reference the FQDN objects in the Networks column

  • Create or modify a DNS Server Group

  • Deploy the policy to the FTD

Verification

  • Login to the CLI of the FTD
  • Run the command system support diagnostic-cli
  • Run the command show dns

From the output below, we can see already the FTD has resolved the DNS entries configured. Notice the TTL (Time-To Live) is unique per domain name, this is because each website can select the TTL for each DNS domain.

We can confirm the configured TTL by taking a packet capture.

  • From the CLI of the FTD create a packet capture for DNS traffic
capture DNS interface outside match udp any any eq domain
  • Run the command clear dns to flush the DNS cache and force the FTD to resolve the FQDN again and allow us to capture the traffic.
  • Run the command show capture DNS to configure the packet capture has worked.

  • Copy the PCAP file from the FTD so it can be opened in wireshark, use the following command:
copy /pcap capture:DNS scp://
  • Open the pcap file in wireshark

From the output below, we can determine the TTL for google.co.uk is 5 minutes (300 seconds) and the TTL for ports.ubuntu.com is 10 minutes (600 seconds).

If you noticed in the output of show dns command previously, the TTL appeared to be plus an additional one minute. The FTD (and ASA) by default always adds one minute to the TTL, resulting in a 6 minutes TTL for google.co.uk and 11 minutes TTL for ports.ubuntu.com.

In some instances, a TTL that is too short could cause issues with the FTD. With the ASA you could configure the command dns expire-entry-timer minutes 60 to set a minimum TTL of 60 minutes to all FQDNs resolved by the ASA. This command is not natively available when using FTD. However, it can be configured using Flexconfig when using an FMC, however this command is not valid when using FDM (as of FDM 6.7).

The screenshot below is of an Flexconfig object, configured on an FMC version 6.7.

Once applied, refreshing the FTD’s cache, we can determine the TTL has increased by 60 minutes

When the FQDN object is created, a unique ID is generated. This ID is associated to the object in the LINA and in Snort the ID is associated with the ACP rule.

  • Run the command show fqdn

From the output below, we can confirm the configured FQDNs, the resolved IP address(es) and a unique FQDN-ID. The ID for the ports.ubuntu.com object is 1005 and google.co.uk is 1006.

  • Run the command show access-list

From the output below we can identify the ACP rule called “FQDN” we created. Notice the RULE-ID which is 268435465, the ACP does NOT reference the FQDN ID only the named object.

  • Run the command expert
  • Navigate to /ngfw/var/sf/detection_engines/<UUID>
  • Run the command cat ngfw.rules

From the output below, we can confirm in the RULE-ID – 268435465 (the same RULE-ID as the ACP) and the “dstfqdn” is 1006, 1005 which is the unique ID of the google.co.uk and ports.ubuntu.com FQDN objects we created.

Testing

Let’s test and confirm network access is using the FQDN firewall rules. From a ubuntu linux computer we will use curl to communicate with google.co.uk, from the output below, we can confirm curl successfully communicated with google.co.uk.

From the FTD we can run the command system support firewall-engine-debug. We can determine from the output that the packet matched the correct RULE ID and the action was “allow”.

By running apt-get update on the ubuntu server, we can generate traffic to the other FQDN object, we will also confirm that FQDN ID 1005 match the correct RULE ID and the action was “allow”.

You can run packet-tracer to confirm traffic matches the excepted rules

If you receive the following error.

Ensure the DNS Resolution is set to IPv4 not IPv4 and IPv6

Re-running the packet-tracer command, will confirm the traffic is permitted and matches the excepted RULE ID.

Tags: , , ,