Es gibt ein aktuelles Angriffsmuster das hier wohl Ursache war:
Plötzlich 500 error
-
Uwe J -
28. November 2025 um 23:35 -
Erledigt
-
-
Wollte da ein Kollege es besonders sicher machen und hat dreimal Hannover ohne ersten und letzten Buchstaben eingeschoben?
Passwörter etc sollten nie in Klartext gepostet werden. Ich gehe davon aus, dass dies alte Daten sind. Ansonsten Moderator bitten diese unkenntlich zu machen.
diese Passwörter habe ich nicht eingegeben. Ansonsten hat auch niemand auf die Page Zugriff.
Kann ich diese Einträge nicht verwenden um wieder an die Page zu gelangen und sie dann löschen?
-
Es gibt ein aktuelles Angriffsmuster das hier wohl Ursache war:
nein, ich lösche die Install Ordner immer nach der Installation.
-
Das tue ich im Regelfall auch, trotzdem hatte ich bei mir eine Seite gefunden, wo ich das offenkundig vergessen habe. Lass dir ein Backup der Seite vor dem Hack wiederherstellen und prüf mal, ob es dort wirklich weder kickstart.php noch JPA noch instllation ordner gab.
-
Kurze Frage, wird der Installationsordner nicht normalerweise durch den Installer gelöscht? Oder hattet ihr bei der Installation eine andere Vorgehensweise?
-
Kurze Frage, wird der Installationsordner nicht normalerweise durch den Installer gelöscht? Oder hattet ihr bei der Installation eine andere Vorgehensweise?
Nein, die Kickstartdateien bleiben im VZ und müssen manuell gelöscht werden. Nicht optimal aber ist leider so.
bei Neukunden lassen wir immer zuerst eine Dateisuche nach kickstart.php auf dem gesamten Webspace durchlaufen. Da war schon die ein oder andere Überraschung bei
-
Bei mir werden kickstart.php und die .JPA-Datei immer gelöscht, wenn der Restore erfolgreich durchgelaufen ist. Per Hand löschen musste ich bisher nur, wenn etwas schiefgelaufen ist.
-
Ich habe das noch nie benutzt, wozu braucht man denn diesen Kickstart?
Ich weiß, dass man es benutzen kann für vorkonfigurierte Joomla!-installationen, z.B irgendwelche Template Anbieter machen das so.
Ich habe von Leuten gehört, die eine Software namens Akeena Backup benutzen und aus dem Joomla! heraus ihre Installation sichern. Der Grund hat mir aber nie eingeleuchtet, da es aus meiner Sicht sinnvoller ist, auf Serverebene, also auf einer darunter liegenden Schicht, die Backups zu machen.
Wenn ich das richtig verstanden habe, dann handelt es sich um Restores mit dieser Software, und in einigen Fällen werden dabei Fragmente hinterlassen, die einen Angriff möglich machen?
-
Zitat
Bei mir werden kickstart.php und die .JPA-Datei immer gelöscht, wenn der Restore erfolgreich durchgelaufen ist.
Ich werde da aufgefordert, auf das "kickstart aufräumen" zu gehen und dort den "aufräumen" button zu klicken. Tu ich das nicht, dann bleiben die Dateien stehen.
Der Installationsordner wird bei einer normalen installation gelöscht (nicht bei development), aber nichts hindert den Anwender, den wieder reinzukopieren (das mach ich gelegentlich, wenn ich eine Seite auf start zurücksetzen will). Normalerweise werden user das nicht machen, aber ausgeschlossen ist es nicht.Zitat.. da es aus meiner Sicht sinnvoller ist, auf Serverebene, also auf einer darunter liegenden Schicht, die Backups zu machen.
1) wer ko, der ko (bayrisch)
2) Ich habe es lange ignoriert - aber inzwischen finde ich akeeba backup auch bequem -
Vielleicht sollte man auch die kickstart.php vor dem Hochladen umbenennen.
Bei der Pro-Version ist es ein Sicherheitsmerkmal.
-
2) Ich habe es lange ignoriert - aber inzwischen finde ich akeeba backup auch bequemIst mein Verständnis dann richtig? Ich würde nämlich auch gern nach möglichen Angriffsvektoren auf meinen Servern suchen, ein paar Kunden haben meines Wissens das Akeeba installiert
-
Ich finde da Akeeba Backup bequem, um seiten umzuziehen. (Ich habe dafür die kostenlose version, kann nicht für andere Varianten sprechen).
Wenn Kunden Akeeba Backup selber einsetzen und nicht wissen, was sie tun, gibt es ein paar Dinge zu beachten. Einmal dieses aktuelle szenario, dass eine alte .jpa Datei und kickstart.php im root nicht gelöscht werden.Zum anderen dass die backup datei standardmäßig innerhalb der Anwendung )administrator verzeichnis) erzeugt wird.
Für einen Umzug ist das kein Problem, aber für Sicherung taugt das nicht.
Darauf muss man die Kunden hinweisen. Akeeba tut das von selber aber ich denke dass viele Anwender den Hinweis nicht lesen oder nicht verstehen. -
erst einmal vielen Dank für die Hinweise. Ich habe wieder etwas dazu gelernt.
Ich habe Alle Dateien gelöscht, eine neue DB erstellt und lade nun J5.4.1 neu hoch.
Dann werde ich die Page eben neu gestalten. Das schult ja auch
-
... aktuelle szenario, dass eine alte .jpa Datei und kickstart.php im root nicht gelöscht werden...
kickstart.php im root kann auch auf die Backups in einem anderen Dateiordner wie z.B.
administrator/components/com_akeebabackup/backup/
zugreifen bzw. diesbezüglich entsprechend eingestellt werden!
Archive Directory:
https://www.akeeba.com/documentation/…setup-page.html
Kickstart Professional wohl sogar per "Import from URL" von überall eine gefährliche .jpa Datei entpacken...
-
doch noch eine Frage....
ich setze die Page ja neu auf. Wäre es da eurer Ansicht nach besser, gleich mit J 6 anzufangen?
Ja
-
Ja
Auch von mir ein Ja.
-
+1 für "Ja"
-
Ich würde die aktuelle Version 6.0.1 nehmen.
