Software Restriction Policies
Software Restriction Policies (SRP) can prevent all malware/virus attacks, including cryptolocker and other ransomware, even if they originate from an email attachment or website or usb drive or Hell itself. SRP is free and already on your computer, you just have to enable it. SRP is basically a whitelist for programs. Any program not on the list will not be allowed to execute. Prerequisites: You will need to know what files and folders are, and understand the difference between an EXE file and DOC file. If you run a domain server and use group policy objects, you can enforce SRP that way, but this article targets workgroup computers. If you run windows 7 home edition, click here. If you have a "server", it doesn't need to have SRP enabled, unless users are sitting in front of it and surfing the internet. I wish setting up SRP were as easy as switching a setting on, but it's not. It's hidden deep within windows surrounded by lots of techno jargon, but I’m going hold your hand through it. Open your local security policy Right-click SOFTWARE RESTRICTION POLICIES Double click ENFORCEMENT and select ALL USERS EXCEPT LOCAL ADMINISTRATORS (Unless you actually surf the internet or check email with an account that has admin permissions. That’s a bad habit, but as long as UAC isn't disabled, SRP will still treat you like a non-admin.) Double click DESIGNATD FILE TYPES and remove LNK and URL, and add PS1. Set the default security level to DISALLOWED. Right-click and add new path rules for: If you use the free Microsoft Office Starter Edition, If you need to add a network share to the list, you can't use mapped drive letters, like s:\programs\. You must the use UNC path, like \\server\share1\programs. You must restart windows after you enable SRP for the first time, but you won't have to restart when you make changes to the rules later. Some computers might require more rules if they run programs from some other weird folder(s). I do not recommend adding c:\users to the list because that would defeat the main purpose of SRP. You must not add any user-writable folders to the list. If you have programs like firefox or chrome that are running from c:\users\johndoe\appdata\ instead of c:\program files, you need to either reinstall it and choose "all users" instead of "just me", or use a certificate based rule. Certificate rules could be useful for certain situations. Most EXE files are "signed" with a digital signature that proves that the EXE file came from the company it claims, and that it hasn't been modified since it was signed. You could add companies like Adobe, Google, and Microsoft but if you use a separate ADMIN account to install new software as I recommend, you won't need certificate rules because we disabled enforcement on administrators anyway. Certificate based rules are known to cause minor performance issues, such as CMD intermittently taking a few extra seconds to start. I have created a ZIP file that I will try to keep current that contains the certs I find myself using the most. Most certificates change every year or two, so if you depend on them, you will need to stay on top of it. Hash rules could also be useful for EXE files that have no signature. A hash rule will confirm that the EXE hasn't been modified since the rule was created. If the EXE file auto updates itself periodically, this rule will drive you up the wall. Network Zone rules seem pretty useless. There is no network zone I would trust in this day and time. If you screw up and somehow block yourself from being able to edit the rules, just boot windows in safe mode, and you will be able to fix it. When SRP blocks a program, it will generate an event 865 or 866 in the Application Log. This is helpful for troubleshooting your rules. This is what the user will see: Known Weakness 1: SRP does not stop Chrome extensions or Firefox add-ons. These extensions/add-ons are not exactly programs, so they are out of SRP's jurisdiction. This can be a major issue because from what I can tell, these extensions/add-ons have read/write access to the file system, which means it would be possible to make a ransomware extension/add-ons! However, Chrome and Firefox can both be tamed.How to tame Chrome How to tame Firefox Known Weakness 2:
Office documents can have macros that have read/write access to the file system. By default, the macros are disabled, but it only requires one click to enable the macros and cause damage.
This is a common real-world threat that I see. You can disable macros in word by going to options, trust center, trust center settings, macro settings, disable all macros without notification. You would also need to do this for Excel, Powerpoint, Access, and all the other Office programs you have installed. To top it all off, this is a per-user setting, so you would have to do this on every user account on every computer. If you are using Active Directory, you can save a lot of time by using a GPO. You'll need to download the Office Administrative Template files from Microsoft in order to see the needed settings in the group policy editor. Just search google for "Microsoft Office Administrative Template files". Adobe Reader also has Javascript and other features that don't belong in PDF files, and they can be disabled but the user can easily override the block unless you disable it with registry policies. Search google for "adobe FeatureLockDown". Known Weakness 3:
Does not work on the GUEST account for some reason. This appears to be a bug in SRP that Microsoft is probably not aware of, and I can't find much info about this issue. Just don't use the guest account. I have found other extremely major security issues with the guest account too, such as RDP allowing logins to GUEST, with a blank password, and even when guest is "disabled"! Don't believe me? Add your "everyone" group to the "remote desktop users" group and try it for yourself! Known Weakness 4:
RUNAS for some reason doesn't obey the SRP policy. You can log into windows as a restricted user, download a program, shift+right-click it, run as different user, enter the same username and password, and presto! This trick doesn't seem to work if the user has a blank windows password. I don't know why Microsoft left this huge hole. The only way I know to plug this hole is to disable RUNAS (google it for a how-to). Viruses won't be able to leverage this weakness automatically, but users could be tricked into doing the steps manually by malicious emails or advertisements. Known Weakness 5:
The windows folder has a few subfolders that are writable by non-admins by default. That means a user could copy a program to one of these folders, then execute it. I guess you would have to block each one of these folders in SRP. C:\Windows\debug\WIA\ These folders have to remain writable to maintain backwards compatibility with older software. Viruses won't be able to leverage this weakness automatically, but user's could be tricked into doing the steps manually by malicious emails or advertisements.
Other than that, Enjoy!
|
