Upon installation I was told that I MUST uninstall my older version of 5.5 first ?!?! (words to that effect). Did that however and restarted.
Installed the new 1383 version, restarted as required and database is now up to date, have selected the custom firewall policy (I want to manually give permission to whatever to speak internet) but on 3 machines now I find the setting/selection to be meaningless - I am not getting alerted and asked for any permissions when I run any software/app - eg - in the past Outlook’s use required me to manually approve its communication the first time I used it after installation … now it doesn’t - it just sods off and go fetch my mail despite the firewall’s custom setting. Same goes for Firefox and IE
If there is a built-in white-list that is causing this behaviour I would really like for it not to be the default criteria as long as the custom firewall behaviour is chosen.
How to force the custom selection to be respected?
Its the first thing I checked on - my list currently looks like this http://www.home.telkomsa.net/glad/Images/comoda.png … in the past with every app I either allowed or prevented access to/for the list got updated - currently its plain ignoring me and not even asking permission for anything.
Hey LvR, you have a rule in there for “All Applications” which is set to Allow all outgoing requests. Maybe this is why everything that connects out is not showing an alert.
Try removing it from the Network Security Policy list and see what happens.
Eric - my apologies - I used the wrong tool to check on the running services - yes - "“inspect” is present and running when using ProcessHacker2 to check on the system
Matty:
Thanks for the suggestion but its a bit too late.
What I have done in the meantime is to solve the puzzle myself.
With the announcement of 1383 I decided to download the standalone installer version because I have to update quite a few machines and a few machines need virgin installs anyway - seemed the more sensible thing to do rather than have a lot of machines download the same thing many times over (saving on bandwidth).
So on all 3 the machines I mentioned, I manually removed the then installed 13xx version, restarted and then installed 1383. The default of 1383 for the firewall is “safe” where apps net access requirements are “learned”.
Now to be quite cl;ear:
I did not and will never create such a blanket rule to allow access for everything
The first thing I did after installation and restart was to change to “custom” mode - that according to my way of thinking should have cleared any and all already created rules anyway (even if I was the dumb cluts to have created such a stupid rule!) … no?
Now :
By way of experimentation I have found that 1383 installation and then changing to “custom” policy for firewall results in this unacceptable behaviour. I found that if I removed 1383, re-installed using the older standalone installer version, changed to “custom” and restart, that the correct interactive behaviour is present - and if I then allow the program to “update” using the built-in update facility in the “more” tab, the interactive behaviour for the “custom” firewall setting is retained once the whole update process is declared successful and 1383 is declared to be running. To confirm this via another independent route I have actually taken the pc with the “updated” 1383 route showing the correct interactive “custom” firewall behaviour and removed completely Comodo, installed 1383 from the standalone installer, and were once again rewarded with the unwanted “custom” firewall setting behaviour - noting that I intentionally did not manually create the rule to allow all…repeat #3 above starting with the older standalone installer and then updating to 1383 from within the program gets me a working system as expected on 3 machines I have here.
So yes - I do realize I am the only common factor here and I don’t see other people complaining about the same, but I have 3 machines showing the fact that the standalone 1383 and a previous version updated to 1383 simply doesn’t exhibit the same firewall behaviour with the same “custom” firewall settings.
Simply changing the firewall from safe Mode to Custom Policy Mode will have no effect on the existing rules. Making this change does not delete any existing rules, nor does it add new rules.
Now :
By way of experimentation I have found that 1383 installation and then changing to “custom” policy for firewall results in this unacceptable behaviour.
I’m trying to recreate your situation but so far I haven’t seen any unexpected behaviour. If you can, would mind expanding a little, on what you mean by “unacceptable behaviour” and what you did to observe this. Basically, what exactly are you seeing/doing once you’ve changed to Custom Policy Mode?
Simply changing the firewall from safe Mode to Custom Policy Mode will have no effect on the existing rules. Making this change does not delete any existing rules, nor does it add new rules.
Guess I have a logic failure in that case ......................... eg - let say you were running with safe mode for a few months and the firewall has a whole horde of rules defined as a result. What you are implying is that at the stage you change to "custom" for firewall, absolutely nothing will change ito firewall behaviour and that only newly encountered attempts to communicate will ACTUALLY be governed by a "custom" rule (since it will now be the first time the firewall has the chance to create a rule depending on your permission) ....................... somehow it strikes me as not being a "custom" firewall setting at all - especially if a nonsense setting like that that Matty mentioned is present - who in his right mind would create such a setting to start with anyway? I am quite confident it was not me and the only other possibility is the 1383 installer (confirmed by repeated uninstall/install sequences) - I can assure you that on all 3 machines in question here, I had the "custom" firewall setting active and acting as one would expect for each and every first time communication attempt by a new piece of sw/app.
I'm trying to recreate your situation but so far I haven't seen any unexpected behaviour. If you can, would mind expanding a little, on what you mean by "unacceptable behaviour" and what you did to observe this. Basically, what exactly are you seeing/doing once you've changed to Custom Policy Mode?
I will try:
I had the older 13xx running on all 3 machines (W7 64 Ultimate) with the firewall in “custom” mode - various rules for the apps/sw that requires net access etc were created on first net access and I had a horde of custom rules in the firewall “application rules” as a result - on all 3 machines
1383 was announced and I decided that rather than allowing every machine to download the update by itself, I would download the full 1383 installer and apply it to the 3 machines manually - as a result I had to remove the older 13xx version, restart and then install 1383 on each of the machines . I immediately changed to “custom” firewall policy and restarted because I was told to and then applied the virus signature update. …
This is where the “unacceptable behaviour” bit comes in - the very first time I started Outlook it sodded off and fetched mail even though I have not been alerted to its attempts to reach the net - same goes for IE and Firefox and anything else you can mention - the app is simply allowed to speak to the net even though its a brand new virgin install of 1383 with the only manual change on my being the selection of “custom” firewall policy
So in short - I basically did not “do” anything consciously/actively or that I know of - I simply changed to “custom” and as normal expected the firewall to behave like in the past with all the previous versions of the firewall - ie - it must alert and ask permission for each and every app/sw that needs comms and must then create a rule depending on my response … but I never even got to answer or respond to any alerts and as a result no rules were created.
I suppose the rule that Matty refers to there may be the problem, but then we need to figure where and what is it that I (lets presume I am the fly in the ointment for now) did to cause the creation of that rule during 1383 installation.
IMO the firewall behaviour should include a “clean all previous rules present” instruction on changing to “custom” policy because I am pretty sure that is the intention of having a “custom” mode (if its not like that currently may I request that change please)
For now though - I can install 13xx from the stand-alone installer I download in June sometime, change to “custom” and confirm that eg Outlook et-all needs permission from me before they can get on the net, update to 1383 via the program itself, and then I can end up with a current and non-“unacceptable behaviour” 1383 installation
Guess I have a logic failure in that case ......................... eg - let say you were running with safe mode for a few months and the firewall has a whole horde of rules defined as a result. What you are implying is that at the stage you change to "custom" for firewall, absolutely nothing will change ito firewall behaviour and that only newly encountered attempts to communicate will ACTUALLY be governed by a "custom" rule (since it will now be the first time the firewall has the chance to create a rule depending on your permission)
Correct.
3. This is where the "unacceptable behaviour" bit comes in - the very first time I started Outlook it sodded off and fetched mail even though I have not been alerted to its attempts to reach the net - same goes for IE and Firefox and anything else you can mention - the app is simply allowed to speak to the net even though its a brand new virgin install of 1383 with the only manual change on my being the selection of "custom" firewall policy
Unfortunately, I’m just not seeing this. As soon as I make the change to Custom Policy Mode, I get alerts.
6. IMO the firewall behaviour should include a "clean all previous rules present" instruction on changing to "custom" policy because I am pretty sure that is the intention of having a "custom" mode (if its not like that currently may I request that change please)
That may be a nice idea but may also cause a lot of novice users a lot of grief. Personally, if one wants to increase the sensitivity of the rules creation process, then one should know the mechanics of doing so.
I just did a clean install of CIS 1383 and it turns out it has the All applications rule in the Internet Security Configuration and no such rule in the Proactive configuration.
I am on Win 7 x86. See attached images.
I still have the installer of 1382 and will try a clean install with that after this and report back.
I am not sure I am following you there … am I not increasing the sensitivity of rules creation process by chosing “custom”? … and if a novice user choses the “custom” policy he should expect the consequences - no?
You are increasing sensitivity by selecting the Custom Policy mode, but this will only affect rules created from that point on. Simply changing to this mode will not remove the existing rules. Also, if a rules exists for an application that allows:
IP - OUT - ANY - ANY - ANY
As most of the default rules do, changing to Custom policy mode will have no affect at all. Likewise increasing the Alert Setting to very high. The best advice, if you want to use Custom Policy mode, is to remove the default firewall rules and start from scratch, once you’ve change the mode.
The problem would seem to be with the Internet Security configuration, which is the configuration used by default, when the AV component of the suite is installed. For some unknown reason this configuration has had the All Applications rule added, which I hope is a mistake.
I understand the current set-up, but its exactly that behaviour you mention that should be automated in the program itself IMO - one could also say that switching from eg custom to auto should create (or then re-create after all the current rules are deleted) the automatic rules as created at the time of installation of the program.
As for the original problem that started this thread - I guess we know the latest installer is somehow responsible for the issue and its not a question of the problem sitting somewhere between the chair and keyboard - at least the issue has been identified and those experiencing this could simply kill that stupid rule iso trying to find an older version to start with like I did
