Critique my Security Setup

-Avira AntiVir Premium real time with Guard, Mailguard, and Webguard.
-FF with ABP.
-Sandboxie with FF and IE forced, drop admin rights, auto delete sandbox when browsers are closed.
-MBAM Pro on demand.
-Paragon Backup and Recovery v10 Pro for backups.
-Just installed Emsisoft Anti-Malware on demand (A-Squared Anti-Malware, I had a 1 year license and just reinstalled it)
-LookNStop FW x64 v2.07

What should I add, take away, change etc.

 

FF+WOT

 

Avira real time. With that setup I'd run nuthin real time. Personally, I like MBAM free as on demand only. I think of real time antimalware as a "kind of virus unto itself"; it slows the system while it tries to protect against threats that aren't likely to occur - against you - because you already harbor the requisite knowledge to prevent threats in the first place I mean, really, Sandboxie run in your limited account (you are running limited, right?) with your sound Paragon insurance policy is already a malware bug's worst nightmare come true.

 

I dont use a limited account. I have the only account on this computer and install/uninstall and trial software all the time. I find it a pain to use a LUA. Hence the reason for Sandboxie and dropping admin rights within browsers.

 

Oh well, the way she goes sometimes. Even as admin, I think you're still okay, After all, there is a crafty member in this forum, Franklin, who runs full admin with Sandboxie, running all kinds of malware for volunteer purposes - good on him - and never gets malware breeches

 

Here is my advice to you my friend

Uninstall everything including Windows and install Ubuntu Lucid Lynx or openSUSE 11.2 that is all you need and have your tranquility back in your brain. No kidding.

Thanks.

 

Hilarious! Maybe priceless? I doubt that's an option CT.

 

No thanks.

 

Have you considered using a DropMyRights approach with your browsers? In this way you can achieve "user" mode for them, before SBIE gets the process, and you don't have to "drop rights" within SBIE.

I do this. I am admin, I start browsers as "user" with DMR approach, let them forced into SBIE. Then within SBIE there is no "drop rights", so my browser can install etc. However, deleting sandbox is easy, and I trust SBIE to not let anything out. IF something ever were to escape SBIE, then it is going to display the "user" rights that it was started with via DMR.

This is the only security measure I use any more, other than keeping my wits about me and an image at hand in case it is needed or I feel the weekly urge to restore it.

Sul.

 

solid setup. Personally I don't bother with Mail or Web guard.

 

I havent considered it. I figured installing DMR and Sandboxie with DMR built in would be redundant. No sense in installing 2 programs to accomplish the same thing.

 

Well you said to critique and I did. In any event your loss man.

 

I just politely declined. Not sure why your getting your undies in a bunch. Not my loss since I game more than anything.

 

Well I just politely said your loss. I really do not know why you thought I was getting my "undies" in a bunch. Come on chill out.

Thanks.

 

@whitedragon551
you already have a pretty solid setup ... but it would be even solid if you sandbox all internet facing programs you have and not just your browsers.

 

You perhaps do not understand exactly. The DMR feature in SBIE is meant to give the same effect for a program that is sandboxed as DMR would when a program is not sandboxed.

Consider that whether you are a user or employ DMR, that a browser will not be able to write to c:\windows. However, there are no restrictions at all for a browser started this way in the c:\sandbox\box_name\drive\windows directory. So in effect, a user will not experience a restrictions within SBIE.

The DMR feature built into SBIE takes this into account. Now, as an admin, when the browser starts in SBIE it will act as if it were a user, so it cannot write to c:\sandbox\box_name\drive\windows.

My direction comes from the view that if I start my browser with DMR, it is pretty solid generally and now has limited rights. Once within SBIE, if I want this same restriction, I enable that DMR feature of SBIE. However, my goal is not to be a user really, just to protect specific areas of concern, such as a browser, from common exploitation. So I do not employ the DMR feature of SBIE. Now when I browse, within SBIE it "feels" like I am admin still. I can install/delete/etc just like normal. However, it is all within the sandbox, so I don't fear really what happens.

If SBIE ever failed, and let something out of the sandbox, then the browser will inherit the OS DMR, and not be able to write to restricted areas.

So redundant, not really. You just need to understand the default restrictions and how they don't apply in situation like this.

Sul.

 

Id use a virtual machine for testing.

 

That would be almost all apps I use. Avira, xFire, BF2, COD4, A-Squared, etc. anything that uses the net to update itself.

 

Try Shadow Defender. One of the best apps i have every used. It's extremely light on resources, and uses about 7,000k of memory if i remember correctly.

 

Ive tried SD and I didnt like it.

 

obviously no need to sandbox your AV/AM

 

Thats still all my video games as they are all online, mail clients, MS Office 2007 suite, and anything else that uses the net for updates. Id have to constantly turn off forced programs to allow the updates and at that point Sandboxie becomes a moot point because its no longer in use.

 

I run all my games sandboxed ... as well as ms office 2007 ... you don't update them on a daily basis, do you? Anyway, that's just a suggestion, it's working for me but might not work for you for some reason.

 

Actually it doesn't work this way, It should work the same as using a separate DMR program and using sandboxie.

I just tested with the DMR on and off in sandboxie 3.44 from a LUA and an admin account and there weren't any differences, I was always able to write to c:\windows (c:\sandbox\etc...\windows)

If you turned DMR on in sandboxie and added a direct access to c:\windows\ then you would get an access denied message.

If I tried to write to c:\windows from the LUA without sandboxie I also got an access denied message.

So it would be redundant to use both,
Unless you feel safer using 2 different programs for protection in case for some reason one doesn't work right...

Below are just some posts about the DMR feature in sandboxie.
http://www.sandboxie.com/phpbb/viewtopic.php?p=29552#29552
http://www.sandboxie.com/phpbb/viewtopic.php?p=30786&sid=a3aa91c9a26ebeee2398ca3272bdc142#30786
http://www.sandboxie.com/phpbb/viewtopic.php?p=30903&sid=a3aa91c9a26ebeee2398ca3272bdc142#30903

 

There may be some discrepancies here. For a fact, the DMR feature in SBIE does indeed strip the admin/pu token from the process within SBIE. I don't know if it employs it in the same way that the NTCreateProcess method that DMR uses or not. But, you should see that any object/container that is defined in the default security template of the OS, which is applied at installation time, as well as any newly created/modified rights on any object or container should carry over into SBIE when using the DMR option.

If you start notepad, as an admin, into a sandbox without the SBIE DMR option enabled, you will be able to access for example c:\boot.ini and modify it. The resulting file should be in the sandbox only.

If you start notepad as an admin, into a sandbox with the SBIE DMR option enabled, you will not be able to access c:\boot.ini at all, exactly as if you were a user or you were using DMR in the real OS.

If you start notepad as a user, into a sandbox without the SBIE DMR option enabled, you will be able to access c:\boot.ini.

If you start notepad as a user (LUA), into a sandbox with the SBIE DMR option enabled, you will not be able to access the c:\boot.ini file.

It is possible there could be some items that are not included for some reason with the SBIE drop rights option, I have not tested it that in-depth.

But one thing I do know, the default security template, that is applied when you installed the windows OS, declares what object/container a group/user has rights to. New items may be exempt from this, depending on the inheritance and propogation methods employed.

I will stand by my statement, and have tested it again in case I made a mistake. The drop rights feature in SBIE should not give you access to any object/container that a user does not have rights to in the real system, unless things have been modified.

It is always possible I am incorrect. I have tested this time and time again, on many machines. Perhaps the key here for your findings is maybe they were not prescribed in the default security template? For example, items in c: should be off limits to a user, but you are allowed to create new containers, and then as the owner, you are allowed to do what you wish. But the files that are on c: that the default security template applied rithts to are not. And this shows itself in SBIE when you test it correctly.

I was involved in a few posts over at their forum, and Tzuks response to a lot of in-depth questions was pretty simple.... "it is just stipping admin and power user tokens". And from what I see it mimics exactly what the SAFER calls do inside the sandbox as if it were outside the sandbox.

Interesting topic, be neat to see what you come up with, as I for one would like to see any deviation from what I have seen. Enquiring minds want to know

Sul.