TechEd Europe 2009: Tag 3

Windows 7 AppLocker: Configuration and Deployment

Einen guten Start in den Tag legte Paul Cooke (siehe Tag 2: Bitlocker) vor – er stellte das neue Windows 7 AppLocker als Teil eines gesamten Sicherheitskonzepts von Unternehmen dar, die weitere Sicherheitsmaßnahmen wie Anti-Virus Software, DRM, Verschlüsselung, ACLs etc. unterstützen kann. Da Schadsoftware selbst im Benutzerkontext ohne Administrationsrechte zumindest die Rechte des ausführenden Benutzers besitzt, ist dies schon ein ausreichend großes Problem; es wird wohl niemanden geben der behauptet, die Daten seines Vorstandsvorsitzenden oder beispielsweise der Personalabteilung seien nicht weiter wichtig – denn auf die kann ein Angreifer im Benutzerkontext des jeweiligen Nutzers zugreifen. Hier greift nun AppLocker hinein.

AppLocker kann in Unternehmen die Software Restriction Policies ablösen oder aber parallel betrieben werden, solange es noch Systeme “kleiner als” Windows 7 in der Umgebung gibt. Im Prinzip sollte AppLocker jedoch langfristig die SRP ablösen. Und das aus gutem Grund, schließlich sind damit genau die Probleme adressiert, die mit Software Restriction Policies immer wieder zu Tage traten: Es gibt “Allow”, “Deny” oder “Exception” Regelwerke, wobei als Best Practice ganz klar ein Regelwerk aus “Allow” plus “Exceptions” angewendet werden sollte. Whitelisting macht mehr Sinn als das Blacklisting, denn alles zu verbieten, was man nicht möchte, kann in 10 Minuten schon wieder von der Realität “da draußen” überholt worden sein.

Wie auch mit den SRP bietet AppLocker Publisher-, Hash- und Pfad-Regeln – nur sind diese bei weitem Flexibler als die SRPs. So können zusätzliche Attribute festgelegt werden, wie etwa Dateiversion (auch mit größer / gleich Operatoren), Dateiname o.ä., auch wenn eine Publisher-Regel zum Einsatz kommt. Außerdem gibt es “Rule Targets”, d.h. man kann Regeln auf Benutzer oder Gruppen anwenden. Ein Segen für alle Administratoren, die bisher auf den Zielsystemen keine Rechte hatten, obwohl sie Administratoren waren. Auch Ausnahmen lassen sich so gewährleisten, etwa alle Benutzer dürfen Applikation XY nicht benutzen, außer der Personalabteilung.

Zusätzlich kamen weitere “Rule Types” dazu, es können nun neben den bekannten “*.exe” Regeln auch Scripte, Installer oder sogar DLLs gefiltert werden. Aber Vorsicht – DLL-Einschränkungen können das System extrem verlangsamen, so daß dies nicht im Regelfall eingesetzt werden sollte. Weiterhin sollte man darauf achten, einige Standardregeln beizubehalten – denn ohne bestimmte Standardregeln, läßt sich das System auch vollkommen lahmlegen – denn ohne das Zulassen von Betriebssystem-relevanten Dateien, kann keine Benutzeranmeldung mehr erfolgen etc. Hier also der Hinweis, das ganze (wie auch sonst bei anderen Themen) in seiner Testumgebung ausgiebig zu testen.

Es gibt einen Testmodus, indem alle Software, die auf dem System läuft, bei Aufruf ins Eventlog geschrieben wird. So kann man komfortabel eine Basislinie der Applikationen erstellen, die man zulassen müßte / sollte, wenn man Probleme verhindern möchte. Die Dokumentation steht also vor allen weiteren maßnahmen. Da sich selbst APP-V Applikationen filtern lassen, ist dieses Logging wirklich Gold wert.

Was das ganze jedoch noch viel interessanter macht ist die Möglichkeit, aus diesen Eventlog Einträgen per PowerShell CMDlets automatisch Regeln zu erzeugen, zu exportieren oder zu importieren. Dadurch lassen sich Prozesse im Prinzip komplett automatisieren.

CLI322_Cooke[1] 

Alles in allem noch einmal der eindringliche Hinweis, das Design, die Ausnahmen, die Anordnung, das Testen wirklich sehr ausführlich durchzuführen – alles andere führt fast zwangsläufig zu größeren Problemen. Mit AppLocker kann man dann jedoch die Gesamtsicherheit seiner Umgebung stark anheben – sofern man die Pflege der Regeln dann nicht vernachlässigt.

Einen kleinen mit Screenshots hinterlegten Überblick zu AppLocker findet man auch hier.

BranchCache Deep Dive: An IT Administrator's Primer

Ravi Rao lieferte die nächste Session auf meinem Plan.

PB110001[1]

Die Problemstellung, die der Branch Cache in Windows 7 und Windows Server 2008 R2 adressiert, lautet unter anderem: Verbindungen von Außenstellen mit geringer Bandbreite und hoher Latenzen wirken sich nicht nur auf die Kosten für die Leitung selbst aus, sondern auch auf die Produktivität der Mitarbeiter. Da in einer globalisierten Welt, in der wir heute leben, immer mehr Zweigstellen angebunden werden, ist dies ein nicht zu unterschätzender Kostenfaktor.

Der Branch Cache stellt zwei Modi zur Verfügung: Einmal einen “distributed cache”, bei dem in einem peer-to-peer Netzwerk Clients untereinander Daten austauschen, und einmal einen “hosted cache”, bei dem ein beliebiger Server in der Zweigstelle diese Aufgabe übernimmt. Es werden in beiden Fällen nur diejenigen Daten geladen, die von einem Client der Zweigstelle angefordert wurden – danach kann diese Datei durch andere Clients direkt lokal in der Außenstelle geladen werden. Das ganze passiert “Protokolltransparent” auf W7 und 2008 R2, d.h. es funktioniert für Protokolle wie SMB, HTTP, FTP o.ä.

So kann etwa SCCM den Branch Cache nutzen, um Software oder Applikationen zu verteilen, die nur einmal aus der Hub-Site heruntergeladen wurden, gleiches gilt für WSUS. SharePoint und generell der IIS kann davon profitieren (HTTP / HTTPS), Dateiserver (SMB) oder auch APP-V Applikations-Streaming. Dritthersteller können die Technik lizenzieren, so daß hier ggf. ebenfalls neue Features denkbar sind.

Technisch wird das ganze über Hashes geregelt, die vor einem Herunterladen der Datei ausgetauscht und über Broadcasts bzw. Multicasts in der Site / dem Link des anfragenden Clients abgefragt werden. Das ganze Prinzip der Aufteilung in Daten-Chunks / Blöcke, geschieht nach dem gleichen Muster wie bei DFSR. Ich vermute also, daß die Clientfunktionalität der “Remote Differential Compression” vom Branch Cache genutzt wird, habe es mir jedoch noch nicht genauer angeschaut. Um das Feature nutzen zu können, muß es auf den entsprechend vorgesehenen Clients und Server installiert worden sein. Da zwischen Branch Cache und Datenzugriff die Applikation selbst steht, die die Authentifizierung und Authorisierung regelt, ist der Branch Cache kein “Sicherheitsrisiko”. Es geht um den reinen Abruf der Daten nach diesen Prozessen, der Transport erfolgt hierbei verschlüsselt.

Das Feature läßt sich per GPO oder NETSH Kommandozeile aktivieren und auch “steuern”. Zur Überwachung stehen SCOM Management Packs, ein eigener Eventlog Channel, Performance Counter und auch NETSH zur Verfügung. Obwohl der Zugriff auf die Daten natürlich geschützt ist, sollte man in Zweigestellen über den Schutz der Branch Cache hostenden Systeme (Clients oder Server, je nach Modus) nachdenken. Entweder auf Festplattenbasis (Bitlocker) oder auf Dateibasis (EFS).

Die DEMOs waren wirklich interessant und vielversprechend, das Thema ist es wert, einen genauen Blick darauf zu werfen (wie die anderen Themen natürlich auch ;-) …).

Zusätzliche Ressourcen zum Thema findet sich hier: https://technet.microsoft.com/en-us/network/dd425028.aspx

Security Best Practices for Hyper-V and Server Virtualisation

Der Titel der Session von Jeff Woolsey lies mich eigentlich andere Themen erwarten, aber insgesamt war die Session sehr breit gefächert – was mir als “nicht Hyper-V Experten” natürlich sehr zuträglich war. ;-)

PB110002[1]

Es ging unter anderem um Sicherheitsaspekte der Trennung zwischen der “Parent Partition” und den “Child-Partitionen”; sobald die Hyper-V Rolle installiert wurde und der Reboot stattgefunden hat, ist das “installierte System” die Parent Partition, sie läuft also schon “virtuell”. Die Parent Partition vertraut den Gästen natürlich nicht – nur so kann verhindert werden, daß über interne Schnittstellen Schadcode in die Parent-Partition geschleust wird. Außerdem müssen die normalen Netzwerkfunktionen zum Datenaustausch genutzt werden, es gibt keine Möglichkeiten der Interaktion wie in Virtual PC.

Zur Delegierung von Benutzerrechten auf die VMs (also etwa die Berechtigung eine konkrete VM neu zu starten oder aber Konfigurationsänderungen durchzuführen), wird der Authorization Manager (AzMan) verwendet. Der Schutz vor physischem Zugriff (etwa in Zweigstellen) kann durch Bitlocker gewährleistet werden; Bitlocker schützt neben den Daten der HDD auch den Bootcode. Am Thema Bitlocker kommt man scheinbar bei kaum einem Bereich mehr vorbei. ;-)

AV-Applikationen können neben der Installation eines Agents in der VM selbst auch offline VHDs scannen – ein Beispiel hierfür wäre etwa McAfee; der Hersteller bietet ein solches Modul in seiner Produktpalette an. Es ist somit möglich den Inhalt einer VHD zu prüfen, ohne die Maschine zu starten. Auf dem Hostsystem sollten vom AV-Scanner die Dateien “vmms.exe”, "vmwp.exe" und “vmswp.exe” ausgenommen werden, da sonst die Performance des Hyper-V Systems stark sinken kann.

Nach diesen Themenbereichen wurden einige Hinweise zur Verwendung von dynamischen VHDs, fixed VHDs und Differenz-VHDs und deren Performance gegeben: Die Botschaft ist eindeutig – in Windows Server 2008 R2 haben massive Performanceschübe stattgefunden, die die VHDs fast mit “RAW-Disks” gleichziehen lassen, wobei die “fixed disk” immer noch am besten abschneidet (fast 100% so schnell wie RAW disks") und expandierende (dynamische) VHDs zwischen 10% – 15% Performanceinbußen hervorrufen können. Hier muß man also abwegen: Reservierter Speicherplatz gegen Leistungsfähigkeit. 10% klingt nicht viel, kann jedoch bei stark ausgelasteten Systemen eine echte Hausnummer sein.

SVR307_Woolsey[1]

Bei dem Thema Auslastung: https://www.microsoft.com wird auf Hyper-V Maschinen gehostet – bei ca. 1,2 Milliarden Zugriffen pro Monat zeigen wir also einmal mehr selbst großes Vertrauen in das Produkt. :-)

In Bezug auf die Perfomance spielen natürlich eine Menge Faktoren eine Rolle – man sollte etwa die NIC-Ausstattung gut planen und für das Management des Hosts, ggf. iSCSI Verbindungen etc. jeweils eine NIC zur Verfügung stellen. Je nach Auslastung der VMs kann dann eine oder mehrere NICs pro VM oder aber “shared physical” NICs verwendet werden. Hier muß gut geplant sein, was über die Leitung geht. HDD-Performance (wie viele Spindeln hat das RAID-Set etc.), ausreichend RAM und CPU-Power setze ich hier einfach einmal voraus. Die Flaschenhälse rechtzeitig zu identifizieren spart eine Menge Geld, denn hier sollte man die Konfiguration prüfen anstatt gleich neue Hardware zu bestellen, die ja nicht nur in der Anschaffung Geld kostet, sondern auch im Betrieb.

In Bezug auf die Performance kamen auch noch weitere Hinweise, so zum Beispiel der Tipp, ISOs einzubinden anstatt CD / DVD Laufwerke des Hosts zu nutzen, falls möglich und getestet Jumbo Frames einzusetzen (hier muß die gesamte Netzwerkinfrastruktur mitspielen, also Router, Switches, Netzwerkkartentreiber etc.), für Windows Server 2003 Systeme 2-Wege Multiprozessor Systeme als Gast zu nutzen und – wer hätte das gedacht – in den VMs den Screensaver zu deaktivieren, denn sonst geht beim VGA Treiber eine Menge Rechenzeit für das Rendering des Bildschirmschoners drauf.

Zum Schluß war ich angenehm von dem Angebot überrascht, eine wirklich kostengünstige “Workgroup Edition” des SCVMM erwerben zu können: die System Center Virtual Machine Manager Workgroup Edition, womit bis zu 5 Hosts (unbegrenzt Gäste) verwaltet werden können – da der Windows Hyper-V Server 2008 R2 ja kostenfrei ist, läßt sich so also für wirklich wenig Geld (Preis / Leistung) eine kleine Hyper-V Struktur komplett verwaltet aufbauen. Wer den kostenfreien Hyper-V Server herunterladen möchte, schaut am besten hier.

Neben diversen anderen Themen wurde auch Windows Server Core 2008 R2 angesprochen, der nun (glücklicherweise) ein “Admin-freundliches” Tool mitbringt, den Server zu konfigurieren: SCONFIG.exe . Dazu fällt mir nur eine Beschreibung ein: Ein Segen für uns alle. ;-)

Die Features vom Windows Server 2008 R2 Hyper-V sind hier zusammengefaßt – Kurzform: Es ist eine Menge seit Windows Server 2008 Hyper-V passiert.

Viele Grüße
Fabian