Gerade die letzten Wochen mit Code Red und Nimda haben gezeigt, wie wichtig es ist, die eigenen Webserver optimal zu sichern. Das betrifft insbesondere den Internet Information Server (IIS) von Microsoft. Aber auch bei anderen Systemen wie beispielsweise dem weit verbreiteten Apache Server muss man sich intensiv mit der Sicherheit auseinandersetzen. Auch wenn diese derzeit nicht im Blickpunkt stehen - automatisch bieten auch sie keine Sicherheit.
Das hat auch die Vergangenheit gezeigt. Der Internet Information Server und die Internetinformationsdienste sind schon seit einiger Zeit das bevorzugte Angriffsziel. Entscheidend dafür ist einerseits, dass es sich um Produkte von Microsoft und damit aus Imagegründen um besonders beliebte Angriffsziele handelt. Eine wichtige Rolle spielt aber auch, dass es in den Produkten einige Problembereiche unter dem Aspekt der Sicherheit gibt, die Microsoft einfach noch nicht schliessen konnte. Die wiederkehrenden Probleme mit Pufferüberläufen sind symptomatisch. Hier hat der Apache Server mit seiner schlankeren Struktur und dem Open-Source-Ansatz Vorteile - was aber nicht heisst, dass dieses System per se sicher ist oder nicht auch zu einem Angriffsziel werden könnte. Immerhin ist es auch nicht allzu lange her, dass ein Wurm Linux-Systeme angegriffen hat.
Es gibt drei wichtige Voraussetzungen für sichere Systeme. Die erste ist eine gute Sicherheitskonzeption, die immer mehrstufige Sicherheitskonzepte umfasst - und natürlich deren Umsetzung. Die zweite Voraussetzung ist die kontinuierliche Überwachung von Systemen, um aussergewöhnliche Situationen erkennen und darauf reagieren zu können. Auch diese Analyse muss auf mehreren Ebenen erfolgen, von der Firewall bis zum Basisbetriebssystem der Webserver. Die dritte Anforderung ist, die Systeme aktuell zu halten.
Bezeichnenderweise gab es beispielsweise im Fall von Code Red schon früher ähnlich gelagerte Szenarien. Mit einer entsprechenden Konfiguration der Systeme hätten hier viele der Probleme vermieden werden können. In keinem Fall aber hätte es zum wiederholten Auftreten dieser Problematik kommen dürfen, da bereits unmittelbar nach den ersten Warnungen Patches und Konfigurationshinweise für die Sicherung von Systemen bereitgestellt und auch über Sicherheits-Mailing-Listen verteilt wurden. Gerade Code Red hat überdeutlich gezeigt, dass es eben nicht nur am System liegt, sondern in hohem Masse auch an der Administration.
Die wichtigsten Quellen für aktuelle Sicherheitsinformationen sind im Umfeld des IIS einerseits Microsoft selber und zum anderen NTBugTraq. Administratoren können sich bei beiden Sites in Mailing-Listen eintragen lassen, um über aktuelle Sicherheitsprobleme im Umfeld von Microsoft-Produkten informiert zu werden. Auf der Sicherheits-Website von Microsoft finden sich auch immer die aktuellsten Patches, Tools für eine bessere Sicherheitskonfiguration und Leitfäden, um Microsoft-Systeme zu sichern. Die Analyse von auftretenden Problemen zeigt aber, dass selbst diese naheliegenden Schritte oft vernachlässigt werden. Microsoft informiert auf dieser Website auch sehr offen und insbesondere schnell über Sicherheitsprobleme. Für Administratoren von IIS-Servern ist es unbedingt sinnvoll, sich in beiden Mailing-Listen einzutragen.
Generell von Bedeutung ist auch Cert. Diese Website ist eine schon fast klassisch zu nennende Informationsquelle zur Sicherheit von Computersystemen. Informationen werden für alle Plattformen geliefert, allerdings in der Regel nur für schwerwiegende Probleme - wie beispielsweise Code Red. Auch diese Website zeichnet sich, ähnlich wie die NTBugTraq-Mailing-List, durch ein hohes Mass an Objektivität aus.
Im Apache-Umfeld muss zudem noch auf die Apache-Website und hier insbesondere auf http://httpd.apache.org/docs/misc/security_tips.html verwiesen werden.
Zu den grundlegenden Massnahmen für die Sicherung von Webservern gehören zunächst zwei. Zum einen müssen die Webserver in ein Firewall-Konzept eingebunden werden. Das betrifft in höherem Masse den Schutz interner Dienste als eine öffentliche Website.
Da aber viele Webserver nicht nur eine für jeden zugängliche Website hosten, sondern auch B2B- und B2C-Dienste mit Authentifizierung anbieten, bedarf es hier einer genauen Planung, welche Funktionen von Systemen vor, innerhalb und hinter der Firewall angeboten werden und wie die Firewall genau zu konfigurieren ist.
Diese Arbeit sollte unbedingt Profis überlassen werden, denn die richtige Konfiguration von Firewalls ist, trotz zunehmend einfacher Administrationsschnittstellen, eine komplexe Angelegenheit und erfordert ein umfassendes Verständnis verschiedenster Protokolle ebenso wie der Arbeitsweisen von Firewalls. Kritisch zu betrachten sind in diesem Zusammenhang einfache, weitgehend vorkonfigurierte Firewalls, da diese immer nur Standardsituationen abfangen können.
Wichtig ist insbesondere auch die Deaktivierung des externen Zugriffs auf Ports, die nicht unbedingt erforderlich sind - und das sind im Zweifelsfall alle ausser den Ports 80 und 443, über die HTTP und HTTPS (SSL) abgewickelt werden. So müssen beispielsweise bei Windows-Servern die Ports 135 bis 139 deaktiviert werden, da über diese wichtige Administrationsfunktionen verfügbar sind.
Die zweite Massnahme ist die sichere Konfiguration der Betriebssysteme, auf denen die Webserver ausgeführt werden. Hier geht es insbesondere um die Deaktivierung von Diensten. Generell gilt, dass so wenig Funktionen wie möglich auf Webservern laufen sollten, da Angreifer dann auch entsprechend wenig Handlungsmöglichkeiten erhalten. Ein kritischer Punkt ist dabei die Frage, inwieweit Windows-basierende Webserver in Domänen eingebunden werden. Eine Antwort darauf kann nur in einem umfassenden Sicherheitskonzept geliefert werden, da es durchaus Konstellationen gibt, in denen die Einbindung in eine Domäne sinnvoll sein kann - man betrachte hier nur das Zusammenspiel mit dem ISA-Server (Internet Security and Acceleration Server) von Microsoft.
Wenn kein anonymer Zugriff auf Webserver erfolgen darf, ist die nächste Frage diejenige nach der Authentifizierung. Die verfügbaren Mechanismen hängen dabei stark vom eingesetzten System ab. So gibt es bei den Internetinformationsdiensten 5.0 von Windows 2000 - und natürlich auch beim Internet Information Server 4.0 von Windows NT - eine enge Integration mit den betriebssystemspezifischen Systemen für das Benutzermanagement.
Die Internetinformationsdienste unterstützen zudem mit der integrierten Windows-Authentifizierung einen speziellen Mechanismus, bei dem NTLM für den Austausch der Anmeldeinformationen verwendet wird. Dieser Ansatz ist allerdings nur mit dem Internet Explorer kompatibel. Zudem ist NTLM unter dem Aspekt der Sicherheit auch nicht frei von Problemen. Die bei der Version 5 hinzugekommene Digest-Authentifizierung wird derzeit ausserhalb des Microsoft-Umfelds ebenfalls noch kaum unterstützt.
Der Standard für die Authentifizierung ist daher derzeit noch das Übermitteln von Kennwörtern im Klartext. In Verbindung mit SSL kann hier aber eine Verschlüsselung stattfinden, so dass dies sicherheitstechnisch unkritisch ist. Die Alternative dazu, die ebenfalls von allen Systemen unterstützt wird, ist der Einsatz von SSLv3 mit Client-Zertifikaten. Das setzt aber voraus, dass alle Clients über digitale Zertifikate verfügen. Dieser Ansatz ist daher insbesondere innerhalb von geschlossenen Benutzergruppen wie beispielsweise der B2B-Kommunikation mit einer begrenzten Anzahl von Partnern und bei Verwendung einer eigenen PKI (Public Key Infrastructure) sinnvoll.
Beim IIS kann eine Konfiguration sowohl auf der Ebene des Servers als auch einzelner Sites erfolgen. Dazu wird jeweils über das Dialogfeld Verzeichnissicherheit gearbeitet. Dort kann sowohl die Form der Authentifizierung konfiguriert als auch eine Zugriffsbeschränkung für ausgewählte IP-Adressen und Domänennamen definiert werden.
Die SSL-Konfiguration kann nur bei den einzelnen Websites erfolgen, da die Zertifikate pro Website ausgestellt werden. Die Voraussetzung ist, dass entweder bereits ein Zertifikat von einer CA verfügbar oder aber eine eigene PKI vorhanden ist, um die erforderlichen Server- und gegebenenfalls Client-Zertifikate auszustellen. Eine eigene PKI ist für Server-Zertifikate nur sinnvoll, wenn innerhalb einer geschlossenen Infrastruktur gearbeitet wird, da der öffentliche Schlüssel auch auf den Clients installiert werden muss.
Daneben müssen insbesondere alle verfügbaren Patches installiert werden. Diese finden sich wie erwähnt unter www.microsoft.com/security. Das Security-Bulletin MS01-044 enthält dabei einen kumulierten Patch, der alle vorangegangenen Fehlerkorrekturen einschliesst. Daher müssen nur dieser Patch und die nachfolgenden, die sich auf die Internetinformationsdienste beziehen, eingerichtet werden.
Für Apache-Server empfiehlt es sich, dem Dokument auf der Website zu folgen. Eine der wichtigsten Massnahmen ist der Schutz der von root ausgeführten Dateien, da diese ansonsten eine Angriffsmöglichkeit bieten. Darüber hinaus ist den Server-Side-Includes und dem Umgang mit CGI-Dateien besonderes Augenmerk zu widmen. Auch hier liefert das genannte Dokument umfassende Informationen.
Letztlich ist ein konsequentes Vorgehen bei der Konfiguration der Sicherheitseinstellungen die Basis dafür, dass Webserver sicher sind. Dabei darf man sich nie in Sicherheit wiegen - denn dass es für ein System nur wenige bekannte Angriffsszenarien gibt, heisst nicht, dass es sicher ist. Denn auch beim IIS gab es zu Beginn kaum bekannte Lücken. Ohne eine kontinuierliche Aktualisierung der Sicherheitseinstellungen geht es daher nicht.
