Author Topic: Configuring Defense+ for min alerts & good security under admin account in XP  (Read 72509 times)

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
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.
« Last Edit: October 22, 2011, 06:10:03 PM by MrBrian »

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #1 on: March 17, 2009, 06:16:40 PM »
Some stats on my exported ruleset sizes:

Prior approach, not mentioned here: ~2100 kB
Using approach outlined here: ~430 kB

The new approach has been used for only a few hours, so the ruleset will grow in the coming days and weeks, but even if it doubles in size, it's still much smaller than that of my previous approach. The Defense+ ruleset now saves much faster than before, which would give a very welcome improvement for the time it takes to remember the answer in a Defense+ alert.
« Last Edit: March 17, 2009, 06:19:50 PM by MrBrian »

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #2 on: March 18, 2009, 06:10:33 PM »
Here is a tip for anyone migrating from a different approach to this one: You can find the filename for each Defense+ policy at registry location HKEY_LOCAL_MACHINE\SYSTEM\Software\Comodo\Firewall Pro\Configurations\n\HIPS\Policy, where n is the configuration to use. The filenames from the registry are useful when you are manually entering allowed executables in the 'All Applications' policy.
« Last Edit: March 26, 2009, 06:34:54 PM by MrBrian »

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #3 on: March 20, 2009, 07:15:06 PM »
The approach has been working out well so far. The time to save D+ policy has dropped from about 18 seconds with my old approach to approximately 2 seconds with this new approach. Those of you who disdain the amount of time taken for remembering a rule at a D+ alert should see a noticeable speedup. The size of the exported configuration now stands at about 500 kB, as compared to 2100 kB with my old approach.

One benefit of this approach that I did not mention before is that there is less of a need for Installation Mode when installing a program, because there are fewer alerts. A benefit of not using Installation Mode is that if you install a program that tries to install a rootkit, you will hopefully get an alert for device driver installation before the rootkit becomes active.

I set my Firewall Security Level to Custom Policy Mode, and Alert Frequency Level to Very High, and allow only the outbound communications that I deem necessary. The goal of this is limit the opportunities for data leaks by grayware or malware, and also ferret out malware which could be using other programs to leak information. Another reason for such granular control is to hopefully alert when shellcode tries to use the Internet to download an executable used to continue an attack.

One minor issue that has come up is covered at http://forums.comodo.com/defense_bugs/some_files_that_are_not_in_my_protected_files_are_protected-t36754.0.html.
« Last Edit: March 25, 2009, 06:07:50 PM by MrBrian »

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #4 on: March 20, 2009, 08:03:06 PM »
A followup to my last post: if you don't limit outbound communications, you may encounter grayware scenarios such as the one described at http://forums.comodo.com/general_security_questions_and_comments_not_product_related/explorerexe_connecting_to_microsoft-t36353.0.html.
« Last Edit: March 26, 2009, 06:37:18 PM by MrBrian »

Offline LarryLaser

  • Comodo Member
  • **
  • Posts: 33
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #5 on: March 20, 2009, 09:26:29 PM »
Very exceptional information MrBrian.
Thanks, it will help me get my system set up better.

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #6 on: March 20, 2009, 10:41:40 PM »
Since the gist of this approach is to get an alert when an executable that has not run previously (well, when CIS has been watching anyway) is about to run, I've made a number of changes to the default Defense+ policies. I'm using XP, so you may need others' advice on how to proceed if you use Vista or Windows 7.

Here are the Defense+ settings that I have for Windows XP:

File group 'Windows System Applications':
  • System
  • %windir%\system32\smss.exe
  • %windir%\system32\csrss.exe
  • %windir%\system32\winlogon.exe
  • %windir%\system32\lsass.exe
  • %windir%\system32\spoolsv.exe
  • %windir%\system32\wbem\wmiprvse.exe
  • %windir%\system32\wbem\wmiadap.exe
  • C:\Program Files\Comodo\COMODO Internet Security\cavscan.exe

File group 'Comodo Files/Folders':
  • C:\Program Files\Comodo\COMODO Internet Security\*
  • %windir%\system32\drivers\cmdguard.sys
  • %windir%\system32\drivers\cmdhlp.sys
  • %windir%\system32\drivers\inspect.sys
  • %windir%\system32\guard32.dll

File group 'Comodo Internet Security':
  • C:\Program Files\Comodo\COMODO Internet Security\cfp.exe
  • C:\Program Files\Comodo\COMODO Internet Security\cfplogvw.exe
  • C:\Program Files\Comodo\COMODO Internet Security\cfpupdat.exe
  • C:\Program Files\Comodo\COMODO Internet Security\cmdagent.exe
  • C:\Program Files\Comodo\COMODO Internet Security\crashrep.exe

Policy for file group 'All Applications':
  • Interprocess Memory Accesses: Allow
  • Process Terminations: Allow
  • Others: Ask

Policy for file group 'Windows System Applications': predefined policy 'Windows System Applications'

Policy for file group 'Comodo Internet Security':
  • Run an executable: Ask
  • Others: Allow
  • Protection Type Interprocess Memory Accesses: Yes; Exceptions: file group 'Windows System Applications', C:\Program Files\Comodo\COMODO Internet Security\*
  • Protection Type Windows/WinEvent Hooks: No
  • Protection Type Process Terminations: Yes; Exceptions: file group 'Windows System Applications', C:\Program Files\Comodo\COMODO Internet Security\*
  • Protection Type Windows Messages: No

Policy for %windir%\explorer.exe: all set to 'Ask'

Policy for %windir%\system32\rundll32.exe:
  • All set to Ask
  • Run an Executable Allowed Applications: %windir%\*

Policy for %windir%\system32\services.exe:
  • Run an Executable: Ask
  • Protected Registry Keys: Ask
  • Protected Files/Folders: Ask
  • Device Driver Installations: Ask
  • Others: Allow

Policy for %windir%\system32\svchost.exe:
  • Run an Executable: Ask
  • Protected Registry Keys: Ask
  • Protected Files/Folders: Ask
  • Device Driver Installations: Ask
  • Others: Allow

Unless you have Automatic Updates turned off and turn off the firewall and D+ when you use Microsoft Updates (as I do), you should keep the policy for the group Windows Updater Applications.

The reason the policies for msiexec.exe, which I removed from the group 'Windows Updater Applications', and explorer.exe were altered is because we want to get alerts when these two perform actions.

My Protected Files:
  • file group 'Comodo Files/Folders'
  • My Documents folder and other data files, such as installation programs, downloads folder, etc.
  • ?:\boot.ini - not protected by the NIS Filecheck rules I use
  • ?:\ntldr - not protected by the NIS Filecheck rules I use
  • ?:\autorun.inf - this is for protecting against malware that infects USB flash drive autorun.inf files; including this file helps to prevent malware on your computer from spreading to others' computers
  • *.sys
  • file group '3rd Party Protocol Drivers'


Very exceptional information MrBrian.
Thanks, it will help me get my system set up better.

You're welcome :).
« Last Edit: March 27, 2009, 07:07:02 PM by MrBrian »

Offline andyman35

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 1579
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #7 on: March 21, 2009, 12:33:25 AM »
Very useful information there,I've stickied this thread.  :-TU

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #8 on: March 21, 2009, 01:17:26 AM »
If you want fewer alerts yet, and you trust Comodo's method of enumerating safe files, then you can use Defense+ Safe Mode instead of Paranoid Mode. This will not reduce the ruleset size though.

Very useful information there,I've stickied this thread.  :-TU

Thank you andyman35 :).

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #9 on: March 21, 2009, 02:03:38 AM »
In an earlier post I mentioned the use of programs such as Autoruns to help shore up some of the weaknesses in this approach. Here is the approach I use with respect to these programs: I think of time spent on my computer as occupying two time periods: 1) Normal period - no software is installed, and the computer is used normally 2) installation period - the short period when I install programs, and do not do any risky behavior, such as browsing the web. The transition from one of the periods to the other triggers the use of 4 programs to check for changes in system state. Any changes made during the transition from normal period to installation period should be examined closely, because by definition nothing was (or should have been anyway) installed during normal period. Changes made during the transition from installation period to normal period don't need to be looked at as closely, because the installation period is short and risky behavior was supposed to be avoided.

The 4 system state recording programs I currently use are NIS Filecheck, HijackThis, Autoruns, and What's Running. Actually I just switched from FingerPrint (from 2BrightSparks) to NIS Filecheck, because NIS Filecheck records file version numbers but FingerPrint does not. I'm not sure if NIS Filecheck is available online anymore though. All 4 of these programs can be used to record part of a system's state, and compare to the prior saved state. NIS Filecheck is used to check for changes in file contents, date modified, etc. I use it check for changes in files with these extensions: exe, dll, ocx, vxd, sys, bat, cmd, com, and scr. Autoruns shows you what programs are configured to run during system bootup or login. What's Running covers some of the same areas as Autoruns, but also records IP connections and running processes. HijackThis covers a lot of the same areas as Autoruns, but also records areas such as the contents of the hosts file, and some Internet Explorer settings.

Offline alfa1

  • Comodo Member
  • **
  • Posts: 42
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #10 on: March 21, 2009, 04:49:03 AM »
it would be nice if you could equip your explanation with pictures so to make even more clear certain passages of your reasoning...

Txs in adv.  :)

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #11 on: March 21, 2009, 10:47:43 AM »
it would be nice if you could equip your explanation with pictures so to make even more clear certain passages of your reasoning...

If you can tell me which parts are giving you trouble, it will help me to improve the explanation :)

Let's suppose we have 4 .exes, which I'll call A, B, C, and D. Let's suppose A, B, and C are allowed to run D. With the approach most people use, you would have these 3 separate D+ policies, each with a 'Run an executable' rule, which can be represented as follows:

A -> D
B -> D
C -> D

Depending on the D+ mode (Paranoid or Safe) and the safe list status of A, B, C, and D, we could have been alerted up to 3 times to capture these 3 rules. However, let's suppose after the first alert, of A executing D, that we decide to make a D+ rule that 'All Applications' are allowed to execute D, which can be represented as follows:

All Applications -> D

With this rule in place, when B executes D for the first time, there will be no alert nor any new rule created. The same happens when C executes D for the first time. In the interest of getting rid of redundant rules, and also reducing processing time and storage requirements, the rule A allowed to execute D can be deleted. Thus, we ended up getting only one execution alert, instead of possibly 3, and we also condensed 3 rules into 1.

One main idea of this approach is that any trusted executables should be allowed to run any other trusted executables. In D+, you accomplish this by putting the executable to be trusted in the 'Run an executable' list of the 'All Applications' policy. Another main idea is that D+ should be configured so that an alert is given when any executable not yet trusted is run for the first time. To accomplish this, the default rules shipped with D+ were altered as described in a prior post.
« Last Edit: March 26, 2009, 07:44:24 PM by MrBrian »

Offline sirio

  • Global Moderator
  • Comodo's Hero
  • *****
  • Posts: 1736
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #12 on: March 21, 2009, 01:19:06 PM »
Hello MrBrian,
interesting your changes, however IMHO all this makes D+ vulnerable.

Now, I don't know if I have understood badly... :-\
In My Protected Registry Keys, you say to leave protected only the COMODO Keys? And to eliminate all the others?  ???
Then, I've to cancel all My protected COM interfaces ?  ???
In My Protected Files set in only these:
Quote
1) My Documents folder and other data files, such as installation programs, downloads folder, etc.
2) Comodo Files/Folders group - to protect the program from malicious alteration
3) ?:\boot.ini - this important file is not protected by the NIS Filecheck rules I use
4) ?:\ntldr - this important file is not protected by the NIS Filecheck rules I use
5) ?:\ntdetect.com - this important file is protected by the NIS Filecheck rules I use, but I included it anyway because it's related to the above two files
6) ?:\autorun.inf - this is for protecting against malware that infects USB flash drive autorun.inf files; including this file helps to prevent malware on your computer from spreading to others' computers
7) \Device\HarddiskVolume? - without this, programs such as chkdsk can do their actions without any alerts


I prefer to answer to some pop-ups more (are not so much) but to be protected up to 100% of the possibility of D+, that is IMO, appraising the advantages and the disadvantages obtained changing the policy how you say, the disadvantages overcome the advantages.

sirio  :)

Offline MrBrian

  • Computer Security Testing Group
  • Comodo's Hero
  • *****
  • Posts: 494
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #13 on: March 21, 2009, 04:18:36 PM »
Hi sirio,

Yes you are right about your interpretation about what my recommendations are. I had similar views to yours in the past. I've come to realize though, that I have pretty safe computing habits, and thus what I was doing in D+ was overkill for my circumstances; for example, I scan all downloaded programs with 3 antivirus programs before I execute them. Thus I changed my D+ philosophy to being mostly about making sure that only trustworthy code is executed. The attempted execution of unintended executables, via exploits etc., should in most cases raise an alert, and thus can be prevented. Malware can't damage your system if it isn't allowed to execute. If your computing habits tend towards risky behavior, the approach I describe might not be for you.

I did keep some prevention/detection monitoring in place - physical memory, disk, device driver installation, network activity, and file protection (mostly for data files). The first 3 of these areas are somewhat uncommon in practice, and result in only small increases in ruleset size. Network activity can involve more user effort, but it doesn't result in large increases in ruleset size. File protection for data files, and also monitoring of low-level disk access, is used because mistakes in allowing untrustworthy executables to run ought not result in data loss. I would hope that, in the event of system compromise, that you have a backup image you can restore. I keep my data on a separate partition from my programs, so that a restoration of my program partition does not affect my data partition. I highly recommend using a behavior blocker such as ThreatFire, Prevx Edge, or Mamutu with this approach. Also, the use of the 4 programs I mentioned in an earlier post serves as another detection mechanism.

There are certainly threat vectors that your approach will handle that mine will not. However, there are some threat vectors that my approach handles that your approach probably doesn't. First example: you download a program that contains a rootkit dropper but you don't realize it. With your approach, because of all the alerts potentially generated during installation, you probably use Installation Mode, which would allow the installation of the rootkit without any alerts. My approach, requiring fewer alerts, makes it feasible to not use Installation Mode during installation, and thus the device driver installation monitoring would hopefully pay off here in an alert and thus prevention of rootkit installation. Second example: the default shipped policy with explorer.exe allows running of any executable without alert, right? Let's suppose you have a vulnerable version of Adobe Reader, and a rigged pdf. According to Didier Stevens (at http://blog.didierstevens.com/2009/03/04/quickpost-jbig2decode-trigger-trio/):

"This explains how the PDF vulnerability can be exploited without you opening the PDF document. Under the right circumstances, a Windows Explorer Shell Extension will read the PDF document to provide extra information, and in doing so, it will execute the buggy code and trigger the vulnerability. Just like it would when you would explicitly open the document. In fact, we could say that the document is opened implictly, because of your actions with Windows Explorer."

The Adobe pdf explorer shell extension runs as a .dll within explorer.exe. Thus, if you click on a rigged pdf in Windows Explorer, and this results in executable file being downloaded and run, your D+ policy for explorer.exe will maybe allow this without alert. In my approach however, I would get an alert, because I altered my D+ policy for explorer.exe.

An additional benefit of this approach for me is that I will hopefully be able to move to a newer version of CIS (well, actually Comodo Firewall Pro back then) than v3.0.14.276, which I currently use. The smaller D+ ruleset size of this approach will result in less time in the processing of remembered answers in D+ alerts. Earlier versions such as v3.0.14.276 do not have this issue.

You of course can add whatever additional D+ protections you want, since it's your computer. You could choose to merely adopt the practice of moving allowed executables to the 'All Applications' policy, but keep all of your existing D+ protections in place. D+ is very configurable :).
« Last Edit: April 05, 2009, 01:05:34 AM by MrBrian »

Offline tcarrbrion

  • Star Group
  • Comodo's Hero
  • *****
  • Posts: 672
Re: An approach for configuring Defense+ for many fewer alerts
« Reply #14 on: March 22, 2009, 04:46:48 AM »
My approach, requiring fewer alerts, makes it feasible to not use Installation Mode during installation, and thus the device driver installation monitoring would hopefully pay off here in an alert and thus prevention of rootkit installation.

An alternative here is to have an alternative configuration for installation that only monitors the most dangerous things. I have started to explore this option.

The Adobe pdf explorer shell extension runs as a .dll within explorer.exe. Thus, if you click on a rigged pdf in Windows Explorer, and this results in code being executed that downloads and runs a malicious file, your D+ policy for explorer.exe will allow this without alert. In my approach however, I would get an alert, because I altered my D+ policy for explorer.exe.

I only allow explorer to run things under program files or windows without an alert. If you are sensible and do most things as a limited user then, since you cannot save malware to these directories, you will always get an alert from explorer when it tries to run the malware, but not in normal use.

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek