Open up Firewall Tasks and enter the Advanced section.
Under Firewall Behavior Settings, General Settings, select Custom Policy Mode
Under Firewall Behavior Settings, Alert Settings, turn off all alerts.
Under Network Security Policy, Application Rules, make sure there are no rules for TELNET.EXE, and delete any if they are there.
Under Network Security Policy, Global Rules, add a rule at the top of the list for TCP out to a single destination address of 91.199.212.133 which is mail1.comodogroup.com, for any source address and any source or destination port.
Click OK in the Network Security Policy dialog to commit the changes.
Run the following command to connect to the Comodo mail server:
TELNET 91.199.212.133 25
It will fail to connect.
Global rules that allow traffic should apply to all applications even if they are not in the application rules list.
Global rules that block traffic do work correctly, that is, they block the traffic without creating an alert (when enabled) for both known and unknown applications.
Interesting finding. Neither Firewall nor D+ makes a rule for Telnet.
I made sure there were no rules in Network and Computer Security Policy. Then set Firewall to Custom and D+ to Paranoid with “Trust the applications digitally signed by Trusted Software Vendors” disabled. Telnet would start straightaway with no alert nor does it show up in NSP and CSP. Truly odd.
In your scenario, if you don’t have an Application rule then the application will fail to connect, regardless of the global rules. Please take a look at the attached, which is from the on-line help.
“The Global Rules tab allows users view, manage and define overall network policy that applies to your computer and is independent of application rules.”
Therefore, a global allow rule should let traffic pass to an unknown application.
Indeed, and just prior to that paragraph you will find.
The Application Rules tab allows users to view, manage and define the network and Internet access rights of applications on your system
Simply put. Application rules define which applications have access and also what level of access. Global rules define which protocols are allowed to either enter or leave the system.
As I said earlier, if there are no entries under Application rules for a given application, then that application will not be able to make outbound connections nor receive inbound connections.
A Global rule is just a simple filter for protocols.
Sorry, the first time I brought up the reply, either the browser did not render or I did not see the image linking to the diagram. I now understand the the mechanism. I just happen to have a philosophical disagreement with the way it works, but I guess I will have to live with it. I’m just used to the way a couple of other firewalls worked, but unfortunately, those are not compatible with 64 bit Windows yet.
One man’s bug is another man’s feature. So now this changes from a bug report to a feature request.
The behavior I am looking for is the following. If a global rule blocks traffic, it does not proceed any further other than possible logging the attempted access. If a global rule allows traffic, then it is permitted to pass. If no global rules are matched, then any application rules are applied. I don’t know if the way the code is structured if it would be possible to have an option to implement that behavior.
The one thing that is missing is the ability to operate the firewall using only (carefully tuned) global rules and no application rules, not that I am recommending that, particularly for outbound HTTP access.
