Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Comodo
Comodo Project Experimental Configuration All Welcome
Message
<blockquote data-quote="AtlBo" data-source="post: 833879" data-attributes="member: 32547"><p>Steps forward and steps backward. First, a serious success. I read that log spam was a cause of high processor usage from cmdagent.exe. This is something that has caused me to have to reinstall Comodo several times, so I have always been interested in a solution. Not sure this will solve cmdagent.exe, but I have finally solved the riddle of log spam. It can be one of two things by a standard. They are:</p><p></p><p><span style="font-size: 22px">1</span>. Log spam from HIPs memory access blocks-Programs like Process Lasso and Cleanmem access memory of Comodo processes. Comodo blocks and logs every attempt. To see if you have this problem, look in the HIPs log. If you see in the logs a program that is attempting to access the memory of a Comodo process, here is the way to fix the problem:</p><p></p><p>Once you have located the name of the file that is spamming the HIPs log, write it down and also see what file it is accessing. There is actually more than one way to handle this, but, so far, the most common trigger for this is a process attempting to access memory of Comodo processes. All processes get flagged for this, not just "Unrecognized". For this example, there are 4 processes attempting to access cis.exe in short increments of time. This method would stop the log spam of the 4 processes for any of the processes listed in the second picture below contained under the header (File Group) Comodo Internet Security. So here are the pictures:</p><p></p><p><span style="color: rgb(226, 80, 65)">1.</span> The group containing the file(s) being compromised by the 4 processes. In this case, the file(s) is/are found in the Comdo Internet Security HIPs rule:</p><p></p><p>[ATTACH=full]224287[/ATTACH]</p><p></p><p><span style="color: rgb(226, 80, 65)">2.</span> Clicking once on the entry "Comodo Internet Security", now we can click to edit the rule for this group:</p><p></p><p>[ATTACH=full]224283[/ATTACH]</p><p></p><p><span style="color: rgb(226, 80, 65)">3.</span> The Edit dialog pops up, and we navigate to "Protection Settings" to find the rule we must edit:</p><p></p><p>[ATTACH=full]224288[/ATTACH]</p><p></p><p><span style="color: rgb(226, 80, 65)">4.</span> In "Protection Settings" we locate the rule "Interprocess memory access"->Exclusions->Modify:</p><p></p><p>[ATTACH=full]224289[/ATTACH]</p><p></p><p><span style="color: rgb(226, 80, 65)">5.</span> Next choose Edit and the option for "File". Now navigate to the process that is attempting to access the memory of a Comodo process. Add this process to the list here:</p><p></p><p>[ATTACH=full]224291[/ATTACH]</p><p></p><p>This should resolve HIPs spam. It can be any process on any other. You may even have to make a separate rule for both the file attempting to access and for the vulnerable application. More than likely, just for the file being accessed in its HIPs protection settings Exclusions for "Interprocess memory access". You will also need to make sure that the rule is set to Active from Inactive.</p><p></p><p><strong>After locating which application is being accessed from the log, go to Settings->HIPs->HIPs Rules. Click on "Add" on the menu. Using the file option search for the executable for which the block is occurring. Make sure to activate "Interprocess memory access". Then add the name(s) of any and all processeds that are trying to access its memory. This will stop HIPs memory access rule log spam. </strong></p><p><strong></strong></p><p><strong><span style="font-size: 18px">2.</span> Firewall log spam-The key here is to look for "Windows Operating System" and/or svchost.exe in the log being the responsible application for the connection log spam. These are mostly blocks and many of them are on local or semi-local traffic (someone else's local). So the goal is to unblock all of the local ones. Once you know which IP ranges on the local network that each of your devices are registered to use, you can see which domain your devices occupy. Usually, it will be the range 192.168.1.1-192.168.1.255. However, if you are accessing a publc wi-fi in your place of residence, you many notice something along the lines of 192.168.***.***, where the star represents any number up to 255. All the third numbers should be the same.</strong></p><p><strong></strong></p><p><strong>As an example, if your computers are connecting using something like 192.168.148.*, then you will be using this IP range element in the firewall rules to get rid of the spam. In the above case, the range would be 192.168.148.1-192.168.148.255. Again, the range is usually going to be the standard 192.168.1.1-192.168.1.255 local range. At any rate, you will be looking to set a NEW allow rule for the application shown in the log to be causing the firewall log spam (responsible for the blocks usually). If the application is what Comodo calls "Windows operating system", looking at its log entries, we will be looking at the remote IPs to see if they are on the same local domain as your PC. These are the ones we want unblocked, not access from devices on other networks. So we can create an allow rule in this example for "Windows operating system" for the range containing our local domain to allow this traffic and end its block spams in the log. One more time, almost every time the range to use is 192.168.1.1-192.168.1.225. This will stop most log spam from "Windows operating system" or svchost.exe.</strong></p><p><strong></strong></p><p><strong>It's important that we, unfortunately, cannot find a way to create a rule for "Windows operating system". For svchost.exe, we can simply create a rule at the top of the firewall list, but "Windows operating system" does not exist anywhere in Comodo by those exact words, "Windows operating system". When creating a rule there is no option to select it as the subject of the rule. This has caused me untold grief over that last 5 years, along with how to deal with svchost.exe. Well, the good news is, that "Windows operating system" is not important, unless it is causing log spam. Also, although it is not available by name to choose as a process/file group for rule creation, we CAN get Comodo to create a firewall rule for us in every situation where we would care to do so. This is because the only time we will care to create a rule for "Windows operating system" is when it is spamming the firewall log. So, if it is doing so, what do we do?</strong></p><p><strong></strong></p><p><strong>OK, this is really not so bad and really quite simple. If I notice that the log events bar for the firewall is dominating the others, and I discover firewall log spamming from "Windows operating system", I would obviously like to resolve the dilemma with the spam. OK, so there is one important thing to note here. In the case of "Windows operating system", the entries are always going to be in the form of blocks. This is by design from Comodo. The only question then is whether there are too many. If so, because these are block events, we can look to "Unblock applications" on the widget to see if "Windows operating system" is there. Indeed, in every instance where a block appears in the firewall log for "Windows operating system", it will also appear in "Unblock applications". So, to create a rule that we can work with in the firewall area, all we have to do is find "Windows operating system" in "Unblock applications" and right click its entry to unblock its firewall block. Comodo does the rest, auto-creating an allow rule, even though there is no way to choose to create a rule for "Windows operating system" in Comodo (or at least that I have seen). This is great!</strong></p><p><strong></strong></p><p><strong>However, it's important to note and consider here that the unblock we issued when we unblocked "Windows operating system" or svchost.exe from "Unblock applications" means that we just allowed ALL inbound traffic for this process (not for the entire system) with a new Comodo created "unblock" rule. So, in above examples, what do we do to set up rules nicely to get all blocks but only allows for safe local?</strong></p><p><strong></strong></p><p><strong>OK, so here is how it's done. With the Comodo allow rule in place, create a new rule and make sure it is ABOVE the Comodo generate "unblock" rule for the application. Having found the range that you would like to allow, we set this new allow rule to allow for TCP and UDP and in. Then we set our IPv4 range below the rule title in the dialog. This is the range of safe IPs we determined to be our local network. OK the rule. Now, with your ranged allow rule in place above the "Unblock applications" rule for the application, we want to make sure now to go back and set the original rule to block. So, click on the original rule and open its Edit dialog. Set the rule to block TCP and UDP in and set it to log. Retitle the rule to match your choices for the rule, i.e. "svchost.exe (or "Windows operating system) Block and Log TCP/UDP In". OK the rule, and you should have the safest possible scenario. This is because you have the block rule in place as clearly Comodo felt was best. Obviously, it was Comodo's choice to firewall block the app in the first place via a firewall block. At any rate, you now have a simple way of allowing local or otherwise safe traffic into the system. You just create a single allow rule above the others any time for whatever IP needs access via the process, but the Comodo generated rule you turned into a block blocks all others. Here is how it will look after you are finished:</strong></p><p><strong></strong></p><p><strong>[ATTACH=full]224308[/ATTACH]</strong></p><p></p><p>Note in the picture above that I have set one of the rules to log activity. This is not necessary and I wouldn't if it were leading to spam, of course. The important thing is that you are in control of the logging now. Also, you now have the added flexibility of being able to refine Comodo's choice to block "Windows operating system" or "svchost.exe". Don't know if "Windows operating system" affects Remote Desktop, but, if so, I could easily create a single allow rule for the single IP of each of the PCs I would like to use to connect via RDP.</p><p></p><p>One other not about the above. There are two ranges that I have allowed, because I park two machines next to each other that use connection sharing for one of them to connect to the internet. The PC using connection sharing uses a different local range to make its connections. It considers the server the machine from which it gets its connection...see here:</p><p></p><p>[ATTACH=full]224313[/ATTACH]</p><p></p><p><strong>Again, recall this same thing can happen with svchost.exe or "Windows operating system". And just to reiterate, if you notice a firewall block in the "Unblock Applications" area (lock icon on the widget) for either of these two processes, go to the firewall log to see if the process (svchost.exe or Windows operating system) is creating spam there. If so, go back to "Unblock Applications" and unblock the application for the protections shown that are blocking this application. This will auto-create an allow rule for the application for all IPs. So our job is to refine this situation so that only safe IP ranges are allowed. Back to the firewall area, we must set the allow rule created by unblocking in "Unblock Applications" back to "block", because we don't want to allow all traffic in via "Windows operating system" or "svchost.exe, either one. Find the "Windows operating system" or svchost.exe rule (should be the newest rule at the top). Now click on the "+" left of the entry to expand its rule(s). Change the rule and its title to "block" and OK the rule. Now, still in the firewall rules area, create a new allow rule under the process. Add this rule just above this process' existing rule which you just edited to re-create the block Comodo had originally been making. Make this rule an allow rule for TCP and UDP and in and then set the range of safe IPs (v4) to be allowed. Usually, the spam are in blocks, so you may find that you can get what you want (eliminate log spam) by just allowing the safe ones of these. Now set the range of the rule to your local network. The bulk of the traffic will now be allowed safely, since it is your local traffic. All other traffic will remain blocked. For this to stop the spam, make sure this allow rule is the top rule under the process' rules.</strong></p><p><strong></strong></p><p><strong>Cure the log spam and you will be laughing with the angels about Comodo. Much if not most of the bugginess and clunkiness will disappear. Here is how a clean log without spam should appear:</strong></p><p><strong></strong></p><p><strong>[ATTACH=full]224306[/ATTACH]</strong></p><p></p><p>No one or two categories overwhelm the statistics in the lab. If we see one bar very high and the others very low, this can be a tell tale sign of log spam.</p><p></p><p><strong>ONE NOTE: When leaving a menu in Comodo settings, make sure to use the button at the bottom of the form to exit the menu. Never use the x's. Rules will not be remembered if the x's are used to leave a menu. Think of a trip into the settings area as a session. During this session, we must use the "OK" button to leave a dialog in order for Comodo to remember the change being made. This means for all dialogs. So, we must back out of the settings area using the OK button. Even one use of an x on the way out will void all changes made. This is obviously important to learn with Comodo. Use an x to escape a settings menu after making a change->expect the change won't be made.</strong></p><p><strong></strong></p><p><strong>Hope this helps some. Still in the formulative stages of setting some things up.</strong></p></blockquote><p></p>
[QUOTE="AtlBo, post: 833879, member: 32547"] Steps forward and steps backward. First, a serious success. I read that log spam was a cause of high processor usage from cmdagent.exe. This is something that has caused me to have to reinstall Comodo several times, so I have always been interested in a solution. Not sure this will solve cmdagent.exe, but I have finally solved the riddle of log spam. It can be one of two things by a standard. They are: [SIZE=6]1[/SIZE]. Log spam from HIPs memory access blocks-Programs like Process Lasso and Cleanmem access memory of Comodo processes. Comodo blocks and logs every attempt. To see if you have this problem, look in the HIPs log. If you see in the logs a program that is attempting to access the memory of a Comodo process, here is the way to fix the problem: Once you have located the name of the file that is spamming the HIPs log, write it down and also see what file it is accessing. There is actually more than one way to handle this, but, so far, the most common trigger for this is a process attempting to access memory of Comodo processes. All processes get flagged for this, not just "Unrecognized". For this example, there are 4 processes attempting to access cis.exe in short increments of time. This method would stop the log spam of the 4 processes for any of the processes listed in the second picture below contained under the header (File Group) Comodo Internet Security. So here are the pictures: [COLOR=rgb(226, 80, 65)]1.[/COLOR] The group containing the file(s) being compromised by the 4 processes. In this case, the file(s) is/are found in the Comdo Internet Security HIPs rule: [ATTACH type="full" alt="Comodo FIX PL Log Spam.png"]224287[/ATTACH] [COLOR=rgb(226, 80, 65)]2.[/COLOR] Clicking once on the entry "Comodo Internet Security", now we can click to edit the rule for this group: [ATTACH type="full" alt="Comodo FIX PL Log Spam (2).png"]224283[/ATTACH] [COLOR=rgb(226, 80, 65)]3.[/COLOR] The Edit dialog pops up, and we navigate to "Protection Settings" to find the rule we must edit: [ATTACH type="full" alt="Comodo FIX PL Log Spam (3).png"]224288[/ATTACH] [COLOR=rgb(226, 80, 65)]4.[/COLOR] In "Protection Settings" we locate the rule "Interprocess memory access"->Exclusions->Modify: [ATTACH type="full" alt="Comodo FIX PL Log Spam (4).jpg"]224289[/ATTACH] [COLOR=rgb(226, 80, 65)]5.[/COLOR] Next choose Edit and the option for "File". Now navigate to the process that is attempting to access the memory of a Comodo process. Add this process to the list here: [ATTACH type="full" alt="Comodo FIX PL Log Spam (5).jpg"]224291[/ATTACH] This should resolve HIPs spam. It can be any process on any other. You may even have to make a separate rule for both the file attempting to access and for the vulnerable application. More than likely, just for the file being accessed in its HIPs protection settings Exclusions for "Interprocess memory access". You will also need to make sure that the rule is set to Active from Inactive. [B]After locating which application is being accessed from the log, go to Settings->HIPs->HIPs Rules. Click on "Add" on the menu. Using the file option search for the executable for which the block is occurring. Make sure to activate "Interprocess memory access". Then add the name(s) of any and all processeds that are trying to access its memory. This will stop HIPs memory access rule log spam. [SIZE=5]2.[/SIZE] Firewall log spam-The key here is to look for "Windows Operating System" and/or svchost.exe in the log being the responsible application for the connection log spam. These are mostly blocks and many of them are on local or semi-local traffic (someone else's local). So the goal is to unblock all of the local ones. Once you know which IP ranges on the local network that each of your devices are registered to use, you can see which domain your devices occupy. Usually, it will be the range 192.168.1.1-192.168.1.255. However, if you are accessing a publc wi-fi in your place of residence, you many notice something along the lines of 192.168.***.***, where the star represents any number up to 255. All the third numbers should be the same. As an example, if your computers are connecting using something like 192.168.148.*, then you will be using this IP range element in the firewall rules to get rid of the spam. In the above case, the range would be 192.168.148.1-192.168.148.255. Again, the range is usually going to be the standard 192.168.1.1-192.168.1.255 local range. At any rate, you will be looking to set a NEW allow rule for the application shown in the log to be causing the firewall log spam (responsible for the blocks usually). If the application is what Comodo calls "Windows operating system", looking at its log entries, we will be looking at the remote IPs to see if they are on the same local domain as your PC. These are the ones we want unblocked, not access from devices on other networks. So we can create an allow rule in this example for "Windows operating system" for the range containing our local domain to allow this traffic and end its block spams in the log. One more time, almost every time the range to use is 192.168.1.1-192.168.1.225. This will stop most log spam from "Windows operating system" or svchost.exe. It's important that we, unfortunately, cannot find a way to create a rule for "Windows operating system". For svchost.exe, we can simply create a rule at the top of the firewall list, but "Windows operating system" does not exist anywhere in Comodo by those exact words, "Windows operating system". When creating a rule there is no option to select it as the subject of the rule. This has caused me untold grief over that last 5 years, along with how to deal with svchost.exe. Well, the good news is, that "Windows operating system" is not important, unless it is causing log spam. Also, although it is not available by name to choose as a process/file group for rule creation, we CAN get Comodo to create a firewall rule for us in every situation where we would care to do so. This is because the only time we will care to create a rule for "Windows operating system" is when it is spamming the firewall log. So, if it is doing so, what do we do? OK, this is really not so bad and really quite simple. If I notice that the log events bar for the firewall is dominating the others, and I discover firewall log spamming from "Windows operating system", I would obviously like to resolve the dilemma with the spam. OK, so there is one important thing to note here. In the case of "Windows operating system", the entries are always going to be in the form of blocks. This is by design from Comodo. The only question then is whether there are too many. If so, because these are block events, we can look to "Unblock applications" on the widget to see if "Windows operating system" is there. Indeed, in every instance where a block appears in the firewall log for "Windows operating system", it will also appear in "Unblock applications". So, to create a rule that we can work with in the firewall area, all we have to do is find "Windows operating system" in "Unblock applications" and right click its entry to unblock its firewall block. Comodo does the rest, auto-creating an allow rule, even though there is no way to choose to create a rule for "Windows operating system" in Comodo (or at least that I have seen). This is great! However, it's important to note and consider here that the unblock we issued when we unblocked "Windows operating system" or svchost.exe from "Unblock applications" means that we just allowed ALL inbound traffic for this process (not for the entire system) with a new Comodo created "unblock" rule. So, in above examples, what do we do to set up rules nicely to get all blocks but only allows for safe local? OK, so here is how it's done. With the Comodo allow rule in place, create a new rule and make sure it is ABOVE the Comodo generate "unblock" rule for the application. Having found the range that you would like to allow, we set this new allow rule to allow for TCP and UDP and in. Then we set our IPv4 range below the rule title in the dialog. This is the range of safe IPs we determined to be our local network. OK the rule. Now, with your ranged allow rule in place above the "Unblock applications" rule for the application, we want to make sure now to go back and set the original rule to block. So, click on the original rule and open its Edit dialog. Set the rule to block TCP and UDP in and set it to log. Retitle the rule to match your choices for the rule, i.e. "svchost.exe (or "Windows operating system) Block and Log TCP/UDP In". OK the rule, and you should have the safest possible scenario. This is because you have the block rule in place as clearly Comodo felt was best. Obviously, it was Comodo's choice to firewall block the app in the first place via a firewall block. At any rate, you now have a simple way of allowing local or otherwise safe traffic into the system. You just create a single allow rule above the others any time for whatever IP needs access via the process, but the Comodo generated rule you turned into a block blocks all others. Here is how it will look after you are finished: [ATTACH type="full" alt="After Rules Creations.png"]224308[/ATTACH][/B] Note in the picture above that I have set one of the rules to log activity. This is not necessary and I wouldn't if it were leading to spam, of course. The important thing is that you are in control of the logging now. Also, you now have the added flexibility of being able to refine Comodo's choice to block "Windows operating system" or "svchost.exe". Don't know if "Windows operating system" affects Remote Desktop, but, if so, I could easily create a single allow rule for the single IP of each of the PCs I would like to use to connect via RDP. One other not about the above. There are two ranges that I have allowed, because I park two machines next to each other that use connection sharing for one of them to connect to the internet. The PC using connection sharing uses a different local range to make its connections. It considers the server the machine from which it gets its connection...see here: [ATTACH type="full" alt="Connection Sharing rule.png"]224313[/ATTACH] [B]Again, recall this same thing can happen with svchost.exe or "Windows operating system". And just to reiterate, if you notice a firewall block in the "Unblock Applications" area (lock icon on the widget) for either of these two processes, go to the firewall log to see if the process (svchost.exe or Windows operating system) is creating spam there. If so, go back to "Unblock Applications" and unblock the application for the protections shown that are blocking this application. This will auto-create an allow rule for the application for all IPs. So our job is to refine this situation so that only safe IP ranges are allowed. Back to the firewall area, we must set the allow rule created by unblocking in "Unblock Applications" back to "block", because we don't want to allow all traffic in via "Windows operating system" or "svchost.exe, either one. Find the "Windows operating system" or svchost.exe rule (should be the newest rule at the top). Now click on the "+" left of the entry to expand its rule(s). Change the rule and its title to "block" and OK the rule. Now, still in the firewall rules area, create a new allow rule under the process. Add this rule just above this process' existing rule which you just edited to re-create the block Comodo had originally been making. Make this rule an allow rule for TCP and UDP and in and then set the range of safe IPs (v4) to be allowed. Usually, the spam are in blocks, so you may find that you can get what you want (eliminate log spam) by just allowing the safe ones of these. Now set the range of the rule to your local network. The bulk of the traffic will now be allowed safely, since it is your local traffic. All other traffic will remain blocked. For this to stop the spam, make sure this allow rule is the top rule under the process' rules. Cure the log spam and you will be laughing with the angels about Comodo. Much if not most of the bugginess and clunkiness will disappear. Here is how a clean log without spam should appear: [ATTACH type="full" alt="Balanced Log.jpg"]224306[/ATTACH][/B] No one or two categories overwhelm the statistics in the lab. If we see one bar very high and the others very low, this can be a tell tale sign of log spam. [B]ONE NOTE: When leaving a menu in Comodo settings, make sure to use the button at the bottom of the form to exit the menu. Never use the x's. Rules will not be remembered if the x's are used to leave a menu. Think of a trip into the settings area as a session. During this session, we must use the "OK" button to leave a dialog in order for Comodo to remember the change being made. This means for all dialogs. So, we must back out of the settings area using the OK button. Even one use of an x on the way out will void all changes made. This is obviously important to learn with Comodo. Use an x to escape a settings menu after making a change->expect the change won't be made. Hope this helps some. Still in the formulative stages of setting some things up.[/B] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
