Wordpress Seite kein Login möglich

[TechGeek]

Hallo zusammen

Habe auf meinem kleinen Server (MacMini/MAMP) ein Wordpress für private Zwecke am laufen. In WP ist die Netzwerkverwaltung aktiviert, so dass man in der gleichen Installation mehrere unabhängige Seiten betreiben kann. Nun wollte ich eine neue solche Seite erstellen, was theoretisch auch ging. Die Seite ist mit der entsprechenden URL auch erreichbar. Aber wenn ich im Backend auf die Verwaltung der Seite will und es mich wieder zur Anmeldung weiterleiten will (wp-admin), geht das nicht. Safari meldet folgendes:

Auch Firefox geht nicht. Was ist hier wohl das Problem und wie kann man es beheben?

Danke für die Hilfe!

 

[Difool]

Hast du die Unterverzeichnis-Installation gewählt?
Denke ja, weil: domain.de/download/wp-admin/

Schau mal in deine .htaccess Datei rein, ob diese evtl. so aussieht:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) download/$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ download/$2 [L]
RewriteRule . index.php [L]

Dann entferne mal das download/, damit es so aussieht:

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) download/$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ download/$2 [L]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Alternativ zeige mal deinen .htaccess Inhalt.

 

[TechGeek]

Sieht bei mir anders aus.

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp/index.php [L]
</IfModule>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

 

[Difool]

Sieht bei mir anders aus.

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp/index.php [L]
</IfModule>
…

Wenn du RewriteBase /wp/ hast,
dann müsste in deiner config.php ja folgendes stehen: define('PATH_CURRENT_SITE', '/wp/');

define( 'WP_ALLOW_MULTISITE', true );
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);     //or true, depends on your chosen way
define('DOMAIN_CURRENT_SITE', 'localhost');    //or domain or ip, depends on your chosen way
define('PATH_CURRENT_SITE', '/wp/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Nochmal zum Nachvollziehen:

Du kannst also aufrufen und bedienen: http://localhost/wp/wp-admin/
In die Netzwerkverwaltung kommst du auch: http://localhost/wp/wp-admin/network/
Hier kannst du aber nicht drauf zugreifen, weil redirect: http://localhost/wp/download/wp-admin/

Bei einer Multisite-Installation in einem Unterverzeichnis sollte der URL überall gleich sein:
1. DB > wp_blog
2. DB > wp_sites
und auch hier:
3. wp_config.php > DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE.

 

[TechGeek]

Meine Güte wie die Zeit vergeht. Kam erst jetzt dazu das anzuschauen...

Und jetzt verstehe ich es erst recht nicht mehr, denn das Verhalten scheint sich seit damals verändert zu haben! Aber beantworte mal die Fragen...

Wenn du RewriteBase /wp/ hast,
dann müsste in deiner config.php ja folgendes stehen: define('PATH_CURRENT_SITE', '/wp/');

Ja das steht dort so.

define( 'WP_ALLOW_MULTISITE', true );
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);     //or true, depends on your chosen way
define('DOMAIN_CURRENT_SITE', 'localhost');    //or domain or ip, depends on your chosen way
define('PATH_CURRENT_SITE', '/wp/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Ja fast, nur dass ich bei

localhost

die öffentliche URL drin habe.

Nochmal zum Nachvollziehen:

Du kannst also aufrufen und bedienen: http://localhost/wp/wp-admin/
In die Netzwerkverwaltung kommst du auch: http://localhost/wp/wp-admin/network/
Hier kannst du aber nicht drauf zugreifen, weil redirect: http://localhost/wp/download/wp-admin/

Alles nein, die Lage hat sich jetzt auch verändert seit letztem mal. Komme auf gar nichts mehr und es wird mir immer "Error establishing a database connection" angezeigt. Beim /WP-Admin bekomme ich ausführlichere Informationen:

Hinter dem Link steckt diese Seite: https://wordpress.org/support/article/debugging-a-wordpress-network/
welche ich abgearbeitet habe. Bei der Datenbank stehe ich aber an, da ich davon keine Ahnung habe. Habe im phpMyAdmin keinen Überblick was da was ist...

Die localhost URL wird übrigens immer automatisch auf die öffentliche Domain URL umgeändert.

Bei einer Multisite-Installation in einem Unterverzeichnis sollte der URL überall gleich sein:
1. DB > wp_blog
2. DB > wp_sites
und auch hier:
3. wp_config.php > DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE.

Das verstehe ich jetzt nicht ganz was hier gemeint ist.

Bin jetzt echt ratlos was da los ist.

 

[Difool]

Mh, ok…

01. Du hast statt "localhost" eine Domain drin – hast du die gemappt? bzw. lief das vorher alles damit?
02. Kontrolliere mal die php-Version bei MAMP und MAMPs Datenbankserver sollte aktiv laufen, also "an" sein.

03. Welche Wordpress Version läuft für deine Multisite?

Bei einer Multisite-Installation in einem Unterverzeichnis sollte der URL überall gleich sein:
1. DB > wp_blog
2. DB > wp_sites
und auch hier:
3. wp_config.php > DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE.

Wenn du via phpMyAdmin die Datenbank öffnest, schaust du mal in die beiden Tabelle:
1. wp_blog
2. wp_sites
(dafür schlicht ^ diese Namen (links) anklicken und rechts in deren jeweiligen Inhalten scrollen zu …)

1. DOMAIN_CURRENT_SITE
2. PATH_CURRENT_SITE

Ob dort exakt die selben Angaben stehen wie sie in der config.php zu finden sind.

Check mal gegen, ob du dich bei den üblichen Anmelde-Pfaden einloggen kannst:
Beispiel:
- deine-domain.de/wp/wp-login.php
- deine-domain.de/wp/download/wp-login.php

Und schau mal nach, ob evtl. das "Einlog-Anmelde-Problem" an der "Cookie-Problematik" liegen könnte.
Dafür setzt du folgendes in die config.php

define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Vorraussetzung natürlich, daß du die Cookies zulässt und die nicht von irgendwas (Browser-AddOns) geblockt werden etc.

 

[TechGeek]

Danke vielmals für die Antwort!

01. Du hast statt "localhost" eine Domain drin – hast du die gemappt? bzw. lief das vorher alles damit?

Ja das lief einwandfrei und habe nie etwas geändert!

02. Kontrolliere mal die php-Version bei MAMP und MAMPs Datenbankserver sollte aktiv laufen, also "an" sein.
Anhang anzeigen 383931

Natürlich ist das an. Habe ich auch schon neu gestartet. PHP ist 7.4.2

03. Welche Wordpress Version läuft für deine Multisite?

Keine Ahnung, und weis nicht wo ich das nachschauen kann wenn ich nicht ins Backend komme.

Wenn du via phpMyAdmin die Datenbank öffnest, schaust du mal in die beiden Tabelle:
1. wp_blog
2. wp_sites
(dafür schlicht ^ diese Namen (links) anklicken und rechts in deren jeweiligen Inhalten scrollen zu …)

1. DOMAIN_CURRENT_SITE
2. PATH_CURRENT_SITE

Finde leider nichts dergleichen. Wenn ich phpmyadmin öffne sieht es so aus:

(Hoffe das Bild zeigt nichts probelmatisches das man nicht öffentlich posten sollte... Sonst bitte sagen)

Hab die einzelnen Einträge geöffnet und dort im Suchfeld nach den gewünschten Wörtern gesucht. Nichts!
Heisst das die Datenbank ist weg? Wenn ja, warum???

Check mal gegen, ob du dich bei den üblichen Anmelde-Pfaden einloggen kannst:
Beispiel:
- deine-domain.de/wp/wp-login.php
- deine-domain.de/wp/download/wp-login.php

Nein geht eben nicht, wie schon geschrieben. Kommt "Error establishing a database connection". Die Meldung wird offenbar von MAMP ausgegeben weil in der Browserzeile dessen Favicon erscheint. Ausserdem wird mir wenn ich lokal im Browser localhost/wp/wp-login.php eingebe die Zeile automatisch auf diese URLs umgewandelt.

Und schau mal nach, ob evtl. das "Einlog-Anmelde-Problem" an der "Cookie-Problematik" liegen könnte.
Dafür setzt du folgendes in die config.php

define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '');
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');
define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

Vorraussetzung natürlich, daß du die Cookies zulässt und die nicht von irgendwas (Browser-AddOns) geblockt werden etc.

Geändert. Da passiert auch nichts. Cookies werden nicht blockiert.

 

[Difool]

Schau mal in die wp-config.php was da für ein Datenbankname eingetragen ist:
Beispiel, wo das in der wp-config.php steht:

/**  MySQL Einstellungen - diese Angaben bekommst du von deinem Webhoster. */
/**  Ersetze database_name_here mit dem Namen der Datenbank, die du verwenden moechtest. */
define('DB_NAME', "datenbankname");

/** Ersetze username_here mit deinem MySQL-Datenbank-Benutzernamen */
define('DB_USER', "datenbank-user");

/** Ersetze password_here mit deinem MySQL-Passwort */
define('DB_PASSWORD', "datenbank-passwort");

/** Ersetze localhost mit der MySQL-Serveradresse */
define('DB_HOST', "localhost");

/** Der Datenbankzeichensatz der beim Erstellen der Datenbanktabellen verwendet werden soll */
define('DB_CHARSET', 'utf8');

/** Der collate type sollte nicht ge‰ndert werden */
define('DB_COLLATE', '');

Dort steht der Name deiner Datenbank, die für diese Installation benutzt wird:
define('DB_NAME', "datenbankname");

Und so sollte die Datenbank dann auch bei der Übersicht von phpMyAdmin heißen und stehen.
Würde mal raten, dass es bei dir wohl die project-wp sein könnte:
define('DB_NAME', "project-wp");

 

[TechGeek]

Würde mal raten, dass es bei dir wohl die project-wp sein könnte:
define('DB_NAME', "project-wp");

Ja genau das ist so. Nur wenn ich mir das anschaue erscheint da irgendwie nicht viel...

Was hat das zu bedeuten?

 

[Difool]

Ja, die Datenbank sieht nicht danach aus, als ob da irgendwelche Wordpress-Tabellen drin wären.
Schau mal nach, ob du MAMP oder MAMP Pro dafür verwendet hast.

Falls MAMP Pro, dann geht die Version ab einer Art Testzeit (Demo) nicht mehr komplett
und dann sind, meine ich mich zu erinnern, dann auch die Datenbanken weg o.s.ä.
Guck mal in diese "READ ME" rein – evtl. steht da was an Infos.

 

[TechGeek]

Pro habe ich sicher nie verwendet, nur die ganz normale Version da bin ich mir sicher. Was ziehen wir denn jetzt für einen Schluss aus dem Ganzen? Bin ich gehackt worden und jemand hat mir die Datenbank gelöscht? Oder was kann das verursacht haben?

 

[Difool]

Klick doch mal bei "READ ME" in phpMyAdmin auf "Anzeigen" und schau nach, was da steht:



Evtl. wird man dann schlauer.

 

[TechGeek]

Verstehe von SQL wirklich kaum etwas. Aber so wie ich das jetzt interpretiere sieht das für mich stark nach einem Hack aus und dass da jemand Geld möchte, um die Daten wieder herzustellen.



Detailbild hinzugefügt

 

[Difool]

Ja, das sieht tatsächlich danach aus.
Hattest du die WP-Multisite Installation in MAMP "nach draussen hin offen erreichbar gemacht"?

Auch möglich ist, wenn du ein kompromittierte Wordpress oder Plugins dort installiert hattest –
also bsw. aus "nicht offiziellen Quellen" oder schlicht veraltete Versionen betrieben hast.

Siehe bsw.:
https://www.sjoerdlangkemper.nl/2017/07/19/drive-by-remote-code-execution-in-mamp/

MAMP hat u.a. SQLiteManager inkludiert – läuft MAMP dann aktiv und du surfst "die falsche Website an" kann so etwas möglich sein:

The SQLiteManager running on localhost cannot be accessed directly by an attacker. However, the attacker can “forge” requests if he can run Javascript in the browser. If you visit the attacker’s web site he can perform the requests from within the browser, on the same computer that MAMP is installed on. These requests can access the SQLiteManager running on localhost. This method of bouncing requests through the victims browser is called cross site request forgery, or CSRF.

Auf den SQLiteManager, der auf localhost läuft, kann ein Angreifer nicht direkt zugreifen. Der Angreifer kann jedoch Anfragen "fälschen", wenn er Javascript im Browser ausführen kann. Wenn Sie die Website des Angreifers besuchen, kann er die Anfragen im Browser auf demselben Computer ausführen, auf dem MAMP installiert ist. Diese Anfragen können auf den SQLiteManager zugreifen, der auf localhost läuft. Diese Methode, Anfragen durch den Browser des Opfers zu leiten, wird als Cross Site Request Forgery (CSRF) bezeichnet.

Ich würde die komplette MAMP-Installation löschen und evtl. auch deinen Rechner mal mit Marewarebytes scannen.
edit:
Auch alle innerhalb von MAMP benutzten Dokumente entweder auf Veränderungen kontrollieren oder gar vernichten und ggf. ein autarkes Backup davon nutzen.

Eine unmittelbare Lösung für dieses Problem wäre die Deaktivierung von SQLiteManager.
MAMP-Benutzer können dies selbst tun, indem sie /Applications/MAMP/conf/apache/httpd.conf bearbeiten.
Solange niemand die Wartung des SQLiteManagers übernimmt, ist es unwahrscheinlich, dass die Sicherheitslücken behoben werden.
MAMP verfügt bereits über einen alternativen Manager für SQLite: phpLiteAdmin.

 

[TechGeek]

Ja, das sieht tatsächlich danach aus.

Meine Güte schon verrückt...! Sowas ist doch kriminell. Kann man da nichts unternehmen gegen solche Typen? Immerhin gibts ne E-Mail Adresse und ein Bitcoin Konto!

Hattest du die WP-Multisite Installation in MAMP "nach draussen hin offen erreichbar gemacht"?

Ja war per DynDNS im Netz mit einem Dienst meines ISPs direkt im Router. Allerdings war das nur ein privates Projekt für mein Umfeld und die URL war nicht gestreut. Die WP Seite war passwortgeschützt.

Auch möglich ist, wenn du ein kompromittierte Wordpress oder Plugins dort installiert hattest –
also bsw. aus "nicht offiziellen Quellen" oder schlicht veraltete Versionen betrieben hast.

Das mit den Plugins bezweifle ich. Nur alles standard zeugs innerhalb WP installiert. Updates hingegen habe ich aber sicher nicht aktiv gepflegt.

Siehe bsw.:
https://www.sjoerdlangkemper.nl/2017/07/19/drive-by-remote-code-execution-in-mamp/

MAMP hat u.a. SQLiteManager inkludiert – läuft MAMP dann aktiv und du surfst "die falsche Website an" kann so etwas möglich sein:

Naja ist ja der "Heim Server" und der wird ja eigentlich nicht zum surfen benutzt. Ausser mal YouTube Tutorials oder sonst etwas suchen (Duckduckgo) wenn man grad daran arbeitet. Würde es denn etwas bringen, wenn man dazu einen anderen Benutzer verwenden würde? Oder schlicht weg einfach gar keine Seiten mehr öffnen auf dem Rechner?

Ich würde die komplette MAMP-Installation löschen und evtl. auch deinen Rechner mal mit Marewarebytes scannen.

Danke für den Tipp! Gefunden hat es aber - Gottseidank - nichts.
MAMP ist deaktiviert und werde das auch noch komplett neu aufsetzen.

Merkwürdig am Ganzen bleibt aber immer noch dass sich das Verhalten geändert hat, seit dem eröffnen des Themas hier. Zu Beginn kam ich ja noch rein in WP und konnte sogar noch eine neue Seite erstellen und alle Multisites auch noch aufrufen. Nur ins Backend der verschiedenen Multisites kam ich nicht mehr...

So oder so hab ich hier aber sicher wieder vieles dazugelernt.

 

[oneOeight]

Kann man da nichts unternehmen gegen solche Typen? Immerhin gibts ne E-Mail Adresse und ein Bitcoin Konto!

Du solltest auf jeden Fall Anzeige erstatten, kommt zwar wohl nicht viel bei rum, weil die Täter vermutlich in einen Land sitzen das so was protegiert.

 

[JackTirol]

Ich würde dir empfehlen, das Wordfence-Plugin zu installieren. Das erkennt potenziell bösartige Zugriffe und kann sie abblocken. Laut monatlichem Report von Wordfence auf meiner Wordpress-Seite werden regelmäßig 40-80 solcher Zugriffe registriert und die zugehörigen IPs geblockt. Auch gescheiterte Login-Versuche, die definitiv nicht ich durchgeführt habe, sind regelmäßig dabei.

Das ist kein 100%iger Schutz, aber reduziert das Risiko deutlich. Nicht zuletzt weil das Plugin auch auf veraltete Wordpress- und Plugin-Versionen hinweist. Darüber hinaus musst du natürlich auch schauen, dass dein Webserver bestmöglich abgesichert ist. Dazu ist es natürlich erforderlich, dass du als Betreiber auch das nötige Wissen dazu hast und auch deinen Wissenstand bezüglich aktueller Bedrohungen und Sicherheitslücken stets aktuell hältst. Frage dich selber: Kannst du das leisten?

 

[dg2rbf]

Hi,
Tja, einen Web-Server und Mail-Server zu Betreiben, ist mit jeder Menge Arbeit verbunden, ich würde davon Abstand nehmen, hatte vor einigen Jahren einen Mail-Server in Betrieb, habs wieder Aufgegeben, machte mir zuviel Arbeit.
LG Franz

 

[Difool]

Eine schlichte htaccess-Passwort-Abfrage auf die wp-login.php bremst die bösen Bots auch schon nachhaltig aus.

Beispiel: .htaccess

<Files wp-login.php>
AuthType Basic
AuthName "My Protected Area"
AuthUserFile PFADANGABE ZUR ->/.htpasswd
Require valid-user
</Files>

 

[JackTirol]

@Difool
Nichts gegen solche Tipps. Aber damit begibt man sich in eine trügerische Sicherheit ("bremst die bösen Bots auch schon nachhaltig aus") – mal angenommen man ist nicht der große Experte auf diesem Gebiet, was ich beim TE, ohne ihm nahetreten zu wollen, vermute. Man schaue sich beispielsweise nur die lange Liste der bekannten Vulnerabilities an. Und das betrifft jetzt nur Wordpress. Der Webserver an sich ist dann nochmal ne andere Nummer. Man kann das nicht einfach vernachlässigen und das Gefühl vermitteln, mit einem simplen .htaccess-Eintrag sei alles ok.