Jan Czada: Denial of Service, Server-Sperre

Vor einigen Tagen wurde mein Root-Server vom Provider gesperrt und vom Netz genommen. Zunächst hing ich in der Luft, hatte keine Ahnung zum weshalb und wieso und war verärgert über die kommentarlose Abschaltung. Dann stellt sich heraus: dank der Sperrung durch Strato wurde ich vor einem finanziellen Desaster bewahrt. Bei einer Analyse des Datenaufkommens ergibt sich ein plötzlicher Verkehr von fast 2 Tb innerhalb einer Woche. Von mir unbemerkt geblieben: bereits einen Monat zuvor Vollauslast über 2 Tage mit 800 Gb Transfer. Der Großteil ist dabei ausgehend (outgoing). Zum Vergleich: normalerweise komme ich über einen zweistelligen Gb-Verbrauch im Monat nicht hinaus.

Ein Anruf beim (angenehm schnellen und kompetenten) Service bestätigt dann die Vermutung. Denial-of-Service-Angriffe von meinem Server aus, möglicherweise durch eine DDoS-Programmeinschleusung über ein unsicheres PHP-Skript. Zugriff auf den Server via Login bestand nicht (nur ich kenne das 10-stellige Passwort und keine Brute-Force-Attacken). Der Server wird in einen Rettungsmodus versetzt um schädliche Skripte o.ä. entfernen zu können. Da ich kein Experte im Umgang mit der Linux-Remote-Console bin kann das erst mal dauern, zum Glück handelt es sich bei den gehosteten Seiten nur um Hobby-Projekte und nicht etwa einen Online-Shop.

Es ärgert mich ungeheurlich, daß ich die Unkosten für den überschüssigen Transfer (abgerechnet in Gb) selber tragen werden muss und der kriminelle Verursacher wohl unauffindbar bleiben wird.

Soweit die Vorgeschichte. Jetzt meine Frage zur Sicherheit von PHP. Wie ist es überhaupt möglich ein DDoS-Programm auf den Server einzuschleusen? Es ist zwar möglich über PHP Shell-Befehle auszuführen, aber alle Skripte, soweit ich das überblicken kann, wurden von mir selbst dahingehend gekodet, daß html-entities, also das  Ausführen von Code über ein Eingabeformular, ausgeschlossen sind. Wie eine eingesetzte Foren-Software das handhabt weiß ich allerdings nicht.

Nehmen wir mal an es würde mit irgendeiner Sicherheitslücke gehen. Der Apache-User wwwrun wird doch wohl nicht eine DoS-Software auf dem Server installieren können?

1. Wie kann sowas geschehen, welche Sicherheitslücken gibt es um DoS-Programme einzuschleusen?
2. Wie kann ich den Schädling ausfindig machen damit der Server wieder online gehen kann, wo sollte ich suchen?
3. Wie kann ich sowas in Zukunft verhindern?
4. Wie realistisch ist es den Urheber in so einem Fall herauszufinden (zwecks Strafanzeige und Einklagung der Unkosten)?
Für jeden Hinweis bin ich wirklich sehr dankbar.

  1. Vor einigen Tagen wurde mein Root-Server vom Provider gesperrt

    Da ich kein Experte im Umgang mit der Linux-Remote-Console bin

    Eigentlich sollte man dich an diesem Punkt schon rädern und vierteilen.

    Es ärgert mich ungeheurlich, daß ich die Unkosten für den überschüssigen Transfer (abgerechnet in Gb) selber tragen werden muss

    Hoffentlich hilft es dir, zu der Erkenntnis zu kommen, dass normale Hosting-Angebote nicht nur für "Looser, Lamer und Kiddies" sind, sondern für Leute wie dich.

    Und möglicherweise kannst du dich glücklich schätzen, nicht für den Schaden, den du durch deine Fahrlässigkeit bei den angegriffenen Dritten erzeugt hast, aufkommen zu müssen.

    Soweit die Vorgeschichte. Jetzt meine Frage zur Sicherheit von PHP. Wie ist es überhaupt möglich ein DDoS-Programm auf den Server einzuschleusen?

    Woher soll hier jemand wissen, welche Software du auf deinem Rechner laufen hast?

    Der Apache-User wwwrun wird doch wohl nicht eine DoS-Software auf dem Server installieren können?

    Er muss nur eine Datei beschreiben und selbige starten können, das ist nun wahrlich nicht schwierig.

    1. Wie kann sowas geschehen, welche Sicherheitslücken gibt es um DoS-Programme einzuschleusen?

    Wie Sand am Meer. Auf deinem Server? Das hängt von der tatsächlich vorhandenen Software ab.

    1. Wie kann ich den Schädling ausfindig machen damit der Server wieder online gehen kann, wo sollte ich suchen?

    Infizierte Server werden nicht gereinigt, sondern von Grund neu aufgesetzt, sprich man fängt mit dem Formatieren der Festplatte(n) an.

    1. Wie kann ich sowas in Zukunft verhindern?

    Falls du es ehrlich wissen möchtest: Lass' in Zukunft die Finger von Sachen, von denen du keine Ahnung hast. Kündige den Root-Spielkram, nimm dir ein ordentliches Hosting-Angebot.

    Danke.

    1. Hallo,

      Infizierte Server werden nicht gereinigt, sondern von Grund neu aufgesetzt, sprich man fängt mit dem Formatieren der Festplatte(n) an.

      Du hast aber auch nicht sehr viel ahnung davon, wie VP-Rootserver laufen, oder?

      Grüße
      Thomas

    2. Tag Knork. Hilfreich ist Dein Beitrag ehrlichgesagt nicht. Wie und wo ich Webhosting betreibe entscheide ich lieber selbst. Ein VServer und sonstige Angebote hätten ebenfalls Opfer werden können, hätte dort sogar böser enden können weil der Inklusiv-Traffic oft geringer ist. Davon abgesehen ist mir noch kein Hosting-Angebot begegnet, bei dem ich über derartigen Speicherplatz verfügen kann wie bei einer eigenen Festplatte, darum gehts aber wesentlich. Davon abgesehen benutze ich mehrere MySQL-Datenbanken (sonst oft auf sehr wenige oder nur eine begrenzt) und  vergebe über Confixx ein eigenes Angebot an einen Verein. Sowas bieten andere Lösungen nicht und bisher bin ich sehr zufrieden.

      Wenn Du schreibst es wäre wahrlich nicht schwierig, dann kannst Du mir, anstatt Deinem jetzigen Beitrag, sicher unabhängig von der Software sagen wie z.B. ...
      Sicherheit war in meinen eigenen PHP-Skripten kein vernachlässigtes Thema, so habe ich wenigstens geglaubt. Also, wie kann jemand "einfach so" über einen Browser auf einem Server Programme einschleusen und serverseitig starten? Wenn Du derartig versiert bist wie du vorgibst, dann kannst Du mir sicher was zum Schutz von PHP-Skripten gegen derartige Fälle sagen.

      Den Server formatieren werde ich wohl noch, es geht zunächst mal darum an meine Daten ranzukommen, wozu ich äußerst gerne FTP-Zugang hätte, welchen ich bekomme wenn ich versichere daß die Gefahr beseitigt ist. Wäre zumindest nett bevor ich formatiere. Auf diese Art kann ich nämlich Daten abgleichen und backupen die ich außer einer serverseitigen Spiegelung noch nicht lokal habe, für eine tägliche Sicherung auf lokale Rechner sind die Seiten nicht wichtig genug und bisher gabs keine Probleme.

  2. Hi,

    1. Wie kann sowas geschehen, welche Sicherheitslücken gibt es um DoS-Programme einzuschleusen?

    die Antwort vom Provider hast du schon "möglicherweise ein unsicheres PHP-Skript"

    1. Wie kann ich den Schädling ausfindig machen damit der Server wieder online gehen kann, wo sollte ich suchen?

    speziell zu Strato kann ich nichts sagen ( kenne nur 1&1 u. Hosteurope ) aber aber in der Regel gibt's eine Adminseite in der man den Server wieder in den Ursprungszustand versetzen kann.
    das sollte reichen, dann sind allerdings alle Daten futsch

    1. Wie kann ich sowas in Zukunft verhindern?

    nur Programme verwenden die auch regelmässig akualisiert werden
    genau die Homepage des Anbieters anschauen

    • wann war das letzte Update
    • Newsletter abonnieren um über Sicherheitslücken/Updates informiert zu sein und die Updates dann auch sofort installieren

    Wie eine eingesetzte Foren-Software das handhabt weiß ich allerdings nicht

    so gehts eben nicht. Ein unsicheres Script und der Server ist gehackt.

    und wenn man selber skriptet sollte man wissen was man tut

    1. Wie realistisch ist es den Urheber in so einem Fall herauszufinden (zwecks Strafanzeige und Einklagung der Unkosten)?

    ich würde auf jeden Fall eine Strafanzeige gegen Unbekannt erstatten
    nicht um dein Geld wieder zu bekommen ( das ist höchstwahrscheinlich futsch ) sondern um dich vor möglichen Forderungen der Geschädigten zu schützen.

    Gruß Udo

  3. Ich beantworte mir meine Fragen selbst, für diesen konkreten Fall und für alle die irgendwann mal ein ähnliches Problem haben sollten.

    2. Wo sollte man suchen?
    In Verzeichnissen die auf CHMOD 777 gesetzt sind, leuchtet ein.

    1. und 3. Wie kann sowas geschehen? Wie kann man es in Zukunft verhindern?
    Anhand einer Sicherheitslücke wird in ein schreibbares Verzeichnis ein Skript hochgeladen. Folgende zwei Sicherheitslücken sind bei mir klar geworden:
    1. Eine eingesetzte Foren-Software ist so dermaßen bescheuert, daß sie anscheinend einen Footer-Include als URL-Parameterübergabe akzeptiert. Auf diese Art konnte über den ausgeführten Footer in ein Verzeichnis ein PHP-Skript zur Ausführung von Shell-Befehlen reingeschrieben werden. Wirklich bescheuert. Lösung: Große Vorsicht bei Dritt-Software, am besten nur bekannte und immer aktuellste Versionen; soweit das möglich ist den Code selbst auf Übergabeparameter und includes durchprüfen. Entfernen von Hinweisen auf eingesetzte Software, vor allem wenn diese weniger bekannt ist und es die Lizenz hergibt, weil danach gezielt gesucht wird.
    2. Das zweite Problem ist schon etwas kniffliger. Über die Möglichkeit ein Bild hochzuladen (Upload-Skript) kann eine JPG-Datei hochgeladen werden, welche in Wirklichkeit aber ein Skript ist und ein Steuerungsskript anlegt. Lösung: Ich weiß noch nicht wie genau, aber Überprüfung auf Echtheit des Bildes nicht nur Anhand der Dateiendung.

    Was mich wundert und mir nicht ganz klar ist wäre, wie ohne Benutzerrechte über einen Browser so weitreichend das System steuerbar ist wie es die Remote-Skripte anscheinend geleistet haben, beispielsweise serverseitige Programmausführung.

    4. Wie sind die Chancen den kriminellen Verursacher zu kriegen?
    Die Apache-Logs geben jedesmal wenn die eingeschleusten Dateien aufgerufen werden eine brasilianische IP-Adresse an und ein brasilianisches Windows XP mit Firefox. Ich halte es für möglich den Urheber theoretisch rauszufinden. Das über eine deutsche Strafanzeige die Behörden und Provider in Brasilien, sollte der Kerl überhaupt wirklich dort sein, mitspielen würden und das ganze dann irgendeine Konsequenz hätte (nach brasilianischem Recht) bzw. eine Kostenforderung erfolgreich wäre, halte ich für sehr unwahrscheinlich.

    In einem Satz: teuer bezahltes Lehrgeld.