Ich würde auch online entwickeln in einer passwortgeschützten Subdomain.
Später das Joomla auf die tatsächliche Domain umzuziehen oder umzuswitchen ist i.d.R. keine große Sache.
Zum Problem:
Prüfe die Dateirechte. Dort ist die Lösung zu finden.
Wenn man mit Linux arbeitet muss man die Berechtigungen beherrschen, sonst wird das nix 
Sorry für die Belehrung, aber so ist das nun mal.
Ja ist ist ein Ansatz:
Via .htaccess den Referrer (Herkunftslink) prüfen und nur den Zugriff über die von Dir legal genutzen Links erlauben.
So lange Du nur lokal arbeitest kannst Du mit der Erweiterung der Gruppe gut leben.
Wenn Du aber auf einem öffentlichen Server bist, dann dies auf keinen Fall machen, sonden die Systemrechte von Linux so nutzen, das sie sinnvoll sind. PHP dann nicht als Apache-Modul laufen lassen, sondern über fcgi oder entsprechende Wrapper. Du musst dann dafür sorgen, das dein benutzer Systemuser derselbe ist mit dem auch PHP und FTP läuft. Dann gibt es keine Konflikte und sofern die Rechte auf dem Webserver korrekt gesetzt werden, kann dieser Systemuser auch nur dort agieren. Das ist keine triviale Einstellung und nichts für Laien. Wenn Du aber nur lokal arbeitest und Dein Webserver von außen nicht erreichbar ist, kannst Du darauf verzichten.
Bevor Du irgendwas anderes machst:
Seite sofort vom Netz nehmen! Nicht das Joomla offline schalten, sonfdern komplett per .htaccess-Passwortschutz schützen oder Basisverzeichnis so umbennen, das man das Web nicht mehr aufrufen kann. Weiterhin die FTP-Zugänge löschen oder neue Passwörter setzen. Das gilt auch für weitere Zugänge die es ggf. gibt.
Hilfe siehe Signatur bzw. Link von "hechtnetz" oder gerne empfehle ich Dir auch einen sehr guten Dienstleister - dann einfach mal per Messenger melden.
Und noch was: Nimm den Code auf Deinem Posting. Das muss man ja nich noch auf diesem Weg verbreiten.
Die Ordner/Dateistruktur innerhalb des Joomla änder sich bei einem Umzug auf den Server nicht. Alles bleibt an derselben Stelle, du greifst dann nur per FTP zu.
Domainunabhängig geht auch dies:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Nein, das muss man nichts ändern, es sei denn du hast dort irgendwo http-Links stehen.
Normalerweise reicht es auch in der Konfiguration "HTTPS erzwingen" einzustellen. Dann wird jeder Aufruf auf https umgeleitet.
Vor der Migration das PHP auf 5.6 stellenund Akeeba in dieser Version deinstallieren!!
Also mit der PHP-Version 5.4 (völlig veraltet) und einer Webserverkonfiguration die apache2handler benutzt, kommst Du nicht weiter und wirst Du es auch nicht selbst lösen können. Und 777er-Dateirechte laß mal lieber sein. Du musst also Deinen Hoster fragen, wie man auf PHP 5.6 oder 7.0 umschaltet und wie man den Account auf fcgi oder ähnliche Technik umschaltet. Das können wir Dir nicht sagen, weil wir Deinen Hoster nicht kennen.
Ist es nicht möglich eine zeitgemäßte und sichere Hostingeinstellung zu bekommen, dann ist der Tipp ganz klar: Hoster wechseln.
Wenn ich Dich richtig verstehe willst Du das Joomla-Login mit LDAP ersetzen. Warum nutzt Du dann nicht die LDAP-Funktionen im Joomla? Ich vermute mal, weil die parallel dazu allen unangemeldeten Usern den Zutritt verwehren willst ??
Vielleicht ist folgendes ein Ansatz:
* administrator-Bereich immer mit .htaccess extra sichern (unabhängig von LDAP)
* alle Inhalte der Seite nur angemeldeten Usern sichtbar machen - die sich dann via LDAP anmelden.
... kann sein ich hab falsch verstanden, ist ja schon spät... aber das fällt mir spontan ein.
Ist die Warnmeldung ist immer noch da, nachdem Du unter Konfiguration->Server->Fehler berichten = Standard eingestellt hast?
Das erläutert die eine Zeile. Daneben gibt es diverse weitre typische Hackversuche über die gezeigte IP. Im ersten Posting werden ganz andere IPs gezeigt. Ich vermute es gibt noch _viel_ mehr Aktivität und der tatsächliche Hack ist noch nicht dabei.
Vielleicht hilft Dir das weiter zur Erklärung der konkreten Frage:
https://www.reddit.com/r/sysad…_advice_on_a_php_exploit/
Hallo,
...zum Glück hatten wir DB- und Dateibackups, so dass der Vorzustand wieder hergestellt ist. ...
Also erst alles Rücksichern und dann untersuchen? Damit zerstörst Du Dir einige der wichtigsten Untersuchungsgegenstände: Die Dateien im Webspace.
Ohne ausführliche Analyse wird es nicht möglich sein den Zeitpunkt des Erst-Hacks festzustellen, damit man überhaupt prüfen kann ob das Backup zeitlich passt.
Es gibt doch mittlerweile massenweise Anleitungen, wenn man nur nach "Joomla gehackt" sucht.
Werden denn Fehler angezeigt, die es zu reparieren gilt? Du schreibst ja das nach einem Update nichts mehr erreichbar ist, da frage ich mich wie die DB-Reparetatur aufgerufen wird.
Du solltest sicherstellen, das VOR der Migration das Joomla erst einmal fehlerfei ist. Werde hier schon Fehler bei der DB-Reparatur angezeigt? Wenn ja, dann reparieren. Eventuell alle originalen Sourcen Deiner 3.5er-Version drüberkopieren (außer Verzeichnis "installation").
Erst wenn Deine aktuelle Version wirklich sauber ist und alles was inkompatibel sein könnte entfernt ist, erst dann mit der Migration nach 3.6.5 starten. Schau Dir alle Erweiterungen ab id=10000 an. Falls Du auch Joomla 3.5.0 bist, installiere erst einmal das Update nach 3.5.1 und erst danach migrieren auf 3.6.5 - die einzelnen Zustände möglichst immer sichern, damit Du zurück kannst, das sollte klar sein. Ein Akeeba-Backend entfernen.
Schau auch mal was für ein PHP-Memory-Limit verfügbar ist. 72 MB oder mehr sollten es schon sein.
Ferndiagnosen ohne Einblick in die konkrete Installation sind immer schwer bis unmöglich. Oft sind es Kleinigkeiten die für Probleme sorgen.
Nimm den Link zur Seite auf jeden all hier aus dem Forum raus und schalte die Seite mit einem Passwortschutz offline.
Dann untersuche das Webs auf Hacks und suche nach der Ursache der Kontaktaufnahme der genannten URL. Ich würde aus dem Bauch heraus auch auf einen Hack tippen, kann es aber nicht direkt bestätigen.
Die Probematik hat sicher nichts mit der Joomlaversion zu tun, ebensowenig mit der PHP-Version, Templates oder dem Webserver, sondern dem Mailserver der hier aktiv werden soll.
Dazu wäre erst einmal wichtig wie versendet wird. Per mail()-Funktion des PHP oder per SMTP. Ob ALF die Einstellungen des Joomla übernimmt weiss ich nicht, weil ich die Komponente nicht kenne, aber offenbar tritt das Problem ja mit dem Standardkontaktformular des Joomla auf und damit kann man ja testen.
Ich nehme an, die eingetragene Emailadresse wird als Absender eingetragen. Falls mail() benutzt wird, wird es keine Bouncemail (Rückläufer) geben, falls SMTP benutzt wird, sollte eine Bouncemail an den eingetragenen Absender gehen, falls der Mailserver den Versandt ablehnt.
Ich würde als erstes daher folgendes machen:
Auf SMTP einstellen und damit prüfen, ob es eine Umzustellbarkeitsmeldung des Mailservers an die Absenderadresse gibt. Dieser Meldung kann man dann in der Regel weiteres entnehmen.
Musik auf der Startseite, wohlmöglich noch ungefragt - ein No-Go
So eine Seite würde ich nur ein einziges mal besuchen.
Mittel- bis kurzfristig rate ich dazu beim Provider eine aktuelle MySQL-Version zu benutzen oder einrichten zu lassen. Falls nicht möglich, dann wechsele.
