Update October 22, 2011: This guide was written for CIS v3.x on Windows XP. Some of the ideas here, particularly the execution control provided via the 'All Applications' Defense+ policy, can still be applied in later versions of CIS and later operating systems. See the guide "Using Comodo Internet Security as an anti-executable" at
http://forums.comodo.com/guides-cis/using-comodo-internet-security-as-an-antiexecutable-t60303.0.html if you want executable control using Windows Vista or later in conjunction with UAC or a standard account.
Having used Comodo Firewall 3 for 15 months, I have come to appreciate the great flexibility of the program, but the approach I had been using required answering too many alerts at times. I have overhauled my approach with the hope of answering fewer alerts in the future, while still having good protection against common threat vectors.
Here are the principles and design goals of my new approach:
1. I want CIS to alert me when an executable that have not run before is about to run. I don't, however, want to be alerted the 2nd, 3rd, etc. time an executable runs, regardless of how the executable was reached.
2. Since I usually use programs from only trusted sources, I don't want CIS to give me many alerts on actions performed by executables that I've already allowed to run.
Here is a sketch of how I accomplish this:
1. I use the 'All Applications' Defense+ policy for executables that I've allowed to run. Since alerts will not populate this policy, manual editing is needed to move allowed executables from other policies to the 'All Applications' policy. Exception: don't move or copy allowed executables from rundll32.exe to policy 'All Applications'.
2. 'Detect shellcode injection' setting is turned on.
3. The only protected registry keys are for CIS self-protection.
4. With a few exceptions, the only protected files are CIS' files, and also data that I don't want to be modified without alert, such as files in My Documents.
5. There are no protected COM interfaces.
6. Defense+ is set to Paranoid Mode, so that all executables are approved by me on first time run.
7. These are the 8 areas that are monitored by Defense+: Device Driver Installation, Protected Registry Keys, Protected Files/Folders, Disks, Physical Memory, DNS/RPC Client Service, Interprocess Memory Accesses, and Process Terminations. The last two will never trigger alerts, but will protect CIS from tampering.
8. Firewall is set to Custom Policy Mode, so that I approve of all network activity.
9. Autorun for all drives is turned off in Microsoft's group policy editor.
Generally, once I approve an executable to run, I want the executable to run with few alerts. There are a few exceptions: I want to be alerted to device driver installations, to stop rootkits before they become stealthed. Also, I want to be alerted to network activity, to reduce the risk of stolen information leaking out.
Here are some observations about this approach:
1. You should see many fewer alerts, especially during installations.
2. The number of policies in Computer Security Policy may be far fewer than before. As a result, the time it takes to save Computer Security Policy (which also happens when you remember an answer in a Defense+ alert) may be reduced considerably - a nice bonus of this approach.
3. There are 3 lines of defense against buffer overflow exploits - the 'Detect shellcode injection' technology built into CIS, the network activity alerts upon downloading of the executable that the attacker wishes to run, and finally the alert upon the running of a new executable.
4. There are no alerts for changes to existing exes, dlls, etc. Malware has to already be running for malicious alteration of exes, dlls, etc. to occur. I use NIS Filecheck on demand to occasionally check for changed exes, dlls, etc.
5. This approach will not alert about changes to autostart locations, the hosts file, Internet Explorer settings, etc. I use HijackThis, Autoruns, and What's Running on demand occasionally to check for these types of changes from the prior state.
6. This approach can do well or poorly against leaktests, depending on the Alert Frequency Level used for the firewall. A behavioral blocker such as ThreatFire will detect some leaktests.
7. This approach is not bulletproof. It was designed to significantly reduce the total number of alerts experienced, while providing protection against the more common threat vectors.
8. Along with signature-based antivirus/anti-malware, an intelligent malware behavior blocker such as ThreatFire, Prevx Edge, or Mamutu is highly recommended as a complement to this setup. Defense+ with this approach is mainly tuned for prevention of malware execution, while the behavior blocker is there in case malware manages to execute.
Please see post
http://forums.comodo.com/feedbackcommentsannouncementsnews_cis/an_approach_for_configuring_defense_for_many_fewer_alerts-t36657.0.html;msg261658#msg261658 from later in this topic for more details.