The Predefined Policies such as Web Browser and E-Mail Client contain a DNS Allow rule. I’m wondering if such a rule should be necessary for each application; shouldn’t the system (svchost.exe) resolve DNS for any application?
Likewise for loopback. Shouldn’t one be able to implement a global loopback rule to allow all in/out to localhost, rather than individual loopback rules within each policy?
Finally, why is the Block All at the bottom of each policy required. Even if it is absent, shouldn’t all requests which are not specifically allowed within the policy, be blocked by the global Block All rule?
You don’t need to worry about technical things! :)Unless you are an Advanced User (If you are I can help you predefine policies). But it’s not necessary for each application no, defaults are good enough. As of version 3.9 you simply just “block” and “allow” ANY Alerts, No configurations, etc required while maintaining good network and computer security controlled by Defense+ and Firewall. Loopback is enabled on by default. No need to worry.
“Block all” - I am not sure what you mean here, where is this option?
Hi Josh, thanks for the reply. Yes, referring to CIS version 3.9.
The predefined policies such as Web Browser and so forth, have as the last rule, a rule to block everything, so that anything which is not specifically allowed by a preceding rule in that policy will be blocked. My question was why should this rule be necessary within each policy–shouldn’t the global block all rule (the one at the bottom of the global rules list) block anything which is not specifically allowed within a policy, whether custom or predefined?
Likewise, these policies contain a loopback rule. Shouldn’t one be able to define a global loopback rule, and eliminate the individual loopback rule within each policy? And the same for the DNS rule?
The most important function of a firewall is to block traffic unless it gets permitted by the user. So block is the basic rule and the user makes exceptions to this rule.
Comodo will read rules top down. So it will first see all traffic that is allowed. Finally it will hit the block rule and traffic that was not allowed will now get blocked.
Did this clear up some things? If not, please ask.:-TU
There are various reasons for these rules. First, with regard to the DNS entries. There are a number of well known DNS attacks aimed at svchost, these can be contained by disabling the DNS client service. By, doing so, however, each application will need to perform it’s own look-ups.
Second, not every application uses loopback, so some predefined rules heve been provided for those that do.
Third, having an individual block rule at the end of each policy provides more granular control. This way, specific applications may have a complete rule set, whilst allowing others to be further enhanced. having a single global block rule prevents this.
Eric, yes thanks, I do understand what you have written, but it doesn’t seem to address my questions?
Toggie, thanks for the explanation. I am very interested in the svchost DNS attacks. Would you be able to point me to a starting point to read up on this? If such attacks can penetrate my router (or I am otherwise at risk from such attacks), then I may pursue finding out how to disable the DNS client service, in which case my policies will need the individual DNS rules. However, if the DNS client service is not disabled, then the individual DNS rules within the policies may be removed without ill effect, correct?
Likewise, if one provides a global loopback rule, then the individual ones may also be removed without ill effect, correct? Even though not every application requires a loopback, are there any security considerations in a global loopback rule?
Now the block rules. Please forgive me for being dense, but I still don’t understand the purpose of the individual block rules. Am I wrong that, even without them, the global block rule (assuming it is in place) will catch all non-matching requests, and therefore nothing will be permitted except what is specifically allowed? And therefore the individual block rules could also be removed? What exactly does a global block rule prevent?
Toggie, thanks for the explanation. I am very interested in the svchost DNS attacks. Would you be able to point me to a starting point to read up on this?
Here’s a starting point…
Likewise, if one provides a global loopback rule, then the individual ones may also be removed without ill effect, correct? Even though not every application requires a loopback, are there any security considerations in a global loopback rule?
In all honesty, I haven’t tried this approach. In theory it should work…
Third, having an individual block rule at the end of each policy provides more granular control. This way, specific applications may have a complete rule set, whilst allowing others to be further enhanced. having a single global block rule prevents this.
If you need to identify problems with any given rule set, having a global block rule makes that task more difficult. Having individual block rules with logging simplifies that task.
In all honesty, I haven't tried this approach. In theory it should work...
Okay, thanks. I also think it should work, but not sure how to test it. As far as I know, I don't have any applications which depend upon the loopback, at least not two-way. I just checked my old Kerio configuration on another machine, and there is a loopback out rule, but no loopback in rule, and no application has complained.
If you need to identify problems with any given rule set, having a global block rule makes that task more difficult. Having individual block rules with logging simplifies that task.
Ah, that makes sense. Thanks for pointing that out.
Okay, having now a better understanding of Comodo’s layered-rules approach, I think I can answer my own questions.
Since a connection must be approved by both an application rule and a global rule, then both an application rule and a global rule are required for any particular connection to succeed. It turns out that the default ‘Allow TCP/UPD out from any/any to any/any’ global rule, if one uses it, provides the global portion for both DNS and loopback connections.
The individual DNS application rules within the policies are redundant, though they cause no problem, if one allows svchost to provide DNS service, since svchost itself has an application rule to allow. If, however, one does not allow svchost DNS access, then the individual application rules will be required.
For loopback, each application which uses it must have an application rule to satisfy the application rule portion of the equation. The default loopback rule within the predefined policies provides this. If an application which uses a predefined policy does not require loopback, these rules should not cause any problem under most circumstances.
