Sicherheit

Verwalten der Windows Vista-Firewall

Jesper M. Johansson

 

Auf einen Blick:

  • Regeltypen und Szenarios
  • Firewallprofile
  • Domänenisolationsregeln
  • Das Problem mit ausgehender Filterung

Vor einer Weile habe ich in meinem Blog einen Artikel über die Windows Vista-Firewall geschrieben. Dieser Beitrag wies nur auf einige der interessanten Features hin, bot aber nicht viele Hinweise für die Bereitstellung.

Im heutigen Artikel werden die Einzelheiten einiger Features der Windows Vista®-Firewall näher beleuchtet, die insbesondere die Unternehmensverwaltung erleichtern sollen. Weiterhin erhalten Sie Ratschläge, wie sich Ihre Arbeit durch Einsatz dieser Features erleichtern lässt und Sie für erhöhte Benutzersicherheit sorgen können.

Aufgrund der neuen Freigabe von SP1 für Windows Vista ist zu erwarten, dass die Unternehmensbereitstellung von Windows Vista jetzt anläuft. (Es ist für Unternehmen üblich, dass sie vor dem Wechsel zu einem neuen Betriebssystem auf die Veröffentlichung des ersten Service Packs warten.) Wenn Sie zu den IT-Experten gehören, die Windows Vista jetzt ernsthafter für ihre Unternehmensumgebung in Erwägung ziehen, sollten Sie sich die Firewall genauer anschauen. Wenn Ihnen die Vorteile der Windows Vista-Firewall erst einmal bewusst werden, entscheiden Sie sich vielleicht, den Vertrag über die Sicherheitssuite mit dem Drittanbieter neu auszuhandeln, um die Firewall aus dem Paket zu entfernen.

Windows-Firewalls damals und heute

Die Firewall in der ursprünglichen Veröffentlichung von Windows® XP ließ viel zu wünschen übrig. Zwar entsprach sie damals in angemessener Weise den Sicherheitsfunktionen in kommerziellen hostbasierten Firewalls, brachte aber nichts Neues oder Innovatives.

Die Firewall in Windows XP SP2 dagegen wurde vollständig verändert. Sie wurde speziell entworfen, um die Verwaltbarkeit in Unternehmen zu erleichtern. Die Windows XP SP2-Firewall ist sehr attraktiv, da sie einfach, zentral verwaltbar, effizient und nicht intrusiv ist. Am wichtigsten ist aber vielleicht, dass sie eine sehr entscheidende Funktion erfüllt: Die Windows XP SP2-Firewall schützt das System beim Startvorgang.

Dieser letzte Punkt ist entscheidend. Ich habe in der Vergangenheit viele Systeme gesehen, die während des Startvorgangs selbst bei eingeschalteter Firewall infiziert wurden. Auf dem Höhepunkt der Blasterepidemie stiegen die Angriffsraten auf einen Angriff in vier Minuten an. Anders gesagt, wenn Sie einen ungeschützten Computer ans Internet angeschlossen ließen, konnte er in durchschnittlich vier Minuten infiziert werden. Wenn Sie sich auf eine Firewall verließen, die das System nicht beim Startvorgang schützte, wurde eins von zwölf Systemen beim Neustart infiziert. Diese Zahlen veranlassten Microsoft, dafür zu sorgen, dass die Windows XP SP2-Firewall das System beim Startvorgang schützt.

In Windows Vista erhielt die Firewall eine weitere vollständige Überarbeitung. Im Hinblick auf die Verwaltung besteht die offensichtlichste Änderung darin, dass die Verwaltungsschnittstellen der Internetprotokollsicherheit (Internet Protocol Security, IPsec) und der Firewall zusammengeführt wurden. Dies ist eine sehr logische Änderung. Sowohl IPsec als auch die Firewall dienen dazu, alles nicht Zugelassene zu blockieren. Der Unterschied besteht darin, dass in der Firewall die Parameter für die Definition dessen, was zugelassen ist, nicht sehr präzise sind, während es in IPsec umständlich ist, umfangreiche Adressbereiche zu sperren oder zuzulassen.

Da sich nun beide Features in einer einzigen Verwaltungsschnittstelle befinden, können Administratoren beide Technologien nahtlos nutzen und sich dabei weniger Sorgen darum machen, ob eine IPsec-Regel oder eher ein Firewallfilter erforderlich ist. Im Wesentlichen erhalten Sie eine einzige Ansicht der Netzwerkangriffsfläche des Systems, und dies hilft, das Fehlerrisiko zu minimieren.

In SP1 für Windows Vista werden den Firewallfeatures einige Verbesserungen im Bereich Zuverlässigkeit hinzugefügt. SP1 enthält außerdem neue Algorithmen, insbesondere die Suite-B-Algorithmen für die Verwendung in IPsec. Dabei handelt es sich um einen Satz an Verschlüsselungsalgorithmen, zu denen der erweiterte Verschlüsselungsstandard (Advanced Encryption System, AES), die Verschlüsselung mittels elliptischer Kurven (Elliptic Curve Cryptography, ECC) und der sichere Hashalgorithmus (Secure Hash Algorithm, SHA) 256 und 384 gehören.

Am wichtigsten ist jedoch, dass in Service Pack 1 Support für den Netzwerkzugriffsschutz (Network Access Protection, NAP) hinzufügt wird. NAP ist ein Tool zur Durchsetzung von Richtlinien, mit dem sichergestellt wird, dass verwaltete und nicht beeinträchtigte Clients mit den aktuellen Sicherheitsrichtlinien, Updates und Antimalwaredefinitionen auf dem neuesten Stand sind, bevor sie eine Verbindung zum Netzwerk herstellen dürfen. NAP kann schädliche Hosts nicht daran hindern, eine Verbindung zum Netzwerk herzustellen, aber es wird gewährleistet, dass alle verwalteten Hosts vollständig konform sind, solange sie nicht aktiv beeinträchtigt sind.

Die Windows Vista-Firewall wird als Windows-Firewall mit erweiterter Sicherheit bezeichnet und ist auch in Windows Server® 2008 enthalten. Sämtliche Features lassen sich auch von einem Remotestandort aus verwalten und mithilfe der Gruppenrichtlinie über ein Netzwerk konfigurieren.

Regeltypen und Szenarios

Die Kombination von Firewall- und IPsec-Funktionen in der Verwaltungsschnittstelle bedeutet, dass es jetzt zwei verschiedene Regeltypen gibt: Richtungsregeln und Verbindungsregeln. Richtungsregeln sind Standardfirewallregeln, die definieren, welcher Datenverkehr in der entsprechenden Richtung zugelassen wird. Verbindungsregeln definieren die Schutzparameter für Verbindungen zwischen Computern. Vergleichsweise ähneln Richtungsregeln den Firewallregeln, die Sie aus früheren Firewalls kennen, während Verbindungsregeln mehr den IPsec-Regeln ähneln, die in Verbindung mit der Firewall in Windows XP SP2 verwendet werden.

Die Zusammenfassung von Firewall und IPsec in derselben Schnittstelle ermöglicht mehrere sehr interessante Szenarios. So besteht beispielsweise eines der wertvollsten heute verfügbaren Sicherheitskonzepte darin, Systeme im Netzwerk voneinander zu isolieren. Microsoft bezeichnet dies als „Server- und Domänenisolation“.

Die Server- und Domänenisolation verwendet sowohl IPsec- als auch Firewallfunktionen. Deshalb enthält die neue Firewallverwaltungsschnittstelle bestimmte Funktionen für Isolationsregeln. Diese sind geeignet, wenn Sie beispielsweise die Verbindung aufgrund von Attributen des Quell- oder Zielsystems, z. B. der Domänenmitgliedschaft, einschränken wollen.

Wie Sie in Abbildung 1 sehen können, beginnt der Assistent für neue Verbindungssicherheitsregeln mit der Frage, welchen Regeltyp Sie erstellen wollen. Wenn Sie Isolation auswählen, konfiguriert der Assistent bestimmte Einstellungen vor, die für eine Isolationsregel geeignet sind.

Abbildung 1 Erstellen einer Isolationsregel mithilfe des Assistenten für neue Verbindungssicherheitsregeln

Abbildung 1** Erstellen einer Isolationsregel mithilfe des Assistenten für neue Verbindungssicherheitsregeln **(Zum Vergrößern auf das Bild klicken)

Möglicherweise bemerken Sie in Abbildung 1 auch, dass die Isolationsregel den Integritätsstatus erwähnt. Die für die Server- und Domänenisolation verwendeten Regeln sind eigentlich die gleichen wie die für NAP.

Sie können für einige Arten von Verkehr keine Authentifizierung erzwingen. Zum Beispiel soll wahrscheinlich für die DNS-Auflösung keine Authentifizierung erforderlich sein. Für die Endpunkte dieser Art von Verkehr benötigen Sie eine Regel für die Ausnahme von der Authentifizierung. Eine Regel für die Ausnahme von der Authentifizierung fungiert genauso, wie es der Name schon sagt: Datenverkehr wird von den IPsec-Anforderungen ausgenommen.

Eine Server-zu-Server-Regel ist eigentlich eine Fehlbenennung. Sie wird zwar häufiger für Server eingesetzt, kann aber auch für Clients verwendet werden. Mit einer Server-zu-Server-Regel wird eine Verbindung lediglich so konfiguriert, dass eine Authentifizierung erforderlich ist. Sie unterscheidet sich von einer Isolationsregel darin, dass eine Isolationsregel nicht nur Authentifizierung erfordert, sondern auch die Erfüllung einiger zusätzlicher Kriterien wie Domänenmitgliedschaft oder Integritätsstatus.

Eine Tunnelregel definiert im Wesentlichen ein Standort-zu-Standort-VPN (virtuelles privates Netzwerk) sowie den Tunnel zwischen den Gateways. Tunnelregeln werden in Windows Vista selten verwendet, da es unwahrscheinlich ist, dass Windows Vista als Gateway eingesetzt wird. Sie können vollständig benutzerdefinierte Regeln erstellen. Dadurch können Sie alle Parameter der Regel anpassen.

Reihenfolge der Regeln

Die Reihenfolge der Regeln ist auf den ersten Blick etwas kompliziert. Der Schlüssel zum Verständnis der Reihenfolge der Regeln besteht darin, zunächst die Frage nach der Reihenfolge außer Acht zu lassen. Es geht nicht so sehr um die Reihenfolge, sondern um die Auswahlregel. Betrachten wir als Beispiel den eingehenden Datenverkehr. Eingehender Datenverkehr, der keiner Regel entspricht, die ihn zulässt, wird standardmäßig blockiert. Sie betrachten dies vielleicht als eine Reihenfolge mit dem Inhalt „Zulassungsregeln werden zuerst berücksichtigt“, aber eine solche Annahme wäre falsch. Wenn ein bestimmtes Paket sowohl einer Zulassungsregel als auch einer Blockierungsregel entspricht, gewinnt die Blockierungsregel. Einfach ausgedrückt bedeutet dies folgende Trefferbedingung:

  1. Blockierungsregeln. Wenn ein Paket oder eine Verbindung einer Blockierungsregel entspricht, wird es verworfen.
  2. Zulassungsregeln. Wenn ein Paket oder eine Verbindung einer Zulassungsregel entspricht, wird es zugelassen.
  3. Standardverhalten des Richtungsprofils. Wenn keine Blockierungs- oder Zulassungsregeln passen, wird der Datenverkehr gemäß dem Verhalten behandelt, das als Standard für Datenverkehr in dieser Richtung und in diesem Profil angegeben ist. In der eingehenden Richtung in allen Profilen bedeutet dies das Blockieren des Datenverkehrs in einer Standardkonfiguration. In der ausgehenden Richtung bedeutet es standardmäßig, dass der Datenverkehr in der Standardkonfiguration zugelassen wird.

Die Regelprüfung wird durch Regeln zur authentifizierten Umgehung (IPsec) eingeschränkt. Mithilfe dieses Regeltyps wird der gesamte authentifizierte Datenverkehr, der den anderen Parametern der Regel entspricht, zugelassen, unabhängig davon, ob er irgendwelchen sonstigen Regeln entspricht. Regeln zur authentifizierten Umgehung sind Richtungsregeln, bei denen die Option „Regeln zum Blocken außer Kraft setzen“ aktiviert ist, wie in Abbildung 2 dargestellt. Diese werden zuerst berücksichtigt, damit authentifizierter Datenverkehr das System immer erreicht. Dies ist entscheidend, damit Sie Datenverkehr von authentifizierten Hosts problemlos zulassen, Datenverkehr von allen anderen jedoch blockieren können. Diese Regel können Sie als die Nummer 0 in der Reihenfolge betrachten. Dann sieht die vollständige Reihenfolgenliste der Regeln wie folgt aus:

Abbildung 2 Aktivieren der Option „Regeln zum Blocken außer Kraft setzen“, um eine Regel zur authentifizierten Umgehung zu konfigurieren

Abbildung 2** Aktivieren der Option „Regeln zum Blocken außer Kraft setzen“, um eine Regel zur authentifizierten Umgehung zu konfigurieren **(Zum Vergrößern auf das Bild klicken)

0. Regel zur authentifizierten Umgehung

1. Blockierungsregeln

2. Zulassungsregeln

3. Standardverhalten des Richtungsprofils

Es ist unerheblich, ob es innerhalb der jeweiligen Klasse mehrere Regeln gibt, die dem Verkehrsmuster entsprechen. Sobald eine Regel dem Datenverkehr entspricht, wird die Regelverarbeitung beendet.

Öffentlich, privat und Domäne

Netzwerkressourcen

Die neue Firewall hat drei Profile: Öffentlich, privat und Domäne. Die Windows XP SP2-Firewall hatte hingegen zwei Netzwerkprofile: Standard und Domäne. Das Domänenprofil wird automatisch aufgerufen, wenn der Computer den Domänencontroller finden kann. In Windows XP wurde das Standardprofil anders verwendet. Dies bot leistungsfähige Funktionalität für einen Sicherheitsadministrator, der den Computer beim Roaming vollständig sperren und dennoch die gesamte Remoteverwaltungsfunktionalität zulassen konnte, die für den Zugriff auf das Netzwerk der Organisation erforderlich ist. Dieser Ansatz brachte jedoch für einige Benutzer gewisse Probleme mit sich, insbesondere für solche mit persönlichen Netzwerken zu Hause. Da immer das Standardprofil verwendet wurde, wenn das System den Domänencontroller nicht erreichen konnte, wurde das System von der Wohnung des Benutzers aus gesperrt.

Das neue private Profil in Windows Vista trägt zur Lösung dieses Problems bei. Wenn Sie jetzt das System mit einem neuen Netzwerk verbinden, werden Sie gefragt, ob dieses Netzwerk öffentlich (dies ist einfach der neue Name für das ehemalige Standardprofil) oder privat ist, und das System wird entsprechend konfiguriert. Daran erinnert sich das System jedes Mal, wenn eine Verbindung zu diesem bestimmten Netzwerk hergestellt wird, und zwar in Abhängigkeit von Netzwerkparametern, die dem System durch die Infrastrukturserver im Netzwerk anzeigt werden. Dies ist nicht absolut sicher, aber es hilft dadurch, dass sich mehr Netzwerke besser sperren lassen.

Die Logik für die Erkennung, ob das System in der Domäne ist, wurde ebenfalls verbessert. Dies führt zu einem schnelleren, zuverlässigeren Übergang und zu weniger Systemen, die das öffentliche oder private Profil verwenden, wenn sie sich in Wirklichkeit in der Domäne befinden.

Sie können die Regeln an einen bestimmten Netzwerktyp binden und so das System daran hindern, zu viele Informationen anzubieten und zu versuchen, eine Verbindung zu Systemen in nicht vertrauenswürdigen Netzwerken herzustellen. Dies ist einer der Bereiche, in denen sich die Integration von Firewall und IPsec auszuzahlen beginnt.

Mit diese neuen Regeln können Sie Einschränkungen vorsehen, die früher nicht möglich waren. Beispielsweise haben Angreifer viele Jahre lang mit Lockangriffen versucht, Benutzer dazu zu bewegen, SMB-Verbindungen (Server Message Block, SMB) für Windows-Netzwerke zu nicht vertrauenswürdigen Hosts herzustellen, wodurch eine Authentifizierungssequenz erzwungen wird, die ein Challenge-Response-Paar liefert, mit dem sich Kennwörter knacken lassen. Ältere Versionen dieses Angriffs wurden auch verwendet, um die Authentifizierung zu Klartext herabzustufen oder um das Challenge-Response-Paar des Benutzers an den Computer zurückzugeben, von dem es stammte. Die erste dieser Techniken wurde bereits vor Jahren ausgemerzt. Die letztere Technik wurde mit Windows XP SP2 bekämpft. Bedenken Sie aber, dass es dennoch unklug ist, Challenge-Response-Paare anzubieten.

Um dies zu verhindern, könnten Sie eine andere neue Funktion in der Windows Vista-Firewall verwenden: die ausgehende Filterung. Ein Administrator könnte zum Beispiel beschließen, alle ausgehenden SMB-Verbindungen (diejenigen, die an den Ports TCP 135, 139, 445 und UDP 137, 138, 445 enden) im öffentlichen Profil zu blockieren. Dann würde es schwieriger, ein System durch einen Lockangriff zur Gewinnung von Challenge-Response-Paaren zu verwenden, oder es würde daran gehindert, auf nicht vertrauenswürdige Windows-Dateifreigaben im Internet zuzugreifen.

Aber auch dies bietet keine absolute Sicherheit. Wenn zum Beispiel das System bereits beeinträchtigt wurde, würde diese Regel das System nicht an der Kommunikation nach außen hindern, da der Angreifer die Regel einfach deaktivieren könnte. Es kann jedoch als Maßnahme sehr nützlich sein, um Systeme zu schützen, die sich korrekt verhalten, aber möglicherweise Angriffen ausgesetzt sind.

In diesem Kontext muss erwähnt werden, dass ebenso wie in Windows XP SP2 in Windows Vista und Windows Server 2008 jeweils nur ein Profil aktiv sein kann. Wenn es zwei aktive Netzwerkschnittstellen im System gibt, von denen eine in der Domäne ist, während sich die andere in einem öffentlichen Netzwerk befindet, wird das öffentliche Firewallprofil auf beide angewendet. Es wird immer das Profil mit den größten Einschränkungen angewendet. Sie können sich vielleicht denken, dass das öffentliche Profil mit stärkeren Einschränkungen verbunden ist als das private Profil, und das private Profil mit stärkeren Einschränkungen als das Domänenprofil. Bedenken Sie, dass die Blockierungsregel für ausgehende SMB viel Datenverkehr über VPN-Verbindungen unterbrechen kann.

Um Datenverkehr über eine VPN-Verbindung zu ermöglichen, wenn der Computer in ein öffentliches oder privates Netzwerk eingebunden ist, erstellen Sie Richtungsregeln, die nur für VPN-Schnittstellen gelten. Damit dies funktioniert, müssen die VPN-Schnittstellen als solche von Windows erkannt werden. Wenn Sie nicht den VPN-Server für Microsoft® Routing- und RAS-Dienste verwenden, testen Sie diese Funktionalität vor der allgemeinen Bereitstellung. Ein Problem besteht hauptsächlich mit eingehendem Datenverkehr zum Client und etwaigen benutzerdefinierten Regeln für ausgehenden Datenverkehr, die Sie erstellen.

Erstellen von Firewallregeln

Eine Firewallregel zu erstellen, ist in der neuen Firewall viel einfacher. Mit dem Assistenten für neue Regeln, der in Abbildung 3 dargestellt ist, können Sie alle üblichen Regeltypen definieren. Er enthält auch vordefinierte Regeln für bestimmte Dienste.

Abbildung 3 Vordefinierte Regeln im Assistenten für neue Regeln

Abbildung 3** Vordefinierte Regeln im Assistenten für neue Regeln **(Zum Vergrößern auf das Bild klicken)

Die vordefinierten Regeln sind besonders wichtig. Bei Serverisolation geht es im Wesentlichen darum, Dienste so einzuschränken, dass sie nur für diejenigen Systeme verfügbar sind, die sie wirklich benötigen. Auf Serverprodukten wird dies durch den Windows Sicherheitskonfigurations-Assistenten (Security Configuration Wizard, SCW) erleichtert, ist aber immer noch nicht ganz mühelos. (Auf den SCW wurde in der Ausgabe des TechNet Magazins vom März 2008 näher eingegangen.)

Die Clientversionen von Windows hatten bisher jedoch keine ähnlichen Funktionen. Wenn Sie den vordefinierten Regeltyp verwenden, ist ein großer Teil der Arbeit bereits erledigt, nämlich die Aufgabe zu ermitteln, welche Endpunkte ein Dienst verwendet. Die Firewall ist nicht nur in dem Sinne anwendungsorientiert, dass sie weiß, welches Programm der „iSCSI-Dienst“ repräsentiert, sondern sie enthält auch vordefinierte Regeln, die bestimmte Funktionen beschreiben. Dadurch können Sie sich auf die Frage konzentrieren, welche Computer in einer Regel abgedeckt werden müssen. Das ist immer noch eine schwierige und zeitaufwändige Aufgabe, aber wenigstens eine für Ihre Umgebung spezifische.

Es gibt auch eine benutzerdefinierte (im Dropdown in Abbildung 3 verschlüsselte) Regel, die Ihnen die gesamte Flexibilität gewährt, die Sie von einer authentifizierenden Firewall erwarten können. Wenn Sie zum Beispiel eine Regel wünschen, die nur IPsec-verschlüsselten Datenverkehr zulässt, so wählen Sie die Option aus, bei der nur sichere Verbindungen auf der Seite „Aktion“ des in Abbildung 2 gezeigten Assistenten zugelassen werden.

Bei dieser Auswahl haben Sie auch die Option, die Verschlüsselung einzuschalten. Wenn Sie diese Option leer lassen, verwendet der Datenverkehr ESP-NULL (Encapsulating Security Payload mit einem NULL-Schlüssel). Dies ist die empfohlene Möglichkeit, IPsec zur Authentifizierung zu verwenden. Die meisten Netzwerkverwaltungstools funktionieren dadurch weiterhin, da der Datenverkehr das Netzwerk im Klartext durchläuft, und wenn Sie je eine Verschlüsselung wünschen, können Sie einfach das Feld markieren.

In vielen Situationen ist die Verschlüsselung des Netzwerkverkehrs nicht annähernd so wichtig wie die Nichtannahme etwaigen Datenverkehrs von schädlichen Hosts. Die Verschlüsselung des Datenverkehrs im Netzwerk hindert einen Angreifer, der sich Zugang zum Netzwerk verschafft hat, den Inhalt des Pakets zu sehen. Wenn Authentifizierung erfordert wird, werden Sie möglicherweise daran gehindert, das Paket überhaupt zu senden und angegriffen zu werden. In vielen Situationen ist die Verschlüsselung auf Netzwerkebene natürlich wichtig, aber es gibt auch viele andere Situationen, in denen nur Authentifizierung erforderlich ist.

Erstellen von Domänenisolationsregeln

In den meisten Umgebungen wird verlangt, dass lediglich eine begrenzte Anzahl von Computern Datenverkehr an eine Arbeitsstation senden kann. Zumindest sollten alle Arbeitsstationen mit Domänenisolationsregeln konfiguriert werden. Dies war in Windows XP kompliziert, ist aber in Windows Vista einfach.

Öffnen Sie zunächst das Verwaltungstool Ihrer Wahl, und wählen Sie den Knoten „Verbindungssicherheitsregeln“ aus. Klicken Sie dann mit der rechten Maustaste auf den Knoten, und wählen Sie „Neue Regel“ aus. Der in Abbildung 1 dargestellte Dialog wird angezeigt. Wählen Sie „Isolationsregel“ aus, und klicken Sie auf „Weiter“. Jetzt müssen Sie auswählen, ob die Regel erzwungen werden soll oder nicht. In den meisten Fällen soll auf Arbeitsstationen wahrscheinlich eine Authentifizierung für eingehenden Datenverkehr erfolgen. Dies hindert jeden nicht mit der Domäne verbundenen Computer, Datenverkehr an die Arbeitsstation zu senden. Um jedoch Dienste von Infrastrukturdiensten anzufordern, muss das System gewissen ausgehenden Datenverkehr im Klartext zulassen. Die beste Option besteht deshalb darin, für eingehende Verbindungen Authentifizierung zu erfordern und für ausgehende Verbindungen Authentifizierung anzufordern.

Wählen Sie als Nächstes die Authentifizierungsmethode aus. Die Standardauswahl wird „Standard“ genannt, was nicht gerade eine besonders hilfreiche Bezeichnung ist. Sie können die Standardauthentifizierungsmethode auf Computerbasis in den IPsec-Eigenschaften konfigurieren (klicken Sie mit der rechten Maustaste auf den Knoten „Windows-Firewall mit erweiterter Sicherheit“, und wählen Sie dann „Eigenschaften“ aus). Die Standardauthentifizierungsmethode ist immer Kerberos, die einfachste und sicherste Methode. Aus Gründen der Verständlichkeit empfehle ich jedoch, dass Sie sie beim Erstellen der Regeln tatsächlich auswählen. Normalerweise ist erforderlich, dass sich nur der Computer authentifiziert, nicht auch der Benutzer. Wenn Sie von beiden eine Authentifizierung erfordern, können unter Umständen bestimmte Arten von Verwaltungsdatenverkehr, z. B. anonym übertragener SNMP-Datenverkehr, nicht entgegengenommen werden.

Nach Auswahl der Authentifizierungsmethode brauchen Sie nur noch auszuwählen, in welchen Profilen diese Regel verfügbar sein soll. Da diese Regel für mit der Domäne verbundene Computer gilt, die ein Kerberos-Ticket vorlegen können, ist es nicht sinnvoll, dies für private oder öffentliche Profile auszuwählen. Speichern Sie die Regel, und Sie sind fertig.

Grundlegende Isolationsregeln sind nicht mehr kompliziert. Um jedoch die Isolationsfähigkeit von IPsec zu nutzen, müssen Sie auch auf Ihren Arbeitsstationen die Serverisolation implementieren. Dadurch können Sie Ihre Arbeitsstationen hindern, andere Clients abzuhören. Sie antworten stattdessen nur den entsprechenden Verwaltungsstationen. Stellen Sie sich vor, wie viel weniger Auswirkungen manche Malwareangriffe gehabt hätten, wenn Clientsysteme abgelehnt hätten, andere Clients abzuhören.

Skripterstellung für die Firewall

Die neue Firewall bietet eine umfassende API, mit der Sie Skripts sowohl für die Bereitstellung als auch für die Bewertung erstellen können. Im Idealfall sollten für die Bereitstellung die Gruppenrichtlinien verwendet werden, aber da Gruppenrichtlinien nicht immer verfügbar sind, ist ein richtiger API-Satz zum Konfigurieren der Firewall wichtig. Die APIs sind unter dem INetFWPolicy2-Satz von APIs zusammengefasst. Im Software Development Kit und in der MSDN®-Bibliothek finden Sie vollständigere Angaben zur Verwendung dieser APIs, aber anhand einiger Beispiele lassen sich die wesentlichen Punkte gut erläutern.

Ein häufiges Beispiel ist das Feststellen, ob eine Gruppe von Regeln eingeschaltet ist. So muss beispielsweise eine Anwendung oder ein Administrator feststellen, ob die Datei- und Druckerfreigabe von einem System zugelassen ist. Dies kann durch die INetFWPolicy2::IsRuleGroupCurrentlyEnabled-API erreicht werden. Abbildung 4 liefert ein Beispiel für ein VBScript, das diese Funktion veranschaulicht.

Figure 4 Verwenden von INetFWPolicy2::IsRuleGroupCurrentlyEnabled

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Falls nun die Datei- und Druckerfreigabe ausgeschaltet ist und Sie diese einschalten müssen, so müssen Sie zuerst sicherstellen, dass dies möglich ist und nicht durch Gruppenrichtlinien außer Kraft gesetzt wird. Dies erfolgt mit der INetFWPolicy2::LocalPolicyModifyState-API. Nachfolgend sehen Sie ein Grundgerüst, das mit Code ausgefüllt werden kann:

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Befehlszeile und Schnittstellentypen

Keine Firewall wäre ohne eine richtige Befehlszeile für die Verwaltung vollständig. Es gibt unter Netsh einen Unterkontext mit der Bezeichnung „advfirewall“. Der „advfirewall“-Kontext gibt Ihnen Befehlszeilenzugriff auf alle Funktionen, die in der grafischen Benutzeroberfläche ausgeführt werden können. Wenn Sie zum Beispiel auf Port 445 die Blockierung des ausgehenden Datenverkehrs implementieren wollen, können Sie von einer Eingabeaufforderung mit erweiterter Berechtigung den folgenden Befehl ausführen:

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

Anschließend müssen Sie den gleichen Befehl ausführen und dabei TCP durch UDP ersetzen, um die Sperre fertigzustellen. Dann ist die Implementierung der Regel abgeschlossen.

Ein interessantes Feature in der Firewall ist die Möglichkeit, Regeln basierend auf dem Netzwerkschnittstellentyp zu konfigurieren. Beachten Sie, dass einige Regeln sich auf VPN-Verbindungen auswirken können. Solange Windows die Schnittstelle als eine VPN-Schnittstelle erkennt, können Sie diesen Regeltyp verwenden, um Datenverkehr über diese Schnittstelle auszuschließen:

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

Dies ist auch in der grafischen Benutzeroberfläche möglich, allerdings erst nach Erstellen der Regel. Sie müssen dann mit der rechten Maustaste auf die Regel klicken, „Eigenschaften“ auswählen und auf die Registerkarte „Erweitert“ klicken. Dort finden Sie einen Abschnitt „Schnittstelltypen“, in dem Sie die richtigen Schnittstellentypen auswählen können.

Ausgehende Filterung

Das Fehlen der ausgehenden Filterung in der Windows XP SP2-Firewall wurde als wichtigster Beweis dafür vorgebracht, dass die integrierte Firewall für die Sicherheit nicht ausreicht. Es sind wohl Tausende von Artikeln darüber geschrieben worden, wie unsicher die Windows XP SP2-Firewall aufgrund der fehlenden ausgehenden Filterung sei, und zwar trotz der Tatsache, das keine Firewall unter Windows XP eine sichere ausgehende Filterung bieten konnte.

Die grundlegende Funktionalität, die die ausgehende Filterung von einer bloßen Bremsfunktion – oder einem Tool zur Durchsetzung von Richtlinien, wie ich es früher verwendete – in ein nützliches Sicherheitsfeature verwandelt, existiert in Windows XP einfach nicht. Sie ist aber in Windows Vista vorhanden. Es ist daher nur logisch, dass die neue Firewall dieses Feature nutzt. Standardmäßig wird der meiste eingehende Datenverkehr blockiert und der meiste ausgehende Datenverkehr zugelassen.

Standardmäßig blockiert die ausgehende Filterung in der neuen Windows Vista-Firewall nur unnötigen Datenverkehr von Diensten. Mehr kann im Prinzip nicht erfolgen, um auf dem Host, der die ausgehenden Filter bereitstellt, Schutz vor Angriffen zu bieten. Unter Windows XP wäre dies unsinnig gewesen.

Dienste in Windows Vista können mit einem sehr eingeschränkten Token ausgeführt werden. Im Wesentlichen verfügt jeder Dienst über eine eigene und eindeutige Sicherheits-ID (SID). Diese Dienst-SID kann verwendet werden, um den Zugriff auf Ressourcen wie Netzwerkports einzuschränken. Es handelt sich dabei um die gleiche Funktionalität wie bei der Einschränkung des Datenverkehrs an Benutzer. Obwohl daher möglicherweise zwei Dienste als NetworkService ausgeführt werden, können sie nicht die Prozesse des jeweils anderen Diensts verwalten, und die Firewall kann so konfiguriert werden, dass nur einer von ihnen nach außen kommunizieren kann. Wenn der blockierte Dienst beeinträchtigt wird, kann er nicht die Kontrolle über den zugelassenen Dienst übernehmen und dessen zugelassenen Port verwenden, um nach außen zu kommunizieren, weil der Port durch die Dienst-SID eingeschränkt ist.

Diese Funktion ist ein weiteres der sehr interessanten Sicherheitsfeatures in Windows Vista, das von der neuen Firewall verwendet wird, um durch die ausgehende Filterung der Firewall wirkliche Sicherheit zu bieten.

Die Firewallfilterung auf Basis von Dienst-SIDs ist in der neuen Firewall standardmäßig aktiviert. Es gibt jedoch keine grafische Benutzeroberfläche, um sie zu konfigurieren. Die Regeln sind im Registrierungsschlüssel „HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices“ vordefiniert. Sie müssen aber mit manuellen Änderungen an diesem Schlüssel sehr vorsichtig sein, da diese nicht unterstützt werden.

Wie viel Sicherheit kann ausgehende Filterung bieten?

Was in der Sicherheitscommunity zu erheblichen Missverständnissen führt, ist die Frage, wie viel Sicherheitswert durch ausgehende Filterung tatsächlich geboten wird. Bisher wurden zwei Szenarios erwähnt, die Sicherheit durch ausgehende Filterung bieten, aber beide beruhen auf neuen Funktionen in Windows Vista, die vorher nicht verfügbar waren. Trotzdem wird allgemein anerkannt, dass ausgehende Filterung grundsätzlich gut ist und bei Kaufentscheidungen für eine Firewall ein entscheidender Faktor sein sollte.

Paradoxerweise standen in vielen Organisationen bei der Kaufentscheidung die Funktionen der ausgehenden Filterung im Vordergrund, aber nach der Implementierung der Firewall wurde die ausgehende Filterung dann gar nicht verwendet. Dies ist bedenklich und führt zu Geld- und Zeitverschwendung bei der Informationssicherheitsgruppe. Es scheint mehr durch den Wunsch getrieben zu sein, ein gutes Gefühl zu haben, weil man ja im Bereich Sicherheit etwas tut, als durch die tatsächliche Analyse wirklicher Bedrohungen. Viel zu oft beeinflusst der Wunsch nach einer Art von „Sicherheitsvorführung“ Entscheidungen, die stattdessen auf Fakten beruhen sollten.

Es gibt eine sehr einfache Tatsache über ausgehende Filterung, die von Befürwortern oft nicht berücksichtigt wird. Das übliche Argument von Anbietern hostbasierter Firewalls besteht darin, dass bei Beeinträchtigung eines Systems, ob durch einen Wurm oder einen interaktiven Angreifer, der Wurm durch die ausgehende Filterung daran gehindert wird, andere Systeme zu infizieren, bzw. der Angreifer daran gehindert wird, weiterhin nach außen zu kommunizieren. Das ist jedoch nicht der Fall.

Wahr ist nur, dass bei sonst völlig gleicher Konstellation die ausgehende Filterung in der Vergangenheit bestimmte Arten von Malware ausgebremst hätte. Wäre Windows XP jedoch mit der ausgehenden Filterung ausgestattet gewesen, so wären die bisher aufgetretenen Würmer mit allergrößter Wahrscheinlichkeit so geschrieben worden, dass sie die Filterung ausgeschaltet oder auf andere Weise umgangen hätten.

Unter Windows XP (und früheren Versionen von Windows) wäre dies mit jedem als Dienst ausgeführten Wurm möglich gewesen – und alle gängigen Würmer wurden als Dienst ausgeführt. Dies geschah nur darum nicht, weil es praktisch keine Umgebungen mit ausgehender Filterung gab und es deshalb unnötig war, diese zu deaktivieren. Bei einem interaktiven Angriff kann der Angreifer ausgehende Filter nach Belieben umgehen. Wenn der Angreifer die Möglichkeit hat, beliebigen Code auszuführen, ist dies ganz einfach. Falls erforderlich, kann der Angreifer den Benutzer aber auch zum Umgehen der Filter verführen.

Ausgehende Filter in hostbasierten Firewalls können je nach Angriffsszenario auf verschiedene Weise umgangen werden. Die einfachste Möglichkeit besteht darin, einen überprivilegierten Benutzer darum zu „bitten“. In zu vielen Umgebungen werden Benutzer immer noch als Administratoren geführt. Diese Benutzer haben das Recht, Sicherheitsrichtlinien nach Belieben zu umgehen. Der Angreifer muss den Benutzer lediglich vor die Wahl zwischen einem immateriellen, nicht unmittelbaren Sicherheitsvorteil und etwas für den Benutzer Erstrebenswerterem stellen.

In vielen Fällen werden Benutzer mit derartigen Dialogen so sehr überschwemmt, dass sie schnell mal auf etwas klicken, ohne die Folgen wirklich zu verstehen. Dies ist das Hauptproblem bei ausgehender Filterung. Bei der Wahl zwischen Sicherheit und hinreichend verlockenden Belohnungen lässt sich der Benutzer immer verführen, denn die meisten Dialoge, in denen Benutzer zu Sicherheitsentscheidungen aufgefordert werden, enthalten keinerlei Informationen, die sie zu solchen Entscheidung tatsächlich befähigen.

Dialoge für Sicherheitsentscheidungen anzuzeigen, die hinreichende Informationen als Grundlage für solche Entscheidungen bieten, ist viel schwieriger als es scheint. Dazu ist es nämlich erforderlich, dass das Sicherheitsprodukt, z. B. die Firewall, nicht nur Ports, Protokolle und die Anwendung versteht, die die Anforderung ausführt, sondern dass es auch versteht, was die Anforderung wirklich erreichen will und was dies für den Benutzer bedeutet. Diese Informationen lassen sich programmgesteuert nur sehr schwer erzielen. So ist zum Beispiel die Tatsache, dass Microsoft Word gerade eine ausgehende Verbindung herzustellen versucht, längst nicht so interessant wie das, was Word mit dieser Verbindung eigentlich erreichen will.

Die Anzahl nutzloser Dialoge muss verringert, nicht erhöht werden, und Firewalls mit ausgehender Filterung tragen nicht dazu bei. Um ein Gefühl für den Entwicklungsstand bei der Versorgung von Benutzern mit wertvollen Informationen zu bekommen, habe ich mir die Vertriebsdokumentation für einen führenden Anbieter hostbasierter Firewalls angeschaut. Die Hochglanzbroschüren loben die Fähigkeiten der ausgehenden Filter und die Beratungsfunktion der Firewall. Die Beratungsfunktion erkennt, was der Benutzer zu tun versucht, und stellt entsprechende Hinweise zur Verfügung. Ungefähr so sieht die Theorie aus. Der Text in der Broschüre war von einem Screenshot folgenden Inhalts begleitet: „Hinweise sind für dieses Programm noch nicht verfügbar. Wählen Sie weiter unten, oder klicken Sie auf „Weitere Information“, um Hilfe zu erhalten.“ Anscheinend können Anbieter nicht einmal im Marketingmaterial informative Dialoge bereitstellen.

Da Benutzer keine ausreichenden Informationen besitzen, um die richtigen Sicherheitsentscheidungen zu treffen, obliegt es dem Administrator, alle ausgehenden Filter zu konfigurieren, da der Endbenutzer dazu nicht in der Lage ist. Dadurch erhöht sich der Verwaltungsaufwand des Administrators erheblich.

Selbst wenn der Benutzer auf „Nein, jetzt nicht“ klickt, wenn die Firewall ihn fragt, kann die Malware die Firewall meist ungehindert umgehen. Solange der Benutzer, in dessen Namen der schädliche Code ausgeführt wird, auf irgendeinem Port ausgehende Verbindungen öffnen kann, kann der schädliche Code einfach diesen Port verwenden. So kann sich jeder Prozess an einen vorhandenen Prozess anhängen. Dies wird auf älteren Betriebssystemen zugelassen. Seit Windows Vista können die Prozesse entsprechend eingeschränkt werden. Deshalb werden Dienste, die standardmäßig eingeschränkt sind, standardmäßig mithilfe der ausgehenden Filter blockiert.

Leider glauben die meisten Leute, dass ausgehende Filterung in hostbasierten Firewalls eine beeinträchtigte Ressource daran hindert, andere Ressourcen anzugreifen. Das ist unmöglich. Es ist schlicht sinnlos, eine beeinträchtigte Ressource mit Schutzmaßnahmen zu belegen und zu erwarten, dass andere Ressourcen dadurch nicht beeinträchtigt werden. Der Schutz gehört zu der Ressource, die geschützt werden soll, nicht zu derjenigen, vor der geschützt werden soll! Einbrecher nach dem Eindringen in Ihr Haus zu bitten, nichts zu stehlen, ist höchstwahrscheinlich weniger effektiv, als sie schon vorher am Einbruch ins Haus zu hindern.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.