Preventing computer malware by using Software Restriction Policies.

1. What does protection from viruses and other malware begin with?

        Protection from computer viruses, ’trojan horses’ and stuff like that strictly depends on the privilege level you use when working on a computer. Usually, all the user accounts are divided into two categories – administrative, which is designed to be used to install programs and configure the system; and standard (with limited rights), which is designed for everyday work. Do you want to configure the software or install something new? Log on as an Administrator. Are you going to watch movies, write some e-mails or communicate through instant messenger? Log on as a Standard User.

        The situation is that normal users do not have enough rights to install programs and tune up the system, thus make it working in a very stable, reliable and secure manner. The users simply cannot mess something up or break something important, because their rights are not enough to do that. A computer virus is not any ‘voodoo magic‘ at all but just usual software, a computer program, that’s why a standard user is not able to infect the system with it. And even more, it does not matter for a computer if the virus is a new or old one, a very complex or primitive one – if the current permissions are not enough, it is not possible to copy virus body to the system folders or add it’s autorun to the Registry, anyway.

SRP_StandardUser

Fig. 1. Selecting user account privilege level in Windows 7

        Regardless of whether we work in the office or at home, we should always log on as Standard Users with limited privileges. Even systems administrators should maintain two user accounts – a standard and an administrative one, but use the latter only when there is a real need to. You can check the type of your user account in the Control Panel.

        Nevertheless, there are some malicious programs that are able to hide and launch themselves not only from system folders, but also in the user working environment – the so-called User Profile. Those programs start automatically every time the infected user logs on to the computer. Usually, such viruses come from flash drives, are spread through instant messengers or get into a computer from the specially crafted webpages. In order to prevent such threats effectively, there is a very simple and reliable Microsoft Windows security setting, which is called Software Restriction Policies.

 

 2. So what are the Software Restriction Policies (SRP) about?

        SRP is a native Windows tool that allows administrators to whitelist software which is permitted to be launched on a computer; all other software is prevented from running. For example, we can tell the system: ”let all the programs from within the C:\Windows, C:\Program Files, D:\Games folders run, but not from any other folder”. As a result, any virus that comes from the flash disk is silently blocked, not being able to start from the restricted folder E:\ or Z:\. Maybe some executable tried to get into a computer from an untrusted website? Well, it won’t run because it was stored in a User Profile within either Temporary Internet Files or %Temp% folders, which are not permitted by the policy. Neither the ’trojan horse’ received by the messenger means being introduced like “super-mega-screensaver” will run.

        Software Restriction Policies have many advantages comparing any popular antivirus program, be it Kaspersky, NOD or Avast even (the actual names of the products and manufacturers do not matter at all). The thing is that ’catching fleas’ with an antivirus program is just a computer analogue of ’russian roulette’, and it’s not clear that you will win this game. In contrast, SRP denies everything which was not previously permitted without guessing if it is good, bad or ugly.

        Notice that the policy itself does not prevent saving a virus body to a computer’s hard disk. SRP is not an antivirus program, thus does not perform any heuristic analysis against files. But what it really does is prevent the suspicious executable from being launched from the disk or flash drive.

        You do not need to search and download the SRP system, it’s built-in to the following Microsoft OS:

  • Windows XP Professional, Windows XP Media Center 2005;
  • Windows Vista Business, Windows Vista Enterprise & Ultimate;
  • Windows 7 Professional, Windows 7 Enterprise & Ultimate;
  • Windows Server 2003 и 2008 (all editions);

        Unfortunatelly, none of the Windows Home versions are supported.

 

3. How do I enable and configure the SRP?

        In order to enable SRP we need to log on to the computer using an administrative account and issue the following command: Start Run gpedit.msc . Navigate to Computer Configuration container, open Windows Settings folder → Security Settings → Software Restriction Policies.

SRP_CreatePolicy

Fig. 2. Enabling SRP in local policies

        This configuration looks similar on all supported Windows versions. Additionally, when configuring Active Directory domain policies you can also find the SRP folder in the User Configuration container. You may find it useful to establish the SRP baseline in the Computer Configuration section, but implement the User Configuration part to expand SRP policy coverage area for the particular user groups only.

        Right-click the Software Restriction Policies folder and select the Create New Policies command. The policy is created, now we will make some additional configuration. Double-click Enforcement value and make sure Apply to: All software files and Apply to: All Users options are selected. This will ensure that all the executables including dynamic libraries (DLLs) are verified, and all the users including Administrators (the most dangerous users by the way) are protected.

        Frankly, an Apply to: All software files option can be too tighten and very complex to maintain in some cases. This is not common but there are some applications that call their DLL modules incorrectly; some applications do keep many of their modules in user profiles even. In that case you may find it easier to weaken the security a bit by switching to Apply to: All software except libraries option. You may do it taking into account that there is a lot of DLL-type malware that is executed by a command like ’rundll32.exe C:\Recycler\virus.dll’, and the amount of that malware constantly grows. And even more, only full executable filtering is able to prevent exploiting ’DLL Hijacking’ application vulnerability.

SRP_Enforcement

Fig. 3. Configuring SRP enforcement options.

        One of the policy parameters could be annoying and could provide no security advantages. By default, SRP processes not executables only but some other file types, too – for example, LNK-files (shortcuts). Double-click the Designated File Types option and remove LNK extension from the list. Note that shortcuts and target executables are not the same. Removing shortcuts from the SRP the security level is not lowered, users won’t be able to use shortcuts to launch restricted executables, anyway.

SRP_FileTypes

Рис. 4. Configuring file types processed by SRP.

        There are the following default SRP security levels:

  • Disallowed: ’whitelist’ mode. All programs except those separately listed are prohibited from running;
  • Basic User: enforced limited privilege mode. All programs except those separately listed are launched with standard user privileges regardless of the current user rights. Only works with UAC enabled;
  • Unrestricted: ’blacklist’ mode. All programs except those separately listed are permitted to run.

        Open Security Levels subfolder, right-click the Disallowed mode and set it to as default.

SRP_DefaultLevel

Fig. 5. Enabling ’whitelist’ as the default policy behavior.

        In the Additional Rules container there are programs listed that are permitted to run on a computer. There are a few entries built-in which provide permissions for the software within the Windows and Program Files folders to be launched from. Thus, most programs will run successfully by default, and the tricky part is that standard users are not allowed to modify those folders contents. In case some business-related software was installed into another folder, you just put a Path to that folder to the policy rules marked with Unrestricted mode. Also, you may find it to be a good idea to add executables by their hash signature – in case the executable would gets infected with a virus, its hash changed and the program was prevented from launching.

        As long as it is possible, when expanding Additional Rules only add folders/paths which users do not have Modify permissions to. ’Whitelisting’ SRP mode not only blocks accidentaly received malware but also all other unwanted software like games, chat clients, alternate internet browsers as well. Never add rules like C:\, %Temp% or F:\ (removable drive) with Unrestricted access level because this would void all the SRP implementation goals.

SRP_AdditionalRules

Fig. 6. Managing a list of unrestricted software.

        Well, the thing is done. For the policy to come into effect for the very first time, restart the system. The upcoming maintenance and security level tuning will not require reboots anymore.

 

4. What should I do if something stopped working on an SRP-enabled system?

        In case you suspect that some end-user program is not working because of SRP restrictions, you can examine the Application Event Log which is accessible by issuing the Start Run eventvwr.msc command.

SRP_EventViewer

Fig. 7. Examining the Application event log.

        You may find some Warning entries from the SoftwareRestrictionPolicies source which have Event ID 865. Double-click the entry and examine it’s contents to see if there’s some executable file mentioned related to a faulty program. Check out the name and the path of the blocked module and add either the required path or the hash of that module to the Additional Rules container of SRP configuration. Try running the program again to see if it’s working now.

 

5. Everything is just fine for now, but how do I maintain the system in the future?

        You might want to install new programs or update the current programs from time to time. It is required to disable SRP restrictions to get these things done, but only for quite a short time. To manage SRP security levels very quickly, you may want to place the following two reg-files to the Windows folder:

SRP_Disable.reg

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000

SRP_Enable.reg

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000

        In fact, the DefaultLevel value does not turn the policy off but switches the current SRP behavior from ‘whitelisting’ (Default: Disallowed) to ‘blacklisting’ (Default: Unrestricted), thus permitting the launch of any program except those clearly described as Disallowed in the Additional Rules policy container. Try avoiding creating rules with Disallowed security level because this makes policy maintenance too complex.

        Create the shortcuts to the reg-files mentioned above and place them on the administrator’s desktop. The software installation procedure won’t become too complex compared with that you have done before:

  • Disable security by switching the SRP mode to Unrestricted with an SRP_Disable shortcut;
  • Install or update all the software you need;
  • Enable security by switching the SRP mode to Disallowed back again with an SRP_Enable shortcut. If you don’t do that, SRP will be enabled automatically at the next reboot of the system.

SRP_Shortcuts

Fig. 8. SRP security level configuration shortcuts.

        Possibly you will forget to enable SRP again after installing a program. To get the protection turned on automatically during background Group Policy processing (90±30 minutes by default), make the following Group Policy configuration for the local computer: run gpedit.msc, navigate to the Computer Configuration → Administrative Templates → System → Group Policy. Double-click Registry Policy Processing value, set it to Enabled and enable Process even if the GPO have not changed checkbox.

        Software Restriction Policies are not able to provide protection from 100% of the viruses, trojans and other malware by design. However, it’s efficiency is much higher than any standard antivirus program around. Good luck increasing the security level of your computer!

Last Content Update: 16-Jan-2011

14 Responses to Preventing computer malware by using Software Restriction Policies.

  1. Russ Hall says:

    I can’t believe they didn’t include this great security addition to Windows home versions! What were they thinking? Home users don’t get viruses?

  2. anyone says:

    Article is a great one.
    Can we have list of hash of the files of viruses so that we can block them.

  3. Jeremy says:

    I really appreciate the article for some reason when i use the registry entry to turn off the goo.
    when the workstation is rebooted it is not re applying the security setting, it doesn’t apply unless i do a gpupdate /force

  4. Уведомление: PoS Malware Mitigation Advice from the Pros

  5. Rukicc says:

    IF you use system center consoles, then add to exceptions «%userprofile%\AppData\Local\Microsoft\System Center Service Manager 2010». In this folder are DLL files.

    In system log was only records like this.

    «The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server %username%. The target name used was %hostname%. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (%your_domain%) is different from the client domain (%your_domain%), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.»

  6. Уведомление: Prévention des programmes malveillants sur les points de vente : quelques conseils efficaces – Par Norman Girard, Vice Président et directeur général Europe de Varonis | Docaufutur

  7. Уведомление: Prévention des programmes malveillants sur les points de vente : quelques conseils efficaces. | Varonis Français

  8. Marco says:

    Great stuff!
    You have to keep in mind that unfortunately more and more legitimate applications are (partly) installed into %USERPROFILE% and %ProgramData% (e.g. Dropbox, Chrome), therefore you must whitelist them.

    • 1. That’s right, but be sure to not to add a whole %UserProfile% to SRP rules! Use hashes or very precise paths instead.
      2. Not really. Deploy Chrome Enterprise to Program Files folder, then control it with GPO instead of running portable version from UserProfile. User folders in general must be banned from saving and launching executables.

      • Marco says:

        Right, they SHOULD be banned, but somehow Chrome (not the portable version) likes to start from [%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe]
        and it even uses
        [%LOCALAPPDATA%\Google\Update\GoogleUpdate.exe]
        from time to time.
        So I whitelisted [%LOCALAPPDATA%\Google].
        Hashes are inconvenient because applications like Chrome and Dropbox update very often.

        Internet Explorer 8 was a pain in the ass, I had to whitelist [%ProgramData%\Symantec\Symantec Endpoint Protection] because «reasons».

  9. Уведомление: SRPs avoid malware, but what if things stop working? – Blog

Оставьте комментарий