M 2.367 Einsatz von Kommandos und Skripten unter Windows Server 2003
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
In der Praxis werden häufig Kommandos und Skripte für kleine Aufgaben wie z. B. das Setzen oder Anzeigen eines bestimmten Parameters eingesetzt. Skripte ermöglichen den automatisierten Ablauf von Kommandos und werden so zu machtvollen Werkzeugen. Das Schadenspotenzial durch Fehlbedienung und Unkenntnis bei einem einzelnen Kommando kann sich in einem Skript potenzieren. 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
Unter Kommandos versteht man den Aufruf von Programmen mittels des Feldes Ausführen... oder über die Befehlszeile der Eingabeaufforderung. Diese wird herkömmlich auch als "DOS-Box" bezeichnet. Während unter DOS der Befehlszeileninterpreter command.com agierte, steht unter Windows Server 2003 die wesentlich leistungsfähigere CMD.exe zur Verfügung. Alles, was in dieser CMD-Shell aufgerufen werden kann, wird als Kommando bezeichnet. Es muss dabei unterschieden werden zwischen den impliziten Kommandos und Steuerungskonstrukten der CMD-Shell, Kommandos des Betriebssystems und Kommandos von Drittherstellern. Kommandos können in einer lesbaren Datei (Batch-Datei, spezielle Skript-Datei) zusammengestellt werden.
Skript
Ein Skript ist eine Klartext-Datei, welche mit einem beliebigen Editor (z. B. 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 für die Automatisierung der Administration eingesetzt. Sie können vor allem die Ausführung sich ständig wiederholender Administrationsaufgaben sehr erleichtern. Werden sie automatisch ausgeführt, z. B. ü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 eigenentwickelter 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 unter Windows Server 2003. Die Anforderungen und Bedingungen für die Erstellung und Anwendung von Skripten sind zu analysieren und daraus verbindliche
Festlegungen zu treffen (siehe M 2.83 Testen von Standardsoftware).
Skripte im Umfeld eines betriebskritischen IT-Systems dürfen nicht von administrativem Personal geschrieben und gepflegt werden, das für die Programmierung von Skripten nicht ausreichend geschult ist und über wenig Erfahrung verfügt (siehe G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten). Es muss ganz besonders im Umfeld der Administration und deren Automatisierung sichergestellt werden, dass keine unerlaubte bzw. nicht freigegebene Software in Form von Werkzeugen oder komplexen Skripten angewendet wird. Auf den Einsatz von Software ohne nachvollziehbare Herkunft ist zu verzichten.
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 bzw. 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, z. B. 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 Crypto-API von Windows Server 2003 verwendet, auf die mittels Skripten zugegriffen werden kann. Nähere Informationen sind dem Platform Software Developement Kit (Platform SDK) für Windows Server 2003 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, d. h. 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 einzelnen Objekten 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 oder administrative Kennungen kompromittiert werden.
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 Quelltexte von administrativen Skripten den Benutzern verborgen bleiben und dass die Skriptausführung den Betrieb nicht beeinträchtigt. Entsprechende Einstellungen befinden sich z. B. in den mitgelieferten administrativen Vorlagen unter Administrative Vorlagen | System | Skripts.
Systemeigene Mittel für Skripts:
Unter Windows Server 2003 stehen nach einer Standardinstallation umfangreiche Möglichkeiten zum Erstellen und Ausführen von Skripten zur Verfügung:
- Eingabeaufforderung/CMD-Shell und Batch-Dateien (.BAT, .CMD)
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 (z. B. steht eine FOR-Anweisung zur Verfügung). Es ist keine Installation erforderlich. - Microsoft Visual Basic Scripting (VBScript) und JScript
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. - Windows Scripting Host (WSH)
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 somit 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 z. T. die Überarbeitung bestehender Skripte erforderlich gemacht haben. Dies sollte bei der Entwicklung von Skripten für den WSH berücksichtigt werden. - Scripting mit Windows Management Instrumentation (WMI)
WMI (Windows-Verwaltungsinstrumentation) ist als zentrale Verwaltungs-technologie in Windows Server 2003 integriert. WMI enthält für 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 bzw. verfügbare Klassendefinitionen untersucht werden. - Scripting mit Active Directory Service Interface (ADSI)
Mit ADSI wird eine scriptbasierte Verwaltung des Verzeichnisdienstes Active Directory analog der WMI-Technologie ermöglicht.
Microsoft-Werkzeuge, die nicht Standardbestandteil von Windows Server 2003 sind:
-
Werkzeug Scriptomatic
Mit Scriptomatic wird ein Werkzeug zum Generieren von Skripten bereitgestellt. Das Werkzeug unterstützt WMI und ADSI. - Windows PowerShell
Mit Windows PowerShell wird eine weiterentwickelte Kommandozeilen- und Skriptingumgebung für die Windows-Plattform angeboten, welche VBScript, JScript und den WSH ablöst.
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 (G 5.23 Computer-Viren) 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 (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.
- Softwareeinschränkungsrichtlinie (Windows XP/Server 2003)
- Mit entsprechenden Regeln können die Dateien Wscript.exe und Cscript.exe oder Skriptdateien selbst an der Ausführung gehindert werden (siehe Maßnahme M 4.286 Verwendung der Softwareeinschränkungsrichtlinie unter Windows Server 2003).
Alternative Skriptumgebungen
Alternative Skriptumgebungen wie Perl, KiXtart und andere verringern die Angriffsfläche von Windows Server 2003 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 von Skripten empfehlen sich die in der Software-Entwicklung gängigen Dokumentationsgrundsätze. 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.
Ergänzende Kontrollfragen
- Gibt es Festlegungen zur Benutzung von Skripten auf organisationskritischen Servern?
- Sind alle eigenentwickelten Skripte sowie Werkzeuge oder Skripte von Drittherstellern angemessen dokumentiert und getestet?
- Wurde der Einsatz der Skripte und Werkzeuge formell freigegeben?
- Ist die Umgebung, in der Skripte ausgeführt werden dürfen, ausreichend gegen Missbrauch und Schadsoftware geschützt?