cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
nashcoop
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 1 of 8

URL.Smartmatch issues

Jump to solution

The site docs.google.com is filtered as Personal Network Storage, and since that category is in our blocklist, it is blocked. The Google apps named Docs, Forms, Sheets, and Slides all resolve at docs.google.com. However, each of them has a subdomain: Documents = /document, Sheets = /spreadsheets, Forms = /forms, Slides = /presentation. I would like to create a rule which will allow me to add user/group exclusions so they can access docs.google.com/document. I attempted to create a URL.SmartMatch rule which referenced the string "docs.google.com/document/" (without the asterisks) and an exclusion based on my test IP address using "Client.IP is in list." However this rule isn't working. I'm looking for recommendations with the smartmatch rule, or alternative parameters.  Thanks.

1 Solution

Accepted Solutions
mkutrieba
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 8

Re: URL.Smartmatch issues

Jump to solution

Hello @nashcoop,

URL.Smartmatch should also work as you configured it. Based on this article:
https://community.mcafee.com/t5/Web-Gateway-Documents/Web-Gateway-Understanding-URL-related-Properti...
smartmatch can also be used like:
domain.tld/path

  • Is equivalent to URL matches *.domain.tld/path* or domain.tld/path*

What I think happens here, that the first CONNECT cycle is already blocked because of category, means you should only see docs.google.com in rule trace being blocked and if you click on "Top Properties" you should see cycle.name = CONNECT.

In the CONNECT cycle (in HTTPS connection) the full URL is not known without/before SSL scanner is triggered. SSL scanning MUST be done to allow MWG to break SSL traffic and look inside the connection to see full requests. Once this is done, you should see further requests with the path.

If the CONNECT (only URL host seen in rule trace) is really blocked already, then you must configure a bypass rule for the cycles CONNECT and CERTVERIFY first to allow MWG to do SSL scanning. Once these cycles are through, SSL scanning should be done (if not bypassed from it) and then MWG should see the cycle GET request with full URL and then you can filter it.

When SSL scanning is deactivated or skipped/bypassed, then you cannot technically filter for the URL path.

Example bypass rule:
Cycle.Name equals CONNECT OR cycle.name equals CERTVERIFY, Action: Stop rule set

If my information still does not help, I would suggest to open a ticket with support and attach feedback file + rule trace:
FEEDBACK FILE
1) Navigate to "Troubleshooting" > select the MWG you are testing on > "Feedback"
2) Keep the option "Pause running McAfee Web Gateway to create a backtrace (recommended)" enabled (this will NOT stop any service!)
3) Click the "Create Feedback File" button. This way we get your policy, configuration and debug information.
Via CLI:
# /opt/mwg/bin/feedback.sh -l 2

RULE TRACE
1) Navigate to "Troubleshooting" > "Rule tracing central"
2) Select the MWG which currently processes your traffic and enter the client IP you are testing with
3) Press the "Go" button, reproduce the issue and stop the rule trace afterwards
4) Click on "Export" > "Export visible traces..."

Regards,
Marcel Kutrieba
Technical Support Engineer

If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

View solution in original post

7 Replies
mkutrieba
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 8

Re: URL.Smartmatch issues

Jump to solution

Hello @nashcoop,

URL.Smartmatch should also work as you configured it. Based on this article:
https://community.mcafee.com/t5/Web-Gateway-Documents/Web-Gateway-Understanding-URL-related-Properti...
smartmatch can also be used like:
domain.tld/path

  • Is equivalent to URL matches *.domain.tld/path* or domain.tld/path*

What I think happens here, that the first CONNECT cycle is already blocked because of category, means you should only see docs.google.com in rule trace being blocked and if you click on "Top Properties" you should see cycle.name = CONNECT.

In the CONNECT cycle (in HTTPS connection) the full URL is not known without/before SSL scanner is triggered. SSL scanning MUST be done to allow MWG to break SSL traffic and look inside the connection to see full requests. Once this is done, you should see further requests with the path.

If the CONNECT (only URL host seen in rule trace) is really blocked already, then you must configure a bypass rule for the cycles CONNECT and CERTVERIFY first to allow MWG to do SSL scanning. Once these cycles are through, SSL scanning should be done (if not bypassed from it) and then MWG should see the cycle GET request with full URL and then you can filter it.

When SSL scanning is deactivated or skipped/bypassed, then you cannot technically filter for the URL path.

Example bypass rule:
Cycle.Name equals CONNECT OR cycle.name equals CERTVERIFY, Action: Stop rule set

If my information still does not help, I would suggest to open a ticket with support and attach feedback file + rule trace:
FEEDBACK FILE
1) Navigate to "Troubleshooting" > select the MWG you are testing on > "Feedback"
2) Keep the option "Pause running McAfee Web Gateway to create a backtrace (recommended)" enabled (this will NOT stop any service!)
3) Click the "Create Feedback File" button. This way we get your policy, configuration and debug information.
Via CLI:
# /opt/mwg/bin/feedback.sh -l 2

RULE TRACE
1) Navigate to "Troubleshooting" > "Rule tracing central"
2) Select the MWG which currently processes your traffic and enter the client IP you are testing with
3) Press the "Go" button, reproduce the issue and stop the rule trace afterwards
4) Click on "Export" > "Export visible traces..."

Regards,
Marcel Kutrieba
Technical Support Engineer

If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

View solution in original post

nashcoop
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 3 of 8

Re: URL.Smartmatch issues

Jump to solution

SSL scanning is already applied in the rule set, and the example in bold that you provided below is exactly the one I used to create my SmartMatch rule which I found in the community article titled "Web Gateway: Understanding URL related Properties."

Despite SSL scanning enabled, and a SmartMatch rule which should  work, it is not working.

Top Properties is only showing URL.Host docs.google.com. and Command.Name Connect

Is equivalent to URL matches *.domain.tld/path* or domain.tld/path*

mkutrieba
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 8

Re: URL.Smartmatch issues

Jump to solution

Hello @nashcoop,

yes this is why it is wrong, command.name CONNECT shows that block happened in first cycle CONNECT, so before MWG could see the GET request with full URL.

So how it works and what MWG sees:
1) CONNECT - https://www.google.com
(here you possibly block the CONNECT)
2) CERTVERIFY - https://www.google.com
(here SSL scanning would be finished)
3) GET - https://www.google.com/test/file.pdf
(here you can filter for /test/file.pdf)

It is technically not possible to check for a URL path (so anything behind www.google.com starting with the /) in CONNECT and CERTVERIFY cycle. SSL scanning must be finished, that MWG sees the GET request with full URL and then you can filter for it.

Please try my example rule from previous comment and place this in same rule set as category block but above the block rule.
So CONNECT and CERTVERIFY are allowed and not running into the category block rule, then SSL scanning can finish and MWG can finally see GET request with full URL. This GET request does not match this example rule and is not bypassed and further running through this rule set and should then match your URL.Smartmatch rule.

Regards,
Marcel Kutrieba
Technical Support Engineer

If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!
nashcoop
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 5 of 8

Re: URL.Smartmatch issues

Jump to solution

Another McAfee technical support person who has examined a rule trace that I sent hom pointed out that since I have a subrule within the SSL Scanner rule which allows Google IP ranges to bypass scanning that is why "docs.google.com/documents" is not being seen by MWG.  To clarify, I am able to successfully use a SmartMatch rule for just "docs.google.com", so his point does make sense to me why subdomains of that aren't being recognized.

mkutrieba
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 8

Re: URL.Smartmatch issues

Jump to solution

Hello @nashcoop,

I think you misunderstand something and mix up information.

First, /documents is NOT a subdomain, google.com is the domain, docs.google.com is subdomain, test.docs.google.com is a subdomain etc.. Anything behind the domain, so behind google.com (starting with the slash /, e.g. /documents) is a URL path which is not part of the domain.
This information/data is encrypted in HTTPS connections and can technically NOT be seen by MWG without SSL scanning. If you bypass SSL scanner, you will ONLY see dosc.google.com and this is all. If you do not see /documents, so the path, you cannot filter for it.

Please read my last comment again explaining the cycles and where MWG sees something. So you MUST do SSL scanning so that MWG breaks SSL traffic in order to see the content, e.g. URL path. Then you can filter for /documents for example.
Also If the CONNECT cycle is blocked, you will not reach point 3) where you see the URL path.

If this information does not help, please open a SR and attach feedback file and rule trace and tell me the SR number that I can take it. If needed, we could also schedule a remote session for better understanding and discussion.

The article URL related properties also explains difference between URL host, URL path and so on:
https://community.mcafee.com/t5/Web-Gateway-Documents/Web-Gateway-Understanding-URL-related-Properti...

So what you need to check based on available information:
1. let google.com run into SSL scanning
2. make bypass rule for CONNECT and CERTVERIFY cycle in rule set where category block rule is located

Regards,
Marcel Kutrieba
Technical Support Engineer

If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!
nashcoop
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 7 of 8

Re: URL.Smartmatch issues

Jump to solution

Thanks for attempting to help me.  I opened a ticket on line Tuesday afternoon only after I tried reaching tech support over the phone.  I sat in the queue waiting to speak to someone for 20 minutes before getting disconnected.  Community forums and email support are a nice option.  However, I've been using the MWG solution for eight years and I know when I need phone/webex support which is why I first attempted to call for assistance with this issue because I knew it wasn't going to get solved over community forums and emails.  The SR# was transferred to Alok Sarda yesterday, and I have a phone call scheduled with him later today.  

mkutrieba
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 8 of 8

Re: URL.Smartmatch issues

Jump to solution

Hello @nashcoop,

this is sad to hear but I am also a TSE for MWG and what I told you here is the same I would tell you on phone to test (without seeing any data yet).
But Alok can also help really well on this. Otherwise I would have taken the SR so that we could have scheduled a call/remote for this. But to late for now 🙂

Regards,
Marcel Kutrieba
Technical Support Engineer

If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!
You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community