In seinem Blog veröffentlicht Sascha einen Artikel, der sich mit der Frage der Haftung bei Störung des normalen Betriebes eines Servers anhand einer eigenen php.ini beschäftigt.
Ansich stimme ich mit der Kernaussage des Artikels überein, aber auch nur im Kern. Der Punkt, ein Provider würde
…den eigenen Kopf bei Haftungsfragen aus der Schlinge zu ziehen oder um zumindest einen Teil der Kosten auf den eigenen Kunden zu übertragen…
stimmt so einfach nicht. Nehmen wir einmal ein Beispiel. Hoste ich meine Seite bei einem grossen deutschen Anbieter, dann bin ich von Haus aus schon Restriktionen bei bestimmten PHP-Funktionen (shell_exec usw.) und anderen Einstellungen unterworfen. Warum dies?
Die Erklärung für mich als Kunde ist relativ einleuchtend. Auf einem Shared-Hosting System liegen teilweise mehrere hundert Kunden. Zum einen hat der Provider die Sicherheit des Servers nach aussen als auch nach innen zu sichern, zum anderen hat er dafür Sorge zu tragen, dass die Webseiten seiner Kunden erreichbar sind.
Nehmen wir jetzt einmal das Beispiel einer WordPress-Installation und dort die Option, Feeds einzulesen. Oftmals werden gerade bei solchen Aktionen hunderte von Feeds gleichzeitig eingelesen. Eine Auslastung bis zum maximalen der zulässigen MySQL-Verbindungen ist die Folge. Die Fehlermeldung “Too many connections” wird nicht lange auf sich warten lassen.
In einem solchen Fall gibt es dann die Möglichkeit, die Prozesse des einzelnen Users zu limitieren oder aber das entsprechende Webpaket zu deaktivieren. Beide Varianten sind nicht toll, bei limitierten Prozessen erhält der User eine Fehlermeldung, bei gesperrten Webpaket hat der User keinen Zugriff mehr und in beiden Fällen ist die Webseite nicht mehr erreichbar.
Und noch ein anderes Beispiel, auch aus der Praxis. Drei Domains eines Kunden werden Ziel einer geballten DDOS-Attacke. Das ganze über ein Botnetz von mehreren 10.000 unterschiedlichen IP-Adressen. Insoweit unproblematisch, dazu gibt es Firewallfilter, aber die Wucht des Angriffes nimmt soviel Bandbreite in Anspruch, dass kaum andere Webserver in diesem Netz erreichbar sind. Erst mit der Hilfe und Umstellungen im Rechenzentrum gelingt es nach ca. 1 Stunde, den Angriff auszubremsen.
Solche Störungen sind aber gerade für andere Kunden auf dem Server genauso problematisch, denn auch diese “leiden” unter solchen einzelnen Usern. Die Folge dürfte klar sein, Kündigungen, schlechtes Image usw.
Es entstehen also auch direkte finanzielle Schäden beim Anbieter selbst. Warum sollte diese nicht die Möglichkeit einer Haftung haben? Und wenn man ehrlich ist, man muss eigentlich nur die AGBs der einschlägigen Provider lesen, alle haben irgendwo einen solchen Passus in den selbigen.
Die Frage, die im Raum bleibt, nimmt der Provider wirklichen einen Kunden in Haftung?
Mir persönlich ist kein Fall bekannt, in dem dies so wäre, auch wenn es die Möglichkeit dazu gibt. Was mir bekannt ist, dass aufgrund solcher Probleme und Störungen Kunden für entstandenen Mehrtraffik aufkommen mussten, gerade wenn es sich um “uralt” Skripte handelt, denen die entsprechenden Sicherheitsupdates fehlen. Aber in diesen Fall bekommt der Begriff “Lehrgeld” eine ganz konkrete Bedeutung 
Wie kann ich nun also eine solche Haftung umgehen? Eine ganz simple Antwort darauf ist, zu wissen was man tut. Wenn ich Scripte installiere und einsetze, dann sollten diese up2date sein. Wenn ich an der Konfiguration schraube, dann sollte ich über das entsprechende Hintergrundwissen verfügen.
Oftmals, wenn auch nicht immer, ist es hilfreich, vorher solche Anwendungen oder Konfigurationen auf einem lokalen System zu testen.
Im einfachsten Fall hilft eine Anfrage an den Provider selber, gerade viele kleine Provider werden hier helfend auf ihre Kunden eingehen und sicher auch die eine oder andere Option individuell für einen Kunden aktivieren bzw. in der Konfiguration anpassen.