URL filter rule for “directory” part in URL ?

[Younghwan Kim]

Dear,

I have a question about “Block and Allow Lists with URL filter function on ASA w/ FirePower”

When we using “URL Filter function”, is possible to we can create manual url filter rule(or access list) as like bellows?

Allow to

http://hosta.com/abc/

Block to

http://hosta.com/def/

My question is, can we using wildcards for “directory” part in URL ?

In my understanding,  if we using filter conditions with exact match  as like as “abc/” and “def/”(not “abc*” or  /*abc/)

then we can create above  “Block and Allow Lists”, is my understanding correct?

Best Regards,

[Marvin Rhoads · Accepted solution]

I don't believe you can use wildcards in URL conditions. Reference:

http://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/118852-technote-firesight-00.html#anc14

So - yes - your match conditions must be exact. Also note that is https is being used then you would need to be decrypting in order to go beyond the domain name in the string.

[Younghwan Kim]

Hi Marvin-san,

Thank you for you reply. 

One more question about this,

Q.How we possible to decryption the URL information in HTTPS traffic?

Is it means we need install(enable) the "SSL Decryption" function?

OR 

Regarding to your answer and following document

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/Access_Control_Rules__URL_Filtering.html#concept_292D0D26F9414181910DCC3265D95E91

Filtering HTTPS Traffic

You can configure SSL inspection to decrypt HTTPS traffic, so that access rules evaluate the decrypted session, which improves URL filtering capabilities. For any traffic that you do no decrypt, the access rules evaluate HTTPS sessions with the following limitations.

When evaluating web traffic using access control rules with URL conditions, the system matches HTTPS traffic based on the subject common name in the public key certificate used to encrypt the traffic. The system disregards subdomains within the subject common name, so do not include subdomain information when manually filtering HTTPS URLs. For example, use example.com rather than www.example.com. In contrast, HTTP filtering considers the entire host name, including subdomains.

Also, the system disregards the encryption protocol (HTTP vs HTTPS). This occurs for both manual and reputation-based URL conditions. In other words, access control rules treat traffic to the following websites identically:

• http://example.com/

• https://example.com/

Above document meaning that we can not decrypt "Directory" part in URL too? and It means we can not using the "Directory" part to using access control rules with URL conditions?

Best Regards,  

Kim

[Marvin Rhoads · Accepted solution]

You're welcome.

That's correct - to go to any level below what is identiifed in the CN portion of the certificate for traffic that is encrypted with SSL/TLS, you need to have a SSL decryption policy for the traffic in question.

If the traffic is general outbound Internet traffic than you need to have a decrypt and resign policy with every one of your clients trusting the certificate used by FirePOWER as it acts as a "man in the middle". Typically this means you have an established PKI whereby you have pushed that certificate to all clients' trusted certificate store. Note that this solution does not always work as some applications use a feature known as "certificate pinning" designed to prevent just such traffic interception. Even when it does work, it requires significantly greater CPU resources to decrypt, inspect and then re-sign the traffic. 

If the traffic is inbound to a server you operate and maintain, it is possible to replicate the server certifcate and private key onto the FirePOWER device for use in doing this action.