A recent question on the newsgroups made me realize that perhaps the intent behind the system policy rules is not crystal clear. I thought to share my understanding of the system policy rule base (tho’ it should be recognized that intent is in the mind of the beholder).
The idea of the system policy rules was to allow a base set of traffic to pass, that traffic that is considered critical to getting ISA Server up and running, even when there’s been an immediate problem. The product team planners put a lot of thought in architecting the right set of rules: “right” being that delicate balance between the critical-to-allow-packets and the we-need-to-block-everything-since-we’re-in-a-bind-here-packets. And, so, the rules include allowance for remote management, remote monitoring, access to specific guidance sites from the Local Host, etc, etc. (You can get all the details in the on-line help.) In short, system policy is what allows ISA Server to continue functioning even in lockdown mode, that mode in which no packets are allowed in.
Having said all that without a breath, I should add that, of course, after careful consideration, you can disable one or more of the system policy rules. For example, if you never, ever do remote management using MMC, you can disable the system policy rules that allow remote management. Here’s how:
I always thought of System Policy as controlling key traffic to and from the ISA firewall system *itself*. Thanks! --Tom.
As always, the good doctor adds an excellent point: traffic allowed by the system policy is indeed that to or from the Local Host--that is the ISA Server firewall itself.
When in doubt, use the default settings