Firepower URL Filtering on non https/http outbound traffic

[GDS2023]

Hi,

We are trying to create a rule to allow outbound sftp, ssh & sql traffic based on URL/hostname but we are not getting any luck.  We are seeing the traffic but it is being captured as Application and IP address without any url/hostname information.   

I'm wondering if this is only possible on https/http traffic?    Any help would be appreciated.

Thanks,

GDS

[MHM Cisco World]

sorry I dont get your request url for ssh and sftp?

Maybe you looking for using fqdn for ACP?

If Yes then check below 

https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/214505-configure-fqdn-based-object-for-access-c.html

MHM

[GDS2023]

Thanks for your reply.  FQDN sounds like a solution which I have tried.  Work on the first time but not after the fqdn host got a new IP.

[MHM Cisco World]

Can you more elaborate 

Thanks 

MHM

[GDS2023]

I'll try my best with the screenshot.   Hope you'll get what I meant.

1. Created network object FQDN-TEST with the value of www.google.com

2. Added a BLOCK rule from my data zone/network to FQDN-TEST

3. Before applying the rule, I can ping www.google.com

4. After applying the rule, www.google.com times out

5. After a while, www.google.com is resolving to a new IP.  Ping is allowed and not hitting the block rule.

[MHM Cisco World]

It can be issue the dns expire entry time is high so the dns not resolve new IP.

From fmc 

Devices > Platform Settings > DNS.

Can you reduce it and check again.

[GDS2023]

Sorry, I should have mention that the FTD is managed locally and not with FMC.   

Looks like default poll time is 4 hours.  I'll lower it for testing and will report back. 

[tvotna]

@GDS2023, FQDN-based rules have never been working properly on either ASA or FTD and will never work, so don't use them. The problem here is that many large enterprises like Google or Cisco use round-robin DNS. Their DNS servers respond with a subset of IP addresses (or a single IP) to a DNS query. FQDNs you configured on FTD in an ACP (or FQDNs configured in an ASA ACL) are resolved by the firewall itself. The client behind the firewall also resolves the same FQDN. Obviously, it is not guaranteed that the firewall and clients get same IP address from the outside DNS server. In this case, when the client sends a packet, the firewall cannot find an entry in its DNS cache for the packet's destination IP and hence cannot apply proper ACP rule or ASA ACL.

This basically means that entire implementation is broken.

ASA has Botnet Traffic Filtering feature with a different design. Instead of resolving FQDN configured in an ACLs, ASA sniffs DNS requests and responses and populates cache from DNS traffic. This is a completely different story, but at some point the feature was deprecated.

Later Network-Service Objects were implemented on ASA with a somewhat similar idea and code ported to FTD. But on FTD this is still an ASA/Lina feature and hence can be used in PBR only. It cannot be used in ACP, so far as I know.

DNS requests themselves can be filtered on FTD by either local DNS policy or by cloud-based Cisco Umbrella. This means that the client will either receive NXDOMAIN or be redirected to a sinkhole for certain FQDNs.

[GDS2023]

This explains the intermittency I'm seeing.   Thank you for the excellent explanation.  Much appreciated.

[MHM Cisco World]

That correct if the FTD keep one entry for each fqdn' 

As I know the ftd keep multi IP for same fqdn' and drop traffic destiantion to thesee IP's.

Fqdn work well in ftd ? I am with you with this point but let him try' I know there are some bug but cisco secure team always work hard to fix this bug.

MHM

[GDS2023]

"As I know the ftd keep multi IP for same fqdn' and drop traffic destiantion to these IP's."  Is there a way check on FTD if the fqdn keeps multi IP?

[MHM Cisco World]

aleescob# show dns
Name: talosintelligence.com
  Address: 2001:DB8::6810:1b36                          TTL 00:05:43
  Address: 2001:DB8::6810:1c36                          TTL 00:05:43
  Address: 2001:DB8::6810:1d36                          TTL 00:05:43
  Address: 2001:DB8::6810:1a36                          TTL 00:05:43
  Address: 2001:DB8::6810:1936                          TTL 00:05:43
  Address: 192.168.27.54                                  TTL 00:05:43
  Address: 192.168.29.54                                  TTL 00:05:43
  Address: 192.168.28.54                                  TTL 00:05:43
  Address: 192.168.26.54                                  TTL 00:05:43
  Address: 192.168.25.54

 https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/214698-understand-fqdn-feature-on-firepower-thr.html

MHM

[GDS2023]

Thanks!  The one listed below was the initial IP before adding the rule.   I'm pretty sure it changed to something else during my testing but it only kept the initial one.

EDIT:
See below:  So it looks like it keeps multi IP.

[tvotna]

@MHM Cisco World, this is not a bug. This is bad design of the product. There is a doc bug which discourages use of FQDNs:

CSCwi04109 DOC ASA/FTD guides should discourage use of FQDN rules that can resolve into high number of IPs
Symptom: This is a doc defect. ASA/FTD Configuration Guides should discourage the use of FQDN based rules when associated with FQDNs that can resolved into a high number of IP addresses, such as hundreds or more (example "cylance-optics-files-use1.s3.amazonaws.com"). Efficacy of using FQDN rule for this nature of DNS A record and IPs returned is very low, considering that the chances for a resolved IP used by the source client when initiating the connection to match an existing DNS entry on the FTD is very small. (for the FQDN above for instance which can resolve into 2,600 addresses or more, and that in default settings the firewall will end up having about 100 addresses on its DNS database, the efficacy is of approx. 4%) ASA and FTD Configuration Guides should encourage customer to use instead URL and/or IP based rules whenever possible when associating with FQDN behaving as above.

[MHM Cisco World · Accepted solution]

I dont know what is not clear in my pervious statement' let him try and check.

@GDS2023 use fqdn and monitor even check if ftd block traffic' if not

You need to manually add IP to SI blacklist IF the fqdn not solve your issue.

MHM