Product SiteDocumentation Site

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 the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.

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.
An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.
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.