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.

Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

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.

The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines. In others, they simply install crypto-miners and use the compromised system to fill their crypto wallets.

Another very common scenario nowadays is a ransomware attack. The attackers will encrypt the data on the machine and leave a note with instructions how to pay ransom to get the key to decrypt the data. Of course, it is not for certain that even after paying, the data can be recovered or be sure it hasn't been stolen (and sold) as well.

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.

Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a rootkit, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time (see also KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter); the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted ps program will omit to list some processes, netstat will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing sudo or ssh with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on.

Dies ist ein Albtraumszenarium, das durch eine Reihe von Maßnahmen verhindert werden kann. Die nächsten Abschnitte beschreiben einige von ihnen.

Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit.

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 am weitesten entwickelte Programm zu wählen und ein besserer Ansatz besteht gewöhnlich darin, das einfachste Programm, das die Erfordernisse erfüllt, auszuwählen.

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).

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.

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.

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 böswillige Aktivitäten auszuführen, könnte Ihnen rechtliche Probleme 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, sowie 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.