I would like to ask for help regarding few problems I encountered during 2 months of Web Gateway 4000 + Web Gateway Reporter usage. First, few words about my McAfee environment:
- Web Gateway 4000 version 7 (188.8.131.52.0 11447)
- Web Reporter Premium 5.2.0.02, build 1105
Problem 1. - Web Gateway
- incorrect categorization of URL's in Web Gateway logs - I configured my environment so that Web Gateway is sending logs to Web Reporter. If I check logs that Web Gateway sends, I can see that every URL gets correctly categorized except URL's that I defined on "Anti-Malware URL Whitelist" on my Web Gateway. Those URL's are categorized with "-". If I remove those URL's from "Anti-Malware URL Whitelist" they get categorized correctly. My "Anti-Malware URL Whitelist" is first rule in my "Gateway Anti-Malware" rule set, which itself is third rule set behind "Authenticate" and "Progress indication" rule sets.
Problem 2. - Web Reporter
- [invalid selection] text for some of my AD groups - when I use "Search Directory" option in "Add User Name Filter"/"Users & Groups"/Group, I can see my domain and all of my Active Directory groups, but few (6 out of 80) groups have [invalid selection] text in front of their name and cannot be selected.
Problem 3 - Web Reporter
- I am unable to remove groups from Web Reporter internal database - at some point, i created filters inside Web Reporter that used some of our AD groups. As I don't want to have those groups in any of the reports anymore, I deleted filters that I created and removed any reference to AD groups that were part of that filter. Still, I continue to see those groups in reports that do not use filters. Is there any way to delete groups from Web Reporter internal database?
My biggest problem at the moment is Problem 2., but I'd like to get answers to other problems too
I've managed to find solution to Problem 2. by myself. It seems that [invalid selection] is only shown for groups that have "," in their name. When I remove "," from the group name, group is available for selection. I tried it on both existing and new groups (that I created to confirm this) so I can confirm that it is working.
OK, one down, two to go ... ...
1) The dash is just a place holder for uncategorized. In Web Reporter, dash is just the default value for everything... For example, if you don't configure a directory, or attached it to your log source, the users will appear in dash. (-\jdoe). The sites in your access log with - for the category will occur for any site that is bypassing the categorization. If your Anti Malware Whitelist comes before the categorization, then it will be uncategorized.
If you are running 64-bit Web Reporter, you can enable categorization and have Web Reporter categorize those URLs during import. But then your reports will not match what was enforced as policy. As an example, if www.gambling.com was put in a white list for testing and then forgotten, you might later see jdoe joing to the site. Your report will show it categorized and you may not know why because gambling category is blocked by policy. If it was a dash, it would be a clue that you have a whitelist entry somewhere allowing the traffic. But the choice to have WR categorize it or not, is yours.
2) On your directory configuration, for the group key, did you put "memberOf" ? try removing the group key if you are using memberOf with Active Directory and see if that clears the problem.
3) Sorry, but you can't. Once values have been loaded they cannot be removed.
Thank you for your reply. I've been thinking about what you wrote under 1.), but it doesn't seem logical to me that sites will not be categorized on Web Gateway because of them being in the ruleset which is higher than Category Content Filter rule set. Shouldn't categorization be done immediately for each URL, and category filter be just that, filter?. I suppose we could move Category Content Filter higher, but I am not certain which rule inside that rule set covers categorization of URL's. Can you help with that information?
As for your reply to my second question, we don't have anything defined under "memberOf". We settled on removing "," from the AD group name for now, but we would like to see more complete solution.
As for your reply to my third question, that is really unfortunate and is something McAfee should really think about implementing in Web Reporter. Because at some point in time we used groups that we don't want to see in our reports now, we have situation that all major reports show duplicate groups. We worked around it by creating filters containing all groups we want to have in our reports, but there are many and it is manual job to keep track of new groups and change membership of filters.
Regarding number one, I cannot comment on the reasons for the implementation, that is just the way it works. URLs are not categorized until a rule references URL.categories. I tested a quick work-around by adding a rule at the top of the whitelist ruleset that had criteria "URL.categories contains Alcohol", and action Continue.
Since the rule says continue if the category contains alcohol, it doesn't block it. And it doesn't take any action for other categories. So it's harmless, but doesn't really make much sense when looking at it. I can't really think of anything available in the options that would. So you are free to make a different choice if you would like. I would recommend putting a comment on the rule to explain it's purpose.
For number 2, that seems like a bug. I'll have to test it. If I can reproduce the problem, I'll file a bug report with engineering.
My personal preference for the that dry-fire rule at the top for categorization is the check for uncategorized sites:
List.OfCategory.IsEmpty (URL.Categories<Default>) equals true
Like Shawn said, it's arbitrary as long as the action is Continue, the lookup is performed.
The reason we don't categorize every URL all at once under normal circumstances at the very tops is you don't always need to or want to.
You are allowed multiple URL filtering configurations with many different parameters like cloud lookups or reverse DNS lookups and even which GTI server you want to use or which next-hop proxy the cloud lookups go through. You may need something categorized differently from one set of users than another. Maybe people in subnet A do cloud lookups to get the Geolocation of their URLs but people in subnet B only need to lookup against the local database-onbox. Or traffic on proxy C must use an explicit proxy in their DMZ to get to the the cloud lookups, but proxy D cannot access the same next-hop.
Or maybe you want to do 2 lookups. One on-box to see if it's uncategorized (faster) and if so, a second to check the Geolocation to block the country you are going to.
The categorization process itself is not static. One size does not fit all.
Plus, You don't categorize private IP addresess or internal .local domains. Why bother when the result will always be false?
With the way it's designed, you have way more flexibility with your controls.
Thanks eelsasser, now when you explain it like that, it does make sense. Problem is that I don't remember reading in manual about that, or even if I read it, I suppose it didn't stick in my mind. It could really be one of those things in manual that are bold and with exclamation point ... or better yet in some FAQ section.