Für die Bedienung der in allen aktuellen Windows-Systemen vorhandenen "Windows Firewall mit erweiterter Sicherheitsverwaltung" (so der vollständige offizielle Name) bieten sowohl Windows 7 und Windows Server 2008 R2 als auch die neue Generation der Betriebssysteme mit Windows 8 und Windows Server 2012 eine grafische Oberfläche, die eine leichte Konfiguration und Verwaltung erlaubt. Aber spätestens beim Einsatz eines Serversystems, das auf Basis der Server-Core-Version arbeitet, wird es für die Administratoren notwendig, auch hier die Kommandozeile zu bemühen.
Zu diesem Zeitpunkt kam und kommt auf vielen Systemen auch weiterhin der netsh-Befehl zum Einsatz. Bei dieser Software handelt es sich nicht um einen einzelnen Befehl, sondern um eine eigenständige Shell, die mit vielen Subbefehlen ausgestattet wurde. Microsoft möchte aber erreichen, dass immer mehr Aufgaben aus dem Bereich Systemkonfiguration und -betreuung auch oder sogar ausschließlich unter Einsatz der PowerShell durchgeführt werden können. So können Anwender und Administratoren nun auf mehr als 2400 CMDlets zur Verwaltung ihrer Windows-Systeme zurückgreifen.
Wir stellen hier einige der neuen Cmdlets vor, zeigen ihre Einsatzmöglichkeiten und demonstrieren zudem, wie sie sich von den klassischen netsh-Kommandos unterscheiden. Dabei ist es sicher gut, dass man bei Microsoft noch nicht - wie zunächst von vielen Experten den befürchtetet -- einen radikalen Schnitt vorgenommen und die netsh-Unterstützung bei den neuen Betriebssystem komplett gestrichen hat: Auch unter Windows 8 und Windows Server 2012 stehen nach wie vor alle netsh-Kommandos zur Verfügung, und bereits entwickelte Batch-Dateien werden auch weiterhin auf den neuen System laufen.
Eine weitere wichtige Neuerung der PowerShell kommt den Administratoren und Anwendern der neuen Windows-Systeme aber auf jeden Fall zugute: Es ist nicht mehr nötig, entsprechende Module - wie in diesem Fall das Modul Netsecurity - explizit nachzuladen, denn das erledigt die PowerShell nun automatisch. Wollen Sie zunächst einmal eine Übersicht darüber bekommen, welche Cmdlets Ihnen die PowerShell im Bereich Sicherheit nun aktuell zur Verfügung stellt, so sollten Sie zunächst den folgenden Befehl eingeben:
Get-Command -module Netsecurity
Eine umfangreiche Liste der PowerShell-Cmdlets rund um den Bereich Netzwerksicherheit (es sind insgesamt 84) ist mit der Auflistung ihrer jeweiligen Parameter in englischer Sprache auf dem TechNet zu finden.
Eine Abfrage: Wie steht’s um meine Firewall?
Wenn es um die Arbeit mit der Windows-Firewall geht, so ist die Abfrage ihrer aktuellen Einstellungen und damit der aktiven Firewall-Regeln häufig ein Ausgangspunkt für die Arbeit des Administrators.
Bisher wurde dann der netsh-Befehl:
netsh advfirewall firewall show rule name=all
verwendet, um die aktuell aktiven Eigenschaften der Firewall direkt von der Kommandozeile aus anzuzeigen. Natürlich steht unter den vielen neuen Cmdlets der PowerShell 3.0 auch eines bereit, das diese Aufgabe entsprechend ausführt:
Show-NetFirewallRule -Policystore ActiveStore
Dieser Befehl zeigt dann alle Firewall-Regeln an, die auf dem Rechner aktiv sind, wobei unter "ActiveStore" sämtliche Policy Stores zusammengefasst werden, die sich auf diesen Computer beziehen. Die Ausgabe dieses Kommandos ist relativ umfangreich, da alle Details angezeigt werden.
Firewall und Firewall-Regeln aktivieren und deaktivieren
Eine weitere häufige Aufgabe ist das Aktivieren und Deaktivieren der Windows-Firewall. Es gehört zwar ohne Zweifel zur üblichen Vorgehensweise, die Firewall eingeschaltet zu lassen.
Aber alle System-Profis kennen folgende Situation: Es sollen Performance Tests von neuen Applikationen durchgeführt werden ohne weitere Beeinflussung - dann wird die Firewall, ebenso wie andere Schutzvorrichtungen auch, schnell mal für einen überschaubaren Zeitraum l abgeschaltet. Praktisch, wenn dann auch auf der Kommandozeile ein entsprechender Befehl zur Verfügung steht. Bei der netsh so er folgendermaßen aus:
netsh advfirewall set allprofiles state on
netsh advfirewall set allprofiles state off
Kommt die neue PowerShell zum Einsatz, so ist hier das Cmdlet Set-NetFirewallProfile die beste Wahl, um die Firewall schnell ein- beziehungsweise auszuschalten:
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
Programme per Firewall aussperren
Einer der Haupteinsatzzwecke einer Firewall besteht darin, bestimmte Ports, Programme oder Protokolle zu blockieren oder freizugeben, um damit auch die Sicherheit des betreffenden System oder Netzwerks zu erhöhen.
Als ein - wenn auch sehr einfaches - Beispiel haben wir hier den bekannten Ping-Befehl gewählt, um zu zeigen, wie das verwendete ICMP-Protokoll "ausgesperrt" werden kann. Zunächst zeigen wir dabei wieder die beiden netsh-Kommandos: Zuerst werden Ping-Anfragen blockiert, und mit einem zweiten Kommando wird dann die Firewall wieder für Ping-Anfragen geöffnet.
netsh advfirewall firewall add rule name="All ICMP V4 Block" dir=in action=block protocol=icmpv4
netsh advfirewall firewall add rule name="All ICMP V4 Allow" dir=in action=allow protocol=icmpv4
Natürlich stehen nun auch für die PowerShell entsprechende Cmdlets bereit, die die gleichen Einstellungen an der Firewall vornehmen. Hier das gleiche Beispiel für die PowerShell 3.0:
NewNetFirewallRule -DisplayName "Block Inbound Ping" -Direction Inbound -Protocol icmp4 -Action Block
NewNetFirewallRule -DisplayName "Allow Inbound Ping" -Direction Inbound -Protocol icmp4 -Action Allow
Das Verhalten der Firewall steuern
Gerade wenn es darum geht, das Verhalten der Firewall entsprechend den eigenen Vorstellungen zu steuern, zeigen sich die neuen PowerShell-Befehle weitaus flexibler und mächtiger, als die entsprechenden Befehle der netsh waren. So war und ist es nach wie vor möglich, mithilfe der netsh die Standardeinstellungen vorzunehmen, die global für die Firewall gelten sollen. Auch an dieser Stelle darf natürlich der Hinweis nicht fehlen, dass all diese Einstellung auch über die grafische Schnittstelle der Konsole vorgenommen werden können. So können mit dem folgenden netsh-Aufruf die Standardaktionen sowohl für den eingehenden (blockieren) als auch für den ausgehenden (erlauben) Netzwerkverkehr festgelegt werden:
netsh advfirewall set allprofiles firewallpolicy blockinbound,allowoutbound
Mit einem weiteren Aufruf werden die Berechtigungen für die Anwender gesetzt, wenn es um die Anzeige bei einem blockierten Programm geht:
netsh advfirewall set allprofiles settings inboundusernotification enable
Nun sollen (ein weiterer Befehl) Unicast-Antworten auf Broadcast- und Multicast-Netzwerkverkehr zugelassen werden:
netsh advfirewall set allprofiles settings unicastresponsetomulticast enable
und schließlich wollen wir noch erreichen, dass die Protokolldaten an einem anderen als den Standardspeicherort (%SystemRoot%\System32\LogFiles\Firewall) abgelegt werden:
netsh advfirewall set allprofiles logging filename "L:\Daten\Firewall\pfirewall.log"
All diese Einstellungen lassen sich nun auch mit der PowerShell vornehmen, wobei es hier möglich ist, diese in einem Befehl zu erledigen. Dabei wichtig: Auch wenn dieser oder andere Befehle hier wegen des Umbruchs in mehreren Zeilen dargestellt werden müssen, geben Sie sie bitte in einer einzigen Zeile ein:
Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen True -AllowUnicastResponseToMulticast True -LogFileName "L:\Daten\Firewall\pfirewall.log"
Hier zeigt sich ein weiteres Mal deutlich, wie viel kompakter Administratoren ihre Befehle mithilfe der PowerShell umsetzen können.
Sehr nützlich, wenn es um die Profile geht
Als weiteres Beispiel haben wir hier ein Cmdlet ausgewählt, dessen Einsatz sowohl unter Windows Server 2012 als auch auf einem Windows-8-System sehr praktisch sein kann:
Get-NetConnectionProfile.
Dieses Cmdlet gehört nicht direkt in die Gruppe der Kommandos für die Netzwerksicherheit, aber möglicherweise will der Systemverwalter oder Administrator bei der Arbeit mit der Windows-Firewall zunächst einmal feststellen, welches Netzwerkprofil die aktuelle Verbindung einsetzt.
Schließlich hängt es entscheidend vom eingesetzten Profil ab, wie die Firewall-Regeln zum Einsatz kommen und welche Firewall-Regeln auf dem System aktiv sind. Dies kann beispielsweise durch eine Befehlszeile dieser Art geschehen:
Get-NetAdapter | Where-Object status -EQ 'up' | Get-NetConnectionProfile -ea 0
Dieser Aufruf wird dann eine Ausgabe der folgenden Form (natürlich je nach Installation unterschiedlich) auf den Bildschirm bringen:
Name: Netzwerk
Interface Alias: Ethernet
Interface Index: 12
Network Category: Private
IPv4Connectivity: Internet
IPv6Connectivity: LocalNetwork
Das erste Cmdlet "Get-Netadapter" arbeitet dabei die vorhandenen Netzwerkadapter ab, wobei wir dann mithilfe des Where-Object-Cmdlets (kann auch durch das Alias "?" abgekürzt werden) nur diejenigen Adapter herausfiltern, die aktiv, also "up", sind. Dieses Ergebnis leiten wir sodann in einer Pipe zum bereits erwähnten Cmdlet Get-NetConnectionProfile. Es zeigt uns in diesem Beispiel an, dass auf diesem Rechner das "Private"-Profile aktiv ist.
Wir haben dem Befehl in diesem Beispiel zusätzlich die Option "-ea 0" mitgegeben: So werden eventuelle Fehlermeldungen auf dem Bildschirm unterdrückt, die durch Verbindungsprofile virtuelle Netzwerkadapter auf dem Server entstehen könnten, wenn diese nicht mit einem Netzwerk verbunden sind, aber aktiv (up) sein sollten.
Interessieren den Anwender jedoch mehr die unterschiedlichen Firewall-Profile auf dem entsprechenden System, so steht ihm dafür ebenfalls ein entsprechendes Cmdlet zur Verfügung:
Get-NetFirewallProfile | format-table name, enabled -autosize
Das Cmdlet Get-NetFirewallProfile liest die unterschiedlichen Profile aus und zeigt sie dann an. Wir haben die Ausgabe hier in das Format-Cmdlet (kann auch mit dem Alias "ft" verwendet werden) geschickt und lassen uns deshalb nur den jeweiligen Namen des Profils und seinen Status (enabled - hier wird dann entsprechend "true" oder "false" angezeigt) auf dem Bildschirm zeigen. Sehr sinnvoll ist hier der Einsatz der Option "-autosize" (kann auch als -auto abgekürzt werden), da es ansonsten passieren kann, dass die Anzeigen "sehr breit" auf das PowerShell-Fenster verteilt wird und der Anwender vergeblich die entsprechende Anzeigespalte sucht.
Sehr schön wäre in diesem Fall dann die Kombination der beiden genannten Befehle: mit Get-Netadapter die Netzwerkadapter durchsuchen, das Ergebnis nach Get-NetConnectionProfile leiten und dann dieses Ergebnis wieder direkt an Get-NetfirewallProfile übergeben. Da aber nicht alle Werte der Netzwerkprofile mit denen der Firewall-Profile übereinstimmen, führt diese Verbindung der Cmdlets immer zu einer Fehlermeldung.
Es ist aber möglich, sich mithilfe von Get-NetFirewallProfile direkt die Werte eines spezifischen Firewall-Profils anzeigen zu lassen:
Get-NetFireWallProfile public
gibt dann die für das "öffentliche" Profil gesetzten Werte auf dem Bildschirm aus.
Problematik Hilfetexte
Noch ein Anmerkung zum Abschluss: Direkt nach der Installation von Windows 8 oder Windows Server sind die PowerShell-Hilfedateien noch nicht auf dem Rechner installiert. So führt beispielsweise der Aufruf von
Get-Help Get-NetConnectionProfile
zwar zu der Anzeige der Optionen dieses Cmdlets, aber auch zu der Aussage, dass die Hilfedateien für dieses Cmdlet auf dem Rechner nicht gefunden werden konnten. Nun wird an vielen Stellen immer wieder darauf hingewiesen, dass mithilfe des Cmdlets
Update-Help
die Hilfedateien auf den aktuellen Stand gebracht werden können.
Es wird immer wieder darauf hingewiesen, dass dies nur mit Administratorrechten möglich ist. Microsoft bezeichnet diesen Mechanismus zudem als einen großen Vorteil für die PowerShell, da es auf diese Weise möglich wird, die Hilfetexte stets auf dem aktuellen Stand zu halten.
Wer diesen Weg befolgt, bekommt zwar eine ganze Reihe zusätzlicher Hilfedateien installiert, aber leider auch einige Fehlermeldungen präsentiert. Weiterhin besitzen gerade eine Reihe der neuen Befehle der PowerShell auch nach einer solchen Aktion noch keine deutschen Hilfedateien.
Auch die alternative Möglichkeit des Aufrufs
Get-Help Get-NetConnectionProfile -Online
führt nach wie vor (Anfang Juli 2013) nicht zum Erfolg: Die Option -Online leitet auf eine Technet-Website, die mit der schönen Überschrift "Windows Server Future Resources" überschrieben ist und den Besucher auf einen späteren Zeitpunkt vertröstet.
Es existieren zwar einige recht umständliche und unpraktische Wege, wenigstens einen Teil der englischen Hilfedateien so zu installieren, dass sie auch auf einem deutschen System angezeigt werden können. Peter Kriegel zeigt auf seinem PowerShell-Blog, wie das geht - aber wie er selbst sagt, kann diese Vorgehensweise auf Dauer nicht befriedigend sein. Anfang 2013 hat das PowerShell-Team wohl mit der Übersetzung der Hilfedateien begonnen. Welche zuerst übersetzt werden, entscheidet sich offensichtlich unter anderem nach der Anzahl der Seitenaufrufe in der Technet-Bibliothek. (mje)