Windows Vista Security

Zehner Windows Vista Security

Marcel Zehner

Windows Vista Security

Der Autor: Marcel Zehner, smart dynamic ag, Bern

Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

© 2007 Carl Hanser Verlag München Gesamtlektorat: Fernando Schneider Sprachlektorat: Sandra Gottmann, Münster-Nienberge Herstellung: Monika Kraus Umschlagdesign: Marc Müller-Bremer, Rebranding, München Umschlaggestaltung: MCP · Susanne Kraus GbR, Holzkirchen Datenbelichtung, Druck und Bindung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent-Nr. 0748702 Printed in Germany ISBN 978-3-446-41356-6 www.hanser.de/computer

Inhalt Einleitung............................................................................................................................. 1 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

Benutzerkontensteuerung....................................................................................... 5 Lokales Administratorenkonto – deaktiviert!...........................................................................6 Standardbenutzerrechte – ein entscheidender Vorteil! .............................................................8 Verwaltung von Windows Vista – Rechteerhöhung bei Bedarf!..............................................9 Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung! .......13 Steuerung mittels Gruppenrichtlinien.....................................................................................21 Deaktivieren der Benutzerkontensteuerung............................................................................27 Für Entwickler........................................................................................................................29 Rückblick ...............................................................................................................................29

2 2.1 2.2 2.3 2.4 2.5 2.6

Integritätskontrolle mit Verbindlichkeitsstufen................................................... 31 Der neue Schutzmechanismus von Windows Vista ...............................................................31 Verfügbare Verbindlichkeitsstufen und Richtlinien ...............................................................32 Verbindlichkeitsstufen für Objekte ........................................................................................33 Verbindlichkeitsstufen für Prozesse .......................................................................................38 Verbindlichkeitsstufen von Benutzerkonten ..........................................................................40 Rückblick ...............................................................................................................................42

3 3.1

Internet Explorer 7 ................................................................................................. 43 Umfassender Schutz durch mehrere Sicherheitsschichten .....................................................43 3.1.1 Schutzschicht 1 – Adressleistensicherheit und IDN-Unterstützung..........................44 3.1.2 Schutzschicht 2 – Sicherheitsstatusanzeige, Zertifikatsverwaltung und Phishing-Filter ..........................................................................................................45 3.1.3 Schutzschicht 3 – Warnung bei unsicheren Einstellungen........................................52 3.1.4 Schutzschicht 4 – Reduzierte Angriffsoberfläche.....................................................54 3.1.5 Schutzschicht 5 – ActiveX Opt-In............................................................................54 3.1.6 Schutzschicht 6 – Dateiausführungsverhinderung (Data Execution Prevention, DEP) ..........................................................................55 3.1.7 Schutzschicht 7 – Geschützter Modus......................................................................56

V

Inhalt

3.2

3.3 3.4 3.5 4 4.1

4.2

4.3

4.4 5 5.1 5.2

5.3 6 6.1

VI

3.1.8 Webseite mit IE7-Demos .........................................................................................57 Weitere Sicherheitseinstellungen ........................................................................................... 58 3.2.1 Sicherheitszonen ...................................................................................................... 58 3.2.2 Datenschutzeinstellungen......................................................................................... 61 3.2.3 Zertifikatsverwaltung ............................................................................................... 63 3.2.4 Löschen von persönlichen Informationen ................................................................65 Konfiguration über Gruppenrichtlinien.................................................................................. 65 Installation von ActiveX-Elementen steuern ......................................................................... 67 Rückblick...............................................................................................................................71 Schützen von Daten und Betriebssystemdateien............................................... 73 Das NTFS-Dateisystem ......................................................................................................... 73 4.1.1 Lokale Sicherheit auf Datei- und Ordnerebene – Jumpstart und Refresh!............... 75 4.1.2 Besitzer von Systemobjekten ................................................................................... 76 4.1.3 Umleitungen im Dateisystem ...................................................................................78 4.1.4 Verbindlichkeitsstufen – Sie erinnern sich? .............................................................80 4.1.5 Kontrolle ist gut, Überwachung ist besser................................................................81 Das verschlüsselte Dateisystem (Encrypting File System, EFS)............................................87 4.2.1 Lösungen ohne Zertifizierungsstelle ........................................................................90 4.2.2 Lösungen mit einer Windows Server-Zertifizierungsstelle ......................................98 4.2.3 Steuerung über Gruppenrichtlinien ........................................................................ 112 4.2.4 Noch etwas zum Abschluss von EFS .....................................................................116 Partitionsverschlüsselung mit BitLocker.............................................................................. 116 4.3.1 BitLocker einrichten............................................................................................... 120 4.3.2 BitLocker über die Kommandozeile verwalten ...................................................... 126 4.3.3 Wiederherstellung .................................................................................................. 127 4.3.4 Schlüsselspeicherung im Active Directory............................................................. 128 4.3.5 Gruppenrichtlinien für BitLocker-Konfiguration ...................................................132 Rückblick............................................................................................................................. 136 Update-Management ........................................................................................... 137 Automatische Updates über Microsoft Update .................................................................... 138 Windows Server Update Services (WSUS) .........................................................................142 5.2.1 Installation von WSUS...........................................................................................142 5.2.2 WSUS-Basiskonfiguration .....................................................................................147 5.2.3 Computergruppen................................................................................................... 154 5.2.4 WSUS-Clients konfigurieren ................................................................................. 155 5.2.5 WSUS-Clients registrieren ..................................................................................... 159 5.2.6 Updates verwalten .................................................................................................. 159 Rückblick............................................................................................................................. 161 Sicherer Netzwerkbetrieb.................................................................................... 163 Netzwerkverbindungen ........................................................................................................ 163 6.1.1 LAN-Verbindungen ...............................................................................................165 6.1.2 WLAN-Verbindungen............................................................................................ 170 6.1.3 Virtuelle private Netzwerke (VPN)........................................................................ 180

Inhalt 6.2

6.3 6.4 7 7.1 7.2 7.3 7.4 7.5

Die Windows-Firewall .........................................................................................................183 6.2.1 Netzwerktypen für Netzwerke festlegen.................................................................186 6.2.2 Die Standardkonsole der Windows-Firewall ..........................................................188 6.2.3 Die erweiterte Konsole der Windows-Firewall ......................................................191 6.2.4 Firewall-Konfiguration mithilfe von Gruppenrichtlinien .......................................205 IPsec ohne Firewall..............................................................................................................205 6.3.1 IPsec-Konfiguration über Gruppenrichtlinien ........................................................210 Rückblick .............................................................................................................................211

7.6 7.7 7.8

Erweiterter Schutz vor Malware und Viren ........................................................ 213 Automatische Updates .........................................................................................................217 Echtzeitschutz zum Erkennen neuer unerwünschter Programme .........................................218 Manuelle Scans zum Suchen nach bereits installierten Spyware-Programmen....................219 Verlauf .................................................................................................................................220 Extras ...................................................................................................................................221 7.5.1 Optionen .................................................................................................................222 7.5.2 Microsoft SpyNet ...................................................................................................224 7.5.3 Unter Quarantäne ...................................................................................................226 7.5.4 Software-Explorer ..................................................................................................227 Informationen in der Ereignisanzeige ..................................................................................228 Konfiguration über Gruppenrichtlinien ................................................................................229 Rückblick .............................................................................................................................232

8 8.1 8.2 8.3 8.4 8.5 8.6

Windows-Dienste absichern ............................................................................... 233 Dienst- und Systemkonten ...................................................................................................233 Viele Dienste standardmäßig nicht ausgeführt .....................................................................237 Dienste werden mit tiefstmöglichen Rechten und isoliert ausgeführt ..................................237 Dienste können für den Netzwerkbetrieb eingeschränkt werden..........................................241 Isolation der „Session 0“......................................................................................................242 Rückblick .............................................................................................................................244

9 9.1 9.2 9.3

Hardware und Treiber.......................................................................................... 245 Neue Gruppenrichtlinieneinstellungen .................................................................................246 Treibersignaturen .................................................................................................................253 Rückblick .............................................................................................................................255

10 10.1

Benutzerkonten und Kennwörter ....................................................................... 257 Übersicht zur Benutzerauthentifizierung..............................................................................257 10.1.1 Kennwortspeicherung.............................................................................................258 10.1.2 Übertragung über das Netzwerk .............................................................................259 Schutz der lokalen Benutzerdatenbank von Windows Vista ................................................264 Kennwortrichtlinien und Kontosperrung..............................................................................265 Dienstkonten ........................................................................................................................271 Ausbildung, Ausbildung, Ausbildung ..................................................................................271 Rückblick .............................................................................................................................272

10.2 10.3 10.4 10.5 10.6

VII

Inhalt 11 11.1 11.2 11.3 11.4 11.5 11.6

Verschiedene Sicherheitseinstellungen ............................................................ 273 Kernel Patch Protection (PatchGuard) ................................................................................. 273 Code-Integrität..................................................................................................................... 274 Address Space Layout Randomization (ASLR)...................................................................275 Remotedesktopverbindungen............................................................................................... 276 Software Restriction Policies ............................................................................................... 279 Rückblick............................................................................................................................. 285

Register............................................................................................................................ 287

VIII

Einleitung Sicherheit, Sicherheit, Sicherheit. Überall in der Welt der Informationstechnologie geht es nur noch um dieses eine Thema. Nur noch? Natürlich nicht, aber Sicherheit ist mittlerweile zum „Top Concern“, also zum Thema Nummer eins, vieler Firmen geworden. In einer vernetzten Welt, in der jeder mit jedem kommunizieren kann, alle erdenklichen Informationen in öffentlichen Netzwerken abgerufen werden können und Firmennetzwerke von jedem Punkt dieser Welt aus zugänglich sind, existiert auch eine Reihe von Risiken. Und diese Risiken sind enorm. Ereignisse wie beispielsweise das Täuschen von Benutzern, der Zugriff auf fremde Informationen oder das Außerkraftsetzen von Diensten gehören leider mittlerweile zur Tagesordnung. Unter dem Deckmantel des Internets lässt sich leicht eine kriminelle Tat begehen, ohne dass es möglich ist, jemals herauszufinden, woher und von wem ein Angriff ausgeübt worden ist. Aber damit müssen wir lernen zu leben, und in naher Zukunft wird sich das bestimmt nicht zum Besseren ändern. Was aber kann dagegen unternommen werden? Wie kann man sich schützen, um die Angriffsfläche der eigenen Firmeninfrastruktur zu minimieren? Wie kann ich meine Firma schützen und sicher machen? Die Kurzantwort auf diese Frage lautet: Ihr Netzwerk wird niemals sicher sein – es lässt sich bestenfalls optimal schützen. Selbst wenn Sie jedes verfügbare Sicherheitstool dieser Welt installieren, wird das der Fall sein. Weshalb das denn nun wieder? Nun, Sicherheit ist komplex, vielschichtig und dynamisch. In einem Sicherheitskonzept müssen deshalb verschiedenste Bereiche, Komponenten und Prozesse eingebunden werden, die weit über die Grenzen der Informationstechnologie hinausreichen. Technische Sicherheit in der IT reicht dabei bei Weitem nicht aus. Deshalb wird das Buch, das Sie in den Händen halten (oder natürlich das PDF, das Sie lesen), auch nicht alle Bereiche abdecken können. Das soll es aber auch nicht. Es soll sich auf einen einzigen Bereich fokussieren, und das ist das Client-Betriebssystem Windows Vista. Sicherheit bei Client-Betriebssystemen Mit diesem Buch möchte ich Ihnen, liebe Leserinnen und Leser, die neuen Abwehrmechanismen, die Windows Vista bietet, ein bisschen genauer aufzeigen und erklären, wie diese in einer Firmenumgebung eingesetzt werden können, um die Gesamtsicherheit der ITLandschaft entscheidend zu erhöhen. Dabei geht es mir einerseits darum aufzuzeigen, wel-

1

Einleitung che Mechanismen Windows Vista für den Schutz des Betriebssystems bietet und wie Sie diese konfigurieren können, andererseits aber auch darum, dass Sie verstehen, was diese Einstellungen genau bedeuten. Ich bin überzeugt, dass umfangreiches und tiefes Sicherheitsdenken und -verständnis nur dann möglich ist, wenn auch die Hintergründe von Diensten, Konfigurationen oder von was auch immer verständlich sind. Ich zeige Ihnen daher in diesem Buch auch auf, wie Windows Vista mit Ihren Konfigurationen umgeht und was hinter den Kulissen alles vor sich geht. Ein nicht unwesentlicher Baustein einer solchen Sicherheitsarchitektur stellen Clients dar. Clients sind diejenigen Komponenten, die am häufigsten vertreten sind (in den meisten Fällen jedenfalls), und sie werden unter anderem genutzt, um mit unbekannten Partnern zu kommunizieren. Wie bitte? Unbekannte Partner? Viele Clients arbeiten mit Internetressourcen, und dabei handelt es sich um Webserver, Webseiten und Webdienste, die nicht vertrauenswürdig, meistens komplett unbekannt sind. Dieser Kommunikationspfad vom internen Netzwerk zur Außenwelt ist nicht vertrauenswürdig und muss ganz besonders gesichert werden, einerseits mit zentralen Komponenten wie beispielsweise einer Firewalloder Proxy-Infrastruktur, andererseits aber auch auf dem Endgerät selber, nämlich dem Client. Es ist auch möglich, dass mobile Clients das firmeninterne Netzwerk verlassen und sich mit fremden, unbekannten Netzwerken verbinden. Was in diesem Zustand dann genau passiert, lässt sich nicht detailliert nachvollziehen. Fakt ist aber, dass diese Geräte zu einem späteren Zeitpunkt wieder am Firmennetzwerk angebunden werden. Da nicht bekannt ist, was in der Zwischenzeit mit diesen Geräten passiert ist, besteht auch hier ein erhöhtes Risiko. Die Liste mit solchen Beispielen lässt sich fast endlos weiterführen. Wichtig ist mir persönlich, dass die gezeigten Beispiele zum Nachdenken anregen. Gibt es solche Szenarien auch in meiner Firma? Wie arbeiten unsere Anwender mit ihren Clients? Habe ich überhaupt in irgendeiner Art und Weise die Kontrolle über meine Clients? Sind meine Anwender geschult, und wissen sie, wie sie sich verhalten müssen? Im Ungang mit E-Mail? Im Umgang mit dem Internet? Technische Sicherheit ist nicht ausreichend Wie aber kann Windows Vista hier ansetzen, um die Sicherheit eines Clients und dadurch des gesamten Netzwerks entscheidend zu verbessern? Bevor wir uns das anschauen, ist etwas ganz besonders zu erwähnen: Die beste Konfiguration, die höchsten Sicherheitseinstellungen und die umfangreichste Überwachung sind unter Umständen wertlos, wenn Benutzer sich falsch verhalten. Einfaches Beispiel gefällig? Ein Benutzer erhält einen Anruf von einer unbekannten Person, die behauptet, dass sie seit Kurzem in der Helpdeskabteilung arbeitet. So weit nichts Außergewöhnliches. Wenn dieser Anrufer den Benutzer auffordert, ihm sein Kennwort zwecks Verifizierung am Telefon durchzugeben, wird es schon kritischer. Viele Benutzer werden dem Wunsch des Anrufers vom Helpdesk – der in Wirklichkeit jemand ganz anderes ist und die Absicht hat, an sensitive Firmendaten zu gelangen – nachkommen und ihm ihr Kennwort bedenkenlos mitteilen. Sie denken, das kann in Ihrer Firma nicht passieren? Versuchen Sie es! Und Sie werden erstaunt sein über den Erfolg.

2

Einleitung Aber Moment einmal, ich habe ja eine Firewall, einen Virenscanner, eine Anti-SpyLösung und erst noch ein superkomplexes Administratorenkennwort. Eigentlich kann da nichts passieren. Wenn eine fremde Person – nennen wir sie einmal „Angreifer“ – mit der gezeigten Methode an ein Kennwort eines Unternehmens kommt, ist das schon äußerst kritisch. Angriffe sind oft mehrstufig und eine erfolgreiche Authentifizierung an einem fremden Netzwerk oft der beste Einstiegspunkt, um den Angriff später auszuweiten. Und das gezeigte Beispiel ist nur eines von vielen, um Benutzer zum falschen Handeln zu bringen. Diese Technik wird im Übrigen als „Social Engineering“ bezeichnet und ist heute weit verbreitet, um Netzwerke bzw. Firmen anzugreifen. Mit diesem kleinen Beispiel möchte ich lediglich aufzeigen, dass technische Sicherheit nicht alles ist. Nichtsdestotrotz ist sie sehr wichtig, um den Schutz einer Infrastruktur zu vervollständigen. Und jetzt kommt (endlich) Windows Vista zum Zug! Sicherheit mit Windows Vista Noch vor ein paar Jahren hat sich im Bereich Netzwerksicherheit alles fast ausschließlich um das Thema Firewall gedreht, andere Themen waren nicht oder nur begrenzt relevant. Die Zeiten haben sich aber geändert, und das Sicherheitsdenken hat sich bis zu den Endgeräten ausgeweitet. Schließlich soll Sicherheit ja mehrschichtig sein, um es einem potenziellen Angreifer schwieriger zu machen, erfolgreich zu werden. Und genau hier setzt Windows Vista an. Mit neuen Sicherheitsmechanismen, die Clients schützen können, um das Gesamtsicherheitskonzept eines Unternehmens zu vervollständigen. Dazu hat Microsoft in den letzten Jahren einiges auf den Kopf gestellt, um mit Windows Vista wirklich „das sicherste Windows-Betriebssystem aller Zeiten“ auf den Markt zu bringen. Das hört sich vielleicht ein bisschen übertrieben an und sehr marketingorientiert, ist aber tatsächlich so. Windows Vista ist das erste Betriebssystem, das vollständig nach dem neuen Security Development Lifecycle entwickelt worden ist. Dabei wird die Sicherheit – anders als bei älteren Betriebssystemen und Produkten – von Anfang an in den Entwicklungsprozess integriert. Sicherheit ist demnach nicht einfach ein simples „Add-On“, sondern fester Bestandteil des Produkts. Dazu aber später mehr. Wer sollte dieses Buch lesen? Für wen hat dieses Buch einen Nutzen? Wer sollte es lesen und sich mit den Inhalten vertraut machen? Nun, dieses Buch ist primär auf Tätigkeitsbereiche von System Engineers, Administratoren und technischen Projektleitern, die im Firmenumfeld arbeiten, fokussiert. Es geht primär darum, die neuen Sicherheitsmechanismen von Windows Vista zu durchleuchten und Ihnen anhand vieler Beispiele zu erklären, wie einzelne Funktionen implementiert sind, warum sie in das neue Betriebssystem eingebettet worden sind und natürlich wie alles richtig konfiguriert wird. Auch Heimanwender werden von den Inhalten dieses Buches profitieren, allerdings werden diese einige Funktionen, die ausschließlich für den privaten Bereich relevant sind, also Funktionen wie beispielsweise Windows Mail oder Windows Kalender, vermissen. Diese Programme werden im Firmenumfeld kaum eingesetzt und werden daher nicht berücksichtigt. Das Buch ist – so hoffe ich zumindest – „gee-

3

Einleitung kig“ ausgelegt und behandelt viel Hintergrundwissen, das bestimmt vielen Lesern bisher noch nicht bekannt ist. Freuen Sie sich also über ein nicht ganz alltägliches Buch. Es ist schwierig, ein Buch, das sich ausschließlich mit Sicherheitsfunktionen befasst, für jedermann sinnvoll strukturiert aufzubauen. Einige Themen überschneiden sich oder bauen aufeinander auf, andere wiederum sind komplett unabhängig und isoliert. Das alles in einen harmonischen Ablauf zu bringen ist eine echte Herausforderung, und ich hoffe, dass mir dieses Meisterstück zumindest einigermaßen gelungen ist. Die einzelnen Kapitel sind grundsätzlich autonom, d.h., Sie können die Kapitel losgelöst voneinander lesen und die Inhalte durcharbeiten. Wie ich bereits in der Einleitung erwähnt habe, ist Sicherheit ein dynamischer Prozess. Was heute relativ sicher ist, kann morgen absolut unsicher sein, was heute aktuell ist, kann übermorgen veraltet sein. Wie lange die Inhalte in diesem Buch Gültigkeit haben bzw. wie lange sie für den Leser wertvoll sind, lässt sich natürlich nicht mit Bestimmtheit sagen. Fakt ist allerdings, dass die erwähnten Technologien mit größter Wahrscheinlichkeit während der gesamten Lebensdauer von Windows Vista aktuell bleiben werden. Natürlich werden einige Komponenten aktualisiert, vielleicht auch erweitert werden, aber diese Neuerungen bauen auf den heute aktuellen Informationen auf. Sie verlieren demnach kein Know-how, keine investierte Zeit und auch kein Geld. Mit einer Webseite zum Buch möchten wir Ihr Know-how aber regelmäßig auffrischen, und so erhalten Sie die Möglichkeit, sich kostenlos über Neuerungen in diesem Bereich zu informieren. Verwenden Sie dazu lediglich folgende URL: http://www.zehni.ch/vistasecurity Danksagungen Ich schreibe diese Zeilen (und den Großteil des Buchs) kurz nach der Durchführung der TechEd in Orlando/USA im Juni 2007. Ich bin seit zwei Wochen in den Vereinigten Staaten, um mir einerseits die letzten Informationen für dieses Buch aus erster Hand bei Microsoft zu beschaffen, andererseits um das Manuskript zum Buch fertigzustellen. Meine Familie – meine Lebenspartnerin Valerie sowie unsere beiden Kinder Jana-Alena und Linus – sind in der Schweiz geblieben, damit ich mich voll auf die bevorstehende Aufgabe konzentrieren kann. Für dieses Verständnis möchte ich den dreien danken. Ich vermisse euch und freue mich, bald wieder zu Hause zu sein! Ebenfalls bedanken möchte ich mich bei allen „Technical Readers“ – alles gute Freunde von mir –, die viel Zeit investiert haben, um meine geschriebenen Texte kritisch zu analysieren und mir wertvolles Feedback zu geben. Besten Dank an dieser Stelle, ich hoffe, ihr seid auch beim nächsten Buch wieder so engagiert dabei! Auch das Team des Carl Hanser Verlags soll nicht unerwähnt bleiben. Allen, besonders aber meinem Lektor Fernando Schneider, der die Idee zu diesem Buch hatte und mir den entscheidenden Anstoß zum Schreiben gegeben hat, möchte ich herzlich danken. Ich freue mich über viele weitere Bücher! So, und jetzt geht’s los ...

4

1 Benutzerkontensteuerung Eines der wohl meisterwähntesten und aufsehenerregendsten Features von Windows Vista ist die Benutzerkontensteuerung (User Account Control, UAC). Bereits lange vor dem Launch von Windows Vista wurde viel über diese neue Funktion berichtet, die dem neuesten Clientbetriebssystem mehr Sicherheit einhauchen soll, und auch heute wird bei Aufzählungen der Windows Vista-Highlights oft zuerst die Benutzerkontensteuerung erwähnt. Grundsätzlich geht es bei dieser Funktion darum, dass Benutzer für tägliche Aufgaben keine Administrationsrechte mehr benötigen. Microsoft hat bereits bei früheren Releases von Windows-Betriebssystemen darauf hingewiesen, dass Benutzer mit „normalen“ Benutzerrechten anstelle von lokalen Administrationsrechten arbeiten können, allerdings hat sich das in der Praxis alles andere als bewährt. Mit normalen Benutzerrechten lässt sich ein System nicht wirklich sinnvoll nutzen, weil essenzielle Aktivitäten schlicht nicht wahrgenommen werden können. Mit normalen Benutzerrechten lässt sich beispielsweise unter Windows XP keine vollständige Wireless-Einrichtung inkl. WEP/WPA-Konfiguration vornehmen, genauso bei Eingriffen in die Energieoptionen – Konfigurationsänderung Fehlanzeige! Auch sind viele Anwendungen nicht oder nur eingeschränkt ausführbar, weil diese möglicherweise Konfigurationsänderungen an Orten speichern, an denen Standardbenutzer keine Rechte besitzen. Um dieses Problem zu umgehen, haben sich viele Administratoren entschieden, Benutzern lokale Administrationsrechte zuzuweisen, sodass diese uneingeschränkt mit ihren Systemen arbeiten können. Aus Sicht der Produktivität und Nutzbarkeit in erster Linie sicher ein Vorteil, sicherheitstechnisch aber ein großer Nachteil. Durch die permanent hohen – nein, höchstmöglichen – Rechte, die Anwender besitzen, wird es für Angreifer, Malware oder Viren deutlich einfacher, ein System zu kompromittieren, weil der immer aktive Administratorenkontext eine breite Angriffsfläche ohne Einschränkungen bietet. Installationen oder Konfigurationsänderungen können so ohne große Probleme und Kenntnis des Anwenders erfolgen und einen Rechner innerhalb kürzester Zeit zu einer Virenschleuder oder einem Zombie umfunktionieren.

5

1 Benutzerkontensteuerung

1.1

Lokales Administratorenkonto – deaktiviert! Eine wichtige Neuerung, die eigentlich nichts mit der Benutzerkontensteuerung zu tun hat, ist die Tatsache, dass das lokale Administratorenkonto unter Windows Vista standardmäßig deaktiviert ist. Wie soll denn ein Windows Vista-Rechner ohne aktives Administratorenkonto administriert werden? Ganz einfach: Beim Setup des Betriebssystems wird ein zusätzliches Konto angelegt, das über Administratorenrechte verfügt und somit die volle Verwaltungshoheit über den Rechner besitzt. Weshalb das so ist? Um sich erfolgreich an einem System anzumelden, benötigt man einen gültigen Anmeldenamen und das zugehörige Kennwort. Bei allen Betriebssystemen vor Windows Vista hatte der Administrator – und somit das heikelste Benutzerkonto eines Systems – jeweils den Anmeldenamen „Administrator“. Somit war immer bereits eine der beiden benötigten Informationen für eine erfolgreiche Anmeldung mit den höchstmöglichen Rechten vorhanden, und es musste nur noch das entsprechende Kennwort ausfindig gemacht werden. Eine Umbenennung des Kontos und somit auch des Anmeldenamens hatte hier Abhilfe geschafft. Tatsächlich? Nun, wenn man es genau betrachtet, nur begrenzt. Jedes Benutzerkonto (unabhängig davon, ob es sich dabei um ein lokales Konto oder ein Domänenkonto handelt) besitzt eine Security-ID (SID) die eindeutig sein muss. Alles, was nun irgendetwas mit Berechtigungen zu tun hat, wird über diese SID abgehandelt, sei es der Zugriff auf Ressourcen oder das Anwenden eines bestimmten Rechts. Bei dem zweiten Teil dieser SID handelt es sich um die Relative ID (RID), und die ist bei jedem Standardadministratorenkonto jeweils 500. Ein Konto kann umbenannt oder verschoben werden (nur in einer Active Directory-Domäne), aber die SID und daher auch die RID bleiben immer unverändert, wodurch eine Identifizierung relativ einfach ist. Unabhängig davon, ob das mit integrierten Tools, mit Werkzeugen von Drittherstellern oder mit Skripten erfolgt, ist das Resultat immer das gleiche: Sie wissen anschließend, bei welchem Konto es sich um das Standardadministratorenkonto handelt. Und das ist schlecht. Folgendes Beispiel zeigt die Informationsbeschaffung mithilfe von WMIC (Windows Management Instrumentation Console), einem Werkzeug, das mit Windows Vista (und auch mit früheren Betriebssystemen) mitgeliefert wird.

6

1.1 Lokales Administratorenkonto – deaktiviert!

Abbildung 1.1 WMIC zum Identifizieren des lokalen Standardadministratorenkontos

Aufgrund des RID-Werts von 500 kann das Konto identifiziert werden. Im gezeigten Beispiel ist das Administratorenkonto in „Master“ umbenannt worden, was aber offensichtlich nicht sehr viel gebracht hat. Es ist innerhalb weniger Sekunden bekannt. Mit dem gezeigten Beispiel soll lediglich beleuchtet werden, dass eine Umbenennung des Standardadministratorenkontos unter Umständen nicht den gewünschten Effekt bringt. Aber bei Ihrem Windows Vista ist das ja kein Problem – das Konto ist ja deaktiviert, und das effektive Administratorenkonto kann nicht so einfach ausfindig gemacht werden.

Abbildung 1.2 Deaktiviertes Standardadministratorenkonto

7

1 Benutzerkontensteuerung

1.2

Standardbenutzerrechte – ein entscheidender Vorteil! Mit dem Release von Windows Vista haben Standardbenutzer neue und sinnvollere Rechtezuweisungen erhalten, sodass viele Aktivitäten, die Benutzer wahrnehmen möchten oder müssen, jetzt ohne Administratorenrechte möglich sind. Es ist demnach grundsätzlich nicht mehr notwendig, einen Benutzer in die lokale Administratorengruppe aufzunehmen, nur weil er Wireless-Konfigurationen, Zeitzonen- oder Energieschema-Anpassungen vornehmen muss. Was aber hat sich an den Rechten für Standardbenutzer genau geändert? Was können Standardbenutzer neu tun? Folgende Liste schafft Klarheit: Anzeigen der Systemzeit und des Datums Ändern der Zeitzone (für mobile Benutzer, die unterschiedliche Zeitzonen bereisen) Einrichten von WEP/WPA (für die Verbindung mit sicheren WLAN-Netzwerken) Ändern der Anzeigeeinstellungen Ändern von Energieeinstellungen bzw. Energieplänen Installieren von zusätzlichen Schriftarten Einrichten von Druckern und anderen Geräten (sofern entsprechende Treiber zur Verfügung stehen) Erstellen und Konfigurieren von VPN-Verbindungen (für den sicheren Zugriff auf private Netzwerke, beispielsweise das eigene Firmennetzwerk) Installation von kritischen Updates (falls Geräte über längere Zeit nicht mehr mit dem Firmennetzwerk verbunden waren und daher nicht mehr dem aktuellsten Patch- und Sicherheitsstand entsprechen) Installieren von ActiveX-Controls (wenn ein Administrator die entsprechenden Sites zuvor freigegeben hat) Defragmentieren der Festplatte (wird automatisch und regelmäßig mithilfe eines geplanten Tasks ausgeführt) Aufgrund der erweiterten Rechte der Standardbenutzergruppe wird die Gruppe „Hauptbenutzer“ nicht mehr benötigt. Die Gruppe steht nach wie vor zur Verfügung, um Migrationsszenarien zu vereinfachen, wird aber für neue Implementierungen grundsätzlich nicht mehr eingesetzt.

Mit diesen neuen Rechten können Standardbenutzer ihr Gerät bzw. Betriebssystem schon mal sinnvoller und bequemer nutzen. Was aber, wenn ein Benutzer administrative Tätigkeiten wahrnehmen muss und Standardrechte doch nicht ausreichen? Was, wenn Benutzer Anwendungen ausführen müssen, die nicht Vista-konform programmiert worden sind und mit Standardrechten nicht auskommen, weil beispielsweise Schreibfunktionen fehlschlagen? Hier kommt jetzt endlich die Benutzerkontensteuerung zum Zug.

8

1.3 Verwaltung von Windows Vista – Rechteerhöhung bei Bedarf!

1.3

Verwaltung von Windows Vista – Rechteerhöhung bei Bedarf! Schauen wir uns zuerst das Beispiel der erweiterten Verwaltung an. Wenn Benutzer erweiterte Konfigurationsänderungen vornehmen müssen, beispielsweise neue Verbindungen durch die Windows Firewall zulassen möchten, dann reichen Standardbenutzerrechte natürlich nicht mehr aus. Damit sich Benutzer für solche Operationen nicht extra ab- und neu anmelden müssen, bietet die Benutzerkontensteuerung die Möglichkeit, die aktiven Rechte zu erhöhen, sodass für die anstehende Konfigurationsänderung – und nur für genau diese – Administrationsrechte aktiviert werden. Alle anderen Programme und Aktivitäten werden nach wie vor mit Standardbenutzerrechten ausgeführt. Da nur für eine bestimmte Aktion Administrationsrechte benötigt werden, bleibt das gesamte System in einem verhältnismäßig sicheren Zustand und ist dennoch bequem nutzbar – die Balance zwischen Sicherheit und Nutzbarkeit ist also fürs Erste realisiert. Wie aber kann ein Benutzer seine Rechte erhöhen, um beispielsweise erweiterte Konfigurationen vornehmen zu können? Dazu stehen verschiedene Möglichkeiten zur Verfügung. Benutzer können ihre Rechte erhöhen, indem sie bei einer entsprechenden Aktion – für die Standardbenutzerrechte nicht mehr ausreichen – ein anderes Konto mit Administrationsrechten verwenden, um sich zu authentifizieren. Die entsprechenden Informationen dazu werden in ein Anmeldefenster eingegeben und die Rechte anschließend erhöht. Falls ein Benutzer bereits mit einem Konto, das über Administrationsrechte verfügt, angemeldet ist, muss lediglich die Erhöhung der Rechte bestätigt werden. Eine Eingabe von Anmeldeinformationen ist nicht notwendig. Sobald für eine bestimmte Aktion erhöhte Rechte benötigt werden, wird dies dem Benutzer durch Anzeige eines entsprechenden Fensters mitgeteilt. Je nach Aktivität und Konfiguration werden dazu (optisch) unterschiedliche Prompts verwendet.

Abbildung 1.3 Zustimmung zur Rechteerhöhung

9

1 Benutzerkontensteuerung

Abbildung 1.4 Eingabe von Anmeldeinformationen zur Rechteerhöhung

Die oben aufgeführten Möglichkeiten, die Rechte bei Bedarf zu erhöhen, lassen sich mithilfe von Gruppenrichtlinien noch detailliert konfigurieren. Aber das werden wir uns später in diesem Kapitel ansehen. Die meisten Aktionen, die unter Windows Vista ein Erhöhen der Rechte benötigen, werden auf der grafischen Oberfläche mit einem Schildsymbol dargestellt. Somit ist sofort ersichtlich, für welche Aufgaben die Rechte von Standardbenutzern nicht mehr ausreichen.

Abbildung 1.5 Schildsymbole bedeuten Rechteerhöhung.

10

1.3 Verwaltung von Windows Vista – Rechteerhöhung bei Bedarf! Was aber läuft im Hintergrund ab, wenn Rechte über eine der gezeigten Varianten erhöht werden? Bei einer erfolgreichen Anmeldung eines Benutzers an einem Rechner wird ein Access Token generiert. Dabei handelt es sich um ein geschütztes Objekt, das Informationen zum Benutzerkonto, dessen Gruppenmitgliedschaften und verfügbare Benutzerrechte enthält. Dieses Access Token kommt immer bei sicherheitsrelevanten Aktivitäten zum Zuge, beispielsweise wenn der Anwender auf Dateien zugreift oder eine Konfigurationsänderung am System vornimmt. Dann werden die Aktivitäten jeweils mit den Informationen des Access Tokens verglichen und der Zugriff entsprechend gewährt bzw. verweigert. Wenn nun unter Windows Vista für eine Aktivität nicht genügend Rechte zur Verfügung stehen, kann ein Benutzer diese unter Angabe von Anmeldeinformationen eines Administratorenkontos erhalten. Dazu wird ein zweites Access Token (Admin-Token) angelegt, das über mehr Möglichkeiten bzw. Rechte verfügt. Auf dieses Admin-Token hat nur genau derjenige Prozess Zugriff, für den die Rechteerhöhung vorgenommen worden ist. Für alle restlichen Prozesse steht ausschließlich das Standard-Token zur Verfügung. Das genau gleiche Verhalten tritt auf, wenn sich ein Benutzer anmeldet, dessen Konto einer Administratorengruppen angehört. Eigentlich ist dieser Benutzer von Beginn an als Administrator authentifiziert, dennoch werden die Rechteinformationen in zwei Tokens, einem Standard- und einem Admin-Token, abgelegt. Falls das Recht für eine Aktivität erhöht werden muss, ist lediglich eine Aktivierung des zweiten Tokens notwendig. Wie dies genau erfolgt, lässt sich konfigurieren. Beispielsweise ist es möglich, die Aktivierung lediglich über eine Bestätigung (und ohne erneute Authentifizierung) zu realisieren. Bei Bedarf kann allerdings auch festgelegt werden, dass eine erneute Authentifizierung unter Eingabe von Benutzername und Kennwort erfolgen muss.

Abbildung 1.6 Split Token bei Administratorenanmeldung

11

1 Benutzerkontensteuerung Die Informationen, die in Access Tokens gespeichert sind, lassen sich mit verschiedenen Methoden darstellen. Ein Tool, das bei Vista standardmäßig mitgeliefert wird und Informationen aus den Access Tokens darstellen kann, ist „Whoami.exe“. Mit einem einfachen Beispiel lässt sich besser nachvollziehen, wie das Split-Token-Verfahren genau funktioniert. 1. Melden Sie sich mit einem Konto an einem Windows Vista-Rechner an, das sich in der lokalen Administratorengruppe befindet. 2. Starten Sie den Command Prompt, beispielsweise über das Startmenü. 3. Geben Sie den Befehl „Whoami.exe /all“ ein . Die dargestellten Informationen zeigen Inhalte des Standard-Tokens des angemeldeten Benutzers. Beachten Sie insbesondere die angezeigten Privilegien.

Abbildung 1.7 Access Token eines Benutzers mit Standardbenutzerrechten

Unter anderem werden mit dem Tool die SID des Benutzerkontos, sämtliche Gruppenmitgliedschaften und eine Liste mit speziellen Benutzerrechten angezeigt. Vergleichen Sie die angezeigten Informationen des Standard-Tokens nun mit einem Admin-Token. Gehen Sie wie folgt vor: 1. Starten Sie mit dem gleichen Benutzer erneut einen Command Prompt, diesmal allerdings im Administrationsmodus (Rechtsklick, „Als Administrator ausführen“). 2. Geben Sie den Befehl „Whoami.exe /all“ ein. Die dargestellten Informationen zeigen Inhalte des Admin-Tokens des angemeldeten Benutzers. Sie werden feststellen, das einerseits deutlich mehr Benutzerrechte zur Verfügung stehen, andererseits aber auch eine höhere Integritätsebene verwendet wird. Doch mehr dazu später.

12

1.4 Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung!

Abbildung 1.8 Access Token eines Benutzers mit Administratorenrechten

1.4

Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung! Somit wäre der Berechtigungsteil abgeschlossen. Widmen wir uns nun den Anwendungen, die mit Standardbenutzerrechten nicht ausgeführt werden können. Warum können bestimmte Anwendungen eigentlich nicht erfolgreich gestartet werden, wenn ein Benutzer nur über Standardrechte verfügt? Das kann beispielsweise daran liegen, dass eine Anwendung bei der Ausführung versucht, Programmdateien zu verändern oder temporäre Dateien an einem Ort anzulegen, an dem ein Benutzer lediglich über Leserechte verfügt. Das Gleiche gilt für bestimmte Bereiche der Registrierung. Folglich scheitern diese Anwendungen bei der Ausführung mit Standardbenutzerrechten vollständig oder lassen sich zumindest nur eingeschränkt nutzen. Leider gibt es immer noch unglaublich viele Anwendungen, die nicht Vista-konform entwickelt worden sind und versuchen, im Programmverzeichnis des Systems oder in Bereichen der Registrierung irgendwelche Änderungen vorzunehmen. Solche Anwendungen scheitern bei der regulären Ausführung mit Standardbenutzerrechten. Mit der Benutzerkontensteuerung von Windows Vista ist aber nun auch dieser Bereich adressiert worden. Bestimmte Orte des Dateisystems und der Registrierungsdatenbank werden bei Bedarf virtualisiert, d.h., an einen anderen Ort umgeleitet. Sobald eine Anwendung eine bestimmte Operation wegen mangelnder Berechtigungen nicht vollständig ausführen kann, wird diese Aktion – beispielsweise die Änderung einer Programmdatei – vom Be-

13

1 Benutzerkontensteuerung triebssystem bemerkt (tatsächlich ist es ein Treiber, der Schreibversuche auf bestimmte Verzeichnisse abfängt und umleitet). Die Änderungen werden dann im Virtual Store abgelegt, und die Programmdateien bleiben im Originalzustand. Wird eine Anwendung das nächste Mal gestartet, wird zuerst geprüft, ob sich geänderte Dateien oder RegistryEinstellungen im Virtual Store befinden. Ist dies der Fall, werden diese geladen. Alle restlichen Informationen werden aus dem regulären Programmordner bzw. dem Registrierungsdatenbankbereich der Anwendung eingelesen.

Abbildung 1.9 Virtualisierung von Schreibzugriffen auf Dateisystem und Registrierung

Folgende Bereiche werden bei einer Legacy-Anwendung bei Bedarf virtualisiert (wobei einige wenige Unterorder von der Virtualisierung ausgeschlossen sind): Dateisystem: „C:\ProgramFiles“ (%ProgramFiles%) Dateisystem: „C:\ProgramData“ (%ProgramData% bzw. %AllUsersProfile%) Dateisystem: „C:\Windows“ (%Systemroot%) Registrierungsdatenbank: „HKLM\Software“ (mit einigen Ausnahmen, z.B. „HKLM\Software\Microsoft\Windows“, „HKLM\Software\Microsoft\Windows NT“ oder „HKLM\Software\Classes“) Die Umleitung der virtualisierten Objekte findet an unterschiedlichen Orten statt: Bereich

Umleitung nach

Dateisystemvirtualisierung

C:\Benutzer\Benutzername\AppData\Local\VirtualStore

Unterhalb dieses Ordners wird eine Ordnerstruktur angelegt, die beispielsweise Ordner mit den Bezeichnungen „Windows“ oder „Program Files“ enthält. Diese Struktur widerspiegelt die tatsächliche Dateistruktur und enthält die virtualisierten Dateien.

14

1.4 Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung! Bereich

Umleitung nach

Registrierungsvirtualisierung

HKCU\Software\Classes\VirtualStore

Unterhalb dieses Schlüssels wird eine Struktur angelegt, die weitere Schlüssel enthält. Diese Struktur widerspiegelt die tatsächliche Registrierungsdatenbankstruktur des Bereichs HKLM\Software und enthält die virtualisierten Registrierungsschlüssel.

Abbildung 1.10 Virtual Store für Dateien

Abbildung 1.11 Virtual Store für Registrierungseinträge

15

1 Benutzerkontensteuerung Beide Virtual Stores befinden sich im Profil des jeweiligen Benutzers und stehen daher auch wieder zur Verfügung, wenn der Benutzer sich das nächste Mal anmeldet. Allerdings werden die Einstellungen nicht in die serverbasierten Profile zurückgeschrieben. Das ist auch nicht notwendig, weil die jeweiligen Anwendungseinstellungen nur genau auf demjenigen Gerät Gültigkeit haben, auf dem sich die Anwendung befindet.

Um das Prinzip dahinter besser nachvollziehen zu können, navigieren Sie am besten einfach einmal in Ihren Virtual Store und prüfen, was sich dort schon so alles angesammelt hat. Auch lassen sich bestimmte Konfigurationen anzeigen, beispielsweise die Virtualisierungskonfiguration einzelner Registrierungsschlüssel. Das Tool „Reg.exe“ kann gegen einen beliebigen Registrierungsschlüssel gestartet werden, um die genaue Konfiguration anzuzeigen.

Abbildung 1.12 Virtualisierungsflags bei Registry-Schlüsseln

Flag

Beschreibung

REG_KEY_DONT_VIRTUALIZE

Dieses Flag legt fest, ob der angegebene Registrierungsschlüssel virtualisiert wird oder nicht. Ist das Flag nicht gesetzt lear), wird der Schlüssel bei Bedarf virtualisiert. Ist das Flag setzt (= Set), wird der Schlüssel nicht virtualisiert.

REG_KEY_DONT_SILENT_FAIL

Dieses Flag legt fest, ob Benutzer bei einer Virtualisierung benachrichtigt werden oder nicht. Ist das Flag nicht gesetzt Clear), bemerkt der Benutzer nichts von der stattfindenden tualisierung. Ist das Flag gesetzt (= Set), wird der Benutzer nachrichtigt und muss den Vorgang bestätigen.

REG_KEY_RECURSE_FLAG

Dieses Flag legt fest, ob die Flag-Einstellungen an die untergeordneten Registrierungsschlüssel vererbt werden. Ist das Flag nicht gesetzt (= Clear), findet keine Vererbung statt. Ist das Flag gesetzt (= Set), werden die Einstellungen an alle vorhandenen Unterschlüssel vererbt.

16

1.4 Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung! Die Virtualisierung gilt grundsätzlich für Legacy-Anwendungen, d.h. für Anwendungen, die ursprünglich für andere Betriebssysteme als Windows Vista entwickelt worden sind. Windows Vista-konforme Anwendungen, die über ein Windows Vista-Manifest mit dem Eintrag „RequestExecutionLevel“ verfügen (und daher mit der Benutzerkontensteuerung interagieren können), benötigen keine Virtualisierung. Ebenfalls nicht virtualisiert werden 64-Bit-Prozesse und alle nichtinteraktiv erfolgten Zugriffe. Mithilfe des Tools „Sigcheck.exe“, das über die Microsoft-Webseite heruntergeladen werden kann (ehemals Sysinternals), kann das Manifest von Anwendungen angezeigt werden. Dadurch ist sofort ersichtlich, ob eine Anwendung Vista-konform entwickelt worden ist. Das ist dann der Fall, wenn die Anwendung die Funktion der Benutzerkontensteuerung kennt und weiß, wie sie mit dieser umzugehen hat. Ein Manifesteintrag (requestExecutionLevel) legt dabei fest, ob bei einem Start eine Rechteerhöhung erfolgen kann oder muss.

Abbildung 1.13 Manifest mit „requestExecutionLevel“-Eintrag

Im Screenshot ist ersichtlich, dass es sich bei der Anwendung „Notepad.exe“ um eine Vista-konforme Anwendung handelt. Das Manifest enthält den Eintrag „RequestExecutionLevel“, der angibt, ob für diese Anwendung die Rechte erhöht werden dürfen oder nicht.

17

1 Benutzerkontensteuerung Es gibt folgende unterschiedliche Werte, die Anwendungsentwickler dazu nutzen können, die Erhöhung von Rechten zu steuern: Wert

Beschreibung

AsInvoker

Wenn dieser Wert gesetzt ist, kann die Anwendung nur mit dem derzeitigen Konto ausgeführt werden. Eine Erhöhung ist nicht möglich. Das Programm „Notepad.exe“ nutzt diese Einstellung.

HighestAvailable

Bei Bedarf kann das Recht des derzeit angemeldeten Benutzers erhöht werden, indem das Admin-Token aktiviert wird oder eine Anmeldung mit einem anderen Konto erfolgt (je nach Richtlinienkonfiguration). Das Programm „Regedit.exe“ nutzt diese Einstellung und ermöglicht dem Ausführenden so, seine Rechte entsprechend zu erhöhen.

RequireAdministrator

Dieser Wert bedingt, dass ein Administrator die jeweilige Anwendung startet. Das Programm „Syskey.exe“ nutzt diese Einstellung standardmäßig.

Ein interessantes Beispiel für die Virtualisierung kann mithilfe der Eingabeaufforderung (cmd.exe) gezeigt werden. Diese Anwendung ist selbstverständlich Windows Vistakonform entwickelt worden und arbeitet optimal mit der Benutzerkontensteuerung zusammen. Sie verfügt über ein Windows Vista-Manifest, das den Eintrag „RequestExecutionLevel“ enthält, sodass die Virtualisierung deaktiviert ist. Wird nun versucht, mit Standardbenutzerrechten eine Datei im Windows-Ordner (c:\windows) anzulegen, schlägt dies fehl. In diesem speziellen Fall versucht der Prozess „cmd.exe“, die Datei zu erstellen. Dieser Prozess verfügt allerdings nicht über ausreichende Rechte, worauf die Erstellung fehlschlägt. Dieser Vorgang ist vergleichbar mit einer Anwendung, die gestartet wird und versucht, Dateien in einem Systemordner zu überschreiben oder zu erstellen. Eigentlich würde jetzt die Virtualisierung zum Zuge kommen und diese zu erstellende Datei in den Virtual Store umleiten. Da die Virtualisierung für die Eingabeaufforderung aber deaktiviert ist, erfolgt keine Virtualisierung, und der Vorgang kann nicht erfolgreich abgeschlossen werden.

18

1.4 Anwendungen mit Standardbenutzerrechten ausführen – eine wahre Herausforderung!

Abbildung 1.14 Eingabeaufforderung ohne Virtualisierung

Über den Task Manager ist sichtbar, dass für die Eingabeaufforderung keine Virtualisierung verfügbar ist (dazu muss die Spalte „Virtualisierung“ eingeblendet werden). Dieses Verhalten lässt sich aber umstellen, sodass auch bei Verwendung der Eingabeaufforderung bei Bedarf virtualisiert werden kann. Nach erfolgter Umstellung kann die Datei korrekt erstellt werden. Allerdings wird sie umgeleitet, ohne dass der Anwender etwas davon mitbekommt. Die umgeleitete, virtualisierte Datei kann angezeigt werden. Starten Sie dazu einen Explorer, und navigieren Sie zu demjenigen Ort, an dem die Datei erstellt worden ist (in diesem Beispiel „c:\windows“). Wenn an diesem Ort virtualisierte Dateien existieren, wird im Explorer die Schaltfläche Kompatibilitätsdateien eingeblendet. Wenn Sie auf diese Schaltfläche klicken, werden Sie direkt zum Virtual Store umgeleitet, und die Datei wird angezeigt.

19

1 Benutzerkontensteuerung

Abbildung 1.15 Eingabeaufforderung mit Virtualisierung

Abbildung 1.16 Virtualisierte Dateien anzeigen

Die Virtualisierung von Dateien oder Registrierungseinträgen wird in der Ereignisanzeige aufgezeichnet. Dafür steht unter Anwendungs- und Diensteprotokolle\Microsoft\ Windows\UAC-FileVirtualization\Operational eine eigene Protokollierungsdatei zur Verfügung.

20

1.5 Steuerung mittels Gruppenrichtlinien

Abbildung 1.17 Ereignisse werden in einer eigenen Protokollierungsdatei aufgezeichnet.

Im Log ist ersichtlich, welche Dateien virtualisiert und welche von der Virtualisierung ausgeschlossen worden sind. Zudem finden sich hier bei Virtualisierungsproblemen interessante Anhaltspunkte für deren Lösung.

1.5

Steuerung mittels Gruppenrichtlinien Die Benutzerkontensteuerung lässt sich detailliert über Gruppenrichtlinien konfigurieren, wodurch Administratoren die Funktion eng kontrollieren können. Es spielt dabei grundsätzlich keine Rolle, ob dazu eine lokale oder eine domänenbasierte Gruppenrichtlinie eingesetzt wird. Bedenken Sie allerdings, dass Domänenrichtlinien Vorrang vor lokalen Gruppenrichtlinien haben und diese übersteuern können. Wechseln Sie in einer Gruppenrichtlinie zum Pfad Computerkonfiguration\WindowsEinstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen. Dort stehen neun Richtlinien für die Verwaltung der Benutzerkontensteuerung zur Verfügung.

21

1 Benutzerkontensteuerung

Abbildung 1.18 Steuerung über Gruppenrichtlinien, Teil 1

Richtlinie

Beschreibung

Administratorbestätigungsmodus für das integrierte Administratorenkonto

Mit dieser Richtlinie wird festgelegt, ob Standardadministratorenkonten (gemeint sind das lokale Standardadministratorenkonto und das Konto des Domänenadministrators) erhöhte Rechte ebenfalls nur durch explizite Betätigung erhalten. Bei aktivierter Richtlinie ist ebenfalls eine Betätigung erforderlich, bei deaktivierter Richtlinie nicht (was gleich-

zeitig bedeutet, dass diese Konten beim Einsatz „angreifbarer“ werden). Standardeinstellungen: Deaktiviert Empfohlene Einstellung: Grundsätzlich sollten die Standardadministratorenkonten nicht für die Administration oder gar für die tägliche Arbeit genutzt werden (bei Windows Vista ist das lokale Administratorenkonto standardmäßig deaktiviert). Da in der Praxis für die Verwaltung leider immer noch oft das StandardDomänenadministratorenkonto eingesetzt wird, sollte diese Richtlinie sicherheitshalber aktiviert werden, um auch beim Einsatz dieses Kontos optimalen Schutz zu genießen. Alle Administratoren im Administratorbestätigungsmodus ausführen

Nur wenn diese Richtlinie aktiviert ist, ist die Benutzerkontensteuerung auch tatsächlich aktiv. Bei deaktivierter Richtlinie stehen somit keine Funktionen der Benutzerkontensteuerung (sichere Rechteerhöhung bei Bedarf, Split-Token-Prozess, Dateisys-

22

1.5 Steuerung mittels Gruppenrichtlinien tem- und Registrierungsvirtualisierung) zur Verfügung. Standardeinstellungen: Aktiviert Empfohlene Einstellung: Um die Sicherheit des Systems zu erhöhen und zu ermöglichen, dass auch Administratoren stets nur mit Standardbenutzerrechten arbeiten, sollte diese Richtlinie immer aktiviert werden. Anwendungsinstallation erkennen und erhöhte Rechte anfordern

Wenn diese Richtlinie aktiviert ist, wird die Installation von Anwendungen heuristisch erkannt und dem Benutzer ermöglicht, seine Rechte für die Installation zu erhöhen. Standardeinstellungen: Deaktiviert Empfohlene Einstellung: Da Benutzer in Unternehmen lediglich mit Standardrechten arbeiten sollten und Software von Administratoren installiert bzw. verteilt wird, sollte diese Richtlinie deaktiviert werden. Wenn ein Benutzer versucht, eine Anwendung zu installieren, wird ihm dadurch keine Möglichkeit geboten, seine Rechte für den Installationsprozess zu erhöhen.

Bei Benutzeraufforderung nach erhöhten Rechten zum sicheren Desktop wechseln

Wenn diese Richtlinie aktiviert ist, wechselt das System bei der Benutzeraufforderung nach erhöhten Rechten vom interaktiven Desktop zum sicheren Desktop. Der Prozess der Benutzerrechteerhöhung wird daher isoliert und lässt sich in keiner Weise beabsichtigt oder unbeabsichtigt (z.B. durch einen Virus) automatisieren. Wird die Richtlinie deaktiviert, wird der Rechteerhöhungsprozess auf dem interaktiven Desktop gestartet, wodurch eine Interaktion mit anderen Anwendungen möglich wird. Standardeinstellungen: Aktiviert Empfohlene Einstellung: Diese Einstellung sollte unbedingt aktiviert werden, um sicherzustellen, dass lediglich der Benutzer selber den Entscheid treffen kann, die Benutzerrechte entsprechend zu erhöhen. Die Benutzerrechte können so nicht ohne Wissen des Benutzers erhöht werden (beispielsweise durch Viren, Skripte oder sonstigen Code).

Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren

Wenn diese Richtlinie aktiviert ist, wird die Virtualisierung von Datei- und Registrierungsschreibfehlern aktiviert. Dabei werden fehlgeschlagene Schreibversuche in den Virtual Store des Benutzers umgeleitet, sodass Anwendungen, die nicht Vista-konform entwickelt worden sind, trotzdem lauffähig sind. Bei deaktivierter Richtlinie können Anwendungen möglicherweise nicht korrekt ausgeführt werden. Standardeinstellungen: Aktiviert

23

1 Benutzerkontensteuerung Empfohlene Einstellung: Diese Richtlinie sollte aktiviert bleiben, sodass Anwendungen möglichst uneingeschränkt ausgeführt werden können. Nur ausführbare Dateien heraufstufen, die signiert und validiert sind

Falls auf Windows Vista-Rechnern Anwendungen nur dann mit erhöhten Rechten ausgeführt werden dürfen, wenn sie eine digitale Signatur besitzen, kann diese Option aktiviert werden. Bei Aktivierung wird beim Start jeder Anwendung, die erhöhte Rechte benötigt, geprüft, ob diese digital signiert ist und ob dem Aussteller des Zertifikats vertraut wird. Ist dies der Fall, können die Rechte erhöht und die Anwendung ohne Einschränkungen ausgeführt werden, ansonsten wird die Ausführung verhindert. Bleibt die Richtlinie deaktiviert, können alle Anwendungen, die erhöhte Rechte fordern – auch diejenigen ohne digitale Signatur –, ausgeführt werden. Standardeinstellungen: Deaktiviert Empfohlene Einstellung: Digitale Signaturen für Anwendungen sind heute noch nicht sehr verbreitet. Damit sichergestellt werden kann, dass alle Anwendungen einwandfrei ausgeführt werden können, wird diese Richtlinie im Normalfall deaktiviert. Falls keine Anwendungen eingesetzt werden, die erhöhte Rechte benötigen, bzw. solche Anwendungen über digitale Signaturen verfügen, kann die Richtlinie natürlich aktiviert werden.

Nur erhöhte Rechte für UIAccessAnwendungen, die an sicheren Orten installiert sind

Bei UIAccess-Anwendungen handelt es sich um Anwendungen, die auf „fremde“ Fenster zugreifen können, d.h., sie können mit anderen Anwendungen zusammenarbeiten. Dazu müssen sie im Manifest den Eintrag „UIAccess = True“ aufweisen und über eine digitale Signatur verfügen (das ist für alle Anwendungen, die eine UIAccess-Integritätsebene anfordern, Pflicht). Wenn diese Anwendungen jetzt noch an einem sicheren Ort installiert sind – bei sicheren Orten handelt es sich um die Verzeichnisse %ProgramFiles% und %System32% –, dann erfüllen sie alle Anforderungen dieser Richtlinie. Wird die Richtlinie aktiviert, können diese Anwendungen erhöhte Rechte anfordern, ansonsten nicht. Standardeinstellungen: Aktiviert Empfohlene Einstellung: Aktivieren Sie diese Richtlinie für höchste Sicherheit. Somit wird sichergestellt, dass nur „saubere“ Anwendungen in andere Prozesse eingreifen können und das System optimal geschützt ist. Anmerkung: Erinnern Sie sich noch an das Tool „SigCheck.exe“, mit dessen Hilfe man Manifestinformationen anzeigen kann?

24

1.5 Steuerung mittels Gruppenrichtlinien Weiter vorne in diesem Buch wird anhand eines Beispiels das Manifest eines Vista-konformen Programms angezeigt. Unter anderem ist darin ersichtlich, ob für dieses Programm UIAccess zugelassen ist oder nicht. Die meisten Programme haben im Manifest einen „False“-Eintrag, was Ihnen den Zugriff auf andere Fenster unmöglich macht. Die Bildschirmtastatur allerdings hat einen „True“-Eintrag. Diesen können Sie mithilfe des Befehls „Sigcheck.exe –m c:\windows\system32\osk.exe“ anzeigen. Der Befehl ist natürlich auch für andere ausführbare Dateien nutzbar. Verhalten der Anhebungsaufforderung für Standardbenutzer

Diese Richtlinie legt fest, wie Windows Vista bei Standardbenutzern reagiert, wenn für einen bestimmten Prozess (z.B. Konfiguration der Windows-Firewall) erhöhte Rechte notwendig sind. Mit der Option „Anforderungen für erhöhte Rechte automatisch ablehnen“ wird die Rechteerhöhung für Standardbenutzer verweigert und ein entsprechender Fehler angezeigt. Falls Standardbenutzer ihre Rechte erhöhen dürfen, kann dies mit der Option „Aufforderung zur Eingabe der Anmeldeinformationen“ erreicht werden. Benutzer erhalten dabei die Möglichkeit, Benutzernamen und Kennwort eines Administratorenkontos einzugeben und so erhöhte Rechte zu erhalten. Standardeinstellungen: „Anforderungen für erhöhte Rechte automatisch ablehnen“ Empfohlene Einstellung: Für Unternehmen macht die Option „Anforderungen für erhöhte Rechte automatisch ablehnen“ Sinn, weil dadurch Standardbenutzer keine Möglichkeit haben, ihre Rechte zu erhöhen. Administratoren melden sich unter Windows Vista grundsätzlich mit Administratorenkonten an und benötigen dieses Recht – weil es nur für Standardbenutzer Gültigkeit hat – daher nicht.

Verhalten der Benutzeraufforderung mit erhöhten Rechten für Administratoren im Administratorbestätigungsmodus

Diese Richtlinie legt fest, wie Windows Vista bei Benutzern mit Administratorenrechten reagiert, wenn für einen bestimmten Prozess (z.B. Konfiguration der Windows-Firewall) erhöhte Rechte notwendig sind. Mit der Option „Erhöhte Rechte ohne Eingabeaufforderung“ werden dem Benutzer die erhöhten Rechte ohne weiteren Eingriff erteilt, wodurch aber die Systemsicherheit beeinträchtigt werden könnte. Die Option „Aufforderung zur Eingabe der Zustimmung“ zeigt dem Benutzer beim Erhöhungsprozess ein Fenster, über das er seine Zustimmung geben muss („Fortsetzen“). Dieses Fenster wird optimal mittels sicherem Desktop angezeigt, sodass dieser Prozess nicht automatisiert oder ohne Wissen des Benut-

25

1 Benutzerkontensteuerung zers bestätigt werden kann. Bei Aktivierung der Option „Aufforderung zur Eingabe der Anmeldeinformationen“ wird der Benutzer aufgefordert, die Anmeldeinformationen eines entsprechenden Administratorenkontos einzugeben, selbst dann, wenn das aktuell verwendete Konto über Administrationsrechte verfügt. Standardeinstellungen: „Aufforderung zur Eingabe der Zustimmung“ Empfohlene Einstellung: Aus Sicherheitsgründen sollte die Erhöhung von Rechten immer manuell durch den Benutzer bestätigt werden. Ob dies lediglich eine manuelle Bestätigung ist („Fortsetzen“) oder eine erneute Eingabe der Anmeldeinformationen, spielt grundsätzlich keine Rolle. Aus Gründen der Anwendbarkeit ist die Option „Aufforderung zur Eingabe der Zustimmung“ eine gute Wahl.

Im privaten Umfeld weichen einige Standardeinstellungen der aufgeführten Richtlinien ab und sind somit nicht genau gleich wie im Firmenumfeld.

Wechseln Sie in einer Gruppenrichtlinie zum Pfad Computerkonfiguration\ Administrative Vorlagen\Windows-Komponenten\Benutzerschnittstelle für Anmeldeinformationen. Dort steht noch einmal eine interessante Richtlinie für die Verwaltung der Benutzerkontensteuerung zur Verfügung.

Abbildung 1.19 Steuerung über Gruppenrichtlinien, Teil 2

26

1.6 Deaktivieren der Benutzerkontensteuerung Richtlinie

Beschreibung

Bei Ausführung mit erhöhten Rechten Administratorenkonten auflisten

Wenn Rechte erhöht werden müssen, ist unter Umständen (je nach Konfiguration der Benutzerkontensteuerung) die explizite Anmeldung mit einem Administratorenkonto erforderlich. Wenn diese Richtlinie aktiviert ist, werden verfügbare lokale Administratorenkonten aufgelistet. Bei deaktivierter Richtlinie kann kein Konto ausgewählt werden, und Benutzername sowie Kennwort müssen explizit eingegeben werden. Standardeinstellungen: Deaktiviert Empfohlene Einstellung: Diese Einstellung sollte deaktiviert werden, sodass keine Informationen über lokale Administratorenkonten preisgegeben werden. Benutzer müssen in diesem Fall nicht nur das Kennwort eines Kontos kennen, sondern auch den Benutzernamen.

1.6

Deaktivieren der Benutzerkontensteuerung Warum überspringen Sie diesen Abschnitt nicht einfach? Sie sollten die Benutzerkontensteuerung unbedingt aktiviert lassen, wenn Sie einen sicheren, bequemen Betrieb von Windows Vista anstreben. Aber bitte, wenn Sie das nicht möchten, lesen Sie weiter ... Die Benutzerkontensteuerung kann auf verschiedene Arten deaktiviert werden. Auch wenn Sie das nicht wirklich tun sollten, stehen verschiedene Möglichkeiten zur Verfügung. Eine Möglichkeit haben Sie bereits kennengelernt: die Konfiguration der Benutzerkontensteuerung mithilfe von Gruppenrichtlinien. Dadurch lassen sich einzelne Komponenten (beispielsweise nur die Virtualisierung von Dateien und Registrierungseinträgen) oder aber die gesamte Funktion vollständig deaktivieren. Eine weitere Möglichkeit der Deaktivierung bietet das Tool „Msconfig.exe“. Dies lässt sich einfach über das Startmenü ausführen. Über den Reiter „Tools“ stehen verschiedene Werkzeuge zur Verfügung, unter anderem „Benutzerkontensteuerung deaktivieren“. Markieren Sie diesen Eintrag, und klicken Sie auf die Schaltfläche Starten. Nach Ausführung des Befehls muss der Rechner neu gestartet werden. Über den gleichen Weg lässt sich die Funktion mit dem Werkzeug „Benutzerkontensteuerung aktivieren“ wieder starten (was mir persönlich wiederum weitaus besser gefällt).

27

1 Benutzerkontensteuerung

Abbildung 1.20 Benutzerkontensteuerung mit „msconfig.exe“ deaktivieren

Eine andere Möglichkeit bietet die lokale Benutzerverwaltung. Wechseln Sie dazu über Systemsteuerung, Benutzerkonten, Benutzerkonten zur Benutzerverwaltung, und wählen Sie den Menüpunkt Benutzerkontensteuerung ein- oder ausschalten. Löschen Sie die Option „Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen“. Auch hier ist ein Neustart notwendig, um die Einstellung zu übernehmen.

Abbildung 1.21 Benutzerkontensteuerung über die Benutzerverwaltung deaktivieren

28

1.7 Für Entwickler

1.7

Für Entwickler Für Anwendungsentwickler ist die Benutzerkontensteuerung ebenfalls entscheidend. Wenn Anwendungen für den Betrieb unter Windows Vista entwickelt werden, sollten diese unbedingt von Anfang an Vista-konform programmiert werden. Dazu hat Microsoft einen Guide veröffentlicht, der über folgende URL heruntergeladen werden kann: http://www.microsoft.com/downloads/details.aspx?familyid=ba73b169-a648-49af-bc5ea2eebb74c16b&displaylang=en

1.8

Rückblick Nachdem wir uns die verschiedenen Bereiche angesehen haben, dürfte klar sein, dass ein Arbeiten unter Windows Vista mit Standardbenutzerrechten durchaus realistisch ist. Falls Benutzer für Aktivitäten mehr Rechte benötigen, können diese bei Bedarf erhöht werden. Wenn Anwendungen wegen mangelnder Rechte nicht oder nicht vollständig ausgeführt werden können, kommt die Virtualisierung von Windows Vista zum Zug und ermöglicht mithilfe von Umleitungen in einer Virtual Store ein korrektes Ausführen. Die Benutzerkontensteuerung dient also nicht ausschließlich der Erhöhung der Sicherheit, sondern auch der Bequemlichkeit. Ein Arbeiten mit einem Betriebssystem soll ja nicht nur sicher sein, sondern auch praktisch. Mithilfe der Benutzerkontensteuerung ist Microsoft hier ein optimaler Mix gelungen. Für höchstmögliche Sicherheit sollte die Benutzerkontensteuerung unbedingt aktiviert bleiben und anhand der Empfehlungen in diesem Kapitel konfiguriert werden. Letztlich stellt sich aber dennoch die Frage, ob Administratoren tatsächlich nur ein einziges Konto verwenden (das durch den Split-Token-Prozess geschützt wird) oder besser doch mit zwei Konten arbeiten sollten (jeweils eines davon als Standardbenutzer konfiguriert, das für die tägliche Arbeit verwendet wird, und ein zweites mit Administratorenrechten, das ausschließlich für die Rechteerhöhung eingesetzt wird). Für höchstmögliche Sicherheit sollten Administratoren zwei Konten nutzen. Das macht die Rechteerhöhung zwar ein bisschen aufwendiger, weil jeweils Benutzername und Kennwort des Administratorenkontos eingegeben werden müssen, aber dafür erreichen Sie damit höchstmögliche Sicherheit.

29

2 Integritätskontrolle mit Verbindlichkeitsstufen Ein mit Vista (zumindest in der Microsoft-Welt) neu eingeführtes Konzept stellen die sog. Verbindlichkeitsstufen dar. Nebst vielen anderen Sicherheitsfunktionen ist diese wohl einer der aufsehenerregendsten, aber gleichzeitig auch unbekanntesten. Viele Administratoren merken anhand verweigerter Rechte, dass sie unter Windows Vista möglicherweise nicht mehr Vollzugriff auf alle Objekte besitzen, und das liegt unter anderem (aber nicht ausschließlich) an diesen neu eingeführten Verbindlichkeitsstufen.

2.1

Der neue Schutzmechanismus von Windows Vista Was aber hat es mit der neuen Sicherheitsfunktion genau auf sich? Unter Windows Vista wurden vier Basis-Verbindlichkeitsstufen eingeführt (und noch zwei erweiterte), um Objekte, Prozesse oder Benutzer unterzubringen. Das bedeutet, dass alle Objekte einer dieser Verbindlichkeitsstufen angehören. Die Idee hinter dem Konzept ist, dass Objekte einer Stufe nur begrenzten oder gar keinen Zugriff auf Objekte höher gelegener Stufen erhalten. So wird das Betriebssystem zusätzlich gehärtet, weil es dadurch viel schwieriger wird, unbemerkt eine Anwendung wie beispielsweise Malware oder einen Virus in einem System zu integrieren. Benutzer und Anwendungen arbeiten dabei auf einer verhältnismäßig tiefen Stufe, wobei wichtige Prozesse des Betriebssystems auf höheren Stufen arbeiten und so vor unbefugtem Zugriff oder vor Manipulation geschützt sind. Das detaillierte Verhalten, wie auf Objekte oder Prozesse höherer Verbindlichkeitsstufen zugegriffen werden kann, lässt sich konfigurieren. Dazu kommen wir allerdings ein bisschen später. Zusammenfassend könnte man sagen, dass die neue Funktion nebst den bekannten NTFSRechten eine weitere (mächtige) Sicherheitsschicht einführt, um das Betriebssystem vor unbefugtem Zugriff zu schützen – diese geht aber bedeutend weiter, weil nicht nur Objekte wie Dateien, Ordner oder Registrierungseinträge, sondern auch Prozesse und Benutzer davon betroffen sind. Wie aber werden Zugriffe jetzt tatsächlich realisiert? Welche der beiden Sicherheitsstufen hat denn nun Vorrang, und wie werden die effektiven Rechte für ei-

31

2 Integritätskontrolle mit Verbindlichkeitsstufen nen Zugriff berechnet? Das ist relativ einfach: Bevor NTFS-Rechte überhaupt verifiziert werden, ist der Zugriff von den Verbindlichkeitsstufen und deren Richtlinien abhängig. Bei einem Zugriff wird zuerst geprüft, ob sich das Zielobjekt (z.B. eine Datei) auf der gleichen oder einer tieferen Ebene wie das Quellobjekt (z.B. ein Prozess) befindet. Ist dies der Fall, ist seitens der Verbindlichkeitsstufen keine Einschränkung vorhanden, und es werden anschließend die konfigurierten NTFS-Rechte überprüft, um den detaillierten Zugriff zu steuern. Befindet sich das Zielobjekt hingegen auf einer höheren Verbindlichkeitsstufe als das Quellobjekt, ist nur ein eingeschränkter Zugriff (oder unter Umständen gar kein Zugriff) möglich. Wenn beispielsweise auf ein Objekt einer höheren Stufe zugegriffen werden soll, kann es sein, dass kein Schreibzugriff darauf möglich ist, obwohl das eigene Benutzerkonto über volle Zugriffsrechte verfügt. Alle Objekte werden mit einer Richtlinie versehen, die beschreibt, welche Möglichkeiten bestehen, um auf andere Objekte höherer Stufen zuzugreifen. Aber dazu gleich mehr.

2.2

Verfügbare Verbindlichkeitsstufen und Richtlinien Windows Vista kennt folgende Verbindlichkeitsstufen für die Zuweisung zu Objekten: Niedrig Auf dieser Ebene läuft beispielsweise der Prozess des Internet Explorers (sofern der geschützte Modus aktiviert ist). Das bedeutet, dass jegliche Aktivitäten des Browsers, inkl. Subprozesse, auf dieser Stufe ausgeführt werden. Da Prozesse einer Stufe standardmäßig nicht über Schreibrechte auf Objekte der höheren Stufen verfügen, kann demnach Code, der über eine Webseite ausgeführt werden soll, auf dem lokalen System keinen Schaden anrichten. Mittel Die meisten Objekte unter Windows Vista werden auf dieser Verbindlichkeitsstufe ausgeführt. Dies gilt auch für Standardbenutzerkonten. Hoch Wenn ein Standardbenutzer seine Rechte erhöht, wird auch die Verbindlichkeitsstufe für den jeweiligen Prozess erhöht, und zwar auf „Hoch“. System Auf dieser Verbindlichkeitsstufe laufen systemnahe Prozesse und Dienste, die mit einem der Konten „Lokales System“ oder „Lokaler Dienst“ gestartet sind. Effektiv existieren noch zwei weitere Stufen, die allerdings fast nirgends sichtbar sind. Es handelt sich um folgende: Nicht vertrauenswürdig Alle anonymen Aktivitäten werden auf dieser Stufe ausgeführt. Dabei handelt es sich um die tiefstmögliche Verbindlichkeitsstufe, die Windows Vista kennt.

32

2.3 Verbindlichkeitsstufen für Objekte Installer Installations- und Deinstallationsprozesse werden teilweise (nicht immer) auf dieser Ebene ausgeführt. Das kann notwendig sein, um systemnahe Software aus dem System zu deinstallieren. Windows Vista kennt folgende Richtlinien der Verbindlichkeitsstufen für die Zuweisung an Objekte: No Read Up No Write Up No Execute Up Die Richtlinie „No Read Up“ auf einem Objekt verhindert, dass dieses Lesevorgänge auf höher gelegene Objekte durchführen kann. „No Write Up“ hingegen ermöglicht Lesezugriffe, allerdings wird das Schreiben auf Objekte höherer Stufen verhindert. „No Execute Up“ schlussendlich verhindert, dass ausführbare Dateien gestartet werden können. In den meisten Fällen ist ein Objekt für die Richtlinie “No Write Up” konfiguriert. Das bedeutet, dass Objekte keinen Schreibzugriff auf andere Objekte höherer Verbindlichkeitsstufen haben. Sie können wohl Informationen lesen, diese aber nicht verändern. Für viele Prozesse hingegen gilt die Richtlinie „No Read Up“, sodass diese nicht in der Lage sind, Informationen von Objekten auf höheren Stufen auszulesen. Diese Richtlinien lassen sich bei Bedarf natürlich beliebig verändern. Was bedeutet das jetzt aber in Zusammenhang mit NTFS-Rechten? Welchen Einfluss haben diese auf effektive Objektzugriffsrechte? Die effektiven Rechte auf Objekte werden aus einer Kombination von Verbindlichkeitsstufen, den eben erwähnten Richtlinien und den konfigurierten NTFS-Rechten ermittelt. Bei einem Zugriff werden immer zuerst die Verbindlichkeitsstufen und die verfügbaren Richtlinien geprüft. Wenn beispielsweise ein Zugriff auf ein Objekt einer höheren Stufe erfolgt und die Richtlinie „No Write Up“ Gültigkeit hat, ist der Schreibzugriff grundsätzlich eingeschränkt. Erst jetzt werden die NTFS-Rechte des Objekts geprüft. Selbst wenn der Benutzer, der auf das Objekt zugreifen will, über volle Zugriffsrechte (Vollzugriff) verfügt, wird er das Objekt nicht verändern können, weil die Richtlinie diesen Vorgang nicht zulässt. Kennen Sie schon die Situation, dass Sie Objekte auch als Administrator nicht löschen konnten? Das kann unter anderem daran liegen, dass Sie von Verbindlichkeitsstufen bzw. der dazu konfigurierten Richtlinien eingeschränkt worden sind.

2.3

Verbindlichkeitsstufen für Objekte Schauen wir uns zuerst Objekte wie Dateien, Ordner und Registrierungsschlüssel an. Alle Objekte, die Windows Vista sichern kann (Objekte, die sich auf einer NTFS-Partition befinden, aber auch Registrierungsschlüssel), verfügen über eine sog. SACL, eine „System Access Control List“. Diese wurde in früheren Windows-Versionen ausschließlich ver-

33

2 Integritätskontrolle mit Verbindlichkeitsstufen wendet, um die Überwachung eines Objekts, beispielsweise erfolgreiche Löschvorgänge in einem Ordner, auszuzeichnen. Den gleichen Bereich eines Objekts verwendet Windows Vista nun, um die Verbindlichkeitsstufe eines Objekts zu speichern. Wichtig hierbei ist aber zu wissen, dass die Verbindlichkeitsstufe in der SACL über die grafische Oberfläche nicht angezeigt werden kann – dafür sind spezielle Werkzeuge notwendig. Unter Windows Vista gehören die meisten Objekte der Verbindlichkeitsstufe „Mittel“ an. Da Vista allerdings sehr viele Objekte verwaltet, ist nicht jedes einzelne Objekt für diese Verbindlichkeitsstufe konfiguriert worden, das würde einen zu großen Aufwand mit sich bringen, besonders auch dann, wenn Service Packs o.Ä. eingespielt werden. Vielmehr weist Windows Vista einem Systemobjekt, das keine explizit konfigurierte Verbindlichkeitsstufe aufweist, immer automatisch die Stufe „Mittel“ zu. Andere Objekte des Betriebssystems verfügen über eine konfigurierte Stufe, z.B. explizit „niedrig“ oder explizit „hoch“. Für diese Objekte wird die zugewiesene Stufe – wie bereits erwähnt – in der SACL gespeichert. Mithilfe verschiedener Tools kann die Verbindlichkeitsstufe eines Objekts angezeigt werden. Die beste Übersicht bietet das Tool „Accesschk.exe“ von Microsoft (ehemals Sysinternals), das zum freien Download auf der Microsoft-Webseite zur Verfügung steht. Mit diesem Tool können die Verbindlichkeitsstufen von Dateien, Ordnern und Registrierungsschlüsseln angezeigt werden. Ebenfalls angezeigt werden die konfigurierten Richtlinien für die jeweiligen Objekte.

Abbildung 2.1 “Accesschk.exe“ zur Anzeige von Verbindlichkeitsstufen

Ein anderes Tool für die Darstellung von Verbindlichkeitsstufen ist „Icacls.exe“, das mit Windows Vista mitgeliefert wird. Der Nachteil dieses Werkzeugs ist allerdings, dass bei

34

2.3 Verbindlichkeitsstufen für Objekte Systemobjekten, die keine explizit konfigurierte Verbindlichkeitsstufe haben (und demnach der Stufe „Mittel“ angehören), keine Verbindlichkeitsstufe angezeigt wird. Das ist ein bisschen verwirrend.

Abbildung 2.2 „Icacls.exe“ zur Anzeige von Verbindlichkeitsstufen

Verbindlichkeitsstufen von Objekten können bei Bedarf angepasst werden. Allerdings ist bei diesem Prozess Vorsicht geboten, weil durch Fehlmanipulation einerseits das Betriebssystem einem erhöhten Risiko ausgesetzt wird, andererseits aber auch Funktionalität beeinträchtigt werden könnte. Wenn – aus welchem Grund auch immer – die Verbindlichkeitsstufe eines Objekts verändert werden muss, sollte dieser Vorgang zuvor ausführlich getestet werden. Wie lässt sich aber nun die Stufe eines Objekts ändern? Dazu benötigen Sie einerseits Werkzeuge, beispielsweise „icacls.exe“ von Microsoft. Andererseits wird aber auch die entsprechende Berechtigung benötigt (die standardmäßig keinem Konto zugewiesen ist!), um Verbindlichkeitsstufen anzupassen. Schauen wir uns zuerst die Berechtigung an: 1. Starten Sie den lokalen GPO-Editor (gpedit.msc). Alternativ lässt sich dieses Recht natürlich auch über einen Domänen-GPO konfigurieren. 2. Wechseln Sie zum Abschnitt Computerkonfiguration\Windows-Einstellungen\ Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten. 3. Editieren Sie die Richtlinie „Verändern einer Objektbezeichnung“. Fügen Sie der Richtlinie eine beliebige Gruppe hinzu, die das Recht zur Änderung von Verbindlichkeitsstufen erhalten soll. Übernehmen Sie anschließend die neuen Richtlinieneinstellungen.

35

2 Integritätskontrolle mit Verbindlichkeitsstufen

Abbildung 2.3 Rechtezuweisung für das Ändern von Verbindlichkeitsstufen

Nachdem Sie nun das Recht besitzen, Verbindlichkeitsstufen zu ändern, möchten wir dies auch gleich testen. Damit keine Systemdateien beeinträchtigt werden, erstellen Sie dazu eine neue Datei. 1. Erstellen Sie auf dem lokalen Windows Vista-Gerät eine neue Datei, und zeigen Sie anschließend mit dem Tool „Accesschk.exe“ von Microsoft die Verbindlichkeitsstufe der Datei an. Wie für alle Objekt wird auch der neuen Datei die Stufe „Mittel“ zugewiesen.

Abbildung 2.4 Datei erstellen und Verbindlichkeitsstufe anzeigen

2. Ändern Sie nun die Stufe mithilfe des Tools „icacls.exe“ auf „Hoch“. Dabei ist es wichtig, dass der Command Prompt, in dem der Befehl ausgeführt wird, im Administratorenmodus gestartet wird (Rechtsklick, „Als Administrator ausführen). Nur so lässt sich die Stufe auch tatsächlich auf „Hoch“ setzen. Wird der Befehl als Standardbenutzer ausgeführt, schlägt er fehl, weil dieser auf der Stufe „Mittel“ arbeitet und dadurch kein Schreibrecht auf Objekte höherer Stufen besitzt. Im folgenden Screenshot wird

36

2.3 Verbindlichkeitsstufen für Objekte sowohl der fehlgeschlagene als auch der erfolgreiche Versuch des Erhöhungsprozesses gezeigt.

Abbildung 2.5 “Icacls.exe“ zur Erhöhung von Verbindlichkeitsstufen (Fehlschlag und Erfolg)

3. Zeigen Sie nach erfolgreicher Erhöhung die neue Verbindlichkeitsstufe des Objekts an. Diese ist jetzt auf „Hoch“ festgelegt.

Abbildung 2.6 Anzeigen der neuen Verbindlichkeitsstufe

4. Versuchen Sie im letzten Schritt, die Datei über den Windows Explorer zu löschen. Sie werden bemerken, dass für Löschung der Datei die Rechte des Standard-Tokens nicht ausreichen werden (weil Standardbenutzer auf der Stufe „Mittel“ arbeiten) und daher erhöht werden müssen. Nur wenn sich der Benutzer auch auf der hohen Verbindlichkeitsstufe befindet, kann die Datei tatsächlich gelöscht werden. Ein Standardbenutzer könnte diese Datei nicht löschen, selbst dann nicht, wenn er über volle Zugriffsrechte verfügt. Erinnern Sie sich? Die Richtlinie „No Write Up“ verhindert genau das.

37

2 Integritätskontrolle mit Verbindlichkeitsstufen

Abbildung 2.7 Rechteerhöhung für das Löschen einer Datei

Verbindlichkeitsstufen haben – wie in diesem Beispiel gezeigt – Vorrang vor NTFSBerechtigungen. Wenn demnach ein Benutzer auf Objekte höherer Verbindlichkeitsstufen zugreifen will, spielen die NTFS-Rechte erst in zweiter Instanz bzw. gar keine Rolle, weil der Zugriff evt. bereits durch die höhere Verbindlichkeitsstufe bzw. die konfigurierte Richtlinie blockiert wird.

2.4

Verbindlichkeitsstufen für Prozesse Widmen wir uns nun den Prozessen. Auch diese werden je einer Verbindlichkeitsstufe zugeordnet und haben daher nur beschränkte Rechte für den Zugriff auf Objekte und andere Prozesse. Bestes Beispiel für einen solchen Prozess ist „Iexplore.exe“, der Prozess des Internet Explorers. Sofern der Internet Explorer 7 im geschützten Modus ausgeführt wird (was das genau bedeutet, werden wir uns später anschauen), wird der Prozess in der Stufe „Niedrig“ ausgeführt. Alle Funktionen des Browsers, beispielsweise Subprozesse oder sonstige Aktivitäten, werden dadurch auch in der Stufe „Niedrig“ ausgeführt. Da fast alle Dateien, Prozesse usw. von Windows Vista mindestens der Verbindlichkeitsstufe „Mittel“ zugewiesen sind und die Richtlinie „Write Up“ Schreibprozesse auf Objekte höherer Stufen verhindert, bedeutet dies gleichzeitig, dass Malware, die möglicherweise über den Internet Explorer heruntergeladen wird und installiert werden soll (natürlich ohne dass der Nutzer etwas davon bemerkt), nicht auf dem System installiert werden kann, weil die Setup-Routine nicht auf Betriebssystemobjekte zugreifen kann. Das Betriebssystem genießt demnach gegenüber dem Internet einen sehr hohen Schutz. Man spricht beim geschützten Modus des Internet Explorers daher auch von einer sog. „Sandbox“, weil der Prozess keine Möglichkeit hat, den isolierten Bereich zu verlassen. Wenn durch Benutzerintervention eine Tätigkeit ausgeführt wird, bei der die „Sandbox“ verlassen werden muss, beispielsweise wenn eine Datei von einer Webseite gezielt gespeichert werden soll, wird dies über einen zweiten Prozess erledigt, der für den aktuellen Vorgang der Stufe „Mittel“ zugeordnet wird und so mehr Möglichkeiten hat.

38

2.4 Verbindlichkeitsstufen für Prozesse Wenn der geschützte Modus nicht aktiviert ist, wird der Prozess „Iexplore.exe“ auf der Stufe „Mittel“ ausgeführt, was wiederum bedeutet, dass das lokale Betriebssystem nicht mehr den gleichen Schutz genießt. Aus diesem Grund sollte der Internet Explorer unbedingt immer im geschützten Modus betrieben werden. Mit dem Tool „Process Explorer“ von Microsoft (ehemals Sysinternals) lässt sich die Verbindlichkeitsstufe von Prozessen anzeigen. Das Tool ist kostenfrei verfügbar und kann über die Microsoft-Webseite heruntergeladen werden.

Abbildung 2.8 Internet Explorer im geschützten Modus mit niedriger Verbindlichkeitsstufe

Andere, besonders systemnahe Prozesse werden in der Verbindlichkeitsstufe „System“ ausgeführt. Dadurch genießen sie vor ungewünschten Eingriffen einen hohen Schutz des Betriebssystems. Folgender Screenshot zeigt als Beispiel den Dienst „Aufgabenplanung“, dessen Prozess in dieser Verbindlichkeitsstufe ausgeführt wird.

39

2 Integritätskontrolle mit Verbindlichkeitsstufen

Abbildung 2.9 Der Dienst „Aufgabenplanung“ in der Verbindlichkeitsstufe „System“

2.5

Verbindlichkeitsstufen von Benutzerkonten Benutzerkonten sind auch einer Verbindlichkeitsstufe zugeordnet. Ein normaler Benutzer mit Standardrechten arbeitet dabei auf der Stufe „Mittel“. Ein Konto mit administrativen Rechten standardmäßig auch, kann aber bei Bedarf die Rechte und dadurch auch die Verbindlichkeitsstufe auf „Hoch“ erhöhen (siehe Benutzerkontensteuerung). Wo aber wird die Information der Verbindlichkeitsstufe bei Benutzern gespeichert? Die Speicherung erfolgt im Token des Benutzer, das bei der Anmeldung generiert wird. Das Token beinhaltet demnach neben der SID des Benutzerkontos, den SIDs der Gruppen, denen das Konto zugeordnet ist, und den Privilegien des Benutzers nun auch die Verbindlichkeitsstufe. Bei einem Administrator, der bekanntlich über zwei Tokens verfügt (siehe Benutzerkontensteuerung, Split-Token-Prozess), weisen beide Tokens eine Angabe der Verbindlichkeitsstufe auf. Das Standard-Token weist die Verbindlichkeitsstufe „Mittel“ auf, das Admin-Token die Stufe „Hoch“. Mithilfe des Tools „Whoami.exe“, das mit Windows Vista mitgeliefert wird, lässt sich die Stufe eines Benutzerkontos darstellen. Starten Sie dazu die Eingabeaufforderung im normalen Modus, und führen Sie den Befehl aus.

40

2.5 Verbindlichkeitsstufen von Benutzerkonten

Abbildung 2.10 Auszug eines Benutzer-Tokens (Standard-Token)

Es ist ersichtlich, dass der Benutzer auf der mittleren Verbindlichkeitsstufe arbeitet. Anders sieht es aus, wenn die Eingabeaufforderung im Administratorenmodus gestartet wird (Rechtsklick, „Als Administrator ausführen“).

Abbildung 2.11 Auszug eines Benutzer-Tokens (Admin-Token)

41

2 Integritätskontrolle mit Verbindlichkeitsstufen

2.6

Rückblick Da Sie nun wissen, was Verbindlichkeitsstufen sind und wie diese eingesetzt werden, hilft Ihnen das bestimmt, gewisse Vorgänge unter Windows Vista besser verstehen zu können. Da Verbindlichkeitsstufen tatsächlich höhere Priorität bei Objektzugriffen als beispielsweise NTFS-Rechte haben, kann das zu interessanten Konstellationen führen. So kann es beispielsweise sein, dass Objekte nicht gelöscht werden können, obwohl das eigene Benutzerkonto über volle Zugriffsrechte oder Besitzrechte verfügt. Das erklärt auch, warum Administratoren teilweise bei ihrer Tätigkeit auf die Fehlermeldung „Zugriff verweigert“ stoßen. Da Sie jetzt das Konzept der Verbindlichkeitsstufen kennen, können Sie solche Fälle jetzt auch besser interpretieren und nachvollziehen. Änderungen an den Verbindlichkeitsstufen sollten nur in Ausnahmefällen und nach ausgeprägten Tests durchgeführt werden. Stellen Sie sicher dass die Sicherheit von Windows Vista bei Änderungen nicht beeinträchtigt wird. Schließlich wollen Sie ein sicheres Betriebssystem – oder nicht?

42

3 Internet Explorer 7 Die Programme, die nicht nur in Firmenumgebungen zu den kritischsten gehören, sind Browser. Das Internet ist allgegenwärtig, und Anwender nutzen es für ihre tägliche Arbeit. Dabei verbinden sich Nutzer mit unbekannten Webseiten, die unbekannten Code ausführen, und können dabei nur in den seltensten Fällen entscheiden, ob es sich bei der besuchten Webseite um ein vertrauenswürdiges Ziel handelt oder nicht. Demzufolge müssen Browser verschiedene Sicherheitsmaßnahmen anbieten, die Benutzer bei Entscheidungen unterstützen. Gleichzeitig benötigt man technische Maßnahmen, um den Schutz des Browsers zu gewährleisten sowie das darunterliegende Betriebssystem und die auf dem Rechner gespeicherten Informationen zu schützen.

3.1

Umfassender Schutz durch mehrere Sicherheitsschichten Mit dem Internet Explorer 7 hat Microsoft eine neue Version des verbreiteten Browsers auf den Markt gebracht, der unter anderem eine Reihe neuer und sehr wichtiger Sicherheitsfunktionen beinhaltet. Die Sicherheit des neuen Internet Explorers ist mehrschichtig und macht es Angreifern – oder anders gesagt Webseiten, die versuchen, Anwender zu täuschen oder schädlichen Code zu injizieren – schwer, ihr Ziel zu erreichen. Das Sicherheitskonzept des neuen Internet Explorers umfasst sieben Sicherheitsebenen und präsentiert sich wie folgt:

43

3 Internet Explorer 7

Abbildung 3.1 Sieben Sicherheitsebenen

Der Internet Explorer 7 ist auch für ältere Microsoft-Betriebssysteme verfügbar. Dort allerdings stehen die beiden Schichten „Dateiausführungsverhinderung“ und „Geschützter Modus“ nicht zur Verfügung, weil wichtige Komponenten im Betriebssystem nicht vorhanden sind.

Die ersten drei der aufgeführten Schichten sollen dem Benutzer helfen, die richtigen Entscheidungen zu treffen und ihn vor sog. „Social Attacks“ schützen, bei denen es darum geht, ihn zu täuschen. Falls ein Benutzer trotzdem falsche Entscheidungen trifft, stehen weitere vier Sicherheitsschichten bereit, die technologisch verhindern sollen, dass ein Gerät erfolgreich kompromittiert wird. Auf den folgenden Seiten werden die einzelnen Schichten detailliert beschrieben.

3.1.1

Schutzschicht 1 – Adressleistensicherheit und IDNUnterstützung

Mithilfe der Adressleistensicherheit wird erzwungen, dass die Adressleiste im Browser immer angezeigt wird. Somit ist es nicht mehr möglich, diese auszublenden und Benutzer auf eine unbekannte Webseite umzuleiten, ohne dass dies aufgrund der URL bemerkt wird. Diese Sicherheitsfunktion verhindert sog. „Popup-Phishing-Attacks“, bei denen neue Webseiten ohne Adressleiste eingeblendet werden und die den Benutzer in der Hoffnung belassen, sich immer noch auf der gleichen Webseite zu befinden. Mithilfe von IDN (International Domain Name) wird sichergestellt, dass eine URL nicht aus Zeichen unterschiedlicher Sprachen bestehen darf. Mit dieser Technologie ist es beispielsweise möglich, Schriftzeichen einer anderen Sprache einzubauen, die optisch nicht von der eigenen Sprache zu unterscheiden sind und so den Benutzer auf eine Webseite umleiten, die nicht dem gewünschten Ziel entspricht. Der Benutzer selber würde die Umleitung aufgrund der URL nicht bemerken (da diese genau gleich, aber mit teilweise fremden Zeichen dargestellt wird).

44

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten

3.1.2

Schutzschicht 2 – Sicherheitsstatusanzeige, Zertifikatsverwaltung und Phishing-Filter

Die Adressleiste wird im Internet Explorer 7 gleichzeitig als Statusanzeige verwendet. Mithilfe von fünf unterschiedlichen Status wird dem Benutzer farblich dargestellt, welchen Status die Webseite, die er gerade besucht, aufweist. Bei den folgenden Beispielen handelt es sich um frei gewählte Webseiten. Es ist möglich, dass der Status der einzelnen Webseiten sich mit der Zeit ändert und mit den Angaben im Buch nicht mehr übereinstimmt.

SSL mit grüner Statusanzeige Bei diesem Status handelt es sich um den höchstmöglichen Sicherheitsstatus, den eine Webseite aufweisen kann. Die Kommunikation mit der Webseite findet in diesem Fall verschlüsselt statt (HTTPS), und das Zertifikat auf der Webseite ist erfolgreich überprüft worden. Erfolgreich bedeutet, dass das Zertifikat noch gültig ist (in Bezug auf das Datum), die eingegebene URL im Browser mit derjenigen der Zertifikats übereinstimmt und dem Aussteller der Zertifikats vertraut wird. Windows Vista kennt dazu eine Liste von vertrauenswürdigen Ausstellern, die den jeweiligen Antragstellern eine Identität bestätigen. Der grüne Status wird aber tatsächlich nur dann angezeigt, wenn es sich beim Zertifikat um ein sog. EV-Zertifikat (Extended Validation) handelt. Anders als bei normalen digitalen Zertifikaten wird dabei die Identität eines Antragstellers intensiver und anhand mehrerer Kriterien geprüft, um eine einwandfreie Identität zu garantieren. Die Firma PayPal verwendet beispielsweise bereits ein neues EV-Zertifikat auf ihrer Webseite (https://www.paypal.com), und viele andere Anbieter von Online-Transaktionen werden in Kürze folgen. Bei EV-Zertifikaten wird jeweils direkt in der Statusanzeige angezeigt, für wen das Zertifikat ausgestellt ist und von welchem Aussteller es stammt.

Abbildung 3.2 SSL mit grüner Statusanzeige und Darstellung des Besitzers (PayPal Inc.)

Abbildung 3.3 SSL mit grüner Statusanzeige und Darstellung des Ausstellers (Verisign)

45

3 Internet Explorer 7 SSL mit weißer Statusanzeige Bei dieser Statusanzeige handelt es sich wie zuvor auch um eine Webseite, mit der die Kommunikation verschlüsselt stattfindet und deren Identität überprüft werden kann. Das Zertifikat der Webseite ist erfolgreich validiert worden und ist in allen Bereichen gültig. Allerdings handelt es sich bei diesem Status um normale digitale Zertifikate und nicht um EV-Zertifikate, was bedeutet, dass die Identitätsprüfung des Betreibers nicht mit den gleichen umfangreichen Prozessen erfolgt ist.

Abbildung 3.4 SSL mit weißer Statusanzeige

Weiße Statusanzeige Die meisten Webseiten, die Sie besuchen werden, verfügen über diesen Status. Die Identität der Webseite kann nicht überprüft werden (kein Zertifikat), und die Kommunikation wird nicht verschlüsselt (kein HTTPS). Allerdings ist das bei den meisten Webseiten auch nicht notwendig, solange keine sicheren Daten übertragen werden.

Abbildung 3.5 Weiße Statusanzeige ohne SSL

Gelbe Statusanzeige Internet Explorer 7 bringt eine neue Technologie, mit der Phishing-Webseiten, also Webseiten, die versuchen, an persönliche Informationen eines Nutzers zu kommen, zu erkennen sind. Um diese Webseites zu erkennen, gibt es verschiedene Methoden. Beispielsweise kann der Internet Explorer Webseiten online bei Microsoft prüfen lassen oder selber aufgrund von Charakteristiken eine Webseite als phishing-relevant einstufen. Falls eine Webseite aufgrund von bestimmten Charakteristiken als Phishing-Webseite eingestuft wird, wird die Adressleiste gelb eingefärbt. Die Kommunikation mit solchen Webseiten sollte sicherheitshalber abgebrochen werden.

Abbildung 3.6 Gelber Status einer Phishing-Webseite (aufgrund Charakteristiken erkannt)

46

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten Rote Statusanzeige Ein roter Status kann beispielsweise dann auftreten, wenn eine Webseite über ein ungültiges Zertifikat verfügt oder auf einer Liste mit bekannten Phishing-Webseiten aufgeführt ist. Die Kommunikation mit solchen Webseiten sollte sicherheitshalber abgebrochen werden.

Abbildung 3.7 Roter Status einer Phishing-Webseite (explizit geblockte Seite)

Abbildung 3.8 Roter Status einer Webseite mit Zertifikatsfehler

Zertifikatsanzeige in der Statusleiste Neben der Statusanzeige ist bei SSL-Webseiten jeweils ein Schlossobjekt sichtbar, über das einfach auf Details des jeweiligen Zertifikats zugegriffen werden kann. Dabei werden Informationen des Zertifikats in vereinfachter Form angezeigt.

Abbildung 3.9 Schlossobjekt und Zertifikatsanzeige

Erfahrene Benutzer haben die Möglichkeit, über die Option „Zertifikate anzeigen“ weitere Informationen zum Aussteller oder zu der Webseite zu bekommen.

47

3 Internet Explorer 7

Abbildung 3.10 Zertifikatsdetails

Der Phishing-Filter des Internet Explorers schützt Benutzer beim Bewegen im Internet vor Webseiten, die versuchen, den Benutzer mit verschiedenen Mitteln zu täuschen. Beispielsweise könnte eine Webseite versuchen, an persönliche Daten eines Nutzers zu kommen, und versucht, dies mit entsprechendem Code, der auf einer Arbeitsstation ausgeführt werden soll, zu realisieren. Solche Webseiten können vom Phishing-Filter erkannt und blockiert werden (gelbe oder rote Statusanzeige). Wie aber entscheidet der Internet Explorer, wann es sich um eine Phishing-Webseite handelt? Dafür wird ein mehrstufiges Konzept verwendet. Jeder Browser verfügt über eine lokale Liste mit vertrauenswürdigen Webseiten. Diese Liste umfasst mehrere Zehntausend Webseiten, wird regelmäßig aktualisiert und ist digital signiert und verschlüsselt auf der Arbeitsstation abgelegt. Wenn ein Benutzer auf eine solche Webseite zugreift, wird keine weitere Phishing-Prüfung durchgeführt. Ist eine URL nicht dabei, wird eine Online-Prüfung der Webseite durchgeführt. Dazu sendet der Browser den ersten Teil der URL (nicht die gesamte URL) an den „Microsoft URL Reputation Service“ (urs.microsoft.com). Wenn die Webseite in dieser Datenbank aufgeführt ist, wird der Benutzer entsprechend gewarnt. Microsoft arbeitet mit unterschiedlichen Partnern zusammen, um diese Datenbank regelmäßig mit Phishing-Webseiten zu aktualisieren. Gleichzeitig werden bestimmte Charakteristiken einer Webseite geprüft, um festzustellen, ob es sich um eine Phishing-Webseite handelt. Wie wird jetzt aber die Statusanzeige verändert?

48

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten Webseitenstatus

Beschreibung

Grün oder Weiß

Die angezeigte Webseite ist keine Phishing-Webseite (je nachdem, ob die Kommunikation verschlüsselt erfolgt oder nicht, wird der Status auf Grün oder Weiß gesetzt).

Gelb

Die angezeigte Webseite weist Charakteristiken einer PhishingWebseite auf, ist aber in keiner Liste von Phishing-Webseiten aufgeführt.

Rot

Die angezeigte Webseite ist explizit in einer Liste mit PhishingWebseiten aufgeführt.

Der Phishing-Filter kann ein- oder ausgeschaltet werden. Nicht erwähnt werden muss, dass er grundsätzlich aktiviert werden sollte, auch wenn dadurch der Zugriff auf Webseiten ein bisschen verzögert werden kann – wenn auch nur minimal. Die Aktivierung bzw. Deaktivierung erfolgt über die erweiterten Internetoptionen im Abschnitt „Sicherheit“.

Abbildung 3.11 Phishing-Filter ein- und ausschalten

49

3 Internet Explorer 7 Phishing-Filter-Einstellung

Beschreibung

Automatische Websiteprüfung ausschalten

Diese Einstellung deaktiviert den automatischen Phishing-Filter, sodass Webseiten, die angezeigt werden, nicht mehr überprüft werden. Allerdings haben Benutzer die Möglichkeit, Webseiten manuell zu überprüfen.

Automatische Websiteprüfung einschalten

Bei dieser Einstellung handelt es sich um die bevorzugte Auswahl. Der Phishing-Filter ist aktiv und prüft jede besuchte Webseite. Zudem ist eine manuelle Prüfung möglich.

Phishing-Filter deaktivieren

Der Phishing-Filter ist vollständig deaktiviert. Eine manuelle Prüfung von Webseiten ist nicht möglich.

Der Phishing-Filter kann auch über Gruppenrichtlinien konfiguriert werden und wird später in diesem Kapitel erläutert.

Die Einstellungen des Phishing-Filters können auch direkt über die Browseroberfläche vorgenommen werden.

Abbildung 3.12 Phishing-Filter-Einstellungen über die Browseroberfläche vornehmen

Über den Menüpunkt „Automatische Websiteprüfung ein-/ausschalten ...“ kann die automatische Prüfung aktiviert bzw. deaktiviert werden, ohne das ein Umweg über die erweiterten Internetoptionen notwendig ist.

50

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten

Abbildung 3.13 Phishing-Filter ein-/ausschalten

Sofern der Phishing-Filter nicht vollständig deaktiviert ist, haben Benutzer die Möglichkeit, jede besuchte Webseite explizit manuell zu prüfen. Dies erfolgt ebenfalls direkt über die Browseroberfläche und den Menüpunkt „Diese Webseite überprüfen“.

Abbildung 3.14 Webseite manuell überprüfen

Verdächtige Webseiten können bei Bedarf über den Menüpunkt „Diese Webseite melden“ angezeigt werden, damit sie ggf. – nach erfolgter Prüfung durch Microsoft – auf die Liste bekannter Phishing-Webseiten aufgenommen werden.

51

3 Internet Explorer 7

Abbildung 3.15 Webseite melden

Eine letzte Funktion in diesem Bereich stellt das sog. „Cross-Domain-Scripting“ dar, das vom Internet Explorer 7 nicht zugelassen wird. Diese Verweigerung soll die Zusammenarbeit von Skripten zwischen Webseiten unterschiedlicher Domänen verhindern und so dazu beitragen, dass nicht unbemerkt Code ausgeführt wird, der von anderen, unbekannten Quellen stammt.

3.1.3

Schutzschicht 3 – Warnung bei unsicheren Einstellungen

Beim Start des Internet Explorers wird jeweils die Konfiguration überprüft und der Benutzer bei unsicheren Einstellungen informiert. Es könnte sein, dass für den Besuch einer vertrauenswürdigen Webseite eine Einstellung an der Sicherheitskonfiguration des Browsers vorgenommen werden muss, um diese erfolgreich anzeigen zu können. Solange sich Benutzer auf genau dieser Webseite befinden, mag die Einstellung, welche die Sicherheit des Browsers beeinträchtigt, kein Problem darstellen. Das Problem liegt allerdings darin, dass Benutzer vergessen, solche Einstellungen wieder rückgängig zu machen, und sich später beim Navigieren im Internet einem erhöhten Risiko aussetzen. Wenn ein Benutzer eine unsichere Einstellung vornimmt, warnt der Internet Explorer bereits davor, diese tatsächlich zu übernehmen. Zudem werden unsicher konfigurierte Bereiche rot dargestellt, sodass sofort ersichtlich wird, wo eine suboptimale Einstellung vorhanden ist.

52

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten

Abbildung 3.16 Optische Darstellung von unsicheren Einstellungen

Wenn die Einstellungen trotzdem übernommen werden, meldet sich der Internet Explorer bei jedem Start und benachrichtigt den Benutzer, dass einige Einstellungen des Browsers unsicher sind, und bietet auch gleich an, diese zu korrigieren (Option „Einstellungen reparieren“). Alternativ besteht die Möglichkeit, direkt zu den Sicherheitseinstellungen zu wechseln und die Konfiguration zu prüfen und ggf. zu ändern.

Abbildung 3.17 Unsichere Einstellungen werden erkannt.

53

3 Internet Explorer 7

3.1.4

Schutzschicht 4 – Reduzierte Angriffsoberfläche

Ein sehr wesentliches Merkmal des Internet Explorers 7 ist die Tatsache, dass er anhand des Security Development Lifecycles (SDL) von Microsoft entwickelt worden. Bei diesem Entwicklungsprozess wird die Sicherheit von Anfang an im Code berücksichtigt und ist integraler Bestandteil der Software und nicht – wie früher – nur eine Art „Add-On“. Mit einer Reihe von Penetrationstests und Audits wurde die Sicherheit abschließend überprüft und das Produkt freigegeben.

3.1.5

Schutzschicht 5 – ActiveX Opt-In

ActiveX-Elemente helfen Entwicklern, Webseiten mit Funktionen auszustatten, die in HTML-Webseiten nicht ausführbar wären. Fast alle ActiveX-Elemente sind im Internet Explorer 7 standardmäßig deaktiviert, um die Angriffsoberfläche des Browsers zu reduzieren. Wenn solche Elemente benötigt werden, muss der jeweilige Benutzer der Aktivierung zustimmen (Opt-In). Das Verhalten kann bei Bedarf detailliert über die Internetoptionen und pro Sicherheitszone konfiguriert werden.

Abbildung 3.18 ActiveX-Konfiguration pro Sicherheitszone

54

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten Des Weiteren steht ein Add-On-Manager zur Verfügung, mit dem Benutzer Einsicht in die bereits installierten Elemente haben und diese aktivieren, deaktivieren oder vollständig löschen können.

Abbildung 3.19 Add-Ons verwalten

Je nach Einstellung des Browsers und ActiveX-Elements können der Download und die Aktivierung mit Standardbenutzerrechten fehlschlagen. Mithilfe von Gruppenrichtlinien kann detailliert gesteuert werden, von welchen Quellen Benutzer ActiveX-Elemente explizit herunterladen und installieren dürfen. Das Vorgehen wird später in diesem Kapitel beschrieben.

3.1.6

Schutzschicht 6 – Dateiausführungsverhinderung (Data Execution Prevention, DEP)

Mithilfe dieser Funktion wird eine ganze Reihe von bekannten Online-Angriffen ausgeschaltet. DEP regelt dabei, wie Software den verfügbaren Arbeitsspeicher nutzen darf. Spezielle Bereiche des Arbeitsspeichers werden dabei als explizit „non-executable“ markiert, d.h., aus diesen Speicherbereichen können keine Programme wie beispielsweise Installationsroutinen für Malware gestartet werden. Einige (vorwiegend ältere) ActiveXElemente könnten mit dieser Funktion Probleme verursachen, weshalb die Funktion standardmäßig deaktiviert ist.

55

3 Internet Explorer 7

Abbildung 3.20 Speicherschutz (DEP) im Internet Explorer 7 aktivieren

Damit die Funktion aktiviert werden kann, muss der Internet Explorer mit erhöhten Rechten gestartet werden (Rechtsklick, „Als Administrator ausführen“). Ansonsten ist die Option schraffiert und kann nicht verändert werden .

Da es zu Kompatibilitätsproblemen mit ActiveX-Elementen kommen könnte, sollte eine Aktivierung zuerst ausführlich getestet werden, um sicherzustellen, dass ein einwandfreies Arbeiten möglich ist.

3.1.7

Schutzschicht 7 – Geschützter Modus

Diese Funktion habe ich bereits in den ersten beiden Kapiteln erwähnt, und sie stellt eines der Highlights der Sicherheitsfunktionen des Internet Explorers dar. Im geschützten Modus arbeitet der Internet Explorer-Prozess (Iexplore.exe) auf der tiefstmöglichen Verbindlichkeitsstufe, die Windows Vista bietet, nämlich auf der Stufe „Niedrig“. Dadurch ist es dem Prozess nicht möglich, Schreibzugriffe auf andere Prozesse, Objekte usw. auszuführen, die auf einer höheren Verbindlichkeitsstufe ausgeführt werden. Unter Windows Vista werden

56

3.1 Umfassender Schutz durch mehrere Sicherheitsschichten die meisten Prozesse und Objekte mit der Verbindlichkeitsstufe „Mittel“ ausgeführt, wodurch der IE7 fast komplett vom restlichen Betriebssystem isoliert wird (sog. „Sandbox“Prinzip). Für bestimmte Aktivitäten, beispielsweise um Datei von einer Webseite zu sichern, wird ein neuer Prozess gestartet, der über mehr Berechtigungen verfügt. Alle anderen Aktivitäten verbleiben im tiefen Modus, um das System optimal zu schützen. Ohne den geschützten Modus hat der Prozess „Iexplore.exe“ höhere Rechte (Verbindlichkeitsstufe „Mittel“, wodurch er theoretisch Schreibzugriff auf andere Bereiche des Betriebssystems erhalten kann). Diese Möglichkeit könnten Angreifer nutzen, um beispielsweise Malware auf einem Rechner zu installieren und so die Hoheit darüber zu erhalten. Der geschützte Modus sollte unbedingt aktiviert werden, um das Betriebssystem zu schützen. Dies kann wahlweise über die Internetoptionen lokal oder mittels Gruppenrichtlinien zentral erfolgen. Zudem lässt sich die Funktion pro Sicherheitszone steuern. Beim Surfen ist in der Fußzeile des Browsers jeweils ersichtlich, ob der geschützte Modus aktiv ist oder nicht.

Abbildung 3.21 Geschützten Modus pro Zone ein-/ausschalten

3.1.8

Webseite mit IE7-Demos

Wenn Sie selber einmal einige Sicherheitsmechanismen testen möchten, besuchen Sie die Webseite http://www.ie7demos.com. Microsoft hat auf dieser Seite verschiedene Szenarien aufgebaut, mithilfe derer man sich einerseits mit den einzelnen Funktionen vertraut machen kann, andererseits aber auch prüfen kann, wie die „Angriffe“ (die hier natürlich harmlos sind) ablaufen und ob die entsprechenden Gegenmaßnahmen des Browser tatsächlich funktionieren.

57

3 Internet Explorer 7

3.2

Weitere Sicherheitseinstellungen In dem neuen Internet Explorer sind natürlich auch altbewährte Funktionen von früheren Browsern übernommen worden. Diese möchte ich hier ebenfalls noch kurz erwähnen, weil sie ebenfalls dazu beitragen, die Sicherheit beim Surfen im Internet zu erhöhen. Allerdings beschränke ich mich dabei auf die wichtigsten Bereiche. Schließlich will ich Sie nicht mit „alten“ Informationen, die Sie längst kennen, langweilen.

3.2.1

Sicherheitszonen

Der Internet Explorer kennt grundsätzlich vier Sicherheitszonen, die verwendet werden, um Webseiten zuzuordnen. Jede Webseite, die Sie besuchen, wird einer der verfügbaren Sicherheitszonen zugeordnet. Was aber bringt eine solche Zuordnung? Da die vier Zonen unterschiedlich vertrauenswürdig sind, können Sie pro Zone unterschiedliche Einstellungen festlegen (beispielsweise wie Benutzer mit ActiveX-Elementen der jeweiligen Webseiten dieser Zonen umgehen können). Der Internet Explorer verwendet dazu bereits vorkonfigurierte Einstellungen, die aber jederzeit über die Schaltfläche „Stufe anpassen“ geändert werden können. Über die Schaltfläche „Standardstufe“ wird wieder die ursprüngliche Konfiguration hergestellt.

Abbildung 3.22 Sicherheitszonen

58

3.2 Weitere Sicherheitseinstellungen Internet (Mittelhohe Sicherheitsstufe) Jede Webseite, die nicht explizit einer anderen Zone zugeordnet ist, gehört zu dieser Zone. Dabei handelt es sich vorwiegend um Internet-Webseiten, die während der normalen Arbeit mit dem Internet besucht werden. Dieser Sicherheitszone lassen sich keine Webseiten explizit hinzufügen. Lokales Intranet (Niedrige Sicherheitsstufe) Zu dieser Zone gehören Webseiten, die im internen, also in einem vertrauenswürdigen Netzwerk betrieben werden. Die Zuordnung von Webseiten zu dieser Zone erfolgt automatisch aufgrund verschiedener Kriterien, die über die Schaltfläche „Sites“ angegeben werden können.

Abbildung 3.23 Lokales Intranet konfigurieren

Vertrauenswürdige Sites (mittlere Sicherheitsstufe) Wenn Sie Webseitenbetreiber kennen und diesen vertrauen, können Sie diese Webseiten dieser Zone zuordnen. Die Zone enthält ausschließlich manuell hinzugefügte, vertrauenswürdige Webseiten. Über die Schaltfläche „Sites“ kann die Liste jederzeit angepasst werden.

59

3 Internet Explorer 7

Abbildung 3.24 Vertrauenswürdige Sites festlegen

Eingeschränkte Sites (hohe Sicherheitsstufe) Webseiten, die explizit nicht vertrauenswürdig sind, können dieser Zone zugeordnet werden. Die Zuordnung erfolgt wie bei der Zone „Vertrauenswürdige Sites“ ebenfalls manuell über die Schaltfläche „Sites“.

Abbildung 3.25 Eingeschränkte Sites verwalten

60

3.2 Weitere Sicherheitseinstellungen

3.2.2

Datenschutzeinstellungen

Cookies sind eigentlich eine gute Sache und bei vielen Webseiten unumgänglich. Beispielsweise werden sie dazu verwendet, um Informationen über den Besucher und dessen Absicht zu speichern, wie die Inhalte eines Einkaufswagens, wenn der Benutzer in einem Online-Shop einkauft. Cookies können von Webseitenbetreibern aber auch genutzt werden, um Sie zu identifizieren, Sie wiederzuerkennen, wenn Sie deren Webseite erneut besuchen. Sie können sogar noch tiefer in Ihre Privatsphäre eingreifen. Einfach alle Cookies zu blockieren ist zwar möglich und schützt Ihre Privatsphäre wahrlich am besten, es ist aber nicht unbedingt zu empfehlen, weil dadurch viele legitime Webseiten nicht mehr ordnungsgemäß funktionieren. Wie aber kann festgelegt werden, welche Cookies gut sind und welche nicht? Der Internet Explorer hilft Ihnen bei dieser Entscheidung mit einer verhältnismäßig einfachen Einstellungsmöglichkeit. Mit einem Schieberegler können verschiedene Sicherheitsstufen getestet und bei Bedarf wieder angepasst werden. Prüfen Sie dabei jeweils, welche Cookies genau geblockt werden.

Abbildung 3.26 Datenschutzeinstellungen

61

3 Internet Explorer 7 Für erfahrenere Benutzer kann die Konfiguration noch detaillierter vorgenommen werden. Über die Schaltfläche „Sites“ kann explizit festgelegt werden, von welchen Webseiten Cookie immer zugelassen oder immer verweigert werden sollen. Dies kann beispielsweise hilfreich sein, wenn eine legitime Webseite mit Ihren Cookie-Sicherheitseinstellungen nicht klarkommt. Wenn Sie der Webseite vertrauen, können Sie diese als Seite aufnehmen, von denen Cookies immer zugelassen sind. Über die Schaltfläche „Erweitert“ lassen sich die Einstellungen des Reglers auch noch einmal detaillierter vornehmen. Wenn Sie zu irgendeinem Zeitpunkt unzufrieden mit Ihren Einstellungen sind, aber nicht mehr wissen, wie diese rückgängig zu machen sind, verwenden Sie die Schaltfläche „Standard“. Dadurch stellt der Browser wieder die Standardeinstellungen her.

Abbildung 3.27 Erweiterte Cookie-Einstellungsmöglichkeiten

Auch Popups können mühsam und gefährlich sein und Sie bei der Arbeit mit Internetressourcen behindern. Sie können verwendet werden, um Werbeinformationen einzublenden, aber auch um Benutzer zu täuschen. So oder so, Popps sind mühsam und können mit dem Internet Explorer 7 bei Bedarf blockiert werden. Dabei kann detailliert angegeben werden, welche Filterungsstufe verwendet werden soll und ob Popups von bestimmten Webseiten immer angezeigt werden.

62

3.2 Weitere Sicherheitseinstellungen

Abbildung 3.28 Popup-Filter-Einstellungen

3.2.3

Zertifikatsverwaltung

Über den Browser kann direkt auf Zertifikate zugegriffen werden, beispielsweise um zu prüfen, welchen Herstellern Sie vertrauen oder welche Benutzerzertifikate Sie selber zur Verfügung haben, beispielsweise für die Authentifizierung an einer Webseite. Über die Schaltfläche „Zertifikate“ oder „Herausgeber“ gelangen Sie zur Detailansicht. Die angezeigten Informationen sind nicht nur für den Browser relevant, sondern für das gesamte Betriebssystem. Wenn Sie beispielsweise über den Browser einen Herausgeber entfernen, wird nicht nur der Browser, sondern das ganze Betriebssystem Zertifikaten dieses Anbieters nicht mehr vertrauen.

63

3 Internet Explorer 7

Abbildung 3.29 Übersicht Inhaltsverwaltung (mit Zertifikatsverwaltung)

Abbildung 3.30 Zertifikatsverwaltung im Browser

64

3.3 Konfiguration über Gruppenrichtlinien

3.2.4

Löschen von persönlichen Informationen

Zu guter Letzt interessiert es Sie bestimmt, wie persönliche Informationen aus dem Browser entfernt werden können. Vielleicht möchten Sie nicht, dass jemand Zugriff auf Ihren Verlauf oder auf Ihre Cookies hat. Diese Informationen lassen sich sehr leicht entfernen. Mit dem Internet Explorer 7 sind alle Bereiche, die persönliche Informationen enthalten können, jetzt über eine einzige Eigenschaftsseite löschbar. Benutzer haben die Möglichkeit zu entscheiden, ob alles oder aber nur bestimmte Bereiche gelöscht werden sollen. Zur gewünschten Ansicht gelangen Sie über die Internetoptionen. Dort können Sie auch gleich temporäre Dateien anzeigen oder deren Speicherpfad ändern.

Abbildung 3.31 Löschen von persönlichen Informationen

3.3

Konfiguration über Gruppenrichtlinien Der Konfiguration des Internet Explorers lässt sich über Gruppenrichtlinien steuern, womit Administratoren über ein zentrales Instrument für die Sicherheitskonfiguration der Browserlandschaft verfügen. Dafür stehen weit über Hundert Einstellungsmöglichkeiten zur Verfügung, wovon auch einige den Sicherheitsbereich betreffen. Weil eine vollständige Beschreibung aller Sicherheitsrichtlinien den Rahmen dieses Buches absolut sprengen

65

3 Internet Explorer 7 würde, finden Sie anbei die wichtigsten Einstellungen für die Sicherheitskonfiguration des Internet Explorers (mit Fokus auf die neuen Sicherheitsfunktionen des Internet Explorers 7 unter Windows Vista). Sie finden die Einstellungen in Gruppenrichtlinien unter Computerverwaltung\Administrative Templates\Windows-Komponenten\Internet Explorer.

Abbildung 3.32 Richtlinien für Internet Explorer-Konfiguration

Richtlinie

Beschreibung

Internet Explorer\Verwaltung der Phishing-Filter deaktivieren

Diese Richtlinie legt fest, ob Benutzer beim ersten Start des Internet Explorers aufgefordert werden, den Phishing-FilterModus zu wählen. Dabei können sie den Phishing-Filter auch komplett ausschalten. Bei einer allfälligen Aktivierung stehen die Varianten „Aus“ (Phishing-Filter ist deaktiviert), „Automatisch“ (aktiv, lokale Prüfung und Weitergabe an Microsoft) und „Manuell“ (aktiv, aber nur lokale Prüfung) zur Verfügung. Standardeinstellung: Deaktiviert (Benutzer werden aufgefordert, den Modus festzulegen) Empfohlene Einstellung: Diese Richtlinie sollte mit der Option „Automatisch“ aktiviert werden, damit Benutzer diese Entscheidung nicht treffen müssen und eine höchstmögliche Sicherheit gewährleistet ist.

Internet Explorer\Überprüfung der Sicherheitseinstellungen deaktivieren

Diese Richtlinie steuert, ob der Internet Explorer beim Start die Konfiguration auf unsichere Einstellungen überprüft und dem Benutzer eine automatische Korrektur anbietet. Standardeinstellung: Deaktiviert (Prüfung wird durchgeführt) Empfohlene Einstellung: Diese Prüfung sollte unbedingt durchgeführt werden, weshalb die Richtlinie nicht aktiviert werden sollte.

66

3.4 Installation von ActiveX-Elementen steuern Richtlinie

Beschreibung

Internet Explorer\Sicherheitszonen: Benutzer können keine Einstellungen ändern

Diese Richtlinie legt fest, ob Benutzer selbstständig Änderungen an den Sicherheitseinstellungen von Sicherheitszonen vornehmen können. Standardeinstellung: Deaktiviert (Benutzer können Änderungen vornehmen) Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden, damit Benutzer keine Änderungen an Zoneneinstellungen vornehmen können. Bedenken Sie allerdings, dass dadurch Benutzer in ihrer Tätigkeit eingeschränkt werden könnten.

Internet Explorer\Sicherheitszonen: Benutzer können Sites nicht hinzufügen oder entfernen

Diese Richtlinie legt fest, ob Benutzer berechtigt sind, selbstständig Webseiten einzustufen und eine der vorhandenen Sicherheitszonen zuordnen zu können. Standardeinstellung: Deaktiviert (Benutzer können Webseiten zuordnen) Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden, damit Benutzer keine Änderungen an Sicherheitszonen durchführen können. Bedenken Sie allerdings, dass dadurch Benutzer in ihrer Tätigkeit eingeschränkt werden könnten.

Internet Explorer\ Internetsystemsteuerung\ Sicherheitsseite\Sicherheitszone\ Geschützten Modus aktivieren

Mit dieser Richtlinie kann der geschützte Modus für die entsprechende Sicherheitszone (für alle verfügbar) aktiviert oder deaktiviert werden. Standardeinstellung: Benutzer können den geschützten Modus selbstständig ein- oder ausschalten. Empfohlene Einstellung: Diese Richtlinie sollte unbedingt aktiviert werden, damit der geschützte Modus von Benutzern nicht ausgeschaltet werden kann.

3.4

Installation von ActiveX-Elementen steuern Wie bereits erwähnt: ActiveX-Elemente sind eigentlich eine gute Sache, solange sie nicht dazu verwendet werden, um Schaden anzurichten oder persönliche Informationen von Benutzern zu sammeln und auszuwerten. Deshalb besteht die Möglichkeit festzulegen, wie Benutzer mit ActiveX-Elementen umgehen müssen (über die Einstellungen der jeweiligen Sicherheitszonen im Internet Explorer). Das kann allerdings auch sehr mühsam sein, weil Benutzer dadurch möglicherweise nicht mehr alle ActiveX-Elemente installieren können, auch diejenigen nicht mehr, die tatsächlich benötigt werden. So ist beispielsweise das Flash Player-Element von Macromedia für die korrekte Anzeige vieler animierter bzw. teilanimierter Webseiten notwendig. Genau dieses ActiveX-Element (und natürlich viele

67

3 Internet Explorer 7 andere auch) kann aber von einem Anwender mit Standardbenutzerrechten nicht installiert werden. Eine entsprechende Fehlermeldung wird angezeigt. Im Anwendungsprotokoll ist der Fehler ersichtlich. Zudem ist die genaue Quelle sichtbar, von der das Element installiert hätte werden sollen.

Abbildung 3.33 Anwendungsprotokoll mit Installationsfehler des ActiveX-Elements

Prüfen Sie unbedingt die Quelle, an der die Installation fehlgeschlagen ist. Diese stimmt nicht immer mit der Webseite überein, auf der Sie die Installation des ActiveX-Elements gestartet haben. Damit die Richtlinie, die Sie jetzt gleich konfigurieren werden, einwandfrei funktioniert, benötigen Sie die korrekte Quelle. Und die finden Sie hier im Anwendungsprotokoll.

Mithilfe von Gruppenrichtlinien kann ein Administrator nun aber explizit festlegen, welche Quellen (URLs) vertrauenswürdig sind und dass Benutzer von diesen Quellen ActiveX-Elemente uneingeschränkt herunterladen und installieren dürfen. Dazu benötigen Sie zuerst einen speziellen Dienst, der zwar mit Windows Vista mitgeliefert, aber nicht installiert wird. 1. Fügen Sie über die Windows-Funktionen den Dienst „ActiveX-Installerdienst“ hinzu. Starten Sie den Dienst, und setzen Sie die Startart auf „Automatisch“.

68

3.4 Installation von ActiveX-Elementen steuern

Abbildung 3.34 ActiveX-Installerdienst hinzufügen

2. Starten Sie die Gruppenrichtlinienverwaltung (gpmc.msc). Erstellen Sie eine Gruppenrichtlinie auf der gewünschten Ebene, und navigieren Sie zum Bereich Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\ActiveX-Installerdienst, und nehmen Sie die gewünschten Einstellungen vor.

Abbildung 3.35 Richtlinie für das Festlegen vertrauenswürdiger Quellen

Mithilfe dieser Richtlinie kann festgelegt werden, von welchen Quellen Standardbenutzer ActiveX-Elemente installieren dürfen. Für die vollständige Konfiguration sind zwei Angaben notwendig: Einerseits muss die Quelle angegeben werden, andererseits muss ein Zah-

69

3 Internet Explorer 7 lenwert eingegeben werden, um festzulegen, welche Arten von ActiveX-Elementen von dieser Quelle installiert werden dürfen.

Abbildung 3.36 Quellen für vertrauenswürdige ActiveX-Elemente festlegen

Richtlinie

Beschreibung

Genehmigte Installationsorte für ActiveX-Steuerelemente

1.

Hostname des Objekts, z.B. „http://fpdownload.macromedia.com“

2.

Vier weitere Angaben (kommagetrennt), z.B. „2,1,0,0“

Die ersten drei Zahlen beziehen sich auf ActiveX-Elemente von der angegebenen Quelle. 1. Zahl = TPSSignedControl (Werte 2, 1 und 0 erlaubt) 2. Zahl = SignedControl (Werte 2, 1 und 0 erlaubt) 3. Zahl = UnsignedControl (Werte 1 und 0 erlaubt) Wert 2 = Installation erfolgt automatisch Wert 1 = Installation erfolgt nach Bestätigung Wert 0 = Installation wird nicht zugelassen Mit den ersten drei Zahlen lässt sich demnach festlegen, wie ein Rechner bei signierten und wie bei unsignierten Zertifikaten reagieren soll. 4. Zahl = Prüfung des Zertifikats, falls Quelle eine HTTPS-Webseite ist (die Werte lassen sich bei Bedarf kombinieren) Wert 0 = Zertifikate müssen vollständig gültig sein (Datum, Hersteller vertrauenswürdig, FQDN im Zertifikat muss mit URL übereinstimmen) Wert 0x00000100 = Unbekannte Zertifizierungsstelle ignorieren* Wert 0x00001000 = Ungültigen Namen (FQDN) ignorieren* Wert 0x00002000 = Ungültiges Zertifikatsdatum ignorieren* Wert 0x00000200 = Falschen Zertifikatszweck ignorieren*

70

3.5 Rückblick Empfohlene Einstellungen: Am besten stellen Sie sicher, dass Benutzer eine ActiveX-Installation immer bestätigen müssen. Dadurch werden die beiden ersten Zahlen auf 1 gesetzt. Nicht signierte Elemente sollten sicherheitshalber nicht installiert werden. Die dritte Zahl ergibt demnach eine 0. Falls die Elemente über eine HTTPSWebseite heruntergeladen werden, sollte das Zertifikat dieser Seite Gültigkeit haben. Setzen Sie daher die letzte Zahl auf 0. Das ergibt einen kommagetrennten Wert von „1,1,0,0“.

3. Übernehmen Sie die Einstellungen (Neustart oder Zuweisung der Richtlinien mit gpupdate.exe /force). Prüfen Sie anschließend, ob das ActiveX-Element von der angegebenen Quelle installiert werden kann. Somit ist die Konfiguration abgeschlossen, und Benutzer sind in der Lage, die ActiveXElemente der angegebenen Quellen selbstständig zu installieren. Administratoren erhalten durch diese Möglichkeit eine sehr enge Kontrolle über ActiveX-Elemente, allerdings ist der Aufwand, diese Konfiguration für alle gewünschten ActiveX-Elemente vorzunehmen, unter Umständen sehr groß. Entscheiden Sie, ob diese Funktion Ihnen und den Mitarbeitern Ihrer Firma einen Mehrwert bringt.

3.5

Rückblick Wie Sie gesehen haben, ist der Internet Explorer mit vielen neuen Sicherheitsfunktionen ausgerüstet worden. Der gezeigte mehrschichtige Ansatz im Bereich der Sicherheit hilft, Angriffe aus dem Internet abzuwehren und erfolgreiche Angriffe zu verhindern. Um höchstmöglichen Schutz zu genießen, sollten Sie unbedingt alle Schichten aktivieren – besonders aber den geschützten Modus, bei dem der Internet Explorer mit sehr tiefen Rechten operiert. Analysieren Sie alle Schichten einzeln, und legen Sie die optimale Konfiguration fest. Und jetzt viel Spaß beim (sicheren) Surfen!

71

4 Schützen von Daten und Betriebssystemdateien Das vermutlich wichtigste Gut einer Firma sind Daten. Daten enthalten alles, Informationen über Kunden und Lieferanten, aktuelle Bestellungen, die in den Produktionsprozess einfließen müssen, oder finanzielle Informationen der eigenen Firma. Diese Daten können in verschiedensten Formen vorliegen, sei es in simplen Dokumenten, in Datenbanken oder in Benutzerpostfächern. Einige dieser Daten sind für eine Firma überlebenswichtig, bei anderen handelt es sich um persönliche Daten von Mitarbeitern, die aus Sicht der Firma unwichtig sind. Hier den Durchblick zu behalten ist nicht ganz einfach und eine echte Herausforderung. Ohne Richtlinie, die beschreibt, wie mit Daten umgegangen werden muss, hat man einen schweren Stand. Wie, bei Ihnen gibt es keine solche Richtlinie? Dann sollten Sie diesen Task sofort in Angriff nehmen, und zwar bevor Sie hier weiterlesen ... Welche Daten sind denn nun tatsächlich heikel und müssen vor Löschung und Manipulation geschützt werden? Wo befinden sich die zu schützenden Daten? Auf verhältnismäßig sicheren Speichermedien innerhalb der Firma oder möglicherweise sogar auf mobilen Geräten, welche die Firma verlassen könnten? Der unsachgemäße Umgang mit Daten kann verheerende Auswirkungen haben. Wenn Daten gelöscht, manipuliert werden oder gar in falsche Hände geraten (beispielsweise in die der Konkurrenz), kann das für eine Firma möglicherweise den Ruin bedeuten. Hoffen wir, dass es nicht ganz so schlimm ist. Aber nichtsdestotrotz: So weit wollen wir es gar nicht erst kommen lassen. Also, was bietet Windows Vista, um Daten zu schützen? Richtig, eine ganze Menge, und die werde ich Ihnen in diesem Kapitel näherbringen.

4.1

Das NTFS-Dateisystem Diese Sicherheitsfunktion kann fast schon als „Dinosaurier“ eingestuft werden, weil sie schon seit etlichen Windows-Generationen (erfolgreich) eingesetzt wird. Natürlich hat es seit der Einführung vor über zehn Jahren einige Erweiterungen und Verbesserungen gegeben, so auch wieder bei Windows Vista. Ich möchte Ihnen nicht erklären, wie NTFS genau

73

4 Schützen von Daten und Betriebssystemdateien funktioniert, dafür ist ein Sicherheitsbuch nicht das richtige Medium, aber ich möchte Ihnen aufzeigen, wie das NTFS-Dateisystem zu einem umfassenden Schutz (aus Administrationssicht) eines Systems beitragen kann. Die erste Frage stellt sich in Sachen Alternativen. Gibt es die überhaupt unter Windows Vista? Ja, es gibt sie, und ja, Sie sollten in der Regel darauf verzichten. FAT bzw. FAT32 wird immer noch unterstützt, allerdings werden bei diesen Dateisystemen zahlreiche Sicherheitsfunktionen (und auch Unsicherheitsfunktionen) nicht unterstützt. Wenn es also keinen triftigen Grund gegen NTFS gibt, sollten Sie unbedingt darauf setzen. Folgende Liste zeigt eine Reihe von Sicherheitsfunktionen, die Ihnen bei der Nutzung von NTFS zur Verfügung stehen: Lokale Sicherheit auf Datei- und Ordnerebene Mithilfe von NTFS ist es möglich, Daten und Betriebssystemdateien lokal zu schützen. Stellen Sie sich vor, dass mehrere Benutzer mit der gleichen Arbeitsstation arbeiten und teilweise vertrauliche Daten auf dem Gerät speichern. In diesem Szenario möchten Sie sicherstellen, dass Benutzer nicht auf Daten von anderen Benutzern zugreifen können. Und genau das lässt sich mit NTFS einrichten. Da sich jeder Benutzer am System eindeutig identifizieren muss, kann mithilfe von Benutzerkonten granular festgelegt werden, wer auf welche Daten Zugriff hat. Das Gleiche gilt für Systemdateien. Auch darauf können Zugriffe eingeschränkt werden (und das ist standardmäßig auch der Fall, wie Sie gleich sehen werden). Wenn Sie FAT als Dateisystem einsetzen, steht die Funktion der lokalen Sicherheit nicht zur Verfügung, und jeder Benutzer kann uneingeschränkt auf alle Daten zugreifen. Viele Sicherheitsstufen für granulare Zugriffssteuerung Mit NTFS werden weit über zehn verschiedene Berechtigungsstufen zur Verfügung gestellt, um Zugriffe eng steuern und kontrollieren zu können. Mit beliebigen Kombinationen lässt sich so einem Benutzer genau dasjenige Recht zuweisen, das er effektiv benötigt. Überwachung Für Ordner und Dateien, die sich auf NTFS-Partitionen befinden, kann die Objektüberwachung aktiviert werden. Dadurch lassen sich Zugriffe auf gewünschte Objekte detailliert überwachen. Wenn beispielsweise nachverfolgt werden soll, wann und von wem eine bestimmte Datei verändert wird, kann dies mit der Objektüberwachung realisiert werden. Daten verschlüsseln Wenn NTFS-Rechte nicht ausreichen, kann die Sicherheit von Daten auf einer NTFSPartition weiter verstärkt werden, indem diese verschlüsselt werden. Per Knopfdruck lassen sich Ordner und Dateien von Benutzern verschlüsseln und so schützen. Kein anderer Benutzer hat die Möglichkeit, diese Daten anzuzeigen.

74

4.1 Das NTFS-Dateisystem BitLocker Höchstmöglichen Schutz erreichen Sie mit dieser neuen Methode, die ganze Systempartition von Windows Vista zu verschlüsseln. Da jede Datei (na ja, fast jede, wie Sie später in diesem Kapitel erfahren werden) verschlüsselt wird, sind alle Daten auch dann geschützt, wenn ein Gerät, beispielsweise ein Notebook, entwendet wird. Die Daten sind so für eine Drittperson nicht einsehbar. In diesem Kapitel werden wir die aufgeführten Punkte detailliert unter die Lupe nehmen, damit Sie die technischen Möglichkeiten kennenlernen, um Ihre Daten optimal zu schützen.

4.1.1

Lokale Sicherheit auf Datei- und Ordnerebene – Jumpstart und Refresh!

An der Idee dieser Funktion hat sich sicherheitstechnisch nicht viel verändert. Der Zugriff auf Daten kann lokal mithilfe von Benutzerkonten und Gruppen eingeschränkt und gesteuert werden. Dazu hat jedes Objekt eine sog. Zugriffssteuerungsliste (Access Control List, ACL), die verschiedene Einträge enthält. Diese Einträge (Access Control Entries, ACE) repräsentieren Benutzerkonten oder Gruppen und legen fest, welche Rechte diese Konten/Gruppen auf das Objekt erhalten. Über die erweiterten Sicherheitseinstellungen lassen sich die Zugriffsrechte zudem sehr detailliert zuweisen.

Abbildung 4.1 NTFS-Berechtigungen einer Datei (einfach und erweitert)

75

4 Schützen von Daten und Betriebssystemdateien Rechte werden kumuliert, d.h., wenn ein Benutzer durch Mitgliedschaft in unterschiedlichen Gruppen mehrere Rechte zugewiesen bekommt, gelten jeweils die höchsten zugewiesenen Rechte. Die einzige Ausnahme besteht dann, wenn für diesen Benutzer irgendwo ein Recht explizit verweigert wird, da das immer Vorrang vor zugelassenen Rechten hat. Zugewiesene NTFS-Rechte unterliegen einem Vererbungsprinzip, d.h., wenn ein Ordner für bestimmte NTFS-Rechte konfiguriert worden ist, werden diese an alle Dateien und Ordner, die sich darin befinden, vererbt. Das macht eine Zuweisung von Rechten sehr einfach, schränkt aber auch ein, weil vererbte Rechte nur sehr begrenzt manipuliert werden können. Aus diesem Grund kann die Vererbung auf eine Datei oder einen Ordner bei Bedarf unterbrochen werden, sodass keine Rechtevererbung von einem übergeordneten Objekt mehr erfolgt und die Rechte des Objekts uneingeschränkt verwaltet werden können. Für die Unterbrechung der Vererbung muss in den erweiterten Sicherheitseinstellungen lediglich die Markierung der Option „Vererbbare Berechtigungen des übergeordneten Objekts einschließen“ gelöscht werden.

Abbildung 4.2 Vererbungsunterbrechung auf einem Objekt

4.1.2

Besitzer von Systemobjekten

Jedes Objekt, das sich auf einer NTFS-Partition befindet, hat einen Besitzer, und der hat volle Verwaltungsrechte über ein Objekt. In älteren Versionen von Windows war für Objekte des Betriebssystems jeweils der Administrator als Besitzer festgelegt. Das Konto, das über Besitzrechte eines Objektes verfügt, hat grundsätzlich alle Manipulationsmöglichkeiten an diesem Objekt. Bei Windows Vista ist das anders. Hier ist für die meisten Objekte

76

4.1 Das NTFS-Dateisystem das Konto „TrustedInstaller“ festgelegt. Was bringt das für Vorteile? Ein Vorteil liegt darin, dass ein Administrator keine Systemdateien mehr löschen kann (beabsichtigt oder unbeabsichtigt), weil er selber nur über begrenzte Objektrechte verfügt (z.B. Lesen). Wenn Sie als Test versuchen, die Datei „Regedit.exe“ im Verzeichnis „C:\Windows“ zu löschen, wird dieser Versuch fehlschlagen, weil das Administratorenkonto nicht über genügend Rechte verfügt.

Abbildung 4.3 Das Konto „TrustedInstaller“ als Objektbesitzer

Zuerst muss der Administrator über die erweiterten Sicherheitseinstellungen die Besitzrechte an diesem Objekt übernehmen (was standardmäßig nur Administratoren können) und sich dann volle Zugriffsrechte zuweisen. Bei diesem Prozess fällt ebenfalls etwas Neues auf. Nachdem die Besitzrechte übernommen worden sind, wird das Administratorenkonto in der Berechtigungsliste aufgeführt. Ihm muss lediglich noch ein höheres Recht, z.B. „Vollzugriff“, zugewiesen werden. Das war bereits in früheren Versionen von Windows so. Was aber neu ist, ist die Tatsache, dass das Konto des ehemaligen Besitzers, in diesem Fall das Konto „TrustedInstaller“, immer noch in der Liste aufgeführt ist, und zwar mit den genau gleichen Rechten wie zuvor. Das macht einiges einfacher, wenn dieses Konto nach wie vor auf das Objekt zugreifen soll. In früheren Windows-Versionen muss das Konto jeweils wieder hinzugefügt werden. Nachdem die Rechte für das Administratorenkonto zugewiesen worden sind, kann die Datei jetzt gelöscht werden. Diese neue Situation, in welcher der Administrator nicht mehr der Besitzer von Systemobjekten ist, fügt dem Betriebssystem eine weitere Schutzschicht hinzu und stellt sicher, dass ein Administrator nicht aus Versehen oder durch eine unbe-

77

4 Schützen von Daten und Betriebssystemdateien merkte Kompromittierung seines Rechners wichtige Systemdateien löschen oder verändern kann. Dazu muss zuerst der Besitz übernommen und dem Administrator ein höheres Recht zugewiesen werden (beide Schritte erfordern ein Erhöhen von Berechtigungen). Natürlich, dabei handelt es sich lediglich um eine minimale Sicherheitserhöhung, aber Sie sehen, dass Windows Vista auch solche Szenarien nutzt, um das System sicherer zu machen.

4.1.3

Umleitungen im Dateisystem

Eine interessante Neuerung ist die, dass auf eine Reihe von Ordnern nicht mehr zugegriffen werden kann, selbst nicht mit Administratorenrechten. Kennen Sie diese Situation? Nein? Dann zeige ich Ihnen ein kleines Beispiel. Bei älteren Betriebssystemen existiert standardmäßig der Ordner „C:\Dokumente und Einstellungen“, der dazu verwendet wird, Benutzerprofile zu speichern. Unter Windows Vista ist dieser Ordner umbenannt worden und heißt nun „C:\Benutzer“; aufgrund der Nachvollziehbarkeit des Namens durchaus ein Vorteil. Was ist aber mit Programmen, Skripten usw., die für ältere Windows-Generationen geschrieben worden sind und (leider) den hardkodierten Pfad „C:\Dokumente und Einstellungen“ verwenden? Eigentlich müsste man meinen, dass die Vorgänge fehlschlagen, weil dieser Ordner ja nicht mehr existiert. Stimmt aber nicht ganz. Diese Prozesse funktionieren nach wie vor einwandfrei! In Windows Vista ist eine Reihe von Umleitungen eingebaut worden, um genau solche Szenarien abzufangen. Wenn die Ordneroptionen so konfiguriert werden, dass geschützte Systemdateien und versteckte Dateien angezeigt werden, kommt der „alte“ Ordner „C:\Dokumente und Einstellungen“ wieder zum Vorschein.

Abbildung 4.4 „Alte“ Ordner darstellen

78

4.1 Das NTFS-Dateisystem Aufgrund der Pfeilsymbole ist sofort ersichtlich, dass es sich hierbei um Umleitungen handelt. Wohin diese Umleitungen allerdings erfolgen, ist nicht direkt sichtbar. Über die Eingabeaufforderung kann dies mit dem Befehl „Dir.exe /a“ sichtbar gemacht werden.

Abbildung 4.5 Umleitungen mit „Dir.exe /a“ anzeigen

Die Tatsache, dass in dieser Darstellung englische Bezeichnungen verwendet werden, ist ein bisschen verwirrend. Die Umleitung erfolgt gemäß Anzeige an den Pfad „C:\Users“, was eigentlich wiederum dem Ordner „C:\Benutzer“ entspricht.

Beim Versuch, auf den Ordner „C:\Dokumente und Einstellungen“ zuzugreifen, werden Sie feststellen, dass dies nicht möglich ist, der Zugriff wird verweigert. Wenn die erweiterten Rechte des Ordners angezeigt werden, wird schnell klar, warum der Zugriff nicht funktioniert. Die Gruppe „Jeder“ hat explizite Verweigerungsrechte, um Ordnerinhalte anzuzeigen.

79

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.6 Rechteverweigerung auf Umleitungsordnern

Wenn keine Ordnerinhalte angezeigt werden können, wie kann es denn sein, dass alte Programme und Skripte nach wie vor funktionieren? Den Ordner nicht auflisten zu dürfen heißt nicht, dass auch Schreibrechte blockiert sind. Der Ordner kann immer noch durchsucht und Operationen können ausgeführt werden. Die verhinderte Auflistung soll vor allem verhindern, dass Administratoren für neu zu erstellende Programme und Skripte den alten Pfad verwenden. Irgendwann – vielleicht schon bei der nächsten Client-Generation – wird dieser Ordner nicht mehr unterstützt werden, und daher alle Zugriffe darauf werden fehlschlagen. Mit dem Tool „Mklink.exe“, das mit Windows Vista mitgeliefert wird, ist es möglich, eigene Umleitungen zu erstellen.

4.1.4

Verbindlichkeitsstufen – Sie erinnern sich?

Erinnern Sie sich an die Verbindlichkeitsstufen, die von Windows Vista genutzt werden? Diese sind bei Objektzugriffen ebenfalls relevant und haben Gültigkeit, bevor NTFSRechte überhaupt geprüft werden. Um die effektiven Rechte auf ein Objekt zu berechnen, sind demnach nicht alleine NTFS-Rechte ausschlaggebend, sondern auch die Verbindlichkeitsstufen, auf denen sich Quell- und Zielobjekte befinden.

80

4.1 Das NTFS-Dateisystem

4.1.5

Kontrolle ist gut, Überwachung ist besser

Im Bereich Überwachung hat sich eigentlich gegenüber der Vorgängerversion auf den ersten Blick nicht so viel getan. Wenn man sich allerdings ein bisschen intensiver mit dieser Funktion befasst, wird man feststellen, dass doch so einiges neu ist. Wozu benötigt man aber überhaupt eine Überwachung? Es ist immer sinnvoll, einem System oder einer Konfiguration nicht blind zu vertrauen, sondern zu prüfen, ob sie wie gewünscht funktioniert. Seit längerer Zeit ist es daher möglich, mit dem WindowsBetriebssystem bestimmte Bereiche zu überwachen. Von Anmeldeversuchen über Zugriffe auf Ordner und Dateien bis hin zu Systemabstürzen kann alles überwacht und aufgezeichnet werden. Wichtig hierbei ist allerdings, dass Sie sich auf diejenigen Bereiche beschränken, die tatsächlich relevant sind. Die Überwachung für alle Bereiche erzeugt eine Datenmenge, die nicht mehr auszuwerten ist. Und hier kommt eine der (versteckten) Neuerungen von Windows Vista zum Zug: Grundsätzlich bestehen (seit Längerem schon) neun Hauptkategorien, die überwacht werden können. Mit Windows Vista wurden nun einige Unterkategorien hinzugefügt, mit denen die Überwachung viel gezielter eingesetzt werden kann. Einige dieser Unterkategorien werden standardmäßig überwacht, weshalb im Sicherheitsprotokoll (dort werden die Ergebnisse der Überwachung angezeigt) von Windows Vista immer irgendwelche Einträge vorhanden sind, ohne dass die Überwachung durch einen Administrator aktiviert worden ist. Die Konfiguration der Überwachung erfolgt zweistufig. Zuerst muss die Überwachung grundsätzlich aktiviert werden, was über Gruppenrichtlinien erfolgt (lokale oder domänenbasierte). Navigieren Sie dazu in der entsprechenden Gruppenrichtlinie zum Pfad Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinien. Die Hauptbereiche der Überwachung werden angezeigt.

Abbildung 4.7 Konfiguration der Überwachungsrichtlinie

81

4 Schützen von Daten und Betriebssystemdateien Überwachungsbereich

Beschreibung

Anmeldeereignisse überwachen

Wenn sich Benutzer an der Benutzerdatenbank des lokalen Rechners authentifizieren bzw. wenn für einen Rechner ein Access Token ausgestellt wird, kann diese Richtlinie solche Vorgänge aufzeichnen.

Anmeldeversuche überwachen

Anmeldeversuche überwachen Kontoverifizierungen gegen einen Domänencontroller (DC), also dann, wenn sich ein Benutzer mit seinem Konto an der Domäne authentifiziert. Der DC, der die Authentifizierung durchgeführt hat, zeichnet die Anmeldung in seinem Sicherheitsprotokoll auf.

Kontenverwaltung überwachen

Wenn die Verwaltung von Benutzerkonten überwacht werden soll, kann dazu diese Richtlinie aktiviert werden. Alle Änderungen an bestehenden Konten sowie das Erstellen von neuen Konten wird aufgezeichnet.

Objektzugriffsversuche überwachen

Mit dieser Richtlinie können Zugriffe auf Objekte (Dateien, Ordner, Registrierungsschlüssel usw.) überwacht werden. Diese Einstellung aktiviert grundsätzlich die Überwachung von Objekten, allerdings muss in einem zweiten Schritt noch angegeben werden, welche Objekte genau überwacht werden sollen. Dies erfolgt in der SACL der jeweiligen Objekte. Wird dieser zweite Konfigurationsschritt nicht durchgeführt, werden keine Ereignisse aufgezeichnet.

Prozessverfolgung überwachen

Wenn gesamte Prozesse mit allen ihren Lese- und Schreibzugriffen aufgezeichnet werden sollen, sollte diese Richtlinie aktiviert werden. Hierbei ist allerdings zu bedenken, dass bei einer Aktivierung eine sehr große Anzahl von Überwachungseinträgen generiert wird. Deshalb sollte diese Richtlinie nur sehr gezielt, z.B. für Troubleshooting-Zwecke, eingesetzt werden.

Rechteverwendung überwachen

Benutzer enthalten eine Reihe von Rechten über eine Richtlinie (werden im Access Token abgelegt, mit „Whoami.exe“ anzeigen). Wenn ein Benutzer eines dieser Rechte nutzt, kann dies durch Aktivierung dieser Richtlinie aufgezeichnet werden.

Richtlinienänderung überwachen

Mithilfe dieser Richtlinie können Änderungen an Sicherheitsrichtlinien (z.B. Zuweisen von Benutzerrechten, Überwachungsrichtlinien usw.) nachverfolgt werden.

Systemereignisse überwachen

Diese Richtlinie überwacht wichtige Systemereignisse wie beispielsweise den Start oder das Herunterfahren eines Geräts, aber auch kritische Ereignisse wie Stopp-Fehler.

82

4.1 Das NTFS-Dateisystem Überwachungsbereich

Beschreibung

Verzeichnisdienstzugriff überwachen

Mit dieser Richtlinie können Zugriffe auf Active Directory(AD)Objekte überwacht werden. Diese Einstellung aktiviert grundsätzlich die Überwachung von AD-Objekten, allerdings muss in einem zweiten Schritt im AD noch angegeben werden, welche Objekte genau überwacht werden sollen. Dies erfolgt in der SACL der jeweiligen Objekte. Wird dieser zweite Konfigurationsschritt nicht durchgeführt, werden keine Ereignisse aufgezeichnet.

Für jede Richtlinie lässt sich jeweils festlegen, ob Erfolg oder Fehlschlag überwacht werden soll. Je nach Situation können beide Varianten sinnvoll sein. Nehmen wir als Beispiel die Anmeldeereignisse an einem lokalen System. Hierbei ist es sicher sinnvoll, fehlgeschlagene Aktionen aufzuzeichnen. Dadurch wird ersichtlich, ob unautorisierte Personen versuchen, sich an einem System anzumelden. Das allerdings würde nicht viel bringen, weil Sie mit nur dieser Einstellung niemals erfahren werden, ob diese unautorisierten Personen es geschafft haben, sich erfolgreich anzumelden. Sie überwachen ja nur fehlgeschlagene Anmeldeereignisse. Demnach wäre es hierbei sicher sinnvoller, neben den fehlgeschlagenen Ereignissen auch die erfolgreichen Ereignisse aufzuzeichnen. Für einige Bereiche ist ein weiterer Konfigurationsschritt notwendig, beispielsweise für die Objektüberwachung. Wenn Zugriffe auf Objekte, z.B. Dateien, überwacht werden sollen, muss in einem zweiten Schritt festgelegt werden, welche Datei genau überwacht werden soll, welche Benutzer überwacht und zuletzt welche Aktivitäten dieser Benutzer aufgezeichnet werden sollen. Das hört sich nach viel Arbeit an. Der zweite Konfigurationsschritt wird direkt auf dem zu überwachenden Objekt vorgenommen. Über die erweiterten Sicherheitseinstellungen können die gewünschten Einstellungen über den Reiter „Überwachung“ vorgenommen werden (dabei handelt es sich um die SACL der Datei). Nachdem ein Benutzerkonto oder eine Gruppe ausgewählt worden ist, das/die überwacht werden soll, kann sehr detailliert festgelegt werden, welche Aktivitäten dieser Benutzer aufgezeichnet werden sollen. Auch hier stehen wieder die Optionen „Erfolg“ und „Fehler“ zur Verfügung. Die vorgenommenen Einstellungen können (genau gleich wie NTFSRechte) vererbt werden. Auch kann die Vererbung bei Bedarf unterbrochen werden. Wie werden aufgezeichnete Informationen dargestellt? Wie bereits erwähnt, werden diese im Sicherheitsprotokoll der Ereignisanzeige gespeichert.

83

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.8 Objekte überwachen

Abbildung 4.9 Aufgezeichnete Ereignisse im Sicherheitsprotokoll

84

4.1 Das NTFS-Dateisystem Sie werden schnell bemerken, dass Windows Vista sehr viele Ereignisse aufzeichnet. Die Überwachung sollte daher sehr gezielt aktiviert werden, damit die aufgezeichneten Ereignisse überhaupt ausgewertet werden können.

So, jetzt kommen wir zu den Neuerungen von Windows Vista. Vielleicht haben Sie es schon bemerkt: Obwohl die Aktivierung standardmäßig in keiner einzigen Gruppenrichtlinie, weder lokal noch über die Domäne, konfiguriert ist, werden bei Windows Vista einige Ereignisse überwacht und im Sicherheitsprotokoll gespeichert. Wo aber ist diese Konfiguration abgelegt? Wie bereits erwähnt, hat Windows Vista ein neues, noch detaillierteres Überwachungsmodell, das sich (zumindest derzeit) nur lokal und mit einem speziellen Werkzeug konfigurieren lässt. Und genau dort ist festgelegt, dass einige Bereiche überwacht werden. Das Tool für die Verwaltung nennt sich „Auditpol.exe“ und ist im Lieferumfang von Windows Vista dabei. Für uneingeschränkten Zugriff muss die Eingabeaufforderung zur Ausführung des Tools mit erhöhten Rechten gestartet werden. Die Hauptkategorien unterscheiden sich nicht von denjenigen, die wir uns zuvor in den Gruppenrichtlinien angesehen haben (mit Ausnahme der leicht abweichenden Bezeichnungen). Sofort ist aber ersichtlich, dass die Überwachung hier sehr viel detaillierter erfolgen kann, beispielsweise durch Aktivierung einer Subkategorie anstelle der ganzen Kategorie. Ansonsten sind die Möglichkeiten identisch. Soll die Überwachung beispielsweise für die Subkategorie „IPsec-Schnellmodus“ aktiviert werden, kann dies mit folgendem Befehl umgesetzt werden:

85

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.10 “Auditpol.exe“ für die Überwachungskonfiguration

Abbildung 4.11 Überwachung für eine Subkategorie aktivieren

86

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

4.2

Das verschlüsselte Dateisystem (Encrypting File System, EFS) Bereits seit Windows 2000 bieten Microsoft-Betriebssysteme die Möglichkeit, Dateien auf einer Pro-Benutzer-Basis zu verschlüsseln. Wenn beispielsweise mehrere Personen (mit personifiziertem Login) den gleichen Computer nutzen, ist es verhältnismäßig einfach, vertrauliche Dateien so zu schützen, dass andere Benutzer keinen Zugriff darauf erhalten. Auch für mobile Geräte kann EFS Schutz bieten, beispielsweise dann, wenn sie gestohlen werden und sich vertrauliche Daten darauf befinden. Der Dienst, der sich hinter dieser Sicherheitsfunktion versteckt, nennt sich „verschlüsselndes Dateisystem“ oder englisch „Encrypting File System, EFS“. Seit der ursprünglichen EFS-Implementierung wurde EFS mit jeder Betriebssystemgeneration weiterentwickelt – bis zur heutigen Version unter Windows Vista. Einige wichtige Neuerungen seien hier schon einmal im Voraus aufgeführt: Höhere Sicherheit durch neuen Algorithmus und längere Schlüssel Bessere Leistung und Stabilität Speichern des privaten Schlüssels auf SmartCards Verschlüsseln der Auslagerungsdatei Verbesserter Schutz für Offline-Dateien Detaillierte Konfiguration über Gruppenrichtlinien Das verschlüsselte Dateisystem (EFS) wird nur in den Windows Vista-Editionen Business, Enterprise und Ultimate unterstützt.

Bevor wir uns den EFS-Neuerungen in Windows Vista widmen, möchten wir uns ansehen, wie EFS genau funktioniert. Dies zu verstehen ist essenziell und notwendig, bevor Sie planen, EFS als Feature in Ihrem Unternehmen oder privat einzusetzen. Essenziell ist es deshalb, weil durch falsche Handhabung Daten möglicherweise nicht mehr angezeigt werden können und kein „Hintertürchen“ vorhanden ist, um diese wieder zu entschlüsseln. EFS basiert auf einer symmetrischen Verschlüsselung, die dem AES-Algorithmus (Advanced Encryption Standard) zugrunde liegt und mit Schlüsseln von 256 Bit Länge arbeitet. Symmetrische Verschlüsselung bedeutet, dass für den Verschlüsselungs- und den Entschlüsselungsprozess die identischen Schlüssel genutzt werden. Bei der Verschlüsselung einer Datei wird ein zufälliger symmetrischer Schlüssel (File Encryption Key, FEK) generiert und die Datei damit verschlüsselt. Anschließend wird der symmetrische Schlüssel im Header der Datei gespeichert, was eine spätere Entschlüsselung vereinfacht, weil der Schlüssel immer direkt an der Datei „hängt“.

87

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.12 EFS-Verschlüsselung, Schritt 1

Im nächsten Schritt muss jetzt sichergestellt sein, dass der symmetrische Schlüssel im Header der Datei nicht jedem Benutzer zugänglich ist. Der symmetrische Schlüssel wird deshalb mit einer asynchronen Verschlüsselungstechnik verschlüsselt und im sog. Data Decryption Field (DDF) der Datei gespeichert. Was bedeutet das? Bei der asynchronen Verschlüsselung ist es so, dass für die Verschlüsselung und die Entschlüsselung unterschiedliche Schlüssel benötigt werden. Wenn eine Information verschlüsselt werden soll, kann ein Benutzer dazu einen seiner beiden Schlüssel nutzen. Um die verschlüsselte Information später wieder zu entschlüsseln, benötigt er das entsprechende Gegenstück dazu. Ein Benutzer benötigt daher für den Einsatz von EFS ein solches Schlüsselpaar. Einer dieser Schlüssel wird als öffentlicher Schlüssel (public Key), der andere als privater Schlüssel (private Key) bezeichnet, und obwohl beide Schlüssel total unterschiedlich sind, besteht eine Abhängigkeit. Wichtig an der ganzen Angelegenheit ist, dass ein Benutzer seinen privaten Schlüssel schützt, weil davon die ganze Sicherheit abhängig ist. Fällt dieser Schlüssel jemandem in die Hände, ist die Sicherheit der mit EFS verschlüsselten Daten nicht mehr gewährleistet. Der öffentliche Schlüssel hingegen muss nicht geschützt werden. Im Zusammenhang mit EFS wird jetzt der zufällig generierte symmetrische Schlüssel – der für die Verschlüsselung und Entschlüsselung einer Datei verwendet wird – mit dem öffentlichen Schlüssel des Benutzers verschlüsselt.

88

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.13 EFS-Verschlüsselung, Schritt 2

Nur der Benutzer, der die Datei verschlüsselt hat und über den korrespondierenden privaten Schlüssel verfügt, kann den symmetrischen Schlüssel im Datei-Header wieder entschlüsseln und mithilfe von diesem die Datei entschlüsseln. Sie sehen also, dass die Sicherheit schlussendlich vom privaten Schlüssel des Benutzers abhängig ist, weshalb er niemals in irgendeiner Form weitergegeben werden darf.

Abbildung 4.14 EFS-Entschlüsselung

89

4 Schützen von Daten und Betriebssystemdateien Dieser Prozess ist komplex, aber für den Benutzer vollständig transparent. Wenn ein Benutzer eine verschlüsselte Datei öffnen will, wird diese automatisch entschlüsselt. Der Benutzer kann die Datei anschließend lesen oder modifizieren und wieder speichern. Beim Speichern bzw. Schließen wird die Datei automatisch wieder verschlüsselt. Als Nächstes drängt sich die Frage auf, woher Benutzer die erwähnten Schlüsselpaare bekommen. Schlüsselpaare sind immer an ein digitales Zertifikat gebunden, das einer Person deren Identität attestiert (ähnlich einem Pass oder einer Identitätskarte). Um solche Zertifikate für den EFS-Einsatz zu erhalten, gibt es eigentlich zwei sinnvolle Möglichkeiten: Selbst signierte Zertifikate Zertifizierungsserver (Certification Authority, CA) Selbst signierte Zertifikate sind Zertifikate, die ein Rechner für den aktuell angemeldeten Benutzer ausstellt. Im Falle von EFS bemerkt das System automatisch, dass der angemeldete Benutzer noch kein Zertifikat besitzt, und erstellt automatisch ein neues selbst signiertes Zertifikat mit korrespondierenden privaten Schlüsseln. Das Zertifikat inkl. Schlüssel wird im Benutzerprofil gespeichert und steht ab diesem Zeitpunkt zur Verfügung. Wichtig bei diesem Zertifikat ist, dass es nur für EFS eingesetzt und nicht für andere Zwecke (beispielsweise für die sichere Mailkommunikation) genutzt werden kann. Alternativ zu selbst signierten Zertifikaten kann eine zentrale Zertifikatsserver-Infrastruktur aufgebaut werden, um Zertifikate – unter anderem für den Einsatz von EFS – an Benutzer auszugeben. Um die Ausstellung von Zertifikaten mit einer Zertifizierungsstelle werden wir uns später kümmern. Sehen wir uns zuerst weitere Möglichkeiten von EFS an.

4.2.1

Lösungen ohne Zertifizierungsstelle

Wie aber verschlüsselt ein Benutzer eine Datei? Dies erfolgt direkt über die grafische Oberfläche über die erweiterten Attribut-Eigenschaften einer Datei. Eine Datei kann demnach mit nur wenigen Mausklicks vor unbefugtem Zugriff geschützt werden.

90

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.15 Datei mit EFS verschlüsseln

Beim Übernehmen der Einstellungen muss angegeben werden, ob nur die markierte Datei oder der gesamte Ordner, in dem sich die Datei befindet, verschlüsselt werden soll. Anschließend wird die Datei verschlüsselt und vom Betriebssystem zwecks sofortiger Identifikation farbig (grün) dargestellt. Diese optische Darstellung kann bei Bedarf über die Ordneroptionen deaktiviert werden. Über die Schaltfläche „Details“ lassen sich weitere Informationen zur verschlüsselten Datei anzeigen. Damit diese allerdings aktiv wird, muss der Verschlüsselungsprozess zuerst vollständig abgeschlossen werden, indem die Einstellungen übernommen werden. Über die Details ist einerseits sichtbar, welche Benutzer auf die verschlüsselte Datei Zugriff haben (nur das eigene Benutzerkonto) und ob ein Wiederherstellungsagent existiert, der die Datei bei Bedarf auch wieder entschlüsseln kann.

Abbildung 4.16 Details einer verschlüsselten Datei anzeigen

91

4 Schützen von Daten und Betriebssystemdateien Das Zertifikat wird im Zertifikatsspeicher des Benutzers gespeichert. Dieser lässt sich mit dem Tool „Zertifikatsmanager“ sehr einfach anzeigen. Starten Sie dazu lediglich das Tool „Certmgr.msc“. Alternativ können Sie auch das MMC-Snap-In „Zertifikate“ verwenden und die persönlichen Benutzerzertifikate anzeigen lassen.

Abbildung 4.17 Zertifikatsmanager zur Anzeige persönlicher Zertifikate

Wo werden aber das Zertifikat und der private Schlüssel eines Benutzers physikalisch gespeichert? Das ist wichtig zu wissen, und den Prozess dahinter sollte man verstehen, damit es später zu keinen Überraschungen kommt. Die physikalische Speicherung des Zertifikats (inkl. öffentlicher Schlüssel) erfolgt standardmäßig im Profil des Benutzers. Die Speicherung erfolgt im Klartext, da öffentliche Schlüssel nicht geschützt werden müssen. Anders sieht das bei der Speicherung des privaten Schlüssels aus. Dieser wird ebenfalls im Benutzerprofil abgelegt, aber in gesicherter Form gespeichert. Dazu generiert Windows Vista einen Master Key und verwendet diesen für die Verschlüsselung. Das nächste Problem ist jetzt der Schutz des Master Keys. Auch dieser wird verschlüsselt, diesmal unter Zuhilfenahme von SID und dem Kennwort des Benutzers, und anschließend im Profil des Benutzers gespeichert. Öffnen Sie Ihr Benutzerprofil, und prüfen Sie folgende Informationen: %userprofile%\AppData\Roaming\Microsoft\SystemCertificates\MyCertificates – um die Zertifikate mit entsprechendem öffentlichen Schlüssel eines Benutzers anzuzeigen %userprofile%\AppData\Roaming\Microsoft\Crypto\RSA\Benutzerkonto-SID – um die privaten Schlüssel eines Benutzers anzuzeigen %userprofile%\AppData\Roaming\Microsoft\Protect\Benutzerkonto-SID – um den Master Key eines Benutzers anzuzeigen

92

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.18 Zertifikatsspeicherung im Benutzerprofil

Mit Windows Vista ist es möglich, Benutzerzertifikate (auch solche, die explizit für EFS genutzt werden) auf einer SmartCard zu speichern. Dadurch wird die Sicherheit von verschlüsselten Dateien nochmals erhöht, weil die Schlüssel nicht mehr auf dem Rechner selber gespeichert sind, sondern sich auf einem entfernbaren Medium befinden, das bei jedem Zugriff auf verschlüsselte Dateien eingelegt werden muss.

Ein wichtiger Punkt ist die Wiederherstellung von Schlüsseln bei Verlust. Was passiert, wenn ein Benutzer seinen privaten Schlüssel aus Versehen gelöscht hat? Bei einem Schlüsselverlust kann ein Benutzer nicht mehr auf seine verschlüsselten Dateien zugreifen, und dafür existiert auch kein Workaround, oder doch? Falls verschlüsselte Daten für einen Benutzer nach einem Schlüsselverlust nicht mehr zugänglich sind, besteht auch ohne den Einsatz einer Zertifizierungsstelle die Möglichkeit, die Dateien wieder zu entschlüsseln und zugänglich zu machen. Wie im ersten Teil erklärt, wird bei jeder Dateiverschlüsselung der symmetrische Schlüssel zweimal abgelegt; einmal verschlüsselt mit dem öffentlichen Schlüssel des Benutzers (DDF-Feld), ein zweites Mal verschlüsselt mit dem öffentlichen Schlüssel des Wiederherstellungsagenten (DRF-Feld). Somit hat nicht nur der Benutzer, sondern auch der Wiederherstellungsagent die Möglichkeit, den symmetrischen Schlüssel im Datei-Header zu entschlüsseln und somit die Dateiinhalte anzuzeigen bzw. diese zu entschlüsseln. Standardmäßig ist in einem Domänenbetrieb das Konto des Domänenadministrators als Wiederherstellungsagent eingerichtet. Damit der öffentliche Schlüssel des Wiederherstel-

93

4 Schützen von Daten und Betriebssystemdateien lungsagenten jeder Arbeitsstation in der Domäne zur Verfügung steht, wird dieser mittels Gruppenrichtlinien – standardmäßig über die „Default Domain Policy“ – verteilt. Bearbeiten Sie die „Default Domain Policy“, und navigieren Sie zum Bereich Computerkonfiguration\Windows-Einstellungen\ Sicherheitseinstellungen\Richtlinie öffentlicher Schlüssel\Verschlüsseltes Dateisystem.

Abbildung 4.19 Wiederherstellungsagent in der Default Domain Policy

Prüfen Sie, welches Konto derzeit als Wiederherstellungsagent konfiguriert ist. Dieses Zertifikat inkl. privater Schlüssel ist im Profil des Administrators abgelegt. Falls dieser über ein serverbasiertes Profil verfügt, steht das Wiederherstellungszertifikat für die Dateientschlüsselung überall zur Verfügung. Falls nicht, findet sich das Zertifikat im lokalen Profil desjenigen Geräts, an dem sich der Administrator erstmals in der Domäne angemeldet hat. Dabei handelt es sich um den ersten Controller der Domäne. Falls eine Wiederherstellung notwendig wird, kann sich der Administrator an diesem Gerät anmelden und die Datei entschlüsseln. Wichtig hierbei ist lediglich, dass der Administrator Zugriff auf das Wiederherstellungszertifikat inkl. privatem Schlüssel hat. Bei lokalen Profilen muss das Wiederherstellungszertifikat daher möglicherweise erst exportiert und auf den Rechner, auf dem die verschlüsselten Dateien gespeichert sind, importiert werden. Der Exportassistent für Zertifikate von Windows Vista existiert unter Windows Server 2000/2003 nicht. Der Export erfolgt daher direkt über das Zertifikats-Snap-In (auch für Windows Vista möglich). Zertifikat des Wiederherstellungsagenten exportieren 1. Starten Sie auf demjenigen Gerät, auf dem sich das Zertifikat des Wiederherstellungsagenten befindet, eine Management Console (mmc.exe), und zeigen Sie die persönli-

94

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) chen Zertifikate des Administrators an. Das Wiederherstellungszertifikat wird angezeigt. 2. Zeigen Sie die Eigenschaften des Zertifikats an, und wechseln Sie zum Reiter „Details“. Klicken Sie auf die Schaltfläche „In Datei kopieren“, um den Exportvorgang zu starten.

Abbildung 4.20 Zertifikat des Wiederherstellungsagenten exportieren, Schritt 1

3. Wählen Sie die Option „Ja, privaten Schlüssel exportieren“, und übernehmen Sie anschließend die Standardeinstellungen für das Exportformat.

Abbildung 4.21 Zertifikat des Wiederherstellungsagenten exportieren, Schritt 2

95

4 Schützen von Daten und Betriebssystemdateien 4. Legen Sie ein Kennwort fest, um die Datei zu schützen, und geben Sie an, wo die Speicherung erfolgen soll. Danach ist der Exportprozess abgeschlossen. Zertifikat des Wiederherstellungsagenten importieren 1. Das exportierte Zertifikat kann auf jedem beliebigen Rechner importiert werden (dort, wo sich die verschlüsselten Daten befinden, die entschlüsselt werden müssen). Melden Sie sich dazu mit dem Konto des Domänenadministrators an, und führen Sie einen Doppelklick auf die Datei aus. 2. Nach dem Start des Importvorgangs muss zuerst das Kennwort für die Datei angegeben werden. 3. Legen Sie anschließend fest, ob der private Schlüssel nach erfolgreichem Import von diesem Gerät wieder exportiert werden darf. Da normalerweise das Zertifikat des Wiederherstellungsagenten sofort nach der Dateientschlüsselung wieder gelöscht wird, spielt diese Option eine nicht allzu wichtige Rolle. Sicherheitshalber sollte die Option „Schlüssel als exportierbar markieren “ nicht ausgewählt werden. 4. Legen Sie abschließend fest, wo das zu importierende Zertifikat gespeichert werden soll. Wählen Sie dazu den Zertifikatsspeicher „Eigene Zertifikate“.

Abbildung 4.22 Zertifikat importieren

5. Schließen Sie den Assistenten ab, und prüfen Sie anschließend, ob Dateien auf dem lokalen Gerät geöffnet und entschlüsselt werden können. Dies müsste nach erfolgtem Import einwandfrei funktionieren.

96

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) Denken Sie daran, das Zertifikats des Wiederherstellungsagenten nach erfolgter Entschlüsselung sicherheitshalber wieder vom Gerät zu löschen. Einfacher wird der Prozess, wenn das Zertifikat und der private Schlüssel des Widerherstellungsagenten auf einer SmartCard gespeichert werden. Dann entfällt der Export- und Importvorgang vollständig, und nach dem Entfernen der SmartCard sind die Informationen auf dem entsprechenden Gerät nicht mehr verfügbar.

Benutzerzertifikate sichern Was aber, wenn kein Wiederherstellungsagent existiert oder Sie nicht in einer Domäne arbeiten? Dann empfiehlt es sich, das eigene Zertifikat inkl. privatem Schlüssel zu sichern und an einem sicheren Ort abzulegen. Die Sicherung kann über verschiedene Werkzeuge erfolgen, beispielsweise über den Zertifikatsmanager (Certmgr.msc) oder das ZertifikatsSnap-In. Das Vorgehen zur Sicherung der Zertifikats inkl. privatem Schlüssel ist dabei dentisch zum Exportvorgang des Zertifikats des Wiederherstellungsagenten, der zuvor beschrieben worden ist. Dieser Vorgang ist für Benutzer aber vielleicht zu komplex und undurchsichtig, und deshalb bietet Windows Vista noch eine weitere Möglichkeit des Zertifikatsexports. 1. Melden Sie sich mit dem Benutzerkonto an, und wechseln Sie zur Systemsteuerung. 2. Wählen Sie den Menüpunkt „Benutzerkonten“ und anschließend noch einmal „Benutzerkonten“. 3. Über die Aufgabe „Dateiverschlüsselungszertifikate verwalten“ lassen sich Benutzerzertifikate sichern. Wählen Sie das gewünschte Zertifikat aus (falls mehrere vorhanden sind, was aber eigentlich nicht der Fall sein sollte).

Abbildung 4.23 Benutzerzertifikat exportieren, Teil 1

97

4 Schützen von Daten und Betriebssystemdateien 4. Legen Sie einen Speicherpfad und ein Kennwort fest, und schließen Sie den Assistenten ab.

Abbildung 4.24 Benutzerzertifikat exportieren, Teil 2

5. Bewahren Sie die Datei an einem sicheren Ort auf. Denken Sie zudem daran, dass für einen späteren Import das angegebene Kennwort eingegeben werden muss. Um die Datei zu importieren, führen Sie lediglich einen Doppelklick darauf aus und folgen dem Assistenten (analog zum Import des Zertifikats des Wiederherstellungsagenten).

4.2.2

Lösungen mit einer Windows Server-Zertifizierungsstelle

Wie Sie gesehen haben, kommen Sie für den Einsatz ohne EFS ganz gut ohne Zertifizierungsstelle aus. Allerdings bietet der Einsatz einer solchen verschiedene Vorteile, und dazu gehören diese: Zentrale Archivierung von privaten (und öffentlichen) Schlüsseln Zentrale Übersicht ausgegebener Schlüssel Automatische Veröffentlichung von öffentlichen Schlüsseln im Active Directory Zertifikate können auch für andere Einsatzzwecke ausgegeben werden. Wenn Sie einen Zertifizierungsserver im produktiven Umfeld einsetzen, sollten Sie unbedingt darauf achten, dass Sie als Basis die Enterprise Edition von Windows Server 2003 einsetzen. Nur dann stehen alle Möglichkeiten der Zertifikatsdienste uneingeschränkt zur Verfügung.

Beim Einsatz einer Zertifizierungsstelle können ausgegebene EFS-Zertifikate inkl. privatem Schlüssel zentral archiviert werden – und somit haben wir schon den wichtigsten Vorteil angesprochen. Im Falle eines Zertifikats- bzw. Schlüsselverlusts ist eine einfache Wiederherstellung der Information aus der zentralen Zertifikatsdatenbank möglich. Benutzer

98

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) müssen dadurch ihre persönlichen Zertifikate nicht mehr selber sichern, wodurch ihnen eine wichtige Aufgabe abgenommen wird. Der Administrator hat zudem jederzeit eine Übersicht, welche Benutzer bereits über Zertifikate verfügen. Ohne Zertifizierungsstelle ist keine Kontrolle möglich, und man betreibt die EFS-Infrastruktur „blind“. Für bestimmte Einsatzgebiete kann es sehr interessant sein, öffentliche Schlüssel von Benutzern im Active Directory zu veröffentlichen. Im Zusammenhang mit EFS wäre es beispielsweise möglich, eine verschlüsselte Datei noch anderen Benutzern zugänglich zu machen. Dazu muss lediglich der öffentliche Schlüssel dieses Benutzers zugänglich sein, sodass der File Encryption Key ein weiteres Mal verschlüsselt und an die Datei angehängt werden kann. Nebst dem Benutzer, der die Datei verschlüsselt hat, und dem Wiederherstellungsagenten können so noch beliebige andere Benutzer auf die Datei zugreifen und sie entschlüsseln. Aber wie gesagt, das geht nur dann, wenn ein Benutzer Zugriff auf öffentliche Schlüssel von anderen Benutzern hat. Mithilfe einer Zertifizierungsstelle können diese nun automatisch im Active Directory veröffentlicht werden, sodass jeder Benutzer auf alle öffentlichen Schlüssel sämtlicher Mitarbeiter Zugriff hat. Das bringt auch bei anderen Einsatzgebieten einen entscheidenden Vorteil, beispielsweise bei der sicheren E-MailKommunikation. Zu guter Letzt können mithilfe einer Zertifizierungsstelle natürlich auch Zertifikate für andere Einsatzgebiete ausgestellt werden, und davon gibt es eine ganze Menge. EFS ist einer der wenigen Dienste, die sich selber bei Bedarf mit einem Zertifikat ausrüsten. Viele andere Dienste verfügen nicht über diese Eigenschaft und sind daher abhängig von einer Zertifizierungsstelle. Obwohl es auf den ersten Blick einfach aussieht, sind die Planung sowie der professionelle und sichere Betrieb einer Zertifizierungsstelle ein komplexes Vorhaben. Ich lege Ihnen ans Herz, sich vor einem entsprechenden Einsatz mit dieser Thematik vertraut zu machen, damit es zu keinen bösen Überraschungen kommt. In diesem Buch zeige ich Ihnen die wichtigsten Handgriffe im Zusammenhang mit EFS auf, diese allein reichen aber bei Weitem nicht aus, um eine Zertifizierungsstelle in der Praxis professionell zu betreiben. Für die folgenden Beispiele wird der Einfachheit halber eine sehr simple ZertifikatsserverInfrastruktur mit nur einem einzigen Zertifikatsserver aufgebaut. Dadurch lassen sich die Szenarien einfach und sinnvoll demonstrieren. Installation des Zertifikatsservers Der benötigte Dienst wird bei Windows Server 2003 mitgeliefert, er muss lediglich hinzugefügt und konfiguriert werden. Verwenden Sie dazu unbedingt die Enterprise Edition von Windows Server 2003, weil sonst wichtige Einstellungen nicht vorgenommen werden können. 1. Melden Sie sich mit Administratorenrechten an. 2. Wechseln Sie zur Systemsteuerung und dort zur Verwaltung der WindowsKomponenten. Fügen Sie die Komponente „Zertifikatdienste“ hinzu, und legen Sie

99

4 Schützen von Daten und Betriebssystemdateien fest, welchen Zertifizierungsstellentyp Sie für den geplanten Einsatz bevorzugen. Für eine vollautomatische Publizierung von Zertifikaten im Active Directory und der Archivierung von privaten Schlüsseln sollte eine Unternehmens-Zertifizierungsstelle bevorzugt werden. Wählen Sie die entsprechende Option aus, und legen Sie anschließend eine eindeutige und aussagekräftige Bezeichnung für die Zertifizierungsstelle fest.

Abbildung 4.25 Zertifikatsserver installieren, Teil 1

3. Geben Sie den Speicherpfad für die Datenbank und die zugehörigen Protokollierungsdateien an. Diese sollten nach Möglichkeit voneinander getrennt werden, um beste Leistung und vor allem optimale Wiederherstellbarkeit zu ermöglichen. Schließen Sie den Assistenten danach ab.

Abbildung 4.26 Zertifikatsserver installieren, Teil 2

100

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) Konfigurieren von Vorlagen Mithilfe von Zertifikatsvorlagen lässt sich eng kontrollieren, welche Arten von Zertifikaten an welche Benutzer ausgegeben werden dürfen und welche Eigenschaften diese besitzen. Im ersten Schritt muss daher eine korrekte Zertifikatsvorlage für den Einsatz von EFS vorbereitet werden. Standardmäßig ist eine solche Vorlage bereits vorhanden, dabei handelt es sich aber um eine hartcodierte Vorlage, die nicht angepasst werden kann. Deshalb wird eine neue Vorlage auf Basis dieser EFS-Vorlage erstellt. Falls bei auszustellenden Zertifikaten eine Archivierung des privaten Schlüssels oder eine automatische Publikation im Active Directory gewünscht wird, kann dies in der neuen Vorlage angegeben werden. Für die Publikation im AD sind keine weiteren Maßnahmen notwendig. Wenn hingegen private Schlüssel archiviert werden sollen, muss angegeben werden, wer berechtigt ist, diese wiederherzustellen. Dabei handelt es sich um einen sehr heiklen Task, weil diese Person theoretisch Zugriff auf alle privaten Schlüssel des Unternehmens hat. Für die Archivierung von privaten Schlüsseln muss daher zuerst ein Benutzer als Schlüsselwiederherstellungsagent (Key Recovery Agent, KRA) bestimmt werden. Dazu benötigt dieser Benutzer ebenfalls ein Zertifikat. 1. Starten Sie das Verwaltungswerkzeug „Zertifizierungsstelle“ für die Verwaltung des neu hinzugefügten Dienstes. Über einen Rechtsklick auf den Container „Zertifikatvorlagen“ können Sie diese unter Auswahl des Menüpunkts „Verwalten“ administrieren. 2. Duplizieren Sie die vorhandene Zertifikatsvorlage „Basis-EFS“ mithilfe des Menüpunkts „Doppelte Vorlage“.

Abbildung 4.27 Zertifikatsvorlage duplizieren

3. Geben Sie eine aussagekräftige Bezeichnung für die neue EFS-Zertifikatsvorlage ein. Legen Sie fest, wie lange Zertifikate, die auf Basis dieser Vorlage ausgestellt werden, gültig sind, und markieren Sie die Option zur automatischen Veröffentlichung der öffentlichen Schlüssel von ausgestellten Zertifikaten.

101

4 Schützen von Daten und Betriebssystemdateien 4. Wechseln Sie zum Reiter „Anforderungsverarbeitung“, und markieren Sie die Option „Private Schlüssel für die Verschlüsselung archivieren“.

Abbildung 4.28 Zertifikatsvorlage konfigurieren

5. Nachdem die neue Vorlage vorbereitet ist, muss die Zertifizierungsstelle nun so konfiguriert werden, dass sie Zertifikate auf Basis dieser Vorlage ausstellen darf. Wechseln Sie dazu zurück zur Konsole „Zertifizierungsstelle“, und löschen Sie im Container „Zertifikatvorlagen“ alle angezeigten Vorlagen. Fügen Sie anschließend über den Menüpunkt „Neu, Auszustellende Zertifikatsvorlage“ die neue Vorlage sowie die Vorlage „Schlüsselwiederherstellungs-Agent“ hinzu.

Abbildung 4.29 Zertifikatsvorlagen hinzufügen

102

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) Zertifikat für Key Recovery Agent ausstellen Nachdem die Zertifikatsvorlagen vorbereitet sind, können ab jetzt Zertifikate basierend auf den verfügbaren Vorlagen ausgestellt werden. Bevor allerdings Benutzerzertifikate ausgegeben werden können, deren privater Schlüssel archiviert werden soll, muss zwingend festgelegt werden, bei welchem Benutzer es sich um den Key Recovery Agent handelt. Erst wenn der Zertifizierungsstelle diese Information bekannt gemacht worden ist, können private Schlüssel archiviert werden. In diesem Beispiel wird gezeigt, wie der DomänenAdministrator ein solches Zertifikat beschaffen kann. 1. Melden Sie sich mit dem Konto des Domänenadministrators an, am besten direkt auf der Zertifizierungsstelle. 2. Verbinden Sie sich auf die Webseite http://Servername/certsrv, wobei Servername dem Namen Ihrer Zertifizierungsstelle entspricht. Melden Sie sich mit den entsprechenden Anmeldeinformationen des Domänenadministrators an der Webseite an. 3. Wählen Sie auf der Startseite den Menüpunkt „Ein Zertifikat anfordern“ und auf der Folgeseite „Eine Anforderung an diese Zertifizierungsstelle erstellen und einreichen“.

Abbildung 4.30 Zertifikat für Key Recovery Agent beantragen, Teil 1

4. Wählen Sie als Zertifikatsvorlage „Schlüsselwiederherstellungs-Agent“ aus, und klicken Sie anschließend auf die Schaltfläche „Einsenden“.

103

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.31 Zertifikat für Key Recovery Agent beantragen, Teil 2

5. Nachdem die Anfrage übermittelt ist, muss der Zertifizierungsstellen-Administrator die Anfrage prüfen und freigeben. Erst dann kann das Zertifikat für die Schlüsselwiederherstellung installiert werden. 6. Wechseln Sie zur Konsole „Zertifizierungsstelle“, und navigieren Sie zum Container „Ausstehende Anforderungen“. Geben Sie das angeforderte Zertifikat über den Menüpunkt „Ausstellen“ frei.

Abbildung 4.32 Beantragtes Zertifikat freigeben

104

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) 7. Wechseln Sie erneut zum Browser, und verbinden Sie sich mit der Zertifizierungsstellen-Webseite (http://Servername/certsrv). 8. Wählen Sie auf der Startseite den Menüpunkt „Status ausstehender Zertifikate anzeigen“. Die zuvor eingereichte Anfrage wird angezeigt. Klicken Sie auf den Link, um das Zertifikat auszustellen und anschließend zu installieren.

Abbildung 4.33 Bestätigtes Zertifikat abholen und installieren

9. Im nächsten Schritt muss die Zertifizierungsstelle informiert werden, welcher Benutzer als Schlüsselwiederherstellungs-Agent agiert. Dazu muss das entsprechende Zertifikat dieses Benutzers angegeben werden, sodass es für spätere Wiederherstellungen von privaten Schlüsseln eingesetzt werden kann.

Abbildung 4.34 Key Recovery Agent festlegen

105

4 Schützen von Daten und Betriebssystemdateien 10. Wechseln Sie zur Konsole „Zertifizierungsstelle“, und zeigen Sie die Eigenschaften Ihres Servers an. 11. Wechseln Sie zum Reiter „Wiederherstellungs-Agenten“, und aktivieren Sie die Archivierung. Geben Sie das Zertifikat des einzigen Schlüsselwiederherstellungs-Agenten an. 12. Bestätigen Sie die Information, dass die Zertifikatdienste neu gestartet werden müssen. Wenn dies erfolgt ist, ist die Zertifizierungsstelle für die Archivierung von privaten Schlüsseln bereit. Es ist möglich, mit mehreren Schlüsselwiederherstellungs-Agenten zu arbeiten. Beispielsweise kann angegeben werden, dass für eine Wiederherstellung eines privaten Schlüssels zwei Agenten verfügbar sein müssen. Nur wenn beide Agenten ihr Zertifikat installieren bzw. auf einer SmartCard mitbringen, ist eine Wiederherstellung möglich.

Wenn die Zertifizierungsstelle ein Problem mit dem Zertifikat des Key Recovery Agents hat (beispielsweise wenn es nicht korrekt geladen und rot dargestellt wird), können keine Zertifikate ausgegeben werden, bei denen die Zertifikatsvorlage eine Archivierung des privaten Schlüssels vorgibt. Zertifikate für Benutzer ausstellen Als letzter Konfigurationsschritt müssen Zertifikate basierend auf der neuen Vorlage an Benutzer ausgestellt werden. Dafür stehen verschiedene Möglichkeiten zur Verfügung: Bezug über die Zertifikatsserver-Website Bezug über den Zertifikatsmanager oder das Zertifikats-Snap-In Automatische Zuweisung über Gruppenrichtlinien Von Windows Vista her kann standardmäßig nicht auf die Webseite für den Bezug von Zertifikaten zugegriffen werden. Prüfen Sie dazu den Microsoft-Artikel KB922706.

Die ersten Methoden bedeuten Handarbeit für Benutzer, die Zuweisung von Zertifikaten sollte aber soweit möglich automatisiert werden. Daher werden wir die dritte Methode verwenden, um Zertifikate basierend auf der neuen Vorlage auszurollen. Es sind lediglich zwei kleine Konfigurationsschritte notwendig, damit der Zertifizierungsserver automatisch Zertifikate an die entsprechenden Benutzer verteilt. Wechseln Sie zur Verwaltung der Zertifikatsvorlagen. Legen Sie über den Reiter „Sicherheit“ fest, dass Zertifikate basierend auf dieser Vorlage für bestimmte Benutzer automatisch ausgerollt werden können. Damit dieser Vorgang einwandfrei funktioniert, muss die Gruppe (oder natürlich ein einzelnes Benutzerkonto) die Rechte „Lesen“, „Registrieren“ und „Automatisch registrieren“ besitzen.

106

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.35 Automatische Zuweisung konfigurieren, Teil 1

Zum Abschluss wird mithilfe einer Gruppenrichtlinie gesteuert, wie die automatische Verteilung genau erfolgen soll. Editieren Sie dazu eine beliebige Richtlinie (z.B. die Default Domain Policy, falls alle Benutzer mit einem solchen Zertifikat ausgerüstet werden sollen). Navigieren Sie zum Bereich Benutzerkonfiguration\Windows-Einstellungen\ Sicherheiteinstellungen\Richtlinien öffentlicher Schlüssel\Einstellung für die automatische Registrierung. Nehmen Sie die Einstellungen wie im folgenden Screenshot gezeigt vor:

Abbildung 4.36 Automatische Zuweisung konfigurieren, Teil 2

107

4 Schützen von Daten und Betriebssystemdateien Wenn Benutzer sich das nächste Mal anmelden, werden sie automatisch mit dem gewünschten Zertifikat ausgerüstet. Dabei wird der private Schlüssel archiviert und der öffentliche Schlüssel im Active Directory veröffentlicht. Archivierte private Schlüssel verwalten Nachdem Zertifikate auf Basis der neuen Vorlage ausgestellt worden sind, kann auf der Zertifizierungsstelle angezeigt werden, ob tatsächlich eine Schlüsselarchivierung erfolgt ist. Starten Sie die Konsole „Zertifizierungsstelle“, und wechseln Sie zum Bereich „Ausgestellte Zertifikate“. Blenden Sie über das Menü „Ansicht“ und „Spalten hinzufügen/entfernen“ die Spalte „Archivierter Schlüssel“ ein.

Abbildung 4.37 Archivierte Schlüssel anzeigen

Bei einem Schlüsselverlust kann der archivierte private Schlüssel wieder aus der Zertifizierungsstellen-Datenbank extrahiert und dem Benutzer übergeben werden. 1. Stellen Sie sicher, dass Sie mit einem Konto angemeldet sind, das einerseits über Administrationsrechte der Zertifizierungsstelle verfügt, andererseits über ein installiertes und gültiges Schlüsselwiederherstellungs-Agenten-Zertifikat verfügt. Starten Sie die Konsole „Zertifizierungsstelle“. 2. Suchen Sie das Zertifikat, dessen privater Schlüssel wiederhergestellt werden muss, und zeigen Sie dessen Eigenschaften an. Wechseln Sie zum Reiter „Details“, und kopieren Sie die Seriennummer des Zertifikats. 3. Extrahieren Sie mit dem Tool „Certutil.exe“ aus der Zertifizierungsstellen-Datenbank das relevante Zertifikats- und Schlüsselmaterial. Diese Information wird dabei in einer Datei in verschlüsselter Form abgelegt.

108

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.38 Schlüsselwiederherstellung, Teil 1

4. Aus den extrahierten Informationen kann abschließend ein neues Zertifikat mit gebundenem privaten Schlüssel erstellt werden. Diese Datei muss der Benutzer noch importieren, danach verfügt er wieder um die relevanten Informationen, um seine Dateien entschlüsseln zu können.

Abbildung 4.39 Schlüsselwiederherstellung, Teil 2

109

4 Schützen von Daten und Betriebssystemdateien Veröffentlichte Zertifikate im Active Directory Zertifikate auf Basis unserer Vorlage werden automatisch im Active Directory veröffentlicht. Dies kann über die Konsole „Active Directory-Benutzer und -Computer“ geprüft werden. Zeigen Sie dazu über das Menü „Ansicht“ die erweiterten Funktionen an. Navigieren Sie zu einem Benutzerkonto, das bereits über ein Zertifikat verfügt, und wechseln Sie zum Reiter „Veröffentlichte Zertifikate“. Die veröffentlichten Informationen werden angezeigt.

Abbildung 4.40 Veröffentlichte Zertifikate anzeigen

Zertifikate können auch manuell veröffentlicht werden. Der Aufwand ist aber bereits bei einer kleinen Benutzerzahl recht groß, weil ein Administrator zuerst an alle öffentlichen Schlüssel kommen und diese anschließend einzelnen veröffentlichen muss.

Wenn verschlüsselte Dateien auch noch anderen Benutzern zugänglich gemacht werden sollen, kann dies nun mithilfe dieser veröffentlichten Information realisiert werden. Dazu muss lediglich über die Detailansicht einer verschlüsselten Datei angegeben werden, welchen Benutzern Zugriffsrechte erteilt werden sollen, und die jeweiligen öffentlichen Schlüssel müssen angegeben werden. Die Benutzerzertifikate können über die Schaltfläche „Benutzer suchen“ im Active Directory gesucht und anschließend angegeben werden.

110

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.41 Anderen Benutzern Zugriff auf verschlüsselte Dateien gewähren.

Ab diesem Zeitpunkt hat der neu hinzugefügte Benutzer ebenfalls Zugriff auf die verschlüsselte Datei. Einige Punkte gibt es allerdings noch zu beachten: Bei den Konten, die Dateien freigeben bzw. auf freigegebene EFS-Dateien zugreifen, darf es sich nicht um Administratorenkonten handeln, weil deren Identität nicht delegiert werden kann. Vorzugsweise sollten serverbasierte Profile eingesetzt werden, wenn die EFSVerschlüsselung eingesetzt wird. Wenn Daten auf einem Remote-Computer verschlüsselt und freigegeben werden (z.B. auf einem Server), muss dem Konto für Delegationszwecke vertraut werden.

111

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.42 Computer für Delegationszwecke vertrauen

Seit Windows Vista können nun auch Offline-Dateien und die Auslagerungsdatei mit EFS verschlüsselt werden. Beide Szenarien machen Sinn, weil dadurch sensitive Daten geschützt werden. Bei Offline-Dateien handelt es sich um Firmendaten, die auf mobile Clients synchronisiert werden und vermutlich die Firma verlassen. Damit diese Daten geschützt sind, auch wenn sich der mobile Client mit fremden Netzwerken verbindet, macht eine Verschlüsselung Sinn. Die Auslagerungsdatei enthält ebenfalls sensitive Informationen und sollte auch geschützt werden. Bisher wurde dazu die Option angeboten, die Auslagerungsdatei beim Herunterfahren eines Geräts explizit zu löschen. Das klappt bestens, nimmt aber viel Zeit in Anspruch. Wenn die Datei hingegen verschlüsselt ist, sind die Daten darin auch geschützt, und eine Löschung ist daher nicht mehr notwendig.

4.2.3

Steuerung über Gruppenrichtlinien

Wie fast alle Funktionen lässt sich auch EFS über Gruppenrichtlinien konfigurieren, und die wichtigsten möchte ich Ihnen aufzeigen. Navigieren Sie dazu zum Bereich Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Richtlinien für öffentliche Schlüssel, und zeigen Sie die Eigenschaften des Ordners „Verschlüsseltes Dateisystem“ an.

112

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS)

Abbildung 4.43 Konfiguration über Gruppenrichtlinien, Teil 1

Option

Beschreibung

DatenwiederherstellungsAgenten hinzufügen

Falls Sie bereits ein Zertifikat für einen Wiederherstellungsagenten besitzen und diesen mithilfe einer Richtlinie an Clients verteilen möchten, kann das entsprechende Zertifikat hier hinzugefügt werden.

DatenwiederherstellungsAgenten erstellen

Falls ein neuer Wiederherstellungsagent festgelegt werden soll, kann über diese Option direkt bei einem Zertifikatsserver ein neues Zertifikat beschafft werden. Dazu muss auf dem Zertifikatsserver eine entsprechende Zertifikatsvorlage vorhanden sein.

113

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.44 Konfiguration über Gruppenrichtlinien, Teil 2

Option

Beschreibung

Inhalt des Ordners „Dokumente“ des Benutzers verschlüsseln

Diese Option verschlüsselt automatisch die persönlichen Do-

SmartCard für EFS verlangen

Mithilfe dieser Option kann erzwungen werden, dass für die

kumente eines Benutzers.

EFS-Verschlüsselung zwingend eine SmartCard verwendet werden muss. Dazu ist eine entsprechende Infrastruktur notwendig. Zwischenspeicherfähigen Benutzerschlüssel von SmartCard erstellen

Diese Option legt fest, ob Schlüssel, die sich auf einer SmartCard befinden, in den Cache geladen werden dürfen und so während der gesamten Sitzung zur Verfügung stehen oder ob diese bei jeder Verwendung erneut eingelesen werden müssen.

Auslagerungsdateiverschlüsselung aktivieren

Wenn die Auslagerungsdatei verschlüsselt werden soll, muss diese Option aktiviert werden. Das macht vorwiegend bei mobilen Geräten Sinn oder aber bei solchen, die nie ausgeschaltet werden.

Schlüsselsicherungsbenachrichtigung verlangen, wenn der Benutzerschlüssel erstellt oder geändert wird

Mit dieser Option wird der Benutzer benachrichtigt, dass er sein Zertifikat und privaten Schlüssel sichern sollte. Eine Anzeige erfolgt dann, wenn ein neues Zertifikat ausgegeben bzw. ein Zertifikat erneuert worden ist.

114

4.2 Das verschlüsselte Dateisystem (Encrypting File System, EFS) Option

Beschreibung

Bei nicht verfügbarer Zertifizierungsstelle EFS gestatten, selbst signierte Zertifikate zu erzeugen

Diese Option sollten Sie beim Einsatz einer Zertifizierungsstelle nicht verwenden, weil sonst Inkonsistenzen auftreten könnten. Wenn beispielsweise anhand einer Zertifikatsvorlage festgelegt worden ist, dass private Schlüssel archiviert werden sollen, wird dies für selbst signierte Zertifikate nicht der Fall sein. Besser ist es in diesem Fall, dem Benutzer keine Verschlüsselung mit EFS zu ermöglichen. Falls die Option genutzt wird, kann die Schlüssellänge festgelegt werden (mind. 2048 Bit empfohlen).

EFS-Vorlage für automatische Zertifikatsanforderung

Falls ein Zertifikatsserver eingesetzt und ausschließlich EFSZertifikate ausgegeben werden, kann auf die Funktion der automatischen Registrierung verzichtet und dafür diese Konfiguration eingesetzt werden. Wenn ein Benutzer ohne EFSZertifikat zum ersten Mal eine Verschlüsselung vornimmt, wird Windows Vista automatisch eine UnternehmensZertifizierungsstelle suchen und dort ein Zertifikat anfordern. Damit das Betriebssystem weiß, welche Vorlage dafür relevant ist, muss diese hier spezifiziert werden.

Weitere Gruppenrichtlinieneinstellungen zu diesem Thema sind quer über alle Bereiche verstreut. Anbei finden Sie eine Zusammenstellung der wichtigsten Einstellungen:

Richtlinie

Beschreibung

Computerkonfiguration\ Administrative Vorlagen\ Netzwerk\Offlinedateien\ Offlinedateicache verschlüsseln

Diese Einstellung sollte für Notebooks, die nicht mit BitLocker

Computerkonfiguration\ Administrative Vorlagen\System\ Dateien, die in verschlüsselte Ordner verschoben werden, nicht automatisch verschlüsseln

Wenn ein Ordner mit EFS gesichert wird, werden alle Dateien

Computerkonfiguration\ Administrative Vorlagen\System\ Gruppenrichtlinien\Verarbeitung der Richtlinien für die EFSWiederherstellung

Über diese Richtlinie kann detailliert festgelegt werden, wie

ausgerüstet sind, unbedingt aktiviert werden, um Firmendaten optimal zu schützen.

und Ordner, die darin erstellt bzw. in diesen Ordner kopiert werden, automatisch verschlüsselt. Dieses Verhalten kann mit dieser Richtlinie geändert werden.

EFS-Richtlinien an Clients zugewiesen werden. Beispielsweise kann angegeben werden, ob EFS-Richtlinien auch über langsame Verbindungen (standardmäßig < 500 kbps) oder ob Änderungen während des laufenden Betriebs oder erst bei einem Neustart zugewiesen werden sollen.

115

4 Schützen von Daten und Betriebssystemdateien Es gibt noch einige weitere Richtlinien, aber die wichtigsten sind mit den angegebenen abgedeckt.

4.2.4

Noch etwas zum Abschluss von EFS

Die Sicherheit von EFS ist abhängig vom Benutzerkennwort, weil unter anderem damit der Master Key im Benutzerprofil gespeichert ist. Wenn EFS eingesetzt wird, sollten deshalb unbedingt auch starke Benutzerkennwörter verwendet werden. Um dies zu erreichen, sollte eine entsprechende Kennwortrichtlinie seitens der Domäne festgelegt werden. Ein gutes Kennwort sollte (damit es nicht erraten werden kann) aus mindestens acht Zeichen bestehen, komplex sein und regelmäßig (am besten alle 30 Tage) geändert werden.

4.3

Partitionsverschlüsselung mit BitLocker Mit Windows Vista ist eine neue Funktion mit der Bezeichnung „BitLocker“ eingeführt worden. Damit wird die Sicherheit von Daten und Systemobjekten noch einmal deutlich erweitert, weil mithilfe dieser Funktion die gesamte Partition, welche die Windows VistaInstallation enthält, verschlüsselt werden kann. Mit EFS ist es auch möglich, Daten zu verschlüsseln, allerdings ist diese Funktion für gezielte Dateiverschlüsselung vorgesehen, nicht aber für die Verschlüsselung der gesamten Betriebssystempartition. Hier setzt jetzt BitLocker an. Die Verschlüsselung mit BitLocker wird nur in den Windows Vista-Editionen Enterprise und Ultimate unterstützt.

Die Frage, die sich stellt, ist natürlich, in welchen Szenarien BitLocker tatsächlich Sinn macht. Alle bisher gezeigten Möglichkeiten, das Betriebssystem zu schützen, funktionieren einwandfrei, aber sie sind dazu gedacht, Online-Angriffe auf ein System abzuwehren. Beispielsweise sind NTFS-Rechte wertlos, wenn jemand eine Festplatte physikalisch entwenden kann. Es bestehen verschiedene Möglichkeiten, eine Festplatte offline anzugreifen, beispielsweise indem sie in einem fremden Rechner als sekundäre Harddisk eingebunden und als normale Datendisk angesprochen wird. Weil das „neue“ Betriebssystem jetzt die Zugriffe auf die Daten steuert, können alle NTFS-Rechte übersteuert werden. Ein bisschen besser sieht es aus, wenn heikle Dateien in einem solchen Szenario mit EFS verschlüsselt worden sind. Das Problem ist aber, dass die Schlüssel in Benutzerprofilen abgelegt sind, die sich ebenfalls auf der Festplatte befinden (das ist nicht der Fall, wenn für EFS ausschließlich mit SmartCards gearbeitet wird). Die Schlüssel in den Benutzerprofilen sind zwar auch gesichert, aber da es sich um einen Offline-Angriff handelt, hat der Angreifer alle Zeit dieser Welt, um die Benutzerkennwörter – die verwendet werden, um die Schlüssel zu schützen – anzugreifen. Wenn Benutzer schlechte Kennwörter verwenden, können diese unter Umständen offline geknackt werden, wodurch die Schlüssel im Benutzerprofil

116

4.3 Partitionsverschlüsselung mit BitLocker und daher auch die mit EFS geschützten Daten entschlüsselt werden können. Sie erinnern sich? Ich hatte im letzten Abschnitt erwähnt, dass für sicheres EFS starke Benutzerkennwörter eingesetzt werden müssen. Das hier ist der Grund, weshalb das so sein sollte. Aber gegen was schützt denn jetzt BitLocker genau? Eigentlich werden zwei Bereiche geschützt. Einerseits wird die gesamte Partition, auf der Windows Vista installiert ist, verschlüsselt. Das schützt alle Betriebssystemdateien inkl. Benutzerprofile, Offline-Dateien, Auslagerungsdateien usw. Gleichzeitig kann (je nach verfügbarer Hardware) auch die Integrität von Komponenten, die zum Start von Windows Vista relevant sind (beispielsweise das BIOS), überprüft werden, also sichergestellt werden, dass keine unautorisierten Änderungen am System vorgenommen worden sind. Die beiden Schutzmechanismen schützen ein System optimal vor Offline-Angriffen, und nur davor! BitLocker schützt vor Offline-Angriffen. Wenn das System erst einmal gestartet ist, bietet die Funktion keinen Schutz mehr. Dann müssen andere Komponenten wie NTFS-Rechte oder EFS-Verschlüsselung eingesetzt werden, um Informationen zu schützen.

BitLocker kommt deshalb vorwiegend dort zum Zug, wo Geräte entwendet werden oder verloren gehen könnten, und das sind mobile Geräte. Natürlich kann BitLocker auch im Desktop-Bereich eingesetzt werden, vielleicht dann, wenn sie an unsicheren, öffentlichen Orten platziert sind. Mit Windows Server 2008 (ehemals „Longhorn“) wird BitLocker ebenfalls ausgeliefert, sodass auch serverseitig eine komplette Verschlüsselung der Installationspartition möglich ist. Ein wichtiger Punkt ist bei der ganzen Euphorie zu beachten: Wenn BitLocker eingesetzt werden soll, muss das System über zwei Partitionen verfügen. Eine (kleine) Partition enthält die Startdateien von Windows (die Systempartition), die andere Partition enthält die Windows Vista-Systemdateien (die Bootpartition). Zugegeben, die Bezeichnungen sind mehr als verwirrend, aber das sind halt die Bezeichnungen, die Microsoft seit Jahren verwendet. Die Systempartition ist die aktive Partition und diejenige, von der bei einem Systemstart die ersten Dateien gelesen werden. Darauf befindet sich auch der Windows Vista Bootmanager, der sämtliche Betriebssysteminstallationen des lokalen Geräts kennt und sie beim Systemstart zur Auswahl anbietet. Für die aktive Systempartition wird eine Größe von 1.5 GB empfohlen. Darauf werden lediglich die Startdateien von Windows Vista abgelegt, die nicht verschlüsselt werden. Deshalb sollten auf dieser Partition – selbst wenn noch freie Kapazität vorhanden ist – keine Dateien abgelegt werden. Falls Sie dies doch tun, kann BitLocker diese nicht schützen. Die Partition, auf der Windows Vista installiert ist, wird fast vollständig verschlüsselt und daher geschützt. Zwei Bereiche bleiben unverschlüsselt, nämlich der Bootsektor und die Metadaten. In diesen Metadaten werden Informationen abgespeichert, die BitLocker für die Entschlüsselung der Partition benötigt. Details dazu werden wir uns gleich anschauen. BitLocker verwendet einen komplexen Mechanismus, um die Windows Vista-Partition zu verschlüsseln. Zuerst wird ein Volume File Encryption Key (VFEK) generiert, ein 512 Bit langer Schlüssel, der einmalig ist. Davon hängt die ganze Sicherheit der BitLocker-

117

4 Schützen von Daten und Betriebssystemdateien Verschlüsselung ab. Dieser Schlüssel wird in zwei Teile geteilt, und von jedem Schlüsselteil werden 128 Bit für den weiteren Prozess verwendet (obwohl eigentlich 256 Bit zur Verfügung stehen würden). Danach wird für jeden Sektor, der verschlüsselt werden muss, ein eindeutiger Sektorschlüssel kreiert. Dies erfolgt aus einer Kombination aus FVEK und Sektorennummer des zu verschlüsselnden Sektors. Dieser Schlüssel wird gemeinsam mit dem zu verschlüsselnden Sektor behandelt und anschließend mit dem AES-Algorithmus geschützt. Dazu wird allerdings erst noch der zweite Teil des FVEK hinzugefügt. Kompliziert, nicht wahr? Aber das ist bei kryptografischen Prozessen halt nun einmal so.

Abbildung 4.45 BitLocker-Verschlüsselungsschema

Jeder Sektor wird mit einem eigenen Sektorschlüssel behandelt, um sicherzustellen, dass jeder verschlüsselte Sektor abhängig von einem anderen Schlüssel ist. Diese Sektorenschlüssel müssen aber nicht gespeichert werden. Sie werden bei Bedarf wieder aus den Informationen des FVEK und der zu entschlüsselnden Sektorennummer generiert. Was ist aber mit dem FVEK? Davon ist die ganze Sicherheit von BitLocker abhängig. Einerseits muss dieser Schlüssel gut geschützt werden, andererseits darf er nicht verloren gehen, weil sonst keine Entschlüsselung mehr möglich ist. Der FVEK wird deshalb in den Metadaten der Windows Vista-Partition abgelegt, und das gleich dreifach. An drei unterschiedlichen Stellen der Partition wird eine Kopie abgelegt, sodass bei einer allfälligen Beschädigung eines Bereichs immer noch mindestens eine Kopie des FVEK verfügbar ist. Wenn zudem ein Rechner physikalisch zerstört wird (mit Ausnahme der Festplatte), besteht ebenfalls kein Problem. Die Festplatte kann in einen anderen Rechner eingebaut und gestartet werden, und weil der FVEK ja immer noch auf der Disk gespeichert ist, kann auch eine entsprechende Entschlüsselung erfolgen. Damit nicht jeder auf den FVEK zugreifen kann (was eine Entschlüsselung des Systems möglich machen würde), werden alle drei Kopien, die auf der Festplatte gespeichert sind, mit einem weiteren Schlüssel, dem sog. Volume Master Key (VMK), verschlüsselt. Dieser VMK wird ebenfalls in den Metadaten der Windows-Partition abgelegt. Und auch dieser wird noch einmal explizit geschützt. Dafür stellt

118

4.3 Partitionsverschlüsselung mit BitLocker Windows Vista sog. Key Protectors zur Verfügung, die jeweils einzeln oder aber kombiniert eingesetzt werden können. Stufe 1 – Nur TPM-Chip Beim Start von Windows Vista wird vom TPM ein Integritäts-Check vorgenommen, bei dem verschiedene Aspekte überprüft werden. Dazu gehören unter anderem BIOS-Daten, ROM-Codes, Bootsektor-Informationen oder der Master Boot Record. Wenn seit dem letzten Betriebssystemstart Änderungen vorgenommen worden sind, schlägt der IntegritätsCheck fehl, und die TPM-Informationen werden nicht zugänglich gemacht. Diese werden aber benötigt, weil sie als Key Protector für dem VMK konfiguriert sind. Wenn demnach der Integritäts-Check fehlschlägt, kann auch keine Entschlüsselung und daher kein Betriebssystemstart erfolgen. Stufe 2 – Nur USB-Stick Falls kein TPM-Chip im System vorhanden ist, kann BitLocker trotzdem genutzt werden. Der VMK wird dann mit einer Information geschützt, die auf einen USB-Stick gespeichert wird. Dieser USB-Stick muss bei jedem Systemstart angeschlossen werden, um einen erfolgreichen Start zu initiieren. Da bei diesem Szenario kein TPM verwendet wird, findet keine Integritätsprüfung statt. Wenn Sie diese Variante wählen, was Sie allerdings nur tun sollten, wenn Ihr Gerät nicht über einen geeigneten TPM-Chip verfügt, muss zuerst eine Richtlinie aktiviert werden, die den BitLocker-Einsatz ohne TPM zulässt. Die Konfigurationsschritte werden später in diesem Kapitel erläutert. Stellen Sie vor einem Einsatz von BitLocker sicher, dass das BIOS Ihres Rechners diese Funktion unterstützt. Unter Umständen muss das BIOS aktualisiert werden.

Stufe 3 – TPM und PIN Wie bei Stufe 1 wird ein Integritäts-Check vorgenommen und erst dann der VMK entschlüsselt. Allerdings muss bei dieser Variante noch zusätzlich ein PIN eingegeben werden, was eine zusätzliche Sicherheitsschicht einführt. Selbst wenn der gesamte Rechner entwendet wird, kann er nicht gestartet werden, weil die TPM-Informationen mit einem PIN geschützt sind. Stufe 4 – TPM und USB Bei dieser Variante werden TPM und zusätzlich ein USB-Stick benötigt. Dabei handelt es sich um die höchstmögliche Sicherheitsstufe, um den VMK und daher die Windows VistaInstallation und alle Daten zu schützen.

119

4 Schützen von Daten und Betriebssystemdateien Für Windows Vista Service Pack 1 und Windows Server 2008 ist angekündigt, dass ein noch höherer VMK-Schutz mit der Key Protector-Kombination TPN, PIN und USB möglich sein wird.

Was ist TPM ganz genau? Stellen Sie sich das am einfachsten wie eine SmartCard vor, die sich auf dem Motherboard Ihres Rechners befindet. Darin können Informationen abgespeichert und bei Bedarf abgerufen werden. Damit die Informationen im TPM-Chip zusätzlich geschützt sind, können sie mit einem PIN (Stufe3) oder einer Information auf einem USBStick (Stufe 4) gesichert werden. Damit ein TPM-Chip für BitLocker eingesetzt werden kann, muss es sich mindestens um einen Chip der Version 1.2 handeln.

4.3.1

BitLocker einrichten

Es gibt zwei Möglichkeiten, BitLocker einzurichten: wenn Windows Vista neu installiert wird oder nachträglich, falls Windows Vista schon komplett installiert ist. Bei einer Neuinstallation kann die notwendige Partitionierung von zwei Partitionen direkt im Setup-Prozess vorgenommen werden. Dazu wechseln Sie beim Setup zu den Wiederherstellungsoptionen und starten die Eingabeaufforderung. Erstellen Sie mit dem Tool „Diskpart.exe“ zwei neue Partitionen: Partition 1, 1500 MB, Laufwerk S:\, aktiv setzen (auf diese Partition werden die Startdateien platziert) Partition 2, beliebige Größe, z.B.: 20000 MB, Laufwerk C:\ Nach dieser Konfiguration kann Windows Vista „normal“ installiert werden. Wählen Sie als Installationspartition die größere der beiden Partitionen aus. Den Rest erledigt die Setup-Routine. Falls bereits eine Installation vorliegt, ist das Vorgehen ein bisschen mühsamer. Vermutlich wird Windows Vista auf einer einzigen Partition installiert und daher nicht für den BitLocker-Einsatz geeignet sein. Für dieses Szenario stellt Microsoft das Tool „BitLocker Drive Preparation Tool“ zur Verfügung, das die korrekte Partitionierung nachträglich vornimmt. Natürlich können diese Schritte auch manuell ausgeführt werden. Dazu muss zuerst die aktive Partition verkleinert werden (was mit Windows Vista neu möglich ist), dann eine neue Partition von 1500 MB Größe erstellt und formatiert werden. Zuletzt muss die Partition aktiviert und die entsprechenden Startdateien müssen darauf kopiert werden. Damit es zu keinen Fehlern kommt, würde ich Ihnen aber die Nutzung des „BitLocker Drive Preparation Tools“ empfehlen. Dieses Tool wird über Windows Update zur Verfügung gestellt und muss vor der Nutzung explizit heruntergeladen und installiert werden. Starten Sie das Tool, das sich im Ordner Startmenü\Alle Programme\Zubehör\ Systemprogramme\BitLocker befindet. Das Tool wird die notwendigen Änderungen an

120

4.3 Partitionsverschlüsselung mit BitLocker der Partitionierung vornehmen. Nach Abschluss der Änderung muss Windows Vista neu gestartet werden, diesmal bereits ab der neuen aktiven Partition.

Abbildung 4.46 BitLocker-Laufwerkverschlüsselung: Partitionierung vorbereiten

Abbildung 4.47 Neue Partitionierung mit aktiver Partition

121

4 Schützen von Daten und Betriebssystemdateien Nach dem Neustart wird automatisch die BitLocker-Konfigurtionskonsole gestartet, die auch über Systemsteuerung\Sicherheit\BitLocker-Laufwerkverschlüsselung angezeigt werden kann. Da die Partitionierung jetzt BitLocker-konform ist, kann BitLocker für die Partition, auf der Windows Vista installiert ist, aktiviert werden.

Abbildung 4.48 BitLocker aktivieren

Nach dem Anwählen des Menüpunkts „BitLocker aktivieren“ wird festgelegt, welche Systemstartoptionen verwendet werden sollen. Dazu stehen wie bereits erwähnt verschiedene Methoden zur Verfügung, die je nach eingesetztem Gerät genutzt werden können. Geräte ohne TPM-Chip verfügen lediglich über eine Option, wohingegen Geräte mit einem TPMChip die Wahl zwischen drei verschiedenen Methoden haben. Je nach getroffener Auswahl variiert die Speicherung der Startschlüssel (im folgenden Screenshot wird ein USBLaufwerk für die Speicherung des Startschlüssels genutzt). Nach dem Festlegen der Starteinstellungen müssen die Wiederherstellungsmechanismen aktiviert werden. Diese können einzeln oder in Kombination genutzt werden. Sicherheitshalber sollten immer mindestens zwei Speicherorte für das Wiederherstellungskennwort genutzt werden. Je nach ausgewählter Methode muss ein USB-Laufwerk, ein Pfad zu einem Ordner oder ein Drucker angegeben werden.

122

4.3 Partitionsverschlüsselung mit BitLocker

Abbildung 4.49 Systemstarteinstellungen festlegen

Falls Sie sich für die Speicherung in einer Datei entscheiden, darf sich der Ordner, in den die Speicherung erfolgt, nicht auf der mit BitLocker verschlüsselten Partition befinden. Das würde natürlich auch keinen Sinn machen, weil es bei einem Problem mit der Entschlüsselung der Partition nicht zur Verfügung stehen würde. Sinnvoller wäre die Speicherung auf einem Medium, das nicht an das lokale Gerät gebunden ist, also beispielsweise ein Netzlaufwerk, auf das (z.B. mit einem anderen Gerät) einfach zugegriffen werden kann, sobald das Wiederherstellungskennwort benötigt wird.

Wenn die Speicherung der Wiederherstellungskennwörter abgeschlossen ist, kann Windows Vista mit der Verschlüsselung der Festplatte beginnen. Optional haben Sie noch die Möglichkeit, überprüfen zu lassen, ob die Speicherung des Startschlüssels erfolgreich war und ob Ihr System diese Information bei Gerätestart auch tatsächlich auslesen kann. Für diese Prüfung ist ein Neustart erforderlich, und wenn der Startschlüssel tatsächlich gelesen werden konnte, startet Windows Vista anschließend mit der Verschlüsselung der gesamten Partition. Konnte der Startschlüssel nicht gelesen werden, wird die Verschlüsselung nicht gestartet.

123

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.50 Wiederherstellung konfigurieren

Abbildung 4.51 Systemprüfung vor der BitLocker-Aktivierung

124

4.3 Partitionsverschlüsselung mit BitLocker Die Verschlüsselung kann je nach Größe der Partition recht lange dauern, allerdings kann während dieses Vorgangs (mit entsprechenden Leistungseinbußen) mit dem System weitergearbeitet werden. Ist die Verschlüsselung abgeschlossen, ist dies über die BitLockerKonfigurationskonsole in der Systemsteuerung sichtbar. Zudem lassen sich dort jederzeit wieder Systemstart- und Wiederherstellungsschlüssel erstellen.

Abbildung 4.52 BitLocker verwalten

BitLocker kann jederzeit wieder deaktiviert werden, wenn die erhöhte Sicherheit nicht mehr benötigt wird. Die Funktion lässt sich auch temporär ausschalten, was beispielsweise dann Sinn macht, wenn das BIOS des Rechners aktualisiert werden muss. Wenn BitLocker während dieser Phase aktiviert ist, wird auf einem Gerät, das einen TPM-Chip nutzt, die Integritätsprüfung fehlschlagen, weil TPM „denkt“, dass unautorisierte Updates des BIOS vorgenommen worden sind. In diesem Fall müsste eine Wiederherstellung mit den erwähnten Methoden erfolgen, was im Firmenumfeld recht mühsam sein kann. Um das zu realisieren, verwendet Windows Vista einen neuen Schlüssel, der im Klartext abgespeichert wird. Die Daten bleiben im verschlüsselten Zustand, sind allerdings wegen des ungeschützten Schlüssels während dieser Zeit nicht wirklich sicher. Erst nach einer erneuten Aktivierung von BitLocker wird das Kennwort im Klartext wieder erneuert und in verschlüsselter Form abgelegt. Bei einer Entschlüsselung hingegen wird die gesamte Partition entschlüsselt, was wiederum viel Zeit in Anspruch nehmen kann. Diese Methode sollte demnach nur dann eingesetzt werden, wenn BitLocker anschließend nicht mehr verwendet wird.

125

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.53 BitLocker temporär deaktivieren oder Volume entschlüsseln

4.3.2

BitLocker über die Kommandozeile verwalten

Die meisten BitLocker-Einstellungen lassen sich mithilfe des Skripts „manage-bde.wsf“ steuern, einige davon sogar ausschließlich. Bei der klassischen BitLocker-Aktivierung werden beispielsweise nicht alle möglichen Protectors verwendet. Wird beispielsweise TPM verwendet, werden neben TPM lediglich ein USB-Startschlüssel und ein Wiederherstellungskennwort verfügbar gemacht. Die Option, die neben TPN noch einen Schutz mittels PIN ermöglicht, schlägt fehlt. Dies lässt sich nun mithilfe des erwähnten Skripts nachkonfigurieren.

Abbildung 4.54 manage-bde.wsf zur Verwaltung von BitLocker

126

4.3 Partitionsverschlüsselung mit BitLocker Wie Sie in der Hilfe-Anzeige sehen können, lassen sich mithilfe dieses Skripts viele Einstellungen wie beispielsweise das Ein- oder Ausschalten von BitLocker oder aber die Konfiguration von Protectors realisieren. Folgendes Beispiel zeigt das Hinzufügen des Protectors „TPMandPIN“ und die Hinterlegung des vom Benutzer einzugebenden PIN.

Abbildung 4.55 Protector „TPMandPIN“ hinzufügen

4.3.3

Wiederherstellung

Auf Rechnern, die mit BitLocker arbeiten, werden möglicherweise Daten erstellt, bearbeitet und gespeichert. Daher ist es wichtig, dass bei irgendwelchen Problemen mit BitLocker verschiedene Wiederherstellungsmethoden zur Verfügung stehen, um irgendwie eine Entschlüsselung durchführen zu können. Wenn die Betriebssystempartition nicht mehr entschlüsselt werden kann, wird dem Benutzer ein Wiederherstellungsschirm angezeigt, über den mithilfe verschiedener Optionen (wenn sie denn konfiguriert sind) trotzdem eine Entschlüsselung realisiert werden kann. Machen Sie sich Gedanken. Warum kann Windows Vista nicht mehr starten? Falls irgendwas verändert worden ist, beispielsweise wurde eine neue Version des BIOS aufgespielt, könnte es sein, dass der Integritäts-Check fehlschlägt und Windows Vista deshalb nicht mehr gestartet werden kann. Vielleicht können Sie diese Änderungen einfach wieder rückgängig machen, um das Problem zu lösen, vielleicht aber auch nicht. Vielleicht haben Sie aber auch nur vergessen, das USB-Laufwerk, das den Startschlüssel enthält, einzustecken. Oder Sie haben den PIN falsch eingegeben. Windows Vista wird in allen diesen Fällen beim Start des Geräts eine entsprechende Meldung anzeigen, die z.B. wie folgt aussehen könnte:

127

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.56 Probleme bei Windows Vista-Start

Möglicherweise haben Sie nur vergessen, das USB-Laufwerk anzuschließen, das den Startschlüssel enthält. Falls dieser aber wegen Verlust nicht mehr zur Verfügung steht, kann über die Funktion „Wiederherstellung“ auch das 48-stellige Wiederherstellungskennwort eingegeben werden. Sie haben dieses hoffentlich zuvor an unterschiedlichen Orten aufbewahrt und können nun auf diese Dateien zurückgreifen – ansonsten könnten Sie jetzt vor einem größeren Problem stehen. Um diese Probleme zu verhindern, gibt es eine weitere Möglichkeit, Informationen für die Wiederherstellung von BitLocker-Installationen aufzubewahren. Alle der bisher erwähnten Methoden eignen sich für Heimanwender oder kleinere Firmen. Für größere Firmen steht daher eine Möglichkeit zur automatischen und zentralen Speicherung dieser Informationen zur Verfügung. Dazu wird der Verzeichnisdienst Active Directory genutzt.

4.3.4

Schlüsselspeicherung im Active Directory

Für größere Organisationen kann es sinnvoll sein, Wiederherstellungsschlüssel (oder auch Schlüsselmaterial) im Active Directory zu speichern. Dadurch verfügen Administratoren über einen zentralen Speicher für alle Wiederherstellungsschlüssel sämtlicher mit BitLocker aktivierter Geräte. Natürlich lässt sich das auch in anderer Form lösen, beispielsweise indem Sie (im einfachsten Fall) in einer Word-Datei eine Liste mit allen 48-stelligen Wiederherstellungsschlüsseln führen. Was ist aber, wenn Sie vergessen, diese Liste nachzuführen? Was, wenn ein Benutzer selber BitLocker aktiviert? Dann fehlen Ihnen diese wichtigen Informationen, um zu einem späteren Zeitpunkt – wenn es notwendig wird – eine Wiederherstellung zu realisieren. Mit dieser Methode ist es möglich, die notwendigen Informationen in einem Child-Objekt des jeweiligen Computerobjekts zu speichern, das für BitLocker aktiviert worden ist. Dieser Prozess erfolgt automatisch, sodass weder Benutzer noch Administratoren daran denken müssen, die Wiederherstellungsschlüssel in irgendeiner Form zu notieren oder zu speichern. Zudem kann mit einer Richtlinie erzwungen werden, dass dieser Prozess obligatorisch ist. Wird diese Richtlinie aktiviert, muss ein Windows Vista-Gerät über eine Verbin-

128

4.3 Partitionsverschlüsselung mit BitLocker dung zur Domäne verfügen, damit BitLocker erfolgreich aktiviert werden kann. Besteht keine Verbindung zur Domäne, können die Schlüssel nicht gespeichert und BitLocker daher nicht aktiviert werden. Obwohl diese Richtlinie Sinn macht, werden Benutzer insofern eingeschränkt, als dass sie BitLocker nicht außerhalb der Firma aktivieren können. Das dürfte aber auch nur selten der Fall sein. Bevor BitLocker-Informationen im Active Directory abgelegt werden können, sind aber einige Voraussetzungen zu erfüllen und verschiedene Vorbereitungsschritte notwendig: Alle Domänencontroller der Domäne müssen mindestens Windows Server 2003 mit Service Pack 1 ausführen (andere Umgebungen werden nicht von Microsoft unterstützt). Mithilfe einer Gruppenrichtlinieneinstellung müssen Computer darüber informiert werden, dass sie BitLocker-Informationen im Active Directory speichern sollen. Informationen über Gruppenrichtlinien zum Thema BitLocker werden später in diesem Kapitel beschrieben. Das Active Directory-Schema muss um verschiedene Objekte erweitert werden, um BitLocker-Informationen zu speichern. Gleichzeitig muss Computern das Recht gegeben werden, ihre BitLocker-Informationen im Active Directory zu speichern. Wenn die notwendigen Voraussetzungen erfüllt sind, kann das Active Directory-Schema mit den neuen Objekten erweitert werden. Dazu muss derjenige Benutzer, der diesen Schritt ausführt, Mitglied der Sicherheitsgruppen „Organisations-Admins“ und „SchemaAdmins“ sein. Dabei handelt es sich um die höchsten Rechte, die in einem Active Directory überhaupt existieren, diese sind aber notwendig, weil eine Schemaaktualisierung jeweils den gesamten Active Directory-Forest betrifft. Die Rechte eines Domänenadministrators reichen demnach nicht aus. Bevor das Schema allerdings aktiviert werden kann, werden einige Dateien benötigt, die bei Microsoft in gepacktem Zustand über folgenden Link zum Download bereitstehen: http://go.microsoft.com/fwlink/?LinkId=78953 Im Download enthalten ist unter anderem die Datei „BitLockerTPMSchemaExtension.ldf“, welche die Schemaerweiterungen beinhaltet. Diese müssen in einem ersten Schritt mit dem Tool „ldifde.exe“ importiert werden. Da die Datei einen Platzhalter für den jeweiligen Domänennamen verwendet, muss bei der Ausführung angegeben werden, mit welchem Wert dieser ersetzt werden soll. Der Befehl für den Import lautet wie folgt: Ldifde.exe –i –v –f „Pfad zur LDF-Datei“ –c „DC=X“ „FQDN der eigenen Domäne“ -k Parameter

Beschreibung

Ldifde.exe

Tool für Import-, Export- und Änderungsprozesse im Active Directory

-i

Legt fest, dass es sich bei der auszuführenden Aktion um einen Importprozess handelt.

-v

Aktiviert den ausführlichen Modus, der während der Befehlsausführung detailliertere Informationen anzeigt.

129

4 Schützen von Daten und Betriebssystemdateien Parameter

Beschreibung

-f „Pfad zur LDF-Datei“

Legt fest, welche Datei die Definitionen für den Import enthält. Hierzu muss der genaue Pfad zur Datei „BitLockerTPMSchemaExtension.ldf“ angegeben werden.

–c „DC=X“ „FQDN der eigenen Domäne“

Mit dieser Option wird der in der Datei verwendete Platzhalter „DC=X“

-k

Legt fest, dass der Importprozess nicht abgebrochen wird, sofern (einige)

durch den voll qualifizierten Domänennamen der eigenen Domäne ersetzt.

zu importierende Objekte bereits bestehen. Die Angaben dieses Parameters werden ignoriert. Anschließend wird der Importvorgang fortgesetzt.

Abbildung 4.57 Erweiterung des Active Directory-Schemas

Nachdem die Erweiterung erfolgreich beendet worden ist, folgt ein zweiter Konfigurationsschritt. Wenn Geräte für BitLocker aktiviert werden und diese ihre Wiederherstellungsinformationen im Active Directory speichern sollen, benötigen sie entsprechende Schreibrechte, über die sie standardmäßig nicht verfügen. Mithilfe des Skripts „AddTPMSelfWriteACE.vbs“, das sich in der bereits heruntergeladenen, selbst-extrahierenden exe-Datei befindet, kann Computern genau dieses Recht erteilt werden. Wo aber werden diese Informationen genau gespeichert? Dafür wird ein neues Child-Objekt unterhalb des Computerkontos eines BitLocker-aktivierten Geräts erstellt. Ein Computer erhält durch die Ausführung des angegebenen Skripts nur genau das Recht, bei seinem eigenen Computerkonto ein neues Child-Objekt zu erstellen und dieses mit Attributswerten aufzufüllen. Dazu wird das Systemkonto „Selbst“ verwendet. Das Skript „Add-TPMSelfWriteACE.vbs“ funktioniert einwandfrei für englische, nicht aber für deutsche Systeme. Leider ist in diesem Script der Name des eingesetzten Systemkontos hartcodiert, das allerdings in der englischen Bezeichnung „Self“. Wenn das Skript

130

4.3 Partitionsverschlüsselung mit BitLocker deshalb auf einem deutschen System gestartet wird, schlägt es fehl, weil das Konto „Self“ nicht gefunden werden kann (auf deutschen Systemen hat es die Bezeichnung „Selbst“). Vor der Ausführung muss daher die Angabe „Self“ durch die korrespondierende SID dieses Systemkontos (S-1-5-10) ersetzt werden.

Abbildung 4.58 Anpassung des hartcodierten Systemkontos „Self“ (vorher: links, nachher: rechts)

Bei deutschen Systemen muss im Skript „Add-TPMSelfWriteACE.vbs“ eine Änderung vorgenommen werden, damit es korrekt ausgeführt werden kann (siehe oben). Es ist durchaus möglich, dass Microsoft das Skript zu einem späteren Zeitpunkt durch eine sprachneutrale Version ersetzt und eine manuelle Anpassung daher nicht mehr notwendig ist.

Zum Abschluss müssen Geräte noch darüber informiert werden, dass Wiederherstellungsinformationen bei einer BitLocker-Aktivierung im Active Directory publiziert werden sollen. Dazu benötigt es zwei Gruppenrichtlinieneinstellungen, die im nächsten Abschnitt detailliert erläutert werden. Die ab diesem Zeitpunkt gespeicherten Informationen können aus dem Active Directory ausgelesen werden. Ein mögliches Tool, das Sie dazu einsetzen können, ist „ADSIedit.msc“. Wenn ein Benutzer sein Wiederherstellungskennwort benötigt brauchen Sie dazu lediglich zwei Informationen: Einerseits den Namen des Computers des Benutzer, der eine Wiederherstellung durchführen muss, andererseits die Kennwort-ID. Bei jeder BitLockerAktivierung werden neue Schlüssel erstellt, und daher kann es natürlich sein, dass für einen Computer mehrere Wiederherstellungskennwörter im Active Directory gespeichert sind. Damit Sie dem Benutzer das aktuelle Kennwort angeben können, benötigen Sie die korrespondierende Kennwort-ID, die dem Benutzer in den BitLocker-Wiederherstellungsoptionen angezeigt wird. Mit „ADSIedit.msc“ können Sie jetzt zum entsprechenden Computerobjekt navigieren und sich dessen Attribute bzw. Attributswerte anzeigen lassen. Das Wiederherstellungskennwort wird im Attribut „msFVE-RecoveryPassword“ gespeichert.

131

4 Schützen von Daten und Betriebssystemdateien

Abbildung 4.59 Wiederherstellungskennwort auslesen

Es gibt natürlich verschiedenste andere Varianten, um an diese Information zu kommen. Beispielsweise könnten Sie das Wiederherstellungskennwort mithilfe eines Skripts – das als Parameter den Computernamen und die Kennwort-ID benötigt – anzeigen lassen.

4.3.5

Gruppenrichtlinien für BitLocker-Konfiguration

Für BitLocker stehen einige (je nach Situation sehr wichtige) Gruppenrichtlinieneinstellungen zur Verfügung. Navigieren Sie dazu zum Bereich Computereinstellungen\Administrative Vorlagen\Windows-Komponenten\BitLockerLaufwerkverschlüsselung.

132

4.3 Partitionsverschlüsselung mit BitLocker

Abbildung 4.60 Gruppenrichtlinien für BitLocker, Teil 1

Richtlinie

Beschreibung

BitLocker-Sicherung in Active DirectoryDomänendiensten aktivieren

Mithilfe dieser Richtlinie kann angegeben werden, ob die Wiederherstellungsinformationen im Active Directory abgelegt werden müssen. Option 1: BitLocker-Sicherung im AD DS erforderlich Legt fest, dass BitLocker die Wiederherstellungsinformationen zwingend im Active Directory ablegen muss. Option 2: Wiederherstellungskennwort und/oder Schlüsselmaterial Legt fest, ob im AD ausschließlich Wiederherstellungskennwörter oder auch Schlüsselinformationen gespeichert werden. Standardeinstellung: Die Speicherung von Wiederherstellungsinformationen im Active Directory ist nicht zwingend. Empfohlene Einstellung: Um sicherzustellen, dass bei einem Integritätsproblem oder Schlüsselverlust nach wie vor auf die Installation zugegriffen werden kann, sollten Wiederherstellungsinformationen im Firmenumfeld zwingend im zentralen AD abgelegt werden. Dadurch sind Sie auch vor Verlust von USB-Laufwerken, welche die Wiederherstellungsinformationen enthalten, geschützt. Sicherheitshalber sollten nebst den Wiederherstellungskennwörtern auch die Schlüsselinformationen im AD gespeichert werden.

133

4 Schützen von Daten und Betriebssystemdateien Richtlinie

Beschreibung

Systemsteuerungssetup: Wiederherstellungsordner konfigurieren

Das Wiederherstellungskennwort kann optional in eine Datei gespeichert werden. Benutzer müssen angeben, wo diese Datei angelegt werden soll. Der mit dieser Richtlinie angegebene Pfad wird Benutzern vom Assistenten vorgeschlagen, aber er kann vom Benutzer beliebig geändert werden. Standardeinstellung: Der Assistent zeigt die oberste Ordnerebene des jeweiligen Computers an. Empfohlene Einstellung: Diese Einstellung ist sehr situationsabhängig. In einigen Situationen kann es durchaus Sinn machen, den Schlüssel im persönlichen Ordner des Benutzers auf einem Server abzulegen. In diesem Szenario könnte der entsprechende Pfad (mithilfe einer Variablen) angegeben werden.

Systemsteuerungssetup: Wiederherstellungsoptionen konfigurieren

Mit dieser Richtlinie kann angegeben werden, welche Wiederherstellungsmechanismen für BitLocker eingesetzt werden. BitLocker stellt dazu die Möglichkeit zur Verfügung, ein Wiederherstellungskennwort manuell einzugeben (48 Stellen) oder dieses auf ein USB-Laufwerk zu speichern (256 Bit Schlüssellänge). Standardeinstellung: Benutzer haben die Auswahl aller verfügbaren Optionen. Empfohlene Einstellung: Im Firmenumfeld sollten Wiederherstellungskennwörter sicherheitshalber zwingend im Active Directory abgelegt werden, damit diese Informationen zentral zur Verfügung stehen (siehe Richtlinie „BitLockerSicherung in Active Directory-Domänendiensten aktivieren“.

Systemsteuerungssetup: Erweiterte Startoptionen aktivieren

Diese sehr wichtige Richtlinie wird verwendet, um die Key Protectors für den VMK zu konfigurieren. Option 1: BitLocker auch ohne TPM zulassen Legt fest, ob auch Systeme ohne TPM BitLocker nutzen dürfen. Option 2: TPM-Startschlüssel-Option Legt fest, ob ein zusätzlicher Schutz mit einem Startschlüssel, der auf einem USB-Laufwerk gespeichert wird, zwingend, nicht möglich oder optional ist.

134

4.3 Partitionsverschlüsselung mit BitLocker Option 3: TPM-PIN-Option Legt fest, ob ein zusätzlicher Schutz mit einem PINCode zwingend, nicht möglich oder optional ist. Standardeinstellung: BitLocker kann nur mit TPM genutzt werden. Startschlüssel- und PIN-Sicherheit können optional verwendet werden. Empfohlene Einstellung: Um die Sicherheit zu erhöhen, sollte neben TPM eine weitere Sicherheitsstufe hinzugefügt werden, entweder die Variante mit einem USBStartschlüssel oder die PIN-Option. Für Geräte ohne TPM muss angegeben werden, dass BitLocker ohne TPM genutzt werden darf, und die USB-Startschlüsseloption muss zwingend aktiviert sein. Zur Information: USB-Startschlüssel und PIN-Optionen dürfen nicht gleichzeitig aktiviert werden (erst ab Windows Vista Service Pack 1 möglich). Verschlüsselungsmethode konfigurieren

Mit dieser Richtlinie kann genau konfiguriert werden, welche Verschlüsselungsmethode für BitLocker verwendet werden soll. Folgende Methoden stehen zur Auswahl: AES 128 Bit mit DiffUser AES 256 Bit mit DiffUser AES 128 Bit AES 256 Bit Standardeinstellung: AES 128 Bit mit DiffUser Empfohlene Einstellung: Normalerweise dürfte die Standardeinstellung ausreichen. Für Geräte mit sehr sensitiven Daten kann die Einstellung „AES 256 Bit mit DiffUser“ eingesetzt werden.

Überschreiben des Arbeitsspeichers bei Neustart verhindern

Standardmäßig wird der Arbeitsspeicher bei jedem Neustart des Rechners überschrieben. Diese Richtlinie steuert dieses Verhalten. Aus Leistungsgründen kann es bei Bedarf angepasst werden. Standardeinstellung: Der Arbeitsspeicher wird bei jedem Neustart überschrieben. Empfohlene Einstellung: Aus Sicherheitsgründen sollten Sie diese Richtlinie deaktivieren, sodass ein Überschreiben des Arbeitsspeichers bei jedem Neustart stattfindet.

135

4 Schützen von Daten und Betriebssystemdateien Richtlinie

Beschreibung

TPM-Plattformvalidierungsprofil konfigurieren

Diese Richtlinie kann eingesetzt werden, um die TPMIntegritätsprüfung detailliert zu konfigurieren. Es lässt sich festlegen, welche Bereiche bei der Integritätsprüfung überprüft werden sollen. Standardeinstellung: Standardmäßig werden die Komponenten PCR0, PCR2, PCR4, PCR8, PCR9, PCR10 und PCR11 verwendet. Empfohlene Einstellung: Um einen optimalen Mix aus Integritätssicherheit und Verwaltbarkeit zu haben, wird empfohlen, die Standardeinstellungen beizubehalten.

4.4

Rückblick Windows Vista bietet mit den beiden Funktionen EFS und BitLocker zwei Möglichkeiten, um Daten und Systemdateien optimal zu schützen. Die beiden Technologien lassen sich problemlos kombinieren, um einen höchstmöglichen Schutz gegen Online- und OfflineAngriffe realisieren zu können. Um sensitive Daten zu schützen, besonders bei mobilen Geräten, würde ich den Einsatz dieser Technologien unbedingt empfehlen, weil sie transparent, sehr benutzerfreundlich und vor allem sicher sind. Natürlich stellt sich auch die Frage der Leistungsabnahme, besonders beim Einsatz der BitLocker-Technologie. Microsoft gibt die Abnahme der Leistung bei rund 5% an, was im tolerierbaren Bereich liegt und von Benutzern in vielen Fällen nicht bemerkt wird. Eine weitere Sicherheitsstufe bringen NTFS-Rechte, die bei lokalen wie auch bei Netzwerkzugriffen Gültigkeit haben. Administratoren haben so eine sehr enge Kontrolle darüber, wer auf welche Ressourcen zugreifen darf. In Kombination mit EFS – das dem Benutzer zusätzlich zu NTFS-Rechten eine Verschlüsselung von Daten erlaubt – und anderen bereits gezeigten Technologien wie beispielsweise UAC und WIC ergibt sich daraus ein abgerundetes Gesamtpaket, um Daten vor Angriffen zu schützen. Am besten prüfen Sie noch heute, welche Ihrer Arbeitsstationen ganz besonderen Schutz benötigen, und evaluieren die passenden Sicherheitsfunktionen, um Ihre Bedürfnisse abzudecken.

136

5 Update-Management So, bei diesem Kapitel haben wir vermutlich den Klassiker erreicht, und um es gleich vorwegzunehmen: Nein, Windows ist nicht das einzige Betriebssystem, das regelmäßig aktualisiert werden muss. Und ja, auch Windows Vista muss immer noch regelmäßig aktualisiert werden. Bevor Vorurteile gefällt werden, sollte man sich allerdings anschauen, was mit Updates genau aktualisiert wird. Oft höre ich die Aussage: „Was, schon wieder zehn neue Updates?“, ohne dass überhaupt geprüft wurde, um welche Updates es sich handelt und was diese genau bezwecken. Nicht alle Updates beziehen sich auf die Sicherheit des Betriebssystems, es gibt auch Updates, die Treiber und sonstige Funktionen erweitern, oder Updates, die bestimmte Bereiche leistungsseitig verbessern. Bevor Urteile gefällt werden, sollte daher zuerst auf die Qualität und Zielbereiche von Updates geachtet werden und nicht nur auf die Quantität. Trotzdem muss die Sicherheit im Auge behalten werden, und wenn man sich die Landschaft ein bisschen genauer ansieht, wird man schnell bemerken, dass bekannte Sicherheitslecks ausgenützt werden, um Systeme anzugreifen. Sobald diese publik werden, ist es eine Frage der Zeit, bis die ersten Angriffe auftauchen. Angreifer nutzen einerseits direkt Informationen über solche Sicherheitslücken, aber auch die Sicherheitsupdates von Microsoft, um zu prüfen, welche Lecks damit gestopft werden. Fakt ist, dass in der Vergangenheit die Zeitspanne zwischen Bekanntwerden eines Sicherheitslecks und dem Auftauchen der ersten Angriffe darauf immer kürzer geworden sind. Deshalb sollte SicherheitsUpdates verhältnismäßig schnell auf Clients und Server verteilt werden, am besten innerhalb ein bis zwei Tage. Das ist eine Herausforderung, ich weiß, aber unumgänglich, wenn Sie Ihr Netzwerk optimal schützen wollen. Das Update-Management von Betriebssystemen kann in einer Firmenumgebung schon zur echten Herausforderung werden. Dazu kommt allerdings, dass auch Anwendungen regelmäßig aktualisiert werden müssen. Wie kann ein Administrator sicherstellen, dass seine Systeme regelmäßig mit den aktuellsten Updates ausgerüstet werden, und wie kann er prüfen, ob tatsächlich alle Geräte den gewünschten Stand aufweisen? Diese Fragen werden Ihnen beim Durchlesen dieses Kapitels beantwortet.

137

5 Update-Management Verschiedene Methoden Es gibt eine Reihe an Möglichkeiten, Systeme regelmäßig zu aktualisieren. Microsoft selber hat dazu einige Produkte auf dem Markt, aber auch viele Dritthersteller bieten Lösungen für das Update-Management an. Seitens Microsoft gibt es folgende populäre Produkte, die das automatische Installieren und Verwalten von Updates unterstützen: Automatische Updates über Microsoft Update Windows Server Update Services (WSUS) 3.0 System Center Essentials (SCE) 2007 System Center Configuration Manager (SCCM) 2007 In diesem Kapitel gehe ich auf die ersten beiden Methoden ein. SCE und SCCM (ehemals SMS) beinhalten auch eine Update-Management-Komponente, allerdings handelt es sich dabei nur um eine Komponente. Diese Produkte beinhalten noch weitere Komponenten für die Verwaltung von Client-/Server-Infrastrukturen und Netzwerken.

5.1

Automatische Updates über Microsoft Update Die einfachste Möglichkeit, einen Windows Vista-Client permanent auf einem aktuellen Stand zu halten, ist die, das Gerät regelmäßig mit Microsoft Update zu verbinden. Nach einer entsprechenden Prüfung der bereits installierten Updates werden dem Benutzer alle Updates angezeigt, die für sein Gerät relevant, aber noch nicht installiert sind. Die gewünschten Updates können markiert und installiert werden. Nach erfolgtem Download werden die Updates automatisch installiert und der Benutzer anschließend informiert. Die Verbindung zu Microsoft Update erfolgt am einfachsten direkt über das Startmenü. Wählen Sie dort im Ordner „Alle Programme“ den Menüpunkt „Windows Update“.

Abbildung 5.1 Die Windows Update-Verwaltung

138

5.1 Automatische Updates über Microsoft Update Falls Sie Windows Vista Ultimate Edition einsetzen, wird noch ein zweiter Bereich angezeigt, über den Sie exklusive Ultimate Updates herunterladen und installieren können.

Beachten Sie besonders den Bereich ganz unten. Dort ist ersichtlich, ob derzeit lediglich Updates für das Betriebssystem oder auch für andere Produkte geprüft werden. Sinnvollerweise aktivieren Sie die Update-Funktion auch für alle restlichen Komponenten, indem Sie auf die Verknüpfung „Updates für erweiterte Produkte“ klicken. Falls Sie die Ultimate Edition von Windows Vista einsetzen, wird ab diesem Zeitpunkt unterhalb der Windows Updates noch ein weiterer Bereich für Ultimate Updates eingeblendet. Durch Klicken auf die Schaltfläche „Nach Updates suchen“ wird eine Verbindung mit Microsoft Update hergestellt und eine Liste mit verfügbaren Updates präsentiert.

Abbildung 5.2 Verfügbare Updates für die Installation markieren

Den Fortschritt des Downloads und der Installation können Sie direkt im Windows Update-Bereich mitverfolgen. Nach erfolgter Installation wird eine Benachrichtigung angezeigt, dass neue Updates erfolgreiche installiert worden sind. Ist bei der Installation ein Fehler aufgetreten, wird dies ebenfalls angezeigt. Um bereits installierte Updates anzuzeigen, wählen Sie im Aufgabenfenster den Menüpunkt „Updateverlauf anzeigen“.

139

5 Update-Management

Abbildung 5.3 Updateverlauf anzeigen

Durch Klicken auf die Verknüpfung „Installierte Updates“ gelangen Sie direkt zum Bereich, über den sich Updates deinstallieren lassen.

Abbildung 5.4 Updates deinstallieren

140

5.1 Automatische Updates über Microsoft Update Obwohl der Prozess der Update-Erkennung und -Installation manuell möglich ist, ist dieses Vorgehen nicht sehr sinnvoll. Was, wenn kritische Updates veröffentlicht werden und Sie nicht daran denken, eine Aktualisierung Ihres Systems durchzuführen? Und wie merken Sie überhaupt, dass neue kritische Updates verfügbar sind? Ach so, klar, Sie haben natürlich die entsprechenden Newsletter von Microsoft abonniert, die Sie regelmäßig über solche Situationen informieren. Trotzdem dürfte es in vielen Situationen Sinn machen, den Update-Prozess zu automatisieren. Ihr System soll dabei selbstständig prüfen, ob neue Updates verfügbar sind, diese herunterladen und installieren. Und somit haben Sie bereits einen Task weniger, mit dem Sie sich beschäftigen müssen. Wenn Sie zum Windows-Update-Fenster zurückkehren, werden Sie in der Aufgabenleiste den Menüpunkt „Einstellungen ändern“ vorfinden, über den sich der Update-Prozess automatisieren lässt. Hier lässt sich festlegen, ob eine regelmäßige Prüfung auf Updates automatisch erfolgen soll oder nicht. Zudem kann angegeben werden, wie ein Benutzer in den Prozess eingreifen darf, d.h., ob der Download und die Installation vollautomatisch erfolgen oder ob der Benutzer die Updates zur Auswahl angezeigt bekommt und den Installationszeitpunkt frei wählen kann. Natürlich lassen sich diese Einstellungen auch über Gruppenrichtlinien vornehmen, doch dazu später.

Abbildung 5.5 Einstellungen für automatische Updates

141

5 Update-Management

5.2

Windows Server Update Services (WSUS) Die automatische Beschaffung von Updates kann auch im Firmenumfeld eingesetzt werden. Damit sind aber einige Probleme verbunden. Wenn jede Arbeitsstation eines Unternehmens Updates bei Microsoft Update bezieht, kann das unter Umständen enorme Datenmengen erzeugen, die heruntergeladen werden müssen und dadurch wertvolle Bandbreite blockieren. Zudem wird der Update-Prozess blind betrieben, d.h., der Administrator hat keine Kontrolle darüber, welche Updates installiert werden sollen, noch eine Übersicht, welche Updates tatsächlich schon installiert sind bzw. noch fehlen. Eine Art Reporting existiert nicht und muss mit anderen Methoden realisiert werden. Viele Administratoren bevorzugen deshalb eine verwaltbare Update-Infrastruktur. Ein Werkzeug, das Microsoft für diesen Bereich kostenlos zur Verfügung stellt, ist WSUS, derzeit aktuell in der Version 3.0. Mithilfe dieses Tools lässt sich die Update-Verwaltung zentralisieren und eng kontrollieren. Administratoren können die gewünschten Updates auf einen WSUS-Server herunterladen, von dem aus sie dann an Clients (und bei Bedarf auch an Server) verteilt werden. Bevor eine Verteilung stattfindet, kann festgelegt werden, welche Updates für welche Geräte freigegeben werden. So können neue Updates in einem ersten Schritt lediglich an eine Handvoll Testgeräte verteilt werden, um zu prüfen, ob keine Kompatibilitätsprobleme (z.B. mit Anwendungen) auftreten. Wenn keine ungewünschten Effekte auftauchen, können die Updates in einem zweiten Schritt an die restlichen Geräte verteilt werden. Eine weitere interessante Funktion von WSUS ist die Reporting-Komponente, mit deren Hilfe Reports über Computer oder Updates erstellt werden können. Dadurch ist sofort ersichtlich, welche Computer noch nicht auf dem gewünschten Stand sind. In einem solchen Fall kann die Installation eines wichtigen Updates sofort ausgelöst werden. Auf den folgenden Seiten möchte ich Ihnen zeigen, wie Sie WSUS für ein effizientes Update-Management einsetzen können. Das gilt natürlich nicht ausschließlich für Windows Vista-Clients, sondern auch für ältere Client-Betriebssysteme, für Server-Betriebssysteme und für andere Anwendungen. Für detaillierte Informationen zum Thema stehen auf der Microsoft-Webseite über die URL http://technet.microsoft.com/en-us/wsus/default.aspx viele Artikel zu den Bereichen Planung und Betrieb zur Verfügung.

5.2.1

Installation von WSUS

Wenn Sie WSUS einsetzen möchten, benötigen Sie zuerst einen Server, auf dem die WSUS-Komponenten installiert werden können. Für größere Umgebungen benötigen Sie möglicherweise mehrere Server, besonders dann, wenn WSUS in verteilten Umgebungen eingesetzt werden soll. Das Produkt kann auf der Microsoft-Webseite über die URL

142

5.2 Windows Server Update Services (WSUS) http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=e4a868d7a820-46a0-b4db-ed6aa4a336d9 kostenfrei heruntergeladen werden. Unabhängig davon muss ein Server, der WSUS ausführen soll, folgende Voraussetzungen erfüllen: Windows Server 2003 inkl. SP1 oder Windows Server 2003 R2 IIS6.0 (www-Komponente) .NET Framework 2.0 Microsoft Report Viewer 2005 Microsoft Management Console 3.0 Genügend Harddiskkapazität für das Speichern von Updates WSUS wird bei der Installation automatisch eine „Windows Internal Database“ installieren, um Informationen abzuspeichern. Alternativ kann auch eine SQL-Datenbank genutzt werden, dann wird allerdings mindestens SQL Server 2005 mit installiertem Service Pack 1 vorausgesetzt. Die Installation gestaltet sich recht einfach. Zuerst muss festgelegt werden, in welchem Ordner WSUS Updates speichern soll. Dieser Ordner sollte sich auf einer Partition mit genügend Speicherkapazität befinden, weil das Volumen je nach Umgebung sehr groß werden kann. Ich empfehle für die Speicherung von Updates mindestens 20 GB zu berechnen, damit es zu keinen Engpässen kommt. Anschließend muss angegeben werden, wo die Datenbank installiert werden soll, in der WSUS-Informationen wie Computer, Update-Stände oder Statistiken aufbewahrt werden.

Abbildung 5.6 WSUS-Installation, Teil 1

143

5 Update-Management Die Installation wird abgeschlossen, indem eine Webseite angegeben werden muss, auf die WSUS-Clients zugreifen können. Die Client-zu-WSUS-Server-Kommunikation basiert webbasiert, weshalb zwingend eine Webseite notwendig ist, um Verbindungen annehmen zu können. Legen Sie fest, ob dazu eine bestehende Webseite verwendet oder explizit eine Webseite für den WSUS-Betrieb angelegt werden soll (anderer Port).

Abbildung 5.7 WSUS-Installation, Teil 2

Danach wird die WSUS-Installation gestartet. Nach wenigen Minuten ist die Installation abgeschlossen, und die notwendigen Komponenten sind installiert und konfiguriert. Beim ersten Start der WSUS-Konsole (über die Administrationswerkzeuge) wird ein Assistent gestartet, der Sie durch die nächsten Konfigurationsschritte führt. Diese Schritte sollten Sie detailliert durchgehen, um sicherzustellen, dass keine wichtigen Konfigurationsschritte ausgelassen werden. Nach der Frage, ob Sie am Verbesserungsprogramm teilnehmen möchten, können Sie festlegen, welche Quelle Ihr neuer WSUS-Server für die Synchronisierung verwenden soll. Dabei kann es sich um Microsoft Updates oder um einen anderen WSUS-Server, der bereits in Ihrer Firma installiert ist, handeln. Legen Sie zudem fest, ob eine Verbindung zum angegebenen Server direkt oder über einen Proxyserver erfolgt.

144

5.2 Windows Server Update Services (WSUS)

Abbildung 5.8 WSUS-Konfigurationsassistent, Teil 1

Nachdem diese Information eingegeben worden ist, wird zum ersten Mal gegen die entsprechende Quelle synchronisiert, um zu prüfen, welche Produkte und Klassifizierungen zur Verfügung stehen (Updates werden keine heruntergeladen). Wählen Sie anschließend die gewünschten Sprachen, die eingesetzten Produkte und die Update-Klassifizierungen aus, die Sie benötigen, um Ihre Clients und Server zu aktualisieren. Diese Auswahl kann zu einem späteren Zeitpunkt jederzeit angepasst werden.

145

5 Update-Management

Abbildung 5.9 WSUS-Konfigurationsassistent, Teil 2

Abbildung 5.10 WSUS-Konfigurationsassistent, Teil 3

Abschließend muss angegeben werden, wie oft der WSUS-Server gegen die angegebene Quelle synchronisiert werden soll, d.h., wie oft er prüfen soll, ob sie über neue Updates verfügt, die den angegebenen Kriterien entsprechen. Die Synchronisierung kann jeweils manuell oder automatisch erfolgen. Eine regelmäßige automatische Synchronisation macht vermutlich in den meisten Fällen Sinn.

146

5.2 Windows Server Update Services (WSUS)

Abbildung 5.11 WSUS-Konfigurationsassistent, Teil 4

Zum Abschluss des Assistenten werden noch einige Aufgaben angezeigt, die erledigt werden müssen. Diesen werden wir uns im nächsten Abschnitt widmen. Wenn Sie die Markierungen bei den angezeigten Optionen nicht explizit gelöscht haben, wird beim Schließen des Assistenten eine erste Synchronisierung des WSUS-Servers durchgeführt und die WSUS-Konsole gestartet. Synchronisierung bedeutet, dass aufgrund der angegebenen Informationen nach Updates gesucht wird. Die Updates selber werden allerdings noch nicht heruntergeladen, sondern lediglich eine Update-Liste. Erst wenn Updates freigegeben werden, die auch tatsächlich von Geräten benötigt werden, erfolgt ein Update-Download.

5.2.2

WSUS-Basiskonfiguration

Die WSUS-Konsole wird verwendet, um fast alle Konfigurationen vorzunehmen. Für die vollständige Verwaltung werden allerdings auch Gruppenrichtlinien benötigt. Doch dazu später. Erst einmal möchten wir die Konsole erkunden und prüfen, welche Konfigurationsmöglichkeiten sie bietet.

147

5 Update-Management

Abbildung 5.12 Die WSUS-Konsole

Bereich

Beschreibung

Updates

In diesem Bereich werden die zu verteilenden Updates verwaltet. Updates können für bestimmte Geräte freigegeben oder blockiert werden.

Computer

Computer, die Updates vom WSUS-Server herunterladen und installieren sollen, müssen sich zuerst beim WSUS-Server registrieren. Computer können dann in Gruppen organisiert werden, um Updates an Computergruppen freigeben zu können. Diese Einstellungen werden in diesem Bereich vorgenommen.

Downstream-Server

Dieser Bereich zeigt sog. Downstream-Server, also andere WSUS-Server, die beim lokalen WSUS-Server Informationen synchronisieren (anstatt dies direkt bei Microsoft Update zu tun).

Synchronisierungen

Über diesen Bereich erhält ein Administrator eine Übersicht vergangener Synchronisationen und hat die Möglichkeit, manuell eine Synchronisation zu starten oder die Einstellungen für die automatische Synchronisation zu ändern.

Berichte

In diesem Abschnitt können Berichte (Reports) erstellt werden. Es stehen standardmäßig Berichte für Updates, Computer und Synchronisierungsinformationen zur Verfügung.

Optionen

Die im WSUS-Konfigurationsassistenten angegebenen Informationen können über diesen Bereich jederzeit wieder geändert werden. Zudem stehen noch zusätzliche Optionen für die WSUS-Serverkonfiguration zur Verfügung.

148

5.2 Windows Server Update Services (WSUS) Bevor wir uns mit der Konfiguration befassen, möchten wir noch eine weitere Sicherheitsschicht integrieren. WSUS-Clients verwenden HTTP, um mit dem WSUS-Server zu kommunizieren. Diese Kommunikation sollte mit SSL geschützt werden, sodass sie vollständig verschlüsselt stattfindet. Dazu muss die Webseite, die für WSUS genutzt wird, mit einem digitalen Zertifikat ausgerüstet und für die SSL-Nutzung freigegeben werden. Ein digitales Zertifikat kann entweder von einer Zertifizierungsstelle bezogen oder selbst ausgestellt werden. Das Szenario mit einer Zertifizierungsstelle haben wir bereits in einem früheren Kapitel behandelt, deshalb möchte ich Ihnen zeigen, wie Sie für eine Webseite ein selbst signiertes Zertifikat ausstellen können. Dazu benötigen Sie lediglich ein Tool aus dem IIS 6 Resource Kit. Installieren Sie das Resource Kit direkt auf dem WSUS-Server, und nutzen Sie das Tool „selfssl.exe“, um der Webseite ein Zertifikat zuzuweisen:

Abbildung 5.13 SSL-Konfiguration für die WSUS-Webseite

Parameter

Beschreibung

Selfssl.exe

Tool zur Ausstellung von selbst signierten Zertifikaten.

/T

Legt fest, dass dem auszustellenden Zertifikat vertraut wird. Dadurch wird das Zertifikat der Liste vertrauenswürdiger Aussteller hinzugefügt.

/N:cn=FQDN

Legt den FQDN im Zertifikat fest. Dieser sollte mit dem FQDN übereinstimmen, den WSUS-Clients nutzen, um sich mit dem WSUS-Server zu verbinden (z.B.: wsus.smartdynamic.ch). Hierzu muss u.U. ein entsprechender Eintrag in der DNS-Zone vorgenommen werden, damit der Name in die korrekte IP-Adresse aufgelöst wird.

149

5 Update-Management Parameter

Beschreibung

/K:Schlüssellänge

Legt fest, welche Schlüssellänge verwendet werden soll. Empfehlung: 2048 Bit.

/V:Lebensdauer

Legt fest, wie lange das ausgestellte Zertifikat gültig ist. Empfehlung: ein bis zwei Jahre (muss danach erneuert werden).

/S:Webseiten-ID

Legt fest, welcher Webseite das neue Zertifikat zugewiesen werden soll. Die ID ist über den IIS-Manager ersichtlich.

/P:Portnummer

Legt fest, welche Portnummer für SSL-Verbindungen genutzt wird. Empfehlung: Standardport 443 nutzen.

/Q

Legt lediglich fest, dass beim Ausführen des Befehls nicht nachgefragt wird, ob allenfalls bestehende Zertifikate überschrieben werden sollen.

Nach erfolgreicher Ausführung kann das Zertifikat über den IIS-Manager angezeigt werden. Zeigen Sie dazu die Eigenschaften der Webseite an, und wechseln Sie zum Reiter „Verzeichnissicherheit“. Im Abschnitt „Sichere Kommunikation“ kann das Zertifikat angezeigt werden.

Abbildung 5.14 SSL-Konfiguration anzeigen

Der WSUS-Server selber vertraut dem neuen Zertifikat bereits (durch die Angabe des Parameters /T). Andere Geräte Ihrer Umgebung hingegen kennen den Aussteller dieses Zertifikats nicht und vertrauen ihm nicht. Deshalb sollte das Zertifikat allen Geräten als vertrauenswürdig eingestuft werden. Dies kann über eine Gruppenrichtlinieneinstellung erreicht werden. Das Zertifikat (ohne privaten Schlüssel) muss dazu über den IIS-Manager exportiert und in einer Gruppenrichtlinie als vertrauenswürdig eingestuft werden.

150

5.2 Windows Server Update Services (WSUS) Den Export können Sie direkt im IIS-Manager starten, indem Sie das Zertifikat anzeigen und über den Reiter „Details“ die Schaltfläche „In Datei kopieren“ anklicken. Der Exportassistent wird gestartet. Wichtig hierbei ist, dass lediglich das Zertifikat, nicht aber der private Schlüssel exportiert wird.

Abbildung 5.15 Exportieren des Zertifikats

Legen Sie zum Abschluss den Speicherpfad fest. Starten Sie die GruppenrichtlinienVerwaltungskonsole, und editieren Sie die „Default Domain Policy“. Navigieren Sie zum Bereich Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\ Richtlinien für öffentliche Schlüssel\Vertrauenswürdige Stammzertifizierungsstellen. Importieren Sie dort das Zertifikat, sodass bei der nächsten Zuweisung der Richtlinie alle Geräte der Domäne diesem Zertifikat vertrauen. So, nachdem auch das erledigt ist, wird es Zeit, weitere Einstellungen in der WSUSKonsole vorzunehmen. Wechseln Sie in der Konsole zum Bereich „Optionen“. Hier sollten vor der produktiven Inbetriebnahme unbedingt noch ein paar Einstellungen vorgenommen werden. Wie bereits erwähnt, wurden die meisten Bereiche schon mit dem WSUSKonfigurationsassistenten konfiguriert, aber es existieren noch weitere, die konfiguriert werden sollten.

151

5 Update-Management

Abbildung 5.16 Zertifikat in Gruppenrichtlinie importieren

Updates müssen grundsätzlich von einem Administrator genehmigt werden, bevor diese am Computer verteilt werden können. Mithilfe der Funktion „Automatische Genehmigungen“ können bestimmte Updates für bestimmte Computer automatisch freigegeben werden, ohne dass der Administrator eingreifen muss. Die automatische Freigabe kann natürlich auch für alle Updates und alle Computer eingesetzt werden, allerdings macht es immer Sinn, Updates zuerst auf ein paar wenigen Geräten zu installieren und zu testen. Zudem kann angegeben werden, ob WSUS-Updates oder von Microsoft aktualisierte Updates automatisch freigegeben werden sollen.

152

5.2 Windows Server Update Services (WSUS)

Abbildung 5.17 Regeln für automatische Genehmigungen

Damit Administratoren nicht immer die WSUS-Konsole starten müssen, um sich ein Bild über die Update-Situation zu machen, können automatische Mail-Benachrichtigungen konfiguriert werden. Der Administrator wird regelmäßig bzw. bei bestimmten Ereignissen per Mail über Neuigkeiten informiert. Legen Sie dazu im Bereich „E-MailBenachrichtigungen“ fest, über welchen Mailserver Mails versendet werden sollen (Relaying bzw. Authentifizierung beachten) und wann dies genau erfolgen soll.

Abbildung 5.18 Benachrichtigungen konfigurieren

153

5 Update-Management Die letzte Option, die konfiguriert werden sollte, ist die Option „Computer“. Hier lässt sich steuern, wie neue WSUS-Clients zu Computergruppen hinzugefügt werden sollen. Was Computergruppen genau sind, erfahren Sie gleich im nächsten Abschnitt. In den meisten Fällen aber sollte die Gruppenzugehörigkeit über Gruppenrichtlinien gesteuert werden.

Abbildung 5.19 Computergruppen-Zugehörigkeit steuern

5.2.3

Computergruppen

Ein wichtiges Element bei WSUS sind Computergruppen. Wie der Name schon vermuten lässt, werden hierbei Gruppen gebildet, und jeder WSUS-Client, der sich beim WSUSServer registriert, kann einer Computergruppe zugeordnet werden. Wenn neue Updates freigegeben werden sollen, kann dies immer für alle Geräte oder für eine oder mehrere Gruppen erfolgen. Als Beispiel könnten die Clients einer Firma in zwei Gruppen unterteilt werden: „Clients“ und „Testclients“. Wenn neue Updates verfügbar sind, können diese in einem ersten Schritt für die Gruppe „Testclients“ freigegeben werden. Nachdem die Updates installiert sind, kann geprüft werden, wie sich die Geräte verhalten. Wenn keine Probleme auftauchen, können die neuen Updates in einem zweiten Schritt der Gruppe „Clients“ freigegeben werden. Die Frage stellt sich nun, wie WSUS-Clients gruppiert werden. Dazu gibt es zwei Möglichkeiten: Die Gruppierung kann manuell erfolgen, indem ein Administrator in der WSUS-Konsole jeden neuen WSUS-Client einer Gruppe zuordnet. Das ist allerdings recht

154

5.2 Windows Server Update Services (WSUS) mühsam und aufwendig und nur bei einer kleinen Anzahl WSUS-Clients zu empfehlen. Besser ist die Option der automatischen Zuweisung. Hierzu werden Gruppenrichtlinien verwendet, um WSUS-Clients automatisch der korrekten Gruppe zuzuordnen. Unabhängig davon, für welche Methode Sie sich entscheiden, der WSUS-Server muss wissen, welche Methode Sie verwenden. Und dazu stehen in den WSUS-Optionen im Bereich „Computer“ die beiden Methoden zur Auswahl. Geben Sie an, welche Methode Sie wünschen. Jetzt geht’s an das Erstellen der Computergruppen. Wechseln Sie in der WSUS-Konsole zum Abschnitt Computer\Alle Computer, und erstellen Sie über die Aufgabe „Computergruppe hinzufügen“ die gewünschten Computergruppen. Dieser Konfigurationsschritt ist notwendig, unabhängig davon, wie die Sie die Zuordnung zu Gruppen konfiguriert haben. Die Gruppen müssen manuell erfasst werden.

5.2.4

WSUS-Clients konfigurieren

Jetzt ist es an der Zeit, Geräte über die Präsenz eines WSUS-Servers zu informieren. Die Konfiguration von WSUS-Clients erfolgt vollständig über Gruppenrichtlinien. Erstellen Sie eine neue Gruppenrichtlinie, und navigieren Sie zum Bereich Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Windows-Update. Diese Einstellungen werden auch verwendet, wenn Sie automatische Updates ohne WSUS konfigurieren möchten.

Abbildung 5.20 WSUS-Gruppenrichtlinieneinstellungen

155

5 Update-Management Richtlinie

Beschreibung

Option „Updates installieren und herunterfahren“ im Dialogfeld „Windows herunterfahren“ nicht anzeigen

Wenn Updates noch nicht installiert sind, wird beim Herunterfahren eines Geräts zusätzlich die Option „Updates installieren und herunterfahren“ angezeigt. Dabei werden zuerst alle Updates installiert und das Gerät anschließend automatisch heruntergefahren. Soll diese Option nicht angezeigt werden, kann diese Richtlinie aktiviert werden. Empfohlene Einstellung: Diese Einstellung sollte deaktiviert werden, damit diese Option beim Herunterfahren angezeigt wird (z.B. für Administratoren).

Die Standardoption „Updates installieren und herunterfahren“ im Dialogfeld „Windows herunterfahren“ nicht anpassen

Beim Herunterfahren eines Geräts wird immer automatisch die Option „Updates installieren und herunterfahren“ ausgewählt. Soll dies nicht der Fall sein, kann diese Richtlinie deaktiviert werden. Empfohlene Einstellung: Diese Richtlinie sollte deaktiviert werden, damit sie beim Herunterfahren immer standardmäßig ausgewählt ist.

Windows UpdateEnergieverwaltung aktivieren, um das System zur Installation von geplanten Updates automatisch zu reaktivieren

Legt fest, dass ein System aus dem Ruhezustand aufgeweckt wird,

Automatische Updates konfigurieren

Aktiviert für Geräte automatische Updates und legt fest, wie Down-

wenn Updates installiert werden sollen (zum angegebenen Zeitpunkt). Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden.

load und Installation genau erfolgen sollen. Wie erfolgen Download und Installation? Option 2: Vor Herunterladen und Installieren benachrichtigen Option 3: Automatisch herunterladen, vor Installation benachrichtigen Option 4: Automatisch herunterladen und laut Zeitplan installieren Option 5: Lokalen Administratoren ermöglichen, Einstellungen zu wählen Geplanter Installationstag Geplante Installationszeit Empfohlene Einstellung: In den meisten Fällen macht Option 4 Sinn. Standardbenutzer werden dabei weder beim Download noch bei Installieren informiert, wodurch die Prozesse auch nicht abbrechen können. Die Installation erfolgt an einem bestimmten Zeitpunkt, am besten täglich während einer Zeit, zu der die meisten Geräte gestartet sind, z.B. am Mittag um 12:00.

156

5.2 Windows Server Update Services (WSUS) Richtlinie

Beschreibung

Internen Pfad für Microsoft Updatedienst angeben

Diese Richtlinie gibt an, wohin interne Clients verbinden sollen, um auf neue Updates zu prüfen. Hier muss die URL der WSUSWebseite angegeben werden. Bedenken Sie, dass diese Webseite möglicherweise auf einem speziellen Port läuft oder per HTTPS angesprochen werden muss. Die Einstellung für beide Felder (Update- und Statistikserver) sollte in etwa wie folgt aussehen: https://wsus.smartdynamic.ch http://wsus.smartdynamic.ch:Portnummer Empfohlene Einstellung: Keine

Suchhäufigkeit für automatische Updates

Diese Richtlinie gibt an, wie oft Clients sich mit dem WSUS-Server verbinden und nach neuen Updates suchen. Der Standardwert liegt bei 22 h und wird noch um +/– 20% verkürzt bzw. verlängert. Diese Abweichung gilt auch dann, wenn eigene Werte eingegeben werden. Empfohlene Einstellungen: Der angegebene Standardwert reicht für die meisten Umgebungen aus und kann daher beibehalten werden.

Nichtadministratoren gestatten, Updatebenachrichtigungen zu erhalten

Legt fest, ob auch Nichtadministratoren benachrichtigt werden, wenn Updates heruntergeladen bzw. installiert werden. Empfohlene Einstellungen: Diese Richtlinie sollte deaktiviert werden, sodass Standardbenutzer keine Benachrichtigungen erhalten.

Automatische Updates sofort installieren

Diese Richtlinie legt fest, ob bestimmte Updates sofort nach dem Download installiert werden sollen. Empfohlene Einstellung: Aus Gründen der Planbarkeit sollte diese Richtlinie deaktiviert werden. So werden Updates gemäß konfiguriertem Zeitplan installiert.

Empfohlene Updates über automatische Updates aktivieren

Diese Richtlinie ist im Zusammenhang mit der Update-Prüfung gegen Microsoft Update relevant und gibt an, ob auch empfohlene Updates zur Installation angezeigt werden sollen. Ansonsten werden nur wichtige Updates angezeigt. Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden, damit empfohlene Updates angezeigt und installiert werden können.

Keinen automatischen Neustart für geplante Installationen durchführen

Beim Aktivieren dieser Richtlinie findet nach erfolgter UpdateInstallation kein Neustart des Rechners statt. Die Updates haben daher erst nach dem nächsten Reboot Gültigkeit. Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden,

157

5 Update-Management damit Benutzer nicht bei ihrer Arbeit unterbrochen werden. Je nach Update kann dies mehrmals hintereinander der Fall sein, was äußerst mühsam sein kann. Erneut zu einem Neustart für geplante Installationen auffordern

Wenn Updates installiert worden sind, ein Benutzer aber seinen Rechner nicht neu startet, wird er regelmäßig vom System aufgefordert, es neu zu starten (nicht wenn die Richtlinie „Keinen automatischen Neustart für geplante Installation durchführen“ aktiv ist). Mit dieser Richtlinie kann angegeben werden, wie häufig eine Benachrichtigung erfolgen soll. Empfohlene Einstellung: Verwenden Sie als nützlichen Mittelwert 30 Minuten als Einstellung. Für die meisten Benutzer wird diese Einstellung ohnehin keine Gültigkeit haben, weil deren Rechner nicht neu gestartet wird, wenn neue Updates installiert worden sind.

Neustart für geplante Installation verzögern

Nach Abschluss der Installation von Updates kann ein Neustart verzögert werden. Geben Sie bei Bedarf einen entsprechenden Wert an. Empfohlene Einstellung: Keine

Zeitplan für geplante Installation neu erstellen

Wenn Geräte Updates heruntergeladen haben, aber zum Zeitpunkt der geplanten Installation nicht gestartet waren, wird nach dem nächsten Neustart eine Installation gestartet. Damit sich diese nicht mit dem Start von Systemdiensten kreuzt, kann mit dieser Richtlinie eine zeitliche Verzögerung konfiguriert werden. Empfohlene Einstellung: Normalerweise reichen fünf Minuten aus, um ein System vollständig zu starten (bis tatsächlich alle Systemdienste und Treiber geladen sind). Eine Einstellung von fünf bis zehn Minuten macht daher am meisten Sinn.

Clientseitige Zielzuordnung aktivieren

Mit dieser Richtlinie können WSUS-Clients automatisch einer Computergruppe zugeordnet werden. Die Gruppen müssen zuvor manuell mithilfe der WSUS-Konsole erstellt werden. Empfohlene Einstellung: Keine Anmerkung: Wenn mit mehreren Gruppen gearbeitet wird, müssen auch mehrere Gruppenrichtlinien erstellt werden, um WSUS-Clients an Computergruppen zuzuweisen.

Signierte Inhalte aus internem Speicherort für MicrosoftUpdatedienste zulassen

Legt fest, ob Updates zwingend von Microsoft signiert sein müssen oder ob auch Signaturen von anderen Anbietern zugelassen werden sollen. Empfohlene Einstellung: Aus Kompatibilitätsgründen sollte diese Richtlinie aktiviert werden.

158

5.2 Windows Server Update Services (WSUS)

5.2.5

WSUS-Clients registrieren

Nachdem die notwendigen Gruppenrichtlinienobjekte erstellt worden sind, werden sich WSUS-Clients beim WSUS-Server registrieren und – falls konfiguriert – automatisch in der korrekten Computergruppe eintragen. Um diesen Prozess zu forcieren, kann auf einem WSUS-Client der Befehl „Wuauclt.exe /detectnow“ ausgeführt werden. Zuvor muss natürlich sichergestellt werden, dass die Geräte die neuen Gruppenrichtlinieneinstellungen erhalten haben. Dies kann ebenfalls forciert werden, diesmal mit dem Befehl „Gpupdate.exe /force“.

Abbildung 5.21 Registrierte WSUS-Clients

Nach der Registrierung kann es einige Minuten dauern, bis der Client vollständig verifiziert hat, welche Updates er tatsächlich benötigt. Der jeweilige Status ist in der WSUSKonsole ersichtlich.

5.2.6

Updates verwalten

Nachdem jetzt klar ist, welche Computer welche Updates benötigen, müssen diese im nächsten Schritt über den Bereich „Updates“ freigegeben werden. Hier können alle bekannten Updates mit Filtern optimal dargestellt werden. Der Filter mit der Bezeichnung „Erforderlich“ kann beispielsweise verwendet werden, um alle Updates anzuzeigen, die tatsächlich von WSUS-Clients benötigt werden. Nachdem die Updates angezeigt werden, können diese markiert und mittels Rechtsklick genehmigt werden.

159

5 Update-Management

Abbildung 5.22 Updates genehmigen

Zuletzt muss angegeben werden, für welche Computergruppen die Genehmigung erfolgen soll. Sie können Updates wahlweise für einzelne Computergruppen oder für alle Computer genehmigen.

Abbildung 5.23 Gruppen für Update-Genehmigung festlegen

Ab diesem Zeitpunkt werden die Updates tatsächlich von Microsoft (bzw. von der angegebenen Quelle) heruntergeladen und dann an die WSUS-Clients weitergegeben. Nachdem WSUS-Clients Updates installiert haben und ihren Status zurückgemeldet haben, kann die-

160

5.3 Rückblick se Information in Form einer einfachen Statistik angezeigt werden. Wenn Sie das WSUSServerobjekt markieren, erhalten Sie eine schnelle Übersicht über Computer, Updates, Installationsprobleme usw.

Abbildung 5.24 Zusammenfassung anzeigen

5.3

Rückblick Ein regelmäßiges Aktualisieren von Betriebssystemen und Anwendungen ist essenziell, um die Sicherheit, aber auch Funktionalität von Systemen gewährleisten zu können. Besonders im Firmenumfeld stellt dies eine echte Herausforderung dar, weshalb Administratoren nicht um den Einsatz von Hilfsmitteln wie beispielsweise WSUS herumkommen werden. In diesem Kapitel wollte ich Sie ein bisschen mit dem Produkt WSUS vertraut machen, auch wenn wir nicht alle Bereiche beleuchtet haben. WSUS kann noch deutlich mehr, und ich empfehle Ihnen, diesen Dienst ein bisschen genauer unter die Lupe zu nehmen.

161

6 Sicherer Netzwerkbetrieb Praktisch alle Rechner sind heute in irgendeiner Weise mit Netzwerken verbunden. Teilweise handelt es sich um Firmennetzwerke, teilweise um das Internet – in beiden Fällen aber kann ein Rechner mit anderen Geräten Informationen austauschen. Das ist einerseits äußerst praktisch, kann aber auch viele Risiken mit sich bringen. Wie auch immer Ihr Rechner mit Netzwerken verbunden ist, in diesem Kapitel werde ich die einzelnen Möglichkeiten einer sicheren Netzwerkanbindung erläutern und Sie mit den notwendigen Informationen ausrüsten, die Sie benötigen, um Ihr Gerät bedenkenlos mit bekannten, aber auch fremden Netzwerken zu verbinden.

6.1

Netzwerkverbindungen Windows Vista unterstützt verschiedene Arten von Netzwerkverbindungen, wovon die klassischen LAN- und WLAN-Anbindungen (Wireless LAN über Funk) zu den verbreitetsten gehören. Während LAN-Verbindungen praktisch überall zum Einsatz kommen, ist der Einsatz von WLAN in Hochsicherheitsnetzwerken nicht sehr verbreitet. Weshalb? Verkabelte Netzwerke (Wired) können physikalisch geschützt werden, Funknetze hingegen nicht. Natürlich können Access Points physikalisch gesichert, eine sichere Authentifizierung realisiert und eine Verschlüsselung der transportierten Daten ermöglicht werden, trotzdem lässt sich die „Luft“, die für den Transport von Daten verwendet wird, nicht physikalisch sichern – im Gegensatz zu einem verkabelten Netzwerk. Neben direkten Verbindungen besteht auch die Möglichkeit, sich remote mit einem Netzwerk zu verbinden, beispielsweise dann, wenn vom Heimarbeitsplatz eine Verbindung zum Firmennetzwerk aufgebaut wird, um anschließend auf Anwendungen oder Daten zuzugreifen. Für den Aufbau solcher virtueller privater Netzwerke (VPN) stellt Windows Vista die gängigen Tunnelprotokolle PPTP und L2TP zur Verfügung. Mit Windows Vista wurde ein neuer Dual-IP-Stack in das Betriebssystem integriert. Neben IPv4 wird nun auch IPv6 vollständig unterstützt und ist auch standardmäßig installiert. Ihr Windows Vista-Gerät kann also bereits nach der Installation mit IPv6 kommunizieren und

163

6 Sicherer Netzwerkbetrieb tut dies auch. Erschrecken Sie sich also nicht, wenn beim ersten „ipconfig /all“-Befehl einige seltsame IP-Adressen angezeigt werden, die mit dem alten Schema so gar nichts mehr zu tun haben. TCP/IP werden wir in diesem Buch nur streifen und uns auf die Schnittstellen zum sicheren Netzwerkbetrieb konzentrieren. Da Sie als Leser dieses Buchs bereits Erfahrungen mit Netzwerken und Protokollen haben, verzichte ich absichtlich darauf, Basisinformationen zum Thema TCP/IP zu vermitteln, die Sie langweilen. Mehr Informationen werden in einer Reihe guter Bücher zum Thema angeboten, die auf dem Markt verfügbar sind. Mit bestehenden Active Directory-Infrastrukturen, die auf Windows Server 2003 basieren, können nicht alle Netzwerkeinstellungen vorgenommen werden, die Windows Vista unterstützt. Obwohl Sie bereits mit den neuen ADMX-Dateien arbeiten, stehen verschiedene Funktionen für verkabelte und kabellose Netzwerkverbindungen nicht zur Verfügung. Erst Windows Server 2008 unterstützt diese Funktionen. Bis Ihre Domänencontroller auf die neuste Servergeneration migriert worden sind, muss daher eine Schemaaktualisierung vorgenommen werden, damit diese Einstellungen trotzdem genutzt werden können. Eine genaue Beschreibung inklusive den benötigten Skripten liefert folgender Microsoft-Artikel: http://www.microsoft.com/technet/network/wifi/vista_ad_ext.mspx Die zwei Skripte werden als LDF-Datei gespeichert und mithilfe des Tools ldifde.exe importiert. Um diesen Vorgang ausführen zu können, müssen Sie mit einem Konto angemeldet sein, das sich in den Gruppen Organisations-Admins und Domänen-Admins befindet. Zudem muss der Domänencontroller mit der Schema-Master-Rolle online und erreichbar sein. Der Import selber ist in wenigen Sekunden abgeschlossen.

Abbildung 6.1 Erweitern des Active Directory-Schemas

164

6.1 Netzwerkverbindungen

6.1.1

LAN-Verbindungen

Der physikalische Schutz von verkabelten Netzwerken ist nicht ganz einfach, aber dennoch einfacher zu realisieren als bei Funknetzwerken. Trotzdem: Falls jemand physikalischen Zugang zu Ihrem Netzwerk erhält, wie wollen Sie dann verhindern, dass diese Person ein bestehendes Gerät vom Netzwerk abhängt, um ein eigenes, mitgebrachtes Gerät mit dem Netzwerk zu verbinden? Dieses Szenario kann unterbunden werden, unter anderem damit, dass Geräte oder Benutzer vor dem Zugriff auf das Netzwerk authentifiziert werden. Als einfachste Variante kann dies auf Ebene des Switches erfolgen. Mithilfe von MACAdressfilterungen kann ein Netzwerkadministrator genau festlegen, an welchen SwitchPorts welche MAC-Adressen erwartet werden. Wird ein anderes Gerät an einem Port angeschlossen, kann der Switch die Kommunikation verweigern. Das funktioniert, allerdings ist die Sicherheit nicht wahnsinnig hoch und lässt sich mit sog. MAC-Spoofing einfach umgehen. Besser ist hierbei die Variante der Authentifizierung nach dem Standard IEEE802.1x, mit dem sich ebenfalls Geräte oder Benutzer authentifizieren lassen. Dabei spielt grundsätzlich auch keine Rolle, ob der Einsatz in einem verkabelten Netzwerk oder einem Funknetzwerk erfolgt, wichtig ist lediglich, dass die eingesetzten Geräte den IEE802.1x-Standard unterstützen. Sobald ein Gerät auf das Netzwerk zugreifen will, nimmt der jeweilige Switch bzw. Access Point die Anfrage entgegen, blockiert aber im ersten Schritt den vollständigen Netzwerkzugriff für das Gerät. Der Client übermittelt die geforderten Informationen mithilfe von EAPoL (EAP over LAN) zum Switch bzw. Access Point, der diese wiederum zu einem RADIUS-Server weiterleitet. Dort findet schlussendlich die Prüfung des Benutzers und/oder Geräts statt. Nach erfolgreicher Überprüfung wird der Netzwerkzugang freigegeben, und das Gerät kann sich regulär verbinden. Der Aufbau einer solchen Infrastruktur ist relativ komplex und sehr umfangreich. Für die Authentifizierung werden digitale Zertifikate benötigt, die zuerst an Clients bzw. Benutzer ausgestellt werden müssen. Anbei werden die wichtigsten Konfigurationsschritte aufgezeigt, die aus Sicht von Windows Vista relevant sind.

Neben den Netzwerkkomponenten, die diesen Standard unterstützen müssen, sind auch geeignete Betriebssysteme notwendig. Windows Vista wie auch Windows XP auf Clientseite, Windows Server 2003 und Windows 2000 Server inkl. Service Pack 4 unterstützen diesen Standard ebenfalls. Unter Windows Vista ist der Dienst standardmäßig deaktiviert und muss für einen Einsatz zuerst gestartet werden. Zudem muss die Startart des Dienstes auf „Automatisch“ umgestellt werden. Wie im Screenshot gezeigt, lassen sich die Dienste für LAN und WLAN – je nach Einsatzgebiet – getrennt aktivieren.

165

6 Sicherer Netzwerkbetrieb

Abbildung 6.2 Dienste für 802.1x-Authentifizierung aktivieren

Die Bezeichnung der gezeigten Dienste kann je nach Version unterschiedlich sein. Wird Windows Vista mit einem deutschen Sprachpaket genutzt, werden die Dienste wie im gezeigten Screenshot dargestellt. In einer vollständig deutschen Version werden die Dienste als „Automatische Konfiguration (verkabelt)“ und „Automatische WLAN-Konfiguration“ bezeichnet.

Nach erfolgter Aktivierung lässt sich die Konfiguration direkt auf der jeweiligen Netzwerkschnittstelle über den Reiter „Authentifizierung“ vornehmen.

Abbildung 6.3 802.1x-Authentifizierung einrichten

166

6.1 Netzwerkverbindungen Bereich „Authentifizierung“

Beschreibung

IEEE 802.1x-Authentifizierung aktivieren

Diese Option legt fest, ob ein Gerät Informationen an einen Switch bzw. Access Point übermitteln darf. Die Übermittlung kann von den jeweiligen Netzwerkgeräten für die Authentifizierung gefordert werden.

SmartCard- oder anderes Zertifikat

Wird diese Option gewählt, kann für die Authentifizierung ein instal-

Geschützter EAP (PEAP)

Bei dieser Variante wird zuerst ein TLS-Kanal zwischen den zwei Ge-

liertes Zertifikat oder ein SmartCard-Zertifikat eingesetzt werden.

räten aufgebaut und anschließend EAP verwendet, um die Authentifizierung auf Basis von Zertifikaten zu realisieren. Der Authentifizierungsprozess ist daher noch sicherer.

Die Konfigurationsmöglichkeiten, die über die Schaltfläche „Einstellungen“ zur Verfügung stehen, variieren je nach gewählten Optionen leicht.

Bereich „Einstellungen“

Beschreibung

Beim Herstellen der Verbindung „Eigene SmartCard verwenden“ oder „Zertifikat auf diesem Computer verwenden“

Für die Authentifizierung mit einem digitalen Zertifikat kann über die-

Serverzertifikat überprüfen

Ist diese Option aktiviert, prüft ein Client, ob das auf dem Server ver-

se Option festgelegt werden, ob das Zertifikat auf dem lokalen Computer gespeichert ist (in Zertifikatsspeicher) oder ob Benutzer über eine SmartCard mit installiertem Zertifikat verfügen.

fügbare Zertifikat gültig ist. Diese Option sollte genutzt werden, um sicherzustellen, dass eine Authentifizierung gegen den richtigen Server stattfindet. Vertrauenswürdige Stammzertifizierungsstellen

Ein Client vertraut standardmäßig verschiedenen Ausstellern von Zertifikaten. Bei der Überprüfung des Serverzertifikats wird unter anderem geprüft, ob der Aussteller vertrauenswürdig ist. Durch die Auswahl der entsprechenden Aussteller in dieser Liste kann festgelegt werden, welchen Ausstellern für die 802.1x-Authentifizierung vertraut werden soll. Dabei wird das Serverzertifikat geprüft und ermittelt, ob der Aussteller auf dem Client vertrauenswürdig ist oder nicht.

Authentifizierungsmethode wählen

Je nach gewählter Methode kann hier nochmals angegeben werden, welche Authentifizierungsmethode eingesetzt werden soll.

Wer noch einen Schritt weitergehen möchte, kann die Funktion NAP (Network Access Protection) einsetzen, für die in Windows Vista bereits ein Client enthalten ist. Serverseitig wird hierfür allerdings Windows Server 2008 vorausgesetzt, weshalb sich NAP derzeit noch nicht vollumfänglich nutzen lässt. So viel aber schon im Voraus: Mithilfe von NAP

167

6 Sicherer Netzwerkbetrieb können Administratoren sicherstellen, dass Geräte, die sich mit Netzwerken verbinden, einen vorgegebenen Status aufweisen. Das ist heute ein großes Problem, sowohl in Netzwerken als auch bei Remote-Verbindungen mittels VPN. Oft wird lediglich eine Authentifizierung eines Benutzers oder eines Geräts durchgeführt und bei Erfolg der Zugriff gewährt. In welchem Zustand sich ein Gerät aber befindet, wird selten geprüft. Um die Sicherheit von Netzwerken zu optimieren, sollte sichergestellt werden, dass Geräte – egal ob es sich um direkt verbundene Geräte oder um VPN-Geräte handelt – einen bestimmten Status aufweisen. Beispielsweise könnte geprüft werden, ob ein Gerät bestimmte Sicherheitsupdates der die aktuellste Definitionsdatei des Virenscanners installiert hat. Nur wenn diese (oder je nach Anforderungen auch mehr) Voraussetzungen erfüllt sind, wird einem Gerät der Zugriff auf das Netzwerk gewährt. Heute ist dies mithilfe der Quarantäne-Funktion für VPN-Clients bereits möglich. Mit NAP wird diese Sicherheit auf lokale Clients erweitert, um die Sicherheit in lokalen Netzwerken zu verbessern. Die Implementierung dieser Authentifizierungsmethoden ist serverseitig relativ komplex. Microsoft hat deshalb einige Dokumente veröffentlicht und die Konfigurationen schrittweise beschrieben. Folgende Tabelle enthält direkte Links zu diesen Dokumenten.

Titel

Link

802.1x für verkabelte Netzwerke implementieren

http://www.microsoft.com/downloads/details.aspx?familyid=05951071

802.1x (und andere Mechanismen) für Funknetze

http://www.microsoft.com/downloads/details.aspx?FamilyID=0f7fa9a2

Network Access Protection Policies in Windows Server 2008

http://www.microsoft.com/downloads/details.aspx?familyid=8E47649

-6B20-4CEF-9939-47C397FFD3DD&displaylang=en

-e113-415b-b2a9-b6a3d64c48f5&DisplayLang=en

E-962C-42F8-9E6F-21C5CCDCF490&displaylang=en

Falls diese Art der Authentifizierung großflächig eingesetzt werden soll, können die Einstellungen mithilfe von Gruppenrichtlinien verteilt werden. Dazu muss lediglich zuerst das Active Directory-Schema erweitert werden (bereits in diesem Kapitel beschrieben).

168

6.1 Netzwerkverbindungen

Abbildung 6.4 Richtlinie für verkabelte Netzwerke erstellen

Abbildung 6.5 Sicherheitsrichtlinie für verkabelte Netzwerke konfigurieren

169

6 Sicherer Netzwerkbetrieb

6.1.2

WLAN-Verbindungen

Bevor wir uns den allgemeinen Sicherheitsfunktionen im Bereich des Netzwerkbetriebs widmen, die für alle Arten von Netzwerkverbindungen relevant sind, möchten wir in das Thema WLAN eintauchen und prüfen, wie ein relativ sicherer Betrieb möglich ist. Wenn Sie sich entscheiden, WLAN einzusetzen, sollten Sie einige Hintergrundinformationen dazu aus diesem Buch mitnehmen, um die verfügbaren Sicherheitsfunktionen zu kennen, damit Ihre Implementierung nicht zum Einfallstor für Angreifer wird. Um mittels WLAN auf ein Netzwerk zuzugreifen, werden Access Points eingesetzt, welche die Schnittstelle zwischen WLAN-Client und physikalischem Netzwerk darstellen. Sie arbeiten als Türsteher und müssen sicherstellen, dass nur autorisierte Personen eine Verbindung zum physikalischen Netzwerk herstellen können. Zudem müssen sie sicherstellen, dass Daten zu bzw. von WLAN-Clients in irgendeiner Form verschlüsselt werden, damit die zu übertragenden Daten nicht von unautorisierten Personen abgehört werden können. Die letzte Sicherheitsstufe erfolgt auf Ebene der Anwendungen bzw. Daten. Mit den klassischen Mechanismen (z.B. Freigabe- und NTFS-Berechtigungen) wird ein Benutzer für den Datenzugriff autorisiert. Die Authentifizierung kann auf verschiedene Arten erfolgen. Einerseits können sich Benutzer und Geräte direkt am Access Point authentifizieren. Dies kann beispielsweise über einen vorinstallierten Schlüssel erfolgen, der sowohl auf dem Client als auch auf dem Access Point eingegeben werden muss. Sind die beiden Schlüssel identisch, ist ein Gerät bereits authentifiziert und kann eine Verbindung herstellen. Diese Methode bringt aber einige Probleme mit sich. Beim Austritt eines Mitarbeiters aus der Firma müssen alle vorinstallierten Schlüssel geändert werden, um sicherzustellen, dass diese Person keine Verbindungen mehr zum Access Point herstellen kann. Das kann in größeren Firmen sehr mühsam sein, wenn eine große Anzahl Mitarbeiter davon betroffen ist oder auch wenn viele Access Points eingesetzt werden. Besser ist beispielsweise eine Authentifizierung mittels RADIUS-Server. Der Access Point delegiert die Authentifizierung dabei an eine dritte Stelle, die wiederum mithilfe von Richtlinien entscheidet, ob eine Verbindung zugelassen werden soll oder nicht. Ist der Benutzer erfolgreich authentifiziert, meldet der RADIUS-Server dies dem Access Point, der den WLAN-Client anschließend mit dem Netzwerk verbindet. Eine Authentifizierung mit Zertifikaten ist ebenfalls denkbar, ist allerdings ein bisschen komplexer zum Umsetzen, weil dazu eine Zertifikatsserver-Infrastruktur aufgebaut werden muss. Der Vorteil beim Einsatz von Zertifikaten liegt bei der Authentifizierung, die sehr stark ist. Zertifikate von Mitarbeitern, welche die Firma verlassen, können auf dem Zertifikatsserver gesperrt werden. Bei der nächsten versuchten Authentifizierung wird das gesperrte Zertifikat erkannt und der Verbindungsaufbau unterbunden. Die Variante mit einem RADIUS-Server bietet einige Vorteile, weil einerseits viel umfangreichere Richtlinien festgelegt werden können, um Benutzer und Geräte zu authentifizieren, andererseits eine Konsolidierung der Authentifizierung auf ein einziges System vorgenommen werden kann, weil mehrere Access Points den gleichen RADIUS-Server nutzen können.

170

6.1 Netzwerkverbindungen Microsoft liefert in den Serverversionen ab Windows Server 2000 eine RADIUSImplementierung mit, die kostenfrei genutzt werden kann. Der Dienst nennt sich Internetauthentifizierungsdienst und kann über die Windows-Komponenten hinzugefügt werden. Einige Firmen bevorzugen es, WLAN-Zugänge in einem eigenen Netzwerksegment zu realisieren. Dieses Segment kann dann durch eine Firewall vom internen Netzwerk getrennt werden, sodass nochmals eine Sicherheitsschicht eingebettet werden kann. Mithilfe der Firewall lässt sich detailliert festlegen, auf welche Ressourcen WLAN-Clients zugreifen dürfen und welche Verbindungsanfragen schon an der Firewall blockiert werden. Diese Implementierung ist natürlich aufwendiger, bietet aber mehr Sicherheit.

Abbildung 6.6 WLAN-Implementierungsschema

Um ein Windows Vista-Gerät mit einem Access Point zu verbinden, bestehen verschiedene Möglichkeiten. Verbindungen können manuell konfiguriert werden, wozu allerdings verschiedene Informationen zum Access Point verfügbar sein müssen. In einer Firmenumgebung kann dies allerdings recht mühsam sein, weshalb WLAN-Netzwerke mithilfe von Gruppenrichtlinien vorkonfiguriert werden können, sodass sie Benutzern automatisch zur Verfügung stehen. WLAN-Verbindungen manuell einrichten Über das Netzwerk- und Freigabecenter lassen sich über den Menüpunkt Drahtlosnetzwerke verwalten jederzeit neue Verbindungen zu Access Points einrichten oder bestehende Verbindungen konfigurieren.

171

6 Sicherer Netzwerkbetrieb

Abbildung 6.7 WLAN-Verbindung manuell einrichten, Teil 1

Abbildung 6.8 WLAN-Verbindung manuell einrichten, Teil 2

172

6.1 Netzwerkverbindungen Einstellungen

Beschreibung

Netzwerkname

Geben Sie in diesem Feld die SSID, also die Netzwerkkennung des Access Points, ein.

Sicherheitstyp

Zur Authentifizierung stehen verschiedene Methoden zur Verfügung. Die in diesem Bereich vorgenommene Konfiguration muss mit derjenigen des Access Points übereinstimmen. Folgende Methoden stehen zur Verfügung: Keine Authentifizierung (Offen) Wird diese Methode gewählt, werden Daten, die zwischen dem WLANClient und dem Access Point übertragen werden, nicht verschlüsselt. Die Übertragung erfolgt vollständig im Klartext, weshalb diese Methode im Firmeneinsatz nicht verwendet werden sollte. Offene WLAN-Netzwerke, beispielsweise an Flughäfen, verwenden meistens diese Methode. WEP WEP steht für „Wired Equivalent Privacy“ und verwendet für die Verschlüsselung von Daten 40 Bit bzw. 104 Bit lange Schlüssel, die statisch sind und sich niemals ändern. Daher ist die Sicherheit verhältnismäßig schlecht. WEP-Schlüssel können innerhalb weniger Sekunden geknackt werden, wenn ein Angreifer genügend Datenpakete gesammelt hat, weshalb diese Verschlüsselungsart nicht eingesetzt werden sollte. WPA-Personal oder WPA-Enterprise WPA steht für „Wi-Fi Protected Access“. Das Verfahren baut auf WEP auf, verwendet allerdings dynamische Schlüssel, was einen erfolgreichen Angriff deutlich schwerer gestaltet. Der Unterschied zwischen der Personal- und der Enterprise-Variante liegt darin, dass für die EnterpriseVariante zwingend digitale Zertifikate für WLAN-Clients ausgestellt werden müssen, wodurch die Sicherheit beim Authentifizierungsprozess deutlich erhöht wird. WPA2-Personal oder WPA2-Enterprise WPA2 ist der Nachfolger von WPA. WPA2 ist gegenüber seinem Vorgänger noch sicherer, weil als Verschlüsselungsalgorithmus AES eingesetzt wird. 802.1x Diese Methode wird allgemein verwendet, um Geräte zu authentifizieren. Neben WLAN-Clients können auch normal verkabelte Geräte authentifiziert werden (am Switch, an dem sie angeschlossen sind). Im WirelessBereich kommt diese Methode heute aber wenig zum Einsatz.

173

6 Sicherer Netzwerkbetrieb Einstellungen

Beschreibung

Verschlüsselungstyp

Als Verschlüsselungstyp werden folgende Optionen zur Verfügung gestellt: Keine Dieser Verschlüsselungstyp – wenn man es denn so nennen darf – kommt automatisch dann zum Einsatz, wenn als Sicherheitstyp die Option Keine Authentisierung (Offen) gewählt worden ist. WEP Dieser schwache Verschlüsselungstyp kommt zum Einsatz, wenn als Sicherheitstyp WEP oder 802.1x verwendet wird. WEP basiert auf einem RC4-Chiffre und ist verhältnismäßig einfach zu knacken. Das Prinzip gilt mittlerweile als unsicher. TKIP Dieser Ausdruck steht für Termporal Key Integrity Protocol. Es handelt sich dabei um den Nachfolger von WEP und soll die Verschlüsselung der Daten optimieren. TKIP verwendet dynamische Schlüssel, die sich regelmäßig ändern. Selbst wenn ein Angreifer einen Schlüssel knacken kann, ist dieser nur während sehr kurzer Zeit einsetzbar und kann nur einen Bruchteil der übertragenen Daten entschlüsseln. AES Dieser Algorithmus wird standardmäßig von WPA2 verwendet und sichert Daten besser als TKIP.

Sicherheitsschlüssel/Passphrase

Je nach ausgewählten Methoden muss für die Authentifizierung des WLANClients an einem Access Point ein vorinstallierter Schlüssel oder eben eine Passphrase eingegeben werden. Dieser Schlüssel muss mit dem konfigurierten Schlüssel auf dem jeweiligen Access Point übereinstimmen und sollte eine hohe Komplexität aufweisen, um sicherzustellen, dass er nicht erraten werden kann. Falls von den zur Verfügung stehenden Sicherheitsmethoden die Enterprise-Versionen eingesetzt werden, kann kein Sicherheitsschlüssel eingegeben werden. Dann werden Computer mittels eines RADIUS-Server und Zertifikaten authentifiziert.

174

Diese Verbindung automatisch starten

Wird diese Option gewählt, verbindet sich ein WLAN-Client automatisch mit

Verbinden, selbst wenn das Netzwerk keine Kennung aussendet

Diese Option muss gewählt werden, wenn ein Access Point seine Netzwerk-

dem Netzwerk, sobald dieses in Reichweite ist.

kennung (SSID) nicht als Broadcast versendet. Viele Access Points halten ihre SSID verdeckt, um nicht erkannt zu werden. Ist dies bei der aktuellen Verbindung der Fall, muss diese Option aktiviert werden.

6.1 Netzwerkverbindungen Über das Netzwerk- und Freigabecenter können die eingerichteten Verbindungen jederzeit wieder konfiguriert oder gelöscht werden. Kommt ein WLAN-Client in die Reichweite eines Access Points, für das eine Netzwerkverbindung eingerichtet worden ist, kann sich dieser bei entsprechend markierter Option automatisch verbinden. Über das Netzwerksymbol in der Taskleiste kann eine Verbindung zudem jederzeit manuell aufgebaut oder abgebrochen werden. Dazu wird lediglich der Menüpunkt Verbindung mit einem Netzwerk herstellen verwendet und anschließend das gewünschte Netzwerk ausgewählt. Hier werden auch Netzwerke angezeigt, die nicht explizit eingerichtet worden sind, aber ihre SSID broadcasten. Somit ist es auch sehr einfach möglich, ein WLAN-Client mit neuen, noch nicht konfigurierten Netzwerken zu verbinden.

Abbildung 6.9 Mit einem WLAN-Netzwerk verbinden

WLAN-Verbindungen mittels Gruppenrichtlinien Administratoren können mithilfe von Gruppenrichtlinien Wireless-Einstellungen an Clients weitergeben. Einerseits können so Sicherheitseinstellungen weitergegeben werden, die ein WLAN-Client einhalten muss, aber auch die Vordefinition bekannter WLANNetzwerke ist möglich, sodass Anwender diese nicht manuell einrichten müssen. Zuerst muss allerdings eine Richtlinie für Clients erstellt werden. Hierfür kann jeweils eine Richtlinie für Windows XP- und/oder Windows Vista-Clients erstellt werden, für die anschließend die WLAN-Konfiguration vorgenommen werden kann.

175

6 Sicherer Netzwerkbetrieb

Abbildung 6.10 WLAN-Richtlinie erstellen

Die Richtlinienkonfiguration unterscheidet sich zwischen den beiden Richtlinien. Im gezeigten Beispiel werden lediglich die Windows Vista-basierten Einstellungen behandelt. Setzen Sie Windows XP-Geräte ein, können Sie die entsprechenden Konfigurationen ableiten. Nachdem die Richtlinie benannt worden ist, wird die aktuelle Konfiguration gezeigt.

Abbildung 6.11 WLAN-Einstellungen mittels Gruppenrichtlinien, Teil 1

176

6.1 Netzwerkverbindungen Einstellungen „Allgemein“

Beschreibung

Automat. Windows-WLANKonfigurationsdienst für Clients verwenden

Nur wenn diese Option aktiviert ist, werden die Richtlinieneinstellun-

Profile

Diese Liste zeigt die in der Richtlinie konfigurierten WLAN-Netzwerke

gen an Clients weitergegeben. Normalerweise sollte diese Option daher aktiviert sein.

mit deren detaillierten Einstellungen. Hinzufügen

Über diese Option können jederzeit neue WLAN-Netzwerke eingerichtet werden, wobei zwischen Infrastruktur (Access Points) und Ad-Hoc (direkte Verbindung von zwei WLAN-Clients) unterschieden wird.

Importieren/Exportieren

Über diese Schaltfläche können einzelne Netzwerkdefinitionen exportiert bzw. importiert werden. Die exportierten Daten liegen als XMLDatei vor und können so sehr einfach zwischen einzelnen Umgebungen transferiert werden, ohne diese immer wieder neu einzurichten.

Einstellungen „Netzwerkberechtigungen“

Beschreibung

Netzwerkname und Berechtigung

Eine Liste bekannter WLAN-Netzwerke. Administratoren können hier vorgeben, ob Verbindungen zu diesen Netzwerken explizit zugelassen oder verweigert werden. Selber erstellte WLAN-Netzwerke werden automatisch in diese Liste hinzugefügt und als Zugelassen markiert.

Verbindungen mit Ad-hocNetzwerken zulassen

Bei gesetzter Option können sich Benutzer mit Ad-hoc-Netzwerken

Verbindungen mit Infrastruktur-Netzwerken zulassen

Bei gesetzter Option können sich Benutzer mit Infrastruktur-

Anzeigen von abgelehnten Netzwerken für Benutzer zulassen

Bei gesetzter Option werden Benutzer benachrichtigt, wenn sie sich

Erstellen von Profilen für alle Benutzer für jeden zulassen

Bei gesetzter Option können Benutzer, die manuell ein WLAN-

verbinden, ansonsten nicht.

Netzwerken (Access Points) verbinden, ansonsten nicht.

mit einem Netzwerk verbinden möchten, das in der Netzwerkliste als Verweigert eingestuft ist.

Netzwerk auf einem Client einrichten, dieses für alle Benutzer verfügbar machen, die sich am Client anmelden. Ist die Option nicht gesetzt, können Benutzer die Netzwerke ausschließlich selber nutzen. Administratoren hingegen können hinzugefügte Netzwerke immer allen Benutzern zur Verfügung stellen.

Jetzt ist es an der Zeit, Netzwerke zu erfassen, sodass diese den entsprechenden WLANClients neben den allgemeinen Richtlinien auch zur Verfügung stehen. Dazu können Ad-

177

6 Sicherer Netzwerkbetrieb ministratoren beliebig viele WLAN-Netzwerke vom Typ Infrastruktur oder Ad-Hoc vorkonfigurieren.

Abbildung 6.12 WLAN-Einstellungen mittels Gruppenrichtlinien, Teil 2

Einstellungen „Verbindung“

Beschreibung

Profilname

Diese Einstellung gibt eine aussagekräftige Bezeichnung für das WLAN-Netzwerk zur einfachen Identifikation an.

Netzwerkname (SSID)

Diese Option legt die vom WLAN-Netzwerk verwendete SSID fest. Der eingegebene Wert muss mit demjenigen des entsprechenden Netzwerks genau übereinstimmen.

Automatisch verbinden, wenn dieses Netzwerk in Reichweite ist

Bei gesetzter Option verbindet sich ein Client automatisch mit dem

Mit einem verfügbaren bevorzugteren Netzwerk verbinden

Fall mehrere Netzwerke gleichzeitig in Reichweite sind, kann mit die-

Netzwerk, sobald dieses in Reichweite ist. Ist die Option nicht gesetzt, muss ein Benutzer eine manuelle Verbindung vornehmen.

ser Option festgelegt werden, dass keine automatische Verbindung initiiert wird, sofern ein anderes Netzwerk mit höherer Priorität bereits verbunden ist (manuell oder automatisch).

Verbinden, selbst wenn das Netzwerk keine Kennung aussendet

178

Diese Option ermöglicht eine Verbindung selbst dann, wenn ein Access Point seine SSID nicht als Broadcast im Netzwerk versendet.

6.1 Netzwerkverbindungen Die Optionen, die über den Reiter Sicherheit zur Verfügung stehen, unterscheiden sich je nach gewählter Konfiguration. Einige Einstellungen sind identisch zu den bereits erwähnten Einstellungen im Abschnitt LAN-Verbindungen.

Einstellungen „Sicherheit“

Beschreibung

Authentifizierung

Diese Option legt den Sicherheitstyp des Netzwerks fest. Je nach gewählter Option stehen unterschiedliche Konfigurationsmöglichkeiten zur Verfügung.

Verschlüsselung

Diese Option legt das Verschlüsselungsverfahren fest.

Netzwerkauthentifizierungsmethode und -modus

Bei Enterprise-Lösungen kann über diese Option die Authentifizierung mittels Zertifikaten gesteuert werden.

Sobald Clients die neuen Gruppenrichtlinieneinstellungen erhalten haben, stehen die Netzwerke zur Verfügung. Die Netze können angezeigt, aber nicht verändert werden.

Abbildung 6.13 Mit Gruppenrichtlinien zugewiesene Netzwerke

179

6 Sicherer Netzwerkbetrieb

6.1.3

Virtuelle private Netzwerke (VPN)

In den letzten Jahren sind VPNs immer beliebter geworden, weil es mithilfe dieser Verbindungsarten sehr einfach möglich ist, sich über das Internet (oder natürlich auch über andere Netzwerke) mit einem Firmennetzwerk zu verbinden, um dort auf Anwendungen und Daten zuzugreifen. Windows Vista unterstützt ausgehende Verbindungen mit den Protokollen PPTP und L2TP, um Anmeldeinformationen und Daten sicher von A nach B und umgekehrt zu übertragen. Bevor Sie eine ausgehende VPN-Verbindung einrichten, müssen Sie entscheiden, welches der beiden Protokolle eingesetzt werden soll. Das ist primär natürlich abhängig von der eingesetzten VPN-Gateway-Infrastruktur, welche die Verbindung annehmen wird. Möglicherweise wird dort ein bestimmtes Protokoll gefordert. Eventuell werden aber auch beide Protokolle unterstützt, damit Benutzer entscheiden können, welches genutzt werden soll. Wo aber liegen die Unterschiede? Folgende Tabelle gibt Aufschluss.

Protokoll PPTP

Beschreibung Point-to-Point Tunneling Protocol Verschlüsselung mit Microsoft Point-to-Point Encryption (MPPE), d.h. RC4-Verfahren mit 128-Bit-Verschüsselung Benutzerauthentifizierung unterstützt NAT-fähig (ohne weitere Voraussetzungen) TCP/IP und andere Protokolle können übertragen werden

L2TP

Layer 2 Tunneling Protocol Verschlüsselung mit IPsec und Verschlüsselungsstärken von 56 Bit (DES), 3 x 56 Bit (3DES) oder AES (256 Bit) Benutzer- und Computerauthentifizierung unterstützt NAT-fähig, sofern beide Geräte NAT-T unterstützen Nur TCP/IP kann übertragen werden

PPTP ist heute sehr verbreitet und flexibel, zudem recht einfach zu implementieren. Der Nachteil besteht in der weniger starken Verschlüsselung und darin, dass lediglich Benutzer, aber nicht Endgeräte authentifiziert werden. Die Sicherheit ist indirekt abhängig von den Benutzerkennwörtern, da diese verwendet werden, um geheime Informationen auszutauschen. Bei einem PPTP-Einsatz sollten daher ausschließlich starke Benutzerkennwörter eingesetzt werden, die regelmäßig geändert werden. Beim Einsatz von L2TP werden neben Benutzern auch die Endgeräte, also die Computer authentifiziert, die den Tunnel aufbauen und verwalten, was eine weitere Sicherheitsebene implementiert. Für diese Authentifizierung können wahlweise digitale Zertifikate (bevorzugt) oder vorinstallierte Schlüssel (Pre-Shared Keys) genutzt werden.

180

6.1 Netzwerkverbindungen Mit Windows Vista lassen sich ausgehende Verbindungen mit beiden Protokollen sehr einfach über das Netzwerk- und Freigabecenter einrichten und verwalten.

Abbildung 6.14 Ausgehende VPN-Verbindung einrichten, Teil 1

Abbildung 6.15 Ausgehende VPN-Verbindung einrichten, Teil 2

181

6 Sicherer Netzwerkbetrieb Nachdem das Verbindungsziel und die Anmeldeinformationen eingegeben worden sind, wird die VPN-Verbindung erstellt. Nachträglich können (und sollten) verschiedene Detailkonfigurationen direkt über die Verbindung vorgenommen werden. Hier kann festgelegt werden, welches Protokoll für den Aufbau des VPN-Tunnels eingesetzt werden soll. Standardmäßig wird „Automatisch“ verwendet, was bedeutet, dass zuerst versucht wird, den Tunnel mittels L2TP aufzubauen. Wenn dies fehlschlagen sollte, ist PPTP zu verwenden. Für höchste Sicherheit sollten Sie hier L2TP wählen. Bedenken Sie aber, dass in diesem Fall ein digitales Zertifikat oder zumindest ein vorinstallierter Schlüssel (eine simple Zeichenfolge beliebiger Länge) auf dem Gerät installiert werden muss. Nicht verwendete Dienste sollten auf der VPN-Verbindung entbunden werden. In den meisten Fällen werden VPN-Verbindungen verwendet, um auf Ressourcen in einer Firma zuzugreifen. Ein Zugriff von Firmengeräten auf den angebundenen VPN-Client ist hingegen nur ganz selten notwendig. In diesem Fall kann der Dienst für die Datei- und Druckfreigabe entbunden werden (unter Umständen können Sie auch noch weitere Dienste entbinden). Über den Reiter Sicherheit lässt sich schlussendlich festlegen, wie der VPN-Client Anmeldeinformationen und Daten zum Server übermitteln möchte. Der Server muss diese Einstellungen ebenfalls unterstützen, damit ein Austausch erfolgen kann. Da es sich um ein VPN handelt, fordert der Client die sichere Kennwortübertragung (MS-CHAPv1/2) und natürlich auch die Verschlüsselung der Daten. Diese Einstellungen sollten Sie unbedingt so beibehalten, um sicherzustellen, dass Ihr Client nicht versehentlich ungeschützt Daten zum Server übermittelt, falls dieser (möglicherweise wegen einer Fehlkonfiguration) keine Verschlüsselung fordert oder unterstützt.

Abbildung 6.16 Eigenschaften von VPN-Verbindungen konfigurieren

182

6.2 Die Windows-Firewall Wie auf allen Verbindungen auch macht es Sinn, für VPN-Verbindungen die WindowsFirewall zu aktivieren. Dieses Thema wird gleich in diesem Kapitel behandelt und gibt Ihnen wertvolle Informationen über den korrekten Einsatz dieses mächtigen Werkzeugs.

6.2

Die Windows-Firewall Sobald ein Gerät mit einem Netzwerk verbunden ist, ist es einem erhöhten Risiko ausgesetzt, unabhängig davon, ob es sich um ein Firmennetzwerk, ein fremdes Netzwerk, ein WLAN oder ein VPN handelt. Natürlich sind nicht alle Netzwerke gleich kritisch, trotzdem sollte für jedes dieser Netze der höchstmögliche Schutz aktiviert werden. Ein wichtiges Element des sicheren Vista-Betriebs stellt deshalb die Windows-Firewall dar. Eine Firewall auf Desktopebene stellt sicher, dass nur explizit zugelassene Verbindungen zu und von einem Gerät hergestellt werden können, andere Verbindungsversuche hingegen blockiert werden. Sie stellt also eine wichtige Komponente des gesamten Sicherheitsprozesses und -konzepts dar. Einige werden die Frage aufwerfen, ob eine desktopbasierte Firewall überhaupt Sinn macht. Um es vorwegzunehmen: Ja, es macht sehr wohl Sinn. Selbst ein Netzwerk, das über die beste und sicherste zentrale Firewall-Infrastruktur verfügt, die sämtliche eingehende Verbindungen bis auf Anwendungsebene inspiziert, kann im Fall eines internen Angriffs oder Virenausbruchs nichts unternehmen. Eine begrenzte Ausnahme besteht dann, wenn ein internes Netzwerk mit Firewalls segmentiert ist, beispielsweise um Server, die verschiedene Rollen ausüben oder unterschiedlich geschützt werden müssen, voneinander zu trennen. Aber selbst dann stellt diese Infrastruktur nur einen begrenzten Schutz dar. Es wäre auch möglich, dass die zentrale Firewall kompromittiert oder die Filterung durch Fehlmanipulation eines Administrators teilweise oder ganz außer Kraft gesetzt wird. In diesem Fall wären Endgeräte – zumindest firewall-technisch – ungeschützt und daher einfacher anzugreifen. Das gleiche Szenario finden wir bei mobilen Anwendern, die beispielsweise ihr Notebook mit auf Geschäftsreisen nehmen und mit fremden, nicht vertrauenswürdigen Netzwerken verbinden. Hier besteht ohne lokale Firewall überhaupt kein Schutz mehr. Es existieren sogar Konzepte, die vorsehen, zentrale Firewall-Infrastrukturen komplett zu eliminieren und den Schutz an die Endgeräte weiterzugeben. Darüber kann man sich streiten, und es gibt für diesen wie auch für den klassischen Ansatz viele Vorund Nachteile – aber diese zu diskutieren gehört nicht in dieses Buch. Konzentrieren wir uns weiter auf Windows Vista. Nebst den bereits erwähnten Szenarien müssen sich Administratoren eine weitere Frage stellen: Welche ausgehenden Verbindungen dürfen von bestimmten Geräten hergestellt werden? Auf diese Frage werden Sie in der Praxis oft die Antwort hören: „Natürlich alles, das hat auf die Sicherheit keinen Einfluss.“ Das ist ein weit verbreiteter Irrtum, weil genau dadurch ein weiteres Sicherheitsloch geöffnet wird. Wenn ein Gerät beliebige Verbindungen zu Zielen herstellen darf, könnte beispielsweise ein Virus dieses Freiticket verwenden, um sich über beliebige Ports weiterzuverbreiten. Auch von Angreifern installierte Werk-

183

6 Sicherer Netzwerkbetrieb zeuge, Skripte usw. könnten uneingeschränkt arbeiten und so den bereits entstandenen Schaden noch zusätzlich vergrößern. Weshalb sollten Geräte, die niemals Internetressourcen benötigen, die Möglichkeit des Internetzugriffs haben? Schränken Sie diese Verbindungen ein, zentral oder mithilfe einer lokalen Firewall direkt am Client. Das Gleiche gilt natürlich auch für den Serverbereich. Beispielsweise benötigt ein Domänencontroller nur in seltenen Fällen Internetzugriff. Auch diese Verbindungen sollten eingeschränkt werden. Ich könnte hier noch viele weitere Beispiele anfügen, aber die aufgeführten dürften bereits ausreichen, um Sie ein bisschen sensibilisiert zu haben. Zusammenfassen könnte man diese kurze Einführung in etwa wie folgt: Mithilfe von desktopbasierten Firewalls wird die Gesamtsicherheit einer IT-Infrastruktur erweitert, und zwar bis zu den jeweiligen Endgeräten, die einen Schutz effektiv benötigen. Was aber bietet jetzt die neue Windows Vista-Firewall genau? Gegenüber dem Vorgänger unter Windows XP ist die Vista-Firewall überarbeitet worden und bringt zahlreiche Neuerungen und Erweiterungen mit sich. Dazu gehören u.a. folgende: Statusbehaftete Paketfilterung Mithilfe der Paketfilterung haben Firewalls die Möglichkeit, unerwünschte Pakete zu erkennen und zu verwerfen. Dazu prüfen Sie bei Paketen Informationen wie beispielsweise das verwendete Transportprotokoll oder die genutzten Kommunikationsports. Verbindungen, die demnach nicht explizit zugelassen werden, können nicht hergestellt werden. Aussagen, dass Paketfilter-Firewalls nicht sicher sind, stimmen nur begrenzt. Vielmehr stellt sich die Frage, was die Aufgabe einer solchen Firewall genau ist. Paketfilter werden primär dort verwendet, wo Verbindungen blockiert werden müssen, und dafür sind sie gut geeignet. Viele Paketfilter (und so auch die Windows Vista-Firewall) setzen zudem eine statusbehaftete Filterung ein. Anstatt jedes Paket isoliert zu prüfen, wird bei eingehenden Verbindungen darauf geachtet, dass Pakete zu einem gültigen Datenstrom gehören. Problematisch sind Paketfilter-Firewalls dort, wo Verbindungen explizit zugelassen werden müssen, z.B. wenn eine Firewall eingehende Verbindungen zu einem Webserver zulassen muss. Über solche offenen Verbindungen lassen sich nicht nur die gewünschten Verbindungen herstellen, sondern auch andere Verbindungen tunneln. Und um solche Angriffe zu erkennen, benötigt eine Firewall weitere Möglichkeiten, nämlich sog. Anwendungsfilter, die eingehende Verbindungen detailliert und bis auf Anwendungsebene inspizieren können. Diese Funktionen werden von Enterprise-Firewalls zur Verfügung gestellt – Windows Vista unterstützt diese Art der Filterung nicht. Kontrolle von ein- und ausgehenden Verbindungen Nebst eingehenden können optional auch ausgehende Verbindungen blockiert werden. Profilbasierte Konfiguration. Die Firewall-Einstellungen passen sich den jeweiligen Umgebungen, in denen sich ein Client befindet, automatisch an.

184

6.2 Die Windows-Firewall Kontrolle von Authentizität und Datenintegrität und Datenverschlüsselung Mithilfe von IPsec kann die sichere Kommunikation mit bekannten Partnern deutlich besser geschützt werden. Zentrale Verwaltung mithilfe von Gruppenrichtlinien Administratoren haben die Möglichkeit, Windows-Firewalls eines Unternehmens zentral mithilfe von Gruppenrichtlinien zu konfigurieren und mit den notwendigen Regeln auszurüsten. Wenn die Vista-Firewall eingesetzt werden soll, stehen grundsätzlich zwei Konfigurationsmöglichkeiten zur Verfügung. Über die Standardkonsole kann die FirewallKomponente nur begrenzt konfiguriert werden, bietet aber die wichtigsten Einstellungsmöglichkeiten in einer Form, die ein Anwender noch einigermaßen interpretieren und konfigurieren kann. Über die vereinfachte Darstellung lässt sich die Firewall ein- oder ausschalten, zudem können eingehende Verbindungen gesteuert werden – mehr aber nicht. Für die vollständige Kontrolle der Vista-Firewall wird die erweiterte Konsole benötigt. Mit dieser können nebst ein- auch ausgehende Verbindungen profilbasiert gesteuert werden; zusätzlich lassen sich auch Einstellungen für den Bereich Authentizität, Datenintegrität und Datenverschlüsselung vornehmen. Ein großer Vorteil der neuen Vista-Firewall stellt der profilgesteuerte Ansatz dar. Besonders bei mobilen Geräten, die sich mit unterschiedlichen Netzwerken verbinden, bestehen oft unterschiedliche Anforderungen. Solange sich mobile Geräte im firmeninternen Netzwerk befinden, möchten Sie möglicherweise Remote-Desktop- oder Remote-AssistanceVerbindungen auf diese Geräte zulassen, sodass Benutzer bei Problemen unterstützt werden können – die Desktop-Firewall muss also über bestimmte Ausnahmen verfügen, damit diese Verbindungen möglich werden. Wenn ein Anwender hingegen das Firmennetzwerk verlässt und sich mit einem fremden, möglicherweise unsicheren Netzwerk verbindet, möchten Sie genau diese Verbindungen mit der Firewall blockieren. Das ermöglicht jetzt der neue, profilgesteuerte Ansatz der Vista-Firewall. Sie bedient sich hierzu des Diensts mit der Bezeichnung Network Location Awareness (NLA), der sämtliche Netzwerke, mit dem ein Gerät verbunden wird, aufgrund verschiedener Charakteristiken (z.B. verfügbare Domänencontroller, MAC-Adressen des Default-Gateways usw.) registriert. Sobald ein Gerät mit einem neuen, unbekannten Netzwerk verbunden wird, muss der Anwender festlegen, um welchen Typ es sich bei diesem Netzwerk handelt. Die Angabe wird gemeinsam mit den Charakteristiken des Netzwerks gespeichert. Wenn ein mobiles Gerät zu einem späteren Zeitpunkt mit einem Netzwerk verbunden wird, das der Anwender bereits einmal klassifiziert hat, ist keine erneute Zuordnung notwendig. Windows Vista erkennt dieses Netzwerk und dessen Typ automatisch. Zu guter Letzt lässt sich mit der erweiterten Konsole das Verhalten eines Geräts betreffend Authentizität, Datenintegrität und/oder Datenverschlüsselung konfigurieren. Was steckt da aber genau hinter? Mit der Authentizität wird sichergestellt, dass zwei Geräte sich gegenseitig authentifizieren müssen, bevor Daten ausgetauscht werden können, wodurch ein Empfänger bzw. ein Absender eines Pakets garantiert werden kann. Mithilfe von Verbin-

185

6 Sicherer Netzwerkbetrieb dungssicherheitsregeln lässt sich das Verhalten eines Geräts konfigurieren. So kann beispielsweise angegeben werden, ob gegenseitige Authentifizierung für ein- und/oder ausgehende Verbindungen verwendet werden soll, zu welchen Zielgeräten dieses Verhalten erwünscht und ob dieses optional oder zwingend ist. Zudem lässt sich auch hier festlegen, für welche Netzwerktypen (Profile) eine Konfiguration Gültigkeit hat. Zusätzlich zur gegenseitigen Authentifizierung lässt sich festlegen, ob und wie zu übertragende Daten geschützt werden sollen. So kann etwa sichergestellt werden, dass Daten während der Übertragung nicht verändert worden sind. Ist dies doch der Fall, wird die Veränderung am Zielgerät bemerkt und das Paket verworfen. Um die Sicherheit nochmals zu erhöhen, können bestimmte Verbindungen komplett verschlüsselt werden. Die so übertragenen Daten sind abhörsicher und genießen daher optimalen Schutz. Bedenken Sie aber, dass dadurch auch die Leistung der jeweiligen Endgeräte beeinträchtigt werden könnte. Die gegenseitige Authentifizierung, die Sicherstellung der Datenintegrität sowie die Verschlüsselung von Daten gehören eigentlich zum Thema IPsec (IP Security), wurden aber aus Gründen der Übersichtlichkeit in die erweiterte Konsole der Vista-Firewall eingebaut. Dadurch lassen sich nun auch diese Einstellungen transparent und zentralisiert mit der Firewall-Konfiguration verwalten. So, und nun möchten wir uns endlich anschauen, wie die einzelnen Komponenten konfiguriert werden.

6.2.1

Netzwerktypen für Netzwerke festlegen

Sobald ein Rechner zum ersten Mal mit einem Netzwerk verbunden wird, wird folgender Dialog angezeigt, um den geeigneten Netzwerktyp festzulegen:

Abbildung 6.17 Netzwerktyp festlegen

186

6.2 Die Windows-Firewall Netzwerktyp

Beschreibung

Domäne

Dieser Netzwerktyp wird automatisch für ein Netzwerk zugewiesen, wenn ein Gerät mit einem Netzwerk verbunden wird, in dem sich ein Domänencontroller befindet, zu dem das Gerät gehört – das Gerät befindet sich sozusagen „zu Hause“. Bei diesem Netzwerk handelt es sich um das vertrauenswürdigste Netzwerk. Die Zugehörigkeit kann nicht manuell verändert werden.

Privat (Zu Hause, Arbeitsplatz)

Dieser Netzwerktyp wird einem Netzwerk manuell zugewiesen, wenn es sich um ein privates, bekanntes Netzwerk handelt. Wenn ein mobiles Gerät beispielsweise zu Hause mit dem privaten Netzwerk verbunden wird, kann diesem Netzwerk der Typ „Privat“ zugeordnet werden. Bei der Zuweisung des Netzwerktyps werden dazu zwei Subtypen zur Auswahl bereitgestellt: „Zu Hause“ oder „Arbeitsplatz“ Wichtig: Anwender benötigen administrative Rechte, um ein Netzwerk als Privat (Home oder Work) einzustufen

Öffentlich

Wird ein Gerät mit einem unbekannten Netzwerk verbunden, wird dieser Typ verwendet, beispielsweise dann, wenn ein mobiles Gerät an einem Kundennetzwerk oder an einem öffentlichen Access Point angebunden wird. Diese Netzwerke unterliegen nicht der eigenen Kontrolle und gelten daher grundsätzlich als unsicher.

Aufgrund des Netzwerktyps aktiviert Windows Vista das jeweilige Firewall-Profil. Daher ist es wichtig, dass Anwender den jeweils korrekten Netzwerktyp zuweisen. Ansonsten wird ein Gerät möglicherweise aufgrund einer zu lockeren Firewall-Konfiguration – die für private Netzwerke gedacht wäre – einem erhöhten Risiko ausgesetzt. Um ein Netzwerk als privat („Zu Hause“ oder „Arbeitsplatz“) zu klassifizieren, benötigen Benutzer daher Administrationsrechte. Sind diese nicht vorhanden, werden alle neuen Netzwerke als öffentlich eingestuft und die Windows Vista-Firewall mit dem restriktivsten Einstellungen versehen.

Der zugewiesene Netzwerktyp eines Netzwerk kann jederzeit wieder geändert werden. Wechseln Sie dazu in der Systemsteuerung zum Netzwerk- und Freigabecenter (Netzwerk und Internet\Netzwerk- und Freigabecenter), und klicken Sie neben der Anzeige des derzeit verbundenen Netzwerks auf den Menüpunkt „Anpassen“. Wählen Sie denjenigen Netzwerktyp aus, der am besten auf das verbundene Netzwerk zutrifft.

187

6 Sicherer Netzwerkbetrieb

Abbildung 6.18 Netzwerktyp für das aktuell verbundene Netzwerk anpassen

Aufgrund des festgelegten Netzwerktyps werden neben dem Firewall-Profil auch andere Bereiche angepasst. So kann angegeben werden, ob das eigene Gerät im Netzwerk sichtbar sein soll und welche Bereiche (Freigaben, Drucker, Medien) anderen Netzwerkbenutzern zur Verfügung stehen sollen. Im unteren Bereich des Netzwerk- und Freigabecenters lässt sich diese Konfiguration anpassen.

6.2.2

Die Standardkonsole der Windows-Firewall

Sehen wir uns zuerst die Möglichkeiten in der Standardkonsole an. Wechseln Sie dazu in der Systemsteuerung zu Sicherheit\Windows Firewall. Über das angezeigte Fenster ist sofort ersichtlich, ob die Firewall derzeit aktiviert ist oder nicht, sowie eine grobe Zusammenfassung der Konfiguration. Über den Menüpunkt „Einstellungen ändern“ kann die Firewall über die Standardkonsole den Bedürfnissen entsprechend angepasst werden. Hier lässt sich die Firewall ein- und ausschalten und zudem angeben, ob Ausnahen zugelassen werden sollen. Ausnahmen stellen eingehende Verbindungen dar, die trotz aktivierter Firewall zugelassen werden. Über den Reiter „Ausnahmen“ können die gewünschten Verbindungen konfiguriert werden. Ausnahmen stellen einerseits Verbindungen zu lokal installierten Anwendungen dar, aber auch explizit angegebene Kommunikationsendpunkte, d.h. Ports.

188

6.2 Die Windows-Firewall

Abbildung 6.19 Änderungen an der Firewall-Konfiguration vornehmen

Abbildung 6.20 Windows-Firewall aktivieren und Ausnahmen festlegen

189

6 Sicherer Netzwerkbetrieb Um zu ermöglichen, dass andere Geräte mit lokal installierten Anwendungen kommunizieren können, müssen diese über die Schaltfläche „Programm hinzufügen“ spezifiziert werden. Bei der Installation von Anwendungen bzw. beim ersten Programmstart wird eine Benachrichtigung angezeigt, ob die Firewall automatisch für die neue Anwendung angepasst werden soll (wenn die Option „Benachrichtigen, wenn ein neues Programm geblockt wird“ aktiviert ist). Wenn Sie diese Nachricht bestätigen, wird eine solche Ausnahme neu hinzugefügt. Falls sonstige Verbindungen zugelassen werden sollen, können diese ebenfalls angegeben werden. Dann allerdings müssen Sie die genauen Protokolldaten kennen, d.h., Sie müssen wissen, über welche Ports eine Verbindung hergestellt wird und auf welchem Protokoll (TCP oder UDP) die Kommunikation basiert. Für Anwendungen und für Ports können noch Bereiche angegeben werden, um eingehende Verbindungen einzuschränken. Wenn somit bekannt ist, welche „fremden“ Geräte Verbindungen zum eigenen Gerät herstellen müssen bzw. dürfen, kann eine Ausnahme nur für genau diese Geräte mithilfe von IP-Adressen und Subnetzangaben konfiguriert werden. Verbindungen von anderen Geräten werden blockiert.

Abbildung 6.21 Neue Ausnahmen hinzufügen

190

6.2 Die Windows-Firewall Zum Abschluss der Konfiguration muss dann noch angegeben werden, welche Netzwerkverbindungen mit der Firewall geschützt werden sollen. Die Windows-Firewall kann dabei alle Verbindungsarten schützen, also z.B. LAN-, Wireless- und VPN-Verbindungen.

Abbildung 6.22 Zu schützende Netzwerkverbindungen festlegen

6.2.3

Die erweiterte Konsole der Windows-Firewall

Bis jetzt scheint sich die neue Windows Vista-Firewall kaum von ihren Vorgängern zu unterscheiden, aber das wird sich ändern, wenn wir uns die erweiterte Konfigurationskonsole anschauen werden. Die neuen Funktionen, die ich in der Einleitung erwähnt habe, werden hier konfiguriert, und diese machen die Konfiguration in der erweiterten Konsole auch deutlich komplexer. Starten Sie dazu eine Management Console, und fügen Sie das SnapIn „Windows-Firewall mit erweiterter Sicherheit“ hinzu.

191

6 Sicherer Netzwerkbetrieb

Abbildung 6.23 Die erweiterte Konsole für die Firewall-Konfiguration

Windows-Firewall-Eigenschaften Bevor wir uns mit Regeln, Verbindungssicherheitsregeln und anderen Elementen befassen, sollten wir die Basiseigenschaften konfigurieren. Klicken Sie dazu auf den Menüpunkt „Windows-Firewalleigenschaften“. Dort angelangt, ist sofort ersichtlich, dass es drei Reiter für die Basiskonfiguration der unterschiedlichen Firewall-Profile gibt. Pro Profil lässt sich angeben, ob eingehende und/oder ausgehende Verbindungen von der Firewall kontrolliert und je nach Konfiguration blockiert und ob diese Verbindungen für eine allfällige Analyse protokolliert werden sollen. Sie werden bemerken, dass die Firewall für alle drei Profile aktiviert ist, ausgehende Verbindungen grundsätzlich zugelassen sind. Wichtig ist, dass es sich bei den angegebenen Einstellungen lediglich um die Ausgangskonfiguration handelt. In einem zweiten Schritt können explizite Ausnahmen konfiguriert werden, die spezifische Verbindungen zulassen oder blockieren. Zudem ist die Protokollierung deaktiviert. Wenn Sie ein bisschen genauer über erfolgreiche und erfolglose Verbindungsversuche auf Ihr System informiert werden möchten, empfiehlt es sich, die Protokollierung einzuschalten. Allerdings ist eine Auswertung der Protokollierungsdateien nicht ganz einfach.

192

6.2 Die Windows-Firewall

Abbildung 6.24 Windows-Firewall-Eigenschaften, Teil 1

Über die Schaltfläche „Anpassen“ im Bereich „Einstellungen“ können weitere Basiskonfigurationen vorgenommen werden. Beispielsweise kann das Verhalten des Systems festgelegt werden, wenn eine Anwendung von der Firewall daran gehindert wird, eingehende Verbindungen anzunehmen. Standardmäßig wird der Benutzer mit einer Benachrichtigung darauf aufmerksam gemacht, sodass die notwendige Firewall-Anpassung per Knopfdruck vorgenommen werden kann. Auch interessant kann die Konfiguration der Regelzusammenführung sein. Dabei werden Regeln (Firewall- und Verbindungssicherheitsregeln), die ein lokaler Administrator erstellt hat, mit denjenigen, die mit Gruppenrichtlinien verteilt werden, zusammengeführt, sodass eine Kombination der beiden Regelkonfigurationen erfolgt. Mithilfe von Gruppenrichtlinien (und nur damit) kann dieses Verhalten der Windows-Firewall konfiguriert werden. Zum Abschluss können noch verschiedene Einstellungen zum Bereich IPsec vorgenommen werden, die sich auf den Betrieb auswirken. Bei IPsec handelt es sich um ein Framework, das genutzt wird, um IP-Verbindungen zu sichern. Dazu wird der IP-Header entsprechend erweitert, um die gewünschten Ziele zu erreichen. IPsec ist komplex, trotzdem möchte ich es nicht unterlassen, Sie mit den wichtigsten Informationen auszurüsten und die Kernkomponenten zu beleuchten. Grundsätzlich unterstützt IPsec zwei generelle Betriebsmodi: Authentication Header (AH) und Encapsulated Secure Payload (ESP).

193

6 Sicherer Netzwerkbetrieb

Abbildung 6.25 Windows-Firewall-Eigenschaften, Teil 2

Modus

Beschreibung

Authentication Header (AH)

Dieser Modus stellt die gegenseitige Authentifizierung und die Datenintegri-

Encapsulated Secure Payload (ESP)

Dieser Modus stellt die gegenseitige Authentifizierung, die Datenintegrität

tät sicher.

und die Datenvertraulichkeit (Verschlüsselung) sicher.

Je nach Anforderungen können Sie sich für einen der beiden Modi entscheiden. Wird der AH-Modus eingesetzt, wird lediglich sichergestellt, dass die richtigen Geräte miteinander kommunizieren (Authentizität) und dass die Daten während der Übertragung nicht verändert worden sind (Datenintegrität). Wird der ESP-Modus genutzt, werden zusätzlich alle Datenpakete verschlüsselt. Diese Methode ist sicherer, benötigt aber auch deutlich mehr Rechnerleistung und macht die Kommunikation daher langsamer. Für die beiden Bereiche werden unterschiedliche Algorithmen verwendet, die wiederum frei gewählt werden können.

194

6.2 Die Windows-Firewall Bereich Datenintegrität

Beschreibung SHA-1, Schlüssellänge 160 Bit MD5, Schlüssellänge 128 Bit

Datenverschlüsselung

DES, Verschlüsselung mit 56 Bit 3DES, Verschlüsselung mit 3 x 56 Bit AES, Verschlüsselung mit 128 Bit, 192 Bit oder 256 Bit

Wie bei allen Verschlüsselungsmethoden ist die Herausforderung auch bei IPsec nicht die Verschlüsselung selbst, sondern der Schlüsseltausch zwischen den beiden Partnern. Da diese Geräte möglicherweise nicht vom gleichen Betreiber verwaltet werden, gibt es keine Möglichkeit, Informationen über Schlüssel auszutauschen, bevor eine Kommunikation stattfindet. Bei IPsec ist für diese Aufgabe IKE (Internet Key Exchange) zuständig, das auf dem Diffie-Hellman-Standard aufbaut. In einer ersten Phase, dem sog. „Main Mode“ (Hauptmodus), müssen sich die Endgeräte auf eine Authentifizierungs- und Verschlüsselungsmethode einigen, die von beiden Geräten unterstützt wird. Dasjenige Gerät, das eine Verbindung aufbaut, sendet daher Vorschläge an den jeweiligen Partner und meldet, welche Methoden es selber unterstützt. Das Zielgerät antwortet wiederum mit der sichersten Übereinstimmung, also derjenigen Methode, die es ebenfalls unterstützt. Ergibt sich keine Übereinstimmung, kann IPsec nicht genutzt werden. Nach Erhalt der entsprechenden Antwort generieren beide Parteien einen Schlüsselteil, aus dem später mit einem komplexen Verfahren der effektive Schlüssel generiert wird. Erst jetzt findet die gegenseitige Authentifizierung mit einer der folgenden Methoden statt: Authentifizierung

Beschreibung

Kerberos V5

Befinden sich beide Endgeräte in der gleichen oder einer vertrauenswürdigen Domäne (innerhalb des gleichen Forests), kann Kerberos als Authentifizierungsmethode genutzt werden. Da Benutzer wie auch Geräte beim Start eines Rechners bzw. bei der Anmeldung authentifiziert werden, sind die beiden Partner gegenüber einander als vertrauenswürdig einzustufen.

NTLMv2

Mit dieser Methode können Computer der gleichen oder einer vertrauenswürdigen Domäne authentifiziert werden. Anders als bei Kerberos kann NTLMv2 auch zwischen vertrauenswürdigen Domänen unterschiedlicher Forests genutzt werden.

Digitale Zertifikate

Beide Endgeräte benötigen ein IPsec-taugliches Zertifikat, dessen Aussteller für beide Parteien als vertraulich eingestuft ist. Diese Variante ist sehr sicher, bringt allerdings auch einen weitaus größeren Aufwand für die Implementierung mit sich.

195

6 Sicherer Netzwerkbetrieb Authentifizierung

Beschreibung

Vorinstallierte Schlüssel (PSK)

Wenn keine Zertifikate genutzt werden können oder sollen, können vorinstallierte Schlüssel eingesetzt werden. Hierbei ist es notwendig, dass beide Partner den gleichen Schlüssel verwenden.

Nach erfolgreicher Authentifizierung der beiden Geräte folgt die zweite Phase, der sog. „Quick Mode“ (Schnellmodus). Dabei wird der Schlüssel neu ausgehandelt und die Datenintegrität bzw. die Verschlüsselung (je nach Modus) verwendet. So, nach diesem kleinen Abschweifer wenden wir uns wieder der erweiterten Konfiguration der Windows-Firewall zu. Wie bereits erwähnt lässt sich IPsec direkt über die FirewallVerwaltung konfigurieren, und dazu stehen einige generelle Einstellungsmöglichkeiten zur Verfügung:

Abbildung 6.26 Windows-Firewall-Eigenschaften, Teil 3

Die für die beiden Phasen eingesetzten Algorithmen können über die erweiterten Einstellungen angegeben und priorisiert werden. Sie sollten diese allerdings nur dann ändern, wenn Sie die benötigte Konfiguration genau kennen. Ansonsten laufen Sie Gefahr, dass Sie eine Konfiguration wählen, die für den vorgesehenen Bereich nicht brauchbar ist. Seien Sie also vorsichtig bei der manuellen Konfiguration von IPsec.

196

6.2 Die Windows-Firewall

Abbildung 6.27 Algorithmen für den Hauptmodus festlegen (Phase 1)

Abbildung 6.28 Algorithmen für den Schnellmodus festlegen (Phase 2)

197

6 Sicherer Netzwerkbetrieb Bei beiden Modi ist ein Wert für die Schlüsselgültigkeitsdauer konfigurierbar. Mit diesem Wert kann angegeben werden, wie lange ein Schlüssel für die gesicherte Kommunikation verwendet wird. Ist die angegebene Zeit verstrichen oder das festgelegte Datenvolumen erreicht, wird zwischen den beiden Partnern ein neuer Schlüssel ausgehandelt. Dies erhöht die Sicherheit massiv, da ein Angreifer für den Eingriff in die gesamte Kommunikation mehrere Schlüssel knacken müsste. Die eingesetzten Authentifizierungsmethoden können über die erweiterten Einstellungen in einer beliebigen Kombination zur Verfügung gestellt und priorisiert werden. Wie bei der Datenintegrität und -verschlüsselung auch muss zwischen zwei Geräten mindestens eine Übereinstimmung getroffen werden, damit die Authentifizierung erfolgreich ist.

Abbildung 6.29 Authentifizierungsmethoden festlegen

Nachdem nun alle allgemeinen Einstellungen vorgenommen worden sind, geht es an die Detailkonfiguration. Eingehende Regeln Wie der Name bereits vermuten lässt, lassen sich in diesem Bereich Regeln für eingehende Verbindungen konfigurieren. Wenn über die allgemeinen Einstellungen grundsätzliche alle eingehenden Verbindungen blockiert werden (was natürlich Sinn macht), können hier zusätzliche Regeln konfiguriert werden, welche die Kommunikation mit bestimmten Anwendungen oder Diensten auf dem lokalen Gerät zulassen. Einige Regeln werden bereits von

198

6.2 Die Windows-Firewall Windows Vista mitgeliefert, andere Regeln werden bei Anwendungsinstallationen automatisch hinzugefügt, um deren korrekten Betrieb zu gewährleisten. Es ist jederzeit möglich, Regeln zu löschen oder zu deaktivieren und natürlich bei Bedarf manuell neue Regeln zu erfassen. Je nach verbundenem Netzwerkprofil (Domäne, Privat oder öffentlich) werden diese Regeln automatisch aktiv und ermöglichen die Kommunikation mit den angegebenen Anwendungen oder Diensten. Regeln können aber auch genutzt werden, um Verbindungen explizit zu blockieren. Normalerweise haben diese Regeln Vorrang vor Regeln, die Verbindungen zulassen. Es gibt allerdings eine Ausnahme. Wenn auf einer Zulassungsregel die IPsec-Option „Regeln zum Blocken außer Kraft setzen“ markiert ist, hat diese Regel Vorrang vor sämtlichen Verweigerungsregeln, welche die Verbindung blockieren könnten (wird gleich näher erklärt).

Abbildung 6.30 Neue Regel für eingehenden Zugriff einrichten, Teil 1

Option

Beschreibung

Programm

Wenn Sie den Zugriff auf ein bestimmtes Programm ermöglichen oder blockieren möchten, wählen Sie diese Option. Anschließend kann angegeben werden, ob der Zugriff auf alle Programme oder ein einzelnes spezifisches Programm zugelassen bzw. blockiert werden soll.

Port

Portdefinitionen können mit dieser Option mitgegeben werden. Sie benötigen dazu die exakte Kommunikationsweise einer Anwendung und müssen das verwendete Protokoll (TCP, UDP) und den genutzten Port angeben.

199

6 Sicherer Netzwerkbetrieb Option

Beschreibung

Vordefiniert

Unter diesem Menüpunkt stehen verschiedene vordefinierte Protokolldefinitionen zur Auswahl. Die Konfiguration wird daher stark vereinfacht, als dass die Definitionen bereits die notwendigen Ports und andere Einstellungen enthalten.

Benutzerdefiniert

Über diese Option stehen alle Optionen uneingeschränkt zur Verfügung. Sie ist daher nur für erfahrene Administratoren geeignet.

Abbildung 6.31 Neue Regel für eingehenden Zugriff einrichten, Teil 2

Option

Beschreibung

Verbindung zulassen

Soll die Verbindung zugelassen werden, muss diese Option gewählt werden.

Verbindung zulassen, wenn sie sicher ist

Wenn die Verbindung zugelassen, aber zwingend mit IPsec geschützt werden soll, muss diese Option gewählt werden. Hierbei besteht noch die Möglichkeit festzulegen, ob auch die Datenverschlüsselung mit IPsec zwingend oder ob lediglich Authentizität und Datenintegrität notwendig sind.

200

Verbindung blockieren

Diese Option verweigert die konfigurierte Verbindung.

Nur Verbindungen von diesen Computern zulassen

Diese Option kann verwendet werden, um eine Regel nur für bestimmte

Nur Verbindungen von diesen Benutzern zulassen

Diese Option kann verwendet werden, um eine Regel nur für bestimmte

Quellen (Computern) zu aktivieren.

Benutzer zu aktivieren.

6.2 Die Windows-Firewall

Abbildung 6.32 Neue Regel für eingehenden Zugriff einrichten, Teil 3

Abschließend wird noch festgelegt, für welche Profile die neue Regel aktiv werden soll. Danach wird die Regel im Regelwerk aufgenommen und ist aktiv. Beim gezeigten Beispiel handelt es sich um eine Portregel. Wenn benutzerdefinierte Regeln verwendet werden, können zusätzliche Einstellungen vorgenommen werden, beispielsweise die verwendeten Quellports oder die lokale IP-Adresse, auf die ein Verbindungsaufbau erfolgen muss. Ausgehende Regeln Wie bei eingehenden Regeln können auch für ausgehende Verbindungen Regeln erstellt werden, die Verbindungen explizit zulassen oder verweigern. Die Konfigurationsmöglichkeiten sind dabei praktisch identisch zu den eben behandelten eingehenden Regeln. Verbindungssicherheitsregeln Wenn IPsec zur erweiterten Absicherung von Verbindungen genutzt werden soll, müssen in diesem Bereich die entsprechenden Regeln konfiguriert werden. Das lokale Gerät muss wissen, zu welchen anderen Geräten IPsec-basierte Verbindungen aufgebaut werden müssen, und dieses Wissen wird ihm in Form von Verbindungssicherheitsregeln mitgegeben. Ohne diese Regeln wird auch kein IPsec genutzt, was sich wiederum auf Regeln für einund ausgehende Verbindungen auswirken kann, falls diese IPsec voraussetzen. Wichtig ist, dass beide Endgeräte, die Daten mit IPsec sichern möchten, für IPsec konfiguriert sind. Wenn nur ein Gerät über eine IPsec-Richtlinie verfügt, kann die erweiterte Si-

201

6 Sicherer Netzwerkbetrieb cherheit nicht genutzt werden. Um eine neue Verbindungssicherheitsregel einzurichten, stehen verschiedene Typen zur Verfügung, die vom Assistenten zur Verfügung gestellt werden.

Abbildung 6.33 Neue Verbindungssicherheitsregel, Teil 1

Option

Beschreibung

Isolierung

Falls Sie das Konzept „Domain Isolation“ umsetzen möchten, benötigen Sie diesen Regeltyp, um beispielsweise sicherzustellen, dass alle Geräte der eigenen Firma IPsec für die gegenseitige Authentifizierung und die Sicherstellung der Datenintegrität konfiguriert werden. Für die Kommunikation mit „fremden“ Geräten, also Geräten, die nicht zum eigenen Active DirectoryForest gehören, wird IPsec nicht genutzt.

Authentifizierungsausnahme

Mithilfe dieses Regeltyps können Geräte definiert werden, mit denen die

Server-zu-Server

Wenn IPsec zwischen zwei Servern oder IP-Segmenten eingerichtet werden

Kommunikation ohne IPsec erfolgen soll.

soll, kommt dieser Regeltyp zum Einsatz. Die IP-Adressen für die Definition der Rechner, zu denen eine IPsec-Verbindung aufgebaut werden soll, können frei vergeben werden. Tunnel

Dieser Regeltyp erstellt einen IPsec-Tunnel zwischen zwei Endgeräten, über den alle gesendeten Daten gesichert werden. Tunnels werden beispielsweise bei Router-zu-Router-Verindungen über das Internet eingesetzt, um sicherzustellen, dass der gesamte übertragene Datenverkehr geschützt wird.

202

6.2 Die Windows-Firewall Die jeweiligen Endgeräte benötigen in diesem Szenario keine IPsecKonfiguration. Benutzerdefiniert

Mit der benutzerdefinierten Konfiguration lassen sich alle erdenklichen Szenarien festlegen, weil alle Funktionen von allen Assistenten zur Verfügung stehen.

Die Endpunkte können manuell oder mithilfe von vorkonfigurierten Computersätzen konfiguriert werden.

Abbildung 6.34 Neue Verbindungssicherheitsregel, Teil 2

Option

Beschreibung

Authentifizierung für eingehende und ausgehende Verbindungen anfordern

Wird diese Option gewählt, versucht das lokale Gerät, ein- und ausgehende Verbindungen mithilfe von IPsec zu behandeln. Ist das nicht möglich, beispielsweise weil der Kommunikationspartner kein IPsec unterstützt oder keine Übereinstimmung der Methoden gefunden worden ist, wird die Kommunikation ohne IPsec realisiert.

Authentifizierung ist für eingehende Verbindungen erforderlich und muss für ausgehende Verbindungen angefordert werden

Diese Option zwingt das lokale Gerät, bei allen eingehenden Verbindungen eine IPsec-Kommunikation zu fordern. Wenn der Kommunikationspartner dies nicht unterstützt oder keine Übereinstimmung gefunden werden kann, wird die Kommunikation abgebrochen. IPsec ist also zwingend.

203

6 Sicherer Netzwerkbetrieb Für ausgehende Anfragen wird zuerst versucht, IPsec zu nutzen. Falls das nicht möglich ist, wird ohne IPsec kommuniziert. Authentifizierung ist für eingehende und ausgehende Verbindungen erforderlich

Wenn IPsec sowohl für ein- als auch für ausgehende Verbindun-

Nicht authentifizieren

Die angegebenen Verbindungen werden bei dieser Option nicht

gen zwingend sein soll, muss diese Option verwendet werden.

authentifiziert.

Für die gegenseitige Authentifizierung können die bereits erwähnten Methoden in Kombination eingesetzt werden. Alle zur Verfügung gestellten Methoden werden verwendet, um mit dem jeweiligen Partner die definitive Methode auszuhandeln. Zum Abschluss muss wiederum angegeben werden, für welche der drei Profile die Verbindungssicherheitsregel aktiviert und welche Bezeichnung verwendet werden soll, um die Regel später zu identifizieren. Überwachung In diesem Bereich haben Administratoren die Möglichkeit, den Betrieb der Windows Firewall zu überwachen. Speziell wenn Probleme bei der Kommunikation auftreten, können die hier zur Verfügung gestellten Informationen helfen, um dem Problem auf die Schliche zu kommen. Exportieren, Importieren und Wiederherstellen Firewall-Einstellungen können recht komplex sein, und man kann leicht die Übersicht verlieren. Deshalb sollten Sie sicherheitshalber vor oder nach jeder Konfigurationsänderung eine Sicherung der aktuellen Firewall-Konfiguration durchführen. Bei einer fehlerhaften Konfiguration können Sie so sehr schnell wieder auf einen funktionierenden Stand zugreifen. Die Export-Funktion eignet sich aber auch, um bereits vorgenommene FirewallEinstellungen auf andere Rechner oder in eine Gruppenrichtlinie (später erklärt) zu übertragen. Auf dem jeweiligen Zielobjekt muss lediglich ein Import initiiert werden, und schon stehen alle Konfigurationen zur Verfügung, die möglicherweise aber noch leichte Anpassungen benötigen. Falls alle Stricke reiße,n können Sie die Wiederherstellungsfunktion nutzen, um die Firewall-Konfiguration wieder auf den Standard zurückzustellen, der nach einer Neuinstallation von Windows Vista verwendet wird.

204

6.3 IPsec ohne Firewall

6.2.4

Firewall-Konfiguration mithilfe von Gruppenrichtlinien

Natürlich lässt sich die Windows Vista-Firewall im Firmenumfeld zentralisiert mithilfe von Gruppenrichtlinien konfigurieren. Über den Bereich Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Windows-Firewall mit erweiterter Sicherheit lassen sich genau die gleichen Konfigurationen vornehmen wie auch lokal. Wenn bereits eine Konfiguration auf einem lokalen Gerät durchgeführt worden ist, kann diese – wie bereits erwähnt – exportiert und in die Gruppenrichtlinie importiert werden.

Abbildung 6.35 Firewall-Konfiguration über eine Gruppenrichtlinie

6.3

IPsec ohne Firewall IPsec kann auch außerhalb der Windows-Firewall konfiguriert werden, wodurch erfahrene Administratoren noch mehr Möglichkeiten haben, IPsec zu konfigurieren. Dazu stellt Microsoft die MMC-Snap-Ins „IP-Sicherheitsrichtlinienverwaltung“ und „IP-Sicherheitsmonitor“ zur Verfügung, die für die Einrichtung und die Überwachung verwendet werden können.

205

6 Sicherer Netzwerkbetrieb In dieser Konsole wird IPsec in Form von Sicherheitsrichtlinien implementiert, von denen jedes Gerät genau eine besitzen kann. Im ersten Schritt muss daher eine neue Richtlinie erstellt und mit Inhalten aufgefüllt werden. Nach der Zuweisung einer aussagekräftigen Bezeichnung kann angegeben werden, ob die Standardantwortregel aktiviert werden soll, was unter Windows Vista allerdings nicht notwendig ist. Im nächsten Schritt werden Sicherheitsregeln in der Richtlinie erfasst, über die festgelegt wird, welche Verbindungen wie genau mit IPsec behandelt werden sollen. Dabei kann eine IP-Sicherheitsrichtlinie beliebig viele IP-Sicherheitsregeln beinhalten, um IPsec möglichst granular konfigurieren zu können.

Abbildung 6.36 IPsec-Konfiguration mit der IP-Sicherheitsrichtlinienkonsole

Wenn eine neue IP-Sicherheitsregel hinzugefügt wird, muss im ersten Schritt festgelegt werden, ob IPsec im Transport- oder im Tunnelmodus genutzt werden soll. Wie bereits erwähnt, handelt es sich beim Tunnelmodus meistens um eine Verbindung zwischen zwei Routern, die Daten (im Auftrag anderer Geräte) untereinander austauschen, die mit IPsec geschützt werden sollen. Die jeweiligen Endgeräte benötigen keine IPsec-Konfiguration und auch keine Kenntnisse darüber, dass die Pakete für die Übertragung über eine bestimmte Route verschlüsselt werden. Beim Transportmodus hingegen müssen beide Kommunikationspartner über eine IPsec-Richtlinie verfügen, weil die selber zuständig für die Sicherung des Datentransports sind. Neben dem Modus lässt sich auch festlegen, für welche Verbindungsarten IPsec genutzt werden soll.

206

6.3 IPsec ohne Firewall

Abbildung 6.37 Neue IP-Sicherheitsregel erstellen, Teil 1

Welche Verbindungen genau mit IPsec behandelt werden sollen, wird mit IP-Filterlisten angegeben. Der IPsec-Treiber vergleicht alle ein- und ausgehenden Datenpakete mit diesen Listen und stellt sicher, dass diese Pakete mit der gleich anschließend zu konfigurierenden Filteraktion behandelt werden. Für die Erstellung der IP-Filterlisten können Quell- und Zieladressen sowie Protokolle und Ports angegeben werden.

Abbildung 6.38 Neue IP-Sicherheitsregel erstellen, Teil 2 (IP-Filterliste)

207

6 Sicherer Netzwerkbetrieb

Abbildung 6.39 Neue IP-Sicherheitsregel erstellen, Teil 3 (IP-Filterliste)

Mithilfe einer Filteraktion wird schlussendlich angegeben, wie IPsec für die jeweiligen Datenpakete eingesetzt werden soll. Die Filteraktion legt fest, ob IPsec im AH- oder ESPModus eingesetzt werden soll und welche Algorithmen für die Sicherung eingesetzt werden. Die gewünschten Kombinationen können (ähnlich wie bei der Konfiguration über die erweiterte Firewall-Verwaltung) detailliert angegeben werden. Administratoren müssen zudem festlegen, ob mit Geräten, die kein IPsec unterstützen, trotzdem kommuniziert werden darf oder nicht und mit welcher Methode die gegenseitige Authentifizierung realisiert werden soll.

208

6.3 IPsec ohne Firewall

Abbildung 6.40 Neue IP-Sicherheitsregel erstellen, Teil 4 (Filteraktion)

Abbildung 6.41 Neue IP-Sicherheitsregel erstellen, Teil 5 (Authentifizierung)

209

6 Sicherer Netzwerkbetrieb Wenn die IP-Sicherheitsrichtlinie erstellt ist, muss diese lediglich noch zugewiesen werden, erst ab diesem Zeitpunkt haben die vorgenommenen Konfigurationen dann auch tatsächlich Gültigkeit. Ob IPsec nun tatsächlich im Hintergrund für die konfigurierten Verbindungen aktiv ist, lässt sich mithilfe des IP-Sicherheitsmonitors überprüfen. Hier sind Statistiken über den IPsec-Betrieb oder die aktiven Sicherheitszuordnungen sichtbar.

Abbildung 6.42 Neue IP-Sicherheitsregel erstellen, Teil 6 (aktivieren und testen)

6.3.1

IPsec-Konfiguration über Gruppenrichtlinien

Wenn IPsec-Konfigurationen an eine Reihe von Rechnern der eigenen Firma (möglicherweise auch an alle) verteilt werden sollen, kann dies mithilfe von Gruppenrichtlinien erfolgen. Im Bereich Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\IP-Sicherheitsrichtlinien können (genau wie im vorherigen Beispiel gezeigt) IPSicherheitsrichtlinien erstellt und zugewiesen werden.

210

6.4 Rückblick

6.4

Rückblick Der sichere Netzwerkbetrieb ist eine große Herausforderung für Administratoren, besonders deshalb, weil sehr viele unterschiedliche Möglichkeiten zur Verfügung stehen, sich mit Netzwerken zu verbinden. Jede Verbindungsart hat ihre Eigenheiten, und jede bedarf besonderer Schutzmechanismen, damit ein System in einem Netzwerk optimal geschützt ist. Die Windows-Firewall kann und sollte eingesetzt werden, um alle diese Netzwerkverbindungstypen zu schützen. Ein restriktiver Einsatz der Firewall sichert ein Gerät nicht nur in fremden Netzwerken, sondern auch in der firmeninternen Umgebung und kann helfen, gezielte Angriffe oder Verbreitungen von Trojanern zu verhindern. Bestehen Anforderungen, um die Netzwerkkommunikation zu sichern, stellt Windows Vista IPsec zur Verfügung, das einerseits direkt über die erweiterte Firewall-Konsole oder über eine dedizierte IPsec-Konsole verwaltet werden kann – je nach Anforderungen. Die gezeigten Sicherheitsfunktionen im Netzwerkbereich gekoppelt mit anderen Schutzmechanismen von Windows Vista ergeben ein (hoffentlich nahezu) vollständiges Sicherheitsdispositiv, mit dem Sie und Ihre Anwender mit gutem Gefühl in die Welt der ITNetzwerke abtauchen können.

211

7 Erweiterter Schutz vor Malware  Viren In früheren Kapiteln haben wir uns bereits einige Technologien angesehen, mit denen ein mit Windows Vista betriebenes Gerät vor Malware geschützt werden kann – beispielsweise die Benutzerkontensteuerung oder die neu verfügbaren Verbindungsstufen. Das alleine reicht aber noch nicht für einen vollständigen Schutz aus, dazu werden weitere Mechanismen benötigt. Einerseits muss eine Möglichkeit bestehen, Malware, die installiert werden soll bzw. bereits installiert ist, zu erkennen. Das kann dann der Fall sein, wenn ein Benutzer eine falsche Entscheidung trifft und gezielt ein entsprechendes Programm aus dem Internet herunterlädt und installieren will. Der im Betriebssystem integrierte Windows Defender erkennt solche Programme frühzeitig und kann diese sofort blockieren oder unter Quarantäne nehmen. Ein ähnliches Problem tritt im Bereich Virenerkennung auf. E-Mail ist in der heutigen Geschäftswelt nicht mehr wegzudenken, und obwohl Mailadministratoren die Möglichkeit haben, Mails, die Viren oder Trojaner enthalten, schon am Gateway zu erkennen und zu blockieren, bleibt ein Restrisiko, dass eine solche Mail im Posteingang eines Benutzers landet. Beim Öffnen eines virenverseuchten Anhangs muss ein Mechanismus erkennen, ob eine Datei „sauber“ ist oder nicht und den Zugriff darauf bei Bedarf blockieren. In diesem Kapitel möchte ich auf diese beiden Thematiken näher eingehen und Ihnen zeigen, wie Mirosoft und Windows Vista Ihnen zu einem optimalen Schutz gegen solche unangenehmen Machenschaften verhelfen. Windows Defender Mit dem Windows Defender wird erstmals in der Microsoft-Geschichte eine AntiSpyware-Lösung direkt mit dem Betriebssystem ausgeliefert. Microsoft hat diese Technologie vor ein paar Jahren eingekauft, weiterentwickelt und zum freien Download zur Verfügung gestellt (für frühere Betriebssystemversionen). Windows Vista genießt nun „out – of –the box“ einen umfangreichen Schutz gegen Spyware und andere unerwünschte Programme. Dazu wird der Windows Defender bei jedem Start von Windows Vista automa-

213

7 Erweiterter Schutz vor Malware und Viren tisch gestartet, und das Betriebssystem und die gespeicherten Daten werden optimal geschützt. Was aber bringt dieses Tool, und wovor bietet es tatsächlich Schutz? Es gibt eine ganze Reihe von unerwünschten Programmen (Trojaner, Malware usw.), die in den letzten Jahren aufgekommen sind und versuchen, Informationen von Benutzern zu stehlen oder diese zu manipulieren. Es gibt aber auch Programme, die danach trachten, Daten gezielt zu zerstören, die Leistung von Rechnern zu beeinträchtigen oder diese komplett unbrauchbar zu machen. Im Firmenumfeld können solche Szenarien katastrophale Auswirkungen haben: Benutzer werden blockiert und können ihren Aufgaben nicht mehr nachgehen, Aufträge können möglicherweise nicht mehr bearbeitet werden, wodurch Kunden unzufrieden werden usw. Diese Liste ist endlos lang und kann für eine Firma finanzielle Einbußen und einen großen Image-Schaden bedeuten. Um Firmen vor solchen Szenarien zu schützen, setzt der Windows Defender genau hier an. Mit einer Reihe von Sicherheitsmechanismen bietet er umfangreichen Schutz gegen die erwähnten Programme und Angriffe, kann diese frühzeitig erkennen und blockieren. Dazu verwendet er verschiedene Mechanismen, um umfangreichen Schutz zu garantieren. Dazu gehören folgende: Automatische Updates Echtzeitschutz zum Erkennen neuer, unerwünschter Programme Manuelle Scans zum Suchern nach bereits installierten, unerwünschten Programmen Quarantänefunktion zum Verwalten von Programmen Anschluss an das Netzwerk „Microsoft SpyNet“ Der Windows Defender wird bei jedem Start von Windows Vista automatisch gestartet und schützt somit das System automatisch vor den erwähnten Angriffen. Über verschiedene Einstellungsmöglichkeiten kann das Verhalten des Defenders manuell oder mithilfe von Gruppenrichtlinien den Firmenbedürfnissen angepasst werden. Windows Defender schützt Geräte vor unerwünschten Programmen wie beispielsweise Malware, nicht aber vor bestimmten Virenarten, wie oft fälschlicherweise angenommen wird. Dazu sind zusätzliche Programme notwendig, die später in diesem Kapitel erläutert werden.

Windows Defender kann suspekte Programme auf eine Vielzahl von Arten aufspüren, beispielsweise durch den integrierten Echtzeitschutz oder durch manuell gestartete Scans. Wird ein solches Programm entdeckt, weist Windows Defender dieses Programm einer der folgenden Warnstufen zu:

214

7.1 Automatische Updates Warnstufe

Beschreibung

Schwerwiegend

Programme dieser Warnstufe gelten als besonders aggressiv oder gefährlich und sind weit verbreitet. Oft handelt es sich dabei um Trojaner, Würmer oder Werkzeuge für das Ausspionieren von Benutzern. Solche Programme sollten unverzüglich vom System entfernt werden.

Hoch

Diese Warnstufe wird verwendet, um Programme zu klassifizieren, die Informationen vom Benutzer wie beispielsweise Daten oder Verhaltensmuster sammeln, den Computer aber auch böswillig zerstören können. Programme dieser Warnstufe sollten daher unverzüglich deinstalliert werden.

Mittel

Programme, die unbemerkt Änderungen an der Konfiguration des Rechners oder an Daten vornehmen können, werden dieser Stufe zugeordnet. Prüfen Sie, ob diese Programme tatsächlich benötigt werden. In den meisten Fällen müssten diese allerdings deinstalliert werden können.

Niedrig

Bei Programmen dieser Stufe handelt es sich um bekannte, aber nicht sonderlich gefährliche Anwendungen. Prüfen Sie, ob diese tatsächlich benötigt werden. Ist dies nicht der Fall, können sie deinstalliert werden.

Noch nicht klassifiziert

Diese Programme enthalten keine Klassifizierung und sind deshalb (normalerweise) sicher. Es könnte aber auch sein, das es sich um ein noch nicht in der Windows Defender-Definitionsdatei enthaltenes, schädliches Programm handelt. Prüfen Sie daher genau, um welches Programm es sich handelt und ob Sie es (oder ein Systemadministrator) installiert haben.

Sie sehen, dass sich die einzelnen Warnstufen teilweise überschneiden, wodurch eine Zuordnung von Programmen recht schwierig wird. Daher kann es sehr gut möglich sein, dass Programme einer Stufe zugeordnet werden, die Programmbeschreibung aber nicht eindeutig mit derjenigen in der Tabelle übereinstimmt. Sie sollten in jedem Fall bei allen klassifizierten Programmen prüfen, ob diese beabsichtigt auf einem Rechner installiert worden sind und ob diese effektiv benötigt werden oder nicht. Wird ein Programm als Malware, Spyware o.Ä. identifiziert, muss der Anwender entscheiden, welche Aktion Windows Defender dafür ausführen soll. Je nach Art der Erkennung stehen unterschiedliche Möglichkeiten zur Verfügung – teilweise abhängig davon, ob ein Programm bereits auf dem lokalen System vorhanden bzw. installiert ist oder eine Webseite versucht, schädlichen Code zur Änderung einer Browserkonfiguration vorzunehmen. Im Folgenden werden die unterschiedlichen Interaktionen, die einem Benutzer zur Verfügung stehen, gezeigt.

215

7 Erweiterter Schutz vor Malware und Viren

Abbildung 7.1 Windows Defender-Warnung, Variante 1

Abbildung 7.2 Windows Defender-Warnung, Variante 2

216

7.1 Automatische Updates Aktion

Beschreibung

Entfernen bzw. Alle entfernen

Die Software wird vollständig vom Rechner gelöscht.

Quarantäne

Die Software wird in einen Quarantäne-Ordner verschoben und kann ab diesem Zeitpunkt nicht mehr ausgeführt werden. Sie kann allerdings zu einem späteren Zeitpunkt wieder aus der Quarantäne entfernt und danach wieder ausgeführt werden.

Ignorieren

Diese Option unternimmt keinerlei Aktion mit dem gefundenen Programm. Bei einer erneuten Überprüfung wird das Programm wieder erkannt und der Benutzer zu einer Aktion aufgefordert.

Immer zulassen

Wenn ein Programm fälschlicherweise als unerwünschtes Programm erkannt wird, kann es mit dieser Aktion einer Liste von zugelassenen Elementen hinzugefügt werden. Bei späteren Überprüfungen wird es daher nicht mehr angezeigt.

Objekte, die sich in der Quarantäne befinden, können über die Quarantäneverwaltung zu einem späteren Zeitpunkt gelöscht oder wieder aktiviert werden. Dazu später aber mehr.

7.1

Automatische Updates Wie ein Virenscanner auch, muss Windows Defender regelmäßig aktualisiert werden, um die lokale Datenbank mit neuen Mustern aufzufüllen. Dieser Prozess ist entscheidend und sollte regelmäßig und automatisch erfolgen, weil nur so sichergestellt werden kann, dass neue schädliche Programme auch erkannt und blockiert werden können. Ein nicht aktualisierter Windows Defender ist deshalb nicht viel besser als gar keiner. Windows Defender kann deshalb auf verschiedene Arten aktualisiert werden: Direkt aus dem Programm (manuell oder automatisch vor einem Scan des Geräts) Über Windows Update Über die Microsoft Windows Server Update Services (WSUS) Über andere Methoden (SCE 2007, SCCM 2007) oder Produkte von Drittherstellern Beim Start des Windows Defenders ist jeweils sofort ersichtlich, ob dieser über die aktuellsten Definitionsdateien verfügt, welche Definitionsversion genutzt wird und wann diese installiert worden ist. Ist die Definitionsdatei veraltet, kann die neuste Version per Klick auf die Schaltfläche „Jetzt nach Updates suchen“ heruntergeladen und aktualisiert werden. Ebenfalls sofort ersichtlich ist, wann die letzte Prüfung stattgefunden hat, wie die regelmäßige, automatische Überprüfung konfiguriert und ob der Echtzeitschutz aktiv ist.

217

7 Erweiterter Schutz vor Malware und Viren

Abbildung 7.3 Starten des Windows Defenders

7.2

Echtzeitschutz zum Erkennen neuer unerwünschter Programme Wie der Name schon vermuten lässt, schützt der Echtzeitschutz des Windows Defenders ein System in Echtzeit. Das bedeutet, dass verschiedene Bereiche permanent überwacht werden, sodass die Speicherung eines suspekten Programms oder eine unerwünschte Konfigurationsänderung (beispielsweise durch Malware) entdeckt und verhindert werden kann. Windows Defender nutzt dazu verschiedene Sicherheits-Agenten, die einzeln aktiviert bzw. deaktiviert werden können. Bei Bedarf kann der Echtzeitschutz auch komplett deaktiviert werden, was aber im Normalfall nicht zu empfehlen ist. Folgende Tabelle zeigt die (derzeit) verfügbaren Sicherheits-Agenten des Windows Defenders und ihre jeweiligen Aufgaben.

Sicherheits-Agent

Beschreibung

Automatisch starten

Dieser Agent überwacht die beim Systemstart automatisch ausgeführten Programme. Möglicherweise versuchen sich Programme unbemerkt so einzurichten, dass sie beim Systemstart aufgerufen werden. Windows Defender bemerkt solche Aktionen.

218

7.3 Manuelle Scans zum Suchen nach bereits installierten Spyware-Programmen Sicherheits-Agent Systemkonfiguration gen)

Beschreibung (Einstellun-

Falls Programme versuchen, Sicherheitsänderungen an Systemdateien,

Registrierungsschlüsseln

oder

an

der

Windows-

Konfiguration vorzunehmen, wird das durch diesen Agenten erkannt. Internet Explorer-Add-Ons

Mithilfe dieses Agenten werden automatisch gestartete Add-Ons des Internet Explorers überwacht. Dadurch ist es einem Prozess nicht möglich, unbemerkt ein Add-On im Internet Explorer zu installieren und zu aktivieren.

Internet Explorer-Konfigurationen (Einstellungen)

Dieser Agent überwacht die Sicherheitseinstellungen des Browsers. Falls ein Programm versucht, unbemerkt Änderungen an dieser Konfiguration vorzunehmen, wird dies verhindert.

Internet Explorer-Downloads

Falls über den Internet Explorer suspekte ActiveX-Komponenten oder sonstige Programme heruntergeladen werden, werden solche frühzeitig blockiert, wenn dieser Agent aktiviert ist.

Dienste und Treiber

Dieser Agent überwacht den Zugriff von Diensten und Treibern auf Windows-Dateien und Anwendungen. Unbekannte Zugriffe werden erkannt und verhindert.

Anwendungsausführung

Wenn Anwendungen gestartet und ausgeführt werden, überwacht dieser Agent die entsprechenden Prozesse und prüft, ob im Anwendungskontext unbemerkt weitere Programme (beispielsweise Spyware) gestartet werden. Solche Programme werden erkannt und die Ausführung blockiert.

Anwendungsregistrierung

Dieser Agent überwacht die Registrierung von Anwendungen im Betriebssystem, auch solche, die nicht automatisch gestartet werden. Dadurch können die unbemerkte Installation und Registrierung von versteckten Programmen verhindert werden.

Windows-Add-Ons

Anwendungen, die als Windows-Add-Ons klassifiziert sind, aber bösartige Absichten haben, können mithilfe dieses Agenten erkannt und blockiert werden.

7.3

Manuelle Scans zum Suchen nach bereits installierten Spyware-Programmen Mit manuellen Scans kann das lokale System nach bereits installierten und gespeicherten Spyware-Programmen durchsucht werden. Beispielsweise könnte es sein, dass sich solche Programme eingeschlichen haben, weil Windows Defender kurzzeitig deaktiviert worden ist oder einige (oder alle) Sicherheits-Agenten des Echtzeitschutzes deaktiviert worden

219

7 Erweiterter Schutz vor Malware und Viren sind. Regelmäßige manuelle Scans helfen in diesen Situationen, solche bereits installierten Programme zu erkennen und zu entfernen. Folgende Scan-Varianten stehen zur Verfügung: Schnellüberprüfung Vollständige Überprüfung Benutzerdefinierte Überprüfung Bei der Schnellüberprüfung werden nur wichtige Bereiche des Systems gescannt, beispielsweise Bereiche der Registrierungsdatenbank, der Windows- oder der Programmordner. Der Vorteil dieser Variante liegt darin, dass eine Überprüfung verhältnismäßig schnell abgeschlossen ist, weshalb sie sich optimal als „Zwischendurch-Überprüfung“ eignet. Bei einer vollständigen Überprüfung hingegen werden alle Dateien und Objekte der lokalen Festplatte überprüft. Diese Überprüfung dauert länger, ist dafür aber gründlicher. Es kann nicht schaden, ab und zu eine vollständige Überprüfung durchzuführen, besonders dann, wenn Sie das Gefühl haben, mit unerwünschten Programmen in Kontakt gekommen zu sein. Benutzerdefinierte Überprüfungen schlussendlich lassen sich detailliert konfigurieren, sodass der Anwender genau festlegen kann, welche Bereiche überprüft werden sollen. Diese Überprüfungsart ist vorwiegend für erfahrene Anwender gedacht. Sinnvoll ist es, wenn regelmäßige Schnellüberprüfungen geplant werden, beispielsweise einmal täglich. Dadurch werden die wichtigsten Komponenten des Betriebssystems auf Spyware überprüft. In größeren Abständen macht auch die vollständige Überprüfung des Systems Sinn, beispielsweise einmal wöchentlich. Bedenken Sie allerdings, dass eine vollständige Überprüfung viel Zeit in Anspruch nehmen kann und die Leistung eines Geräts während der Zeitdauer der Überprüfung beeinträchtigt wird.

7.4

Verlauf Über die Verlaufsfunktion ist ersichtlich, wie Windows Defender in der Vergangenheit gearbeitet hat, d.h., es ist sofort ersichtlich, ob unerwünschte Programme gefunden und welche Aktionen dafür ausgewählt worden sind. Der Verlauf kann bei Bedarf jederzeit gelöscht werden, sofern der Benutzer über lokale Administratorenrechte verfügt.

220

7.5 Extras

Abbildung 7.4 Anzeige des Verlaufs im Windows Defender

7.5

Extras Der Windows Defender lässt sich detailliert konfigurieren und so den Bedürfnissen von Benutzern und Firmen anpassen. Über den Bereich Extras können verschiedene Einstellungen und erweiterte Konfigurationen vorgenommen werden.

221

7 Erweiterter Schutz vor Malware und Viren

Abbildung 7.5 Windows Defender-Extras

7.5.1

Optionen

Über diesen Bereich lassen sich grundlegende Einstellungen zum Verhalten des Windows Defenders festlegen. Die Einstellungen werden in unterschiedliche Bereiche aufgeteilt. Automatische Überprüfung In diesem Bereich lässt sich festlegen, ob und wie Windows Defender regelmäßige Überprüfungen des lokalen Systems durchführt. Als Typen stehen dazu die Schnellüberprüfung oder die vollständige Überprüfung zur Auswahl. Optimal wird die Option verwendet, die sicherstellt, dass vor einer Prüfung die neusten Definitionsdateien heruntergeladen und installiert werden, damit sichergestellt ist, dass eine Prüfung möglichst effizient und umfangreich abläuft. Wenn durch die regelmäßige Prüfung unerwünschte Programme und Elemente erkannt werden, kann angegeben werden, dass für diese eine festgelegte Standardaktion ausgeführt werden soll, sodass Benutzer nicht mehr in den Prozess eingreifen müssen.

222

7.5 Extras

Abbildung 7.6 Optionen des Windows Defenders

Standardaktionen Über diesen Bereich lässt sich festlegen, wie Windows Defender bei der Erkennung von Programmen reagieren soll. Beispielsweise kann angegeben werden, dass Programme der Stufe „Hoch“ automatisch entfernt werden sollen, was verhindern kann, dass Benutzer eine falsche Auswahl treffen können und unerwünschte Programme trotz Erkennung installiert werden. Echtzeitschutz-Optionen Wie bereits im vorherigen Abschnitt erwähnt, verfügt Windows Defender über einen Echtzeitschutz, der Programme, Elemente oder sonstige unerwünschte Änderungen an der Systemkonfiguration erkennen und blockieren kann. In diesem Bereich kann angegeben werden, welche Sicherheits-Agenten aktiv genutzt werden sollen. Normalerweise macht es Sinn, alle verfügbaren Agenten zu aktivieren, um den Echtzeitschutz optimal auszunutzen. Es ist sinnvoll, dass Benutzer informiert werden, wenn Software erkannt wird, deren Risiko noch nicht eingestuft worden ist. Ebenfalls Sinn macht es, Benutzer dann zu benachrichtigen, wenn Software, die nicht ausgeführt werden darf (später in diesem Kapitel), Än-

223

7 Erweiterter Schutz vor Malware und Viren derungen am System vornehmen will. Abschließend kann festgelegt werden, ob das Windows Defender-Symbol in der Taskleiste immer oder nur bei aktiven Aktionen angezeigt wird. Ich persönlich finde es sinnvoll, das Icon immer anzuzeigen, damit sofort ersichtlich ist, dass ein System mit Windows Defender aktiv geschützt ist – aber das ist Geschmackssache. Erweiterte Optionen Für einen vollumfänglichen Schutz des Systems sollte die Option zur Überprüfung von Archiven (z.B. Zip-Ordner) aktiviert werden, genauso wie die heuristische Suche nach Elementen, mit der noch unbekannte Programme, die in keinen Definitionsdateien enthalten sind, trotzdem erkannt werden können. Wird die Option zur Erstellung eines Wiederherstellungspunkts verwendet, könnte ein System, das durch eine Softwareentfernung Schaden genommen hat, wieder zum Laufen gebracht werden. Auch diese Option macht daher Sinn. Schlussendlich können in den erweiterten Optionen bestimmte Bereiche von der  nur  Administratoroptionen Mit den letzten Einstellungsmöglichkeiten kann der Windows Defender komplett deaktiviert werden, was Sie allerdings niemals tun sollten. Zudem lässt sich festlegen, wie Windows Defender von Benutzern mit Standardrechten genutzt werden darf.

7.5.2

Microsoft SpyNet

Mit „SpyNet“ hat Microsoft eine Community ins Leben gerufen, die beim Kampf gegen unerwünschte Programme unterstützend wirken soll. Benutzer haben optional die Möglichkeit, ihre Entscheidungen an Microsoft zu übermitteln, beispielsweise dann, wenn sie ein Programm in Quarantäne versetzen. Diese Handlung wird an Microsoft übermittelt und ausgewertet. Wenn viele andere Benutzer mit einem Programm die gleiche Aktion durchführen, kann das Programm nach intensiver Prüfung durch Microsoft in neuen Definitionsdateien als Malware, Spyware o.Ä. eingestuft werden. Benutzer helfen demnach mit, die Definitionsdateien des Windows Defenders und damit die Sicherheit von Systemen weltweit zu verbessern. Über Extras\Microsoft SpyNet lässt sich die gewünschte Mitgliedschaft festlegen, die selbstverständlich kostenlos ist.

224

7.5 Extras

Abbildung 7.7 Beitritt zum Microsoft SpyNet

Mitgliedschaft

Beschreibung

Einfaches Mitglied werden

Als einfaches Mitglied bei SpyNet werden von Ihrem Rechner Informationen über Programme, deren Quelle und durchgeführte Benutzeraktionen gesammelt und an Microsoft zur Auswertung übermittelt. Persönliche Informationen werden grundsätzlich nicht an Microsoft weitergegeben.

Als Premiummitglied beitreten

Die Premiummitgliedschaft bietet grundsätzlich die gleichen Möglichkeiten der einfachen Mitgliedschaft, allerdings werden dem Benutzer zusätzlich Warnmeldungen und Informationen zu Programmen oder Vorkommnissen angezeigt, deren Risiken von Microsoft noch nicht vollständig analysiert und in Definitionsdateien integriert worden sind. Benutzer werden dadurch mit noch mehr Informationen beim Kampf gegen unerwünschte Programme versorgt.

Microsoft SpyNet jetzt nicht beitreten

Wenn Sie keine Informationen über Ihre Entscheide an Microsoft übermitteln möchten, sollten Sie dem SpyNet nicht beitreten und diese Option wählen.

225

7 Erweiterter Schutz vor Malware und Viren

7.5.3

Unter Quarantäne

Wenn Sie nicht sicher sind, ob ein Element tatsächlich schädlich für Ihr System ist, kann es temporär in den Quarantänebereich des Windows Defenders verschoben werden. Das Programm ist somit erst einmal isoliert und kann keinen weiteren Schaden anrichten. Programme in der Quarantäne können jederzeit nachträglich definitiv gelöscht oder aber wiederhergestellt, d.h. aktiviert, werden.

Abbildung 7.8 Quarantäneverwaltung

Nach dem Markieren von Quarantäneobjekten stehen die erwähnten Möglichkeiten zur Verfügung. Zudem lassen sich bei bekannten Programmen weitere Informationen direkt online anzeigen. Damit können sich Anwender ein Bild über ein Programm machen und möglicherweise besser entscheiden, ob es vom System entfernt werden sollte oder nicht.

226

7.5 Extras

7.5.4

Software-Explorer

Der Software-Explorer gibt dem Anwender eine zentrale Übersicht über Programme und Elemente, die auf dem Computer ausgeführt werden. Beispielsweise lassen sich alle Programme anzeigen, die beim Systemstart automatisch ausgeführt werden, wozu viele Detailinformationen über Installationsort und -datum, Version oder Herausgeber angezeigt werden. Dadurch wird sofort ersichtlich, ob Programme ohne Kenntnis des Nutzers gestartet werden und möglicherweise unerwünschte Aktionen ausführen. Programme können per Knopfdruck temporär deaktiviert und zu einem späteren Zeitpunkt wieder aktiviert werden. Wenn sichergestellt ist, dass ein Programm nicht verwendet werden soll oder muss, kann es vollständig entfernt werden.

Abbildung 7.9 Der Software-Explorer

Neben automatisch gestarteten Programmen können auch alle derzeit ausgeführten Programme und Prozesse angezeigt werden. Möglicherweise werden unerwünschte Elemente erst nach dem Systemstart aktiviert und sind daher in der Ansicht der automatisch gestarteten Programme nicht sichtbar. Wenn die derzeit ausgeführten Programme angezeigt werden, steht die Möglichkeit zur Verfügung, diese direkt über die Konsole zu beenden oder den Task Manager für weitere Aktivitäten zu starten. Auch Netzwerkprogramme, die eine aktive Verbindung zu Remotesystemen hergestellt haben, können im Software-Explorer angezeigt werden. Zu allen Anwendungen werden Detailinformationen sowie die Verbindungsziele und -ports angezeigt. Mit dieser Funktion

227

7 Erweiterter Schutz vor Malware und Viren kann sehr schnell erkannt werden, ob sich unbekannte Programme auf einem Rechner mit unbekannten Zielen im Intranet oder Internet verbinden, um sich weiterzuverbreiten (z.B. bei Würmern) oder um andere Programme oder Werkzeuge herunterzuladen, um einen Angriff auszuweiten. Suspekte Verbindungen können sofort blockiert werden. Zu guter Letzt kann der Software-Explorer die verfügbaren Winsock-Dienstanbieter darstellen. die auf einem System zur Verfügung stehen. Dabei handelt es sich um Programme, die Netzwerk- oder Kommunikationsmöglichkeiten für Anwendungen bieten, um sich mit anderen Geräten zu verständigen. Wenn Sie noch detailliertere Informationen zu Programmen, die beim Betriebssystem gestartet werden, erhalten möchten, können Sie das Tool „Autoruns for Windows“ von Microsoft (ehemals Sysinternals) einsetzen. Damit erhalten Sie einen detaillierten Überblick, welche Dienste, Programme, Treiber oder DLLs beim Start von Windows Vista automatisch gestartet werden bzw. welche Module aktuell geladen sind. Das Tool bietet in diesem Bereich somit weitaus mehr Funktionalität als der Windows Defender oder das in Vista enthaltene Tool „msconfig.exe“.

7.6

Informationen in der Ereignisanzeige In der Ereignisanzeige werden Detailinformationen zum Betrieb des Windows Defenders angezeigt. Im Systemprotokoll ist beispielsweise ersichtlich, ob und wann Überprüfungen durchgeführt worden sind und ob Windows Defender schädliche, unerwünschte Programme entdeckt hat.

Abbildung 7.10 Windows Defender in der Ereignisanzeige

228

7.7 Konfiguration über Gruppenrichtlinien

7.7

Konfiguration über Gruppenrichtlinien Windows Defender lässt sich mithilfe von Gruppenrichtlinien zentral konfigurieren. Dadurch haben Administratoren von Netzwerken über einige Bereiche des Windows Defenders zentrale Verwaltungsmöglichkeiten, leider aber nicht über alle. Im Bereich Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Windows Defender einer Gruppenrichtlinie stehen verschiedene Einstellungsmöglichkeiten zur Verfügung.

Abbildung 7.11 Gruppenrichtlinieneinstellungen

Richtlinie

Beschreibung

Definitionsaktualisierungen durch WSUS und Windows Update einschalten

Mit dieser Richtlinie kann festgelegt werden, wie Windows Defender aktualisiert werden soll. Grundsätzlich verwendet Windows Defender für die Aktualisierung den Windows UpdateClient, verbindet sich also – je nachdem, wie Windows/Microsoft Update genau konfiguriert ist – mit einem firmeninternen WSUSServer oder direkt mit Microsoft Update im Internet. Was aber, wenn WSUS nicht zur Verfügung steht, beispielsweise wenn mobile Geräte längere Zeit keine Verbindung mit dem Firmennetzwerk herstellen? Dann kann diese Richtlinie verwendet werden, um Clients bei Bedarf direkt zu Microsoft Update umzuleiten und Windows Defender-Updates von dieser Quelle herunterzuladen. Standardeinstellung: Falls keine Verbindung zu WSUS (sofern konfiguriert) hergestellt werden kann, verbindet sich Windows

229

7 Erweiterter Schutz vor Malware und Viren Defender direkt mit Microsoft Update für die Aktualisierung von Definitionen. Empfohlene Einstellung: Diese Richtlinie sollte unbedingt aktiviert werden, damit Clients bei Microsoft Update die neusten Definitions-Updates herunterladen können, falls WSUS nicht (oder längere Zeit nicht) zur Verfügung steht. Vor geplanten Scanvorgängen auf neue Signaturen überprüfen

Vor geplanten Überprüfungen sollte sichergestellt werden, dass Windows Defender über die aktuellsten Signaturen verfügt. Mit dieser Richtlinie lässt sich festlegen, dass vor einer Überprüfung die neuesten Updates heruntergeladen werden. Standardeinstellung: Vor einer Überprüfung werden keine Updates heruntergeladen. Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden, um sicherzustellen, dass jede Überprüfung mit den aktuellsten Updates durchgeführt wird. Nur so kann die höchstmögliche Sicherheit für ein Gerät gewährleistet werden.

Windows Defender deaktivieren

Diese Richtlinie deaktiviert den Windows Defender, sodass keine weiteren Überprüfungen mehr durchgeführt werden. Standardeinstellung: Windows Defender wird ausgeführt. Empfohlene Einstellung: Um Betriebssysteme optimal schützen zu können, sollte Windows Defender unbedingt aktiv sein und diese Richtlinie daher nicht aktiviert werden. Wenn Firmen hingegen andere Programme für diese Funktion einsetzen, kann Windows Defender deaktiviert werden.

Anforderungen des Echtzeitschutzes für die Erkennung unbekannter Dateien deaktivieren

Falls Windows Defender unbekannte Aktivitäten auf einem Rechner entdeckt, kann mit dieser Richtlinie festgelegt werden, ob Benutzer diese bestätigen müssen oder nicht. Standardeinstellung: Benutzer erhalten Informationen, die sie bestätigen müssen, sobald Windows Defender eine unbekannte Aktivität erkennt. Empfohlene Einstellung: Diese Richtlinie sollte auf jeden Fall deaktiviert werden, sodass Benutzer immer über unbekannte Aktivitäten informiert werden und diese bestätigen müssen.

Protokollierung der Erkennungsdaten bekannter gutartiger Programme aktivieren

Mit dieser Richtlinie lässt sich angeben, ob bekannte gutartige Programme bei einer Echtzeitüberprüfung protokolliert werden sollen. Standardeinstellung: Gutartige, bekannte Programme, die bei einer Echtzeitüberprüfung erkannt werden, werden nicht protokolliert.

230

7.7 Konfiguration über Gruppenrichtlinien Empfohlene Einstellung: Diese Richtlinie muss normalerweise nicht explizit aktiviert werden, weil Informationen über gutartige Programme nicht relevant sind. Protokollierung der Erkennungsdaten unbekannter Programme aktivieren

Mit dieser Richtlinie lässt sich angeben, ob unbekannte Programme bei einer Echtzeitüberprüfung protokolliert werden sollen. Standardeinstellung: Unbekannte Programme, die bei einer Echtzeitüberprüfung erkannt werden, werden protokolliert. Empfohlene Einstellung: Diese Richtlinie sollte aktiviert werden, sodass unbekannte Programme protokolliert werden. Dies ist unter Umständen nützlich, um Programme zu identifizieren und zu einem späteren Zeitpunkt zu deinstallieren.

Gesamten Signatursatz herunterladen

Falls Probleme mit Signatur-Updates auftreten, kann Windows Defender angewiesen werden, den vollständigen Signatursatz herunterzuladen. Ansonsten werden lediglich Differenzial-Dateien heruntergeladen, um ein System zu aktualisieren. Standardeinstellung: Es werden jeweils Differenzial-Dateien heruntergeladen, nicht der gesamte Signatursatz Empfohlene Einstellung: Diese Richtlinie sollte im Normalfall deaktiviert werden, weil durch das Herunterladen des gesamten Satzes deutlich mehr Daten übertragen werden müssen als bei einer Differenzial-Datei. Falls allerdings Probleme mit den Signaturen auftreten, kann die Richtlinie aktiviert werden, um so die Probleme möglicherweise zu beheben.

Microsoft SpyNetBerichterstattung konfigurieren

Mithilfe dieser Richtlinie kann festgelegt werden, ob Windows Defender an Microsoft SpyNet angebunden werden soll und ob Benutzer diese Einstellung ändern können. Dazu stehen bei aktivierter Richtlinie die Optionen „Keine Mitgliedschaft“, „Standard“ und „Erweitert“ zur Verfügung. Standardeinstellung: Windows Defender ist nicht mit dem Microsoft SpyNet verbunden. Empfohlene Einstellung: Um vollumfänglichen Schutz zu erhalten, empfiehlt es sich, die Option „Erweitert“ zu nutzen, wodurch die Premiummitgliedschaft bei SpyNet konfiguriert wird. Falls SpyNet hingegen nicht genutzt werden soll oder darf, aktivieren Sie die Richtlinie ebenfalls, wählen aber die Option „Keine Mitgliedschaft“. Dadurch haben Benutzer keine Möglichkeit, die SpyNet-Mitgliedschaft selber zu aktivieren. Falls dies möglich sein soll, deaktivieren Sie die Richtlinie.

231

7 Erweiterter Schutz vor Malware und Viren

7.8

Rückblick Windows Defender stellt ein weiteres Glied in einer ganzen Reihe dar, um ein Windows Vista-System vor unerwünschter Malware, Spyware o.Ä. zu schützen. Die Bedienung ist verhältnismäßig einfach, die Konfiguration übersichtlich und nachvollziehbar – und trotzdem leistet der Windows Defender exzellente Dienste. Ein wichtiger Punkt muss allerdings angemerkt werden: Mit dem Windows Defender liefert Microsoft zwar eine Lösung, um Malware und andere ungewünschte Programme zu bekämpfen, ich denke aber, dass sich das Programm im professionellen Umfeld nicht buschfeuerartig ausbreiten wird, weil einige essenzielle Bereiche derzeit nicht oder nur teilweise und unter Einsatz mühsamer Mechanismen realisiert werden können. Die zentrale Verwaltung für das Produkt ist zwar vorhanden, ist allerdings mangelhaft, sodass Administratoren nicht alle Funktionen kontrollieren können. Beispielsweise existiert keine zentrale Verwaltungskonsole, um sichtbar zu machen, welche Clients veraltete Definitionsupdates verwenden. Auch zu welchen Zeitpunkten auf Geräten Scans durchgeführt worden sind und ob diese erfolgreich Programme entdeckt oder entfernt haben, ist nicht ersichtlich, genauso fehlt die Möglichkeit, erkannte Programme in einer zentralen Quarantäne zu speichern. Es bestehen zwar Möglichkeiten, um bestimmte Informationen zu konsolidieren oder zumindest konsolidiert zu überprüfen, beispielsweise mit WSUS oder der Weiterleitungsfunktion in der Ereignisanzeige, allerdings arten diese selbst konfigurierten Lösungen schnell in „Bastellösungen“ aus und können später nur noch schwer verwaltet werden. Firmen, die demnach eine vollumfänglich verwaltbare Lösung für diesen Bereich suchen, müssen sich vermutlich noch anders orientieren. Aber Microsoft arbeitet weiter am Windows Defender und wird auch hier früher oder später neue Verwaltungsmöglichkeiten anbieten, die das Produkt auch für große Firmen wieder interessant macht. Für kleine und mittlere Umgebungen, die möglicherweise nicht so hohe Anforderungen an ein solches Produkt stellen, dürfte die Lösung durchaus willkommen sein.

232

8 Windows-Dienste absichern Windows Vista führt – wie jedes andere Microsoft-Betriebssystem auch – im Hintergrund eine Reihe von Diensten aus. Viele dieser Dienste werden beim Start von Windows Vista automatisch gestartet und bleiben dies auch während der gesamten Laufzeit des Betriebssystems. Andere Dienste werden bei Bedarf gestartet und möglicherweise auch wieder beendet, wenn sie nicht mehr verwendet werden. Einige Dienste stellen wichtige Komponenten des Betriebssystems bereit, ohne die nur ein eingeschränkter Betrieb möglich ist. Andere Dienste hingegen werden von Anwendungen verwendet. Bei Diensten handelt es sich grundsätzlich um Anwendungen, die teilweise beim Systemstart automatisch ausgeführt werden und somit zur Verfügung stehen, ohne dass sie explizit gestartet werden müssen. Da diese Programme ständig laufen, sind sie beliebte Ziele für Angriffe jeglicher Art und müssen daher besonders geschützt werden.

8.1

Dienst- und Systemkonten Jeder Dienst wird mit einem Dienst- bzw. Systemkonto (Service Account, System Account) gestartet, wobei es sich um ein manuell vorbereitetes Benutzerkonto (Service Account) oder ein vordefiniertes Betriebssystemkonto (System Account) handeln kann. Bei Anzeige der Windows-Dienste werden die jeweils verwendeten Dienstkonten sichtbar.

233

8 Windows-Dienste absichern

Abbildung 8.1 Dienstkonten in der Übersicht

Windows Vista stellt drei integrierte Systemkonten zur Verfügung, die von allen Basisdiensten verwendet werden:

Systemkonto

Beschreibung

Lokales System

Dieses Systemkonto verfügt über fast vollständige Zugriffsrechte auf dem lokalen System. Gleichzeitig nimmt es die Identität des lokalen Computers für Netzwerkzugriffe an und kann sich so auch an anderen Systemen im Netzwerk authentifizieren.

Lokaler Dienst

Bei diesem Konto handelt es sich um ein Systemkonto mit eingeschränkten Rechten. Wie ein normales Benutzerkonto auch hat es die Möglichkeit, auf bestimmte, aber nicht auf alle Bereiche des lokalen Systems zuzugreifen.

Netzwerkdienst

Dieses Systemkonto verfügt auf dem lokalen System über eingeschränkte Rechte (wie das Systemkonto „Lokaler Dienst“). Beim Herstellen von Netzwerkverbindungen nimmt es die Identität des lokalen Systems an und kann sich so an anderen Systemen authentifizieren (wie das Systemkonto „Lokales System“).

Administratoren können für den Start von Diensten beliebige Konten konfigurieren. Diese müssen lediglich über die entsprechenden Rechte verfügen, damit der Dienst alle seine

234

8.1 Dienst- und Systemkonten Aufgaben uneingeschränkt ausführen kann. Gleichzeitig sollte allerdings sichergestellt werden, dass diese Konten nicht zu viele Rechte aufweisen, weil sonst das Betriebssystem im Fall einer Dienstkompromittierung einem erhöhten Risiko ausgesetzt ist. Das Konto einfach der lokalen Gruppe „Administratoren“ hinzuzufügen wäre somit der falsche Ansatz – wenn auch der einfachste. An den Standarddiensten müssen normalerweise keine Änderungen an den Dienstkonten vorgenommen werden. Falls Sie dies trotzdem tun, könnte es sein, dass bestimmte Dienste nicht mehr korrekt ausgeführt werden oder (und das wäre noch schlimmer) das System einem erhöhten Risiko gegenüber Angriffen ausgesetzt wird.

Einige Dienste werden als eigenständige Prozesse ausgeführt, andere hingegen werden im Kontext des Prozesses „svchost.exe“ ausgeführt. Haben Sie sich schon einmal gewundert, warum im „Task Manager“ mehrere Instanzen des Prozesses „Svchost.exe“ laufen? Jetzt wissen Sie es. Dieser Prozess gilt als Gefäß für die Ausführung verschiedener Dienste (oft werden mehrere Dienste in einem einzigen svchost-Prozess registriert), um die Sicherheitskonfiguration der beinhalteten Dienste zu vereinfachen. Anstatt jeden Dienst einzeln zu konfigurieren, ist es so möglich, dem jeweiligen svchost-Prozess eine Sicherheitskonfiguration mitzugeben, die dann für alle darin laufenden Dienste verbindlich ist. Ein einzelnes Sicherheitstoken mit den zugewiesenen Berechtigungen für den svchost-Prozess reicht somit aus, um mehrere Dienste mit der korrekten Sicherheitskonfiguration auszurüsten. Mit dem „Process Explorer“ lassen sich diese Informationen detailliert darstellen.

Abbildung 8.2 Eigenständige und in einem svchost-Prozess registrierte Dienste

235

8 Windows-Dienste absichern Über den Reiter „Security“ sind die Sicherheitseinstellungen des svchost-Prozesses ersichtlich. Es ist zu erkennen, mit welchem Dienst- bzw. Systemkonto die registrierten Dienste ausgeführt werden und in welcher Session diese laufen (mehr Informationen zu Sessions später in diesem Kapitel). Es wird zudem angezeigt, welche SIDs im Sicherheitstoken des svchost-Prozesses enthalten sind. Wie ein Benutzerkonto verfügen auch Dienste über ein Sicherheitstoken, das angibt, über welche Gruppenmitgliedschaften und über welche Integritätsebene sie verfügen. Im unteren Bereich werden die dem Prozess explizit zugewiesenen Rechte angezeigt, die benötigt werden, damit die registrierten Dienste ihre Aufgaben uneingeschränkt wahrnehmen können.

Abbildung 8.3 Sicherheitsanzeige eines svchost-Prozesses

Durch das Zusammenfassen von einzelnen Diensten zu einem svchost-Prozess kann wie gezeigt die Sicherheitskonfiguration vereinfacht werden, indem Einstellungen an mehrere Dienste vererbt werden, die genau die gleichen Rechte benötigen. Was ist hiervon aber neu bei Windows Vista? So weit eigentlich noch nicht viel. Trotzdem hat Windows Vista einige Neuerungen im Zusammenhang mit Diensten zu bieten, und so wurden verschiedene Techniken eingeführt, die verhindern sollen, dass Dienste – beispielsweise dann, wenn Sie erfolgreich angegriffen worden sind – unnatürlich reagieren und so Schaden am eigenen Gerät oder an anderen Systemen anrichten können.

236

8.2 Viele Dienste standardmäßig nicht ausgeführt

8.2

Viele Dienste standardmäßig nicht ausgeführt Unter Windows Vista werden Dienste, die vom Betriebssystem nicht zwingend benötigt werden, gar nicht erst ausgeführt. Das macht Sinn, weil dadurch die Angriffsoberfläche des Betriebssystems verkleinert wird. Dienste sind in der Vergangenheit immer öfter Ziele von Angriffen geworden und müssen daher gut geschützt werden. Die einfachste Maßnahme ist demnach die, Dienste, die nicht benötigt werden, auch nicht auszuführen bzw. gar nicht erst zu installieren. Dann entstehen auch keine Missverständnisse beim Einspielen von Updates. Ein häufig in der Praxis beobachtetes Beispiels stellen Dienste dar, die auf einem Rechner ausgeführt werden, obwohl sie eigentlich gar nicht benötigt werden. Und weil die nicht benötigt werden, werden sie auch nicht regelmäßig mit den neusten Updates aktualisiert. Je länger ein solches System im Betrieb ist, desto größer wird die Gefahr eines erfolgreichen Angriffs, weil ein Dienst möglicherweise über Jahre nicht aktualisiert worden ist und zwischenzeitlich viele Angriffspunkte bekannt geworden sind, diesen zu kompromittieren. Wenn diese Dienste deinstalliert oder zumindest deaktiviert bleiben, wird dieses Risiko verringert oder aber ganz aus der Welt geschafft.

8.3

Dienste werden mit tiefstmöglichen Rechten und isoliert ausgeführt Viele Dienste wurden bisher mit dem Dienstkonto „Lokales System“ ausgeführt. Das Problem bei diesem Konto ist, dass es auf dem lokalen Gerät über sehr hohe Rechte verfügt und dadurch die Möglichkeit hat, auf viele Informationen des lokalen Geräts zuzugreifen, auch auf sensitive Daten. Wenn ein solcher Dienst kompromittiert wird, kann dies einem Angreifer sehr viele Möglichkeiten bieten, um Daten eines Systems auszulesen oder den Angriff auf weitere Bereiche des Geräts auszuweiten. Zudem wurden Diensten grundlegende Rechte entzogen, um bestimmte Tätigkeiten auf einem System auszuführen. Mit Windows Vista ist die Anzahl der Dienste, die mit diesem Konto ausgeführt werden, reduziert worden. Dienste verfügen nur noch über genau diejenigen Rechte, die sie effektiv benötigen, wodurch wiederum die Angriffsoberfläche verringert wird. Natürlich benötigen einige Dienste nach wie vor das lokale Systemkonto, weil sie sonst nicht korrekt arbeiten können, aber bei vielen Diensten wurde das Konto angepasst und durch eines mit weniger Rechten ersetzt. Eine weitere sehr wichtige Neuerung ist die Tatsache, dass Dienste nun über eine eigene SID, also eine Sicherheits-ID, verfügen. Mithilfe dieser SID ist es möglich, einem Dienst sehr gezielt Rechte auf Objekte wie beispielsweise Dateien, Ordner oder Registrierungsschlüssel zu erteilen oder zu verweigern. Administratoren verwenden dazu Dienste zum expliziten Berechtigen oder Verweigern, genauso wie sie es mit Benutzern oder Gruppen auch tun. Entwickler wiederum können festlegen, ob Dienste über eingeschränkte Rechte verfügen. Natürlich kann jeder Entwickler eines Windows-Diensts selber entscheiden, ob

237

8 Windows-Dienste absichern er das tatsächlich will oder nicht, aber die Möglichkeit dazu ist vorhanden. Wenn eine solche Einschränkung erfolgt, entfernt das Betriebssystem die nicht benötigten Rechte aus dem Sicherheitstoken des Dienstes bzw. des svchost-Prozesses. Der Dienst ist somit weitaus weniger mächtig und kann bei einer allfälligen Kompromittierung weniger (oder gar keinen) Schaden anrichten. Auch Administratoren können in die Sicherheitskonfiguration von Diensten eingreifen, allerdings sind dann entsprechend tiefe Kenntnisse über die Dienste und deren Aufgaben notwendig, damit diese nach einer Sicherheitsanpassung noch einwandfrei funktionieren. Um eine solche Konfiguration vorzunehmen, stellt Windows Vista das Tool „sc.exe“ zur Verfügung. Nebst Sicherheitskonfigurationen können Dienste auch anderweitig verwaltet werden. Sc.exe Gerätename Befehl Dienstname Option1 Option2 usw.

Parameter

Umleitung nach

Sc.exe

Tool für die Dienstverwaltung

Gerätename

Legt den Gerätenamen fest, auf dem der Befehl ausgeführt werden soll. Wenn kein Name angegeben wird, erfolgt die Ausführung lokal.

Befehl

Das Tool stellt über 20 Befehle zur Verfügung, mit denen Informationen über Startart, Sicherheitskonfiguration oder sonstige Konfigurationen abgefragt werden können. Mit Befehlen können auch Konfigurationsänderungen vorgenommen werden. Mit dem Befehl „sc.exe /?“ kann eine Liste mit allen Befehlen angezeigt werden.

Dienstname

Gibt den Dienstnamen an, für den ein Befehl ausgeführt werden soll.

Option 1, Option 2 usw.

Einige Befehle benötigen Optionen, die zum Abschluss des Befehls eingegeben werden müssen.

238

8.3 Dienste werden mit tiefstmöglichen Rechten und isoliert ausgeführt Anzeigen von Dienstinformationen

Abbildung 8.4 sc.exe zum Anzeigen von Dienstinformationen

Ein wichtiges Dienstattribut ist „SID-Type“. Damit wird festgelegt, ob es sich um einen „unrestricted“ (einen uneingeschränkten) oder einen „restricted“ (einen eingeschränkten) Dienst handelt. Uneingeschränkte Dienste können über Lese- und Schreibzugriffe auf andere Objekte verfügen, eingeschränkte Dienste hingegen haben grundsätzlich nur die Möglichkeit, Informationen zu lesen, nicht aber diese zu verändern. Ein Dienst, der nur sehr gezielte Schreibrechte benötigt, könnte daher als eingeschränkter Dienst konfiguriert werden, wodurch er lediglich Leserechte über bestimmte Objekte zugeteilt bekommt. In einem zweiten Konfigurationsschritt kann dem Dienst (über seine SID) das Schreibrecht auf Dateien, Ordner oder Registrierungseinträge zurückgegeben werden. Dienstrechte anpassen

Abbildung 8.5 sc.exe zum Ändern von Dienstrechten

239

8 Windows-Dienste absichern Beim Ändern an Rechten von Diensten sollten Sie sehr genau wissen, wie ein Dienst funktioniert und welche Berechtigungen dieser tatsächlich benötigt. Wenn ein Dienst zu wenige Rechte besitzt, kann er nicht korrekt ausgeführt werden; besitzt er hingegen zu viele Rechte, kann das ein Sicherheitsrisiko für das System darstellen. Um Änderungen an Diensten vorzunehmen, werden erhöhte Rechte benötigt, wozu die Eingabeaufforderung im Administratoren-Modus gestartet werden muss.

Eingeschränkte Dienste konfigurieren

Abbildung 8.6 sc.exe zum Ändern des Attributs „SID-Type“

Nachdem der Dienst jetzt eingeschränkt ist, kann ein Administrator jetzt festlegen, auf welche Objekte der Dienst Schreibrechte erhalten soll. Dies erfolgt nach dem gleichen Prinzip wie das Berechtigen eines Benutzers über die Sicherheitseinstellungen des jeweiligen Objekts. Um allerdings dem System mitzuteilen, dass es sich bei dem hinzuzufügenden Objekt um einen Windows-Dienst handelt, muss dies auch explizit spezifiziert werden. Wie im folgenden Screenshot ersichtlich ist, muss dazu das Format NT Service\Dienstname verwendet werden.

240

8.4 Dienste können für den Netzwerkbetrieb eingeschränkt werden

Abbildung 8.7 Rechtezuweisung für einen Windows-Dienst

8.4

Dienste können für den Netzwerkbetrieb eingeschränkt werden Einige Dienste des lokalen Systems arbeiten möglicherweise netzwerkbasiert, d.h., sie stellen über das Netzwerk Verbindungen zu anderen Geräten her. Ein Beispiel eines solchen Dienstes ist der automatische Update-Dienst, der sich regelmäßig mit Windows Update oder einem firmeninternen Server verbindet, um die aktuellsten Updates zu beziehen und diese anschließend zu installieren. Diese Netzwerkverbindung muss zwingend hergestellt werden können, damit der Dienste einwandfrei funktionieren kann. Es gibt aber auch Dienste, die keinen Netzwerkzugriff benötigen, weil sie ausschließlich lokale Aufgaben wahrnehmen. Diese Dienste sollten daher auch das Recht besitzen, ausgehende Verbindungen herzustellen. Mithilfe der Dienstintegration in die Firewall und der Tatsache, dass Windows Vista auch ausgehende Verbindungen einschränken kann, kann dieses Ziel erreicht werden. Dienste, die tatsächlich nur lokal arbeiten, können so mithilfe der Firewall eingeschränkt werden. Im Fall einer erfolgreichen Dienstkompromittierung wird einem Angreifer dadurch erschwert, einen Angriff auf andere Systeme auszuweiten, weil die Windows-Firewall möglicherweise für diesen Dienst keine ausgehenden Verbindungen vorsieht und diese Verbindungen blockiert. Dienste, die effektiv Netzwerkverbindungen herstellen müssen, können ebenfalls eingeschränkt werden, und zwar so, dass sie genau diejenigen Ziele ansprechen können, die sie auch benötigen – aber nicht mehr.

241

8 Windows-Dienste absichern

Abbildung 8.8 Ausgehende Verbindungen für einen bestimmten Dienst blockieren

Detailinformationen zum Erstellen von Regeln, die ausgehende Verbindungen blockieren, finden Sie im Kapitel „Windows Firewall“.

8.5

Isolation der „Session 0“ Wenn sich Benutzer an einem Gerät anmelden, wird für jeden Benutzer eine Session gestartet. Unter Windows Vista ist es mit der schnellen Benutzerumschaltung (Fast User Switching) möglich, mehrere Benutzer gleichzeitig an einem Gerät zu authentifizieren. Eine weitere Möglichkeit besteht im Herstellen von Remote-Desktop-Verbindungen auf ein System. Somit kann es sein, dass auf einem Gerät mehrere Sessions gleichzeitig ausgeführt werden. Die „Session 0“ ist unter Windows Vista speziell für die Ausführung von Diensten (die auf einer hohen Integritätsebene arbeiten) und nicht für Benutzer reserviert. Sie verfügt daher auch nicht über eine Benutzeroberfläche, wodurch Benutzer nicht direkt mit den ausgeführten Diensten kommunizieren und (möglicherweise falsche) Entscheidungen treffen können. Wenn sich Benutzer anmelden und Anwendungen starten, werden diese in der Benutzersession (z.B. „Session 1“ für den ersten angemeldeten Benutzer) ausgeführt und sind somit

242

8.5 Isolation der „Session 0“ von den Windows-Diensten getrennt. Durch diese Isolation wird es bösartigen Anwendungen erschwert, erfolgreiche Dienste zu kompromittieren und so an höhere Rechte zu kommen, weil bestimmte Kommunikationsmöglichkeiten zwischen den Sessions eingeschränkt sind. Mithilfe des Tools „Process Explorer“ kann sichtbar gemacht werden, in welchen Sessions Dienste und Anwendungen ausgeführt werden. Dazu muss lediglich die Spalte „Session“ eingeblendet werden.

Abbildung 8.9 Anzeige der verwendeten Session

Vor Windows Vista wurden in der „Session 0“ Dienste und Benutzeranwendungen des ersten angemeldeten Benutzers in der gleichen Session ausgeführt, wodurch die direkte Interaktion der beiden Komponenten möglich war.

243

8 Windows-Dienste absichern

8.6

Rückblick Mit Windows Vista wurden im Bereich der Windows-Dienste einige neue Funktionen eingeführt, um die Angriffsoberfläche des Systems entscheidend zu verringern. Allerdings wird es einige Zeit brauchen, bis Administratoren und Entwickler mit den neuen Möglichkeiten vertraut sind und die Vorteile auch tatsächlich nutzen werden. Aber selbst wenn dieses Umdenken nicht unmittelbar erfolgt, bietet Windows Vista im Bereich der WindowsDienste weitaus mehr Sicherheit als dessen Vorgänger und erhöht die Sicherheit mit dem Einsatz von geschickt gewählten Dienstkonten, der Dienst- und Session 0-Isolation und den nicht zwingend verwendeten und deshalb deaktivierten Diensten markant.

244

9 Hardware und Treiber Mit Windows Vista wurden rund 700 neue Gruppenrichtlinieneinstellungen eingeführt, um das Betriebssystem noch detaillierter konfigurieren zu können. Einige davon befassen sich mit der Konfiguration von Hardware und Treibern und ermöglichen Administratoren so eine viel engere und flexiblere Kontrolle von Systemen. Dass Administratoren sich schwertun in den nunmehr über 2300 Einstellungen, die gewünschten darunter zu finden, ist es anderes Thema – aber lassen wir das. Eine wichtige und von Firmen oft gewünschte Richtlinieneinstellung ist die Installationseinschränkung bestimmter Hardwaretypen. Ich wurde oft von Firmen gefragt, wie die Installation von USB-Laufwerken und USB-DVDBrennern verhindert werden kann, ohne gleich alle USB-Geräte, z.B. Digitalkameras, einzuschränken. Das war bisher ein nicht ganz einfaches Unterfangen. Mit den neuen Windows Vista-Gruppenrichtlinieneinstellungen wird das allerdings zum Kinderspiel. Warum aber möchten Firmen bzw. IT-Entscheider die Nutzung bestimmter USB-Geräte überhaupt verhindern? Es gibt viele Gründe, die dafür sprechen, Benutzer daran zu hindern, solche Geräte einzusetzen. Einerseits wird es dadurch sehr leicht möglich, „fremde“ Daten in ein Netzwerk zu importieren. Was passiert, wenn ein Benutzer ausführbare Dateien von seinem privaten Rechner mit in die Firma bringt und diese startet? Das ist möglicherweise noch nicht so schlimm. Wenn diese Dateien allerdings einen Trojaner tragen, der auf eine Ausführung wartet, kann das auf ein Firmengerät verheerende Auswirkungen haben. Wenn der Zugriff auf die weit verbreiteten USB-Laufwerke unterbunden wird, fällt diese Möglichkeit des Datenimports weg. Zugegeben, es gibt eine Reihe anderer Methoden, um Daten in ein Netzwerk einzuschleusen: E-Mail, FTP, WebDAV usw. Demnach müssten auch diese Kommunikationswege geprüft und allenfalls eingeschränkt werden. Mit der neuen Möglichkeit, die Windows Vista aber bietet, lässt sich eine dieser Methoden schon einmal sehr einfach blockieren. Es ist demnach ein weiterer kleiner Baustein eines Konstrukts, um die Sicherheit von Systemen zu erhöhen. Die Sicherheitseinstellungen in diesem Abschnitt richten sich an Administratoren, welche die Installation bzw. den Zugriff auf bestimmte Gerätetypen verhindern möchten. Diese Maßnahme dient natürlich auch dem Schutz vor Angriffen, allerdings nur begrenzt. Mittlerweile sind auf dem Markt USB-basierte Geräte verfügbar, die als Keylogger eingesetzt werden können. Diese zeichnen sämtliche Eingaben des Benutzers auf und können den

245

9 Hardware und Treiber Angreifer per Mail regelmäßig informieren, welche Eingaben auf dem Gerät getätigt worden sind. Andere wiederum verwenden einen integrierten Webserver, über den ein Angreifer jederzeit zugreifen und die protokollierten Informationen abrufen kann. Auch kritisch können US-basierte WLAN-Adapter sein, mithilfe derer ein Angreifer versuchen könnte, den Zugriff auf ein System zu erhalten. Ein solches Gerät ist innerhalb weniger Sekunden installiert, und ein Angreifer benötigt lediglich kurz einen physikalischen Zugriff auf ein solches Gerät. Aber welche Geräte auch immer von Angreifern verwendet werden, sie sind schwer zu erkennen, weil Benutzer selten prüfen, ob sich am USB-Anschluss des Desktops, der sich unter dem Bürotisch befindet, ein unbekanntes USB-Gerät befindet. Hand aufs Herz: Wann haben Sie zum letzten Mal geprüft, ob sich ein solches Gerät an Ihrem PC befindet? Mit der Möglichkeit, solche Installationen zu verhindern, können solche Angriffsversuche wahrscheinlich abgewehrt werden. Wenn Angreifer während längerer Zeit physischen Zugriff auf ein Gerät haben, wird diese Funktion natürlich wertlos, weil sie mit verschiedenen Techniken ausgehebelt werden kann. Bei allen technischen Schutzmöglichkeiten der Hardware gilt es deshalb, diese physikalisch zu sichern, beispielsweise indem firmeninterne Desktop-Geräte nicht öffentlich zugänglich gemacht oder Notebooks mit der BitLocker-Technologie (oder anderen vergleichbaren Methoden) verschlüsselt werden.

9.1

Neue Gruppenrichtlinieneinstellungen An unterschiedlichen Bereichen können die Gerätenutzung und die Treiberinstallation detailliert gesteuert werden. Schauen wir uns dazu einmal den ersten Bereich an. Unter Computerkonfiguration\Administrative Vorlagen\System\Wechselmedienzugriff kann festgelegt werden, auf welche Arten von Wechselmedien grundsätzlich zugegriffen werden kann und welche Zugriffsarten erlaubt sind.

246

9.1 Neue Gruppenrichtlinieneinstellungen

Abbildung 9.1 Wechselmedienzugriff verwalten

Richtlinie

Beschreibung

Zeit (in Sekunden) bis zur Erzwingung des Neustarts

Nachdem der Zugriff auf ein Wechselmedium eingeschränkt worden ist, muss das System neu gestartet werden. Mithilfe dieser Richtlinie kann der zwingende Neustart automatisiert werden, indem ein Zeitwert angegeben wird. Um die Richtlinie zu aktivieren, ist allerdings zwingend ein Neustart erforderlich.

CD und DVD: Lese/Schreibzugriff verweigern

Mit diesen beiden Richtlinien erfolgt die Zugriffssteuerung auf CD- und DVD-Geräte. Eine Unterscheidung zwischen den beiden Gerätetypen bzw. zwischen CD/DVD-Lesern und -Brennern erfolgt nicht. Die Richtlinie gilt für alle Gerätetypen.

Benutzerdefinierte Klassen: Lesezugriff/Schreibzugriff verweigern

In diesem Bereich können spezifische Geräteklassen blockiert werden. Möchten Sie beispielsweise nur den Zugriff auf Digitalkameras blockieren, andere Geräte aber uneingeschränkt zulassen, kann dies mit einer benutzerdefinierten Klasse erfolgen. Dazu muss die jeweilige GUID der Geräteklasse angegeben werden.

Diskettenlaufwerke: Lese/Schreibzugriff verweigern

Mit diesen beiden Richtlinien erfolgt die Zugriffssteuerung auf Disket-

Wechseldatenträger: Lese/Schreibzugriff verweigern

Mit diesen beiden Richtlinien erfolgt die Zugriffssteuerung auf Wech-

Bandlaufwerke: Lese/Schreibzugriff verweigern

Mit diesen beiden Richtlinien erfolgt die Zugriffssteuerung auf Band-

tenlaufwerke.

seldatenträger.

laufwerke.

247

9 Hardware und Treiber Richtlinie

Beschreibung

WPD-Geräte: Lese/Schreibzugriff verweigern

Mit diesen beiden Richtlinien erfolgt die Zugriffssteuerung auf WPDGeräte. WPD steht für „Windows Portable Devices“ und beinhaltet beispielsweise PDAs oder mobile Telefone.

Wenn der Lese- oder Schreibzugriff auf eine bestimmte Geräteart verhindert wird, zeigt das Betriebssystem beim Zugriff auf das Gerät eine Fehlermeldung an – je nach konfigurierter Richtlinie wird die Fehlermeldung sofort angezeigt (wenn der Lesezugriff blockiert wird) oder spätestens dann, wenn ein Schreibzugriff auf das Medium erfolgt (wenn nur der Schreibzugriff blockiert wird). Was aber, wenn der Zugriff auf Gerätetypen blockiert werden soll, die nicht über die verfügbaren Richtlinien konfiguriert werden können? Auch das lässt sich lösen, und zwar mit der zuvor beschriebenen Richtlinie, mit der sich benutzerdedinierte Geräteklassen konfigurieren lassen. Dazu muss zuerst die Hardware-ID oder die Geräteklasse-ID des zu konfigurierenden Geräts ausfindig gemacht werden. Am einfachsten schließen Sie ein solches Gerät an Ihren PC an und starten nach erfolgreicher Installation den Gerätemanager. Über den Reiter „Details“ der Geräteeigenschaften können die benötigten IDs angezeigt werden.

Abbildung 9.2 Anzeigen der IDs für Hardware und Geräteklassen

Wählen Sie im Auswahlfeld die Eigenschaften „Geräteklasse-GUID“ bzw. „HardwareIDs“ aus, und prüfen Sie die angezeigten Werte. Eine Geräteklasse spezifiziert einen bestimmten Gerätetyp, beispielsweise alle USB-Laufwerke oder alle Digitalkameras. Wenn

248

9.1 Neue Gruppenrichtlinieneinstellungen Sie eine ganze Klasse, also eine Geräteart, sperren möchten, können Sie diese Geräteklasse verwenden und die ID in der Richtlinie für benutzerspezifische Klassen angeben. Möchten Sie hingegen genauer festlegen, welche Geräte blockiert werden sollen, verwenden Sie die angezeigten Hardware-IDs. Hier werden mehrere IDs angezeigt. Werte weiter oben in der Liste spezifizieren sehr genau, um welche Geräte es sich handelt. Im gezeigten Screenshot beispielsweise ist in der obersten Hardware-ID der genaue USB-Laufwerkstyp inkl. Versionsangabe festgelegt. Wird diese ID für das Blockieren des Zugriffs verwendet, werden nur genau diese USB-Laufwerke blockiert. Wenn ein Benutzer allerdings ein Version 1Gerät verwendet, ist der Zugriff darauf nach wie vor uneingeschränkt möglich. Wenn Sie den Zugriff demnach umfassender einschränken möchten, müssen Sie Hardware-IDs weiter unten in der Liste verwenden. Um die Richtlinie zu konfigurieren, muss lediglich die jeweilige ID kopiert und in die Richtlinie eingefügt werden.

Abbildung 9.3 Geräteklasse-ID oder Hardware-ID einfügen

Besser, als nur den Zugriff auf ein bestimmtes Gerät zu verhindern, ist es, die Treiberinstallation bzw. -aktivierung für ein Gerät vollständig zu blockieren. Über den Pfad Computerkonfiguration\Administrative Vorlagen\System\Geräteinstallation einer Gruppenrichtlinie stehen genau diese und noch weitere Möglichkeiten zur Verfügung.

249

9 Hardware und Treiber

Abbildung 9.4 Richtlinien für die Geräteinstallation

Richtlinie

Beschreibung

Alle digital signierten Treiber bei der Treiberbewertung aus Auswahl gleich behandeln

Wenn ein Gerät installiert wird, zeigt Windows Vista jeweils eine Liste gültiger Treiber zur Auswahl an. Dabei werden Treiber, die von Microsoft signiert sind, Treibern mit „fremden“ Signaturen und unsignierten Treibern vorgezogen. Bei Aktivierung dieser Richtlinie werden Microsoft-signierte Treiber und signierte Treiber von anderen Herstellern gleichwertig behandelt. Unsignierte Treiber hingegen haben auch bei aktivierter Richtlinie letzte Priorität.

Sprechblasen mit der Meldung „Neue Hardware gefunden“ während der Geräteinstallation deaktivieren

Nach Aktivierung dieser Richtlinie wird dem Benutzer nicht angezeigt,

Keinen WindowsFehlerbericht senden, wenn ein Standardtreiber in einem Gerät ist

Bei Aktivierung dieser Richtlinie wird kein Fehlerbericht erstellt, wenn

Zeitlimit für die Geräteinstallation festlegen

Wenn das in dieser Richtlinie angegebene Zeitlimit für eine Treiberin-

dass ein Treiber erfolgreich installiert worden ist. Standardmäßig wird diese Nachricht angezeigt.

für ein Gerät ein generischer Treiber installiert worden ist.

stallation überschritten wird, wird die Installation abgebrochen. Der Standardwert liegt bei 300 Sekunden, also fünf Minuten.

Bei der Installation eines neuen Gerätetreibers keinen Systemwiederherstellungspunkt erstellen

250

Bei Aktivierung dieser Richtlinie wird vor einer Treiberinstallation kein Systemwiederherstellungspunkt erstellt. Standardmäßig wird ein solcher Punkt bei Treiberinstallationen und -aktualisierungen erstellt,

9.1 Neue Gruppenrichtlinieneinstellungen was bei Problemen die Wiederherstellung einer älteren, funktionierenden Konfiguration und Treibersituation ermöglicht. Remotezugriff auf die PnPSchnittstelle zulassen

Durch Aktivierung dieser Richtlinie ist es möglich, über andere Sys-

Administratoren das Außerkraftsetzen der Richtlinien unter „Einschränkungen bei der Geräteinstallation“ erlauben

Wird diese Richtlinie aktiviert, können alle Mitglieder der lokalen

Installation von Geräten mit Treibern zulassen, die diesen Gerätesetupklassen entsprechen

Mit dieser Richtlinie kann die Treiberinstallation für bestimmte Gerä-

teme auf die lokale Plug’n’Play-Schnittstelle zuzugreifen.

Gruppen „Administratoren“ uneingeschränkt Treiber installieren, unabhängig davon, ob dies mit einer anderen Richtlinie verhindert wird.

teklassen explizit zugelassen werden. Diese Richtlinie wird nur benötigt, wenn die Richtlinie „Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind“ aktiviert ist. Mit dieser Konstellation kann ein System so konfiguriert werden, dass Treiberinstallationen für sämtliche Geräte blockiert werden, die explizit in dieser Richtlinie festgelegten Geräte aber installiert werden dürfen. Für das Festlegen von Geräten werden Geräteklassen-IDs benötigt.

Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen

Mit dieser Richtlinie kann die Treiberinstallation für bestimmte Geräteklassen explizit verhindert werden. Das Verhindern der Geräteinstallation mit dieser Richtlinie hat Vorrang vor Richtlinien, welche die Installation der gleichen Geräteklasse explizit zulassen. Für das Festlegen von Geräten werden Geräteklassen-IDs benötigt.

Benutzerdefinierte Meldung anzeigen, wenn Installation durch eine Richtlinie verhindert wird (Hinweistext)

Wenn ein Treiber nicht installiert werden kann, kann dem jeweiligen

Benutzerdefinierte Meldung anzeigen, wenn Installation durch eine Richtlinie verhindert wird (Hinweistitel)

Wenn ein Treiber nicht installiert werden kann, kann dem jeweiligen

Installation von Geräten mit diesen Geräte-IDs zulassen

Mit dieser Richtlinie kann die Treiberinstallation für Geräte mit einer

Benutzer eine beliebige Nachricht angezeigt werden. In dieser Richtlinie wird der angezeigte Text angegeben.

Benutzer eine beliebige Nachricht angezeigt werden. In dieser Richtlinie wird der angezeigte Fenstertitel zum Text angegeben.

bestimmten Hardware-ID explizit zugelassen werden. Diese Richtlinie wird nur benötigt, wenn die Richtlinie „Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind“ aktiviert ist. Mit dieser Konstellation kann ein System so konfiguriert werden, dass Treiberinstallationen für sämtliche Geräte blockiert werden, die explizit in dieser Richtlinie festgelegten Geräte aber installiert werden dürfen. Für das Festlegen von Geräten werden Hardware-IDs benötigt.

Installation von Geräten mit diesen Geräte-IDs verhindern

Mit dieser Richtlinie kann die Treiberinstallation für Geräte mit einer bestimmten Hardware-ID explizit verhindert werden. Das Verhindern der Geräteinstallation mit dieser Richtlinie hat Vorrang vor Richtlinien,

251

9 Hardware und Treiber welche die Installation der gleichen Hardware-IDs explizit zulassen. Für das Festlegen von Geräten werden Hardware-IDs benötigt. Installation von Wechselgeräten verhindern

Diese Richtlinie verhindert die Treiberinstallation sämtlicher Wechselgeräte. Die Richtlinie hat Priorität vor anderen Richtlinien, welche die Installation von Wechselgeräten zulassen.

Installation von Geräten verhindern, die nicht in anderen Richtlinien beschrieben sind

Wenn diese Richtlinie aktiviert wird, werden sämtliche Treiberinstallationen verhindert, sofern dies nicht in einer anderen Richtlinie, beispielsweise mit der Richtlinie „Installation von Geräten mit diesen Geräte-IDs zulassen“, explizit zugelassen wird.

Im Bereich Computerkonfiguration\Administrative Vorlagen\System\Treiberinstallation stehen nochmals zwei Einstellungen für die Konfiguration der Treiberinstallation zur Verfügung.

Abbildung 9.5 Richtlinien für die Treiberinstallation

252

Richtlinie

Beschreibung

Installation von Treibern dieser Gerätesetupklassen ohne Administratorenrechte zulassen

Wenn diese Richtlinie aktiviert ist, können Benutzer ohne Administra-

Eingabeaufforderung zur Suche nach Gerätetreibern auf Windows Update deaktivieren

Bei aktivierter Richtlinie erhalten Administratoren keine Aufforderung

torenrechte Treiber der angegebenen Geräteklassen installieren. Für das Festlegen von Geräten werden Geräteklassen-IDs benötigt.

zum Suchen von Treibern über Windows Update.

9.2 Treibersignaturen

9.2

Treibersignaturen Bereits seit Längerem verwenden Hersteller von Treibern die Möglichkeit, diese digital zu signieren. Aber wozu soll das gut sein? Eine digitale Signatur identifiziert den Signierer eindeutig, und somit wird es möglich, die Echtheit des Treibers bzw. die Identität des Herstellers sicherzustellen. Eine solche Überprüfung macht durchaus Sinn, weil dadurch verhindert werden kann, dass schädliche Programme unter dem Deckmantel von Treiberherstellern installiert werden können. Das Betriebssystem verfügt daher über einen Mechanismus, um Treibersignaturen zu überprüfen und bei nicht signierten Treibern entsprechend zu reagieren. Unter Windows Vista funktioniert dieses Feature je nach eingesetzter Architektur unterschiedlich. Die 32-Bit-Version von Windows Vista lässt die Installation von unsignierten Treibern durch Administratoren zu, nachdem eine entsprechende Warnmeldung angezeigt worden ist. Benutzer mit normalen Rechten hingegen können solche Treiber nicht installieren. Das gleiche Szenario auf einem Gerät, das die 64-Bit-Version von Windows Vista ausführt, verhindert die Installation eines nicht signierten Treibers vollständig. Diese Version setzt voraus, dass alle Kernel-basierten Treiber über eine digitale Signatur verfügen, damit eine Installation erfolgreich durchgeführt werden kann. Verfügt ein Treiber nicht über eine digitale Signatur, kann der Treiber nicht installiert werden. Diese Einschränkung lässt sich nicht ausschalten, was gleichzeitig bedeutet, dass vor dem Einsatz eines Windows Vista-Clients auf einer 64-Bit-Architektur die Geräte- bzw. Treibersituation detailliert abgeklärt werden muss. Unabhängig davon, welche Architektur Sie einsetzen, unterscheiden Windows Vista folgende Vertrauensebenen für die Einstufung von Treibern:

Vertrauensebene

Beschreibung

Kategorie 1 – Digital signiert mit einem Microsoft WindowsZertifikat

In diese Kategorie fallen beispielsweise Treiber, die Microsoft mit dem Betriebssystem mitliefert, sowie Systemdateien, die über eine digitale Signatur verfügen. Die Signatur ist von Microsoft selber realisiert worden und gilt daher als äußerst vertrauenswürdig. Administratoren und Benutzer können solche Treiber installieren.

Kategorie 2 – Digital signiert mit einem Zertifikat eines vertrauenswürdigen Ausstellers

Ein Aussteller ist dann vertrauenswürdig, wenn die Zertifizierungsstelle in der Liste der vertrauenswürdigen Aussteller eingetragen ist. Mit Windows Vista wird bereits eine vorab gefüllte Liste mitgeliefert, die aber jederzeit erweitert bzw. gekürzt werden kann. Administratoren und Benutzer können solche Treiber installieren.

Kategorie 3 – Digital signiert mit einem Zertifikat eines nicht vertrauenswürdigen Ausstellers

Wenn ein signierter Treiber installiert werden soll, dessen Signierer nicht als vertrauenswürdig gilt, wird Administratoren von 32-

253

9 Hardware und Treiber Bit-Vista-Betriebssystemen eine Warnmeldung angezeigt, die besagt, dass der Aussteller nicht vertrauenswürdig ist. Durch Bestätigen dieser Warnmeldung kann ein Administrator einen solchen Treiber trotzdem erfolgreich installieren. Anders ist es bei 64-BitVista-Betriebssystemen. Bei dieser Architektur können Kernelbasierte Treiber, die nicht digital signiert sind, auch von Administratoren nicht mehr installiert werden. Benutzer ohne Administratorenrechte können auf beiden Plattformen keine Treiber mit diesem Status installieren. Kategorie 4 – Treiber ohne digitale Signatur

Bei Treibern dieser Kategorie ist das Verhalten identisch zu Treibern der Kategorie 3.

In den erweiterten Startoptionen (F8) steht die Option Erzwingen der Treibersignatur deaktivieren zur Verfügung, die es Administratoren und vor allem Treiberentwicklern ermöglicht, 32- und 64-Bit-Systeme in einem Modus zu starten, in dem unsignierte Treiber installiert und getestet werden können. Beim nächsten (normalen) Windows-Start ist die Option wieder ausgeschaltet. Diese erweiterte Startoption sollte sowohl auf 32-Bit- als auch auf 64-Bit-Architekturen ausschließlich für Test- und Entwicklungszwecke eingesetzt werden, um die Sicherheit und Stabilität des Betriebssystems nicht zu beeinträchtigen.

Windows Vista erlaubt es Administratoren, mit den Tool sigverf.exe installierte, nicht signierte Systemtreiber aufzuspüren und diese – falls ein Hersteller zwischenzeitlich eine neue, digital signierte Treiberversion zur Verfügung stellt – zu ersetzen.

Abbildung 9.6 sigverif.exe, Teil 1

254

9.3 Rückblick Wenn das Tool nicht signierte Dateien findet, werden diese direkt angezeigt. Detailinformationen zu den überprüften Treibern sind in der erstellten Protokolldatei sichtbar, die direkt über die erweiterten Eigenschaften angezeigt werden kann.

Abbildung 9.7 sigverif.exe, Teil 2

9.3

Rückblick Mithilfe der neuen Funktionen zur Kontrolle von Hardware- und Treiberinstallationen wird die Sicherheit des Betriebssystems zusätzlich erhöht. Benutzer können so daran gehindert werden, bestimmte Gerätetypen wie beispielsweise USB-Laufwerke zu installieren und zu nutzen. Das Gleiche gilt natürlich auch für Angreifer. Diesen wird es durch die eingeschränkten Zugriffe erschwert, ein System mit externen Geräten anzugreifen. Wenn ein Angreifer allerdings bereits über einen physikalischen Zugriff verfügt, wird die Situation schon relativ kritisch. Aber trotzdem sollten die in diesem Kapitel gezeigten Einschränkungen eingesetzt werden, um es zu erschweren, unerlaubte Geräte an einem System nutzen zu können.

255

10 Benutzerkonten und Kennwörter Kennwörter werden von Benutzern für die Authentifizierung verwendet. Ein Benutzer muss sich gegenüber einem System eindeutig identifizieren, was heute in den meisten Fällen mit einem Benutzernamen und dem korrekten zugehörigen Kennwort erfolgt. Natürlich gibt es viele andere Möglichkeiten der Benutzerauthentifizierung, beispielsweise können dazu digitale Zertifikate verwendet werden, die auf SmartCards gespeichert werden, Fingerabdruckleser oder biometrische Systeme, die einen Benutzer eindeutig identifizieren können. Kennwörter bieten gegenüber vielen anderen Methoden eine Reihe von Vorteilen: Sie können sehr flexibel eingesetzt werden, die Sicherheit kann bei korrekter Handhabung sehr hoch sein, und die Kosten für einen breiten Einsatz sind verhältnismäßig gering. Auf die meisten anderen Authentifizierungsmethoden trifft das nicht zu, weshalb diese heute sehr gezielt eingesetzt werden, aber (noch) nicht für die breite Masse bestimmt sind.

10.1

Übersicht zur Benutzerauthentifizierung Wenn sich Benutzer an einem System anmelden, wird als geheime Information das Kennwort angegeben. Das System, das die Benutzerauthentifizierung durchführt – das kann ein Windows Vista-Gerät mit einer lokalen Benutzerdatenbank, aber auch ein Domänencontroller mit einer Active Directory-Datenbank sein –, muss Zugriff auf eine Benutzerdatenbank haben, in der Anmeldenamen, Kennwörter und sonstige Informationen von Benutzern gespeichert sind. Die Schwierigkeit daran ist nun, die gespeicherten Informationen sicher zu verwalten, sodass es nicht möglich ist, dass unautorisierte Personen oder Prozesse diese Informationen auslesen können. Wenn eine solche Benutzerdatenbank kompromittiert wird, ist die Sicherheit eines lokalen Systems oder (noch viel schlimmer) der gesamten Active Directory-Domäne nicht mehr gewährleistet. Demnach muss sichergestellt werden, dass die gespeicherten Informationen sicher sind. Windows speichert Kennwörter aus diesem Grund nicht im Klartext, sondern als Hash. Bei einem Hash handelt es sich um einen Wert, der mithilfe eines Algorithmus aus einem Benutzerkennwort generiert wird. Da Hashing ein Einwegverfahren ist, kann aus einem bekannten Hash das ursprüngliche Benutzerkennwort nicht wieder hergestellt werden.

257

10 Benutzerkonten und Kennwörter Wenn ein Angreifer demnach eine Benutzerdatenbank oder Kennwörter bei der Übertragung über das Netzwerk stehlen kann, besitzt er lediglich die Hashwerte, aber noch nicht die Klartextkennwörter von Benutzern. In einem weiteren Schritt kann er natürlich versuchen, mithilfe der Hashwerte die ursprünglichen Kennwörter zu generieren. Dazu stehen verschiedene Möglichkeiten von Attacken zur Verfügung, von einfachen Wörterbuch- und Brute-Force-Angriffen bis hin zu intelligenten Angriffen, beispielsweise mit RainbowTables. Je simpler ein Benutzerkennwort konstruiert ist, umso leichter ist ein Angriff darauf, was gleichzeitig bedeutet, dass Kennwörter immer eine gewisse Komplexität aufweisen sollten. Im Normalfall sollte ein Kennwort mindestens aus acht Zeichen, aus Buchstaben, Zahlen und Sonderzeichen bestehen und natürlich regelmäßig geändert werden. Der letzte erwähnte Punkt ist entscheidend. Ein Angreifer hat genug Zeit, um mithilfe der gestohlenen Hashwerte das richtige Kennwort eines Benutzers herauszufinden. Die Idee ist nun, dass ein solcher Angriff mehr Zeit in Anspruch nimmt, als ein Benutzerkennwort gültig ist. Bis ein Angreifer ein Benutzerkennwort herausgefunden hat, muss der Benutzer das Kennwort also längst wieder geändert haben, womit die Arbeit des Angreifers umsonst war. Kennwörter bzw. die Kennwort-Hashes sind nicht nur in einer Benutzerdatenbank gespeichert, sondern werden bei der Authentifizierung über das Netzwerk übertragen, und zwar immer dann, wenn sich ein Benutzer oder ein Prozess über das Netzwerk an einem anderen System authentifiziert. Bei der Anmeldung an einer Windows-Domäne beispielsweise wird das vom Benutzer eingegebene Kennwort am Client behandelt, um es optimal zu schützen. Dazu wird vom Server eine sog. „Challenge“ – eine Zufallszahl konstanter Länge – an den Client übermittelt, die mit dem Benutzerkennwort verschlüsselt wird. Das Resultat wird dann an den Server übermittelt. Der führt wiederum die gleichen Abläufe mit dem Kennwort-Hash des anzumeldenden Benutzers durch. Sind die beiden Resultate schlussendlich identisch, hat der Benutzer am Client das korrekte Kennwort eingegeben. Das genaue Verfahren zur Übermittlung von Kennwörtern ist natürlich ein bisschen komplexer, und Microsoft unterstützt verschiedene Verfahren, um Benutzer zu authentifizieren, d.h., um Benutzerkennwörter zu übertragen. Um diese Prozesse und deren Unterschiede zu verstehen, finden Sie anbei die wichtigsten Informationen dazu.

10.1.1 Kennwortspeicherung Ein System, das eine Authentifizierung durchführen soll, also beispielsweise ein Domänencontroller oder ein Server mit einer lokalen Benutzerdatenbank, müssen Kennwörter von Benutzern in Form von Hashes gespeichert werden. Dazu unterscheidet Windows grundsätzlich zwei Hash-Typen:

258

10.1 Übersicht zur Benutzerauthentifizierung Hash

Beschreibung

LM-Hash

Unterstützt werden Kennwörter mit max. 14 Zeichen aus einem Zeichensatz von knapp über 140 Zeichen, wobei Groß- und Kleinschreibung keine Rolle spielt. Der Hash wird als 128-Bit-Wert gespeichert.

NT-Hash

Unterstützt werden Kennwörter mit max. 127 Zeichen aus einem Zeichensatz von über 65000 Zeichen. Groß- und Kleinschreibung wird berücksichtigt, was Kennwörter sehr vielfältiger macht. Der Hash wird als 128-Bit-Wert gespeichert.

Mithilfe von Werkzeugen können die Hashwerte mit den entsprechenden Berechtigungen aus einer Benutzerdatenbank ausgelesen werden. Folgender Screenshot zeigt ein solches Werkzeug, das vorwiegend bei Kennwort-Audits zum Einsatz kommt.

Abbildung 10.1 Kennwort-Hashes von Benutzerkonten

10.1.2 Übertragung über das Netzwerk Wenn sich ein Benutzer an einem Server authentifizieren muss, fordert das Ziel eine Authentifizierung. Dazu muss nun das Benutzerkennwort vom Client zum gewünschten Ziel sicher übertragen werden. Windows stellt dazu verschiedene Methoden zur Verfügung: LM-Antworten Viele Clients verwenden diese Antworten, um Kennwörter sicher zu übertragen. Dazu wird das eingegebene Benutzerkennwort wie bereits beschrieben bis zu 14 Zeichen mit Nullen aufgefüllt und alle verwendeten Buchstaben in Großbuchstaben konvertiert. Das Kennwort wird dann in zwei sieben Zeichen große Teile zerlegt, aus denen ein DESSchlüssel generiert wird, um eine Konstante zu verschlüsseln. Die erhaltenen Resultate werden dann zusammengehängt und bis zu 21 Stellen (21 Byte) mit Nullen aufgefüllt. Der erhaltene Wert wird wiederum in drei gleich große Teile à je sieben Zeichen zerlegt, die als DES-Schlüssel verwendet werden, um die zuvor vom Server zugestellte „Challenge“ zu verschlüsseln. Die drei erhaltenen Resultate werden wiederum aneinandergehängt und ergeben so die LM-Antwort, die zum Server übertragen wird.

259

10 Benutzerkonten und Kennwörter NTLM-Antworten Clients aus der Windows-Businesslinie können NTLM nutzen, um Benutzerkennwörter über das Netzwerk zu übertragen. Das eingegebene Benutzerkennwort (Groß- und Kleinbuchstaben werden übernommen) wird dabei mit dem MD4-Algorithmus zu einem 16 Byte langen NTLM-Hash verarbeitet, der anschließend mit Nullen bis auf 21 Byte aufgefüllt wird. Der erhaltene Wert wird in drei gleich große Teile à je sieben Zeichen zerlegt, die als DES-Schlüssel verwendet werden, um die zuvor vom Server zugestellte „Challenge“ zu verschlüsseln. Die drei erhaltenen Resultate werden wiederum aneinandergehängt und ergeben so die NTLM-Antwort, die zum Server übertragen wird. NTLMv2-Antworten Diese Methode stellt eine noch sicherere Art der Authentifizierung dar, weil sie speziell dazu entwickelt worden ist, Sicherheitslücken der beiden älteren Methoden zu beheben. NTLMv2 steht bereits seit Windows NT4 mit Service Pack 4 zur Verfügung und findet heute ein breites Einsatzgebiet. Wie aber werden bei dieser Methode Anmeldeinformationen geschützt? Das eingegebene Benutzerkennwort (Groß- und Kleinbuchstaben werden übernommen) wird dabei mit dem MD4-Algorithmus zu einem 16 Byte langen NTLM-Hash verarbeitet. In einem zweiten Schritt wird der verwendete Benutzername in Großbuchstaben umgewandelt und mit dem Server- bzw. Domänennamen verknüpft (je nachdem, ob eine Authentifizierung an der lokalen Benutzerdatenbank eines Server oder an einer Domäne erfolgt). Die verknüpften Informationen werden mithilfe des HMAC-MD5-Algorithmus und des NTLM-Hash als Key zu einem weiteren Hash, dem NTLMv2-Hash, verarbeitet. Aus verschiedenen Informationen, unter anderem einem Zeitstempel und einer Nonce (Nonce kommt von „Number used once“ und ist eine frei gewählte und einmalig verwendete Zahlenkombination), wird ein Blob generiert, der wiederum mit der zuvor vom Server zugestellten „Challenge“ verknüpft und mit dem HMAC-MD5-Algorithmus und dem NTLMv2-Hash als Schlüssel verarbeitet wird. Das Resultat wird erneut mit dem Blob verknüpft und so als NTLMv2-Antwort übertragen. Was ist mit Kerberos? In dem Dschungel von Möglichkeiten, sich per LM, NTLM usw. zu authentifizieren, bleibt die Frage offen, wo sich Kerberos einreiht. Seit Windows Server 2000 wird in Active Directory-Domänen Kerberos in der Version 5 als primäres Authentifizierungsprotokoll verwendet, allerdings gibt es einige Situationen, bei denen Kerberos nicht genutzt werden kann, beispielsweise dann, wenn eine Authentifizierung an einem Gerät erfolgen soll, das sich in einer Arbeitsgruppe befindet. Dann kommen wieder die „alten“ Mechanismen zum Zug.

260

10.1 Übersicht zur Benutzerauthentifizierung Bei Kerberos sind die Abläufe und Konzepte anders, was es gegenüber NTLM schneller, flexibler und auch sicherer macht. Beispielsweise ist es möglich, Geräte gegenseitig zu authentifizieren, um sicherzustellen, dass beide Parteien mit dem korrekten Partner kommunizieren und nicht fälschlicherweise Daten an ein Drittgerät übermitteln, das nicht für den Datenempfang bestimmt ist. Zudem müssen Zielgeräte von Verbindungen nicht immer einen Domänencontroller für eine Authentifizierung beauftragen. Die Authentifizierung können die Geräte selbstständig durchführen, was deutlich schnellere Antwortzeiten mit sich bringt. Benutzerkennwörter werden bei Kerberos ebenfalls als Hash zu Domänencontrollern übertragen und somit vor unbefugtem Zugriff geschützt. Nach einer erfolgreichen Authentifizierung wird dem Benutzer ein Kerberos-Ticket ausgestellt, das unter anderem den Zeitpunkt der Ausstellung sowie den Benutzernamen speichert. Anstatt bei jedem erneuten Ressourcenzugriff das Benutzerkennwort wieder einzugeben, wird lediglich das Ticket präsentiert und der Benutzer authentifiziert. Die Übertragung des Tickets wird ebenfalls gesichert. Während der täglichen Arbeit kann es sein, dass Benutzer mehrere Tickets für unterschiedliche Aktivitäten und Ressourcenzugriffe benötigen. Diese werden von Kerberos automatisch ausgestellt, um Benutzern die notwendigen Zugriffe zu gewähren. Kerberos ist zu mächtig, als dass es in diesem Buch detaillierter beschrieben werden könnte. Trotzdem ist es mir sehr wichtig, dass Leser dieses Buches die Unterschiede der einzelnen Authentifizierungsmechanismen verstehen und diese interpretieren können. Und dazu habe ich hoffentlich die relevanten Bereiche kurz angesprochen. Was ist diesbezüglich neu bei Windows Vista? Mit Windows Vista wurden zwei wichtige Änderungen am Authentifizierungsmechanismus vorgenommen, die Administratoren unbedingt kennen sollten, um Probleme beim Betrieb zu vermeiden. In den lokalen Sicherheitseinstellungen sind die zwei Änderungen unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen sichtbar.

261

10 Benutzerkonten und Kennwörter

Abbildung 10.2 Änderungen an Sicherheitseinstellungen

Richtlinie

Beschreibung

Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern

Diese Richtlinie ist standardmäßig aktiviert. Somit handelt es sich bei Windows Vista um das erste Microsoft-Betriebssystem, das LM-Hashes „out of the box“ nicht mehr speichert. Das ist einerseits gut, weil dadurch die „schwachen“ LM-Hashes nicht mehr in der Benutzerdatenbank gespeichert werden und die Kennwortinformationen dadurch besser geschützt sind. Nachteilig wirkt sich hingegen aus, dass sich Geräte, die weder Kerberos noch NTLM (also NT-Hashes) unterstützen, nicht mehr an einem Windows Vista-Gerät bzw. an dessen lokaler Benutzerdatenbank authentifizieren können.

Netzw rksicherheit: LANManagerAuthentifizierungsebene

Mit dieser Richtlinie kann festgelegt werden, welche Informationen ein Server, der eine Authentifizierung vornehmen muss, von einem Client anfordert. Folgende Einstellungen stehen zur Verfügung: LM- und NTLM-Antworten senden Clients verwenden immer LM und NTLM, aber niemals NTLMv2Sitzungssicherheit, DCs akzeptieren LM, NTLM und NTLMv2. LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt)

262

10.1 Übersicht zur Benutzerauthentifizierung Clients verwenden immer LM und NTLM und NTLMv2Sitzungssicherheit, wenn der Server es auch unterstützt, DCs akzeptieren LM, NTLM und NTLMv2. Nur NTLM-Antworten senden Clients verwenden immer NTLM und NTLMv2-Sitzungssicherheit, wenn der Server es auch unterstützt, DCs akzeptieren LM, NTLM und NTLMv2. Nur NTLMv2-Antworten senden Clients verwenden immer NTLMv2 und NTLMv2Sitzungssicherheit, wenn der Server es auch unterstützt, DCs akzeptieren LM, NTLM und NTLMv2. Diese Option ist unter Windows Vista standardmäßig ausgewählt. Nur NTLMv2-Antworten senden, LM verweigern Clients verwenden immer NTLMv2 und NTLMv2Sitzungssicherheit, wenn der Server es auch unterstützt, DCs akzeptieren nur NTLM und NTLMv2. Nur NTLMv2-Antworten senden, LM und NTLM verweigern Clients verwenden immer NTLMv2 und NTLMv2Sitzungssicherheit, wenn der Server es auch unterstützt, DCs akzeptieren nur NTLMv2. Windows

Vista

verwendet

standardmäßig

die

Einstellung

„Nur

NTLMv2-Antworten senden“.

Unter Windows XP und Windows Server 2003 beispielsweise wurden jeweils noch LMund NTML-Mechanismen für die Authentifizierung genutzt. Gleichzeitig wurden die LMHashes in der Datenbank aufbewahrt, um Kennworteingaben auf älteren Clients zu prüfen. Aus Sicht von Angreifern war das eine hervorragende Möglichkeit, um über Netzwerkpakete an Kennworthashes zu gelangen. Natürlich konnte diese Einstellung angepasst werden, aber dafür musste ein Administrator über Kenntnisse zu diesem Thema verfügen, um die korrekten Einstellungen vornehmen zu können. Sie besitzen diese Kenntnisse jetzt und wissen, wie sie ältere Betriebssysteme in Bezug auf die Kennwortspeicherung und übertragung sicherheitstechnisch optimieren können. Unter Windows Vista sind die Einstellungen bereits deutlich besser, weil nur noch die NTLMv2- Authentifizierung verwendet wird und LM-Hashes nicht mehr in der Benutzerdatenbank gespeichert werden. Diese Einstellung könnte aber möglicherweise zu Kompatibilitätsproblemen mit älteren oder „fremden“ Betriebssystemen führen, sodass sich diese nicht mehr erfolgreich an einem Windows Vista-Gerät authentifizieren können.

263

10 Benutzerkonten und Kennwörter

10.2

Schutz der lokalen Benutzerdatenbank von  Vista In der Benutzerdatenbank von Windows Vista (SAM, Secuity Account Manager) werden Benutzerkonteninformationen und Kennworthashes gespeichert, die bei einer allfälligen Authentifizierung verwendet werden. Beim Hashing-Verfahren handelt es sich um ein Einwegeverfahren, weshalb die Kennworthashes in der Benutzerdatenbank nicht umkehrbar sind, d.h., daraus nicht die Klartext-Benutzerkennwörter hergestellt werden können. Trotzdem gibt es aber eine Reihe von Möglichkeiten, um Kennwörter von Benutzern aufgrund verfügbarer Hashes zu rekonstruieren, weshalb diese optimal geschützt werden sollten. Die Übertragung über das Netzwerk haben wir im letzten Abschnitt behandelt. Was aber, wenn jemand ein Windows Vista-Notebook entwendet? Kein Problem für Sie, oder? Schließlich setzen Sie auf allen Ihren Geräten die BitLocker-Technologie ein, wodurch alle Informationen auf dem Notebook inkl. der Benutzerdatenbank verschlüsselt sind. In diesem Fall sind die Informationen geschützt und nicht zugänglich. Ohne BitLocker wird’s kritischer, weil nun ein uneingeschränkter Zugriff auf die Informationen der Benutzerkontendatenbank möglich ist. Windows Vista bietet aber auch für diesen Fall eine weitere Sicherheitsschicht, die mit dem Tool Syskey implementiert werden kann. Windows Vista verschlüsselt die Benutzerdatenbank (und viele andere Informationen wie beispielsweise SSL-Keys, Recovery Keys usw.) mit sog. Master Keys. Diese Master Keys werden wiederum mit einem Systemschlüssel verschlüsselt, dem sog. System Key. Dieser Schlüssel wird bei der Installation von Windows Vista automatisch generiert und lokal in der Registrierungsdatenbank des Systems gespeichert, sodass er beim Start von Windows immer zur Verfügung steht und die benötigten Master Keys entschlüsseln kann. Das Problem bei einem gestohlenen Notebook ist nun, dass Programme genutzt werden können, um Kennwörter von lokalen Benutzerkonten zurückzusetzen, vorzugsweise natürlich dasjenige des Administratorenkontos. Das geht, weil die Benutzerdatenbank – die verschlüsselt ist – mithilfe des frei verfügbaren System Keys entschlüsselt werden kann. Mit dem Tool Syskey kann die Speicherung des Schlüssels geändert werden. Anstelle einer lokalen Speicherung kann der Schlüssel auf eine Diskette ausgelagert oder mit einem manuellen Kennwort geschützt werden. Beim Start des Tools werden die verfügbaren Methoden angeboten.

264

10.3 Kennwortrichtlinien und Kontosperrung

Abbildung 10.3 Syskey im Einsatz

Sofern Sie sich für die Variante mit Diskette oder Kennwort entscheiden, müssen diese Informationen bei jedem Start des Geräts zur Verfügung stehen, d.h., Sie müssen das jeweilige Kennwort eingeben oder die Diskette mit dem Schlüssel einlegen. Wenn diese Informationen durch Verlust nicht mehr zur Verfügung stehen, ist ein Start des Systems nicht mehr möglich. Die einzige Möglichkeit besteht dann darin, die Registrierungsdatenbank eines früheren Zeitpunkts wiederherzustellen, zu dem der System Key noch in der Registrierungsdatenbank erfolgt ist (demnach also ein Zeitpunkt bevor das Tool Syskey eingesetzt worden ist).

10.3

Kennwortrichtlinien und Kontosperrung Der beste Übertragungsschutz von Kennwörtern und die sicherste Kennwortspeicherung sind wertlos, wenn Angreifer diese erraten können. Administratoren müssen daher sicherstellen, dass Kennwörter sicher und nicht zu erraten sind und zudem regelmäßig gewechselt werden. Mit dem Einsatz von Kontosperrungsrichtlinien kann zudem festgelegt werden, wie das System reagieren soll, wenn für Benutzerkonten mehrmals fehlerhafte Kennworteingaben erfolgen. Dabei könnte es sich um einen Angriffsversuch handeln, der unterbunden werden kann, indem Benutzerkonten nach einer bestimmten Anzahl falscher Kennworteingaben deaktiviert werden. Mithilfe von Kennwort- und Kontensperrungsrichtlinien lassen sich genau diese Einstellungen vornehmen. Wenn Windows Vista-Geräte in einer Domäne betrieben werden, werden diese Einstellungen mithilfe der „Default Domain Policy“ vorgegeben, für Geräte einer Arbeitsgruppe bzw. die Kennwortrichtlinie für lokale Benutzerkonten kann die lokale

265

10 Benutzerkonten und Kennwörter Gruppenrichtlinie eingesetzt werden. Im Abschnitt Computerkonfiguration\WindowsEinstellungen\Sicherheitseinstellungen\Kontorichtlinien\ können die gewünschten Einstellungen vorgenommen werden.

Abbildung 10.4 Kennwortrichtlinien

Die Richtlinien für Kennwörter sollten wohlüberlegt gewählt werden, da von ihnen die Sicherheit des gesamten Systems abhängig ist. Als Entscheidungshilfe finden Sie in folgender Tabelle die Erklärung zu den einzelnen Kennwortrichtlinien.

Richtlinie

Beschreibung

Kennwort muss Komplexitätsvoraussetzungen entsprechen

Mithilfe dieser Richtlinie können Administratoren fordern, dass Benutzer

komplexe

Kennwörter

konstruieren,

die

aus

Groß-

/Kleinbuchstaben, Ziffern und Sonderzeichen bestehen müssen. Das Kennwort „smart“ beispielsweise würde die Vorgaben nicht erfüllen, wogegen „password123$“ bei aktivierter Richtlinie von Benutzern vergeben werden könnte. Standardeinstellung: In der Default Domain Policy ist diese Richtlinie aktiviert, auf einem lokalen Windows Vista-Gerät hingegen deaktiviert. Empfohlene Einstellung: Diese Richtlinie sollte unbedingt aktiviert werden, damit Benutzer sichere Kennwörter wählen. Wenn diese Richtlinie nicht aktiviert wird, werden Benutzer Kennwörter wie Fe-

266

10.3 Kennwortrichtlinien und Kontosperrung rien, Insel, Sommer usw. wählen, die einerseits sehr einfach zu erraten sind und andererseits mit geeigneten Werkzeugen in weniger als einer Sekunde geknackt werden können. Kennwortchronik erzwingen

Die Kennwortchronik stellt sicher, dass Benutzer bei einer Kennwortänderung das neue Kennwort nicht identisch zum alten festlegen. Administratoren können hierzu einen Wert angeben, der festlegt, wie viele Benutzerkennwörter pro Benutzerkonto in der Chronik aufbewahrt werden sollen, um Benutzer daran zu hindern, immer wieder die gleichen Kennwörter zu nutzen. Standardeinstellung: In der Default Domain Policy ist dieser Wert auf 24 voreingestellt, auf einem lokalen Windows Vista-Gerät ist die Richtlinie deaktiviert. Empfohlene Einstellung: Eine Kennwortchronik zu führen macht absolut Sinn. Dazu sollte immer der höchstmöglich konfigurierbare Wert von 24 verwendet werden.

Kennwörter mit umkehrbarer Verschlüsselung speichern

In einer Benutzerdatenbank werden nicht Kennwörter, sondern Kennworthashes gespeichert. Wird diese Richtlinie aktiviert, werden Kennwörter verschlüsselt gespeichert. Anders als beim HashingVerfahren ist die Verschlüsselung umkehrbar, wenn jemand im Besitz des korrekten Schlüssels ist. Wenn ein Angreifer an diese verschlüsselten Kennwortinformationen kommt, ist es somit um einiges einfacher, daraus das Benutzerkennwort zu generieren, als dies mit einem Kennworthash möglich ist. Standardeinstellung: Deaktiviert Empfohlene Einstellung: Aus Sicherheitsgründen sollte auf Mechanismen verzichtet werden, die eine verschlüsselte Kennwortspeicherung fordern, und die Richtlinie daher deaktiviert werden.

Maximales Kennwortalter

Diese Richtlinie legt fest, wie häufig Benutzer ihre Kennwörter ändern müssen. Eine regelmäßige Änderung ist notwendig, um sicherzustellen, dass Kennwörter von Angreifern nicht innerhalb kürzester Frist ausfindig gemacht und anschließend genutzt werden können. Standardeinstellung: 42 Empfohlene Einstellung: Sie werden von Ihren Arbeitskollegen vermutlich nicht zum Mitarbeiter des Monats gewählt, wenn Sie den Wert für diese Richtlinie zu tief ansetzen. Für Benutzer sind Kennwörter meistens einfach nur lästig, und die Idee hinter einem regelmäßigen Kennwortwechsel wird den meisten nicht klar sein. Eine gute Balance zwischen Sicherheit und Benutzerfreundlichkeit kann erreicht werden, wenn ein Wert zwischen 30 und 90 Tagen verwendet wird.

267

10 Benutzerkonten und Kennwörter Richtlinie

Beschreibung

Minimale Kennwortlänge

Ein Kennworthash weist immer genau die gleiche Länge auf, unabhängig davon, wie viele Ziffern oder Buchstaben für ein Kennwort verwendet werden. Kurze Kennwörter können aber einfacher erraten werden, weshalb unbedingt eine minimale Kennwortlänge gefordert werden sollte. Standardeinstellung: 0 Empfohlene Einstellung: Kennwörter sollten aus mindestens acht Zeichen konstruiert werden, um sicherzustellen, dass ein Erraten nicht zu einfach wird. Zudem wird so sichergestellt, dass bei einer allfälligen Übertragung des LM-Hashes das Kennworts über das Netzwerk (falls dies überhaupt erfolgt, weil diese Einstellung bei Windows Vista bekanntlich deaktiviert ist) für einen Angreifer nicht sofort ersichtlich ist, ob ein Kennwort kürzer als acht Zeichen ist. Diese Information ist sehr interessant, um ein Kennworthash anzugreifen und das korrekte Kennwort eines Benutzers ausfindig zu machen.

Minimales Kennwortalter

Diese Richtlinie legt fest, wie alt ein Kennwort sein muss, bevor es vom Benutzer gewechselt werden kann. Benutzer tendieren dazu, immer die gleichen Kennwörter zu verwenden. Mithilfe der Einstellungen Kennwortchronik erzwingen und Maximales Kennwortalter kann ein Administrator genau das verhindern. Findige Benutzer könnten daher auf die Idee kommen, bei Erreichen des maximalen Alters ihr Kennwort mehrmals nacheinander zu ändern, sodass sie zum Schluss wieder das ursprüngliche Kennwort verwenden können. Standardeinstellung: 0 Empfohlene Einstellung: Sinnvollerweise verwenden Sie für diese Richtlinie einen Wert von mindestens 1, um sicherzustellen, dass Benutzer nicht mehrmals täglich eine Kennwortänderung durchführen und so die konfigurierte Kennwortchronik umgehen können.

Bei Sicherheits- und Kennwortaudits zeigt sich immer ein ähnliches Bild: Während sich Benutzer an die vorgegebenen Kennwortrichtlinien halten müssen, tun dies Administratoren nicht. Obwohl diese über die höchsten Berechtigungen für die Administration und daher über die sensitivsten Kennwörter verfügen, wechseln viele Administratoren ihre Kennwörter viel zu selten. Bei solchen Audits habe ich selber Administratorenkennwörter geprüft, die mehr als zwei, teilweise drei Jahre nicht mehr geändert worden sind. Die Auswirkungen dieses Verhaltens könnten fatal sein. Sie sollten die Option Kennwort läuft nie ab auf allen Administrationskonten schnellstens löschen und sich dem vorgegebenen Zyklus für die Kennwortänderung anschließen.

268

10.3 Kennwortrichtlinien und Kontosperrung Neben Kennwortrichtlinien können auch sog. Kontosperrungsrichtlinien eingesetzt werden, bei deren Bestimmung oft größere Diskussionen ausgelöst werden. Das eine Lager befürwortet diese Richtlinien, weil damit erreicht werden kann, dass Benutzerkonten gesperrt werden, wenn das zugehörige Kennwort zu oft falsch eingegeben worden ist. Ist ein Konto erst einmal gesperrt, ist eine Anmeldung nicht mehr möglich, selbst dann nicht, wenn das korrekte Kennwort eingegeben wird. Somit kann verhindert werden, dass Angreifer Kennwörter von Benutzern ausprobieren können, um so möglicherweise irgendwann auf das korrekte Kennwort zu stoßen. Das hört sich so weit eigentlich gar nicht so schlecht an, aber trotzdem gibt es auch viele Gegner dieser Einstellung. Leider ist diese Einstellung aber anfällig gegenüber Denial-of-Service-Angriffen, weil ein Angreifer mithilfe eines simplen Skripts versuchen könnte, viele oder sogar alle Konten einer Active DirectoryDomäne durch mehrfache, falsche Kennworteingaben zu sperren. Wenn das lediglich einmal vorkommt, wäre das einfach nur unangenehm, wenn der DoS-Angriff aber mehrmals täglich vorkommt, absolut tragisch. Kontensperrungsrichtlinien werden am gleichen Ort wie die Kennwortrichtlinien konfiguriert. Ich rate aus den erwähnten Gründen jeweils vom Einsatz dieser Richtlinie ab, weil das Risiko eines DoS-Angriffs schlicht zu groß ist und Benutzerkonten und -kennwörter gut genug geschützt sind, wenn eine starke Kennwortrichtlinie eingesetzt wird. Dann allerdings sollten Sie sicherstellen, dass Anmeldeversuche an Ihren Systemen überwacht werden, um auffällige Muster, also viele fehlgeschlagene Anmeldungen, erkennen zu können. Die Windows-Überwachungsfunktion wurde bereits in einem früheren Kapitel beschrieben. Möglicherweise entscheiden Sie sich aber trotzdem dafür, diese Funktion einzusetzen, deshalb ist es wichtig, die Möglichkeiten der Kontosperrung zu kennen. Folgende Tabelle gibt Aufschluss:

Richtlinie

Beschreibung

Kontensperrungsschwelle

Diese Richtlinie legt fest, nach welcher Anzahl falscher Kennworteingaben ein Konto gesperrt wird. Je kleiner der eingesetzte Wert ist, desto früher erfolgt die Sperrung eines Benutzerkontos. Standardeinstellung: 0 (deaktiviert) Empfohlene Einstellung: Wie bereits erwähnt, würde ich empfehlen, diese Funktion nicht zu verwenden und daher den Wert 0 zu wählen. Bei dieser Einstellung werden Benutzerkonten niemals gesperrt. Möchten Sie die Funktion der Kontensperrung für Ihr Firmennetzwerk dennoch verwenden, ist ein Wert von 4–8 sinnvoll.

Kontosperrdauer

Wenn ein Konto gesperrt wird, kann mit dieser Richtlinie angegeben werden, ob und wann das Konto automatisch wieder entsperrt wird oder ob eine manuelle Entsperrung durch einen Administrator erfolgen muss. Standardeinstellung: nicht definiert

269

10 Benutzerkonten und Kennwörter Empfohlene Einstellung: Wenn die Kontensperrung eingesetzt wird, sollte dieser Wert verhältnismäßig tief gesetzt werden. Dadurch wird sichergestellt, dass ein Konto bei einer allfälligen Sperrung innerhalb nützlicher Frist wieder zur Verfügung steht, ohne dass ein Eingriff durch einen Administrator notwendig wird. Mit einem tiefen Wert ist Ihr Netzwerk daher weniger anfällig gegen DoS-Angriffe. Ein optimaler Wert liegt zwischen fünf und 30 Minuten Zurücksetzungsdauer des Kontosperrungszählers

Diese Richtlinie legt fest, wann der Zähler für fehlerhafte Kennworteingaben für Benutzerkonten wieder auf 0 zurückgesetzt wird. Der Wert darf nicht größer als die konfigurierte Kontensperrdauer sein. Standardeinstellung: nicht definiert Empfohlene Einstellung: Sinnvollerweise verwenden Sie für die Rücksetzung des Zählers einen Wert zwischen 30 und 240 Minuten. Diese Werte sind allerdings nur dann möglich, wenn die Kontosperrdauer ebenfalls mindestens diese Werte aufweist. Ansonsten verwenden Sie den Wert, den Sie für die Kontosperrdauer festgelegt haben.

Gesperrte Konten können nach bestimmter Zeit automatisch oder manuell durch Administratoren entsperrt werden. Bei letzter Variante erfolgt dies direkt über die Eigenschaften des jeweiligen Benutzerkontos – je nach Benutzerkonto über die lokale Benutzerverwaltung oder in der Active Directory-Domänenverwaltung. Dabei muss lediglich die Option „Konto gesperrt“ gelöscht werden, um das Konto wieder freizugeben.

Abbildung 10.5 Lokale Konten und Domänenkonten entsperren

270

10.4 Dienstkonten

10.4

Dienstkonten Von Angreifern häufig attackiert werden Dienstkonten (Service Accounts), die dazu verwendet werden, bestimmte Dienste zu starten und auszuführen. Diese werden lokal oder in der Domänendatenbank erfasst, mit einem komplexen Kennwort versehen und so konfiguriert, dass deren Kennwort nie abläuft – was in diesem Fall unumgänglich und legitim ist, wenn das verwendete Kennwort sehr komplex ist. Bei Dienstkonten werden in Netzwerken aber immer wieder die gleichen Fehler beobachtet. Dienstkonten benötigen für die korrekte Ausführung des Dienstes bestimmte Rechte. Teilweise werden diese Rechte automatisch vergeben, wenn eine neue Anwendung implementiert wird, die Dienstkonten verwendet. Oft müssen aber Administratoren die Rechte für die eingesetzten Dienstkonten vergeben. Wie bei Benutzerkonten auch müsste hier das „Least Privilege“-Prinzip gelten, d.h., Dienstkonten sollten nur genau diese Rechte zugewiesen werden, die sie effektiv benötigen, und nicht mehr. Der Aufwand, die notwendigen Rechte zu vergeben, ist teilweise sehr groß, weshalb viele Administratoren dazu neigen, Dienstkonten der Gruppe Domänen-Admins hinzuzufügen. Dadurch wird natürlich erreicht, dass ein Dienstkonto alle notwendigen Rechte besitzt und den Dienst korrekt ausführen kann, aber natürlich ist diese Methode in Bezug auf die Sicherheit von Systemen wiederum sehr schlecht und sollte wenn irgendwie möglich vermieden werden. Ein zweites Problem liegt darin, dass für verschiedene Dienste die gleichen Dienstkonten (und daher natürlich auch die gleichen Kennwörter) verwendet werden. Wenn ein Dienstkonto erst einmal erfolgreich kompromittiert worden ist, hat ein Angreifer so sehr einfach die Möglichkeit, auch andere Dienste ohne Mehraufwand zu manipulieren. Auch oft beobachtet wird, dass unterschiedliche Dienstkonten verwendet werden, allerdings immer die genau gleichen Kennwörter genutzt werden. Das ist schon ein bisschen besser und erhöht die Sicherheit, allerdings nur minimal. Besser wäre es, für jeden Dienst unterschiedliche Dienstkonten mit unterschiedlichen und komplexen Kennwörtern zu verwenden, sodass Angriffe und deren Ausbreitung massiv erschwert werden.

10.5

Ausbildung, Ausbildung, Ausbildung Was bringen Kennwörter, wenn Benutzer diese an andere Personen weitergeben? Was, wenn Kennwörter auf einen Zettel geschrieben und dieses gut sichtbar am Monitor angebracht werden? Viele Benutzer erachten ein Kennwort als mühsam oder sogar als reine Schikane und würden am liebsten ganz darauf verzichten. Sie erkennen nicht, welche Zwecke Kennwörter tatsächlich erfüllen, und schon gar nicht die Auswirkungen, wenn ein Kennwort in fremde Hände gerät. Benutzer müssen demnach für den korrekten Umgang mit Kennwörtern geschult werden. Sie müssen wissen, wozu Kennwörter genutzt und welche Informationen damit geschützt werden. Und sie müssen wissen, an wen sie ihre persönlichen Kennwörter weitergeben dürfen, nämlich an gar niemanden, eigentlich nicht einmal an Administratoren – Kennwörter sind persönlich.

271

10 Benutzerkonten und Kennwörter In Nutzungsreglements oder Sicherheitsrichtlinien sollten solche Themen daher unbedingt berücksichtigt und bei unsachgemäßer Handhabung auf entsprechende Konsequenzen hingewiesen werden. Regelmäßige Wiederholungen der Schulungen fördern den sicheren Umgang mit Kennwörtern und bringen Ihrem Netzwerk einen zusätzlichen, sehr wichtigen Sicherheitsschub.

10.6

Rückblick Von Kennwörtern ist die Sicherheit von Systemen abhängig. Als Administrator müssen Sie daher sicherstellen, dass Kennwörter sicher gespeichert und aufbewahrt, aber auch sicher über das Netzwerk übertragen werden. Zudem liegt es in Ihrer Aufgabe, Benutzer beim Umgang mit Kennwörtern auszubilden. Alles in allem eine nicht ganz einfache Aufgabe, wenn man bedenkt, in welchen Bereichen überall Kennwörter eingesetzt werden. Windows Vista hat die Sicherheit für die Kennwortaufbewahrung und -übertragung gegenüber früheren Microsoft-Betriebssystemen verbessert. Trotzdem gibt es immer noch einige wichtige Punkte zu beachten und teilweise manuelle Konfigurationen vorzunehmen. So sollten Sie in jedem Fall eine geeignete Kennwortrichtlinie einführen, um starke Kennwörter technisch zu erzwingen. Denken Sie daran, dass auch Administratoren sich an diese Richtlinien halten sollten, um diejenigen Konten mit den höchsten Rechten optimal zu schützen.

272

11 Verschiedene Sicherheitseinstellungen In den letzten Kapiteln haben wir bereits viele mächtige Sicherheitsfunktionen behandelt, die sich teilweise sehr umfangreich konfigurieren lassen. Windows Vista bietet aber noch viele weitere, nicht ganz so umfangreiche Funktionen, um den Schutz des Betriebssystems und Benutzerdaten zu verbessern. Viele dieser Funktionen sind nicht kapitelfüllend und daher in diesem Kapitel zusammengefasst. Sie sollten auch diesen Funktionen höchste Aufmerksamkeit schenken, weil einige davon tatsächlich entscheidend sein können, um ein System mit dem letzten Quäntchen Sicherheit zu versehen.

11.1

Kernel Patch Protection (PatchGuard) Diese Sicherheitsfunktion ist nicht ganz so populär und auch bereits in früheren WindowsVersionen (Windows XP 64 Bit, Windows Server 2003 SP1 64 Bit) enthalten. Trotzdem schafft sie es immer wieder in die Schlagzeilen und Diskussionsforen, weil einige Hersteller – speziell von Antiviren- und Anti-Malware-Software – damit ihre liebe Mühe haben. Was aber ist genau „Kernel Patching“, und weshalb sollte man sich davor schützen? Beim Windows Vista-Kernel (bzw. allgemein bei Kerneln) handelt es sich um das Herzstück des Betriebssystems. Der Kernel ist dafür zuständig, die Basisdienste des Betriebssystems bereitzustellen, und dient als Basis für sämtliche Dienste, Anwendungen, aber auch Geräte (Hardware), die auf einem System eingesetzt werden. Wenn im Kernel Fehler auftreten, kann dies folglich weitreichende Auswirkungen auf das gesamte Betriebssystem haben und die Sicherheit, aber auch die Stabilität beeinträchtigen. Weil durch einen unautorisierten Eingriff in den Kernel auch unbemerkt Änderungen an der Sicherheitsarchitektur vorgenommen werden können, muss er besonders geschützt werden. Kernel Patch Protection hat die Aufgabe, sog. „Kernel Patching“, also das Ändern (und vor allem das unautorisierte Ändern) von Kernelcode zu verhindern. Angreifer können diese Methode beispielsweise nutzen, um Rootkits auf einem System zu implementieren, die dann von Virenscannern oder Anti-Malware-Tools nicht erkannt werden können. Um dies

273

11 Verschiedene Sicherheitseinstellungen zu verhindern, ermöglicht Microsoft Softwareanbietern nicht, Änderungen direkt am Kernel vorzunehmen. Das gilt nicht nur für Software von Drittherstellern, sondern auch für Software und Werkzeuge von Microsoft selber. Anwendungen müssen für die Kommunikation mit Kernel-Komponenten die dafür bereitgestellten Schnittstellen nutzen, weshalb es sein kann, dass Anwendungen nicht mehr korrekt funktionieren. Wird trotzdem versucht, eine direkte Änderung am Kernel vorzunehmen, wird das System heruntergefahren und neu gestartet. Natürlich lässt sich diese Funktion nicht ausschalten, und das bedeutet, dass solche Anwendungen den neuen Richtlinien von Microsoft angepasst werden müssen. Dass einige Hersteller von Software über diesen Kernelschutz nicht sehr erfreut sind, ist nachvollziehbar. Wenn man allerdings das Schutzpotenzial dahinter erkennt, ist es seitens Microsoft sicher ein weiterer Schritt in die richtige Richtung. Mit einem Zähneknirschen muss man leider akzeptieren, dass diese Funktion bei 32-BitSystemen nicht zur Verfügung steht. Da Windows Vista allerdings das letzte 32-BitClientbetriebssystem von Microsoft ist, wird sich dies hoffentlich bei der nächsten Generation erledigt haben, sodass diese Funktion spätestens dann für alle Installationen zur Verfügung steht.

11.2

Code-Integrität Der beste Schutz eines Systems ist wertlos, wenn manipulierte Systemdateien geladen werden. Mithilfe von Integritätsprüfungen stellt Windows Vista daher sicher, dass die korrekten und unveränderten System- und Kerneldateien geladen werden, wodurch es nicht mehr möglich ist, unbemerkt kritische Dateien zu ersetzen. Durch gezieltes Ändern solcher System- oder Kernelkomponenten könnte ein Angreifer das Verhalten des Betriebssystems zu seinen Gunsten ändern und unbemerkt Aktivitäten ausführen. Damit Windows Vista solche unerwünschten Veränderungen erkennen kann, wird beim Laden von Systemdateien und Kernelkomponenten jeweils deren Hash überprüft. Wenn sich eine Datei unbemerkt verändert hat, wird dies beim Laden der Komponente entdeckt und der Ladevorgang unterbrochen. Ein Hash ist ein verhältnismäßig kurzer Wert, der aus einer größeren Datenmenge – z.B. aus den Inhalten einer Datei – generiert wird. Solange sich diese Datenmenge nicht verändert, wird immer der genau gleiche Hashwert erzeugt. Ändert sich die Datenmenge hingegen, wird ein neuer, komplett unterschiedlicher Hashwert erzeugt. Ein Hashwert eignet sich demnach optimal, um zwei Datenmengen miteinander zu vergleichen. Dazu werden die Daten lediglich mit dem gleichen Algorithmus behandelt und die daraus resultierenden Hashwerte verglichen. Sind diese identisch, sind auch die vergleichenden Dateien identisch. Sind die Hashwerte hingegen unterschiedlich, weisen die Daten Differenzen auf. Genau das gleiche Verfahren verwendet Windows Vista, um sicherzustellen, dass Systemdateien nicht verändert worden sind. Ist ein Hashwert beim Laden einer Datei anders, als

274

11.3 Address Space Layout Randomization (ASLR) das Betriebssystem es erwartet, geht Windows Vista davon aus, dass diese Datei verändert worden ist, und wird den Ladevorgang verhindern. Falls einige Dienste und Treiber nach dem Startvorgang nicht geladen sind, ist dies in der Ereignisanzeige sichtbar. Microsoft stellt dazu zwei Protokollierungsdateien zur Verfügung, um Informationen des Bereichs Codeintegrität konsolidiert darzustellen. Die ausführliche Protokollierung (Verbose) muss für die Nutzung manuell aktiviert werden, was allerdings nur dann notwendig ist, wenn größere Probleme im Zusammenhang mit der Integritätsprüfung auftreten.

Abbildung 11.1 Ereignisanzeige der Codeintegrität

11.3

Address Space Layout Randomization (ASLR) Unter Windows Vista werden beim Systemstart viele der zu ladenden Betriebssystemkomponenten in zufälliger Reihenfolge geladen und im RAM gespeichert. Dadurch ist nicht mehr bekannt, in welchem Bereich des RAM sich welche Module befinden, was es einem Programm mit bösartigen Absichten bzw. einem Angreifer wiederum erschwert, dasjenige Modul zu finden, das verändert werden soll oder für das ein Buffer-Overflow-Angriff ausgeführt werden soll. In früheren Betriebssystemen war die Ladereihenfolge immer gleich, d.h., Module befanden sich immer in der gleichen Reihenfolge im Arbeitsspeicher, womit

275

11 Verschiedene Sicherheitseinstellungen einem Angreifer bereits wichtige Informationen über den genauen Aufenthaltsort des anzugreifenden Codes bekannt waren. Das Planen und Ausführen eines Angriffs war dadurch wesentlich einfacher, als dies unter Windows Vista der Fall ist.

11.4

Remotedesktopverbindungen Damit ein Administrator ein Windows Vista-Gerät mittels Remotedesktop übernehmen kann, muss diese Funktion erst einmal über die erweiterten Systemeigenschaften aktiviert werden. Was hierbei neu ist, wird schnell ersichtlich: In früheren Windows-Versionen kann Remotedesktop lediglich aktiviert oder deaktiviert werden. Windows Vista bietet aber zwei unterschiedliche Sicherheitsebenen für die Bereitstellung von Remotedesktop. Im klassischen Fall verbindet sich ein Benutzer oder Administrator mittels RDP (Remote Desktop Protocol) mit einem anderen Gerät (Windows Vista oder ein WindowsServerbetriebssystem) und gelangt auf die Oberfläche. Dort wird ein Anmeldefenster präsentiert, über das die Authentifizierung erfolgt. Die eingegebenen Informationen werden verifiziert und dem Benutzer der Zugriff gewährt. Das Problem bei diesem klassischen Verbindungsaufbau ist die Tatsache, dass ein System auf Anfragen antwortet, obwohl noch nicht sichergestellt werden kann, ob derjenige, der eine Verbindung aufbauen möchte, auch tatsächlich berechtigt ist, dies zu tun, und über gültige Anmeldeinformationen verfügt. Besser ist der Ansatz, zuerst eine Authentifizierung durchzuführen und erst dann den Zugriff zum gewünschten System zu realisieren. Dieser Ansatz schützt aber auch den Benutzer, der die Verbindung herstellt. Stellen Sie sich vor, Sie möchten sich an einem anderen System mittels Remotedesktop verbinden. Sie geben den Namen des Systems ein und sehen nach kurzer Wartezeit den Anmeldeschirm des gewünschten Systems. Sie geben Benutzernamen und Kennwort ein und erhalten anschließend die Meldung, dass Sie nicht erfolgreich angemeldet werden konnten. Nun, was ist, wenn Sie sich gar nicht auf dem gewünschten System befinden, sondern von einem Angreifer auf ein anderes System umgeleitet worden sind? Sie haben soeben Ihre gültigen Anmeldeinformationen eingegeben, die vermutlich aufgezeichnet worden sind und nun verwendet werden können, um im Netzwerk Ihre Identität anzunehmen. Kein besonders schöner Gedanke, oder? Was kann Windows Vista gegen diese Probleme tun? Für eingehende Verbindungen stehen dazu zwei unterschiedliche Möglichkeiten zur Verfügung, um Remotedesktopverbindungen anzunehmen und zu verarbeiten.

276

11.4 Remotedesktopverbindungen

Abbildung 11.2 Eingehende Remotedesktopverbindungen aktivieren

Einstellung

Beschreibung

Keine Verbindung mit diesem Computer zulassen

Wie die Bezeichnung der Einstellung bereits vermuten lässt, werden

Verbindungen von Computern zulassen, auf denen eine beliebige Version von Remotedesktop ausgeführt wird (weniger Sicherheit)

Wird diese Option aktiviert, werden Remotedesktopverbindungen un-

Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird (mehr Sicherheit)

Um höchstmögliche Sicherheit zu erreichen, sollte diese Option akti-

bei dieser Option keine Remotedesktopverbindungen zugelassen.

abhängig von der eingesetzten RDP-Clientversion zugelassen.

viert werden. Dadurch wird sichergestellt, dass eine Verbindung erst dann hergestellt werden kann, wenn die angegebenen Anmeldeinformationen des Benutzers bzw. Administrators erfolgreich überprüft worden sind. Wichtig hierbei ist, dass ein RDP-Client eingesetzt wird, der Sicherheit auf Netzwerkebene unterstützt, d.h., der mindestens über die Version 6.0 des Microsoft RDP-Clients verfügt.

277

11 Verschiedene Sicherheitseinstellungen Um clientseitig eine Vorauthentifizierung realisieren zu können, benötigen Sie die Version 6 des Microsoft RDP-Clients. In Windows Vista ist dieser bereits enthalten, für frühere Betriebssystemversionen steht er über die Microsoft-Webseite zum Download bereit. Nach erfolgtem Start lassen sich über den Reiter Leistung verschiedene Einstellungen zur Authentifizierung an Server vornehmen.

Abbildung 11.3 Ausgehende Remotedesktopverbindungen konfigurieren

Einstellung

Beschreibung

Immer verbinden, auch wenn Authentifizierung fehlschlägt

Diese Option stellt eine Verbindung auch bei fehlgeschlagener

Warnung anzeigen, falls Authentifizierung fehlschlägt

Wenn die Vorauthentifizierung fehlschlägt – beispielsweise wenn Sie

Vorauthentifizierung her, sofern das Zielsystem das zulässt.

auf ein anderes System umgeleitet worden sind, auf dem jemand versucht, an Ihre Anmeldeinformationen zu kommen –, wird eine Warnmeldung angezeigt. Sie können selber entscheiden, ob die Verbindung trotzdem hergestellt werden soll oder nicht. Eine Verbindungsherstellung ist allerdings nur möglich, wenn das Zielsystem das zulässt. Wenn Sie eine Verbindung zu einem Windows Vista-Gerät herstellen, unterstützt dieses eine Vorauthentifizierung. Stellen Sie hingegen eine Verbindung zu einem Windows Server-Betriebssystem her, wird die Vorauthentifizierung immer fehlschlagen und bei dieser Option eine Warnmeldung anzeigen. Serverseitig wird die Vorauthentifizierung erst ab Windows Server 2008 unterstützt. Diese Option ist unter Windows Vista standardmäßig aktiviert.

Keine Verbindung, wenn Authentifizierung fehlschlägt

278

Wenn diese Option aktiviert ist, wird eine Fehlermeldung angezeigt und der Verbindungsaufbau abgebrochen.

11.5 Software Restriction Policies

Abbildung 11.4 Fehlermeldungen bei der Authentifizierung auf Netzwerkebene

Natürlich stellt Windows sicher, dass keine doppelte Anmeldung an Systemen erforderlich wird. Dazu werden die Anmeldeinformationen, die bereits durch die Vorauthentifizierung verifiziert worden sind, zum Zielsystem weitergegeben, um die Authentifizierungzu realisieren.

11.5

Software Restriction Policies Um zu verhindern, dass Programme auf einem System genutzt werden, können Richtlinien für Softwareeinschränkungen eingesetzt werden. Administratoren haben die Möglichkeit, die Ausführung sämtlicher Programme grundsätzlich zu verhindern und explizit zu definieren, welche Anwendungen ein Benutzer starten darf. Wenn bekannt ist, welche Programme von Benutzern benötigt werden, können genau diese freigegeben werden. Programmstarts und –installationen, die von einem Benutzer oder durch einen anderen Prozess (beispielsweise durch einen Trojaner) initiiert werden, bleiben erfolglos. Der zweite und weniger restriktive Ansatz lässt die Ausführung von Programmen grundsätzlich zu, allerdings können explizit festgelegte Programme blockiert werden. Die Konfiguration erfolgt mithilfe von Gruppenrichtlinien wahlweise lokal oder über eine Domäne. Navigieren Sie dazu zum Bereich Computerkonfiguration\WindowsEinstellungen\Sicherheitseinstellungen\Richtlinie für Softwareeinschränkung. Vor der effektiven Konfiguration muss zuerst aber noch eine neue Richtlinie erstellt werden.

279

11 Verschiedene Sicherheitseinstellungen

Abbildung 11.5 Richtlinien für Softwareeinschränkungen

Nach der Aktivierung der Richtlinie müssen einige Basiseinstellungen vorgenommen werden, die über die Objekte Erzwingen, Designierte Dateitypen und Vertrauenswürdige Herausgeber zur Verfügung stehen.

Abbildung 11.6 Basiskonfiguration

280

11.5 Software Restriction Policies Erzwingen

Beschreibung

Richtlinien für Softwareeinschränkung anwenden auf

Administratoren können mithilfe dieser Option festlegen, ob tatsächlich alle

Richtlinien für Softwareeinschränkung auf folgende Benutzer anwenden

Mit der Option „Alle Benutzer“ werden Einschränkungen tatsächlich für alle

Softwaredateien von einer Richtlinie betroffen werden oder ob bestimmte ausgeschlossen (z.B. DLLs) werden sollen.

Benutzer aktiviert, auch für Administratoren eines lokalen Systems. Ist das nicht gewünscht, sprich sollen lokale Administratoren von Richtlinien für Softwareeinschränkungen ausgeschlossen werden, kann die Option „Alle Benutzer außer den lokalen Administratoren“ verwendet werden.

Beim Anwenden von Richtlinien für Softwarebeschränkung

„Zertifikatsregeln ignorieren“ bedeutet, dass keine Programme mithilfe von Zertifikatsregeln zugelassen oder verweigert werden können, diese Regeltypen sind also standardmäßig deaktiviert. Möchten Sie diese Art von Programmidentifikationen jedoch anwenden, muss die Option „Zertifikatsregeln erzwingen“ verwendet werden.

Designierte Dateitypen

Beschreibung

Erweiterungen festlegen

In diesem Fenster kann festgelegt werden, für welche Dateitypen die konfigurierten Softwareeinschränkungen Gültigkeit haben. Nur diese Dateitypen werden von Richtlinien verarbeitet. Dateien mit nicht aufgeführten Endungen werden nicht berücksichtigt.

Dateierweiterung

Falls ausführbare Dateien mithilfe einer Richtlinie kontrolliert werden sollen, die standardmäßig nicht in der Liste enthalten sind, können diese jederzeit nachträglich in der Liste aufgenommen werden.

Vertrauenswürdige Herausgeber

Beschreibung

Vertrauenswürdige Herausgeber

Über die drei verfügbaren Optionen lässt sich festlegen, wer Zertifikatsaussteller als vertrauenswürdig einstufen darf. Diese Entscheidung kann unter Umständen sehr kritisch sein, weshalb Sie hierfür Benutzer nicht vorsehen sollten.

Überprüfung des Zertifikats

Mit diesen Optionen kann festgelegt werden, ob und wie Zertifikate bei eingesetzten Zertifikatsregeln überprüft werden sollen. Das lokale System kann prüfen, ob digital signierte Programme mit einem gültigen Zertifikat signiert worden sind, das nicht gesperrt worden ist. Auch der Zeitstempel, d.h. die Gültigkeitsdauer des verwendeten Zertifikats, kann geprüft werden.

Um die Sicherheit eines Systems zu erhöhen, kann es durchaus Sinn machen, nur genau diejenigen Programme zuzulassen, die effektiv benötigt werden, und alles andere zu blockieren. Dadurch wird es enorm schwierig, unbemerkt Dateien auf einem System erfolg-

281

11 Verschiedene Sicherheitseinstellungen reich auszuführen, wodurch wiederum die Sicherheit, aber auch die Stabilität verbessert werden. Natürlich schränkt man sich beim Einsatz dieser Technologie ein, aber es ist möglich, mit einem gesunden Aufwand-Nutzen-Verhältnis ein relativ hohes Maß an Sicherheit zu implementieren und gleichzeitig die Nutzbarkeit nicht außer Acht zu lassen. Bevor nun mit dem Erstellen von Regeln begonnen wird, muss festgelegt werden, ob das System grundsätzlich alle Programme an der Ausführung hindert oder ob alle Programme gestartet werden dürfen. Diese Konfiguration erfolgt über das Objekt Sicherheitsstufen.

Abbildung 11.7 Konfiguration der gewünschten Sicherheitsstufe

Sicherheitsstufe

Beschreibung

Nicht erlaubt

Wenn grundsätzlich alle Programme blockiert werden sollen, kann diese Richtlinie verwendet werden. Mit zusätzlichen Regeln können anschließend einzelne Programme explizit zugelassen werden.

Standardbenutzer

Wird diese Option gewählt, können Mitglieder der Gruppe Standardbenutzer Software ausführen, andere Benutzer hingegen nicht.

Nicht eingeschränkt

Diese standardmäßig ausgewählte Option lässt die Ausführung von Programmen uneingeschränkt zu. Mithilfe von Ausnahmen müssen Programme, die blockiert werden, explizit angegeben werden.

282

11.5 Software Restriction Policies Über das Objekt Zusätzliche Regeln können jederzeit neue ausführbare Dateien oder Programme mit einer Regel identifiziert werden, um die Richtlinie für Softwareeinschränkung zu erweitern.

Abbildung 11.8 Zusätzliche Regeln erstellen

Identifikation

Beschreibung

Pfadregel

Ein Programm kann aufgrund der ausführbaren Datei und des Speicherorts eindeutig identifiziert werden. Mit Pfadregeln können aber auch ganze Pfade, also Ordner oder Registrierungsschlüssel, angegeben werden, sodass die Programme, die sich darin befinden, von der Regel erfasst werden. Diese Regelart eignet sich daher besonders für Situationen, in denen grundsätzlich alle Programme blockiert werden und nur einige wenige tatsächlich ausgeführt werden dürfen. Zur Ausführungsverhinderung ist diese Identifikation nicht geeignet, da ein simples Verschieben einer ausführbaren Datei dazu führt, dass diese nicht mehr von der Pfadregel erkannt wird und dann vom Benutzer ausgeführt werden kann.

Hashregel

Zum expliziten Verweigern von Programmen eignet sich die Identifikation mittels eine Hashwerts. Aus den Dateiinhalten wird ein Hash generiert, um ein Programm zu identifizieren. Der Vorteil dieser Regelart gegenüber Pfadregeln liegt darin, dass der Hash einer Datei immer gleich bleibt, auch dann, wenn

283

11 Verschiedene Sicherheitseinstellungen diese verschoben wird. Wenn findige Benutzer demnach blockierte Programme an einen anderen Ort verschieben oder kopieren, können diese immer noch nicht ausgeführt werden, sofern die Ausführungsverhinderung mit einer Hashregel realisiert wird. Falls eine ausführbare Datei allerdings aktualisiert wird, beispielsweise durch die Installation eines Service Packs, ändert sich auch der Hash, wodurch die Identifikation verloren geht. In einem solchen Fall müssen die eingesetzten Regeln angepasst werden. Zertifikatsregel

Mit Zertifikatsregeln kann sichergestellt werden, dass nur Programme ausgeführt werden dürfen, die mit einem digitalen Zertifikat eines vertrauenswürdigen Herstellers signiert worden sind. Dazu muss lediglich das entsprechende Zertifikat eines Softwareherstellers angegeben werden (cer-Datei). Da leider immer noch viele Dateien unsigniert verteilt und genutzt werden, wird diese Regelart weniger häufig eingesetzt.

Zonenregel

Zonenregeln dienen der Herkunftsidentifikation einer Software (nur .msiDateien) aus dem Internet. Dabei wird geprüft, zu welcher Sicherheitszone eine Webseite gehört, die ein ausführbares Programm zur Verfügung stellt. Auch diese Regeltypen kommen weniger häufig zum Einsatz.

Abbildung 11.9 Pfad- und Hashregeln erstellen

284

11.6 Rückblick

Abbildung 11.10 Zonen- und Zertifikatsregeln erstellen

Programme, die nicht eingeschränkt werden, können von Anwendern ganz normal ausgeführt werden. Wird hingegen ein Programm gestartet, dessen Ausführung durch eine Regel verhindert wird, wird eine aussagekräftige Fehlermeldung angezeigt.

11.6

Rückblick Nach diesen letzten Sicherheitsfunktionen habe ich Ihnen das notwendige Wissen vermittelt, mit dem Sie die Sicherheitsarchitektur von Windows Vista verstehen und vor allem nutzen können, um Systeme sicher zu konfigurieren. Dieses Wissen ist in der heutigen Zeit essenziell, weil Bedrohungen und Angriffe massiv zugenommen haben – und das wird sich auch in Zukunft nicht ändern.

285

Register 3 3DES 180, 195

Authentifizierungsmechanismus 261 Authentizität 185 Autoruns for Windows 228

8 802.1x 173

A Access Control Entries 75 Access Control List 75 Access Points 170 Access Token 11 Accesschk.exe 34 ACE 75 ACL 75 ActiveX Opt-In 54 ActiveX-Elemente 54, 67 Add-On-Manager 55 Address Space Layout Randomization 275 Add-TPMSelfWriteACE.vbs 130 Ad-Hoc 177 Administratorbestätigungsmodus 22 Administratorenkonten auflisten 27 Administratorenkonto 6 Admin-Token 11 ADMX-Dateien 164 ADSIedit.msc 131 AES 174, 180, 195 Anwendungsfilter 184 ASLR 275 Auditpol.exe 85 Ausbildung 271 Authentication Header 194

B Benutzerauthentifizierung 257 Benutzerdefinierte Geräteklassen 247 Benutzerkonten 257 Benutzerkontensteuerung 5 Besitzer 76 BitLocker 75, 116, 264 BitLocker Drive Preparation Tool 120 BitLocker-Kennwort-ID 131 BitLocker-Schlüsselspeicherung im Active Directory 128 BitLocker-Sicherheitsstufe Nur TPM-Chip 119 Nur USB-Stick 119 TPM und PIN 119 TPM und USB 119 BitLockerTPMSchemaExtension.ldf 129 BitLocker-Wiederherstellung 127 Blob 260 Brute-Force-Angriffen 258 Buffer-Overflow-Angriffe 275

C Certmgr.msc 92 Certutil.exe 108 Challenge 258 Code-Integrität 274 Computergruppen 154

287

Register Cookies 61 Cross-Domain-Scripting 52

D Data Decryption Field 88 Data Execution Prevention 55 Datei- und Registrierungsschreibfehler 23 Dateiausführungsverhinderung 55 Dateisystemvirtualisierung 14 Datenintegrität 185, 195 Datenschutzeinstellungen 61 Datenverschlüsselung 185, 195 DDF-Feld 88, 93 Denial-of-Service-Angriffe 269 DEP 55 DES-Schlüssel 195, 259 Development Lifecycle 3 Dienstisolation 237 Dienstkonten 233, 271 Diffie-Hellman-Standard 195 digitale Zertifikate 180 Dir.exe /a 79 DoS-Angriffe 269 DRF-Feld 93

E EAPoL 165 Echtzeitschutz 217 EFS 87 Einwegverfahren 257 Encapsulated Secure Payload 194 Encrypting File System 87 Enterprise-Firewalls 184 EV-Zertifikate 45

F Fast User Switching 242

G Geräteklasse-GUID 248 Geräteklasse-ID 248 Gpupdate.exe 159 Gruppenrichtlinieneinstellungen 245

288

H Hardware-ID 248 Hash 257 Hashregel 283 Hashwerte 258 Hauptmodus 195 HMAC-MD5-Algorithmus 260 HTTPS 45

I Icacls.exe 34 IDN 44 IE7-Demos 57 IEEE802.1x 165 Iexplore.exe 56 IIS 6 Resource Kit 149 IKE 195 Inhaltsverwaltung 64 Integritäts-Check 119 Integritätskontrolle 31 Integritätsprüfung 274 International Domain Name 44 Internet Explorer 7 43 ActiveX Opt-In 54 Adressleistensicherheit und IDNUnterstützung 44 Dateiausführungsverhinderung (Data Execution Prevention, DEP) 55 Geschützter Modus 56 Reduzierte Angriffsoberfläche 54 Sicherheitsstatusanzeige, Zertifikatsverwaltung und Phishing-Filter 45 Sicherheitszonen 58 Warnung bei unsicheren Einstellungen 52 Internet Key Exchange 195 IP-Filterlisten 207 IPsec 180 Authentication Header 194 Encapsulated Secure Payload 194 IPsec Modus Main Mode 195 Quick Mode 196 IPsec-Tunnel 202

Register IP-Sicherheitsmonitor 205 IP-Sicherheitsregel 206 IP-Sicherheitsrichtlinienverwaltung 205 Isolierung 202

K Kennwortalter Maximal 267 Minimal 268 Kennwort-Audits 259 Kennwortchronik 267 Kennwörter 257 Kennwort-ID 131 Kennwortlänge 268 Kennwortrichtlinien 265 Kennwortspeicherung 258 Kennwortübertragung 182 Kerberos-Ticket 260, 261 Kernel Patch Protection 273 Kernel Patching 273 Key Protector-Kombination 120 Key Protectors 119 Key Recovery Agent 101 Klartextkennwörter 258 Kompatibilitätsdateien 19 Komplexitätsvoraussetzungen 266 Kontensperrungsschwelle 269 Kontosperrung 265 Kontosperrungsrichtlinien 269 KRA 101

L L2TP 180 LAN-Verbindungen 165 Layer 2 Tunneling Protocol 180 ldifde.exe 129, 164 Least Privilege 271 Legacy-Anwendung 14 LM-Antworten 259 LM-Hash 259

M MAC-Adressfilterungen 165 MAC-Spoofing 165 Malware 213 manage-bde.wsf 126 Manifest 17 Master Keys 264 MD4-Algorithmus 260 MD5 195 Microsoft SpyNet 214, 224 Mklink.exe 80 MPPE 180 MS-CHAPv1/2 182 Msconfig.exe 27 msFVE-RecoveryPassword 131

N NAP 167 NAT-T 180 Network Access Protection 167 Network Location Awareness 185 Netzwerkbetrieb 163 Netzwerksicherheit Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern 262 LAN-Manager-Authentifizierungsebene 262 Netzwerktypen 186 Netzwerkverbindungen 163 NLA 185 No Execute Up 33 No Read Up 33 No Write Up 33 Nonce 260 NTFS-Dateisystem 73 NT-Hash 259 NTLM 260 NTLM-Antworten 260 NTLMv2-Antworten 260

O Offline-Angriffe 116

289

Register

P Partitionsverschlüsselung 116 PatchGuard 273 Patch-Management 137 Pfadregel 283 Phishing-Filter-Einstellung 50 Phishing-Webseite 46 Point-to-Point Tunneling Protocol 180 PPTP 180 Pre-Shared Keys 180 Process Explorer 39, 235 Profilbasierte Firewallkonfiguration 184

Q Quarantäne 226

R RADIUS-Server 165, 170 Rainbow-Tables 258 RC4-Verfahren 180 RDP 276 RDP-Vorauthentifizierung 278 Rechteerhöhung 9 Rechtevererbung 76 Regedit.exe 77 Registrierungsvirtualisierung 15 Relative ID 6 Remote Desktop Protocol 276 Remotedesktopverbindungen 276 RequestExecutionLevel 17 Richtlinien für Verbindlichkeitsstufen 32 RID 6 Rootkits 273

S SACL 33, 83 SAM 264 sc.exe 238 SCCM 2007 138, 217 SCE 2007 138, 217 Schnellmodus 196 SDL 54 Secuity Account Manager 264

290

Security Development Lifecycle 54 Security-ID 6 selfssl.exe 149 Service Accounts 233, 271 Session 0 242 SHA-1 195 Sicherer Desktop 23 Sicherer Netzwerkbetrieb 163 Sicherheits-ID 237 Sicherheitstoken 235 Sicherheitszonen 58 SID 6, 237 Sigcheck.exe 17 Signierer 253 sigverf.exe 254 SmartCards 257 Social Engineering 3 Software Restriction Policies 279 Software-Explorer 227 Split-Token-Prozess 40 Split-Token-Verfahren 12 SpyNet 214, 224 Spyware 213 SSID 173, 178 SSL 45 Standardbenutzerrechte 8 Standard-Token 11 Statusbehaftete Paketfilterung 184 svchost.exe 235 symmetrische Schlüssel 93 Syskey 264 System Access Control List 33 System Accounts 233 System Key 264 Systemkonten 233 Lokaler Dienst 234 Lokales System 234 Netzwerkdienst 234 Systemobjekte 76

T TCP 190 TKIP 174

Register TPM-Chip 119 Treiber 245 Treibersignaturen 253 TrustedInstaller 77

U UAC 5 Überwachung 74, 81 Anmeldeereignisse überwachen 82 Anmeldeversuche überwachen 82 Kontenverwaltung überwachen 82 Objektzugriffsversuche überwachen 82 Prozessverfolgung überwachen 82 Rechteverwendung überwachen 82 Richtlinienänderung überwachen 82 Systemereignisse überwachen 82 Verzeichnisdienstzugriff überwachen 83 UDP 190 UIAccess-Anwendungen 24 Umkehrbare Verschlüsselung 267 Umleitungen im Dateisystem 78 Update-Management 137 Updateverlauf 140 USB-Geräte einschränken 245 USB-Startschlüssel 126 User Account Control 5

V Verbindlichkeitsstufen 31, 80 Benutzerkonten 40 Objekte 33 Prozesse 38 Vertrauenswürdige Herausgeber 281 VFEK 117 Viren 213 Virtual Store 14 Virtualisierung 13 Virtuelle private Netzwerke 180 VMK 118 Volume File Encryption Key 117

Volume Master Key 118 VPN 180

W Wechselmedienzugriff 246 WEP 173 Whoami.exe 12, 40 Wiederherstellungsagent 93 Wi-Fi Protected Access 173 Windows Defender 213 Windows Firewall Ausgehende Regeln 201 Eingehende Regeln 198 Überwachung 204 Verbindungssicherheitsregeln 201 Windows Internal Database 143 Windows Management Instrumentation Console Windows-Dienste 233 Windows-Firewall 183 Wired Equivalent Privacy 173 WLAN-Sicherheitstyp 173 WLAN-Verbindungen 170 WMIC 6 WPA2-Enterprise 173 WPA2-Personal 173 WPA-Enterprise 173 WPA-Personal 173 WPD-Geräte 248 WSUS 138, 142, 217 WSUS-Clients 155 Wuauclt.exe 159

Z Zertifikate veröffentlichen 110 Zertifikatsregel 284 Zertifikatsverwaltung 63 Zertifikatsvorlage 101 Zonenregel 284 Zufallszahl 258

291