i made this guide for an older version of WSA, but it is still valid:
http://malwaretips.com/Thread-How-to-setup-Webroot-SA-alongside-another-Antivirus
feel free to correct if something is wrong.
Page 1 / 1
That's a pretty solid guide for the most part. Thanks for sharing! I'd offer a few minor tweaks.
Many of these settings are default settings already. Of course, you may not be assuming that the person reading the guide is operating from a clean install, but has rather already been fiddling with the settings in advance.
You are careful to note where some of the settings are a matter of preference more than a matter of making WSA run optimally alongside another antivirus program, which is good. However in Step 5: Real-time Shield, it has the suggestion to untick "scan when written or modified." I assume this is a slight performance tweak on your part, but that isn't really a necessary step. If WSA sees another antivirus program attempting to take action on-write or on-modification, it will recognize this and allow the other security program to do its job without interfering. There should be no worry of conflict with leaving that setting on.
The Step B2 - Quarantine section is not necessary. Webroot maintains a global listing of good files in addition to bad ones and unknown ones. Third-party antivirus software is included in this list. It takes less time for WSA to ask the cloud if the software in question is good, bad, or unknown than it does for you to manually tell it to flag all of those files as good. Additionally, the third-party software is probably going to update a lot, being that it's antivirus software (most-likely old-school definitions based stuff too). When it updates, those files change, and for all real purposes they are new files. The original whitelisting action you would have taken would have whitelisted a certain set of files locally, but it wouldn't account for updates. However, our cloud-based whitelisting does that automatically, which is why you notice no ill effects.
On Step C, I'd caution that you want to know for sure what you're telling it to Allow. If you see programs you use all the time in that list and you are positive they are not threats, you can toss them into the Allow column. However, there are two things to consider about this:
1. Don't just go by the name. Some threats will name themselves something convincing in an effort to evade manual detection (think "windows.exe" or even real file names like "smss.exe").
2. Uncertainty should raise suspicion. Obscure names can be bad stuff too. If you see something like aphwef876.exe (I just hit random keys there like a polymorphic infection would rename itself), and it's sitting in a Monitor or Block status, there's a good chance that's an infection.
While some users are tech-savvy enough to be able to investigate entries that are unjustifiably set to Monitor and decide to Allow them, other users who are less tech-savvy would be wise to either A) leave those in Monitor status in case they are later flagged as Bad and need to be automatically rolled back to before WSA first saw them or 😎 contact Support to determine if such movement to Allow is justified. B is preferred, because any time you ask Support about a file that we are currently marking as Unknown, it prompts us to look at that file right away and determine it. That doesn't just help you - that helps everyone with WSA installed, which is pretty cool when you think about it.
Many of these settings are default settings already. Of course, you may not be assuming that the person reading the guide is operating from a clean install, but has rather already been fiddling with the settings in advance.
You are careful to note where some of the settings are a matter of preference more than a matter of making WSA run optimally alongside another antivirus program, which is good. However in Step 5: Real-time Shield, it has the suggestion to untick "scan when written or modified." I assume this is a slight performance tweak on your part, but that isn't really a necessary step. If WSA sees another antivirus program attempting to take action on-write or on-modification, it will recognize this and allow the other security program to do its job without interfering. There should be no worry of conflict with leaving that setting on.
The Step B2 - Quarantine section is not necessary. Webroot maintains a global listing of good files in addition to bad ones and unknown ones. Third-party antivirus software is included in this list. It takes less time for WSA to ask the cloud if the software in question is good, bad, or unknown than it does for you to manually tell it to flag all of those files as good. Additionally, the third-party software is probably going to update a lot, being that it's antivirus software (most-likely old-school definitions based stuff too). When it updates, those files change, and for all real purposes they are new files. The original whitelisting action you would have taken would have whitelisted a certain set of files locally, but it wouldn't account for updates. However, our cloud-based whitelisting does that automatically, which is why you notice no ill effects.
On Step C, I'd caution that you want to know for sure what you're telling it to Allow. If you see programs you use all the time in that list and you are positive they are not threats, you can toss them into the Allow column. However, there are two things to consider about this:
1. Don't just go by the name. Some threats will name themselves something convincing in an effort to evade manual detection (think "windows.exe" or even real file names like "smss.exe").
2. Uncertainty should raise suspicion. Obscure names can be bad stuff too. If you see something like aphwef876.exe (I just hit random keys there like a polymorphic infection would rename itself), and it's sitting in a Monitor or Block status, there's a good chance that's an infection.
While some users are tech-savvy enough to be able to investigate entries that are unjustifiably set to Monitor and decide to Allow them, other users who are less tech-savvy would be wise to either A) leave those in Monitor status in case they are later flagged as Bad and need to be automatically rolled back to before WSA first saw them or 😎 contact Support to determine if such movement to Allow is justified. B is preferred, because any time you ask Support about a file that we are currently marking as Unknown, it prompts us to look at that file right away and determine it. That doesn't just help you - that helps everyone with WSA installed, which is pretty cool when you think about it.
@ wrote:
That's a pretty solid guide for the most part. Thanks for sharing! I'd offer a few minor tweaks.
Many of these settings are default settings already. Of course, you may not be assuming that the person reading the guide is operating from a clean install, but has rather already been fiddling with the settings in advance.
Thanks, i posted it here to got feedbacks on it. i knew it was not perfect ;)
You are careful to note where some of the settings are a matter of preference more than a matter of making WSA run optimally alongside another antivirus program, which is good. However in Step 5: Real-time Shield, it has the suggestion to untick "scan when written or modified." I assume this is a slight performance tweak on your part, but that isn't really a necessary step.
You are right, it was a performance tweaking option (most of our members are quite sensitive to performance); since i always set my companion AV (WSA in this case) to detect on executed only.
The Step B2 - Quarantine section is not necessary. Webroot maintains a global listing of good files in addition to bad ones and unknown ones. Third-party antivirus software is included in this list. It takes less time for WSA to ask the cloud if the software in question is good, bad, or unknown than it does for you to manually tell it to flag all of those files as good. Additionally, the third-party software is probably going to update a lot, being that it's antivirus software (most-likely old-school definitions based stuff too). When it updates, those files change, and for all real purposes they are new files. The original whitelisting action you would have taken would have whitelisted a certain set of files locally, but it wouldn't account for updates. However, our cloud-based whitelisting does that automatically, which is why you notice no ill effects.
Good to know, i wanted to be the most cautious possible to avoid any posssible conflicts/system slowdown; i will add your feedback on my guide.
On Step C, I'd caution that you want to know for sure what you're telling it to Allow. If you see programs you use all the time in that list and you are positive they are not threats, you can toss them into the Allow column. However, there are two things to consider about this:
1. Don't just go by the name. Some threats will name themselves something convincing in an effort to evade manual detection (think "windows.exe" or even real file names like "smss.exe").
2. Uncertainty should raise suspicion. Obscure names can be bad stuff too. If you see something like aphwef876.exe (I just hit random keys there like a polymorphic infection would rename itself), and it's sitting in a Monitor or Block status, there's a good chance that's an infection.
While some users are tech-savvy enough to be able to investigate entries that are unjustifiably set to Monitor and decide to Allow them, other users who are less tech-savvy would be wise to either A) leave those in Monitor status in case they are later flagged as Bad and need to be automatically rolled back to before WSA first saw them or 😎 contact Support to determine if such movement to Allow is justified. B is preferred, because any time you ask Support about a file that we are currently marking as Unknown, it prompts us to look at that file right away and determine it. That doesn't just help you - that helps everyone with WSA installed, which is pretty cool when you think about it.
yes you are also right on this point, on the forum i belong , we are quite averted users so i forgot sometimes the basic users .
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.