hoffe, ich störe nicht bei den Weihnachtsvorbereitungen.
Happy Hanukkah. 😀
Nein, Spaß beiseite, wir sind hier das ganze Jahr aktiv, auch Ostern und Weihnachten, bei Bedarf auch am Heiligen Abend.
The requested URL was not found on this server.
Hm, der Zugang zum Admin-Bereich liefert auch einen „500-Internal Server Error“.
Verwendest du auf deiner Website „Affiliate Marketing“? Ich sehe ein paar Fehlermeldungen dazu, die auf eine gehackte Website hinweisen könnten.
Als Theme ist weiterhin Hueman Pro aktiviert. Du müsstest das Verzeichnis umbenennen, damit WordPress auf ein Standard-Theme („Twenty …“) zurückfallen kann.
Probier bitte auch mal was passiert, wenn du die .htaccess in z.B. no.htaccess umbenennst.
Thread-Starter
Noppi
(@noppi)
Danke @pixolin
Bin so u 100 und kannte Hanukkah nicht, ist auch lt. Goo Chanukka richtig?
Dann weiss ich das wenigstens.
Theme hatte ich inzwischen wieder zurück, weil keine Besserung kam.
Admin liefert mir kommplett blank bei _admin oder bei _login 404.
Auf der Seite sind Amazon Artikel verstreut. Mit dem Azon LinkTool.
Es waren auch andere Azon Plugins, aber noch nicht benutzt.
Zur zeit habe ich über FTP alle Plugins gelöscht.
Jetzt aktuell nur noch WP 2023 Theme
no.htaccess bringt 403
-
Diese Antwort wurde geändert vor 1 Jahr, 4 Monaten von
Noppi.
Bin so u 100 und kannte Hanukkah nicht, ist auch lt. Goo Chanukka richtig?
Ups, keine Ahnung. Hatte nur gestern gelesen, dass man sich in den USA im Moment Happy Hannukah wünscht … Egal, zurück zum Thema.
Theme hatte ich inzwischen wieder zurück, weil keine Besserung kam.
Schön, nur für uns schwer nachvollziehbar.
no.htaccess bringt 403
Das ist ungewöhnlich. Poste bitte mal den Inhalt der wp-config.php und index.php – bitte vor dem Absenden aber die Zugangsdaten zu deiner Datenbank und die SALT-Keys aus der Antwort löschen. Wir möchten niemandem die Schlüssel deiner Website in die Hand drücken.
Thread-Starter
Noppi
(@noppi)
Jau,
hab keine index.php ….??
wie kann die wegkommen?
wp-config.php
<?php
/** Enable W3 Total Cache */
define('WP_CACHE', true); // Added by W3 Total Cache
define( 'WP_MEMORY_LIMIT', '256M' );
/**
* The base configuration for WordPress
*
* The wp-config.php creation script uses this file during the installation.
* You don't have to use the web site, you can copy this file to "wp-config.php"
* and fill in the values.
*
* This file contains the following configurations:
*
* * Database settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @link https://wordpress.org/support/article/editing-wp-config-php/
*
* @package WordPress
*/
// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'xxxx' );
/** Database username */
define( 'DB_USER', 'xxxx' );
/** Database password */
define( 'DB_PASSWORD', 'xxxx' );
/** Database hostname */
define( 'DB_HOST', 'xxx' );
/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );
/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );
/**#@+
* Authentication unique keys and salts.
*
* Change these to different unique phrases! You can generate these using
* xxxx
*
* You can change these at any point in time to invalidate all existing cookies.
* This will force all users to have to log in again.
*
* @since 2.6.0
*/
/**#@-*/
/**
* WordPress database table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'WA3cd_';
define( 'WP_POST_REVISIONS', 10 );
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the documentation.
*
* @link https://wordpress.org/support/article/debugging-in-wordpress/
*/
define( 'WP_DEBUG', false );
/* Add any custom values between this line and the "stop editing" line. */
/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
Thread-Starter
Noppi
(@noppi)
Verzeichnis wp-admin hat auch keine index.php
Bego hatte aber auch gebeten, die wp-config.php ohne Zugangsdaten und SALT-Keys zu senden. 🤷♂️
Thread-Starter
Noppi
(@noppi)
Moin @hage , schicker Helm
ist noch in Genehmigung
Thread-Starter
Noppi
(@noppi)
Hab über ftp aus anderer wp-seite hochgeladen, auch im admin Verzeichnis.
Scheint noch weitere fehler zu sein
Hallo @noppi
Hab über ftp aus anderer wp-seite hochgeladen, auch im admin Verzeichnis.
keine Ahnung, was du meinst. Du müsstest das etwas genauer beschreiben, was du da veranstaltest: Du solltest bedenken, dass wir hier eine Handvoll Freiwilliger sind, die in unserer Freizeit Probleme von WordPress-Anwendern versuchen zu lösen. Wir helfen hier, so weit wir gerade Zeit haben. Insofern ist es hilfereich, wenn du auf die von uns beschriebenen Lösungsvorschläge eingehst. Dazu gehört auch, dass du notierst, was sich genau bei der Umsetzung der Lösungsvorschläge ergeben hat. Du solltest dabei auch bedenken, dass sich bei Rückfragen zwangsläufig die Zeit bis zur Lösung deines Problems verlängert.
Der Helm ist aktuell erst mal wetterbedingt im Ruhestand. 😉
Thread-Starter
Noppi
(@noppi)
OK, sorry.
sollte u. a. den Inhalt der index.php posten, habe dann über ftp gesehen, dass keine index.php im HauptVerzeichnis ist. Ebensowenig im admin Verzeichnis.
Habe dann aus einer anderen WP Installation einer anderen Domain die jeweiligen index.php ins Haupt- und wp-admin Verzeichnis hochgeladen.
PS der Post mit der wp-config.php muß hier noch genehmigt werden
Das ist alles etwas verkorkst. Bei der WordPress-Installation wird eine index.php mit angelegt – ohne die würde deine Website gar nicht laufen. Scheinbar hast du sie aber bei der Fehlersuche gelöscht.
Am besten wird es wohl sein, wenn du deinen Webhoster bittest, ein Backup wiederherzustellen.
In der wp-config.php war nichts Auffälliges. Ob deine Website gehackt und in der index.php Schadcode enthalten war, lässt sich nicht sagen, wenn du die Datei zwischenzeitlich gelöscht hast.
Thread-Starter
Noppi
(@noppi)
Ja, schon komisch mit den index.php.
Bin mir aber sicher, dass ich – auch noch 2 Dateien in unterschiedlichen Ordnern – gelöscht habe. Bin mir um die Wichtigkeit bewußt.
Werde mal ein Backup zurückspielen.
Habe noch ne Frage:
Gibt es eine Möglichkeit meine Dateien – so über ftp – beim Hoster zu scannen.
Habe keinen Plesk Zugang, nur so Hosting Pakete bei all-….
Sollte sich da was böses eingenistet haben, würde ich das gerne untersuchen und bestenfalls bereinigen.
-
Diese Antwort wurde geändert vor 1 Jahr, 3 Monaten von Noppi.
Die Wahrscheinlichkeit, dass du nach einem Angriff eine Backdoor übersiehst, ist recht hoch.
Bei Verdacht auf einen Angriff solltest du die Dateien in wp-content/uploads und die wp-config.php auf deinem PC sichern, die Dateien sehr gründlich nach möglicher Malware untersuchen (auch vermeintlich harmlose Mediendateien, *.jpg, *.png, *.ico …), eine Liste der bisher verwendeten Plugins und Themes erstellen, dann alles löschen und entweder ein Backup wiederherstellen oder WordPress, Themes und Core neu herunterladen und nach dem Löschen der Dateien auf den Server ziehen. Zuletzt wp-config.php und das Uploads-Verzeichnis wiederherstellen.
Vereinzelt und auf gut Glück Dateien löschen beseitigt meist nicht die Schlupflöcher, die sich ein umsichtiger Angreifer geschaffen hat und du fängst anschließend wieder von vorne an.
Thread-Starter
Noppi
(@noppi)
Vielen Dank,
habe die Dateien und die DB gesichert und mit Bitdefender geprüft, danach ist alles sauber.
geh auch noch mit ESET drüber, mal sehen
Das
WordPress, Themes und Core neu herunterladen und nach dem Löschen der Dateien auf den Server ziehen.
würde ich trotzdem machen.
