I’m running version 22.214.171.124 of Comodo and believe I’ve discovered a reproducible bug in the application control rules section. I have a few rules defined, but the three applicable are:
protocol: tcp out
protocol: udp out
protocol: TCP/UDP out
Initially, the rules are presented in THAT ORDER. However, if I double click the first rule and just click OK, it moved to the bottom of the three rules, and the block rules moves to the top of the list.
If I double click the second rule (port 53 rule), then that rule stays where is is, the block rule moves to the top of the three and the 1270.0.1 rule moves to the bottom.
If I double click the bottom rule (the block rule) and click OK everything stays where it is.
I can make the block rule go back down the bottom of the list by simply opening it and clicking OK once it’s been moved to the top of the list.
The ordering of the rules has an effect on how the firewall handles application traffic. I believe it’s a cast of ‘first rule match wins’ - hence why everything broke when the block rule moved to the top of the three and caused much confusion till I figured out what happened.
Could this be verified as a bug and a fix released? Thanks!
Greetings, dray, and thank you for posting about this!
I have previously noticed that the rules re-order themselves, but hadn’t paid that much attention to it. I just assumed that it was because of the edit; as the “most recently touched” rule, it had refreshed to the top of that group. Then I moved on…
So I paid a little more attention now. You are correct, the rules order in Application Monitor DOES matter; others may have known this, but I did not ~ thank you. I guess that kind of makes sense, and is/could be useful.
However, the changing order when you edit the rule (open it, then click OK, even if you don’t make changes) is a different thing…
I also noticed that if you open the rule, but Cancel out, the order remains the same. I did not notice a difference when moving between different rules; they all moved if I clicked OK.
One other thing I noticed as well… I had two rules for IE, with iVault as the parent; one TCP, one UDP; no ports specified. I had two other rules for IE with explorer.exe as the parent, with ports specified. When I created a Block rule for IE, TCP/UDP Out (with parent set to Learn), the AppMon placed it in the list, and the two rules with iVault as the parent were gone. The other two rules remained. Odd.
The problem with your rules disappearing could be caused by a feature I’ve noticed that automatically summarises your application rules. For example, if you have a rule to allow iexplore.exe to access 127.0.0.1 on tcp port 2323, then add another rule to allow iexplore.exe to access 127.0.0.1 on any tcp port, the first rule is automatically removed because it’s functionality is now defunct. Your rules disappearing might have been a by design feature or a bug. Couldn’t be sure without more details though (mainly - were the ivault parent rules that disappeared pass or block?).
In case the developers are curious how I discovered this bug - after I’d setup my rules I was surfing with IE and received a popup regarding iexplore and OLE - I think I said allow (can’t be sure though). Doing so must have caused the rules to reorder in the background and my “block all for iexplore.exe” (rule 3) was reordered to the top of the list causing all intenret explorer traffic to be blocked.
Oh, I’m aware of the rules over-write scenario; so far that hasn’t been an issue for me. With testing out this scenario, tho, to see how it would work with what you posted, the rules disappearing was not expected.
The two rules where iVault was the parent were “Allow” rules. They were replaced by a generic “Block” rule, which is odd. I understand that a generic TCP Out and UDP Out can be replaced by a TCP/UDP Out, and so on, but not an Allow for a Block, not a “Learn” parent for a defined parent. That’s just not right… (:AGY)