Beiträge von b3317133

Ausser "silence is golden" index.php sind da in der Regel keine, eine Prüfung sollte also sehr schnell gehen, daher die Frage.

Bei Themes und Plugins sollte man übrigens am Rande bemerkt nicht alleine dem WordPress Backend trauen, durch die netten "all_themes" und "all_plugins" Filter sieht man da nicht immer zwingend alles, was tatsächlich vorhanden und ggf. auch aktiv ist.

@danielgoehr Fitzkogerd beschreibt übrigens "In der Folge kommt es dann zu neuen Dateien in wp_admin" (konträr zu Deinem Punkt 1. oben) und hat offenbar einen Trigger via wp-cron erkannt, das scheint dann ggf. eine andere Variante zu sein als bei Dir. Mal die Cron-Aufrufe geprüft, mit "WP Crontrol" o.ä.?

Welche .php Dateien ausser Themes und Plugins gibt es in wp-content/ denn noch?

Das heisst, in Deinem Fall ergibt ein Diff aller Dateien des gesamten Websites und einem Satz sauberer frisch entpackter zips der gleichen Versionen des WP Core und allen Plugins und allen Themes eine 100% Übereinstimmung (ausgenommen wp-config.php)?

Teste es doch einfach: Via phpMyAdmin Export aller Tabellen aus der alten Datenbank, Import in die neue, leere Datenbank, kurze Sichtprüfung in ein paar Tabellen ob der Import geklappt hat, Umschalten DB-Zugangsdaten via wp-config.php, Sichtprüfung des Websites, falls "zerschossen", Zurückschalten via wp-config.php, alles wieder wie vorher.

Ansonsten spezifiziere bitte mal genauer, was "auf einer MySQL 5.5-Datenbank, diese macht einige Probleme" heisst. Je nach "Probleme" ist ggf. nicht die Datenbankversion die Ursache / Lösung.

Wenn man z.B. nach dem Text [COLOR=#ff0000]a[/COLOR] für [COLOR=#00b300]Dezember 2017[/COLOR] sucht, ergibt das eine URL wie diese:

[plain]http://example.com/[/plain]wp-admin/upload.php?mode=list&attachment-filter&[COLOR=#00b300]m=201712[/COLOR]&filter_action=Auswahl+einschr%C3%A4nken&[COLOR=#ff0000]s=a[/COLOR]&action=-1&paged=1&action2=-1&affected&_ajax_nonce=XXXXXXXXX&ps

Passt man die URL an, indem man den Monat weglässt, also m=2017 statt m=201712, wird nach meiner Beobachtung im ganzen Jahr gesucht.

[plain]http://example.com/[/plain]wp-admin/upload.php?mode=list&attachment-filter&[COLOR=#00b300]m=2017[/COLOR]&filter_action=Auswahl+einschr%C3%A4nken&[COLOR=#ff0000]s=a[/COLOR]&action=-1&paged=1&action2=-1&affected&_ajax_nonce=XXXXXXXXX&ps

Ob / inwieweit dann noch die Pagination funktioniert, habe ich nicht getestet, ggf. unter "Ansicht anpassen" oben die Einträge pro Seite vorher entspr. hochsetzen.

Frage doch mal bei den Jetpack Autoren nach, die haben ihre ganz eigene Meinung zu GDPR (= englische Bezeichnung der DSGVO), hier am Beispiel Cookie-Checkbox:

Zitat

If you ... disagree with that decision, I would recommend that you deactivate Jetpack's Comment form option under Jetpack > Settings > Discussion in your dashboard. Your site will then display the default comment form again, that includes a checkbox.

Edit: genauere Bezeichnung Cookie-Checkbox

Zitat von Fitzkogerd

2. dann wp_includes und wp_admin löschen bzw. neu hochladen? Was bringt das, wenn im root the wp_load.php Datei geändert wird?

Bitte genau lesen, dort steht:

Zitat

Alle Systemdateien von WordPress ersetzen, dafür wp-admin/ und wp-includes/ komplett löschen.

Die Systemdatei [FONT=Courier New]wp-load.php[/FONT] (die meinst Du wahrscheinlich, ein [FONT=Courier New]wp_load.php[/FONT] gibt es in WordPress nicht) gehört natürlich dazu. Die beiden Unterordner löscht man vorher, weil beim einfachen Überschreiben der Ordner die vom Trojaner / Hack zusätzlich irgendwo eingefügte Dateien sonst erhalten bleiben.

Wenn man Jetpack einsetzt, braucht man sich um DSGVO eher keine Gedanken mehr zu machen, das Plugin verstösst praktisch mit jeder zweiten Funktion dagegen.

@danielgoehr Es ist in den seltensten Fällen nur ein Hack, erfahrungsgemäss sind es allermeist unterschiedlichste Kombinationen aus diversen Hacks und Trojanern, die über erratene Kennwörter oder auch über z.B. "genullte" Themes und Plugins o.ä. an Bord kommen.

Zu 1. & 2. Es müssen immer ausnahmslos ALLE WordPress-Dateien, Theme- & Plugin-Dateien (auch nicht aktive) ersetzt bzw. abgeglichen werden, siehe Link oben.

Zu 3. Die beiden genannten Dateien sind legitim und müssen nicht verseucht sein, das Löschen einer legitimen [FONT=Courier New]wp-advanced-cache.php[/FONT] kann unter Umständen das Frontend eines Websites lahmlegen.

Deine Liste ist ein Erfahrungsbericht eines Einzelfalls, und falls die unter 3. genannten Dateien wirklich verseucht waren, würde ich darauf wetten, dass es noch eine ganze Reihe andere Dateien gegeben hat oder auch noch gibt.

Ein Klassiker hier ist die erste Zeile der [FONT=Courier New]wp-config.php[/FONT] oder ein paar offiziell klingende [FONT=Courier New].php[/FONT] Dateien in einem Unterordner in einem inaktiven Twenty XXX Theme.

Alternativ sucht man sich einen Hostingprovider, bei dem das automatisch geht.

WP Cron ist ein legitimer Teil des WordPress Core, darüber werden regelmässig dort eingetragene Aufgaben bearbeitet, und in Deinem Fall offenbar u.a. auch der Trojaner neu installiert bzw. repariert oder initialisiert. Die Datei [FONT=Courier New]WPINC . '/images/tnd.png[/FONT]' ist hier kein Bild sondern eine PHP-Datei mit Teilen des Trojaners.

Ändere die Passwörter einfach vor und nach dem Abarbeiten der gesamten Liste.

Mit dem Installieren eines Secruity-Plugins und dem Austausch nur selektiver Dateien ist es nicht getan. Es muss ein kompletter Abgleich aller .php Dateien auf dem Server (Core, Plugins, Theme, u.a.) mit sicher sauberen Versionen erfolgt sein. Dabei beachten, Trojaner hinterlassen gern auch zusätzliche Dateien in System- oder Theme oder Plugin- oder Upload-Ordnern, die ggf. vom Namen her legitim klingen, es aber nicht sind. Daher auszutauschende Ordner vorher komplett löschen.

Die Datei [FONT=Courier New]wp-config.php[/FONT] bei der Untersuchung nicht vergessen, dort verstecken sich Trojaner oft in der ersten Zeile, erst sichtbar wenn man im Editor gaaaanz weit nach rechts scrollt.

Ggf. empfiehlt sich auch die Nutzung professioneller Hilfe, die gibt es über die Jobbörse hier im Forum.

Wende Dich an den wordpress.com Support. Dieses Forum hier ist für selbst installiertes WordPress.

Stelle mal die Farben um, im Menü: Profil > Farbschema verwalten > Standard

Erstelle am besten ein Ticket im WordPress Core Trac.

Funktioniert es mit einem TwentyXxx Standard Theme?

Zitat von JoKo170848

Datenbankversion PHP 4.6.6 ist installiert.

Was bedeutet das? Welche PHP-Version? Welche MySQL-Version? WordPress selbst benötigt als absolutes Minimum PHP 5.2.4 und MySQL 5.0, Themes und Plugins können auch höhere Anforderungen haben.

Empfehlenswert für die Praxis wäre derzeit wohl PHP 7.1.x stable und MySQL 5.6.x

Du kannst statt dem Besucher-Trigger einen Cron-Job auf dem Server laufen lassen, wenn das der Server bietet.

Bleibt der Beitrag auch nach ein paar Stunden oder einen Tag nach dem Termin immer noch unveröffentlicht, wenn Du als normaler Besucher die Seite immer wieder mal besuchst? Evtl. gibt es irgendwelche Wechselwirkungen mit der Serverzeit.

Zum Thema DSGVO solltest Du ggf. nochmal nachlesen...

Funktioniert das geplante Veröffentlichen mit einem standard TwentyXxx Theme?

Und ist unter Einstellungen > Allgemein die richtige Zeitzone (Berlin) angegeben?

Zitat von Gurke258

Folgende Plugins sind derzeit installiert bzw. aktiviert

Tipp am Rande: Die ersten beiden Plugins sind meiner Meinung nach nicht DSGVO konform. Das dritte braucht man im laufenden Betrieb nicht.

Zitat von Gurke258

Wo kann ich denn rausfinden ob es über die Besucher getriggert ist?

Setze einen Beitrag als geplant und melde Dich von Wordpress ab. Rufe den Website nach dem geplanten Termin als normaler Besucher auf. Ist der Beitrag nach diesem Besuch veröffentlicht?

Wid ein Cache-Plugin benutzt? Falls ja, deaktivere das mal.

Und gibt es genug Besucher auf der Seite? Im normalen WordPress Setup werden Dinge wie geplante Ereignisse durch Besucheraufrufe der Seite getriggert.