lässt sich der orphan entry check für die migration 1.0.7 auf imscp deaktivieren?
ich muss vorher mit 1.0.7 auf einen neuen server migrieren, dabei lasse ich alle configs neu generieren und muss später manuell die Tabellen für FTP, htaccess user auf die uids ändern ...
und danach die migration von imscp durchführen,
auch ein test in einer Vbox ist durch die orphan entry checks nicht möglich ...
weiss jemand wie ich das im migration script deaktivieren kann?
Posts by fulltilt
-
-
danke, hab jetzt mal die stable installiert ...
der installer ist ja echt geil -
ich möchte heute einen neuen produktiv server installieren, sollte ich dazu die stable nehmen oder die beta?
regards
-
hab auch noch einen alten 1.0.7 am laufen ... habe aber nix weiter finden können als eine server_synchronize.php ....
-
kann man einfach ein neues PMA package in den ordner kopieren und die config.cfg des alten verwenden, oder gibts da noch mehr zu beachten?
-
A security issue has been reported in phpMyAdmin, which can be
exploited by malicious people to compromise a vulnerable system.The security issue is caused due to the distribution of a compromised
phpMyAdmin source code package containing a backdoor, which can be
exploited to e.g. execute arbitrary PHP code.The compromised source file was distributed via the "cdnetworks-kr-1"
SourceForge mirror with the phpMyAdmin-3.5.2.2-all-languages.zip
download. -
Wenn du solche Probleme damit hast, dann setz doch fail2ban ein...ist nicht wirklich zuverlässig, hängt sich öfter mal auf und je nach logfile grösse auch sehr CPU lastig ... auch bei den angriffen die ich bis jetzt beobachtet habe, hat ständig die IP gewechselt und somit geht dann auch die grösse der logfiles schnell hoch, je nachdem wie lange (tage, wochen, monate) die attacken andauern, muss fail2ban sich durch grosse logfiles suchen
ich verwende es daher nur für ssh und ftp wobei es relativ stabil läuftzum obigen vorschlag wäre es wohl so besser:
- Möglichkeit im Panel den Schutz zu aktivieren
für jede Anwendung getrennt (webmal, ftp, pma) ja/nein
- anstatt der Fehlerseite direkt Umleitung aufs Paneloder eben eine captcha komponente die sich auch in die tools includen lässt
und ich bin mir ziemlich sicher das ich nicht der einzige bin der mit bruteforce attacken probleme hat, wenn ein bot lange genug auf PMA nach einem root passwort testet, wird er es früher oder später ausspähen können ...
-
thanks gOOvER, mache ich
Hört sich mal Gut anKönntest Du evtl ein Ticket dazu eröffnen??
Danke für den Vorschlag
-
Zum Anbinden müsste man den kompletten Login der Tools umschreiben. Das mit dem sichtbarmachen, naja, ob das was bringt; die Leute, die hier versuchen PMA oder so zu hacken, kennen die Struktur von i-MSCP und wissen, wo sie was findenkönnte man eventl. über session handhaben, wenn aktiviert soll auf eine gültige imscp session geprüft werden, ansonsten gibts eine fehlerseite ...
na ja, so in etwa## edit ##
z.b. eine zentrale auth.php im tools folder
diese prüft ob der zusätzliche schutz in im panel aktiviert ist
falls ja, wird in der auth.php auf eine gültige session geprüft
gülltige session ja/nein
bei nein
header('Location:fehlerseite');hierbei müsste man lediglich in die index.php's der tools die auth.php includen
wäre doch kaum aufwand ... -
Nein, nur in i-MSCP. Pma, etc sind externe Scripts, welche wir in der Regel nicht verändernschade, hatte über 4 wochen ziemliche probleme damit, bis ich eine htaccess in den panel folder gesetzt habe, nun müssen zwar alle kunden 2x einloggen, es gab aber keine andere möglichleit auf die schnelle ... wäre schon nicht schlecht wenn die tools an die bruteforce detection wie beim panellogin angebunden werden könnten, oder ein captcha zusätzlich ...
oder z.b. eine möglichkeit die tools öffentlich oder nur nach panel login verfügbar zu machen ...