Warum? Und wo schrauben diesmal?
IfModule mod_php5.c => "Wenn Modul mod_php5 aktiviert ist" - Das ist es aber nicht. PHP wird mittels mod_fcgi oder mod_itk ausgeführt (je nachdem was du beim Setup ausgewählt hast).
Poste bitte mal die Ausgabe von phpinfo()...
denke das wäre über eine Datenbankänderung möglich..
Wie umständlich. Ich nutze da lieber die tolle Funktion unter Benutzerverwaltung -> Kundenzuordnung 
Geht halt nur mit dem Admin...
Moin
Dann werf ich mal was neues in den Raum: LDAP
Die meisten Dienste können mittlerweile LDAP, proftpd, courier, dovecot, postfix, selbst SASL kann via LDAP authentifizieren.
Vorteil ist, die Passwörter sind zentral und verschlüsselt gespeichert (keine Redundanzen -> neu anlegen der UserDB für jedes Programm entfällt -> niemand braucht ein unverschlüsseltes Passwort). Da LDAP einen hierarchischen Aufbau hat bleibt das ganze auch übersichtlich und kann notfalls auch mal ohne imscp administriert werden.
Nachteil: Ein weiterer Dienst der möglicherweise abstürzen kann 
pma Login nicht mehr möglich... Aber hier kann ja für bequeme Kunden ein opt-in erstellt werden, wo sie explizit auf das Risiko (unverschlüsseltes PW) hingewiesen werden.
Bei mir läuft openLDAP nach paar Konfigurationsschwierigkeiten problemlos seit paar Monaten. Ich nutz es zurzeit für Jabber, SVN via Apache und openVPN und ich muss sagen ich bin begeistert von
Da ich mir LDAP auch in imscp wünsche, würd ich auch anbieten dabei mitzuhelfen (sicher mal für die LDAP Konfiguration und Einbindung in die jeweiligen Dienste. Das ganze Frontend diesbezüglich umgebaut werden, der Backendteil fällt afaik weg...)
Hoffungsvoll
Jadawin
Edit: Mir ist grad ein grösseres Einfallstor für "Viren" aufgefallen: Der Pluginmechanismus. Wenn iwelche Admins Plugins von sonstwo runterladen ist die DB schnell mal exploited (Ja ok, der ganze Server auch)^^
It is an error, the backup won't be created. I have this also sometimes. Try backupping with the tar option "--ignore-failed-read". I didn't test it here, but it should work...
Hab ich, sci2tech hats bereits in den master aufgenommen und das Ticket geschlossen. 
Hab die verantwortliche Zeile gefunden...
In der Datei /var/www/imscp/engine/PerlLib/Servers/httpd/apache_fcgi.pm die Zeile 791 auskommentieren. Sollte dann so aussehen:
# "$self::apacheConfig{APACHE_CUSTOM_SITES_CONFIG_DIR}/$data->{DMN_NAME}.conf",
In der Datei /var/www/imscp/engine/PerlLib/Servers/httpd/apache_itk.pm ist es auf Zeile 732.
Getestet mit i-MSCP Version 1.0.3.0 und hat bei mir bestens funktioniert.
Hi
Ja hab nur im englischen Teil gesucht und dann hier nen Thread aufgemacht... Hast du ein Ticket eröffnet? Dann kann das andere geschlossen werden...
Hat der Trick mit "chattr -i $file" funktioniert? Oder was hast du als Workaround gemacht?
lg
Verstehe mich bitte nicht falsch. Ich nehme Deine Gedanken ernst und tue es nicht einfach so ab. Ein richtiger Angreifer kennt sich mit der Materie aus.
Ihm würde der Root Zugriff auf die Datenbank vollkommen ausreichen. Ob verschlüsselte Passwörter ein großer Wall für ihn sind, will ich bezweifeln.
In kürzester Zeit hat er diese entschlüsselt.
Das ist einfach kein Schutz der Dein Szenario nur ansatzweise schützen würde.
Wenn die Passwortverschlüsselung richtig gemacht wird nützen dem Angreifer die Hashes gar nichts. Hab dazu kurz was im ersten Post geschrieben, kanns dir aber gerne noch detaillierter darlegen.
Auch wenn ich die Thematik selbst schon mal im Internen angestoßen habe, werde ich es gerne noch einmal ansprechen.
Ja gerne
Aber wenn ich mich nicht täusche gibt es auch große closed Sources Panel die auch ihre Mail-, FTP- und DB-Passwörter Plain abspeichern.
Unter anderem ein Grund, warum ich Open Source bevorzuge...
Zuerst muss der Angreifer mal root Zugriff haben. Wenn einer aber "nur" DB zugriff hat, dann kann der schonmal nix machen.
Die Schwierigkeitsstufe ist erhöht und Scriptkiddies haben schonmal verloren. Ein besserer Angreifer muss sich zuerst in die Funktionsweise von courier, proftpd, usw. einlesen und kann dann ggf. modifizierte Binaries einschleusen...
=> Das auslesen braucht dann wie gesagt Zeit. Viel mehr Zeit als mal kurz die DB kopieren und unbemerkt wieder zu verschwinden.
Folgendes imaginäres Szenario:
Ein Sicherheitsloch in i-MSCP, mit Zugriff auf die DB. Ist schonmal genug schlimm. Aber nun: Ein Sicherheitsloch im Updateserver/Softwareserver, der jetzt alle Server-IPs preisgibt (Wer hat die Updatecheck-Funktion schon nicht aktiviert?). Ein Angreifer kann jetzt gemütlich alle Server nach Namen+Passwörtern abgrasen und tausenden von unwissenden Kunden schaden... Was soll ich da meinen Kunden erzählen? "Ja sry, die i-MSCP Entwickler habens nicht für nötig erachtet."
TheCry: Was soll ein Angreifer die DB sonst interessieren? Irgendwelche unternehmenskritische Daten kommen eh nicht da drauf.
Warum sind die i-MSCP Loginpasswörter verschlüsselt?
Die Strategie geht auch nur solange gut, solange keiner davon weiss...
Nur so meine Ansicht...
Natürlich macht es Sinn, wenn ein Einwegverfahren verwendet wird (bsp. MD5). Ein Angreifer kann so zwar die Passworthashes auslesen, muss aber zuerst mit Rainbow-Tables ran, was unter Umständen eine Weile dauern kann.
Wenn jetzt noch ein Salt dazu verwendet wird (zufällig generierter String, der ans Passwort gehängt wird), und zudem noch ein sicheres Verschlüsselungsverfahren verwendet wird (MD5 ist veraltet), dann kann sich der Angreifer die Zähne an den Hashes ausbeissen.
Es geht hier um Vermeidung von Kollateralschaden, (zu) viele Leute verwenden gleiche Passwörter überall im Internet.
