Can someone tell my how to disable Comodo’s Internal Safe List ? I sure some program has malicious act, but comodo treat it as a safe file. I disabled ‘automatically scan unrecognized files in the cloud’, and this program not in ‘Trusted Software Vendors’ list and ‘trusted file’ list, but comodo still treat as a safe file. Now I have to make comodo work in ‘paranoid mode’ 
.
What is the name of the file you think is malicious? Also, is it digitally signed?
Can you upload it to Virustotal and CIMA and post a link to the results?
It is digitally signed. File name is “qq.exe”. It’s a IM software. But it access other process’s memory, low level disk and send privacy data to the server. In my country, the government require the vendor to monitor the chat, web site visited and others.
OK. I upload it to Virustotal and CIMA. And official site download URL is: http://softdl1.tech.qq.com/soft/21/QQ2010_SP2.exe.
Is there a way to disable Comodo’s Internal Safe List? Comodo is a rule-base firewall, I can’t understand why I can’t disable it.
Did you try making a rule to block it? Maybe the safe list is more related to Defense+ than to Firewall…
Yes. I make a rule to block it in Defense+ and it work. But when Defense+ run in ‘safe mode’, if the ‘Access Rights’ of a safe file is ‘Ask’, Defense+ allow this action and no alert. This file is not in my ‘safe file list’ and it not digitally signed by Vendors in ‘Trusted Software Vendors’. It seem in ‘Defense+ internal safe list’. So I have to make Defense+ work in ‘paranoid mode’. How can I disable ‘Defense+ internal safe list’?
qq.exe is the main executable of Tencent QQ instant messaging application. It is the most popular free instant messaging computer program in Mainland China, and the worlds third most popular. Not essential to be automatically started. But should be left running if you want to communicate with your buddies instantly.
According to Defense+ Security Level rules:
Safe Mode: While monitoring critical system activity, Defense+ automatically learns the activity of executables and applications certified as ‘Safe’ by Comodo. It also automatically creates ‘Allow’ rules these activities, if the checkbox ‘Create rules for safe applications’ is selected. For non-certified, unknown, applications, you will receive an alert whenever that application attempts to run. Should you choose, you can add that new application to the safe list by choosing ‘Treat this application as a Trusted Application’ at the alert. This instructs the Defense+ not to generate an alert the next time it runs…
The Defense+ Computer Security Policy access rights for the application will then be set to ‘Trusted Application’ which is a pre-defined security policy that is essentially ‘allow all’ for all application accesses. Defense+ security policies apply specifically to applications and only specifically to access of system resources, e.g., protected Files and Folders, Registry Keys, COM interfaces, etc. Its a good idea to ensure that the security policy for any arbitrary application is set to ‘custom’, and set access rights to ‘ask all’.
If you have never granted ‘Treat this as a Trusted Application’ access rights and the app has a custom access rights policy, then check whether the application lives in the Defense+ Trusted Files folder; Files added to the Trusted Files area are automatically given Defense+ trusted status. I believe that overides whatever Computer Security Policy may be configured for the app.
When an application wants to access those system resources that you have defined in ‘Defense+ settings’, ‘monitoring settings’, you will be alerted for each particular access attempt. Your answer to each specific access attempt will be qualified whether you check ‘remember this’ or not for each alert. If ‘remember this’ is NOT checked, you’ll be pestered EVERY time the app wants to access THAT PARTICULAR system resource (over, and over and over and over again). Otherwise just ensure that ‘remember this’ is checked (for that app only), and it’ll never bother you again (for that specific resource only).
That is just plain best practice in order to ‘sandbox’ each app into their own physical environment. Never deny an application that you are familiar with access to system resources (it’ll cause them not to work properly). It also establishes a HIPS baseline, because if an app that hasn’t alerted you in ages suddenly wants access to something new: something about that app changed (maybe it has become compromised somehow).
The problem as I see it is that you want to restrict IP access by a particular app. That’s done in the firewall configruation. First ensure that the app isn’t in the Firewall Network Security configred with "trusted’ security policy. Secondly, if you don’t want the app to access the internet at all: define it as a blocked application in Firewall. In that case it would be better to just plain uninstall it. However, if you use it for IM, then it needs to have access the internet. With Firewall Network Security Policy rules you can establish WHICH IP addresses it has access to.
What I do for ANY app that needs internet access is define a default policy of ‘ask’ IP in/out src any dest any (log when rule fires). I make sure that’s the LAST rule for any app. Then I check the Firewall event log to find out what IP address it wanted to go to. Then I find out what that IP address domain name is, then I create a rule specifically to allow THAT app access to THAT IP address using the specific ports it asked for. If you can establish which IP address’ are the Big Brother Is Listening servers, you can block them specifically (but allow the IP addresses you need to IM).
‘qq.exe’ is only an example. what I mean is defense+ treat some files as a safe file, but this file not in my ‘safe file list’ and it not digitally signed by Vendors in ‘Trusted Software Vendors’, also no any rule allow activities of this file. It seem in 'Defense+ internal safe list" and this list will updated from comodo server.
My bad :-[ I should’ve read your last post more closely.
According to the rules:
Note: Defense+ trusts the applications if:
•The application/file is included in the Trusted Files list.
•The application is from a vendor included in the Trusted Software Vendors list.
•The application is included in the extensive and constantly updated Comodo safelist.
Furthermore, per the ‘sandboxing’ rules:
•An application can become recognized as ‘safe’ by CIS (and therefore not sandboxed or scanned in the cloud) in the following ways:
◦Because it is on the local Comodo White List of known safe applications
◦Because the user has added the application to the local ‘Trusted Files’
◦By the user granting the installer elevated privileges (CIS detects if an executable requires administrative privileges. If it does, it asks the user. If they choose to trust, CIS regards the installer and all files generated by the installer as safe)
•Additionally, a file is not sandboxed or sent for analysis in the cloud if it is defined as an Installer or Updater in HIPS policy (See Computer Security Policy for more details)
Per Unknown Files: The Sand-boxing and Scanning Processes
Cloud Scanning Part 1
•If the hash is not on the latest black-list, it’s signature is checked against the latest white-list [Comodo’s File Look-Up Server (FLS) to check the very latest signature databases]
If an unknown file is never identified outright throughout the sandboxing process as malware its ultimately deemed to be (and designated as such) to be ‘safe’ …the local [including in-the-cloud] white-list is [ultimately] updated; once its in either the cloud or local-whitelists, the app is ‘safe’, i.e., trusted.
I believe this is flawed processing as opposed to being an outright bug. Apps that fail postive malware testing, and are not outright in CIS factory default Trusted Vendor Listing - reqiuring CA certification - or subsequently placed in Trusted Vendor List by the user (requiring at least vendor self-signed binaries) can at best be flagged as ‘recognized’ and thereby circumventing sandboxing and associated processing. And in the latter circumstance local ‘safe’ apps can never be used as a basis for global whitelisting.
On the other hand it can be argued that whitelisted apps are deemed ‘trusted’ and that that status circumvents Computer Security Policy IS a bug.
I get it. Thank you for your reply. :-TU