Great, but i´m not able to import the RuleSet.
i removed all RuleSets, saved the configuration and tried to import you xml file.
Import works, but when i try to save the changes i get an error message
error.JPG 114.6 K
can you try to clean all elements prior to the import? All rules, all lists, all settings and retry the import? If that still fails then, please send the log of the coordinator and UI.
you are fully right, when removing all Rule Sets, Lists and Settings i can import your policy.
Btw, can i run into any troubles when sorting the rule set?? Such as sorting the Rule Set you posted here.
- Moving WebCache to TopLevel
- Moving AcctiveX Controls to TopLevel
Can i run into any troubles when sorting this way??
I think, many customers will sort the ruleset for themselves.
- Could it be possible to place a RuleSet entry (HTML Opener, Composite Opener) in the wrong way?
1 of 1 people found this helpful
some insides :
Web Cache: can be theoretically placed everywhere as we will cache based on the original request, unless it has been blocked (Block, Authenticate, etc)
Moving ActiveX to top, theoretically yes. However, remember the cycles. ActiveX will be done in every cycle you have enabled. Doing it is request cycle doesn't make any larger sense as you are generally not posting HTML pages out that much.
HTML Opener, Composite Opener should be place above rules that require it. The order is not important, as once enabled, they will remain enabled for all rule sets comming underneath.
Generally I suggest to structure your rule sets according to the cycles, whereas allow lists and block lists shall remain at the top.
Hope that makes sense,
you are absolutely right, anyone who is aware with MWG7 will not make a mistake.
But, new users/admins or RTFM admins could make bad mistakes.
By moving out ActiveX Controls from "HTML Filtering" RuleSet to a TopLevel Rule Set all ActiveX filters are not working any more. Is this right?
"Enable HTML Opener" can be defined several Times. Could i run in any troubles by doing this??
When defining multiple "Gateway Antimalware" RuleSets, the content will be scanned several times??
I see the following problem when implementing MWG7.
- Admins are changing the rule set and filters are not working any more
- There is no logical test when saving the ruleset to prevent "missing Openers" etc.
I know, MWG is designed as an "open system". This is absolutely great, but there can be also some bad "problems" at customers.
1 of 1 people found this helpful
<....> (taking a deep breath )
I think the question is more on understanding how the MWG rule engine is working in general. Let me try to take an approach to explain that better.
Generally, MWG knows 4 cycles.
Request, Response, Embedded, Log
If you know ICAP, it is fairly easy to compare as this is nothing else but reqmod in ICAP. It is the cycle in which the product handles all objects being transferred FROM the CLIENT TO the SERVER. This is not only the request, such as GET www.xyz.org, but also stuff that is posted to the net, such as uploads, forms, even this post(as soon as I hit 'Post Message').
Everything that is being retrieved from the server, respmod in ICAP. Remember Usually After a Request there is a response. GET www.xyz.org will trigger the server to send data to you, whereas on a POST there is not necessarily a response, however in most cases there is.
A cycle for everything that is part of anyting else. If you want to be able to scan inside an archive, you will need the embedded cycle. Archive members are embedded into the archive as container for its content.
Is not really steerable via the rule engine as it runs automatically at the end of each transaction* to log its outcome.
*transaction=current traffic over the web gateway, request for each single object
For every cycle the rule engine will restart at the top and look at the rule sets marked to be executed on this cycle.
In case you want a rule set to do either scanning in HTML (HTMLOpener) or in Archives, Documents, etc. (all CompositeOpener; Opener for all objects, which are composed out of different ones), you need to enable the respective opener ABOVE that rule set in the tree - it will remain activated for the rest of the cycle then. If you have the requirement to handle objects differently, you can create different openers under settings and use them as part of the rule engine.
something you must keep in mind is that the last activated setting will be the one to steer the opener, e.g. if you want to be able to scan <div></div> in HTML and have that enabled in a call to the opener (EnableHTMLOpener) with a setting A in one of the rule, but your last call was for an opener with a setting B who hasn't that enabled, you won't be able to scan for this.
Composite Opener is different as it doesn't have a setting, so it will have the same functionality all the time and will just we enabled again (which isn't an issue). To recall, the Composite Opener is in charge of
- Extracting embedded objects from the composite objects - archives, OLE2-based documents, etc.
- Extracting text
So, keep in mind when structuring the tree of Rule Sets, you should, based on best practises think of it as a cone or trinagle standing on the apex:
Based on the above you should be able to easily figure what your policy is going to look like. There will be for sure gotchas, exempts, different ways to solve it, but this is the general concept idea.
hope this helps,
Message was edited by: Michael Schneider on 06/09/2010 14:19:30 CEST
great Answer. This is the information we need and what is missing in any product manual.