Bundesamt für Sicherheit in der Informationstechnik

M 2.367 Einsatz von Kommandos und Skripten ab Windows Server 2003

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

In der Praxis werden häufig Kommandos und Skripte für kleine Aufgaben eingesetzt, zum Beispiel um bestimmte Parameter zu setzen oder anzuzeigen. Skripte ermöglichen es, Kommandos automatisiert ablaufen zu lassen. Fehlbedienung und Unkenntnis können das Risiko bei einem einzelnen Kommando in einem Skript vervielfachen. Deshalb müssen Skripte mit Bedacht eingesetzt werden, damit ihre Auswirkungen kontrollierbar und nachvollziehbar bleiben. Wird der Aufwand für Planung, Entwurf und Wartung in Kauf genommen, können administrative Aufgaben mittels Skripten vereinheitlicht und standardisiert werden.

Kommando

Mit Kommandos wird der Aufruf von Programmen mittels des Feldes "Ausführen" oder über die Befehlszeile der Eingabeaufforderung bezeichnet. Während unter DOS der Befehlszeileninterpreter command.com agierte, steht unter Windows die wesentlich leistungsfähigere CMD.exe zur Verfügung. Alles, was in dieser CMD-Shell aufgerufen werden kann, wird als Kommando bezeichnet. Es muss zwischen den impliziten Kommandos und Steuerungskonstrukten der CMD-Shell, , Kommandos des Betriebssystems und Kommandos von Drittherstellern unterschieden werden. Kommandos können in einer lesbaren Datei (Batch-Datei, spezielle Skript-Datei) zusammengestellt werden.

Skript

Ein Skript ist eine Klartext-Datei, die mit einem beliebigen Editor wie notepad.exe erstellt werden kann. Die in einem Skript enthaltenen Anweisungen werden beim Aufruf durch einen entsprechenden Interpreter ausgeführt. Skripte werden unter Windows hauptsächlich eingesetzt, um die Administration zu automatisieren. Sie können vor allem die Ausführung sich ständig wiederholender Administrationsaufgaben sehr erleichtern. Werden sie automatisch ausgeführt, zum Beispiel über Geplante Tasks, arbeiten sie auch in Abwesenheit eines Administrators. Die Wiederverwendung von Skripten gewährleistet die Nachvollziehbarkeit und einheitliche Qualität der durchgeführten Aufgaben.

Anforderungen

Für Skript-Interpreter, mitgelieferte Skripte und Skripte aus Zusatzpaketen des Herstellers ( z. B. MBSA, Support Tools, Ressource Kit) sowie eigenentwickelte Skripte sollten die gleichen Anforderungen gelten wie für eine Standardsoftware (siehe B 1.10 Standardsoftware ). Es handelt sich letztlich um Standardsoftware für die Administration. Die Anforderungen und Bedingungen, um Skripte zu erstellen und anzuwenden, sind zu analysieren und daraus verbindliche Festlegungen zu treffen. Ebenso sind alle eigenentwickelten Skripte sowie Werkzeuge oder Skripte von Drittherstellern angemessen zu dokumentieren und zu testen (siehe M 2.83 Testen von Standardsoftware ).

Skripte im Umfeld eines betriebskritischen IT-Systems dürfen nur von administrativem Personal geschrieben und gepflegt werden, das für die Programmierung von Skripten ausreichend geschult ist und über genug Erfahrung verfügt (siehe G 2.67 Ungeeignete Verwaltung von Zutritts-, Zugangs- und Zugriffsrechten ). Es muss ganz besonders im Umfeld der Administration und deren Automatisierung sichergestellt werden, dass keine unerlaubte oder nicht freigegebene Software in Form von Werkzeugen oder komplexen Skripten angewendet wird. Auf den Einsatz von Software ohne nachvollziehbare Herkunft ist zu verzichten. Ebenso sollte die Umgebung, in der Skripte ausgeführt werden dürfen, ausreichend gegen Missbrauch und Schadsoftware geschützt sein.

Der Rahmen für den Einsatz von Skripten sollte in einer Sicherheitsrichtlinie festgelegt werden. Es ist mindestens festzulegen, für welchen Einsatzzweck und aus welcher Herkunft Skripte verwendet und welche Skriptumgebungen und Skriptsprachen benutzt werden dürfen. Weiterhin ist festzulegen, welche Anforderungen an die Entwicklung und Freigabe für Skripte in bestimmten Einsatzbereichen gelten sollen. Wenn nichts anderes festgelegt wird, sind immer die Maßnahmen aus B 1.10 Standardsoftware anzuwenden. Es ist allerdings zu berücksichtigen, dass diese unter Umständen nicht für jeden Einsatzbereich effektiv und praktikabel sind, zum Beispiel bei Anmeldeskripten.

Es sollte überlegt werden, generell keine unsignierten Skripte zuzulassen. Die Signaturen basieren auf Sicherheitszertifikaten. Skripte des Herstellers sind bereits signiert. Es empfiehlt sich, die eigenen Zertifikate aus Vorlagen einer Windows Server 2003-Zertifizierungsstelle zu erstellen. Zum Signieren werden spezielle Programmier-Objekte der Krypto-API von Windows verwendet, auf die mittels Skripte zugegriffen werden kann. Nähere Informationen sind für Windows Server 2003 dem Platform Software Developement Kit (Platform SDK) oder ab Windows Server 2008 dem Windows SDK zu entnehmen. Die Richtlinie kann ab Windows XP/Server 2003 mit Hilfe einer Softwareeinschränkungsrichtlinie administrativ umgesetzt werden.

Grundsätze

Für alle Skripte sollte beachtet werden, dass sie in der Regel zwar aufwärts, aber oft wegen ihrer Weiterentwicklung bei der Nutzung neuer Funktionen nicht abwärts kompatibel sind.

Skripte werden immer im Sicherheitskontext der aufrufenden Benutzersitzung ausgeführt, sie verfügen während des Ablaufs über die Berechtigungen dieses Sicherheitskontextes. Wird ein Skript durch einen Dienst oder einen laufenden Prozess gestartet, dann gilt der Sicherheitskontext dieses Dienstes oder Prozesses auch für das Skript. Für viele Funktionen, auf die mittels Skript zugegriffen wird, werden administrative Berechtigungen auf einzelne Objekte oder auf dem gesamten Server benötigt.

Werden Skripte für Benutzer (z. B. An-/Abmeldeskripte) oder Dienste (z. B. im Zusammenhang mit Datensicherung) bereitgestellt, dürfen innerhalb des Skriptablaufs keine unerlaubten erweiterten Berechtigungen vergeben.

Häufig werden Skripte bei Domänenanmeldungen oder über Gruppenrichtlinien des Active Directory automatisch verteilt und ausgeführt.

Es sollte dafür gesorgt werden, dass den Benutzern Quelltexte von administrativen Skripten verborgen bleiben und dass die Skriptausführung den Betrieb nicht beeinträchtigt. Entsprechende Einstellungen befinden sich zum Beispiel in den mitgelieferten administrativen Vorlagen unter Administrative Vorlagen | System | Skripts.

Ab Windows Server 2008 ist zu beachten, dass auch Skripte der Benutzerkontensteuerung unterliegen (siehe M 4.340 Einsatz der Windows-Benutzerkontensteuerung UAC ab Windows Vista ). Dies kann zur Folge haben, dass für frühere Windows-Versionen entwickelte Skripte zunächst nicht mehr funktionieren, weil ihnen administrative Berechtigungen fehlen.

Systemeigene Mittel für Skripts:

Unter Windows Server 2003 und höher stehen nach einer Standardinstallation umfangreiche Möglichkeiten zur Verfügung, um Skripte zu erstellen und auszuführen:

Es handelt sich um eine Skriptumgebung des Herstellers, die auch eine Dokumentation beinhaltet. Die Möglichkeiten der Batch-Programmierung waren in älteren Versionen eingeschränkt, sind aber inzwischen sehr mächtig, es steht zum Beispiel eine FOR-Anweisung zur Verfügung. Es ist keine Installation erforderlich.

VBScript ist eine einfache Skriptsprache. Sie besitzt keine eingebauten Funktionen zur Administration. Diese werden erst in der Kombination mit Windows Scripting Host (WSH) und den Schnittstellen zur Windows Management Instrumentation (WMI), Active Directory Service Interface (ADSI) und anderen Schnittstellen des Betriebssystems erschlossen. Dazu müssen Objekte in das Skript eingebunden werden, die über diese Schnittstellen bereitgestellt werden. Ohne gute Kenntnisse der entsprechenden Objektmodelle ist deren Nutzung zwar mit Hilfe von umfangreichen Vorlagen und Beispielen möglich, jedoch nicht zu empfehlen (z. B. wegen ähnlicher Methoden wie GetObject versus CreateObject). JScript ist mit VBScript hinsichtlich des Einsatzzwecks gleichzusetzen. Der Unterschied besteht in der an die Programmiersprache Java angelehnten Syntax. VBScript und JScript werden seit dem Erscheinen von Windows Server 2003 nicht mehr weiterentwickelt und sind daher unter dem Aspekt der Zukunftssicherheit kritisch zu bewerten.

Skripte (z. B. in Form von .vbs- oder .js-Dateien) werden über CScript.exe (Kommandozeilenausgabe) oder WScript.exe (grafisches Ausgabefenster) aufgerufen und abgearbeitet. Durch diese beiden Programme wird der WSH in Ausführung gebracht. WSH ist die standardmäßige Umgebung zur Skriptverarbeitung. Er besitzt eigene Programmfunktionen und kann Erweiterungen für WSH-kompatible Sprachen nachladen (VBScript, JScript). Der WSH ist ein Interpreter. Er kann COM-Objekte verwenden und hat Zugriff auf eine Reihe von Systemschnittstellen (siehe oben). WScript.exe und CSript.exe enthalten einen rudimentären Debugger zum Testen von Skripten.

Im Zusammenhang mit WSH sind eine Reihe von Aktualisierungen und Fehlerkorrekturen für Windows NT/2000/XP/2003 erschienen, die Sicherheitsprobleme behoben und zum Teil die Überarbeitung bestehender Skripte erforderlich gemacht haben. Dies sollte bei der Entwicklung von Skripten für den WSH berücksichtigt werden.

WMI (Windows-Verwaltungsinstrumentation) ist als zentrale Verwaltungstechnologie ab Windows Server 2003 integriert. WMI ermöglicht einen einheitlichen Zugriff auf die Konfiguration, Verwaltung und Überwachung fast aller Windows-Ressourcen. WMI gibt es bereits seit 1998 (Windows NT 4.0 SP4). Die WMI-Architektur ist komplex, sie besteht aus drei Schichten (Ressourcen, Infrastruktur, Nutzer) und ist objektorientiert aufgebaut. Sie wurde über DLLs für die Anbieterbeschreibungen (%SystemRoot%\system32\wbem) und den WMI-Dienst (winmgmt.exe) implementiert. Für den Zugriff mittels Windows-Skripten werden kompatible Skriptumgebungen wie WSH oder ActivePerl verwendet. Mit dem Snap-in wmimgmt.msc, dem WMI-Testprogramm wbemtest.exe oder dem Befehlszeilen-Werkzeug wmic.exe können WMI-Konfigurationen vorgenommen und verfügbare Klassendefinitionen untersucht werden.

Mit ADSI wird eine skriptbasierte Verwaltung des Verzeichnisdienstes Active Directory analog der WMI-Technologie ermöglicht.

Neuerungen mit Windows Server 2008

Mit Windows PowerShell wird eine weiterentwickelte Kommandozeilen- und Skriptingumgebung für die Windows-Plattform angeboten, welche VBScript, JScript und den WSH ablöst. PowerShell übernimmt einige aus der Unix-Welt bekannte Konzepte (z. B. Pipes) und setzt auf dem .NET-Objektmodell auf. Ab Windows Server 2008 ist PowerShell optional verfügbar, ab Server 2008 R2 ist sie im Standardlieferumfang enthalten. :

Mit Scriptomatic wird ein Werkzeug zum Generieren von Skripten bereitgestellt. Das Werkzeug unterstützt WMI und ADSI. Eine Version für die PowerShell ist ebenfalls verfügbar.

Für viele Werkzeuge und Skripte, die von Microsoft bereitgestellt werden, gibt es keine generelle Produktunterstützung. Dies ist im Einzelfall mit dem Hersteller zu klären. Teilweise wurden die Werkzeuge zu Lehrzwecken bereitgestellt, besitzen keine oder nur unzureichende Fehlerbehandlungen und sind nicht leistungsoptimiert.

WSH abschalten

Die Skript-Fähigkeiten von Windows werden leider auch zur Verbreitung von Schadsoftware () missbraucht. Auf Clients werden Skripte daher häufig eingeschränkt oder unterbunden. In einer Client/Server-Umgebung kann der administrative und organisatorische Nutzen von Skripten das erhöhte Risiko und den entsprechenden Sicherheitsaufwand rechtfertigen. Werden nur Kommandozeilenskripte benötigt, sollte der WSH auf dem Server blockiert werden, um die Sicherheit zu erhöhen.

Der WSH kann auf verschiedene Weise blockiert werden:

  • Erstellen des Registrierschlüssels (ab Windows 2000/XP/Server 2003)
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\ Settings\Enabled
    (Format Reg_DWORD)
    Der Wert wird auf Null gesetzt. Die geänderte Registrierungseinstellung sollte in einer administrativen Vorlage abgebildet werden.

Alternative Skriptumgebungen

Alternative Skriptumgebungen wie Perl, KiXtart und andere verringern die Angriffsfläche nicht automatisch. Sie greifen genauso auf Betriebssystemfunktionen zu und können eigene Sicherheitslücken enthalten. Es gelten die oben genannten Anforderungen und Grundsätze.

Dokumentation

Für die Entwicklung sowohl von eigenentwickelten als auch von Skripten von Fremdherstellern sind die in der Software-Entwicklung gängigen Dokumentationsgrundsätze einzuhalten. Mindestens sollten ein Anforderungskatalog, eine Funktionsbeschreibung und Benutzerhilfe, die Ausführungsbedingungen sowie eine Versionskontrolle vorliegen. In der Dokumentation der jeweiligen Windows-Komponente oder des jeweiligen Betriebskonzeptes muss anhand von Skriptname und Versionsnummer erkennbar sein, welches Skript eingesetzt wird.

Prüffragen:

  • Ist die Umgebung, in der Skripte ausgeführt werden dürfen, ausreichend gegen Missbrauch und Schadsoftware geschützt?

  • Wird für die Programmierung von Skripten ausschließlich ausreichend geschultes Personal eingesetzt?

  • Werden nur freigegebene Skripte und Werkzeuge eingesetzt?

  • Ist in der Sicherheitsrichtlinie festgelegt, für welchen Einsatzzweck und aus welcher Herkunft Skripte verwendet und welche Skriptumgebungen bzw. Skriptsprachen benutzt werden dürfen?

  • Ist sichergestellt, dass in den Quelltexten der Skripte keine administrativen Kennungen hinterlegt werden?

  • Ist der Windows Scripting Host (WSH) auf den Servern deaktiviert, sofern dieser nicht benötigt wird?

  • Sind alle eigenentwickelten Skripte sowie Werkzeuge oder Skripte von Drittherstellern angemessen dokumentiert und getestet?

Stand: 13. EL Stand 2013