Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
TechNet Magazine > Home > Alle Ausgaben > 2009 > TechNet Magazine Oktober 2009 >  Freak von alle anschließen: AppLocker: ’S IT er...
Inhalt anzeigen:  Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
Geek of all Trades AppLocker: IT’s First Security Panacea?
Greg Shields


There’s a long-standing saying in our industry that nothing is a panacea. Defined as a “remedy for all diseases, evils or difficulties,” the oft-offered but neverrealized panacea would represent the IT solution to end all solutions.
It's conventional wisdom that no single product can ever fully offer you that one-stop fix for all your problems, no matter how hard that product's salespeople might try to convince you otherwise. Yet in exploring the new AppLocker functionality in Windows 7 and Windows Server 2008 R2, I have to wonder whether Microsoft has gotten close.
To fully understand the power of AppLocker, think about the basics of maintaining system security. Malware is a constant threat. Whether it infects your systems through an Internet browser or is pushed via a worm-style attack, it sometimes overwhelms even the best firewalls and anti-malware engines. Further, even with a layered approach to security in your environment, the combination of these tools can never be prepared for that dreaded zero-day attack.
Yet there's one common thread among virtually all pieces of malware: Its code has to be processed for it to damage your systems.
This single point raises the question for administrators: "If virtually all malware requires processing to be dangerous, could I protect myself by preventing that processing from occurring in the first place?"
The answer: Absolutely. And the solution for that problem is AppLocker.

Whitelisting Applications
AppLocker has its roots in the Group Policy technology called Software Restriction Policies (SRP), which debuted with Windows XP and Windows Server 2003. SRP introduced the concept of blacklists and whitelists in relation to disallowed and allowed executables in a Windows domain. The concept is simple:
  • With a blacklist, you, the administrator, identify the specific executables that are disallowed from executing on computers in your domain. At the time of launch, processes are verified against the blacklist before being executed. If a process is on the blacklist, execution is prevented and the user is instead presented with an error message.
  • With a whitelist, the opposite becomes true. Using a whitelist, you instead specify the processes that are allowed to run on your computers. Launched processes are verified against the whitelist before execution. Only those on the whitelist are allowed to run; those not on the whitelist are prevented from being executed.
With SRP, either of these two paradigms was possible, with the default focusing on the blacklisting of applications. Over time, however, it became obvious that the whitelisting concept could be dramatically more powerful. While whitelisting involved more work because each and every application approved to run had to be entered into the policy, it was a potent method for preventing everything else.
In effect, by leveraging SRP's whitelisting paradigm, an environment could specify which applications had been tested, verified and approved by its administrators and security policy. Everything else—including most forms of executing malware and other quasi-legitimate apps not approved by IT—would be explicitly denied execution. No processing, no malware, no infection.
But while simple in concept, SRP's technology was painful in implementation. Despite all its power, SRP was implemented by only a very few environments. Determining the exact set of acceptable applications was a painful and complex process with little automation support. Making even a small mistake in an SRP Group Policy could mean the prevention of all software execution in the domain. Too risky and too administratively complex in its configuration, SRP rarely made it onto most environments' radars.

AppLocker: More Than SRP Version 2
AppLocker's technology is intended to increase adoption levels by incorporating better management functionality. Integrated much more tightly into the Windows 7 and Windows Server 2008 R2 operating systems, AppLocker leverages SRP's concepts to create a more useable solution.
The first way in which AppLocker improves over SRP is through the addition of an Audit Only enforcement mode (see Figure 1). In this mode, configured computers and executable rules only report where violations of policies take place. By combining AppLocker's Audit only enforcement mode with an empty whitelist, it's possible to quickly identify the types of applications that are being run on computers across the domain. With audit information being deposited into each computer's AppLocker event log, details on those applications and their executables can be documented for later enforcement.
Figure 1 AppLocker in Audit only mode. (Click the image for a larger view)
A second mechanism improves rule creation through an automated wizard. Found in AppLocker's Group Policy console is a selection to Automatically Generate Rules (see Figure 2). This option launches a wizard that will scan any file structure on a reference computer, looking for executables. Any executable found in the assigned path or its subfolders can have a rule automatically generated for it. Pointing this wizard toward a reference computer with your environment's common software installed automatically generates a list of rules. That list can be used as your starting point for later customization.
Figure 2 AppLocker Automatically Generate Executable Rules Wizard (Click the image for a larger view)
AppLocker also simplifies rule generation by reducing the number of rule classes to three. They're designed to be used in combination, and you'll find that each rule class provides a different approach to limiting software execution:
  • Path Rules create a restriction based on the name or location of the executable's file. For example, a Path Rule can be created for a particular filename (sol.exe) or a combination of filename and wildcard (sol*.exe) to capture limited modifications to a filename. Wildcards can also be used in combination with file paths (%PROGRAMFILES%\Microsoft Games\*).
  • File Hash Rules are created to overcome some obvious limitations with Path Rules. Using a Path Rule, an executable can be accessed by moving it out of a managed path or by sufficiently altering its filename. Using a File Hash Rule, a cryptographic hash of a managed file is created. Basing rules off of file hashes means that they remain managed no matter where they're located on the system. While this increases the security of the overall solution, its downside becomes obvious as files change over time due to patches or updates. For that reason, using File Hash Rules requires additional due diligence as software is updated.
  • Publisher Rules require that the managed executable is digitally signed. That digital signature enables the file to be restricted based on its publisher, product name, filename and file version. A sliding scale and custom value option gives you the ability to adjust which characteristics you care about and which are optional. For example, it's possible to restrict a file based on its publisher, product name and filename while setting a wildcard for the file version (see Figure 3). The net result: Any later version updates to that file are automatically approved.
Figure 3 Creating and customizing a publisher rule. (Click the image for a larger view)
A final useful addition is the ability to create special exceptions associated with any rule class. These exceptions enable a further definition of which executables are allowed for execution, as opposed to which are prevented. For example, you may allow the execution of any executable in the %PROGRAMFILES%\Microsoft Office\* folder, but specifically prevent WINPROJ.EXE due to licensing restrictions or other reasons.
Because AppLocker settings are typically created via Group Policy, the assignment of execution-prevention rules can be focused on the computers in your environment or the individual users. Inside the Group Policy Management Editor (GPME), AppLocker settings that are defined for computers are in the location Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies. Those defined for users are in the same location under User Configuration. As such, any combination of user and computer-focused configurations can be made based on the application of Group Policy. Policy-merging is additive, meaning that Group Policy won't override or replace rules already present in a linked Group Policy Object (GPO). Rules assigned via Group Policies will apply using the same application order as traditional GPOs.
Right now, AppLocker's main limitation is related to the OS versions that will enforce its rules. At the client side, only Windows 7 Ultimate and Windows 7 Enterprise can participate in AppLocker rule enforcement. For servers, any edition of Windows Server 2008 R2 except for Windows Web Server and Windows Server Foundation will enforce AppLocker rules. While Microsoft may back-port this functionality into earlier OS versions, this feature currently adds to the list of compelling reasons for a Windows 7 upgrade. (At this writing, no information has been released about a possible back-port to earlier OS versions.)
One piece of good compatibility news: AppLocker's Group Policy foundation requires no upgrade of domain controllers (DCs) to support the distribution of its policies. Existing Windows Server 2003 and Windows Server 2008 DCs can host AppLocker policies.

A Simple Deployment of AppLocker
If AppLocker's added security sounds useful to your small environment, your next steps involve implementing the solution. Obviously, implementation won't happen until you've upgraded a sizeable percentage of your desktops and laptops to Windows 7. Operating systems prior to Windows 7 and Windows Server 2008 R2 won't apply AppLocker rules, but they will respect those applied through SRP. While SRP and AppLocker rules aren't directly convertible, the information you gather through AppLocker's Audit Only mode can be manually converted for use in SRP.
Deploying AppLocker involves multiple steps, beginning with determining how to implement the technology and creating a reference computer for isolating your starting set of applications. Remember that, unlike SRP, App­Locker defaults to the assumption that you'll be creating a whitelist of applications. While creating a blacklist architecture is possible, doing so isn't recommended simply because that approach doesn't provide the same execution-prevention power offered by whitelists.
In its document titled "Planning and Deploying Windows AppLocker Policies," Microsoft outlines a nine-step process for implementing App­Locker in an environment. While this document is in beta at this writing, the currently available version includes significant detail on how to properly build a complete AppLocker infrastructure. For simplicity's sake, however, here are a few steps that you need to get started.
First, create a list of applications that your IT organization considers acceptable for execution. You can create this list manually by interviewing application owners in your organization. Or you can begin by creating and interrogating a reference computer containing the commonly available applications in your business. Start that process by building the OS instance—or imaging it using your favorite image-deployment solution—and ensuring that the right applications are installed. Onto this computer, you should also install the Remote Systems Administration Toolkit (RSAT) for Windows 7, which can be found on the Microsoft Web site. The RSAT includes the GPME components necessary for creating AppLocker Rules.
When ready for analysis, create a new GPO and launch it within the GPME. Navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies | AppLocker and click the link in the right pane for Configure Rule Enforcement. In the resulting window, check the box marked Configured under Executable Rules and set the rule to Audit Only. This setting maintains your existing behaviors on managed systems while reporting AppLocker rule violations to the local event log.
You'll notice that this window has an Advanced tab, within which you can choose to Enable the DLL rule collection. AppLocker has the ability to create rules based on DLLs in addition to executable files. While you can implement this setting for added security, doing so will add an extra administrative burden because you'll need to isolate and configure rules for all DLLs in your environment in addition to executable files. Because an executable file can leverage multiple DLLs, that task can be a management headache. Enabling DLL rule collection also will impact system performance because the processing of each DLL will require validation prior to execution.
Your next step is configuring the default set of Executable Rules. Right-click the AppLocker sub-node of the same name and choose to Create Default Rules. Three rules are created by default. Two allow the execution of all files in the Windows and Program Files folders, while the third (shown in Figure 4) allows members of the local Administrators group to run all applications. This third rule effectively excludes local Administrators from rule processing.
Figure 4 Default rule excluding local administrators from execution prevention. (Click the image for a larger view)
Once that's complete, right-click the Executable Rules node again and choose to Automatically Generate Rules. This wizard will interrogate the local machine for potential executables for rule creation, which is why it must be run on the reference computer. By default, the wizard will check for executables in the C:\Program Files path, although alternate paths can be checked by editing them in the wizard's options.
Clicking Next in the wizard takes you to the Rule Preferences screen. Here, you have the option to create Publisher Rules for files that are digitally signed or to create Hash Rules for all files. Path Rules can be automatically created in this screen, but only when files haven't already been digitally signed by their publishers. Clicking Next again completes the system scan and takes you to a screen where you can review the list of rules. Rules that you don't wish to create can be eliminated by clicking the link to review the files that were analyzed, then deselecting the check box next to the appropriate files. Once that's complete, click Create.
Completing this task on a freshly built Windows 7 system adds four new rules. Although quite a few more executable files are found in this location, the wizard will by default group together rules to simplify their application. At this point, if you feel like monitoring for other executable types, it's possible to configure rules for scripts and Windows Installer-based executables in this same GPME location.
At this point, the GPO will begin configuring targeted clients based on OU membership. Because the rule-enforcement policy is set to Audit Only, no execution restriction will actually occur. During this period, it's a good idea to look through the event logs on various managed systems to see whether your rules are working for your environment or whether their application would prevent a necessary executable from running. Use that information to tweak your existing set of rules so that they function correctly for your environment.
When you're ready to move from reporting on executables to actually preventing them, just navigate back to the AppLocker node in the GPME and change the enforcement properties from Audit Only to Enforce Rules.
Obviously, you'll need more project planning and testing prior to deployment. But these simple steps will get you started. While AppLocker may not be the complete security panacea, its abilities to prevent all but your absolutely approved executables from running means that it comes really, really close.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields' Geek-of-All-Trades tips and tricks at ConcentratedTech.com.
Meister aller Klassen AppLocker: ’S IT erste Security Allheilmittel?
Greg Shields


Es ’s ein langjähriges Spruch in unserer Branche, dass nichts Allheilmittel ist. Laut Definition eine “ Lösung für alle Diseases, Evils oder Schwierigkeiten beim eingeben, würde das Allheilmittel oft angeboten jedoch Neverrealized IT-Lösung So beenden Sie alle Lösungen darstellen.
Es ist konventionellen Weisheit, die kein einzelnes Produkt jemals vollständig Sie, dass eine Stop-Update für alle Probleme unabhängig davon anbieten kann, wie hart Verkäufer für das Produkt möglicherweise versucht, andernfalls verleiten. In erkunden die neue AppLocker-Funktionalität in Windows 7 und Windows Server 2008 R2, muss ich noch gefragt, ob Microsoft schließen gelangt ist.
Überlegen Sie die Grundlagen der Verwaltung der Systemsicherheit, um die Leistungsfähigkeit von AppLocker vollständig zu verstehen. Malware ist eine Konstante Bedrohung. Ihre Systeme über einen Internetbrowser infiziert oder über einen Wurm-Stil Angriff abgelegt, überflutet es manchmal sogar die besten Firewalls und Antimalware-Module. Sogar mit einem mehrstufigen Ansatz zur Sicherheit in Ihrer Umgebung, kann die Kombination dieser Tools, niemals für die gefürchtete Zero-Day-Angriffe vorbereitet werden.
Es gibt noch einen gemeinsamen Thread zwischen praktisch alle Teile von Malware: Der Code hat, Ihre Systeme beschädigen verarbeitet werden.
Diese einzelnen Punkt löst die Frage für Administratoren: "Wenn praktisch alle Malware Verarbeitung gefährlich sein erfordert, konnte ich selbst schützen, indem die Verarbeitung erfolgt in erster Linie verhindern?"
Die Antwort lautet: Absolut. Und die Lösung für dieses Problem ist AppLocker.

Whitelisting Anwendungen
AppLocker hat seinen Stamm in der Gruppenrichtlinien-Technologie, Software für Sicherheitsrichtlinien (SRP), die mit Windows XP und Windows Server 2003 führte aufgerufen. SRP führte das Konzept von Blacklists und Whitelists in Bezug auf nicht erlaubt und ausführbaren Dateien in einer Windows-Domäne zulässig. Das Konzept ist einfach:
  • Mit einer Sperrliste, identifizieren Sie Administrator, die bestimmten ausführbaren Dateien, die nicht zulässig sind auf Computern in Ihrer Domäne ausführen. Zum Zeitpunkt Markteinführung werden Prozesse anhand der Sperrliste überprüft, bevor Sie ausgeführt wird. Ist ein Prozess auf der Sperrliste, Ausführung wird verhindert, und der Benutzer wird stattdessen eine Fehlermeldung angezeigt.
  • Mit einer Whitelist wird das Gegenteil true. Verwenden einer Whitelist, geben Sie stattdessen die Prozesse, die auf Ihren Computern ausführen dürfen. Gestartete Prozesse werden anhand der Positivliste vor der Ausführung überprüft. Nur die auf der Positivliste dürfen ausgeführt werden;Diese werden nicht auf der Positivliste verhindert ausgeführt.
Mit SRP war eines dieser beiden Paradigmen möglich, mit dem Schwerpunkt auf das Sperren von Anwendungen. Im Laufe der Zeit war es jedoch offensichtlich, dass das Konzept Whitelisting erheblich leistungsfähiger sein kann. Während Whitelisting mehr Arbeit, beteiligt da jede Anwendung genehmigt ausführen musste in der Richtlinie eingegeben werden, war es eine potent-Methode für alles andere verhindern.
Durch Nutzung des SRP Whitelisting Paradigma, könnten in eine Umgebung angeben, welche Anwendungen mussten wurde getestet, überprüft und genehmigt von den Administratoren und Sicherheitsrichtlinien. Alles andere – einschließlich der Ausführung von Malware und anderen quasi-legitimate Anwendungen, die nicht genehmigt durch die meisten Formulare IT, würde die Ausführung explizit verweigert werden. Keine Verarbeitung, keine Malware, keine Infektion.
Aber beim einfachen Konzept des SRP-Technologie in Implementierung mühsam war. Trotz seiner Leistungsfähigkeit SRP wurde implementiert, indem nur eine sehr wenigen Umgebungen. Bestimmen den genauen Satz von zulässigen Anwendungen war ein mühsam und komplexen Prozess mit wenig Automatisierungsunterstützung. Sogar einen kleinen Fehler in einer Gruppenrichtlinie SRP vornehmen könnte die Vermeidung von alle Software die Ausführung in der Domäne bedeuten. Zu riskant und in seiner Konfiguration SRP selten administrativ zu komplex war es auf den meisten UmgebungenRadars.

AppLocker: Mehr als SRP Version 2
Der AppLocker Technologie soll Akzeptanz Ebenen durch die Integration bessere Verwaltungsfunktionen zu erhöhen. Viel enger in den Betriebssystemen Windows 7 und Windows Server 2008 R2 integriert, nutzt die AppLocker des SRP Konzepte zum Erstellen einer mehr verwendet werden-Lösung.
Die erste Möglichkeit, die in der AppLocker über SRP verbessert durch das Hinzufügen einer Überwachung Erzwingung Modus ist (siehe Abbildung 1). In diesem Modus Regeln konfigurierten Computern und ausführbare Datei nur Bericht stattfinden, in denen Verletzungen von Richtlinien. Durch Kombinieren des AppLocker nur Erzwingung Überwachungsmodus mit einer leeren Whitelist, ist es möglich, schnell die Typen von Anwendungen identifizieren, die auf Computern in der Domäne ausgeführt werden. Mit Überwachungsinformationen in AppLocker-Ereignisprotokoll des Computers abgelegt werden können Details zu diesen Anwendungen und Ihre ausführbaren Dateien höher Erzwingung dokumentiert werden.
Abbildung 1 AppLocker im Überwachungsmodus nur. (Zum Vergrößern auf das Bild klicken)
Ein zweiter Mechanismus verbessert Regelerstellung durch einen automatisierten Assistenten. In Gruppenrichtlinien des AppLocker gefunden Konsole ist eine Auswahl zu Regeln automatisch generieren (siehe Abbildung 2). Diese Option wird ein Assistent, die alle Dateistruktur auf einem Referenzcomputer Scannen wird nach ausführbaren Dateien gestartet. Jede ausführbare Datei in den zugeordneten Pfad oder seinen Unterordnern gefunden haben eine Regel automatisch für Sie generiert. Zeigen mit diesem Assistenten auf einem Referenzcomputer mit Ihrer Umgebung häufig Software, die automatisch installiert, erzeugt eine Liste von Regeln. Die Liste kann als Ausgangspunkt für die spätere Anpassung verwendet werden.
Abbildung 2 AppLocker automatisch generieren ausführbare Regelassistent (auf das Bild für eine größere Ansicht klicken.)
AppLocker vereinfacht auch die Generierung von Regel durch Verringern der Anzahl der Regel Klassen auf drei. Sie sind dafür vorgesehen, in Kombination verwendet werden, und Sie werden feststellen, dass jede Regelklasse einen anderen Ansatz zum Einschränken von Software Ausführung bereitstellt:
  • Pfad Regel erstellen Sie eine Einschränkung basierend auf dem Namen oder Speicherort der ausführbaren Datei. Beispielsweise können eine Pfadregel für einen bestimmten Dateinamen ("sol.exe") oder eine Kombination von Dateinamen und Platzhalter (sol*.exe) zum Erfassen von begrenzter Änderungen an einem Dateinamen erstellt werden. Platzhalter können auch in Kombination mit Dateipfade (%ProgramFiles%\Microsoft Games\ 1) verwendet werden.
  • Datei Hash Regeln werden erstellt, um einige offensichtlichen Einschränkungen mit Pfadregeln zu überwinden. Verwenden eine Pfadregel, kann eine ausführbare Datei durch Verschieben von es außerhalb des verwalteten Pfad oder durch ausreichend ändern den Dateinamen zugegriffen werden. Mithilfe einer Hashregel Datei wird kryptografischer Hash einer verwalteten Datei erstellt. Formularvorlage Regeln aus der Datei hasht bedeutet, die bleiben, unabhängig davon, wo sich diese auf dem System befinden, sind verwaltete. Während dies die Sicherheit der Gesamtlösung erhöht, wird seine Nachteil offensichtlich, wie Dateien mit der Zeit aufgrund von Patches oder Updates ändern. Aus diesem Grund verwenden Datei Hash Regeln erfordert zusätzliche aufgrund Sorgfalt wie Software wird aktualisiert.
  • Publisher Regeln erfordern, dass die verwaltete ausführbare Datei digital signiert ist. Die digitale Signatur ermöglicht die Datei, eingeschränkt werden, basierend auf seiner Publisher, Produktname, Filename und Datei-Version. Eine gleitende Skalierung und benutzerdefinierten Wert Option bietet, sind Sie die Möglichkeit, welche Merkmale anpassen, die Sie interessieren und die optional. Es ist beispielsweise möglich, eine Datei beim Festlegen des eines Platzhalters für die Dateiversion auf seine Verleger, Produktnamen und Dateiname Grundlage einschränken (siehe Abbildung 3). Das Ergebnis: Höheren Version Aktualisierungen für die Datei werden automatisch genehmigt.
Abbildung 3 erstellen und Anpassen einer Publisher-Regel. (Zum Vergrößern auf das Bild klicken)
Eine endgültige nützliche Ergänzung ist die Fähigkeit spezielle jeder Regel-Klasse zugeordnete Ausnahmen erstellen. Diese Ausnahmen ermöglichen eine weitere Definition der ausführbaren Dateien zulässig sind, für die Ausführung im Gegensatz zu dem daran gehindert werden. Z. B. möglicherweise ermöglichen alle ausführbaren Datei im Ordner "%Programme%\Microsoft Office\ 1", aber insbesondere WINPROJ.EXE aufgrund auf Lizenzierung, Einschränkungen oder aus anderen Gründen verhindern.
Da AppLocker Einstellungen in der Regel über die Gruppenrichtlinie erstellt werden, kann die Zuweisung der Datenausführungsverhinderung Execution Prevention Regeln auf den Computern in Ihrer Umgebung oder der einzelne Benutzer konzentriert. In GPME (der Richtlinie Management-Editor), AppLocker, die für Computer definiert sind Einstellungen im Ordner Computerkonfiguration | Richtlinien | Windows-Einstellungen | Sicherheitseinstellungen | der Anwendungsrichtlinien. Definiert für Benutzer sind am selben Speicherort unter Benutzerkonfiguration. Als solche kann eine beliebige Kombination Benutzer und Computer ausgerichteten Konfigurationen basierend auf der Anwendung von Gruppenrichtlinien vorgenommen werden. Richtlinie-das Zusammenführen ist additiv, Bedeutung, die Gruppenrichtlinie außer Kraft setzen wird nicht oder ersetzen-Regeln in einer verknüpften Gruppenrichtlinienobjekt (GPO) bereits vorhanden. Regeln über Gruppenrichtlinien zugewiesen werden herkömmliche Gruppenrichtlinienobjekte unter die gleichen Anwendung Reihenfolge angewendet.
Jetzt, des AppLocker main Einschränkung bezieht sich auf Betriebssystemversionen, die Ihre Regeln erzwungen werden. Auf dem Client können nur von Windows 7 Ultimate und Windows 7 Enterprise AppLocker Regel erzwingen teilnehmen. Für Server wird eine beliebige Edition von Windows Server 2008 R2 mit Ausnahme von Windows Web Server und Windows Server Foundation AppLocker Regeln erzwungen. Während Microsoft diese Funktionalität in früheren Betriebssystemversionen Back-Port kann, fügt dieses Feature derzeit die Liste der überzeugende Gründe für eine Aktualisierung von Windows 7 hinzu. (Zur Erstellung dieses Dokuments wurde keine Informationen über mögliche Back-Anschluss für frühere Betriebssystemversionen veröffentlicht.)
Ein Teil der gute Kompatibilität News: AppLocker des Gruppenrichtlinien-Foundation erfordert keine Aktualisierung von Domänencontrollern (DCs) um die Verteilung von dessen Richtlinien zu unterstützen. Vorhandene Windows Server 2003 und Windows Server 2008-DCs können Host AppLocker Richtlinien.

Eine einfache Bereitstellung von AppLocker
Wenn des AppLocker Sicherheit Sounds hilfreich, Ihre kleine Umgebung hinzugefügt haben, beinhalten die nächsten Schritte Implementierung der Lösung. Implementierung wird nicht natürlich passieren, bis Sie einen anpassbaren Anteil Ihrer Desktops und Laptops zu Windows 7 aktualisiert haben. Betriebssystemen vor Windows 7 und Windows Server 2008 R2 wird nicht AppLocker Regeln anwenden, aber Sie werden über SRP angewendeten berücksichtigen. Während Regeln SRP und AppLocker nicht direkt konvertiert werden, kann die Informationen über AppLocker des überwachen Modus manuell für die Verwendung in SRP konvertiert werden.
Bereitstellen von AppLocker umfasst mehrere Schritte, beginnend mit bestimmen zum Implementieren der Technologie und erstellen einen Referenzcomputer für Ihre ersten Satz von Anwendungen zu isolieren. Denken Sie daran, dass im Gegensatz zu SRP, Anwendung ­ Locker zu der Annahme standardmäßig, dass Sie einer Whitelist Anwendungen erstellen möchten. Zwar möglich, erstellen eine Sperrliste Architektur dadurch einfach empfohlen wird nicht da diesen Ansatz die gleichen Ausführung Vorbeugung Leistungsfähigkeit von Whitelists angeboten bieten nicht.
In das Dokument mit dem Titel "planen und Bereitstellen von Windows AppLocker Richtlinien"Microsoft stellt eine neun-Schritt-Prozess zum Implementieren von Anwendungen ­ Locker in einer Umgebung. Während der Beta bei diesem Dokument wird, enthält die derzeit verfügbare Version wichtige Details zum ordnungsgemäß eine vollständige AppLocker-Infrastruktur erstellen. Der Einfachheit sind hier jedoch einige Schritte, die Sie beginnen müssen.
Erstellen Sie zunächst eine Liste der Anwendungen, die Ihr Unternehmen für die Ausführung zulässig betrachtet. Sie können diese Liste manuell erstellen, durch die Befragung Anwendungsbesitzer in Ihrer Organisation. Oder Sie können durch Erstellen und Befragen eines Referenzcomputers mit den Allgemein verfügbaren Anwendungen in Ihrem Unternehmen beginnen. Starten, indem BS-Instanz erstellen – oder mit das bevorzugte Bild imaging-Bereitstellung-Lösung – und sicherstellen, dass die richtigen Anwendungen installiert werden. Auf diesen Computer sollten Sie auch Remote Systems Administration Toolkit (RSAT) für Windows 7 Installieren der auf der Microsoft-Website. Die RSAT enthält die GPME-Komponenten zum Erstellen von AppLocker Regeln erforderlich.
Wenn für die Analyse bereit, erstellen Sie ein neues GRUPPENRICHTLINIENOBJEKT und innerhalb des GPME zu starten. Navigieren Sie zu Computerkonfiguration | Richtlinien | Windows-Einstellungen | Sicherheitseinstellungen | der Anwendungsrichtlinien | AppLocker und klicken Sie auf den Link im rechten Fensterbereich für die Regel erzwingen konfigurieren. Kontrollkästchen Sie im Fenster resultierenden die markiert konfiguriert unter Regeln zum Ausführen und die Regel auf nur Überwachung festgelegt. Diese Einstellung gewährleistet, dass Ihre vorhandenen Verhaltensweisen auf verwalteten Systemen AppLocker Regelverletzungen in das lokale Ereignisprotokoll reporting.
Sie werden bemerken, dass dieses Fenster eine Registerkarte Erweitert hat, in der Sie wählen können die DLL-Regelsammlung aktivieren Sie. AppLocker hat die Möglichkeit, Regeln basierend auf DLLs zusätzlich zu ausführbaren Dateien zu erstellen. Während Sie diese Einstellung für zusätzliche Sicherheit implementieren können, wird dadurch ein zusätzlicher Verwaltungsaufwand hinzugefügt, da Sie isolieren und Konfigurieren von Regeln für alle DLLs in Ihrer Umgebung zusätzlich zu ausführbaren Dateien müssen. Da eine ausführbare Datei mehrere DLLs nutzen kann, kann die Aufgabe eine Verwaltung Kopfschmerzen sein. Aktivieren DLL-Regel Auflistung auch Systemleistung beeinträchtigt, da die Verarbeitung von jeder einzelnen DLL Validierung vor Ausführung erforderlich wird.
Ihre nächste Schritt ist den Standardsatz von Regeln ausführen konfigurieren. Klicken Sie mit der rechten Maustaste die Unterknoten AppLocker mit dem gleichen Namen und wählen Sie zum Erstellen von Standard-Regeln. Drei Regeln sind standardmäßig erstellt. Zwei ermöglichen die Ausführung aller Dateien in den Ordnern Windows und Programme, während das dritte (dargestellt in Abbildung 4) Mitglieder der lokalen Gruppe Administratoren zum Ausführen aller Anwendungen ermöglicht. Dieser dritte Regel schließt lokale Administratoren effektiv von Regelverarbeitung.
Abbildung 4 Standard-Regel ausschließen lokale Administratoren aus Ausführung verhindern. (Zum Vergrößern auf das Bild klicken)
Sobald dies abgeschlossen ist, klicken Sie erneut mit der rechten Maustaste auf den Knoten ausführen Regeln, und wählen zu Regeln automatisch generieren. Mit diesem Assistenten wird den lokalen Computer für potenzielle ausführbaren Dateien für die Regelerstellung, Abfragen, weshalb es auf dem Referenzcomputer ausgeführt werden muss. Standardmäßig wird der Assistent für ausführbare Dateien im Pfad C:\Programme überprüft, obwohl alternativen Pfade überprüft werden, indem Sie in den Optionen des Assistenten.
Auf Weiter im Assistenten gelangen Sie zu der Regel Einstellungen Bildschirm. Hier haben Sie die Option Publisher-Regeln für Dateien erstellen, die digital signiert sind oder Hash-Regeln für alle Dateien zu erstellen. Pfad Regeln können in diesem Bildschirm, jedoch nur, wenn Dateien bereits digital Ihre Herausgeber signiert wurde noch nicht automatisch erstellt werden. Klicken Sie auf Weiter erneut führt das System durchsucht und Sie gelangen zu einem Bildschirm, in dem Sie die Liste der Regeln überprüfen. Regeln, die Sie erstellen möchten können entfernt werden, indem Sie auf die Verknüpfung zu die Dateien zu überprüfen, die analysiert wurden und anschließend das Kontrollkästchen neben den entsprechenden Dateien deaktivieren. Sobald dies abgeschlossen ist, klicken Sie auf erstellen.
Diese Aufgabe auf einem neu erstellten Windows 7-System fügt vier neue Regeln. Obwohl ein paar weitere ausführbaren Dateien an diesem Speicherort gefunden werden, führt der Assistent durch standardmäßige Gruppe zusammen Regeln um Ihre Anwendung zu vereinfachen. Wenn Sie wie andere ausführbaren Dateitypen überwachen, ist es an dieser Stelle zum Konfigurieren von Regeln für Skripts und Windows Installer-basierten ausführbaren Dateien in dieser gleichen GPME Speicherort möglich.
Zu diesem Zeitpunkt beginnt das GRUPPENRICHTLINIENOBJEKT gezielte Clients basierend auf OU-Mitgliedschaft konfigurieren. Da die Richtlinie erzwingen der Regel auf Überwachung festgelegt ist, wird keine Einschränkung Ausführung tatsächlich auftreten. Während dieses Zeitraums ist es ratsam, Suchen über die Ereignisprotokolle auf verschiedenen verwaltete Systeme, um festzustellen, ob die Regeln für Ihre Umgebung arbeiten oder, ob Ihre Anwendung eine erforderliche ausführbare Datei Ausführung verhindern würde. Verwenden Sie die Informationen, um Ihre vorhandenen Satz von Regeln zu optimieren, so dass Sie für Ihre Umgebung ordnungsgemäß.
Wenn Sie bereit, Verschieben von Melden von ausführbaren Dateien tatsächlich zu verhindern sind, klicken Sie einfach wechseln Sie zurück zum Knoten AppLocker in der GPME, und ändern Sie die Erzwingung-Eigenschaften von Überwachung nur auf Regeln erzwingen.
Natürlich benötigen Sie weitere Projekt planen und Testen von prior to Bereitstellung. Doch diese einfachen Schritte werden Ihnen den Einstieg. AppLocker ist möglicherweise nicht die vollständige Sicherheit Allheilmittel seine Fähigkeiten, damit alle jedoch bedeutet, dass Ihre absolut genehmigten ausführbare Dateien ausgeführt wird, kommt es wirklich, wirklich schließen.

Greg Shields, MVP, ist ein Partner am Concentrated Technology. Erhalten Sie weitere ShieldsFreak von alle Geschäfte Tipps und Tricks ConcentratedTech.com.
Page view tracker