tmp Ordner - Sicherheit

H

HugoHorst

New Member
Hallo,

ich habe einen älteren Server (Suse 11), auf dem einige fast tote Webs laufen unter Confixx. Scheinbar gibt es ein Skript mit einer Sicherheitslücke, denn heute fand ich im /tmp-Ordner ein Skript, dass für einen ausgehenden DDoS genutzt wurde. Bei genauerem Hinsehen handelt es sich wohl um IRC Nachrichten.

Der Server befindet sich derzeit in der Neuinstallation, allerdings würde ich dies in Zukunft gerne vermeiden wollen, da das schuldige Skript leider nicht identifizierbar ist.

Per PHP wird schon einiges verboten:
Code: 
disable_functions = show_source, system, shell_exec, exec, popen, proc_open, symlink, url_fopen, phpcredits, escapeshellarg, proc_close, proc_get_status, proc_nice, proc_terminate, virtual, ini_alter, ini_restore, php_ini_scanned_files, memory_get_usage,pfsockopen,diskfreespace,link,getmyuid

Zusätzlich gibt es kein Perl oder andere Skriptsprachen über Apache.
Die Dateien im /tmp-Ordner gehören allerdings dem Apache-User, weshalb ich mich frage, wie soetwas vermeidbar bzw. schwieriger zu machen ist.
Bringt es z.b. etwas auf suPHP umzusteigen? Allerdings hat hier jeder User seinen eigenen tmp-Ordner, sodass dies nur eine Verlagerung des Problems wäre oder?

Vielen Dank für eure Hinweise
 
Ich frage mich, worin genau du das Sicherheitsproblem siehst.

  1. Darin, dass die Daten dem Webserver gehören?
  2. Darin, dass sich alle Leute einen temporären Ordner teilen?
  3. Darin, dass mithilfe eines Scripts ein DoS durchgeführt wurde?

Je nach Antwort auf diese Fragen gibt es natürlich entsprechend andere Antworten auf dieses Thema...
 
Das ist kein Problem des /tmp-Ordners, sondern ein Problem von nicht gepatchten Sicherheitslücken. Wenn du die Symptome bekämpfst, kommt morgen ein Script, das sich anders einnistet und du bist am selben Punkt.

Also einfach immer konqequent

  • Sicherheitsupdates einspielen
  • alle Web-Anwendungen regelmäßig aktualisieren

alles andere setzt am falschen Ende an.
 
Und gesetzt dem Fall, daß ein fehlerhaftes PHP-Script auf einer der Webseiten für das Einschmuggeln des DDoS-Scriptes verantwortlich war, bringen auch alle Sicherheitsupdates nix, wenn nach der Neuinstallation ein Backup zurückgespielt wird, in dem das lückenhafte PHP-Script wieder enthalten ist und auf dem Webserver landet.
SuPHP (oder auch SuExec) machen es dir leichter, die unterschiedlichen Webs voneinander abzuschotten, schützen aber nicht vor Lücken in den Scripten selbst. Wenn die Lücke dann wieder ausgenutzt wird, kannst du aber zumindest das Problem auf den jeweiligen User einkreisen.
 
Hast du die Webserver-Logs nach dem Skriptnamen abgesucht? In irgendeinem Request sollte ja ein verdächtiger Dateiname auftauchen.
 
You must log in or register to reply here.
Back
Top