Wildcard domain matching on the FTD

[Alex-Pr]

I am trying to limit internet access for a server that needs access to several wildcard based domains and I can't figure out if that is possible on a Firepower FTD managed by FMC

As an example, one of the requirements is
*.compute-*.amazonaws.com - TCP 80, 443

My understanding is that wildcards won't work in an FQDN based access rule.

Is a workaround to have a url based rule to allow .amazonaws.com ?

I am confused if this will work as I have only seen URL matching for filtering (blocking) and the other piece of the puzzle is it takes 5 or so packets of a http request before the URL is even seen...

This post talks a bit about creating the wildcard for URL
https://community.cisco.com/t5/network-security/using-wildcard-in-url-filtering/td-p/3196891
Firepower does support wildcard, but not this format like (*.microsoft.com) rather it support (.microsoft.com) format. You can create a URL object with value (.microsoft.com) for blocking all microsoft.com domain, it will block for support.microsoft.com/ www.update.microsoft.com/ or any other sub domain after .microsoft.com. So use dot(.) instead of asterisk(*) it will work fine. I am testing it in production environment.

This article specifies that the wildcard won't work as an access rule
https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/214505-configure-fqdn-based-object-for-access-c.html

Thanks

[Marius Gunnerud]

If you configure a url object (ex. cisco.com) and reference that in the rule, this will match any url that contains cisco.com.  This could be tools.cisco.com or even cisco.com/some-page.  So it is not a wildcard per se but will act much like a wild card.

[perryj1]

I'm working on a similar issue with Office 365. Aldex-PR, did the below suggestion work for you? 

[Alex-Pr]

The way that I find works best is URL matching.

It is not quite a wildcard match but close.  It basically allows all the subdomains and directories

as example, of you create it as microsoft.com it will allow as *.microsoft.com/*

How the match is made is when the URL is seen the first few packets.   So essentially the ACL will allow the handshake to start and will then kill the session if it cannot match the URL.

To do it

1 - Create URL objects 

as example microsoft.com   (don't put a * or . in front)

2 - Create a ACL

Make your destination network ANY (or geographically limit etc)

Dest Port HTTP/HTTPS etc

URLs - Enter your group of URLs

Note that this will not work for protocols that don't send a URL in the first few packets.  

FQDN matching - I don't think this will work for what you are doing. Basically how it works is it is creating a dynamic ACL by periodically querying the FQDN's that you tell it to.  So if you don't know every subdomain that it will use you are hooped.

As for O365, what you may need to do if the URL object doesn't get it to work is create a network group with the 10 or so large network ranges they have listed on their support sites (way more if you are doing IPv6).  from there create a ACL that matches an ip from that range and the port.

Good luck.

Thanks

[Mike.Cifelli]

@perryj1 I have actually had more success in some scenarios setting up an FQDN network object.  Especially in scenarios where remote side IPs change frequently.  Setup a new network object (fqdn), and assign this object in your ACP as the destination.  As long as you have DNS setup properly this should work.  From FTD command line you can issue > show fqdn to verify resolution.  

[perryj1]

Thanks for the advice. While I believe the URL method should work, the potential for the many URL's that MS uses to change has led us to try and automate updating the object group in FMC that we will use in our ACP.