Anti-Executable configuration with CIS v 5.8

Can someone please explain how to set CIS 5.5 or 5.8 as an anti executable program ?

I have gone through the CIS 3 tutorial, but many things have changed and they changed by a lot…since then…

As An Anti-Executable Program? can you explain?

Here is a guide on how to turn D+ into an anti executable:Using Comodo Internet Security as an anti-executable.

Thanks for the response.

I have already gone through it, and in fact that is what I was referring to as obsolete. Since, there are many changes in both UI and architecture of CIS 5.8, I wanted to see how the same can be done in this new version.

Yes please. Easiest step with brief explanation.

Emily.

I’m the author of the CIS anti-executable guide mentioned above. One of the advantages of using v4.x as an anti-executable is that it can block DLL execution, whereas v5.x cannot, as far as I know. I just downloaded v5.5 and will test its DLL execution control abilities.

How many of you are interested in the guide being updated for the latest CIS, besides SivaSuresh? Are there any of you using v4.x as an anti-executable per my guide? Are you comfortable using v5.x as an anti-executable if it cannot block DLL execution? If I update the guide for v5.x, should the v4.x guide be retained?

Question for the mods: is it ok to alter my guide to give the download locations for CIS v4.1? Is there a download location within the Comodo website for v4.1?

I for one would be interested, though I don’t usually run in this mode.

RE CIS 5 as an anti-executable - DLLs are still part of the executables group, but as some point in 5.x’s evolution it stopped being possible to determine which extensions are subject to execution control. What occurs to me is that you could block the executables group, then add exceptions.

Note that CIS now parses the command line for certain extensions - basically for extensions that trigger execution on an interpreter. This makes sense because in this case you need to control the interpreter’s actions not the executable’s. (Well this is not strictly accurate, but you get the idea). That’s probably why the list of extensions subject to execution control was withdrawn. The alternative would have been to replace it by a complex dialog that allows specification of execution control and parsing/security action module. To difficult for most people I guess.

I’m afraid I don’t know what happens to old download links. Maybe ask Ronny. I’m sure people would be more than happy for you to change links, if the links you need exist. Your guides have always made a big contribution to the forum, and it would be great for them to continue, and/or be maintained. I read them just to understand more fully how CIS works :slight_smile:

In my D+ FAQs there some v5 stuff you may find useful in any update.

Best wishes, and hoping you can update to v5

Mouse.

Thank you Mouse for your feedback and kind words.

I have download locations for the last in the v4.x series. For x86 it’s hxxp://www.filehippo.com/download_comodo/7708/ and for x64 it’s hxxp://download.chip.eu/de/Comodo-Internet-Security-64-Bit-_6804435.html . The latter is in German though. I’m not sure if I should update the v4.x article with these links?

If I update the guide for v5 and also retain the v4 material, my thought would be to have separate threads for v4.x and v5.x. The thread that’s already pinned would be changed to provide the links to each of these threads. Any thoughts on this would be appreciated.

That would be just fine.

You are welcome.

Separate threads make sense to me.

I’ll check with other mods re the external links, though I think this is OK.

Mouse

Confirm that there are no problems with AV updates the external links you propose. But Matty reminds me that there may have been a change in AV database format sometime in the 4’s and 5’s.

Dunno if 4.x AV will update any more, but maybe it will, and maybe it doesn’t matter if your users are concentrating on default deny HIPS (as we all should, dunno why C doesn’t brave it out on this issue).

Some days I feel like disabling CIS AV… Maybe I don’t have enough courage either.

Best wishes, and the very best of luck, McBrain. If anyone can work out a way with CIS 5, that works well - you can.

Don’t hesitate to ask if you need help or anything stickied etc.

Also don’t hesitate to tell me if you find any FAQ mistakes as part of the process.

:slight_smile:

Mouse

Thank you Mouse :). I updated the guide with those links.

I have some good and bad news regarding v5.5. The good news is that the method in the guide still works with v5.5. The bad news is that DLL execution cannot be controlled with CIS v5.x. DLL execution control is an option available in CIS v4.x. Without DLL execution control, your machine would have been vulnerable to Stuxnet (if I recall correctly), DLL planting attacks, etc.

For anyone reading this, are you interested in using CIS purely as anti-executable software? Or do you plan to use other features available in CIS?

For those interested in the importance of DLL execution control, see dll exploit/ .lnk exploit mitigation by HIPS | Wilders Security Forums.

I get .dlls alerted from time to time, so there is some control. Rapport (security software) keeps trying to execute a DLL but CIS blocks it. I’m guessing the .dll is unrecognised.

Broadly .dlls cannot run themselves, but fake .dlls can insert themselves.

But there are only limited ways they can insert themselves

  • register as service providers for a COM publish/subscribe service
  • replace an existing dll
  • any others?

The COM alerts you get deal with the first possibility. Sig & hash checking would deal with the second. Maybe that’s what CIS does. Both involve some sort of execution detection. But of course its the control over how this is handled that is gone…

I believe CIS 5.x does have DLL control for the special case of rundll32.exe, but not in the general case. I tested with portable Firefox, which loads DLLs. CIS v5.x shows no alerts for these DLLs, whereas CIS v4.x can.

Some other ways that DLLs can be run are via a vulnerability or via a DLL planting attack. In the case of the (now patched) LNK vulnerability that Stuxnet and other malware used (uses?), a vulnerability in .LNK file processing causes explorer.exe to load a malicious DLL. http://blog.acrossecurity.com/ contains a lot of information about DLL (and binary in general) planting attacks.

It’s true that CIS can be configured to alert when a DLL file is written, although my guide doesn’t configure CIS to do so. DLLs can have any extension though, not just .DLL.

Think there is more than this.

Rapport and Idrive run .dlls and these get alerted, I think if unrecognised. Is your firefox running unrecognised .dlls

If you create an ask rule for all executables, this should alert all file that attempt to run .dlls which are not allowed to by a superior rule. So if you put it above the explorer rule for example…

Carrying on with this then you have svchost and rundll which you’d have to extract from the windows system group and create tailored rule that were sub-ordinate.

Dunno but something should be possible here…

Have to operate in paranoid with the sandbox and maybe IEC off…

Mouse

So something ought to be possible…?

Thank you. I’ll try further…

Firefox portable loads multiple DLLs, which I can see prompts for if using CIS v4.x. There are no DLL prompts though when I try with CIS v5.x.

Thread https://forums.comodo.com/beta-corner-cis/how-cis-hips-is-going-to-protect-against-this-t60858.0.html has info regarding DLL control in CIS v5.x, including a post from egemen.

Yes interesting. Had not seen this.

Still not conclusive - what Egemen says is usually right. But not necessarily all there is to know. If it was CIS would be less secure… :slight_smile:

I am getting .dlls blocked from starting. And the alerts do not suggest that rundll is involved.

Maybe the alerts are a bug? But I think not…

You’ll find .dlls in the trusted file list too.

Hmm:)

Mike

Any thoughts about this?

If you create an ask rule for all executables, this should alert all files that attempt to run .dlls which are not allowed to by a superior rule. So if you put it above the explorer rule for example....

Carrying on with this then you have svchost and rundll which you’d have to extract from the windows system group and create tailored rule that were sub-ordinate.