I’ve been playing around with CIS6, and I decided I have to get a better understanding of the application. I’ve read the docs, but I still have some questions, because some parts of the documentation are rather confusing, or don’t explain the workings sufficiently. Here’s my list:
Cloud lookup: As far as I understand this feature automatically adds safe files to trusted list, and bad files to the blocked list. Is it possible to configure it so that the feature only adds bad files to blocked list, but does not modify the trusted list? If not, I’d like to add it to my wishlist.
Trusted files/HIPS: HIPS offers permission policy and protection settings. According to the docs, the HIPS does not monitor trusted files. If I add an executable or a process to trusted files, what happens with protection settings policy? Does HIPS still apply the protection settings for this trusted application? It would be a fail, if it didn’t.
Trusted files: I need some clarification for when adding trusted files. As far as I read it a user can add trusted files to the list where the file gets hashed. So even if the filename changes somehow, the hashes remain the same - this means you don’t get any alerts for this application. Files can also be added by filename/path, which means that even if the content changes, the file is still trusted. How can I add trusted files by hash and how by path/filename???
All Applications: What’s the deal with the “All Applications” rule in HIPS? What’s the difference between rules listed above or below this rule?
Reg keys: How to protect certain registry keys from modification by ANY non-system application? I can’t stress how many times I’ve had to mess with the registry to fix file associations for *WAV files because some media player always decided it was smarter than the user, and continuously modified the file associations to point to itself. I would simply deny the media player access to registry keys, but there’s always a next application that tries to be smart, and doesn’t yet have the blockade to reg keys. The result? I need to mess with the registry to fix restore the file associations… again.
Elevated installer: When running a program that triggers a popup request for elevated privileges… if granted, does HIPS/BB still monitor this process? What happens, if I treat an application as an installer? Does HIPS still monitor it? What about executable processes spawned by the app that was treated as an installer - are they monitored by HIPS?
Raw Disk access: If I change the policy for all applications, and treat an application as an installer, do the rules still apply to it? I.e I’d like to block raw HDD access for all applications except those I allow (i.e. a hex editor of my choice). The reason for this is that some weirdo progs try to write data to inappropriate places on the HDD. Let this be the interpartition space or the boot sector (Adobe CS3). I’d like to block any and all non-system apps (including programs treated as installers) from writing to these parts of the HDD unless I manually override (by adding a HIPS policy per application).
Cloud lookup is comodos version of a cloud av. It warns the user of bad files and adds safe files to the trusted files list but there is not an option to turn them off individually. this would be a great topic for the wishlist.
- [b]Trusted files/HIPS:[/b] HIPS offers permission policy and protection settings. According to the docs, the HIPS does not monitor trusted files. If I add an executable or a process to trusted files, what happens with protection settings policy? Does HIPS still apply the protection settings for this trusted application? It would be a fail, if it didn't.
If a file is in the trusted files list defense + will not monitor the file. You would have to create custom rules if you wanted defense+ to monitor a file.
- [b]Trusted files:[/b] I need some clarification for when adding trusted files. As far as I read it a user can add trusted files to the list where the file gets hashed. So even if the filename changes somehow, the hashes remain the same - this means you don't get any alerts for this application. Files can also be added by filename/path, which means that even if the content changes, the file is still trusted. How can I add trusted files by hash and how by path/filename???
The trusted files list works by file hash only in v6. In v5.10 CIS had an option to trust a file by filename but it was removed from v6 probably because its a security risk. If you would like the feature to return you can create a new topic in the wishlist.
- [b]All Applications:[/b] What's the deal with the "All Applications" rule in HIPS? What's the difference between rules listed above or below this rule?
I believe this rule enables defense + to monitor all unknown applications since CIS is default deny. Im not 100% sure though.
- [b]Reg keys:[/b] How to protect certain registry keys from modification by *ANY* non-system application? I can't stress how many times I've had to mess with the registry to fix file associations for *WAV files because some media player always decided it was smarter than the user, and continuously modified the file associations to point to itself. I would simply deny the media player access to registry keys, but there's always a next application that tries to be smart, and doesn't yet have the blockade to reg keys. The result? I need to mess with the registry to fix restore the file associations... *again*.
- [b]Elevated installer:[/b] When running a program that triggers a popup request for elevated privileges... if granted, does HIPS/BB still monitor this process? What happens, if I treat an application as an installer? Does HIPS still monitor it? What about executable processes spawned by the app that was treated as an installer - are they monitored by HIPS?
If you click run unlimited when you get an elevated privileges alert the installer will be allowed to do what it wants. The installer rules treates the installer and all the files created by the installer as trusted so use caution when applying this rule.
- [b]Raw Disk access:[/b] If I change the policy for all applications, and treat an application as an installer, do the rules still apply to it? I.e I'd like to block raw HDD access for all applications except those I allow (i.e. a hex editor of my choice). The reason for this is that some weirdo progs try to write data to inappropriate places on the HDD. Let this be the interpartition space or the boot sector (Adobe CS3). I'd like to block any and all non-system apps (including programs treated as installers) from writing to these parts of the HDD unless I manually override (by adding a HIPS policy per application).
Thanks in advance!
If you give an application as an installer the app will be able to do what it wants. For what your asking you would have to create some custom HIPS rules.
So you’re saying a trusted file cannot be protected with defense+ protection settings i.e. interprocess memory access? I have to remove the file from trusted list, and apply new policy in HIPS.
Tell me then what is the solution to those auto-generated batch files that an IDE like Atmel Studio 6 generates. Each time a compile is executed, the IDE generates a new *.bat file and executes it. And therefore I get alerts each time!
Is there a way to block modifications? I do not wish to see alerts.
Is there any way I can apply certain restrictions to installers i.e. raw disk access, but still allow them to do other things needed for an application installation?
Tell me then what is the solution to those auto-generated batch files that an IDE like Atmel Studio 6 generates. Each time a compile is executed, the IDE generates a new *.bat file and executes it. And therefore I get alerts each time!
ok first you are going to have to create a new group in your defense + rules go to the defense + settings and click protected objects ->under protected files right click and select groups ->right click and select add new group and name it whatever you want then right click on your new group and select add folders -> select the folder where the .bat files are executed from. Click ok, then go to HIPS rules and create a new rule, click browse ->file groups then select your newly created group and give it the installer/updater policy. Now any file ran from that folder will be treated as an installer.
Now if you try and execute a bat file you will get an alert saying explorer.exe wants to execute the .bat file since its unknown. To bypass these alerts go back into the HIPS rules and double click the explorer.exe rule and chang it to custom ruleset, to the right of “run an executable” click ‘modify (0\0)’, under allowed files/folders add the .bat folder.
Now anything ran from that folder will be treated as an installer/updater and wont generate any alerts when explorer.exe tries to execute them.
Use extreme caution with this method. ANY files ran from this folder will be allowed to run with the highest rights. If malware is ran from this folder CIS will not protect you
Is there a way to block modifications? I do not wish to see alerts.
yes, in the HIPS rules change it to custom ruleset and instead of the action being 'ask' change it to 'block' next to protected registry keys.
Is there any way I can apply certain restrictions to installers i.e. raw disk access, but still allow them to do other things needed for an application installation?
Regards!
No, since the installer/updater is a predefined ruleset it cannot be changed. you would have to create a custom ruleset to change the restriction settings.
Hope this helps, i know its complicated but defense + is very powerful and granular so you can do lots of customization to fit your needs. Let us know if you have any more questions.
Interesting, thank you for the answers! Yes, I realize it is complex, though I still miss some options. I’ll make a wishlist soon. In the meantime I have some more questions.
Is there a way to treat an application (maybe all appplications) that get executed by a specific process under a certain HIPS rules policy? If the same application gets executed by a different applications, the previous rules do not apply. I.e. if I could set any *.bat file (in a given folder) that is executed by Atmel Studio to temporarily be treated as trusted or under a certain HIPS policy. If I execute the same .bat file from explorer it is not trusted any more. It would be wonderful, if users could apply HIPS rules to sub-processes like this.
I noticed I get a lot of sandbox popups. When does an app get sandboxed automatically? The do-not-sandbox option will move the executable to the trusted list according to the docs. Is there a way not to sandbox a process without adding it to the trusted list?
Is there a way to configure what restrictions a sandbox policy applies? Is there a way to create custom sandbox policies?
sorry about the late reply been really busy with school and work.
I think the installer/update policy will work this way. All files executed by the parent app with the installer policy will also be treated as trusted. With any other policy the child process will be treated as unknown thus being sandboxed or producing a HIPS alert depending on your settings.
I noticed I get a lot of sandbox popups. When does an app get sandboxed automatically? The do-not-sandbox option will move the executable to the trusted list according to the docs. Is there a way not to sandbox a process without adding it to the trusted list?
Since CIS is a default deny architecture it will sandbox all unknown apps. So if the app isnt signed by a trusted vendor, isnt in the cloud whitelist, doesnt have a HIPS rule and isnt in the trusted files list the app will get sandboxed.
Is there a way to configure what restrictions a sandbox policy applies? Is there a way to create custom sandbox policies?
No the sandbox has predefined policies that cannot be changed. You can read about each of them [url=http://help.comodo.com/topic-72-1-451-4846-Unknown-Files---The-Auto---Sandboxing-and-Scanning-Processes.html]here[/url].
I also wanted to mention that the installer policy does not except the file from the autosandbox anymore, like v5. To use the installer policy the autosandbox will need to be disabled.
Hope this helps, if you have any more questions let me know.