Sicherheitslücken im World Wide Web
1. Welche Sicherheitsrisiken gibt es bei der Internetnutzung?
Weitere Sicherheitsvorkehrungen:
Zur weiteren Sicherheit kann der Nutzer auch folgende Hinweise von einer Studie der Uni Münster beachten:
- Stellen Sie stets einen Proxyserver ein
- Wählen Sie hohe Sicherheitsstufen aus
- Aktivieren Sie die Nachfrage vor dem Aufruf externer Programme zurDarstellung von Dateien.
- Stellen Sie das automatische Starten von heruntergeladenen Programmen ab.
- Überprüfen Sie Zertifikate, kontrollieren Sie die Rechte der einzelnen Zertifikate
- Schalten Sie alle Warnmeldungen ein. Dies geht besonders gut mit einer Firewall ider einem IDS (s. IDS).
- Aktivieren Sie die Java-Protokollierung
- Stellen Sie das automatisches Update des Browsers ab
Zur weiteren Sicherheit kann ein Anwender auch ein Intrusion Detection System(IDS) benutzen. Ein IDS besteht aus den folgenden drei Hauptkomponenten:
· Einer Komponente zur Datensammlung, die Informationen z.B. über den allgemeinen Systemzustand und die Betriebsmittelvergabe sammelt. Diese Information kann quantitativer Art sein, z.B.: der Port 4711 empfing während der letzten Sekunde 20 SYN-Pakete. Es kann sich allerdings auch um qualitative Aussagen handeln, etwa der folgenden Art: Benutzer Felix schickte eine E-Mail ab, kurz nachdem der sich beim System angemeldet hat.
· Einer Komponente zur Datenanalyse, welche die gesammelten Daten im Hinblick auf mögliche Angriffe analysiert.
· Einer Komponente zur Ergebnisdarstellung, die das Analyseergebnis
benutzergerecht aufbereitet und dem Sicherheitsbeauftragten als Entscheidungshilfe für das weitere Vorgehen liefert.
Ein IDS wäre beispielsweise Zone Alarm von ZoneLabs.
Ein guter Link zu Sicherheitstips für Internetanwender ist das Forum Sicherheit im Internet.
Insbesondere gibt es natürlich Sicherheitstips bei den FAQ des W3.
Sicherheitsgefahren bei Java Applets
Applets werden in zwei Kategorien eingeteilt: trusted und untrused. Trusted Applets unterliegen keinen Sicherheitsrestriktionen und können daher Verbindungen zu einem host öffnen, wann immer sie möchten; untrusted applets unterliegen dagegen Sicherheitsrestriktionen.
Wenn ein Applet geladen wird, wird ein erster check vorgenommen, um zu sehen, ob bereits ein Applet mit demselben Namen (d.h. der Wert des CODE Attributs im APPLET tag) im class Pfad existiert; wenn es so ist, wird das Applet aus dem class-Pfad geladen. Solche Applets werden als trusted angesehen.
Wenn kein Applet mit dem verlangten Namen im class Pfad gefunden wird, wird das Applet von der url geladen, die auf der Seite des Applets dafür angegeben wurde.Diese Art von Applets werden als untrusted angesehen.
Untrusted Applet laufen in einem sog. Sandkasten auf dem Client Rechner, d.h. sie zwar auf den Client-Rechner geladen, dürfen weder auf diesem Rechner weder schreibend, noch lesend auf diesen Rechner zugreifen oder irgend eine andere Funktion ausführen. Auch erlaubt die Voreinstellung im Appletviewer nur, dass das Applet Verbindungen zum host, also zu dem Webserver, von dem es geladen wurde, öffnet.
Wenn der Benutzer das Applet eine Funktion ausführen lassen will (z.B. Drucken oder Speichern), muss er jede einzelne Funktion für das Applet freischalten. Hiermit ist natürlich ein hohes Mass an Sicherheit gewährleistet, da der Benutzer an für sich Kontrolle über jede einzelne Funktion des untrusted applets hat.
Eine gute Seite, auf der Sicherheitsrelevantes zu Java Applets steht, sind die FAQ zur Sicherheit von Java bei SUN
Es gibt aber auch zerstörerische Java Applets, die z.B. online Passworte cracken können, den Browser in die Knie zwischen können oder sogar versuchen, Kontrolle über die Workstation zu erhalten. Diese hostile applets können dies aber nur bewerkstelligen, indem sie Fehler in den Browsern ausnutzen. Dazu ein Überblick über Hostile Applets.
Funktionsweise des CGI (Server) Scripts:
Um z.B. Daten im Web zu verarbeiten, ist es nötig, eine Schnittstelle zwischen Webbrowser und Webserver zu erzeugen. Das CGI gilt als eine Schnittstelle, die eine Interaktion zwischen Webserver und -browser über HTTP ermöglicht. Dabei wird i.d.R. eine CGI-Applikation, in die ein HTML-Dokument eingebettet ist, vom Webserver an den Browser geschickt.
CGI-Programme sind somit in der Lage, Informationsanfragen anzunehmen und durch dynamisch erzeugte HTML-Dokumente zu beantworten. Sie enthalten z.B. Daten einer Datenbank, wie etwa die Daten eines Flugplans oder Updates.
Sicherheitslücken unter CGI:
CGI scripts beinhalten einige Sicherheitslücken, weil die Scripts oft Fehler beinhalen, aber von Webadministratoren trotzdem installiert werden. Grundsätzlich gibt es zwei Arten dieser Sicherheitslücken:
1. Sie können gewollt oder ungewollt über den Server informieren, so dass Hacker eine Lücke leichter finden können.
2. Programme, die eine Eingabe eines Internetnutzers verarbeiten, wie z.B. den Inhalt eines Formulars oder einen Suchindex, können gegen bestimmte Attacken verwundbar sein, bei denen der User sie dazu bringt, einen Befehl auszuführen.
CGI Programme haben Sicherheitslücken, da sie theoretisch die Möglichkeit haben, die Passwortdatei des Servers zu verschicken, oder die Struktur des internen Netzwerks darzustellen.
Eine bekannte Sicherheitlücke von CGI-Scripten waren Gästebücher. So wurden Eingaben mit einem ";" (das in UNIX als Trennzteihen aufgefasst wird) und einem darauf folgenden UNIX-Befehl vorgenommen (z.B. die Passwortdatei an die Adresse des Hacker zu senden).
Sicherheitsvorkehrungen:
CGI Programme sollten mit grosser Sorgfalt geschrieben werden, wie sie bei der Konfiguration von Servern vorzunehmen ist, da sie auch als Miniserver angesehen werden können. Standardmässig vorhandene CGI Skripte sollten dagegen entfernt werden.
Es wird darum vorgeschlagen, CGI Programme zentral im cgi-bin Verzeichnis zu speichern, um die Übersicht zu behalten, welche CGIs aktiv im System installiert sind und diese u.U. auf mögliche Sicherheitslücken zu überprüfen. Ausserdem hat so ein Hacker grössere Schwierigkeiten, eine "böse" CGI Datei irgendwo im System abzulegen und dann aus dem Internet heraus ausführen.
Meiner Meinung lässt sich keine allgemeine Aussage treffen, da die zerstörerische Applets eher die Sicherheit des Nutzers (Webbrowsers) bedrohen, während schölecht programmierte CGI-Skripts u.U. eine Sicherheitslücke für den Webserver darstellen kann. Für den Nutzer stellen Java Applets eine grössere potentielle Gefahr dar, obwohl sie im Allgemeinen in der Sandbox ausgeführt werden, aber aufgrund von Broserfehlern auf seinen Rechner zergreifen könnten.
Der Server ist das zentrale System der Informationsverarbeitung im Internet sowie dem unternehmenseigenen Intranet.
Eine Möglichkeit von Serverangriffen sind URL Angriffe. Hierbei wird z.B. das "~" Zeichen missbraucht, da oft auf Verzeichnisse zugegriffen werden kann. Weiterhin gibt es einige Arten von CGI Angriffen auf Server.
Ein weiteres Risiko sind Automatische Verzeichnislistings (automatic directory listings). Verzeichnislisten sind ein komfortables Feature, können aber u.U. einem Hacker sensible Informationen geben, denn für einen Hacker ist es einfacher, eine Sicherheitslücke in einem System zu finden, je mehr er über das System weiss. Z.B. könnten Backupinformationen über Source Code, CGI Skripte, symbolische Links oder andere temporäre Dateien vorhanden sein, die natürlich zum Schaden des Webservers ausgenutzt werden können. Allerdings kann es passieren, dass diese Dateien trotz des Ausschaltens der Verzeichnislisten diese Programme entdeckt werden können, aber die Suche wird zumindest erschwert. Um sicherzugehen, sollten diese Dateien aber ausserhalb der Zugriffsmöglichkeiten aus dem Inter- oder Intranet liegen.
Symbolic link following
Manche Server erlauben, dass Dateistrukturen mit symnolischen Links erweitert werden. Dies ist nützlich, kann aber zu Sicherheitsrisiken führen, wenn unabsichtlich ein Link zu einem besonders zu schützenden Bereich gelegt wurde. NCSA und Apache Server erlauben daher das vollkommene Ausschalten symbolischer Links.
Links:
Sicherheitskonzept für den www-Serverbetrieb
Auch die System-Konfiguration kann zu Problemen führen.
Der Zugriff auf Rechner, die den Zugriff zu NFS benötigen, sollte beschränkt werden. Ferner sollten keine Dateisysteme an den eigenen Rechner oder an localhost exportiert werden, damit kein indirekter Zugriff über ein anderes Programm möglich wird. Wenn möglich, sollten die NFS-Zugriffe auf read-only (ro) beschränkt sein. Diese Option ro sollte bei dem Export auf dem Server benutzt werden. Zugriffe für den root sollten ebenfalls nur dort erlaubt sein, wo sie unbedingt notwendig sind.
Eine Authentisierung des Zugriffes sollte über NFS nur stattfinden, wenn man ein entsprechendes Verfahren aktiviert. Unterstützt werden z.B. DES (Option secure). Ein DES-Verfahren wird in der Regel von dem Betriebssystem mitgeliefert. Sollte keine Authentisierungsmethode genutzt werden, so findet keine Überprüfung der zugreifenden Benutzerkennung statt. Somit kann jeder Benutzer (unter Verwendung eines entsprechenden Programms) auf die Daten der anderen Benutzer zugreifen.
Bei der Aufteilung in privilegierte und nichtprivilegierte Ports ist zu beachten, daß dem Rechner aber auch dem Administrator selbst Vertrauen entgegengebracht werden muß, damit Rechner oder Administrator diese Vereinbarung nicht unterlaufen. Vielfach ist ein solches Vertrauen nicht gerechtfertigt, so daß diese Einteilung obsolet geworden ist. Gleiches gilt
analog, falls einem System NFS-Zugang gewährt wird, welches keine Unterscheidung zwischen "privilegierten" und "nicht-privilegierten" Ports kennt (z.B. DOS).
Allgemeine Sicherheitsmassnahmen
- Der Server sollte nicht als root, sondern nur mit wenigen Benutzerrechten konfiguriert sein.
- Es sollten immer die aktuellen Patches von Programmen installiert sein, um keine Sicherhetisrisiken aufgrund bekannt gewordener Implementationsfehler einzugehen.
- Standardmäsig vorhandene CGI Skripte sollten entfernt werden und dafür sorgfältig geschriebene eigene Skripts verwandt werden.
Schriftliche Sicherheitpolitik im Unternehmen
Eine wichtige Maßnahme, die ein Systemadministrator durchzuführen hat, um den Webserver sicherer zu machen, ist eine security policy zu schreiben und allen Mitarbeitern kenntlich zu machen. Diese Sicherheitsvorschriften sollten folgender Punkte darstellen:
- Wer darf das System nutzen?
- Wann dürfen die User das System nutzen?
- Was dürfen einzelne Nutzer(gruppen) tun (verschiedene Nutzergruppen sollten verschiene Rechte erhalten)
- Wie ist die Vorgehensweise, um Zugang zum System zu erhalten
- Wie wird die zugangsberechtigung entzogen(wenn z.B. ein Mitarbeiter das Unternehmen verläßt)
- Was für Methoden gibt es für remote und lokalen login?
- Wie wird das System überwacht?
- Wie wird Sicherheitslücken begegnet?
- Welche Vorgehensweise gibt es für Angriffe und Sicherheitsvorfälle?
Das BSI hat folgende Vorschläge zur Serversicherung:
- Beschaffen Sie sich einen ausreichend dimensionierten Rechner. Dies betrifft insbesondere die maximale Anzahl der offenen Verbindungen.
- Setzen Sie ein "sicheres" Betriebssystem ein. Anhaltspunkte für die Qualität eines Betriebssystems bieten eine Quellcode-Evaluierung, der Support des Herstellers bei Sicherheitsproblemen oder auch die freie Verfügbarkeit des Quellcodes.
- Installieren Sie das Betriebssystem als Minimal-System.
- Installieren Sie sich alle relevanten bzw. vom Hersteller empfohlenen Patches.
- Installieren Sie einen HTTP-Server, der bei Sicherheitsproblemen vom Hersteller aktualisiert wird.
- Installieren Sie zusätzliche Software nur, wenn diese unbedingt notwendig ist und beachten Sie alle Sicherheitshinweise der Autoren.
- Vergeben Sie für alle Programme und Dateien nur minimale Rechte. Starten Sie z.B. den HTTP-Server unter UNIX nicht mit Root-Privilegien sondern als Nutzer www. Geben Sie dem Nutzer www dann keine unötigen Zugriffsrechte auf andere Dateien oder Programme.
- Setzen Sie Programme zur Überprüfung sicherheitsrelevanter Einstellungen wie z.B. die Zugriffsrechte für Dateien ein.
- Schalten Sie Server-Side-Includes ab, sofern Sie sich nicht über die speziellen Sicherheitsprobleme im klaren sind und diese in Kauf nehmen müssen.
- Insbesondere die exec-Form der SSI sollte abgeschaltet werden. Weitere Infos zu den SSIs finden sich hier.
- Verwenden Sie CGI-Programme (Common Gateway Interface) nur, wenn dies unbedingt notwendig ist, z.B. für die Anbindung einer Datenbank. Stellen Sie niemals Shells, Interpreter o.ä. in das cgi-bin-Verzeichnis. Weitere Infos finden Sie hier.
- Überprüfen Sie in regelmäßigen Abständen, ob Daten oder Programme auf Ihrem Web-Server verändert worden sind. Hierzu kann z.B. das Programm Tripwire verwendet werden.
- Wenn möglich, verwenden Sie für die Speicherung der Daten Medien, die einen physikalischen Schreibschutz bieten, wie z.B. manche SCSI-Festplatten.
- Kontrollieren Sie regelmäßig die Protokolldateien.
- Erstellen Sie regelmäßig Backups.