Security auf Webservern
Gregor Longariva (www.softbaer.de, longariva@softbaer.de), 02.12.2000Das Betreiben eines Webservers ist heutzutage ziemlich einfach. Jedes Netzwerkfaehige Betriebssystem bietet ein oderer mehrere Produkte, mit denen man mit mehr oder weinger grossem Aufwand seinen eigenen Server betreiben kann. Wenn ich mich zurueckerinnere wie umstaenlich die Einrichtung eines Webservers frueher war - einige erinnern sich vielleicht noch an den 'httpd' vom CERN, fuer den es dann irgendwann mal ziemlich viele Patches gab die dann unter einem Hut zusammengefasst wurden und zum "Apache" (kommt von "a patch") wurden...).
Theoretisch ist das Einrichten eines eigenen Webservers heutzutage wirklich
kein Problem mehr. Sowohl die freien Produkte (Apache, Internet Information
Server (IIS) von Microsoft) als auch kommerzielle Produkte (etwa dem Netscape
Webserver oder andere) sind relativ einfach zu konfigurieren.
In der Regel kann man bereits bei der Installation des Betriebssystems einen
Webserver mitinstallieren: Windows NT Server installiert den IIS, alle Linux
Distributionen sowie alle BSD Derivate installieren einen Apache und auch
andere Unixes - etwa Solaris - installieren einen Webserver (entweder eigene
oder Apache wie mittlerweile bei Solaris 8 der Fall ist).
Fuer eine Intranetloesung reicht das vollkommen und man braucht sich - eine
Firewall oder Nichterreichbarkeit von Aussen mal vorausgesetzt - keine
weiteren Gedanken mehr machen.
Man darf aber eines nicht vergessen: ein Webserver ist ein Programm, welches
DATEN zur verfuegen stellt, welche nach Aussen hin sichtbar sind. Der kleinste
Fehler in der Konfiguration genuegt, um ungewollt die Personalakten von
Mitarbeitern, Passworten (hoffentlich zumindest verschluesselt) oder andere
sensitive Daten fuer jedermann zugaenglich zu machen. Man erinnere sich an
verschiedene Faelle im Netz, wo Kundendaten (Teilweise sogar Bankinformationen)
zugaenglich waren.
Was ich damit sagen will ist einfach: auch wenn die INSTALLATION einfach ist -
die KONFIGURATION muss dafuer umso sorgfaeltiger gemacht werden.
Aber die Sicherheit beginnt bereits eine Stufe tiefer - eigentlich sogar zwei
Stufen tiefer: einmal beim Betriebssystem selbst und einmal bei der Serversoftware.
Wenn das Betriebssystem auf dem der Webserver laufen soll unsicher
ist, macht eine noch so gute Konfiguration des Webservers keinen Sinn. Es nuetzt
nicht, wenn ich in meinem Haus vergitterte Fenster anbringe und eine Alarmanlage
installiere wenn die Tueren keine Schloesser haben oder es soundsoviele Nach-
schluessel gibt. Als naechstes muss natuerlich die Serversoftware sicher und
stabil sein. Ich erinnere an Microsoft und den IIS Server. Mircosoft selbst
hatte es versaeumt, einen Patch fuer den IIS zu installieren und wurde genau
ueber dieses Sicherheitsloch das nicht gestopft wurde angegriffen.
Die Wahl der Serversoftware sollte - ganz nebenbei bemerkt - nicht unbedingt
nach dem Kriterium "sowieso dabei" oder "bequem zu installieren und warten"
getroeffen werden sondern AUSSCHLIESSLICH unter dem Aspekt "wie sicher" oder
"wie schnell sind Patches da falls doch mal was sein soll". So hat man im IIS
von Microsoft zwar in den letzten beiden Monaten erstaunlich viele Sicherheits-
loecher gefunden, die jedoch in relativ kurzer Zeit von Microsoft gestopft
wurden. Allerdings mit dem Haken, dass man staendig dahinter sein muss und
die Updates auch einspielen muss.
Doch zurueck zum Betriebssystem. Auch das sicherste Betriebssystem nuetzt mir
wenig, wenn ich andere Dienste auf dem Server laufen habe, die potentielle
Angriffpunkte darstellen koennen (oder tun). Wenn ich also einen FTP Zugang
zum Server anbiete ueber den bestimmte Leute ueber ihren Account Daten
uploaden koennen (welche vielleicht sogar noch Zugriff auf die Konfiguration
vom System oder Webserver haben) ist das vergebliche Liebesmueh'. Wie viele
vielleicht wissen, uebertraget FTP (telnet uebrigens auch) alle Daten (auch
das PassWORT) im KLARTEXT. Das heisst, ich braeuchte mir nur einen Rechner
zu suchen, der irgendwo "zwischen" dem Server und dem Client liegt und die
Verbindungen abzuhoeren (technisch absolut das leichteste). Frueher oder
spaeter wird jemand das Passwort tippen und ich habe Zugang.
Aehnliches gilt uebrigens fuer POP3 - das am weitesten genutzet Protokoll zum
Abholen von Mails von Mailservern. Auch POP3 sendet das eigene Passwort im
Klartext ueber das Netz. Abhilfe koennte hier eine gepatchte Version (uebrigens
von mir so praktiziert) von einem POP Server schaffen, welcher eine andere
Passwortdatenbank verwendet als die Logindaten. Alles was dann noch passieren
kann (sofern Benutzer nicht fuer POP und login dasselbe Passwort verwenden) ist,
dass jemand die Mails lesen kann.
Immerhin.
Es gibt aber durchaus Dienste, die per se nicht angreifbar sind sondern einfach nur Sicherheitsloecher haben. Lange Zeit (das ist allerdings nun schon sehr lange her) war 'sendmail' so ein Kanditat mit vielen Bugs und Sicherheits- loechern ueber die Fremde ins System einbrechen konnten. Nun, um kurz zusammenzufassen: auf einem Webserver (eigentlich: auf jeden Server der einen Dienst im Web anbietet) sollten moeglichst wenig verschiedene Dienste laufen. Einmal um moeglichst wenig Angriffspunkte zu bieten und zum anderen um den Ueberblick leichter behalten zu koennen (3 Serverdienste sind leichter zu warten als 17). Ausserdem sollten moeglichst wenig (wenn ueber- haupt) Benutzer direkten Zugang zum System haben. Und wenn dann nur ueber sichere Verbinungen (etwa durch das verwenden von ssh).
Auch bei der Konfiguration eines Servers kann man viel falsch machen. Da der Apache derzeit der am weitesten verbreitete Webserver ist, moechte ich hauptsaechlich auf den eingehen. Mal ein ganz simples Beispiel: nehmen wir mal an, es gibt Benutzer auf dem System und diese haben im Homeverzeichnis ihr ~/public_html. Niemand kann ihnen verbieten, folgenden Befehl auszufuehren:
'ln -s / ~/public_html/root'
Diejenigen die sich mit Unix auskennen werden sicher gleich gemerkt haben, was
hier passiert. Fuer die anderen: der Befehl 'ln' legt sogenannte Symlinks an.
Das heisst, eine Datei oder ein Verzeichnis kann ueber einen anderen Namen (der
auch ganz woanders liegen kann) zugegriffen werden. In diesem Speziellen Fall
wuerde das heissen, dass man - wenn man in das Verzwichnis '~/public_html/root'
wechselt in Wirklichkeit im "root" Verzeichnis (der Basis der Baumstruktur
unter Unix, also '/') rauskommt. Das heisst nun weiter, das JEDES Verzeichnis
(welches Leserechte fuer alle - und das sind in der Regel die meisten) und
JEDE Datei (ebenfalls Leserechte fuer alle) eingesehen werden kann. Und zwar
von aussen - man brauchts nur zu probieren:
'http://url.des.servers/~longariva/root'
Erstaunt? Nun, eigentlich sollte jeder daran gedacht haben. Und wenn ich ganz
ehrlich bin - auch wenn das jetzt vielleicht boese klingen mag - jemand der
das Ganze NICHT durchschaut hat sollte auf keinen Fall einen Server im Netz
warten. Es gibt noch eine ganze Reihe anderer Moeglichkeiten wie man ungewollt
einen Server unsicher machen kann auf die ich hier nicht weiter eingehen
moechte. Grundsaetzlich moechte ich aber als Regel postulieren:
"Ich habe schonmal damit gearbeitet" ist ZUWENIG! Zum Glueck kann der Apache Symlinks verbieten - auch wenn das u.U. an anderer Setelle Probleme machen kann. Aber das ist wieder ein anderes Thema.
Auch nicht in erster Linie von der Serverkonfiguration abhaengig sind die
Probleme, die durch (falsche) Verwendung von Skripten, die auf dem Server
laufen (CGI, PHP, ASP usw.). Laesst man solche Skripten uneingeschraenkt zu,
kann ein Benutzer - absichtlich oder ohne zu wollen - auch sehr viel anrichten.
Man darf nicht vergessen: solche Programm laufen AUF dem Server und koennen -
je nach Konfiguration - uneingeschraenkt auf Daten, Verzeichnisse usw.
zugreifen.
Ich moechte anhand von CGI ein Beispiel anbringen. CGIs koennen beliebige
Programme sein - meistens sind es Perl Skripten. Aber auch C Programme, Shell
Skripten, ja sogar Visual Basic (etwa auf einem Windows System) koennen fuer
CGI verwendet werden.
Verwenden wir fuer mein Beispiel ein shell Skript wie folgt:
#!/bin/sh
/bin/cat /etc/passwd
ganz kurz - aber mit grosser Wirkung. Legen wir das Skript in das Verzeichnis
in dem CGIs liegen und machen es ausfuehrbar (chmod a+x Ein falsch konfigurierter Server kann aber auch Skripten in JEDEM Verzeichnis ausfuehren lassen. Man stelle sich folgendes Szenario vor:
- auf dem Server is anonymes FTP moeglich
- der Benutzer hat einen Link auf das FTP Verzeichnis gemacht ("er moechte auf die Dateien zugreifen koennen, die er upgeloadet hat")
- ein BalckHat kommt drauf, schreibt sich ein irgendein Skript welches auf der Platte nach Passworten oder sonstwelchen Daten sucht
- Der BlackHat laedt das Skript auf den Server - es ist ueber den Link erreichbar und wegen der Fehlkonfiguration kann es auch ausgefuehrt werden.
Es mag zwar sein, dass derartig falsch konfigurierte Systeme unwahrscheinlich klingen. Aber sie glauben gar nicht, was man im Web alles sieht und findet...
Dem erfahrenen Webadmin moegen vielleicht meine Beispiele doch etwas trivial
erscheinen. Das duerfen sie auch ruhig. Mein Ziel ist, den nicht so erfahrenen
Admins zu zeigen, wie man mit trivialen Fehlern sehr viel anrichten kann und
ihnen dringendst ans Herz zu legen, sich entsprechendes weitreichendes Wissen
anzueignen. Das sicherste Betriebssystem mit der besten und fehlerfreisten
Webserver Software auf dem schnellsten Rechner nuetzt nichts wenn aus
Unwissenheit oder auch nur aus Versehen falsche Konfigurationen oder falsche
Rechte gesetzt werden.
Ich moechte aber niemandem den Mut nehmen, doch selber seine(n) Server zu
administrieren. Ich moechte wirklich nur betonen, dass dies - sofern der
Server aus dem Internet erreichbar ist - wirklich nur dann empfehlenswert ist,
wenn ein gewisses Wissen da ist. Aber troesten Sie sich - auch der erfahrenste
Sys/Net/Webadmin macht manchmal Fehler...
Info
$Id: webserver.shtml,v 1.3 2004/03/08 22:09:09 xwolf Exp $
© 1996 - 2004 by xwolf -
xwolf ist eingetragene Marke beim Deutschen Patent- und Markenamt (Nr. 301 04 380)