Hallo,
ich habe mir vor einer Weile Webspace (auf einem Linux-Server) bei einem Anbieter gemietet, bei dem ich u.a. auch einige Cronjobs laufen lassen kann. Jetzt hat sich kürzlich herausgestellt, dass aus welchen unerfindlichen Gründen 2 Komponenten des von mir eingesetzten CMS nach Zugriff auf die Konfiguration die Konfigurations-Dateien öffnen und dann statt wie vorher mit 644 die Dateien mit den Rechten 777 abspeichern. Das ist einfach nur suboptimal, und da dieser Fehler in der Komponente auch bei Script-Kiddis bekannt ist, wurde bereits von außerhalb versucht, die Dateien zu beschreiben.
Jetzt weiss ich zwar um das Problem mit den Komponenten, kann sie aber selbst mangels PHP-Kenntnissen nicht umschreiben. Könnte ich aus Sicherheitsgründen nicht ein Script erstellen, welches als Cronjob läuft in verschiedenen Abständen und folgendes macht:
- Durchsuchen aller Verzeichnisse nach Dateien mit Rechten größer 644 - Erstellung einer Liste dieser Dateien - Versand der Liste per Email an mich als Webmaster
Was müsste denn in dem Script drinnenstehen? Leider habe ich von Shell-Programmierung nicht so die große Ahnung und wüsste daher aktuell auch keinen so richtigen Ansatz.
Vielen Dank für ein paar Vorschläge. MFg
Em 16/1/2008, "Alexander Wanning" alexanderwanning@gmx.de escreveu:
Jetzt hat sich kürzlich herausgestellt, dass aus welchen unerfindlichen Gründen 2 Komponenten des von mir eingesetzten CMS nach Zugriff auf die Konfiguration die Konfigurations-Dateien öffnen und dann statt wie vorher mit 644 die Dateien mit den Rechten 777 abspeichern.
Wieso überhaupt *44? Warum muss der Webserver dort schreiben können, wenn er die Konfiguration doch sicherlich nur liest? Wenn die Anwendung einmal konfiguriert ist, entziehst du einfach die Schreibrechte (chmod -w) und Ruhe ist.
Jetzt weiss ich zwar um das Problem mit den Komponenten, kann sie aber selbst mangels PHP-Kenntnissen nicht umschreiben. Könnte ich aus Sicherheitsgründen nicht ein Script erstellen, welches als Cronjob läuft in verschiedenen Abständen und folgendes macht:
[...]
Das mag jetzt zwar etwas akademisch klingen, aber du hast dann eine Race Condition, also ein Zeitfenster, in welchem die Angreifer bereits tätig geworden sein können. Solange dieses größer Null ist, ist auch die Wahrscheinlichkeit eines Angriffs größer Null. Das Risiko würde ich nicht eingehen wollen.
Du könntest ja auch etwas spezifischer werden, vielleicht finden sich Freiwillige, die die Lücke für dich beheben. Genügend PHP-Entwickler gibt es ja auf dieser Liste.
Josef
Em 16/1/2008, "Josef Spillner (kuarepoti-dju.net)" 2005@kuarepoti-dju.net escreveu:
Wieso überhaupt *44?
Kleiner Denkfehler von mir, der aber nichts an der grundsätzlichen Problematik ändert, sondern nur die Fragestellung leicht variiert: Warum soll das CMS die Rechte der Datei ändern können?
Josef
Moin Liste
Am Mittwoch, 16. Januar 2008 20:13 schrieb Josef Spillner (kuarepoti-dju.net):
Em 16/1/2008, "Alexander Wanning" alexanderwanning@gmx.de escreveu:
Jetzt weiss ich zwar um das Problem mit den Komponenten, kann sie aber selbst mangels PHP-Kenntnissen nicht umschreiben. Könnte ich aus Sicherheitsgründen nicht ein Script erstellen, welches als Cronjob läuft in verschiedenen Abständen und folgendes macht:
[...]
Das mag jetzt zwar etwas akademisch klingen, aber du hast dann eine Race Condition, also ein Zeitfenster, in welchem die Angreifer bereits tätig geworden sein können. Solange dieses größer Null ist, ist auch die Wahrscheinlichkeit eines Angriffs größer Null. Das Risiko würde ich nicht eingehen wollen.
Eventuell wäre "dnotify" auch eine "Lösung". Also keine Lösung im Sinne von Lösung des Problems sondern im Sinne von kurieren der Symptome. Neuere Kernelversionen informieren das System über Änderungen an Verzeichnissen oder Dateien. Dies Kernelschnittstelle muss man nur mit einem geeigneten Programm überwachen. Und "dnotify" ist so ein Programm.
dnotify --background --attrib /Pfad/zur/Datei -e chmod \ 644 /Pfad/zur/Datei/KonfigDatei
Das sollte sofort bei einer Änderung der Dateiattribute ein chmod aufrufen. Das Zeitfenster für eine Race Condition wird deutlich schmaler.
Ciao
Jens
PS: dnotify überwacht auch Verzeichnisse rekursiv. Aber da es nur beim Starten die Verzeichnisse "erfasst" bemerkt es zwar neu angelegte Unterverzeichnisse aber nicht mehr Änderungen da drin. Da muss man dnotify neu starten.
Hallo,
ich habe extra allgemein gefragt, da ich ja hier keine Diskussion über das von mir verwendete CMS aufmachen wollte. Also ich nutze Joomla 1.0.13. Dort habe ich die Komponente "CommunityBuilder" und das Gästebuch "Easybook" in der jeweils aktuellen FAssung installiert. Mit allen anderen Komponenten habe ich das Problem mit verändernden Dateirechten der Configuration nicht, nur bei diesen beiden. Jetzt weiss ich um das Problem, und ich korrigiere bei BEdarf die Dateirechte dann manuell zurück. Aber für die Fälle, wo man das nicht so gleich feststellt, wäre das von mir gewünschte Script sicherlich wenigstens eine gute Variante. Mit dem Zeitfenster, da hast DU sicherlich recht, aber es ist doch besser als nichts. So stelle ich den Cronjob in einem kurzen INtervall ein, und voila ... ich habe dann eine kurze REaktionszeit. BEsser wäre sicherlich den Fehler in den Komponenten zu finden. FAlls unter den PHP-Profis jemand INteresse hat?
"Dnotitfy" wird mir sicherlich nicht viel nutzen, da ich ja keinen eigenen Server gemietet habe, sondern nur Webspace. UNd dnotity werde ich als Cronsjob mglw. nicht laufen lassen, kann ich aber mal probieren.
Ansonsten werde ich mir mal die im MAN-Pages der von Tobias genannten Befehle anschauen. Vielleicht bekomme ich das Script ja sogar noch selber hin?!
Mfg Alexander
Josef Spillner (kuarepoti-dju.net) schrieb:
Jetzt weiss ich zwar um das Problem mit den Komponenten, kann sie aber selbst mangels PHP-Kenntnissen nicht umschreiben. Könnte ich aus Sicherheitsgründen nicht ein Script erstellen, welches als Cronjob läuft in verschiedenen Abständen und folgendes macht:
[...]
Das mag jetzt zwar etwas akademisch klingen, aber du hast dann eine Race Condition, also ein Zeitfenster, in welchem die Angreifer bereits tätig geworden sein können. Solange dieses größer Null ist, ist auch die Wahrscheinlichkeit eines Angriffs größer Null. Das Risiko würde ich nicht eingehen wollen.
Du könntest ja auch etwas spezifischer werden, vielleicht finden sich Freiwillige, die die Lücke für dich beheben. Genügend PHP-Entwickler gibt es ja auf dieser Liste.
Josef
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexander Wanning schrieb: | - Durchsuchen aller Verzeichnisse nach Dateien mit Rechten größer 644 | - Erstellung einer Liste dieser Dateien
man find suche nach -perm
| - Versand der Liste per Email an mich als Webmaster
man mail man mailx man sendmail
Damit sollte sich ein Einzeiler konstruieren lassen.
Alternativ kannst Du auch Josefs Ansatz probieren, indem Du die Datei auf 444 setzt.
Tobias
lug-dd@mailman.schlittermann.de
-
Alexander Wanning -
Jens Weiße -
Josef Spillner (kuarepoti-dju.net) -
Tobias Schlemmer