Back-End absichern, aber praktikabel!

  • Wenn Du doch sowieso HTProtect einsetzt: Das kann doch auch die .hatccess/.htpasswd- Absicherung installieren. Du brauchst halt nur eine Buchführung (z.B. in Deinem Passwortmanager), welche Kombination von Benutzernamen und Passwort Du für für den jeweiligen Apache brauchst.

    Freundliche Grüße aus Wächtersbach, Rolf Dautrich

  • Wenn Du doch sowieso HTProtect einsetzt: Das kann doch auch die .hatccess/.htpasswd- Absicherung installieren. Du brauchst halt nur eine Buchführung (z.B. in Deinem Passwortmanager), welche Kombination von Benutzernamen und Passwort Du für für den jeweiligen Apache brauchst.

    Ja klar, aber es geht ja nicht nur darum, die Absicherung zu installieren. Meine Kunden und ich wollen uns ja immer wieder ins Back-End einloggen. Und bis das auch noch eingerichtet ist, nimmt man schon einen beträchtlichen Aufwand auf sich.

  • Mal dumm gedacht, eigentlich reicht für den Backendschutz für alle Seiten die gleiche User / Passwort-Kombi?

    Was man hier will, ist doch Roboter abwehren, die direkt Schwachstellen im Backend ausnutzen bzw. Schwachstellen in Plugins / Komponenten.

    Das ist jedenfalls viel besser als es gar nicht einzurichten.

  • Mal dumm gedacht, eigentlich reicht für den Backendschutz für alle Seiten die gleiche User / Passwort-Kombi?

    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. So oder so ist der Aufwand aber beträchtlich, denn es ist ja nicht damit getan, den Passwortschutz einzurichten. Je nach Variante, die hier diskutiert wurde, müssen > 100 Lesezeichen und/oder > 100 Einträge im Passwortmanager auch noch angepasst werden.

  • 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.

  • Das würde ja bedeuten, dass Joomla «out of the box» unsicher ist! Was ich nicht glaube, denn das wäre ja ein Skandal!

    Ich habe wirklich lange überlegt, ob ich auf so einen Unsinn überhaupt antworten soll.

    Du sprichst von einer Kundenwebseite. Daher liegt die Annahme nahe, dass du hier als Dienstleister auftrittst. Insofern bin ich ganz froh, dass zwischen uns keine Geschäftsbeziehung besteht.

    Es geht außerdem nicht ausschließlich um Joomla. Was glaubst du, wie viele Webseiten in letzter Zeit kompromittiert wurden, weil der Administratorbereich nicht ausreichend abgesichert war?

    Dabei ging es keineswegs immer um einen erfolgreichen Joomla-Login. Häufig wurden Sicherheitslücken in Drittanbieter-Erweiterungen ausgenutzt, über die Schadcode hochgeladen oder ausgeführt werden konnte. Eine zusätzliche Absicherung des Administratorbereichs hätte solche Angriffe zumindest deutlich erschwert oder teilweise verhindert.

    Wer die Absicherung des Adminbereichs pauschal für überflüssig hält, unterschätzt die tatsächlichen Angriffswege

    erheblich.

  • Wer die Absicherung des Adminbereichs pauschal für überflüssig hält, unterschätzt die tatsächlichen Angriffswege erheblich.

    Mein allererster Satz in diesem Beitrag lautete

    «Es ist ja unbestritten, dass das Absichern des Backends mittels einer .htaccess sehr empfehlenswert ist.»

    Ich bin immer noch der Meinung, dass es sträflich fahrlässig vom Joomla Projekt wäre, wenn ein CMS zur Verfügung gestellt wird, das als erstes nach der Installation grad schon mal mit Mitteln ausserhalb Joomla abgesichert werden muss. Überhaupt lenkst Du jetzt irgendwie vom eigentlichen Thema ab! Ich WILL ja das Back-End absichern. Man darf doch nach praktikablen und einfachen Mitteln suchen, dies zu tun. Mir scheint nach all diesen Antworten: es ist machbar, aber nicht ganz einfach und mit einem ziemlichen Aufwand verbunden.

  • Ich habe im HTProtect-Dashboard, angeregt durch das in diesem Thread beschriebene Problem und den damit verbundenen Aufwand bei Einrichtung oder Änderungen, eine Möglichkeit ergänzt, den zusätzlichen Passwortschutz für "/administrator" per Batch-Aktion einzurichten, zurückzusetzen oder um weitere Benutzer-/Passwort-Kombinationen zu erweitern.

    Dadurch lässt sich die Konfiguration auch bei größeren Beständen mit 100 oder mehr Websites mit geringem Aufwand umsetzen.

    Bei gleichbleibenden Zugangsdaten oder unter Verwendung einer Domain-Variablen im Passwort können betroffene Kunden zudem unkompliziert per Rundmail darüber informiert werden.

  • Moin,

    ich weiß auch nicht so recht. Das Internet hat sich verändert. Die Art Software zu programmieren hat sich verändert. Wir werden laut Analysten noch 1, 2 Jahre brauchen, bis dieser Tornado des Vipe Codings / Ki - Dramas die gesamte Software Landschaft einmal auf Links gedreht hat. Dazu gibt es übrigens sehr interessante Videos, wie ganze Branchen es jahrelang versäumt haben, sich darauf vorzubereiten. ERP System zum Beispiel:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Naja, Joomla ist ein ziemlich gutes Stück Software, verglichen mit anderen CMS wahrscheinlich eines der Sichersten. Dafür musste sich das Joomla Projekt auch jahrelanges genörgel anhören: Warum fehlt das neuste Feature, warum dauert alles so lange, warum diese Hammer brake changes etc. etc. Ich finde in Zeiten wie Diese bekommt das Joomla Projekt endlich mal was zurück gezahlt: Vertrauen. Und wie immer: Was wir als Dienstleister oder Anwender uns für einen Kram da rein installieren, dafür kann und sollte Joomla keine Verantwortung übernehmen.

    Ich magst ja gerne Bildhaft: Du verkaufst tolle Autos. Namenhafte Hersteller. Zentralverriegelung, Alarmanlage, Wegfahrsperre. Alles drinnen. Er oder du hast zudem ein schickes goldnes Radio eingebaut, große Alufelgen. Spoiler. Alles sehr auffällig, sehr teuer. Nun ruft der Kunde dich an und beschwert sich, dass das Auto geklaut wurde. Vermutlich angezogen durch das geile Radio. Er hätte eine Garage gehabt, um dieses jeden Abend sauber dahinter zu verbergen, aber jedes Abend das Garagentor aufzumachen war ihm einfach zu aufwendig. Er nennt es einen Skandal, das jemand ein Auto baut, welches gestohlen werden kann.

    Ja natürlich hinkt diese Metapher etwas, und natürlich lässt sich das nicht alles 1 zu 1 vergleichen. Und natürlich wird jemand wieder jedes einzelne meiner Bildworte umdrehen und überprüfen, um das Gegenteil zu erklären, was okay ist. Aber mir geht es hier um's Prinzip.

    Zum Thema: Ich hatte jahrelang den htaccess Schutz so gesetzt: https://wicked-software.de/de/blog/admini…ccess-schuetzen. Das geht wirklich gut, aber durch Bitwarden und Co, brauche mir die Passwörter nicht mehr merken. Zudem das Abspeichern der URL, fertig.

    Sehr interessant in diesem Zusammenhang dieser Beitrag, das ist nochmal ein ganz anderes LEvel der Sicherheit: https://wicked-software.de/de/blog/joomla…ndlich-zumachen

    Aber da brauchst du für die 115 Seiten sehr viel mehr Zeit. :)

    Viel Erfolg weiterhin.

    WBR from de-DE

    Wenn ich eins gelernt habe: Keep it simple and you keep it long! :)

  • Sehr interessant in diesem Zusammenhang dieser Beitrag, das ist nochmal ein ganz anderes LEvel der Sicherheit: https://wicked-software.de/de/blog/joomla…ndlich-zumachen

    Das wolltest du im übrigen auch noch testen, leider gab es von dir keine Rückmeldung mehr. Hast du es getestet?

    Weil für mich war diese Lösung nicht brauchbar, leider.

    Stef
    15. Juni 2026 um 16:17
  • 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.

  • Das wolltest du im übrigen auch noch testen, leider gab es von dir keine Rückmeldung mehr. Hast du es getestet?

    Weil für mich war diese Lösung nicht brauchbar, leider.

    Stef
    15. Juni 2026 um 16:17

    Moin, nein, ich bin leider nich nicht dazu gekommen. Habe es aber in meine eigene Web Anwendung (die im LAN läuft und selbst da nutze ich die htaccess + Passwort) integriert

    Bin gerade nebenbei noch ein bisschen beim umstellen auf das Cassiopeia Extended, wenn das läuft probiere ich es mal aus :)

    WBR from de-DE

    Wenn ich eins gelernt habe: Keep it simple and you keep it long! :)

  • Ich bin immer noch der Meinung, dass es sträflich fahrlässig vom Joomla Projekt wäre, wenn ein CMS zur Verfügung gestellt wird, das als erstes nach der Installation grad schon mal mit Mitteln ausserhalb Joomla abgesichert werden muss.

    Das Joomla Projekt muss einen Mittelweg zwischen Sicherheit und Nutzungskomfort finden. Man kann ein System immer noch stärker härten, noch mehr Sicherheitsmechanismen einbauen und Maßnahmen erzwingen - das geht dann aber auf Kosten des Komfort und erzeugt Nutzerbeschwerden.

    Ist eine Seite ohne htaccess Passwortschutz im Backend per se unsicher? Nein. Ist es, in der langen Liste der potenziellen Maßnahmen, eine der sinnvollsten Tätigkeiten? Auf jeden Fall.

  • Man kann ein System immer noch stärker härten, noch mehr Sicherheitsmechanismen einbauen und Maßnahmen erzwingen - das geht dann aber auf Kosten des Komfort und erzeugt Nutzerbeschwerden.

    Genau das waren meine Befürchtungen bei htprotect, das ich nach anfänglicher Begeisterung dann, als es immer komplexer wurde, wieder entfernt habe.

  • 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.

  • Ist eine Seite ohne htaccess Passwortschutz im Backend per se unsicher? Nein. Ist es, in der langen Liste der potenziellen Maßnahmen, eine der sinnvollsten Tätigkeiten? Auf jeden Fall.

    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.

    Beides entspricht 100% meiner Ansicht! Drücke ich mich denn dermassen unverständlich aus? Welche implizierten Andeutungen habe ich gemacht? Ich schrieb «Das würde ja bedeuten, dass Joomla «out of the box» unsicher ist! Was ich nicht glaube, denn das wäre ja ein Skandal!» und das ist mit anderen Worten genau das, was SniperSister und flotte hier auch schreiben.

    Ihr hackt lieber auf mir rum mit völlig verdrehten Vorwürfen:

    «Wer die Absicherung des Adminbereichs pauschal für überflüssig hält, unterschätzt die tatsächlichen Angriffswege erheblich.» und «... Full ACK. Dem ist nichts hinzuzufügen.»???

    anstatt meine Frage richtig zu lesen und darauf einzugehen! Finde ich unfair und daneben! Nochmals (so sorgfältig formuliert wie ich das hinbekomme):

    1. Ich finde die .htaccess Absicherung des Backends eine gute und empfehlenswerte Massnahme!
    2. Wenn Aufwand und Nutzen in einem ausgewogenen Verhältnis sind, dann werde ich das tun.
    3. Meine Frage war: wie mache ich eine .htaccess Absicherung des Backends mit erträglichen Nutzerbeschwerden?
      - Absicherung einrichten
      → dazu gab's einen Tipp von kitepascal, vielen Dank!
      - Meine eigenen Back-End Logins möglichst benutzerfreundlich einrichten, ohne dass Benutzernamen und Passwort über die Zwischenablage kopiert und eingefügt werden müssen. Mein Passwortmanager Bitwarden füllt meine .htaccess Zugangsdaten nicht aus
      → dazu gab's ein paar Lösungsansätze, die ich prüfenswert finde, die aber auf den ersten und zweiten Blick einen gewissen Aufwand auszulösen scheinen. Trotzdem: vielen Dank!
      - Meinen Kunden nicht etwas zumuten, das sie als unzumutbar betrachten könnten
      → dazu gab's einen Tipp von kitepascal, vielen Dank!

    Es gibt wahrscheinlich hunderttausende Webseiten ohne diesen erhöhten Backendschutz. Klar: man kann immer alles noch sicherer machen, aber alle Webseiten ohne .htaccess Absicherung des Backends als apokalyptisch unsicher zu bezeichnen, ist dann doch sehr übertrieben.

    An die Adresse jener, die sich um meine Kunden Sorgen machen:

    • Ich verwalte die Webseiten mit mysites.guru
    • mysites.guru macht regelmässige Full Audits der Webseiten und überwacht, ob sie online sind oder nicht
    • mysites.guru meldet mir per E-Mail, wenn irgendwo ein neuer Benutzeraccount eröffnet worden sein sollte oder wenn andere auffällige Dinge passieren
    • Ich lese die interessanten Blog-Beiträge zum Thema Sicherheit, die mysites.guru regelmässig veröffentlicht
    • Ich prüfe alle Webseiten täglich 1-2x auf vorhandene Updates und installiere diese sofort, also noch am selben Tag. 365 Tage im Jahr!
    • Ich backupe alle Webseiten regelmässig
    • Alle meine Webseiten sind längst auf Joomla 6.1.2
    • Ich verwende, wenn möglich, Core-Funktionen und setze Erweiterungen nur dann ein, wenn es nicht anders geht
    • Meine Back-End-Benutzernamen sind nicht «admin» und die Passwörter sind sehr komplex
    • Ich deaktiviere Benutzeraccounts, welche seit mehr als einem Jahr nicht mehr eingeloggt waren
    • Nicht mehr verwendete Erweiterungen werden sofort und restlos entfernt
    • Noch keine meiner Webseiten ist bisher gehackt worden, sie waren von den diversen Sicherheitslücken der letzten Wochen nicht betroffen