the idea of the global allow list (or global whitelist) is to add trusted destinations there. When thinking about a large company you usually have dozens of intranet sites which usually can be excluded from scans since you can trust them. For many customers this reduces the load on the proxies, which could be desirable in some cases.
Generally - similar to everything else in MWG - it is up to you to decide whether there are hosts/networks you trust or not. A global allow by client IP may make sense for some servers polling updates since not in all cases the updates you obtain are suspicious. Also in many cases functionality is considered more important than security, so in cases a website does not behave as expected *some* customers tend to simply whitelist everything, rather than looking into every problem in detail and find out what exactly is causing issues.
In regards to your query:
1.) This approach does not make too much sense. AV scanning is the most expensive operation you can do on MWG and it makes sense to do the AV scanning close to the end of your policies. All potential block/whitelist rules that could help MWG to apply less AV scanning are helpful in regards to performance. For example it does not make sense to apply AV and then apply a strict URL filter rule set. MWG will AV scan everything and then eventually block it. It makes more sense to have URL filter on top, since it can already block content and blocked content does not need to be scanned by AV.
Assuming you follow this guideline AV should be close to the end of the rule set. So there is not too much use when calling "Stop Cycle" after AV, since most expensive tasks have already been done. If this is what you desire it is certainly possible.
2.) If you apply "Stop Ruleset" it will only leave the global allow list rule set, no filters are bypassed. As you stated for ALL interesting rule sets like URL Filter, Media Type, SSL Scanner, AV, etc you have to add a similar "Stop Ruleset" rule which refers to the whitelist. Depending on where you put such a rule adding one URL will skip multiple rule sets, you will not have the ability to granularly decide which filters are skipped and which are not, for each whitelist entry the same rules apply.
If would be easier to think about "another approach" if you can illustrate what the problem/concern is, e.g. what causes problems and needs to be whitelisted, etc.
Many thanks for your insights. OK, my goal would not be achive best performance regarding these sites, but at least enforce AV. Situation: often a "partner" or B2B website must be listet, as i.e. authentication is not working properly (some applet not using the system settings), or a corrupt media type pops up, or a ssl common name missmatch blocks the connection or the site is uncategorized. And what is more problematic, it is often a combination of 3 or 4 of these things. We have support personel then looking for the easiest way out: Global Whitelist, and all is working. So yes, these sites are given some sort of trust, but at least we want to enforce AV checking.
We already have some Custom Bypass rules in place, but usually either bypass authentication, or ssl content inspection, or application filter.
What do you think?
1 of 1 people found this helpful
I think I start to understand :-)
If all you worry about is applying AV you could extend the global allow list. You could leave a "real" allow list that just stops everything and add a second "limited" allow list that applies AV only. By doing so you will eliminate most filters that could cause trouble, but AV will remain enabled for these URLs.
I would do something like this:
I left the "normal" white list in place. You can add hosts which should not be touched by MWG here.
Then I added an "AVonly" rule set, which will apply AV and block if something malicious was found, otherwise it stops the cycle ("allow access"). I added some more rules to allow efficient AV scanning such as the opener for extracting files and data trickling as a progress indication method. Other modifications such as Web Cache or Progress Pages will not be used here.
Note: I have not tested it and it is not a commonly used rule set, I just created it a few minutes ago - it should just demonstrate some options :-)
Nachricht geändert durch asabban on 06.11.13 10:40:43 MEZ
Yep, exactly what I had in mind, thanks for you opinion and insights on data trickling.