This bug has been reported several times in the previous release. Why can this bug not be fixed?
Example: default Network Application Rule for Comodo Firewall Pro
First test was to set logging on for the first rule and then run a check for updates. Everything ok
Second test was to change first rule to ask and then run a check for updates. Not so good
Update check is being blocked because the rule following the ASK rule is being used instead. This is very easy to recreate. Would the developers please fix this?
Thanks, Al
IBM T41 Laptop
Intel(R) Pentium(R) M processor 1700MHz
1GB Memory
Windows XP + SP2 + WUS security Fixes
Symantec Antivirus Corporate Edition 9.0.3.1000
I guess this is by design.
From my limited knowledge Ask is always evaluated after allow and block rules regardless of its position. I don’t know if only one ask rule is supported for each policy.
If I only use a single ASK rule, then ASK shows me alerts. I cannot imagine why an ASK rule would be checked last. Does block before asking sound logical to anyone?
The predefined email client policy does not work for many of us. It just acts as a block on my system. The purpose of an “ask” (and other firewalls have it) is to allow a real time decision as to whether something should be allowed or blocked, depending on the situation. From the CFP3 help file:“Action : Define the action the firewall will take when the conditions of the rule are met. Options available via the drop down menu are ‘Allow’, ‘Block’ or ‘Ask’”. So the current problem is either a design error or a coding error. I gave up on using it after all the bug reports were ignored. I use “block and log” instead and just change it and do it over if that is the wrong answer. But we are finding more situations where it would be helpful if it worked as advertised; thus another bug report attempt.
An example of where I would find “ask” useful:
embedded http in email
I currently have added a rule to “email client” to allow Thunderbird to download it all
I would really like an “ask” rule so I can see what it is before I download it
I don’t want a block rule because it is difficult to recover from it
The default email client rules ask once, then continue to allow or block (without a rule) depending on your answer. This (mis) behavior is the subject of several other threads, including the one on localhost alerts.
Ok. I’ve verified that when you have overlapping BLOCK and ASK rules, BLOCK will take precedence. Looks like the programmers took the easy way out and all I can say is shame on them ;D
As a test, I created 9 block rules to replace the single block rule without overlap and ASK works fine.
Al (this can’t be the solution) Adric
p.s. I noticed also that the last two IP protocols marked in red are using protocol numbers instead of
the names GRE and RSVP. No consistancy there.
From the behaviour I observed the email policy usually add a new ruile entry (I guess that remember checkbox apply).
This could explain the behaviour you are describing. I guess this is the reason Ask action have a lower precedence than allow or block. in fact when an ask action generate a new rule the ask rule is not replaced by the new one.
If we account for Firewall alert level settings things get messy. With an high alert level setting you could craft an ask rule to create a large amount of new rules. Each one of these will be put before the ask rule. If you use a low alert level settings and you create a block rule answering to the ask alert the program will be unable to connect anymore.
I don’t want to create new rules-I just want CFP3 “ask” to do exactly what the help file quote above says it does. I will even accept it as a manual edit. When the situation covered by a rule is triggered, ask me whether I want to allow or block it THIS TIME. For high level alerts, fill in the parameters for the rule just like I had said “block” or “allow”. Another example: sometimes I want a program to get an update, sometimes I don’t. An “ask” rule could take care of that situation. Or have Comodo fix the help file to show this is not the capability and call it something else.
If the remember checkbox is unchecked no rule will be added.
Even if OT I guess the alert level settings should affect the number of options an alert will offer using a drop down button in order to be able to generate rules with a detail lower or equal to that level (high alert level should be able to generate rule with very low, low, medium and high detail).
I cannot object that the way it works is counter-intuitive but if this was a design decision. I guess we should describe the most open behaviour that correct the glitches and accounts for all combinations of CFP settings.
Allow TCP Out POP3
Allow UDP Out 53
Ask TCP Out 80
is completely useless as the default action in almost every firewall including Comodo is ASK!
Ask TCP Out 80
Allow TCP Out POP3
Allow UDP Out 53
ASK is useless as well because TCP Out port 80 is not matched by any other rule therefore the firewall will ask.
ASK only makes sense if it’s followed by ALLOW or BLOCK rules that match the ASK rule:
Allow TCP Out POP3
Allow UDP Out 53
Ask TCP Out 80
Block IP In/Out Any
However ASK is currently useless as the last case does not work because of the bug.
If I have to accout your statements then your last rule don’t need an ASK too as this one should be enough to trigger ask on http connections
Allow TCP Out POP3
Allow UDP Out 53
Block tcp Out where desrination port is not 80
Block udp Out any
Block IP in any
Anywas if we have to guess the intended design from the email policy the ask rule is meant for something like this
Allow TCP Out POP3
Allow UDP Out 53
Ask IP In/Out Any
What this policy do?
As a policy it overrides the trusted status of an app if you use train with safe mode.
It catches pretty much everyting not explicitely defined and allow the creation of a new rule.
This should mean that ask was primarily intended to finetune a ruleset.
Anyway I’m in no position to tell if this is a design decision or not but I hardly believe that this bugreport was not aknowledged by developers when it was reported versions ago.
As I would like V3 to mantain the most flexible architecture possible I guess that any change should address all possible scenarios.
In may case the use of ask to override a trusted status and to finetune a policy is a much more desirable behaviour.
Anyway in order to make better use of this forum I guess tha a new topic should be created in the feedback board to discuss this and to suggest an alternate behaviour that will not break existing capabilities.
Running a poll in that topic would be a good idea too.
If such topic is opened I hope that a link will be posted here.
Exactly. That is why we are asking for clarification and not assumptions. The subject topic was brought up previously here and here. If you read the entire threads, you will see that this question was left unanswered/ignored.
I have a different opinion on that. BLOCK all and ASK specific is more restrictive and leaves less room for letting the cat out of the bag. If the predefined rule for the email ciient is a way to fine tune, then I disagree because the first time you allow an ASK for the email client you will get a very broad rule at the top which more or less makes the other rules below useless. An example of this is thundebird asking for access to http port 80. If I allow with remember, I get a rule that says Allow TCP out from IP any to IP any where Source Port is any and Destination Port is any (even in Custom Policy Mode). This overrides the rules for POP3/SMPT and DNS requests and is not the behavior I would like to see. Although, this looks like an additional problem in that an ASK alert does not create a specific network rule unless I change my Alert Setting to high which is not the default.
I would agree with that, but not until the devs can clarify the situation as to why this is WAD or
BAD. According to my interpretation of the documentation, this is a bug.
If you remove the “Block IP In/Out Any” for the individual application and place a “Block IP In/Out Any” for All Applications at the end the ASK Rule works.
From my personal experience not all unanswered bugreports are left ignored. That’s what I was trying to say. If I have to guess thye reason is that development takes many efforts and at the end of the day there is not much time left to post in the forums. That’s why we sometimes fear that devs are actually imprisoned in a dungeon ;D
That behaviour is due to V3 alert level settings. I posted many times about a possible enhancements to alerts that makes them able to generate rules with different detail levels using dropdown buttons. This way the alert level settings define the maximun detail it is possible to select using alert dropdown buttons. As this feature implementation is trivial I guess it will actually been implemented sooner or later
I suggested that in order to let this topic develop without waiting for a direct reply. Joining a topic requre time and efforts. A developer couldn’t just drop by and say it is a WAD whitout being involved in a lenghty discussion
A poll would be enough to gather feedback among other users. the more the feedback the better the chances the priority will rise. Even if something was meant by design if the userbase desire a different approach the feature will be changed.
The program connects to IP 123.123.123.123 Port 80. The firewall intercept the connection and processes the rule.
Allow TCP Out POP3: Does not match the port (80 is not included in POP3). Next rule.
Allow UDP Out 53: Does not match port nor protocol. Next Rule.
Block TCP Out Not 80: Comodo was (I will test again today when I update to latest version) ignoring the exclude checkbox, so the rule become Block TCP Out 80. Use a set of ports rather than a single port and the rule should work properly. But if the firewall is working properly is should not match the connection.
Block UDP Out: Does not match Protocol. Next Rule.
Block IP In Any: Does not match direction. End of rules reached. Execute default action ASK.
If “ask” would be fixed, this would also help with the SPI bug/design decision that ignores passive ftp. The default rules for web browsers and ftp clients had to be modified to add: allow/tcp/out/any/any/any/any to get passive ftp to work, since SPI rules did not recognize the connection to port 21 as being an FTP request. This negates all of the port restrictions for http and turns the web browser default to “allow tcp out everywhere” plus “allow DNS out”. If “ask” worked, users could replace the “allow” there with an ask. This would also help identify the nonstandard http ports when used, although with the current (3.0.16.295) rules there is no restriction on http ports.
