PHP-Code per HTTP einspeisen

Hallo liebe ‚wer-weiss-was‘ Freunde …

ich betreibe eine Website und einige andere Dienste auf einem V-Server, all dies nur für den Privatgebrauch. Jeder weiss, einen D-/V-Server setzt man nicht aus Spass online und lässt diesen vorsich hinvegetieren. Wer sicht nicht kümmert, kann schnell als ‚OR‘ dienen oder es werden illegale Daten gespeichert.

Ich logge jeden Zugriff auf meiner Website, jede Seite die aufgerufen wird, jeder SSH/FTP Zugriff und jede Änderung am System. Die Logfiles werden von mir fast Täglich durch gesehen.

Nach Änderung der Ports für den SSH/FTP Zugriff gibt es bei diesen Protokollen keine Probleme mehr mit Botnetzen die einen Zugriff ergattern möchten. Doch viel mir schon des längeren auf, dass versucht wird, per PHP-Code über HTTP Zugriff auf das System zu erlangen. Hab mir einige der Scripte angesehen und wenn man dadurch wirklich Zugriff bekommt, hat man kein kleines Problem mehr.

Nun meine Fragen:

Wie kann man sich gegen eventuelle Scriptlücken schützen?
Kann man sich Rechtlich in irgendeiner Weise vor soetwas schützen?

Es sind ja, wenn man es genau betrachtet ‚Angriffe‘ auf mein System.
Würde jemand Zugriff darauf bekommen, würde er mich sicherlich nicht informieren und mir die Lücke zeigen, sondern würde irgendwelchen unfug anstellen.

Unter den Seiten die die Scripte ‚hosten‘ sind meist *.ru Seiten, von denen der Code 15 Min lang getestet wird und danach sofort wieder gelöscht. Aber ich hab auch schon Seiten aus den UK (Szene Clubs - Disco), Firmen usw. gefunden. Sind solche Seiten auch evtl. Opfer von Nezten die ihre Scripte auf Server hoch laden und von dort aus testen? Oder sind dies gezielte ‚Angriffe‘?

Vielleicht hat sich jemand schon einmal mit den Thema auseinander gesetzt und kann mir ein paar gute Ratschläge für weitere Vorgehensweisen erläutern. Für jeden Ratschlag, jede Anmerkung und Hilfe bin ich sehr Dankbar.

Mit freundlichen Grüßen

Tobias …

Hallo Tobias,
wenn man server Logs durchsieht fällt einem ja so einges auf was versucht wird. z.b wird versucht ob ein phpMyAdmin oder ähnliches zu finden ist. es werden url parameter mit php / SQL injections durchprobiert.

rechtlich hättest du nach deutschem recht wohl schon etwas in der hand. das problem ist den wirklichen übeltäter zu finden denn du weist nicht ob hinter der dem angreifenden rechner/ip wirklich, ein übeltäter sitzt oder vieleicht nur ein opfer das durch genau so einen. fehler infiziert wurde.

dinge die man tun kann:

  1. Seine eigenen scripte sichern (denke das ist dir klar) input validieren und allem script input grundsätzlich als „gefahr“ ansehen. und auch mit entsprechenden maßnahmen sichern.

  2. du kannst versuchen mit den „angereifern“ kontakt aufzunehmen. um ihnen bescheid zu geben das ihr system infiziert ist und sie freundlich bitten ihr system durchzuchecken. wenns ein „guter“ ist wird er sich darüber freuen und sein system sichern. wenns ein „böser“ ist bringt es sowiso nichts. da könntest du höchstens versuchen über den provider ran zu kommen.

rechtsstreits halte ich nicht für erfolgversprechend. da es schwierig ist den waren täter zu ermitteln. und es geld kostet weil du nicht weisst wie viele relay server genutzt werden und selbst wenn die maschine ermittelt wird. wer weiss wo der übeltäter sitzt.

randnotiz zu den das speichern von ip adressen ist nach aktueller rechtslage zumindest fragwürdig wenn nicht sogar verboten (denke da wird es noch ein paar gegenklagen geben):

http://www.heise.de/newsticker/meldung/96781

„…Daten über das Ende des jeweiligen Nutzungsvorgangs hinaus zu speichern. Insbesondere dürfen demnach IP-Adressen nicht archiviert werden.“

gruss chris

Hallo,

Doch viel mir schon des längeren
auf, dass versucht wird, per PHP-Code über HTTP Zugriff auf
das System zu erlangen. Hab mir einige der Scripte angesehen
und wenn man dadurch wirklich Zugriff bekommt, hat man kein
kleines Problem mehr.

Nun meine Fragen:

Wie kann man sich gegen eventuelle Scriptlücken schützen?

  1. Kein PHP einsetzen. Andere Sprachen (z.B. Perl, Ruby) bieten z.B. mit Taint-Checking viel bessere Möglichkeiten, sich gegen unerwartete Angriffe zu wehren.

  2. Design by Security: Sicherheit ist nichts, was man als zusätzliche Lage irgendwo draufklatschen kann. Man muss beim Design (und auch beim Programmieren selbst) von vornherein an Sicherheit denken, und das Thema immer im Hinterkopf behalten

  3. Die richtigen Tools: Es gibt viele Tools, die einem das Leben sehr viel leichter machen. Z.B. kann man ein Template-System benutzen, dass eine „default escape“-Option besitzt, d.h. dass alle interpolierten Variablen per Default HTML-Escaped werden.
    Bei Datenbanken immer Platzhalter verwenden, niemals Variablen in SQL-Strings interpolieren.
    Und so weiter.

  4. Kein XMLRPC, ausser man braucht es unbedingt.

Wenn man diese Schritte beachtet, ist man kein lukratives Ziel für Angreifer mehr.

Man kann durchaus 99.5% aller gängigen Lücken schliessen, und meistens reicht das, um Angreifer abzuschrecken.

Wenn dann doch etwas passiert, sollte es zumindest vor Gericht kein Problem sein nachzuweisen, dass man sich stehts um Sicherheit bemüht hat, also keine Fahrlässigkeit vorliegt.

Grüße,
Moritz

HuHu …

Hab ich mir schon gedacht …
Und das mit der IP-Speicherung find ich total beknackt.

Es dient doch eigentlich nur der Sicherheit für die SA.
Da heißt es irgendwann wohl doch noch, den Server im Ausland hosten.

Wegen den inputs, die sind schon so abgewandelt, das es nicht den Standarts entspricht wie z.B. email, name etc …

Gruß Tobias

  1. Kein PHP einsetzen. Andere Sprachen (z.B. Perl, Ruby)
    bieten z.B. mit Taint-Checking viel bessere Möglichkeiten,
    sich gegen unerwartete Angriffe zu wehren.

Ich bin nun nicht der Begabteste in Sachen PHP …
Da muss ich mir wohl mal Perl anschaun.

  1. Die richtigen Tools: Template-System

Was sind bei dir Template-Systeme? - CMS?

Gruß Tobias

Hallo,

  1. Die richtigen Tools: Template-System

Was sind bei dir Template-Systeme? - CMS?

Nein, sowas hier: http://de.wikipedia.org/wiki/Template_Engine
Für Perl beliebt ist z.B. dieses hier: http://search.cpan.org/perldoc?HTML::Template

Ciao,
Moritz