topic Re: Wildcard domain matching on the FTD in Network Security

Wildcard domain matching on the FTD

Alex-Pr — Thu, 18 Feb 2021 21:27:04 GMT

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

Re: Wildcard domain matching on the FTD

Marius Gunnerud — Thu, 18 Feb 2021 22:27:33 GMT

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.

Re: Wildcard domain matching on the FTD

perryj1 — Wed, 20 Oct 2021 14:52:37 GMT

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

Re: Wildcard domain matching on the FTD

Mike.Cifelli — Wed, 20 Oct 2021 15:04:58 GMT

@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.

Re: Wildcard domain matching on the FTD

Alex-Pr — Wed, 20 Oct 2021 20:56:47 GMT

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

Re: Wildcard domain matching on the FTD

perryj1 — Thu, 21 Oct 2021 14:15:29 GMT

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.

Re: Wildcard domain matching on the FTD

atsukane — Wed, 05 Nov 2025 15:38:28 GMT

I know this is a 4 year old thread, but thanks @Alex-Pr

We had a requirement to allow wildcard access to a remote SQL server over tcp/1433, with the host portion of destination URL can dynamically change.

I've tested with 2 rules, one using a wildcard network FQDN object in "subdomain.domain.com" format (no leading "dot ."), and another rule using a wild card URL object, both have port specified to tcp/1433.

The rule with network FQDN object did not work, but URL object works.

Initially, after reading Solved: Using wildcard in URL filtering - Cisco Community i've added URL object as ".subdomain.domain.com" with the leading dot, this worked fine.

then after seeing this post, removed the leading dot and tested, and the access is still still working, so not entirely not sure what to make of the significance of the leading dot.

Thanks