InstallerGeek created the topic: Windows 7 Security: What You Need to Know, Part Three
Malicious Trojans continue to plague end-users’ desktops, yet most machines aren’t exploited due to missing patches (although this is the second biggest cause), unpatched zero days (almost never a factor), drive-by downloads, or misconfigurations. Nope, most systems are infected because users are duped into intentionally installing programs that Web sites say they need. These socially engineered Trojans come in the guise of anti-virus scanners, needed codecs for a media player, fake patches, and just about any other bait the bad guys can concoct to lure end-users into installing their Trojan file.
The most effective means of thwarting these types of threats in an enterprise environment is preventing end-users from installing unapproved programs. If you leave the decision up to end-users, they will almost always make the wrong choice. If they didn’t, malware wouldn’t be nearly as popular as it is today.
Microsoft’s most sophisticated solution to the problem is AppLocker, an application-control feature included in Windows 7 (Ultimate and Enterprise versions) and Windows Server 2008 R2. This week, in part three of my ongoing series about Windows 7 security improvements, I’ll discuss AppLocker. (You can read my part one, an overview of some of the security changes, and part two, covering XP Mode. Also, for the sake of full disclosure, I’m a full-time employee at Microsoft.)
Opening Up AppLocker
AppLocker is an improvement on the Software Restriction Policies (SRP) introduced with Windows XP Professional. AppLocker allows you to define application execution rules and exceptions based on file attributes such as path, publisher, product name, file name, file version, and so on. You can then assign policies to computers, users, security groups, and organizational units via Active Directory.
You can configure AppLocker locally using the Local Computer Policy object (gpedit.msc) or via Active Directory and Group Policy Objects (GPOs). AppLocker relies on the built-in Application Identity service, which is normally set to manual startup type by default. Administrators should configure the service to start automatically.
Within the local or group policy object, AppLocker is enabled and configured under the \Computer Configuration\Windows Settings\Security Settings\Application Control Policies container.
By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed. First-time testers will benefit by allowing AppLocker to create a default set of “safe rules” using the Create Default Rules option. The default rules allow all files in Windows and Program Files to run, along with allowing members of the Administrators group to run anything.
One of the most notable improvements over SRP is the ability to run AppLocker against any computer using the Automatically Generate Rules option to quickly create a baseline set of rules. In a few minutes, dozens to hundreds of rules can be produced against a known clean image, saving administrators anywhere from hours to days of work.
Choice, Choices
AppLocker supports four types of rule collections: Executable, DLL, Windows Installer, and Script. SRP administrators will notice that Microsoft no longer has the registry rules or Internet zones options. Each rule collection covers a limited set of file types. For example, executable rules cover 32-bit and 64-bit .EXEs and .COMs; all 16-bit applications can be blocked by preventing the ntdvm.exe process from executing. Script rules cover .VBS, .JS, .PS1, .CMD, and .BAT file types. The DLL rule collection covers .DLLs (including statically linked libraries) and OCXs.
If no AppLocker rules for a specific rule collection exist, all files that share the same format are permitted to run. However, once a rule for a specific collection is created, only the files explicitly allowed in the rule can execute. For example, if you create an executable rule that allows .EXE files in %SystemDrive%\FilePath to run, only executable files located in that path are allowed to run.
AppLocker supports three types of rule conditions for each rule collection: Path Rules, File Hash Rules, and Publisher Rules. Any rule condition can be used to allow or deny execution, and it can be defined for a particular user or group. Path and File hash rules are self-explanatory; both accept wild card symbols. The Publisher rules are fairly flexible and allow several fields of any digitally signed file to be matched with specific values or wild cards. By using a convenient slider bar in the AppLocker GUI, you can quickly replace the specific values with wild cards. Each new rule conveniently allows one or more exceptions to be made. By default, Publisher rules will treat updated versions of files the same as the originals, or you can enforce an exact match.
Worth the Cost
However, if you need to make a rule for a file type that is not defined in AppLocker’s policy table, you’ll need to use some creativity to get the desired effect. For example, to prevent Perl script files with the .PL extension from executing, you would have to create an executable rule that blocked the Perl.exe script interpreter instead. This would block or allow all Perl scripts and require some resourcefulness to gain finer-grained control. This is not a unique issue, as many other application control products have the same sort of limitation.
AppLocker’s configuration and rules can easily be imported and exported as readable XML files, the rules can be quickly cleared in an emergency, and all can be managed using Windows PowerShell. Reporting and alerting are limited to what can be pulled from the normal event logs. But even with AppLocker’s limitations, the price tag — free, if you are running Windows 7 and Windows Server 2008 R2 — can be a strong lure for up-to-date Microsoft shops in preventing socially engineered Trojans.
Next week, I’ll wrap up this series with a discussion of many other Windows 7 security deltas.
- DevOps Certified Professionals (DCP)
- Site Reliability Engineering Certified Professionals (SRECP)
- Master in DevOps Engineering (MDE)
- DevSecOps Certified Professionals (DSOCP)
URL - https://www.devopsschool.com/certification/
My Linkedin - https://www.linkedin.com/in/rajeshkumarin
- Apache Lucene Query Example - April 8, 2024
- Google Cloud: Step by Step Tutorials for setting up Multi-cluster Ingress (MCI) - April 7, 2024
- What is Multi-cluster Ingress (MCI) - April 7, 2024
