topic Block Wildcard in Network Security

Block Wildcard

ssan239 — Mon, 08 Apr 2024 14:56:57 GMT

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

Re: Block Wildcard

MHM Cisco World — Mon, 08 Apr 2024 15:28:09 GMT

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

Re: Block Wildcard

Eric R. Jones — Mon, 08 Apr 2024 21:20:59 GMT

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

We do this for our block list

Re: Block Wildcard

tvotna — Tue, 09 Apr 2024 17:43:52 GMT

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.

Re: Block Wildcard

Marius Gunnerud — Wed, 10 Apr 2024 12:28:29 GMT

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.

Re: Block Wildcard

tvotna — Wed, 10 Apr 2024 15:15:27 GMT

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.

Re: Block Wildcard

Marius Gunnerud — Wed, 10 Apr 2024 16:55:46 GMT

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.

Re: Block Wildcard

tvotna — Thu, 11 Apr 2024 10:00:30 GMT

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