LogIn-Versuche über Frontend ohne login-componente und obwohl Frontend-LogIn deaktiviert ist

    • Neu
    Joomla Version
    5.2.1
    PHP Version
    PHP 8.3.x
    Hoster
    webgo
    Link (URL) zur Seite mit dem Problem
    https://clemens-psychotherapie-weinheim.de

    Seit ca. 1 Woche bekomme ich vom Plugin BruteForceStop Versuche gemeldet, dass jemand versucht, sich über das Frontend einzuloggen. Dies geschieht bei zwei meiner Websites. Das wundert mich sehr, da jegliches Frontend-Einloggen deaktiviert ist. Als Template nutze ich YooTheme Pro, das auf dem UiKit aufbaut. Auch über YooTheme nutze ich kein Element, das ein Frontend-Login ermöglichen könnte.

    Bei diesen Versuchen wird die reguläre Homepage-URL genutzt und BruteForceStop meldet dann:

    Code
    Benutzername:  \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
IP-Adresse:    5.42.107.248
Zeitpunkt:     2024-11-15 07:42:11
Quelle:        Frontend

    Ungewöhnlich ist auch, dass BruteForceStop kein Passwort meldet, das bei dem Versuch genutzt wurde.

    Ich habe den gerade erst laufenden Beitrag component users ausschalten natürlich auch gelesen. Aber es gibt ja keinen Hinweis darauf, dass diese Komponente für die von mir beobachteten Versuche genutzt wurde. Zudem finde ich diese Komponente bei mir nicht, da ich YooThemePro benutze.

    Frage: Besteht hier Handlungsbedarf? Wenn ja, wo sollte ich eingreifen?

    • Neu

    Ja, es wäre durchaus sinnvoll zu handeln.

    Die Lösungsmöglichkeiten für dein Problem hast du ja bereits selbst gefunden und verlinkt.

    Dann funktioniert eben z.B. das nachfolgende nicht mehr:

    clemens-psychotherapie-weinheim.de/index.php?option=com_users////&view=login

    • Neu
    Zitat von Clemens-XS

    Seit ca. 1 Woche bekomme ich vom Plugin BruteForceStop Versuche gemeldet, dass jemand versucht, sich über das Frontend einzuloggen. ...

    Frage: Besteht hier Handlungsbedarf? Wenn ja, wo sollte ich eingreifen?

    Es besteht u.a. Handlungsbedarf insofern, das Du unbedingt eine Benachrichtigung per Email bei solchen Vorfällen abschalten solltest. Falls es tatsächlich mal massive Zugriffe gibt (also echte Bruteforceattacken), löst das auch jedes mal eine Email aus und damit müllst Du nicht nur Dein Postfach voll, sondern eine solche Emailflut kann auch ganz andere Folgen nach sich ziehen - je nachdem was für einen Emailserver Du benutzt. Also z.B. Blacklisting, Sperrung, Überlastung und Sperrung beim Provider etc.pp.

    Grundsätzlich rate ich auch dazu immer auch ein wirksames(!) Captcha einzurichten, welches auf alle Formulare wirkt. Auch wenn Formulare nicht direkt freigeschaltet werden, gibt es im Joomla diverse "integrierte" Formulare, die man einfach nur mit typischen bekannten Links aufrufen kann. Oben siehst Du ja ein Beispiel. Wirksame Captchas halten die meisten Bot-Zugriffe ab.

    • Neu

    flotte Meine Datenbank läuft nicht voll, weil ich BruteForceStop so eingestellt habe, dass die Anzahl versendeter Mails begrenzt ist und dass nach mehrmaligem Login-Versuch mit der gleichen IP-Adresse, diese gesperrt wird. BruteForceStop ist da schon ziemlich gut.

    Um die Problematik, dass trotz deaktivierter Benutzer-PlugIns für das Frontend dennoch über solch einen Link ein Anmeldefenster gezeigt wird, muss ich mich noch kümmern. Gemäß des o.g. Threads component users ausschalten habe ich aber noch nicht gefunden, wo ich mit einem Override eingreifen müsste. Ich nutze kein Cassiopeia sondern YooTheme Pagebuilder und evtl. liegen die zu ändernden Dateien woanders.

    • Neu
    Zitat von Clemens-XS

    ...Ich nutze kein Cassiopeia ....

    Beachte aber das man die users-Komponente und das Formular auch per Cassiopeia-Template aufrufen kann z.B per:

    clemens-psychotherapie-weinheim.de/index.php?option=com_users////&view=login&template=cassiopeia

    • Neu

    Eventuell genügt es einen Menüeintrag vom Menüeintragstyp Anmeldeformular zu erstellen

    bei dem "Im Menü anzeigen" auf Nein steht und bei dem in den den Details der Template-Stil Cassiopeia gewählt ist und die Zugriffsebene auf Public ist.

    Dann genügt eventuell schon der Template-Override wie bereits beschrieben...

    Habe es aber nicht geprüft bezüglich YooThemePro ...

    • Neu

    Ich habe mich versucht, durchzuwursteln mit den Override-Empfehlungen usw. bin aber nicht wirklich weiter gekommen damit. Eine dieser Änderungen führte gleich zum Ausfall der Website. Nicht lustig!.

    Nachdem ich die Empfehlung von WM-Loose gelesen habe, bleibe ich doch jetzt bei dem, was ich schon habe: Das Kubik-Rubik-Intrusion System macht exakt das, was das kostenfreie Plugin Brute Force Stop auch macht. Und das funktioniert schon seit Joomla 1.x für mich zuverlässig.

    Ich habe doch sowieso immer im Backend eine LogIn-Möglichkeit für den Admin. Ob ein Angreifer versucht, darüber ins System zu gelangen oder über das Frontend, ist doch völlig Wumpe. Hauptsache, er wird nach 2 oder 3 Versuchen zuverlässig ausgesperrt. Allerdings sperre ich das Backend sowieso mit einer htaccess.

    Solange Joomla im LogIn-Plugin keine Sicherheitslücke reinbaut, bin ich auf der sicheren Seite: Der Admin-Name / Benutzername besteht bei mir aus einem 22-stelligen passwort-artigen Gebilde und das Passwort hat ebenfalls 22 Stellen.

    Solange jetzt keine Gegenargumente kommen von Menschen, die mehr KnowHow haben als ich, lasse ich alles so, wie es jetzt ist.
    Wie seht Ihr das?

    • Neu

    Andreas24 Genau deshalb habe ich die Zahl 22 genannt, weil dieses Forum ja öffentlich lesbar ist. Wer sagt denn, dass ich wirklich 22 Stellen verwende?

    Und wenn doch, rechne mal aus, wie viele Kombinationen es aus zwei 22-stelligen "Wörtern" gibt (Admin-Name 22-stellig und Passwort 22-stellig) und dann noch das Handicap, dass nach drei oder wie viel vergeblichen Versuchen bereits die IP durch BruteForceStop gesperrt wird. Besonders in Verbindung mit diesem Handicap dürfte es unrealistisch sein, hier eine Gefahr zu vermuten.
    Da würde ich eher die Sorge haben, dass doch mal eine LogIn-Komponente den eingegebenen Code nicht 100% zuverlässig prüft und der Hacker dann doch eindringen kann.

    Jedenfalls bin ich jetzt wieder beruhigt. Diskussionen wie die in dem o.g. Thread component users ausschalten nützen wenig, bringen aber "den Aufreger des Tages". :)

    • Neu

    Da bin ich anderer Meinung.

    BruteForceStop oder IDSJ sind bestenfalls eine fragwürdige erste Stufe der Bedrohungserkennung und nützen nur wenig und können selbst auch gefährliche Sicherheitslücken haben. Siehe z.B. Zitat aus IDSJ

    Zitat

    Hinweis: Das Plugin säubert oder filtert keine bösartigen Eingaben, sondern führt die ausgewählten Aktionen aus, wenn ein Einbruchsversuch erkannt wird. Ein IDS-System sollte nicht als alleiniger Schutz in Ihrer Umgebung eingesetzt werden! Verwenden Sie es als erste Stufe der Bedrohungserkennung.

    aus: https://kubik-rubik.de/de/idsj-intrus…stem-for-joomla

    Insbesondere die Nutzung von Login-Formularen, sofern diese nicht benötigt werden, zu deaktivieren ist sicherlich sinnvoll, auch wenn dies insgesammt auch nur ein geringer Sicherheitsgewinn ist...

    Zitat von Clemens-XS

    ...Da würde ich eher die Sorge haben, dass doch mal eine LogIn-Komponente den eingegebenen Code nicht 100% zuverlässig prüft und der Hacker dann doch eindringen kann...

    Das ist ja die Users-Komponente, da es in Joomla keine Login-Komponente gibt.

    Wenn das Login-Formular der Users-Komponenze gar nicht nutzbar ist, weil deaktiviert, dann ist auch keine diesbezügliche Sicherheitslücke nutzbar. Dann braucht dein BruteForceStop diesbezüglich auch nichts tun...

    • Neu

    Mir ist es schwer gefallen, die zu ändernde default.php zu finden. Ich habe die default.php per Override nun gefüllt mit:

    <html> <head> <meta http-equiv="refresh" content="0; URL=/"> </head> <body> </body> </html>

    und der Test mit den beiden oben im Thread stehenden Links verlief positiv: Nach kurzem Flackern landete man wieder auf der Homepage.

    Herzlichen Dank!

    • Neu

    Gestern hatte ich erst eine meiner Sites abgesichert. Heute wollte ich bei den anderen die Absicherung nachholen. Nun stelle ich fest, dass es bei drei weiteren Sites weder im Cassiopeia-Template noch im YooTheme-Template ein Unterverzeichnis "com_users" gibt. Eine dieser Sites wurde gerade erst frisch installiert und kann daher wohl kaum kaputt gefrickelt worden sein.

    Wie kann das sein? Wo liegt denn in solch einem Fall die "com_users"?

    • Neu

    oder alternativ die benötigten fehlenden Dateiordner und Dateien selbst erstellen an der richtigen Stelle...

    Übrigens gibt es im Backend auch den Hilfe-Button:

    help.joomla.org/proxy?keyref=Help52:Templates:_Customise&lang=de

    bei Joomla 4 ist es bereits auch ins deutsche übersetzt:

    help.joomla.org/proxy?keyref=Help40:Templates:_Customise&lang=de