Windows 2000 und IIS 5.0 härten

Ziel der Härtung eines Servers ist es, ihn möglichst unverwundbar gegenüber Angriffen zu machen. Angriffe wird man nie gänzlich verhindern können, doch die Auswirkungen lassen sich durch eine sichere Konfiguration begrenzen.

28.07.2003, 10:07 Uhr

Lesezeit: 9 Min.

Security

Von

Daniel Bachfeld

Ziel der Härtung eines Servers ist es, ihn möglichst unverwundbar gegenüber Angriffen zu machen. Angriffe wird man nie gänzlich verhindern können, doch die Auswirkungen lassen sich durch eine sichere Konfiguration begrenzen. Wenn ein Server eine Schwachstelle aufweist, muss dies nicht zwangsläufig dazu führen, dass ein Angreifer komplett die Kontrolle übernimmt. Dieser Artikel kann keine Anleitung zur vollständigen Härtung eines Windows Webservers sein, jedoch erste Anhaltspunkte für die weitere Vorgehensweise geben.

Prinzip der minimalen Dienste

Prinzipiell gilt: Dienste die zum Betrieb des Webservers nicht benötigt werden, werden nicht installiert, jeder andere Dienst läuft auf einem eigenen Server. Ausnahmen bestätigen die Regel: Ein Webserver kann zusammen mit einem FTP-Server installiert werden, wenn sonst keine andere Möglichkeit besteht. Immer im Auge behalten muss man, dass der Webserver durch andere Dienste bedroht wird und selbst auch andere gefährden kann. Man sollte also nicht der Versuchung erliegen, den Webserver auch noch als Domain-Controller zu betreiben.

Zur Installation des Webservers reichen wenige Dienste aus

In der Regel geht man in zwei Schritten vor: Zuerst wird die Betriebssystemplattform, also Windows 2000, gehärtet und dann der Dienst, der darauf laufen soll, -- der Webserver IIS. Microsofts Webserver ist stärker mit dem Betriebssystem verwoben, als zum Beispiel Linux und Apache. Deshalb sollte man schon bei der Installation von Windows 2000 alle Funktionen mitinstallieren, die der IIS benötigt. Eine Nachinstallation ist aber auch jederzeit möglich.

Bei der Installation von Windows 2000 stehen neben dem Internet Information Server zahlreiche andere Dienste und Windows-Komponenten zur Verfügung. Gleich am Anfang verzichtet man auf weitere Dienste: Ein SMTP-Server hat auf einem Webserver eigentlich nichts zu suchen, ebenso wenig wie FrontPage-Erweiterungen und Visual InterDev. Installieren sollte man aber das Snap-In für Microsofts Management Console (MMC), um den IIS später komfortabel konfigurieren zu können. Nameserver (DNS), Zeitserver (NTP), Managementserver (SNMP) und WINS-Server werden ebenfalls nicht aufgespielt. Von DHCP auf einem Webserver ist ebenfalls abzuraten, das kann eigentlich ein Domain-Controller erledigen und der Webserver selbst erhält ohnehin eine feste

From Scratch

Einer frischen Installation ist immer der Vorzug gegenüber einer bereits vorhandenen zu geben. Allerdings merkt mancher erst spät, dass sein Server unsicher ist und scheut den Aufwand einer Neuinstallation. Alle Schritte zur Härtung lassen sich auch im Nachhinein durchführen. Lediglich der FTP- und der SMTP-Server müssen an gesonderter Stelle in den Internet-Informationsdiensten deaktiviert werden.

Baseline Security

Im Anschluss an die Installation sind alle Service Packs und Sicherheitspatches einzuspielen. Damit man hier den Überblick behält, verwendet man Version 3.3 des Hot Fix Network Checker 'Hfnetchk' [5]. Dieses Kommandozeilen-Tool lädt eine stets aktuelle XML-Datei von Microsofts Internetseiten und vergleicht die darin gelisteten Hot Fixes mit den installierten. Abweichungen werden protokolliert und angezeigt, fehlende Hot Fixes müssen manuell nachinstalliert werden, zum Beispiel über Microsofts Updateseiten [6]. Alternativ kann auch den Security Baseline Analyzer verwendet. Dieser bietet eine grafische Oberflache für 'Hfnetchk' und prüft zusätzlich noch Systemrichtlinien und Desktopeinstellungen, -leider nur für englische Versionen von Windows.

Hfnetchk zeigt an, dass noch nicht alle Patches eingespielt sind

Einige Dienste installiert Windows 2000 ohne Nachfrage per Default. Telefoniedienste, Warndienste und Computerbrowser stehlen Ressourcen und beeinträchtigen die Sicherheit. Wehren kann man sich dagegen nur, indem man sie nachträglich deaktiviert. Was diese Dienste genau machen, füllt ganze Bücher, auf jeden Fall ist größte Vorsicht beim An- und Abschalten geboten. Vom Remote-Procedure-Call (RPC) hängen viele andere Dienste ab, beendet man ihn, beendet man unter Umständen andere Dienste, die der IIS benötigt.

Ob man seinen Webserver lokal oder remote administrieren möchte, sollte vor der Installation feststehen. Soll der Server nur konfiguriert werden oder müssen auch Inhalte gepflegt werden?. Hiervon hängt ab, welche Dienste deaktiviert werden können. Die Administration über das Webinterface stellte beim IIS eine große Angriffsfläche dar, am besten installiert man sie gar nicht erst (Internetdienste-Manager). Der Einsatz von Terminalservices wäre denkbar, kostet aber zusätzlich Lizenzen. SSH bietet nur eine Kommandozeile, genauso wie das unsichere Telnet, kann allerdings dabei helfen, die Verbindung mit einem VNC-Server zu schützen, wenn man auf eine grafische Oberfläche nicht verzichten kann [7]. Der Einsatz der MMC über das Netzwerk ist zweckmäßig, allerdings muss dann der RPC-Locator auf Port 135 laufen und auch hier sollte die Verbindung geschützt werden, zum Beispiel über IPSec. Die lokale Administration ist die sicherste, leider auch die unkomfortabelste.

Abgeschrieben

Die MMC hilft bei der Verwaltung und Sicherung des IIS

Wer unsicher ist, welche Dienste er abschalten kann, benutzt die Sicherheits-Templates von Microsoft und passt sie seinen eigenen Bedürfnissen an. Microsoft stellt mit der Sicherheitsvorlage hisecweb.inf [3] seine Vorstellung von Sicherheit für Webserver vor. Dort sind nicht nur Vorgaben über die benötigten Dienste festgehalten, sondern auch Kontorichtlinien, lokale Sicherheitsrichtlinien, und Sicherheitsoptionen. Zusätzlich wird auch noch der TCP/IP-Stack ein wenig robuster gegen DoS-Attacken gemacht. Setzen kann man diese Richtlinien mit dem MMC-Snap-In Sicherheitskonfiguration und -analyse.

Abschließend sollte noch NetBios over TCP/IP in den Netzwerkeinstellungen deaktiviert werden. Die Netzwerkfilter in den erweiterten TCP/IP-Einstellungen können zum Abblocken von Anfragen auf Dienste verwendet werden. Leistungsfähiger, aber aufwendiger, ist die Filterung mit den IPSec-Policies [8] unter Windows 2000. Wenigstens Port 80 für HTTP sollte noch offen bleiben und eventuell ein Port für die Remote-Administration.

IIS Lockdown

Im nächsten Schritt kann man sich an die Konfiguration des IIS machen. Das kostenlose Tool IISLockdown von Microsoft unterstützt den Administrator beim Härten in zwei Modi: Express und Advanced Lockdown. Der Express Lockdown verrammelt den Webserver, so dass nur noch HTML-Seiten ausgeliefert werden. Will man doch etwas mehr Funktionen, empfiehlt sich der manuell konfigurierbare Advanced Lockdown, in dem man "Other Server" in der Liste der möglichen Server auswählt.

Leseschwäche

Im Advanced Mode lässt sich der Zugriff auf Skripte wie: .idc, .ida , .htr und .htw, asp-Seiten und auch Server-Side-Includes konfigurieren. Code-Red wäre mit diesen Einstellungen nicht zum Zug gekommen. Darüber hinaus löscht das Tool auch die mitinstallierten Beispielskripte des IIS und virtuelle Verzeichnisse, deaktiviert WebDAV und verhindert, dass anonyme Benutzer Schreibrechte auf dem Server erhalten oder Systemtools wie tftp.exe oder cmd.exe starten können.

Auf Wunsch beseitigt IISLockdown unbenötigte Verzeichnisse

Ein weiteres Microsoft-Tool, namens URLScan, parst und analysiert HTTP-Requests und URLs und ist mittlerweile Bestandteil von 'IISLockdown'. Es installiert sich als ISAPI-Filter im IIS und nimmt ankommende URLs unter die Lupe. Viele erfolgreiche Angriffe auf den IIS wurden in der Vergangenheit über spezielle URLs vorgenommen. Angriffe wie '.%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir' werden nun sofort verworfen: Sowohl die Dateierweiterung .exe ist nun nicht mehr in einer URL erlaubt, als auch die Verwendung von '..'. Letzteres bereitet allerdings Probleme, wenn in HTML-Seiten relative URLs verwendet werden und Bilder zum Beispiel über den Pfad "../images/" eingebunden werden. Der Wurm Nimda hätte auf gesicherten Servern keine Chance gehabt. Möglich sind nach der Installation von URLScan nur noch die HTTP-Methoden POST, GET und HEADER. Über die urlscan.ini darf man die Konfiguration editieren und URLScan seinen Sicherheitsanforderungen anpassen.

URL-Scan wird als ISAP-Filter installiert.

IISLock und URLScan sind in einigen Teilen redundant: IISLockdown löscht das Mapping auf Skripte und URLScan filtert den Zugriff darauf aus. Doch diese Redundanz schadet nicht, im Gegenteil: Je mehr Hürden ein System einem Angreifer in den Weg stellt, desto besser.

Attacke

Grundsätzlich sollte man seine eigene Arbeit überprüfen. Sowohl Port-Scanner und spezielle Schwachstellenscanner geben einen ersten Überblick, ob die Härtung gelungen ist. Auch sollte man probieren, Skripte aufzurufen und Fehlerzustände zu provozieren. Am besten führt diese Tests jemand durch, der an der Härtung des Servers nicht beteiligt war. Man selbst neigt oft dazu, Tests an Funktionen auszulassen, von denen man überzeugt ist, dass sie sicher oder ohnehin nicht installiert seien. Mit relativ wenig Aufwand sind Windows 2000 und IIS jetzt erheblich sicherer als vorher. Leider ist die Kreativität der Angreifer so groß wie die Komplexität des Servers: Mit einem Vorfall ist immer zu rechnen. Sicherheit ist ein Prozess und erfordert die Pflege und Wartung des Servers. Für den ersten Betrieb sollte die Konfiguration mit den erwähnten Tools ausreichend sein. Weitere Hinweise und Leitfäden finden sich in [1], [2] und [3], die dazu passenden Tools kann man unter [4] herunterladen.

Fazit

Natürlich läßt sich der Server noch weiter härten, solche Anleitungen füllen ganze DIN-A4-Ordner, es Bedarf hierzu aber wesentlich mehr Aufwand und Erfahrung des Administrators. Bisher nicht betrachtet wurden Zugriffsrechte auf Dateien, Verzeichnisse und Registry Keys. Auch könnten Gruppen und Benutzer auf dem Server gelöscht oder umbenannt werden und das Netzwerk ließe sich weiter gegen Angriffe abschotten.