Hi,
I am using CIS firewall 12.2.2.8012 and wanted to ask if the wildcard I did is correct.
I wanted to create a rule for “crashreporter.exe” in all folders contained in my ‘Portables’ folder. Say,
D:\Portables*\crashreporter.exe
Is the wildcard firewall rule correct?
Will CIS block all “crashreporter.exe” in D:\Portables
Thanks for your patience!
I would make the following rule:
D:\Portables*\crashreporter.exe
Is this drive an internal drive or an external drive? When it is an internal drive the rule will not work when you disconnect and reconnect it. CIS does not trust external drives because they are not continuously monitored.
Firewall rules and HIPS rules don’t work for removable media.
That’s bug number 8 on the bug list…
It’s not a bug. It is by design.
Nope, it’s a bug. Files are trusted by their file rating and their hashes so it should not matter from which drive files are executed being either from internal drive or from removable media.
Once a Firewall rule or HIPS rule is created for a trusted file (e.g. test.exe) having a wildcard rule like ?:\*test.exe it should work from all drives.
And when you create ASK rules for files on removable media and select “remember my answer” than you end up with answering that question all the time and polluting the rules list with duplicates rules.
It’s one of the annoying CIS bugs.
It is by design that Application Rules are path based. You can easily test that yourself on a fixed a hard drive by substituting an executable by a different one with the same name.
This is how Comodo Firewall started with v3 and Application Rules have always been kept path based also when hash based solutions were introduced making it a two-tier system.
Since hash based recognition was introduced CIS will handle files with default strategies for Trusted, Unknown or Malware files. It is only when you make Application Rules the hash check and default strategies for Trusted, Unknown or Malware files will be skipped in favor for application rules.
Since it has always worked like that it is by design and not a bug.
Not trusting external drives has always been a cornerstone of CIS since its inception and is by design and therefor not a bug.
However, your case does make a valid wish to integrate hash recognition in Application Rules which will as a result make it possible to make rules for programs on external drives.
Please make a format verified wish in the Wish board. That way you can promote it to other users who may then cast their votes on it. That way you will also contribute more positively and constructively to the community.
Attach a removable media to the system then create Firewall rules and/or a HIPS rules for an executable on that media. The created rules will work for as long as the media is attached. When you detach the media for a while and then re-attach the same removable media (system giving it the same drive-letter) then the previously created rules stop working for no obvious reason. The rules are still listed both on the Firewall rules list and on the HIPS rules list but they don’t work anymore, the CIS user doesn’t know why these rules don’t work anymore because they are still on the list.
The CIS user expects that created rules on the rules lists work as expected for as long as they are on the list but they don’t work as expected for removable media due to a serious bug.
File hashes are the backbone of CIS protection and when the same executable with another name is executed from either internal or removable media then CIS is smart enough to see whether the file hash is different or not and allow or block that executable depending on the file trust rating. For the CIS user it should not matter from which drive (from internal or from removable media) an executable is being executed. CIS will always check the file hash and block or contain unknowns accordingly.
I’ve created many Wish requests and submitted many bug reports over the past years (you know that) and despite all my positive efforts Comodo trashed all those request and bug reports so I stop all my efforts in testing CIS any further until Comodo decides to fix the majority of bugs on the bug list which were submitted by many many loyal CIS users over the past decades and starts implementing Wish requests submitted also by many many loyal CIS users over the past decades.
I’ve contributed positively and constructively over the past years more than enough in hopes for the community to get the bugs fixed and it’s due to Comodo’s attitude of not fixing bugs that I stop testing CIS any further.
This bug is just one example of the long established or long standing bugs which Comodo refuses to fix.
I meant to write
If they are separate folders in the Portables folder each one containing crashreporter.exe then D:\Portables\*\crashreporter.exe should work. I’ve used that format successfully here.
I can’t confirm this for the firewall rules, the hips rules, and the sandbox. The rules were easily remembered, at least in this version of the 
I know you to be a very committed and knowledgeable member.
It can be aggravating when projects or people we deeply care don’t seem to notice us (anymore) and we may get carried away by our frustration and might end being bitter.
It seems clear that development of CIS is less resourced than it used to be. F.e. I remember we used to have Star Group testing internal builds and more communication from Comodo about plans etc. Those were different times I’m afraid.
In the end venting frustration time and again without cease does not take you or the forums anywhere. Sometimes it is better to take a bit of distance, either internally or externally, when frustration has taken over. It clouds the mind and makes us lose sight of qualities that are there.
It reminds me of borrowing three CD singles with rare versions of Insomnia by Faithless from a housemate. Each CD had 5 mixes. Some were totally ■■■■■■ like they had given the recording technician’s junior assistant who had been badgering to get hands on with music permission to do a remix. Interestingly no matter how mediocre or ■■■■■■ some of those mixes were they could not kill the song its self. The song was rock solid and would not budge. I feel the same about CIS. The foundations are rock solid and that will stay.
For now things are moving forward only slowly, COMODO_RT is giving their best; things are where they are so let’s help people who are new to CIS to have a good start. This is the least we can do, and hope for better days with more development.
COMODO_RT is doing his best he can and people are rude to Xcitium…
When people lie openly, whether it is Comodo Staff or someone else, then it is legitimate to act rude against them.
Xcitium does not lie everyone trusts Xcitium.
You believe in fairy tales.
Take off your pink glasses and read other forums and you will discover that not everyone trusts Comodo …
And so not everyone trusts Kaspersky.Kaspersky is one of the best antiviruses it has great detection rates but their servers are in Russian and alot of people dont trust Kaspersky
Your feedback is totally irrelevant and guides this discussion away from your statement that “Xcitium does not lie everyone trusts Xcitium” which is not correct. Point.
It is correct everyone trusts Xcitium
Believe in what you like to believe, the truth is too harsh for you , dream your fairy tails, sleep well and dream on.
I love Xcitium and they never lie the bugs will be fixed but do you know how hard it is to fix 1 single bug? it may be more time to fix it or less time.
You have absolutely no idea what you are talking about, it’s pure nonsense!
Forget about Comodo fixing any bugs. They will not change any single line in the codebase to fix any long-standing bugs.
Just forget about it!!!