1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

wp-signup unterbinden (ruft Login Seite auf)

Dieses Thema im Forum "Konfiguration" wurde erstellt von WP-58475, 13. Mai 2020.

  1. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Hallo zusammen,

    ich habe in der "All in one WP Security" die URL der wp-login Seite geändert. Wenn ich jetzt die wp-signup.php aufrufe (Registrierung deaktiv) werde ich automatisch auf die Login Seite umgeleitet, mit der Fehlemeldung, daß keine Registrierung möglich ist.

    Mit diesem "Umweg" habe ich letztendlich keinen Sicherheitsvorteil. Wie kann ich diese Umleitung der signup.php auf die Login Seite unterbinden?

    Gruß
    WP-58475
     
  2. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Tipp: Passwörter raten machen viele Bots über xmlrpc.php, dafür braucht man kein Login-Formular...

    Nutze ein sicheres Passwort, in der Kompexität wie unter Deinem Benutzer > Profil > Passwort vorgeschlagen, das ist völlig ausreichend.
     
    WP-58475 gefällt das.
  3. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    OK, dann sind evtl. einige Funktionen in der FW eher fürs Marketing, wie bei der Softwarefirewall für den PC auch :)
    Dann kann ich ruhig die Original Login URL bestehen lassen. Die Fehlversuche habe ich auf 20 gesetzt.

    - Nutzt es, wenn ich einen Honey Pot für die Login URL in der FW setze?
    - Ist das Ändern vom Tabellen Präfix WP_ auf einem anderen Wert ein (Sicherheits-) Vorteil oder eher "sinnlos"?
     
  4. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Die Möglichkeit zum Anpassen des Tabellen Präfix (das macht man am besten direkt und ausschliesslich zum Zeitpunkt der Erstinstallation) ist dafür da, dass man mehrere WordPress Installationen in einer Datenbank nutzen kann. Das war früher mal interessant, als für zusätzliche Datenbanken beim Hosting hier und da noch richtig viel Geld verlangt wurde.

    Oft liest man in irgendwelchen ganz tollen und meist alten "Tutorials", dass eine Änderung des Präfix einen Sicherheitsvorteil bieten würde, das ist mMn. Quatsch. Wenn ein Angreifer bereits in der Lage ist, über Tabellennamen auf Daten zuzugreifen, nutzt er eine sog. eine SQL-Injection (google) Lücke und man hat ganz andere Probleme als Tabellen zu "verstecken".

    Was Du wie in welcher Firewall konfigurierst oder nicht, oder ob Du eine nutzt oder nicht, bleibt natürlich Dir überlassen. Manche schwören auf dies, manche auf das, manche auf was ganz anderes, die meisten haben aber keine Ahnung, was sie da nutzen.

    Der wichtigste Punkt bei solchen Firewall u.ä. Plugins ist, dass man immer technisch zu 100% versteht, was da genau passiert, also was die entspr. Funktion der Firewall wie "verteidigt", und dazu wie WordPress sonst im Detail funktioniert, also ob/wie man den entspr. Angriffspunkt ggf. auch anderweitig umgehen könnte usw., sonst ist das oft nur "gefühlte" Sicherheit.
     
    WP-58475 gefällt das.
  5. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Jo, das mit dem Präfix mit mehreren Installationen habe ich auch so gekannt. Ich handhabe es so, daß ich mehrere Unterverzeichnisse im FTP Zugang für die Installationen nutze. 5 Datenbanken habe ich. Mit XAMP arbeite ich nur, wenn ich KEINEN Internetzugang habe. Mit SQL Injection usw. kenne ich mich (leider) gar nicht aus...

    Mir kommt die WP FW wie eine "gefühlte" Sicherheit vor: Mittlerweile habe ich heraus gefunden, wie über /?author=1 der Benutzername heraus gefunden werden kann. Die "andere" Anzeige des Benutzernamens im Blogbeitrag würde hier nix bringen. Und so eine blöde Funktion gibts in der FW, damit ein anderer Name, als der Benutzername angezeigt wird =D

    Ich will mal schauen, ob man einfach im PHP MyAdmin die Benutzer ID einfach verändern kann. Und Beiträge für "Aktuelles" dann mit "Autoren" oder sogar "Mitarbeiter" Rechten (mit Genehmigung vom Admin für Veröffentlichung) schreiben lassen.

    Ich will die XML RPC Schnittstelle komplett abschalten. Leider muß man das in der funcions.php machen, was ich grob gelesen habe. Dann wäre beim Update wieder alles weg. Mal schauen, ob der Blog für "Aktuelle Beiträge" noch funktioniert. Evtl. verzichte ich auf so einen Blog und schreibe das alles manuell auf die Webseite. Blog zum Kommentieren von Beiträgen nutze ich gar nicht...
     
  6. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Irgendwelche IDs direkt in der Datenbank anpassen führt meist zu Folgeproblemen.

    An Benutzernamen kommt man auch anders, sie werden zum Teil z.B. durch die REST-API ausgeplaudert, ein kleiner Nebeneffekt des ach so tollen Gutenberg Editors...

    Um die REST API nach aussen abzuschalten gibt es diverse Plugins, wie auch diverse Plugins für das Abschalten von XML RPC. Schau Dir deren Code an, und bau Dir ggf. bei Bedarf ein eigenes kleines Plugin, das nur das macht, was Du willst und verstehst.

    Am wichtigsten neben aktuellem Theme/Plugins/PHP/usw. ist ein sicheres Passwort, wie beschrieben so was ähnliches wie wenn man im Benutzerprofil auf "Passwort generieren" klickt.
     
    WP-58475 gefällt das.
  7. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Mein PW ist schwer zu erraten, weil es ein Satz ist, bei dem jedes Wort der Anfangsbuchstabe genommen wird =D
    Es kommt also eine Buchstabenkombi heraus...

    Den Gutenberg Editor habe ich durch den Classic Editor ersetzt. Keine Ahnung, ob die Gutenberg-Schwachstelle dann noch aktiv ist...
    Was auch "genial" von diesen FW sind: Die WP Versionsnummer im Quelltext verstecken =D Selbst ich als Anfänger hatte schon daran Zweifel, ob das überhaupt etwas bringt...

    Mal ne Frage, weil Du Dich mit dem Thema gut auskennst: Bringt die Sperre bei "Fehlversuch Login" von der Sicherheit etwas, wenn jemand über die verschiedenen Schnittstellen eine Bruteforce macht? Der "Mensch" wäre ausgesperrt. Keine Ahnung, wie es bei einem Robot aussieht...
     
  8. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Benutzer via REST-API sieht man ohne weitere Massnahmen so:
    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Die Version einer WordPress Installation kann man anhand diverser Dinge ermitteln, auch z.B. aus der Kombination von vorhandenen JavaScript oder CSS Dateien mit entspr. unterschiedlichen Inhalten. Das kann niemand blocken.

    Allerdings ist es den meisten Botnetzen sowieso völlig egal, welche Version oder ob überhaupt WordPress auf einem Server läuft, er wird mit allen möglichen Dingen bombardiert, vollautomatisiert.

    Wenn Bots zu sehr nerven sollten, kann man die IPs eine Weile mitloggen und dann diese bzw. eine entspr. IP-Range direkt in der .htaccess blocken, dann wird WordPress gar nicht mehr davon erreicht.
     
    WP-58475 gefällt das.
  9. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Damit sehe ich den Admin und den geänderten Anzeigename im Blog :)

    Und wie sieht es aus, wenn z. B. eine DOS Attacke mit ständig geänderten IP Adressen statt findet, die außerhalb der IP Range liegt? Dann kommt man mit dem Blockieren gar nicht mehr hinterher. Aber wahrscheinlich kommt das in der Praxis seltener vor...
     
  10. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Wenn Du tatsächlich eine echte DDoS-Attacke exakt zielgerichtet gegen Deinen Server haben solltest, nutzt ein WordPress Firewall Plugin erst recht nichts und ist vielmehr kontraproduktiv, da es nur die Serverlast zusätzlich erhöht.

    Wende Dich in so einem Fall am besten an Deinen Hostinganbieter, ein aufmerksamer Anbieter wird sowas aber ohnehin bereits selbst bemerkt haben und eigene Massnahmen ergreifen.

    Alternativ blockiere z.B. für eine Weile alle Besucher via .htaccess und werte alle IP-Adressen aus den Access-Logs aus, meist sind die heutzutage wg. DSGVO teilanonymisiert, aber das ist egal, da man in der Regel trotzdem eine IP-Range daraus ableiten kann und sperre dann all diese IP-Ranges grosszügig in der .htaccess, das fängt relativ viel ab.

    Das hat mit WordPress aber rein gar nichts mehr zu tun. Dafür gibt es andere Foren, die sowas viel detaillierter und nicht nur so grob zusammengefasst behandeln.
     
  11. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Einfach interessehalber: Ist eine normale Webseite mit Adobe Muse sicherer, als mit Word Press? Bei Adobe Muse habe ich "nur" einen FTP Zugang ohne irgendwelche Admins, Redakteure und Angriffsschnittstellen?
     
  12. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    Jedes System das fertige Seiten mit rein statischem HTML/JS/CSS generiert ist sicherer.

    Voraussetzung ist natürlich, dass die FTP-, bzw. besser SFTP-Zugangsdaten nicht abhanden kommen...
     
  13. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Jo, ist SFTP :)

    Ist es sinnvoll, die wp-login mit einer .htaccess Datei (mit Benutzername und Kennwort) abzusichern? Oder würden hier die Schnittstellen Probleme weiter als Angriff dienen, so daß die .htaccess "übersprungen" werden kann? Ich lese gerade diesen Bericht und er sieht ebenfalls, daß die FW wenig Sinn machen: https://www.kuketz-blog.de/htaccess-schutz-wordpress-absichern-teil4/

    Mit dem /wp-json/wp/v2/users bekomme ich immer den 1. Admin Benutzername angezeigt, obwohl ich testweise 2 angelegt habe...
     
  14. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    11.634
    Zustimmungen:
    1.778
    XML-RPC geht an wp-login.php vorbei. Zugriffe auf wp-login.php werden auch für normale passwortgeschütze Seiten in WordPress benötigt. Zugriffe auf /wp-admin/.. werden u.a. für AJAX-Aufrufe im Frontend von diversen Plugins und auch Themes benötigt. Eine wie auch immer geartete .htaccess Sperre hat meistens unerwünschte Folgen. Daher sicheres Passwort, fertig.

    Poste einen Beitrag o.ä. mit dem zweiten Admin.
     
    WP-58475 gefällt das.
  15. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Habe jetzt das "Disable WP REST API" installiert. Jetzt erhalte ich bei wp-json/wp/v2/users eine negative Rückmeldung, siehe Anhang :) Ich hoffe, daß die API Schnittstelle tatsächlich deaktiv ist. Wie ich die XML-RPC Schnittstelle testen kann, weiß ich leider nicht...

    API.png

    Mit ?author=ID sehe ich weiter den Benutzer. Geht das auch über API?
    Diese Funktion hat in der "All in one Sec FW" null Funktion... =D
     
    #15 WP-58475, 14. Mai 2020
    Zuletzt bearbeitet: 14. Mai 2020
  16. WP-58475

    WP-58475 Member

    Registriert seit:
    9. Mai 2020
    Beiträge:
    24
    Zustimmungen:
    0
    Wie sieht es von der Sicherheit aus, wenn ich auf Updates verzichte, weil ich die Schreibrechte für alle PHP Dateien auf 444 gesetzt habe? Die wp-config auf 400...
     
  17. RTW

    RTW Member

    Registriert seit:
    29. Mai 2020
    Beiträge:
    18
    Zustimmungen:
    1
  18. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.351
    Zustimmungen:
    345
    Ich erstelle auf all meinen Kundenseiten folgende Konfiguration:
    1. xmlrpc per htaccess unterbinden (im Gegensatz zu @b3317133 kann ich auf keiner Seite Probleme feststellen)
    2. plugin limt-login (wie von @RTW auch vorgeschlagen)
    3. wp-hide-login (Umleitung der loginseite)
    4. iq-block-country (allen IPs außerhalb De den Zugriff auf das Backend verwehren)

    Das ist für mich die bisher bestmögliche Sicherheitskombi und lässt 95% der Angriffe ins Leere laufen. Auch Bruteforce kommt da mE nicht durch. Natürlich gilt als 1. Regel das von @b3317133 angemerkte sichere Passwort, diese Regel hilft aber wenig, wenn man nie sicher sein kann, dass Kunden, Mitarbeiter und Redakteure sich daran halten, weshalb zumindest ich mich lieber auf meine eigene Sicherheitskombi verlasse.
     
    RTW gefällt das.
  19. RTW

    RTW Member

    Registriert seit:
    29. Mai 2020
    Beiträge:
    18
    Zustimmungen:
    1
    Vielleicht sollte man an dieser Stelle auch nochmal anmerken, dass ein Backup eigentlich ein guter Garant ist, dass man seine Seite im Falle einer feindlichen Übernahme auch wiederherstellen kann.
     
    meisterleise gefällt das.
  20. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.351
    Zustimmungen:
    345
    Auf jeden Fall! Fast genauso schlimm ist allerdings, wenn der Hacker deinen Webauftritt kopiert hat und als Fakeseiten online stellt. Dann hat man richtig stress.
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden