14.6. Weitere sicherheitsbezogene Überlegungen
Sicherheit ist nicht nur ein technisches Problem; mehr als alles andere geht es dabei auch um bewährte Verfahrensweisen und um das Verständnis der Risiken. Dieser Abschnitt bespricht einige der häufigeren Risiken, sowie auch einige erprobte Verfahrensweisen, die je nach Sachlage entweder die Sicherheit erhöhen oder die Auswirkung eines erfolgreichen Angriffs verringern sollten.
14.6.1. Inhärente Risiken von Web-Anwendungen
Der universelle Charakter von Web-Anwendungen hat zu ihrer weiten Verbreitung geführt. Häufig laufen mehrere gleichzeitig: eine Web-Mail, ein Wiki, irgendein Gruppenarbeitssystem, Foren, eine Bildergalerie, ein Blog und so weiter. Viele dieser Anwendungen stützen sich auf den „LAMP“-Stack (Linux, Apache, MySQL, PHP). Leider wurden viele dieser Anwendungen auch ohne große Rücksicht auf Sicherheitsprobleme geschrieben. Von außen kommende Daten werden allzu häufig nach nur geringer ober gar keiner Überprüfung benutzt. Indem speziell hierfür ausgelegte Werte geliefert werden, kann der Aufruf eines Befehls unterlaufen werden, so dass stattdessen ein anderer ausgeführt wird. Viele dieser offensichtlichen Probleme sind im Laufe der Zeit behoben worden, jedoch treten regelmäßig neue Sicherheitsprobleme auf.
Das regelmäßige Aktualisieren von Web-Anwendungen ist daher ein Muss, damit ein Cracker (ob ein professioneller Angreifer oder ein Skript-Kiddie) eine bekannte Sicherheitslücke nicht ausnutzen kann. Das tatsächliche Risiko hängt vom Einzelfall ab und reicht von der Datenvernichtung bis zur Ausführung beliebigen Codes, einschließlich der Verunstaltung von Websites.
14.6.2. Wissen, was zu erwarten ist
Eine Sicherheitslücke in einer Web-Anwendung wird häufig als Ausgangspunkt für einen Einbruchsversuch benutzt. Im Folgenden werden die möglichen Konsequenzen kurz dargestellt.
Die Folgen eines Einbruchs sind unterschiedlich deutlich in Abhängigkeit von den Motiven des Angreifers. Skript-Kiddies wenden lediglich Rezepte an, die sie auf Websites finden; meistens verunstalten sie eine Webseite oder löschen Daten. In subtileren Fällen fügen sie den Webseiten unsichtbare Inhalte hinzu, um so in Suchmaschinen die Verweise auf ihre eigenen Seiten zu verbessern.
Ein weiter fortgeschrittener Angreifer wird darüber hinausgehen. Ein Katastrophenszenario könnte folgendermaßen aussehen: der Angreifer erlangt die Fähigkeit, als Benutzer www-data
-Befehle auszuführen. Jedoch erfordert die Ausführung eines Befehls zahlreiche Manipulationen. Um sich sein Leben leichter zu machen, installiert er andere Web-Anwendungen, die speziell dafür entworfen wurden, aus der Ferne zahlreiche Arten von Befehlen auszuführen, wie z.B. das Durchsuchen des Dateisystems, das Begutachten von Berechtigungen, das Hoch- oder Herunterladen von Dateien, die Ausführung von Befehlen und sogar das Bereitstellen einer Netzwerkkonsole. Häufig ermöglicht es eine Sicherheitslücke, einen wget
-Befehl auszuführen, mit dem Schadsoftware in das Verzeichnis /tmp/
heruntergeladen wird, um sie dann auszuführen. Die Schadsoftware wird häufig von einer fremden Website heruntergeladen, die zuvor kompromittiert wurde, um so Spuren zu verwischen und das Finden des Ursprungs des Angriffs zu erschweren.
An diesem Punkt verfügt der Angreifer über ausreichende Bewegungsfreiheit, um einen IRC-bot zu installieren (einen Roboter, der sich mit einem IRC-Server verbindet und über diesen Kanal gesteuert werden kann). Dieser Bot wird häufig dazu verwendet, illegale Dateien zu tauschen (nicht autorisierte Kopien von Filmen oder Software und so weiter). Ein entschlossener Angreifer könnte sogar noch weitergehen wollen. Das Konto www-data
erlaubt keinen vollständigen Zugang zum Rechner, und der Angreifer wird versuchen, Administratorrechte zu erlangen. Nun sollte dies nicht möglich sein, aber wenn die Web-Anwendung nicht aktuell war, besteht das Risiko, dass der Kernel und weitere Programme ebenfalls veraltet sind; dies ergibt sich manchmal aus einer Entscheidung des Administrators, der, obwohl er die Sicherheitslücke kennt, es versäumt hat, das System zu aktualisieren, da es keine lokalen Benutzer gibt. Der Angreifer kann dann diese zweite Sicherheitslücke ausnutzen, um Root-Zugang zu erlangen.
Jetzt ist der Angreifer im Besitz des Rechners; er wird gewöhnlich versuchen, diesen privilegierten Zugang möglichst lange zu erhalten. Hierzu ist die Installation eines Rootkits erforderlich, eines Programms, dass einige Komponenten des Systems ersetzt, so dass der Angreifer in der Lage ist, zu einem späteren Zeitpunkt erneut die Privilegien des Administrators zu erlangen; das Rootkit versucht außerdem, sein Vorhandensein zu verbergen, wie auch alle Spuren des Einbruchs. Ein unterwandertes ps
-Programm wird dann einige Prozesse nicht auflisten, netstat
wird einige der aktiven Verbindungen nicht aufführen und so weiter. Durch Verwendung der Root-Berechtigungen war der Angreifer in der Lage, das ganze System zu beobachten, hat aber keine wichtigen Daten gefunden; daher wird er versuchen, auf andere Rechner des Firmennetzwerks zuzugreifen. Durch die Analyse des Administratorkontos und der Verlaufsdateien findet der Angreifer heraus, auf welche Rechner üblicherweise zugegriffen wird. Indem der Angreifer sudo
oder ssh
durch ein verfälschtes Programm ersetzt, kann er einige Passwörter des Administrators abfangen, die er bei den entdeckten Servern anwenden wird... und der Einbruch kann sich von hier aus weiterverbreiten.
Dies ist ein Albtraumszenarium, das durch eine Reihe von Maßnahmen verhindert werden kann. Die nächsten Abschnitte beschreiben einige von ihnen.
14.6.3. Die Software wohlüberlegt auswählen
Sobald die möglichen Sicherheitsprobleme bekannt sind, muss ihnen bei jedem Schritt des Bereitstellungsprozesses eines Dienstes Rechnung getragen werden, insbesondere bei der Auswahl der zu installierenden Software. Viele Websites, wie zum Beispiel SecurityFocus.com
, unterhalten eine Liste kürzlich entdeckter Sicherheitslücken, die ein Bild einer Sicherheitsbilanz vermitteln können, bevor eine bestimmte Software eingesetzt wird. Natürlich muss diese Information der Popularität der besagten Software gegenübergestellt werden: ein weiter verbreitetes Programm ist ein verlockenderes Ziel und wird folglich eingehender erforscht. Andererseits kann ein Nischenprogramm voller Sicherheitslücken sein, die aufgrund mangelnden Interesses an einem Sicherheitsaudit niemals veröffentlicht werden.
In der Welt der freien Software besteht im allgemeinen große Wahlfreiheit, und eine Software einer anderen vorzuziehen, sollte eine Entscheidung sein, die auf örtlich gültigen Kriterien beruht. Eine höhere Anzahl von Leistungsmerkmalen bringt auch ein erhöhtes Risiko einer Sicherheitslücke mit sich, die im Code verborgen sein könnte; es kann auch kontraproduktiv sein, das höchst entwickelte Programm zu wählen, und ein besserer Ansatz besteht gewöhnlich darin, das einfachste Programm, das die Erfordernisse erfüllt, auszuwählen.
14.6.4. Einen Rechner als Ganzes verwalten
Die meisten Linux-Distributionen installieren standardmäßig eine Reihe von Unix-Diensten und zahlreiche Hilfsprogramme. In vielen Fällen werden diese Dienste und Programme für den eigentlichen Zweck, zu dem der Administrator den Rechner eingerichtet hat, nicht benötigt. Als allgemeine Richtlinie für Sicherheitsfragen gilt, dass nicht benötigte Software möglichst deinstalliert werden sollte. In der Tat macht es keinen Sinn, einen FTP-Server abzusichern, wenn in einem anderen, nicht benutzten Dienst eine Sicherheitslücke dazu ausgenutzt werden kann, Administratorrechte für den ganzen Rechner zu erlangen.
Aus demselben Grund werden Firewalls häufig so konfiguriert, dass sie Zugang nur zu solchen Diensten ermöglichen, die öffentlich zugänglich sein sollen.
Heutige Rechner sind ausreichend leistungsfähig, um mehrere Dienste auf demselben physischen Gerät unterzubringen. Aus ökonomischer Sicht ist eine solche Möglichkeit interessant: nur einen Rechner verwalten, geringerer Energieverbrauch und so weiter. Unter Sicherheitsaspekten kann diese Entscheidung jedoch problematisch sein. Ein einziger kompromittierter Dienst kann Zugang zum ganzen Rechner zur Folge haben, wodurch wiederum die anderen Dienste, die auf demselben Rechner untergebracht sind, gefährdet werden. Diesem Risiko kann entgegengewirkt werden, indem man die Dienste voneinander isoliert. Dies kann entweder durch Virtualisierung erreicht werden (jeder Service wird in einer eigenen virtuellen Maschine oder einem Container betrieben) oder durch AppArmor/SELinux (jeder Dienste-Daemon hat einen passend gestalteten Satz an Berechtigungen).
14.6.5. Benutzer sind Spieler
Spricht man über Sicherheit, so denkt man sogleich an den Schutz vor Angriffen durch anonyme Cracker, die sich irgendwo im Internetdschungel verbergen; eine häufig vergessene Tatsache ist jedoch, dass Risiken auch von innen entstehen können: ein Angestellter, der im Begriff ist, die Firma zu verlassen, könnte sensible Dateien aus wichtigen Projekten herunterladen und an Wettbewerber verkaufen, ein nachlässiger Verkäufer könnte während eines Treffens mit einem potentiellen Neukunden seinen Schreibtisch verlassen, ohne seine Sitzung zu sperren, ein ungeschickter Benutzer könnte versehentlich das falsche Verzeichnis löschen und so weiter.
Die Reaktion auf diese Risiken kann technische Lösungen umfassen: nur die tatsächlich erforderlichen Berechtigungen sollten den Benutzern gewährt werden, und regelmäßige Sicherungskopien sind unabdingbar. In vielen Fällen wird der angemessene Schutz jedoch auch mit einer Unterweisung der Benutzer in der Vermeidung von Risiken verbunden sein.
14.6.6. Physische Sicherheit
Es macht keinen Sinn, die Dienste und Netzwerke abzusichern, wenn die Rechner selbst nicht geschützt sind. Es gehört sich, dass wichtige Daten auf im laufenden Betrieb austauschbaren Platten in einem RAID-System gespeichert sind, da Festplatten irgendwann ausfallen und die Datenverfügbarkeit unabdingbar ist. Aber wenn jeder Pizzalieferant das Gebäude betreten, in den Serverraum schleichen und mit einigen ausgewählten Festplatten davonlaufen kann, ist ein wichtiger Teilbereich der Sicherheit nicht gegeben. Wer kann den Serverraum betreten? Wird der Zugang überwacht? Diese Fragen verdienen Beachtung (und eine Antwort), wenn die physische Sicherheit beurteilt wird.
Zur physischen Sicherheit gehört auch, dass Unfallrisiken wie Brände bedacht werden. Wegen dieses besonderen Risikos ist es gerechtfertigt, die Sicherungsmedien in einem separaten Gebäude zu lagern, oder wenigstens in einem feuersicheren Stahlschrank.
14.6.7. Rechtliche Haftung
Einem Administrator vertrauen seine Nutzer mehr oder weniger vorbehaltlos, genauso wie die Nutzer des Netzwerks im Allgemeinen. Er sollte deshalb jede Nachlässigkeit vermeiden, die von böswilligen Menschen ausgenutzt werden könnte.
Ein Angreifer, der die Kontrolle über Ihren Rechner übernimmt und ihn dann als vorgeschobene Basis („Relais-System“ genannt) benutzt, um von ihm weitere ruchlose Aktivitäten auszuführen, könnte Ihnen gesetzliche Unannehmlichkeiten verursachen, da die angegriffene Seite den Angriff zunächst als von Ihrem System ausgehend sieht, und daher Sie als Angreifer (oder als Komplizen) betrachten wird. In vielen Fällen wird der Angreifer Ihren Server als Relais zur Versendung von Spam benutzen, was keine großen Auswirkungen haben sollte (außer möglicherweise die Registrierung in schwarzen Listen, die Ihre Fähigkeit, legitime E-Mails zu versenden, beschränken könnte), aber dennoch unangenehm wäre. In anderen Fällen können durch Ihren Rechner bedeutendere Störungen verursacht werden, wie zum Beispiel Denial-of-Service-Angriffe. Dies wird manchmal zu Einnahmeverlusten führen, da die berechtigten Dienste nicht verfügbar sein und Daten zerstört werden können; manchmal wird dies auch tatsächliche Kosten verursachen, da die angegriffene Seite rechtliche Schritte gegen Sie einleiten kann. Rechteinhaber können Sie verklagen, wenn eine nicht autorisierte Kopie eines urheberrechtlich geschützten Werkes von Ihrem Server weitergegeben wird, wie auch andere Unternehmen, falls sie aufgrund von Dienstgütevereinbarungen zu Strafzahlungen infolge des Angriffs durch Ihren Rechner verpflichtet sind.
Wenn dies geschieht, genügt es nicht gewöhnlich nicht, seine Unschuld zu beteuern; Sie werden zumindest überzeugende Beweise benötigen, die von einer bestimmten IP-Adresse ausgehende verdächtige Aktivitäten auf Ihrem Rechner zeigen. Dies wird nicht möglich sein, wenn Sie die Empfehlungen dieses Kapitels vernachlässigen und zulassen, dass der Angreifer Zugang zu einem privilegierten Konto (insbesondere Root) erlangt und dies dann dazu benutzt, seine Spuren zu verwischen.