Webworking

Security auf Webservern

Das 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:

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:

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:

KEIN SERVERDIENST sollte von jemandem gewartet werden, der keine oder wenig Ahnung vom darunterliegenden System hat!

„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:

ganz kurz – aber mit grosser Wirkung. Legen wir das Skript in das Verzeichnis in dem CGIs liegen und machen es ausfuehrbar (chmod a+x ). Nun fuehren wir es aus. Was passiert? Schockiert? Hoffentlich nicht, denn wenn ja ist der Job als Webadmin wohl doch nicht ganz das richtige… Nun, im Apache kann man einschraenken WO ausfuehrbare Programme liegen duerfen und eigentlich sollten NUR erfahrene Web/CGI Programmierer Skripten fuer das Internet erstellen. Aber manche Kunden moechten ihre eigenen (oder eingekauften) Skripten auf „ihrer Homepage“ (dem Server den Sie lieber Leser administrieren) laufen lassen. Sie koennen sicher Mechanismen erfinden um zu ueberpruefen ob und was der Benutzer/Kunde in seinen CGI Verzeichnissen ablegt. Aber auch dafuer braucht es Erfahrung und Wissen.
Ein falsch konfigurierter Server kann aber auch Skripten in JEDEM Verzeichnis ausfuehren lassen. Man stelle sich folgendes Szenario vor:

  1. auf dem Server is anonymes FTP moeglich
  2. der Benutzer hat einen Link auf das FTP Verzeichnis gemacht („er moechte auf die Dateien zugreifen koennen, die er upgeloadet hat“)
  3. ein BalckHat kommt drauf, schreibt sich ein irgendein Skript welches auf der Platte nach Passworten oder sonstwelchen Daten sucht
  4. Der BlackHat laedt das Skript auf den Server – es ist ueber den Link erreichbar und wegen der Fehlkonfiguration kann es auch ausgefuehrt werden.

..alles weitere ueberlasse ich Ihrer Phantasie.
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…