Block Wildcard

[ssan239]

Hi Team,

We have a requirement to block wildcard domain for example *.xx.xx. As this is wildcard we dont see an option to block it in FTD(Managed using FMC). Please suggest a best way to block this wildcard in FTD. 

Regards,

Sanjay S

[MHM Cisco World]

You can use SI dns policy' you can in notepad add domain then fed it to FMC and use in ACP SI.

Did you try that?

MHM

[Eric R. Jones]

Is this the process your speaking of? https://safe.menlosecurity.com/doc/docview/viewer/docNDCCEB78C228273e1953362d6e58abe0aede2f9b72dfcc5bdc716e33a263d9ea0ed0150b5bedf.

We do this for our block list

[tvotna]

There is a good doc on this:
https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/214852-block-dns-with-security-intelligence-usi.html

The document claims that blocking a domain also blocks sub-domains, although I'm not sure. This needs to be tested.

[Marius Gunnerud]

The URL in FTD is a string match.  So, for example, blocking facebook.com will also block chat.facebook.com.  Add a deny statement at the top of the ACP blocking the base domain and this should also block subdomains.

[tvotna]

IMO, manual URLF for HTTPS would require either Decryption Policy or TLS Server Identity Discovery for TLS1.3 and matching by CN instead of host portion of the URL itself. This should also work, but there is a chance to face with CSCwi76002 or CSCwf35573 or something similar.

[Marius Gunnerud]

I would agree if you are going to inspect the packet details.  However, the poster is only looking to block the URL / domain and subdomains which is not encrypted in the HTTPS header.

[tvotna]

@Marius Gunnerud, HTTP header is of course encrypted in both TLS1.2 and TLS1.3. You mean SNI extension in the Client Hello probably, which is not encrypted, right? My understanding of official documentation and TACSEC-2002 (Las Vegas 2023) is that manual URL filtering (URL object in ACP rule) doesn't use SNI and relies on server certificate CN instead, if decryption policy is absent:

Documentation:

To filter encrypted traffic, the system determines the requested URL based on information passed during the TLS/SSL handshake: the subject common name in the public key certificate used to encrypt the traffic.

HTTPS filtering, unlike HTTP filtering, disregards subdomains within the subject common name. Do not include subdomain information when manually filtering HTTPS URLs in access control or QoS policies. For example, use example.com rather than www.example.com.

On the other hand, from TACSEC-2002 it appears that Security Intelligence URL lists and feeds can use SNI, but this is not documented officially.

Documentation is awful.