Der Joomla-Core ist einer der sichersten im Vergleich zu verschiedenen anderen CMS. Das kann ich nun wirklich aufgrund meiner über 20 jährigen Erfahrung als Hoster sagten. Fast alle Sicherheitslücken werden mit den Erweiterungen eingebaut... da unterscheidet sich Joomla dann aber auch nicht von anderen CMS.
Die von crimle implizierten Andeutungen sind meines Erachtens unbegründet und nicht in Ordnung.
Diverse Scripte nutzen einen public-Folder, aber das ist die Minderheit. Einen gewissen Schutz stellt das schon dar, aber das ist auch keine Allheillösung. Backdoors werden allzu oft in Bereichen versteckt, die auch bei einem Public-Folder öffentlich sein müssen. Wenn ein Hacker Zugriff hat, kann er in jedes Verzeichnis Dateien erzeugen. Nur weil ein Teil nicht direkt aufrufbar ist, gibt es immer noch genug Bereiche die immer öffentlich erreichbar sein müssen.
... Full ACK. Dem ist nichts hinzuzufügen.
Lass die php.ini doch einfach weg.
Buche ein Hosting was global kompatible Werte für Joomla hat und gut is.
Wenn alle Seiten nur von mir selbst bewirtschaftet würden, sehe ich das auch so. Hier geht es aber um > 100 Webseiten von verschiedenen Kunden.
Ich bezog mich nur auf DEINEN Zugang. Kunden-Zugänge haben eigenen individuellen Login/Pass-Schutz
Kannst es auch noch auf Deine IP eingrenzen, falls die statisch ist oder wenn nicht das die Hostangabe der Einwahl-IP.
Na ja ob das wirklich alles so ein riesen Aufwand wäre das einmal sinnvoll einzurichten.... Dann sitzt man halt mal 2 h dran.
Für Deinen Login kannst Du ja eigene Zugangsdaten nutzen. Vielleicht auch identische. Man kann beim .htaccess mehrere Zugänge einrichten, sogar Gruppen.
Hi David, ist zwar nun off-topic, aber was ist das Problem bei dem Server? Wir setzen das hier seit ein paar Wochen im Team ein und sind ganz zufrieden.
flotte Bitwarden + Vaultwarden ist mein nächstes Projekt, das hört sich echt spannend an: https://www.heise.de/ratgeber/Wie-m…t-11250955.html
Vaultwarden + Nginx Proxy Manager (wegen Letsenencrypt) auf einem kleinen VPS ist eine optimale und leicht zu installierende Variante. In der Docker-Variante sehr einfach auch upzudaten. VaultWarden bietet kostenlos all das was Bitwarden in den große Abo-Vaianten anbietet. Also auch die Verwaltung von Organisationen, was perfekt ist, wenn man mit mehreren Personen im Team arbeitet. Alle Teammitglieder haben einen gemeinsamen Tresor und zusätzlich noch den eigenen privaten Tresor. Die Bitwarden - Clients sind voll kompatibel. Vaultwarden ist ja ein Fork in Rust geschrieben und openSource.
Falls es mal Inkompatibilitäten zwischen den Bitwarden-Clients und dem Vaultwarden-Server geben sollte, ist das von der Vaultwarden Community schnell gelöst. Vor kurzem gab es so eine Situation, weil die Bitwarden Clients erweitert wurden.
Die "echte WAF" ist normalerweise immer vor einer Anwendung. Bei Apache-Webservern üblicherweise Tools wie mod_security, also Teil des Webservers selbst. Eine .htaccess kann dann noch etwas ergänzen auf Script- oder Kunden-spezifischer Ebene - und sei es nur der Passwortschutz des administrator-Verzeichnisses bei Joomla oder der wp-login.php bei Wordpress. Derart mächtige Regeln wie mit mod_security sind damit nicht möglich.
Wir versuchen bekannte gewordene Angriffsvektoren mit mod_security bereits vorab abzufangen. Das gilt dann global für den ganzen Server und allen Webs.
Für mich besteht ein Firewall-Konzept aus diesen Teilen:
Punkt 4) ist alleine kein Allheilmittel, auch wenn das von verschiedenen Herstellern gerne behauptet wird. Dazu habe ich schon zu viele Hacks gesehen, wo solche Tools installiert waren und versagt haben.
Wichtiger -meiner Ansicht nach- sind diese Punkte:
Weil ich weiß das diese Punkte eher theoretischer Natur sind, User "jeden Scheiss" installieren und sich oft monatelang nicht um Updates kümmern, geschweige denn regelmäßig mal "nach dem Rechten schauen", oft genug gar keine große Ahnung haben, ist eine Software-Absicherung gemäß Punkt 4), wie z.B. HTProtect aktuell, rsfirewall usw. oder anderen Tools, durchaus oft sinnvoll - aber kein Allheilmittel.
Die Variante 1 in meinem oberen Posting hier mit einem Screenshot untermauert.
Ich rufe eine Seite mit .htaccess-PW-Schutz auf. Im Bitwarden-Client gibt es zwei Einträge, die dann aufpoppen, wenn man einmal auf den Icon in der Bowserleiste klickt. Aufgrund der Namesgebung ds Eintrags weis sich welcher Eintrag für .htaccess und welcher für das Joomla-Login ist.
Mit Klick auf den Kopierbutton (roter Pfeil) kann man Username und PW des htaccess-Zugangs kopieren. Und dann in die jeweiligen Felder pasten. Ist das überwunden, wird das Joomla-Login automatisch eingetragen.
Nicht perfekt, aber funktioniert einwandfrei.
150 Seiten würde ich auf diese Weise ungern aufrufen, weil das zu langsam ist. Dafür würde ich Variante 2) benutzen, die alles vollautomatisch macht.
Mein Passwortmanager Bitwarden füllt die Zugangsdaten zum Back-End automatisch aus, sodass ich nur noch [Enter] drücken oder auf den Button [Anmelden] klicken muss. Wenn aber ein .htaccess Backendschutz eingerichtet ist, erfolgt eine zusätzliche Passwortabfrage. Diese kann Bitwarden nicht automatisch ausfüllen, ich nehme an, das das aus Sicherheitsgründen so sein muss?
Ich nutze Vaultwaren zusammen mit den Bitwarden Clients. Das beschriebene Problem kenne ich.
Es gib zwei Lösungen:
1) Bitwaren kann das auch speichern, aber man muss das einmal manuell eintippen. Wenn das .htaccess-PW abgefragt wird erkennt das der Bowser-Client und man kann User/Passwort mit der Kopierfunktion dort rauskopieren.
OK, ich gebe zu, das ist keine schnelle optimale Lösung, aber immerhin möglich.
2) Du kannst diese .htaccess-Zugangsdaten mit dem Brower-PW-Manager erfassen. Ich nutze den Bravebrowser, aber das geht sicher auch mit jedem anderen Browser. Für die Erfassung ist es aber erst einmal sinnvoll den Browser-PW-Manager wieder zu aktivieren - nur für die Erfassung. Den schaltet man ja überlicherweise bei Nutzung von Bitwarden ab.
Wenn man das alles erfasst hat, füllt der Browser die Daten automatisch ein und Bitwarden macht das Joomla-Login.
Oh manno... aber Danke fpr die Info.
So meinte ich das auch nicht. Aber wenn Du Deine php.ini (warum gibts die überhaupt, na egal...) deaktiviert wird, dann wirkt eine andere php-Ini-Einstellung. Und ob das so gewollt bzw. richtig ist. wäre zu prüfen.
eine php.ini hat dort nichts zu suchen. Allerdings ab ich schon oft gesehen, das bei bestimmten Hostern überall php.ini Files in Ordnern erzeugt werden.
Hacker verteilen auch gerne php.ini-Files. Du solltest Deine Installation mal professionell prüfen lassen.
Oh Sorry, da hab ich tatsächlich nicht genau hingesehen.
Ich nehme also alles zurück und behaupte das Gegenteil!
Die Lastest Releases zeigen nur ein Update am 24.07.26 an:
Gemäß der Meldung müssten dort ja 30 Erweiterungen aufgeführt werden....
Da wird dann wohl einiges unter den Teppich gekehrt?
Oder muss ich wie früher nach einem Hack trotzdem alles löschen, eine neue DB anlegen und alles mühsam wieder neu aufbauen?
Das können wir von hier aus nicht erkennen.
Grundsätzlich besteht ein hohes Risiko, wenn man nicht auf alte Backups aufsetzt, denn php-Backdoors können aus nur einer einzige Codezeile bestehen und unterscheiden sich kaum bis gar nicht von tyischen PHP-Code.
Wir wissen auch nicht ob es nicht andere Hacks gibt, wie z.B. wegen den Helix Ultimate-Hack und Du Schadcode in der Datenbank..
Du musst also selbst entscheiden, ob Du alles sauber bereinigt hast.
Frage wurde ja beantwortet, aber ein fader Beigeschmack bleibt.
User weiss nicht was für Dateien da rumliegen und postet den Link zur Seite und sogar noch die Dateien.
In diesen Fall ist es gut ausgegangen, aber was wenn es ein Hack gewesen wäre?
Dann hätte jemand Hackerfiles verteilt und gleichzeitig einen Link zu einer gehackten Seite, wo alles mögliche passieren kann, wenn man das aufruft.
Daher meine Bitte:
In solchen Fällen keine Links posten. Dateinamen sind OK, aber keine Inhalte. Wenn überhaupt dann nur als Screenshot wo man nur einen Teil des Inhalts sieht.
Noch ein Tipp:
Dateien einfach bei https://www.virustotal.com/gui/home/upload einreichen und checken lassen oder eine KI anvertrauen.
Also es hört einfach nicht auf 
Hat der Hoster kein Prozess-Monitoring?
