HBUMNMapServer ger Capter Sicherheit

Sicherheit

Bei jeder Anwendung in einem Netzwerk stellt sich die Frage nach der Sicherheit der ganzen Angelegenheit; das gleiche gilt natürlich auch für eine MapServer-Applikation.

Leider haben viele Entwickler und Anwender eine eher schwammige Vorstellung vom Begriff 'Sicherheit'. Sie wollen einfach 'sicher' sein; und das möglichst einfach und möglichst schnell\footnote{Aus diesem Grund installieren sich so viele Menschen Produkte, die ihnen genau das versprechen: sogenannte Personal Firewalls. Diese tun allerdings im Grunde nichts anderes, was ein sauber konfiguriertes System nicht sowieso schon tun würde.}. Das Vorgehen sollte jedoch ein ganz anderes sein.

Zu Beginn sollte die Frage stehen, was mit Sicherheit eigentlich gemeint ist, was man also genau zu erreichen gedenkt. Entlang dieser Vorgabe kann man sich dann eigene Richtlinien und Konzepte entwickeln, die einen das Ziel erreichen lassen. Es wird sehr gerne pauschal gesagt, dass 'hundertprozentige Sicherheit nicht erreichbar' sei. Das stimmt nicht ganz; wenn man sich kluge und genaue Vorgaben macht, lassen sich diese sehr wohl zu 100\

MapServer ist, wie jedes andere Programm auch, immer Teil einer komplexen Umgebung. Diese Umgebung, insbesondere deren nach außen kommunizierenden Bestandteile wie Webserver, dessen Skriptsprachen wie PHP usf., soll an dieser Stelle nicht Bestandteil der Betrachtung sein; ganz einfach, weil es zu viele verschiedene Umgebungen gibt, als dass sie sich in Aufwasch abhandeln lassen würden. Wir konzentrieren uns an dieser Stelle nur auf den MapServer und die Applikationen, die auf ihm basieren können.

Neuigkeiten über Sicherheitsaspekte der restlichen von Ihnen eingesetzten Software finden sie zum Beispiel beim CERT der Universität Stuttgart~http:website:cert. Software, die dort häufig mit Problemen in Erscheinung tritt, sollte gemieden werden.

Stellen wir uns also zuerst die Frage, was wir bezüglich der Sicherheit des MapServers erreichen möchten. Typische Anforderungen umfassen zum Beispiel:

• MapServer sollte nicht dazu verwendet werden können, Zugriffsrechte auf dem Computer zu erhalten, auf dem er läuft, oder nicht vorgesehene Zugriffe auf Befehl von außen durchführen.
• Die Originaldaten, aus denen die Karten erzeugt werden, sollen nicht von außen zugänglich und herunterladbar sein.
• Es soll keinen Zugriff auf die Konfigurationsdatei der Applikation, als das Mapfile, geben.

Außerdem wollen wir in Abschnitt~2 einen kurzen Blick auf die Client-Seite unserer MapServer-Anwendungen werfen.

Dies sollen im folgenden unsere zentralen Punkte sein. Ihr individuelles Sicherheitskonzept kann selbstverständlich andere Punkte umfassen. Falls Ihnen etwas in diesem Kapitel fehlt, so zögern Sie nicht, uns zu schreiben.

Komprommittierung des MapServer-Rechners

Den MapServer selber als Angriffsvektor auf ein System zu benutzen ist wegen seiner Funktion als CGI-Programm im Webserver darauf beschränkt, ihm Parameter zu übergeben, die ihn dann zu einem vom Betreiber unerwünschten Verhalten zu veranlassen\footnote{Natürlich könnte beispielsweise auch der Webserver Fehler bei der Verarbeitung von CGI-Programmen machen, aber dann ist nicht MapServer das primäre Problem.}.

Dem Autor ist keine öffentlich zugängliche Evaluation des MapServer-Quellcodes bekannt. Ein flüchtiges Durchsehen der Quellen brachte zwar einige der üblichen verdächtigen Problemverursacher zutage -- beispielsweise 94 Aufrufe allein von =strcpy= , eine Funktion, die für viele buffer overflows in Vergangenheit und Gegenwart verantwortlich zu machen ist. Generell scheint es so zu sein, dass die Programmierer sauber mit Werten umgehen und sie recht sorgfältig prüfen. Generell wäre es aber selbstverständlich besser, wenn solche Funktionen schlicht nicht verwendet würden.

Beachten Sie bitte, dass es neben den ganzen Parametern für die Bounding Box, die zu aktivierenden Layer und so weiter beispielsweise auch die Möglichkeit gibt, den Pfad für die temporären Bilddateien des MapServers zu notieren. Sie sollten auf alle Fälle Abschnitt~\ref{text:mapfile:cgiparams:restrict} studiert haben, um herauszufinden, wie Sie mit diesem Problem umgehen können.

\subsubsection*{Versionsbanner}

Es ist eine gängige Methode, Serverdienste aufzurufen, um deren Versionsnummer in Erfahrung zu bringen, um dann in einer Bibliothek mit Verwundbarkeiten zu eben dieser Versionsnummer zu suchen. Aus diesem Grund verfolgen einige Administratoren den Ansatz, die sogenannten Bannerfunktionen Ihrer Software abzuschalten bzw. zu unterbinden, um diese Art der Informationsfindung zu vermeiden.

Wenn Sie eine CGI-Anwendung mit MapServer laufen haben, sollten Sie sich einmal das produzierte HTML ansehen. In der allerersten Zeile finden Sie eine Angabe zu allen Eigenschaften des verwendeten MapServers, wie Sie sie vom Aufruf von =mapserv -v= von der Kommandozeile kennen. Produziert wird diese Zeichenkettte von der Funktion =msGetVersion()= in der Datei =maperror.c= . Wollen Sie eine entschärfte Version dieses Strings, ersetzen Sie die komplette Funktion vor dem Kompilieren beispielsweise durch folgendes:

char* msGetVersion () {

 static char *version = "UMN MapServer";
 return (version);

}

Falls Sie die Kommentarzeile komplett verschwinden lassen wollen, müssen sie etwas mehr Arbeit investieren, denn Sie müssen alle Stellen finden, an denen =msGetVersion= aufgerufen wird, und die Aufrufe entsprechend modifizieren.

Bevor Sie sich diese Arbeit machen, sollten Sie sich fragen, ob die Maßnahme überhaupt Sinn ergibt. Nehmen wir an, Sie setzen MapServer 3.6.5 ein und es wird eine Sicherheitslücke in dieser Version bekannt. Sie fühlen sich sicher, denn niemand sieht von außen, dass Sie diese Version einsetzen. Aber was hindert einen Angreifer daran, es trotzdem zu probieren? Gar nichts. Im Gegenteil, Sie sind so unsicher wie vorher, denn Sie setzen immer noch die Software mit der Schwachstelle ein, ob Sie nun das Banner ändern oder nicht. Ein geändertes Banner entbindet Sie nicht von der Pflicht, einen vorhandenen Sicherheitspatch so bald wie nur irgend möglich zu testen und dann einzuspielen. Und wenn Sie das tun, kann Ihnen auch die Information, die das Banner nach außen liefert, herzlich egal sein.

\subsubsection*{Offenheit der Quellen}

Der MapServer ist Software, die einer Open Source-Lizenz unterliegt; das bedeutet also, dass sich jeder den Quellcode herunterladen kann \ldots und natürlich auch auf Schwachstellen untersuchen kann. Obwohl das generell als positiv angesehen wird (schließlich können Sie eine eigene Evaluierung des Codes vornehmen, bevor Sie ihn einsetzen), könnte man auch argumentieren, dass jeder potentielle Angreifer das natürlich ebenso kann.

Dazu folgendes: Bei einem Blick auf entsprechende Statistiken läßt sich schnell erkennen, dass das Verschleiern des Quellcodes mitnichten automatisch zu geringerer Verwundbarkeit der Software gegenüber Angriffen führt. Meine persönlichen Erfahrungen zeigen darüber hinaus, dass die Entwickler nichtfreier Software in den meisten Fällen langsamer in der Behebung von Fehlern sind als diejenigen, die freie Software schreiben -- eben weil die öffentliche Kontrolle fehlt.

Wie auch immer man an dieser Stelle argumentiert, die freie Software bietet Ihnen selbst unter den widrigsten Umständen die Möglichkeit, das Problem selber beheben zu können\footnote{Oder es jemanden anders machen zu lassen, auch wenn Sie ihn vielleicht bezahlen müssen.}, wenn es sein muß. Diese Möglichkeit werden Sie ohne die Quelltexte niemals haben.

Zugänglichkeit der Originaldaten

In den meisten Fällen, die mir bisher untergekommen sind, wollten die Betreiber einer MapServer-Applikation nicht, dass ihre Originaldaten wie Shapefiles, TIFF-Bilder und so weiter, an die Außenwelt gelangen. Wenn diese Daten jedoch in einem Verzeichnis liegen, das sich im Verzeichnisbaum befindet, auf das der Webserver Zugriff hat, dann können diese Daten jedoch unter Umständen von außen heruntergeladen werden.

Ein Beispiel: das Root-Verzeichnis ihres Webservers sei

=/usr/local/apache/htdocs= ,

und Ihre Daten lagern Sie unter

=/usr/local/apache/htdocs/data/shapes= .

Dann sind diese Daten natürlich erst einmal über einen URL wie

http://ihr.url/data/shapes/

in jedem Webbrowser zu sehen und herunterladbar. Zwar können Sie ein Auflisten des Verzeichnisinhaltes in den meisten Webbrowsern wegkonfigurieren, aber Raten kann erstaunlich schnell zum Ziel führen. Es ist daher anzuraten, dass Sie Ihre Daten in einem Verzeichnisbaum lagern, der sich nicht über den Webserver einsehen läßt. Danach Sie berücksichtigen die entsprechenden absoluten Pfade in Ihrem Mapfile (dass sie am besten auch nicht nach außen zugänglich machen, siehe unten).

• Lagern Sie Ihre Originaldaten außerhalb des Zugriffsbereichs des Webservers, und benutzen Sie dann absolute Pfade im Mapfile, um auf diese Daten zu verweisen.

Hinweis : Einigen Personen schmeckt schon die Tatsache nicht, dass MapServer Zugriff auf das komplette Dateisystem des Rechners haben kann, auf dem er läuft, und nicht etwa in einer =chroot= -Umgebung läuft, in der bereits das Betriebssystem dafür sorgen würden, dass MapServer nicht aus einer bestimmten Verzeichnishierarchie heraus kann. Bisher hat das aber nicht zu Sicherheitsproblemen geführt, und das muß es auch nicht zwangsläufig.

Verschleiern des Mapfilenamens

Neben den ganzen Parametern zur Kartendarstellung finden Sie auch den Name des Mapfiles in der Liste der Parameter für den CGI-Aufruf von MapServer. Einmal davon abgesehen, dass dieser Parameter nicht WMS-konform ist, kann der Pfad einem Beobachter Informationen über die Struktur Ihres Dateisystems liefern.

Wie Sie verhindern, dass man den Namen (und damit den kompletten Pfad) des Mapfiles von außen sieht, können Sie in Abschnitt \ref{text:wms:mapfilename} finden.

• Erzählen Sie nicht der ganzen Welt, wo in Ihrem Dateisystem ihr Mapfile liegt.

MapScript-Anwendungen

Ein kurzes Wort zu MapScript-Anwendungen. Der häufigste Fehler in allen webbassierten Skriptsprachen ist es, Eingaben von außen ungeprüft zu übernehmen und weiterzubenutzen. Das ist ein selbstunterschriebenes Todeurteil; in zwei bestimmten Situationen ganz besonders.

Die erste gefährliche Situation ist, wenn Sie Eingaben unhinterfragt an einen Aufruf wie =system()= weiterreichen. Sagen wir, Sie haben das folgende in Ihrem Skript zu stehen:

<math>inhalt = system ("/bin/ls " . </math>dir);

Danach möchten Sie dann die Ausgabe von =ls= parsen und weiterverarbeiten. Wenn Sie nun aber das folgende über den URL erhalten:

.. & dir = /usr/local/verzeichnis && rm -rf <math>HTTP_ROOT & ...

dann haben Sie augenscheinlich ein Problem\footnote{Das Beispiel funktioniert so nicht. Man muß schon etwas mehr Aufwand treiben -- schon alleine wegen der beiden =\&\&= -- aber dieser Aufwand äußert sich lediglich in einer komplizierteren Zeichenkette, die zu übergeben ist. Außerdem soll hier lediglich das Prinzip demonstriert werden.}. Subtilere Kommandos sind hier natürlich ohne weiteres möglich.

Die zweite Situation ist ähnlich der ersten, wenn Sie Eingaben von außen unkontrolliert in SQL-Abfragen übernehmen. Das kann insbesondere bei Paßwortabfragen und Loginprozeduren desaströs sein.

Die Lösung ist hier, eine Menge von Zeichen zu definieren, die in der Eingabe vorkommen darf, und alles andere nicht zuzulassen. Darüberhinaus stellen die meisten Sprachen Funktionen zum 'Escapen' von Zeichenketten zu Verfügung, die man auf jede Eingabe anwenden sollte.

Sicherheitsfragen für PHP werden beispielsweise in~faq:dclp diskutiert, für alle anderen Skriptsprachen gibt es ähnliche Dokumente.

Geben Sie sich nicht dem Fehlgedanken hin, dass Sie Werte nicht überprüfen müssen, nur weil ein Angreifer die Quellen Ihrer Skripte nicht kennt. Bereits aus dem Fehlerverhalten bei absichtlich sinnlosen Eingaben lassen sich Rückschlüsse auf die Struktur eines Programmes ziehen. Es gibt diverse Beispiele dafür, die Probleme der sicherheitsbezogenen Website packetstorm ist eines der prominenteren.

=Die Clientseite: Active Scripting=(2)

Man sieht häufig Dinge wie Rechtecke, die man in einer Karte aufziehen kann, um dann in den gewählten Ausschnitt zu zoomen. Solcherlei läßt sich in reinem HTML nicht bewerkstelligen, sodass auf Programmiersprachen zurückgegriffen wird, die in die HTML-Seite eingebettet sind; JavaScript ist der am häufigsten anzutreffende Kandidat. Andere Hilfsmittel sind Java, ActiveX und so weiter.

Das Problem mit diesen aktiven Komponenten\footnote{In Microsoft-Termini ActiveScripting genannt, daher die Überschrift.} sind die ständig und wiederholt auftretenden Sicherheitslöchern auf der Client-Seite, sprich in den Implementierungen der Webbrowser. Insbesondere der Internet Explorer (aber auch praktisch jeder andere Browser) tritt immer wieder mit Sicherheitslöchern ins Rampenlicht, die von der ungewollten Preisgabe persönlicher Daten bis zur willenlosen Ausführung fremden Programmcodes das gesamte Spektrum der Problematik abdecken.

Als Konsequenz hat eine wachsende Zahl Webnutzer ActiveScripting deaktiviert. Insbesondere Ämter und Firmen neigen sogar dazu, JavaScript und so weiter an einer zentralen Stelle aus dem Netzverkehr komplett herauszufiltern. Um es kurz zu machen: das ist eine äußerst vernünftige Entscheidung. Viele verbreitete WÜrmer und Viren hätten sich ohne Scripting nicht festsetzen können, bzw. wären gar nicht erst entstanden.

Wenn Sie mit Ihrer Mapping-Applikation jetzt JavaScript voraussetzen\footnote{Oder irgendeine bestimmte Skriptsprache, oder einen bestimmten Webbrowser, oder nur bestimmte Versionen von Browsern, oder bestimmte Plugins\ldots das Problem läßt sich beliebig erweitern.}, gibt es für den sicherheitsbewu0ten Benutzer im Grunde nur zwei Möglichkeiten:

1. Die eigenen Sicherheitsrichtlinien über den Haufen werfen und alles aktivieren, was Sie als Autor dem Benutzer vorgeben.
2. Ihre Seite links liegen lassen und woanders hingehen.

Auf den ersten Blick ist es von Vorteil, wenn der Benutzer das erste tut. Wenn er einen konsequenten Arbeitgeber hat, dann kann das jedoch Folgen für ihn haben, wenn ihm am Arbeitsplatz eine Richtlinie die Deaktivierung aktiver Inhalte vorgibt. Wenn er ein Privatnutzer ist, wird aufkeimendes Bewußtsein für die Ursachen von Sicherheitsproblemen vielleicht im Vorhinein erstickt, und dann ist die nächste Wurm- oder Virenepidemie wieder nur eine Frage der Zeit. Wie auch immer, es hätte mehr negative Auswirkungen als positive.

Ist er allerdings konsequent und hält sich an seine Vorgaben, macht er das zweite, und das wollen Sie ebenfalls nicht.

Für eine Applikation die im Internet zur Verfügung steht, sollten Sie gründlich abwägen, ob Sie Technologien wie JavaScript wirklich einsetzen wollen, bis Sie dann zur einer Entscheidung kommen. Bei einer Anwendung, die ausschließlich im Intranet einer Firma eingesetzt wird und deren Integrität sichergestellt ist, kann man eventuell davon Ausgehen, dass Skripte sicher sind.

Im übrigen sind aktive Inhalte (darunter fallen wie gesagt auch Shockwave Flash, Java Applets und so weiter, die auch allesamt nicht brauchbar von Suchmaschinen erfaßt werden können) ein erhebliches Problem, wenn es um die Accessibility geht, also die Zugänglichkeit der Applikation für körperlich behinderte Nutzer. Es gibt hier beispielsweise Richtlinien vom World Wide Web Consortium. Des weiteren gibt es in einigen Ländern Gesetzgebungen, die zumindest für die Webseiten öffentlicher Einrichtungen die erleichterte Zugänglichkeit für Behinderte fordern. Und Sie entsinnen sich sicherlich, wer für gewöhnlich als Auftraggeber auf den Daten sitzt.

Das sinnvollste Vorgehen ist daher, dem Benutzer Alternativen vorzugeben, die trotzdem funktionieren und verwendet werden können, und ihn dann darauf aufmerksam zu machen, welche Voraussetzungen für erweiterte Funktionalität zu erfüllen sind.