Beiträge von maltris

Guten Tag werte WPDE-Mitglieder,

generell ist es nicht meine Art zu solchen Anliegen um Hilfe zu fragen, da ich in meiner Vergangenheit gewiss über tausend gehackte WordPress-Instanzen gesehen und viele davon auch selber wieder auf die Beine gebracht habe. Am morgen des 15. April bemerkte ich bei einer WordPress-Instanz ein merkwürdiges Verhalten, kompromittierte DB und Daten, Umleitungen zu Scam-Webseiten, das Übliche. Das Schlagwort "stivenfernando" gepaart mit "wordpress" kann euch über die Form der Kompromittierung mittels Google aufklären.

Zunächst habe ich also ein Backup auf seine Konsistenz geprüft, WordPress, Plugins und Theme auf Aktualität geprüft und eingespielt. Hierbei fiel mir bereits auf, dass die gesamte Installation vollständig up-to-date war. Eine Komprimittierung mittels veraltetem Plugin kann ich also eigentlich ausschließen. Lediglich die PHP-Basis war noch 7.1.33, welches ich in diesem Zuge direkt auf 7.4.4 hochzog.

Zu diesem Zeitpunkt hatte ich in diversen Themen im wordpress.org Forum bereits versucht mit anderen Personen abzugleichen, welche Plugins als Einfallstor infrage kommen könnten. Überschneidungen gab es eigentlich nur bei:

• cookie-notice
• classic-editor
• duplicator

Diese Plugins deaktivierte ich also bereits vorab. Leider war die wordpress.org Forenadministration hier sehr schnell daran, alle Threads, die auf dieses Problem hinwiesen, frühzeitig zu entfernen (derzeit höchstens im Google-Cache zu finden, auf Anfrage habe ich einige Screenshots erstellt). Im Endeffekt wurde ich für meine Hilfe gegenüber Personen, die dieses Problem ebenfalls hatte, dann kurzerhand aus dem Forum verbannt.

Da ich die WordPress-Installationen u. a. mittels git-Versionskontrolle wegsichere, konnte ich hier auch sehr bequem unvermittelte Änderungen auf den Datendateien monitorieren. Bis zum Abend des 16. April war dann Ruhe, die Seite wurde trotz vollständiger Reinigung erneut auf die gleiche Weise komprimittiert. Diesmal hatte ich jedoch genug Zeit um die Accesslogs für weitere Analysezwecke wegzusichern:

45.12.32.173 - - [16/Apr/2020:16:17:54 +0200] "POST /wp-login.php HTTP/1.0" 200 7607 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"
45.12.32.173 - - [16/Apr/2020:16:17:55 +0200] "GET /wp-admin/options-general.php HTTP/1.0" 200 185769 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"

Dies waren die ersten Requests mit denen die WordPress-Installation erneut komprimittiert wurde. Für mich scheint es hier so, als wäre der Einbruch mit einer sauberen Authentifizierung gegen das Dashboard erfolgt?

Die User-Accounts wurden vorerst minimiert, Zugangsdaten prophylaktisch geändert und Salts regeneriert. Seit der Änderung sehe ich immer mal vereinzelte Login-Versuche auf das Dashboard, welche meiner Meinung nach jedoch als Grundrauschen zu klassifizieren sind.

Seht ihr bei verwalteten und/oder eigenen WordPress-basierten Seiten ähnliche Symptome?

Derzeit beobachte ich die betroffene WordPress-Instanz weiterhin und kann gerne weitere Informationen liefern.

Freue mich auf eine rege, aber geordnete und freundliche Diskussion!

Die Vorredner haben recht, daher erhältst du auch von mir die klare Empfehlung, dich nach einem qualitativen Hoster von virtuellen oder dedizierten Servern umzuschauen. Viel Erfahrung in dem Bereich sagt mir, dass du bei deinem derzeitigen Anbieter, der ja doch recht bekannt ist, kaum auf einen grünen Zeig kommen wirst, zumindest mit deren virtualisierten Systemen.

Wenn du dennoch daran festhalten möchtest, empfehle ich dir ein Performancemonitoring einzurichten, beispielsweise mittels collectd und einer entsprechenden Datenbank hinten dran, Check_MK oder anderen ähnlichen Hilfsmitteln. Hiermit wirst du dann sehen können wann und in welchem Ausmaß die Leistung degradiert wird. Schaue auch, ob zu diesen Spitzen dann eine besonders hohe IO-wait auftritt, iostat kann hierbei hilfreich sein.

Eine weitere Verbesserung kann darin bestehen, von FastCGI auf FPM zu wechseln. Unter Umständen erfährst du hier ein wenig Performancezuwachs durch die etwas andere Art und Weise mit der FPM die Daten behandelt.
Marginale Verbesserungen kannst duch auch nochmal durch ein Upgrade von PHP 7.2 auf 7.4 erreichen. Aber wie gesagt, wahrscheinlich alles wenig und marginal.

Dein IO-Test mit dd beschränkt sich auf relativ große Blöcke (1M) und erfolgt mit Lese- und Schreibcache. Hier empfehle ich dir, den "direct" Modus zu probieren um direkt auf das Blockdevice "durchzuschreiben" und kleinere Blockgrößen zu testen. Im Thomas-Krenn-Wiki gibt es eine entsprechende Anleitung mit reichlich Erklärung.

Zitat

Wenn ich Ihn drücke kommt zwar eine E-Mail aber das Formular ändert sich nicht auf den Text "Erfolgreich gesendet" (o.ä)
Also man könnte den Button 100x drücken und so meinen Posteingang zuspamen

Bitte um Verlinkung der betroffenen Seite, erst dann kann man das zuverlässig analysieren.

Zitat

(bzw alles geht in den Spam-Ordner)

Das ist wahrscheinlich eher ein Einstellungsproblem am versendenden Mailserver (hier wäre interessant wo und/oder wie gehostet) oder am Spamfilter.

Zitat

Das "Youtube Video" muss dafür auf deinem Rechner sein...

Um das noch zu ergänzen: Um, nachdem sämtliche urheberrechtlichen Aspekte geklärt sind, das YouTube-Video herunterzuladen, empfiehlt sich "youtube-dl" (auch als Windows Executable verfügbar). Insbesondere deshalb, da sehr einfach Qualitäts- und Encoding-Einstellungen angepasst werden können:

youtube-dl https://www.youtube.com/watch?v=kbLrmesC9x0

Viel Erfolg!

Hallo,

ich kenne XAMPP-VM nicht im Detail. Interessant wäre hier, wie die Dateiberechtigungen in dieser VM gesetzt werden.

Laut https://www.apachefriends.org/faq_stackman.html müssen die Dateien entsprechend kopiert werden:

Zitat

To copy files from the host system to the XAMPP-VM Apache server document root, follow these steps:

• Launch the stack manager by double-clicking the XAMPP icon in the mounted disk image.
• Mount the /opt/lampp directory from the "Volumes" tab of the stack manager and click the "Explore" button to open the file manager.
• Navigate to the /opt/lampp/htdocs directory in the file manager. This directory is the XAMPP-VM Apache server document root. Copy files to it from the host system using the file manager in the usual way.

Anschließend können die Zugriffsrechte über das XAMPP-Controlpanel "General" -> "Open Terminal" mit folgenden Befehlen angepasst werden:

User ändern (im Beispiel rekursiv und auf den User "daemon"):

chown -R daemon:daemon /opt/lampp/htdocs

Berechtigungen ändern (im Beispiel rekursiv und auf 777):

sudo chmod -R 777 /opt/lampp/htdocs

Eventuell hilft hier:

https://www.netz-gaenger.de/blog/wordpress…ogs-vor-google/ (Keine Eigenwerbung)

Lt. dem o. g. Artikel unterstützen WP Hide Post und Yoast SEO das was du dir wünscht ohne Post-IDs statisch in den Code zu schreiben.

Wünsche viel Erfolg!

Bist du ganz sicher, dass nicht einfach durch den Reload die hinzugefügte Kategorie alphabetisch sortiert wird und damit weiter unten landet?

Solltest du sicher sein: Besteht hier unter Umständen ein Caching-Problem mit Middleware? Um welches Webhosting/welches Serversetup handelt es sich?

Dann vermute ich, suchst du hiernach:

RewriteCond %{QUERY_STRING}     ^a=add&pid=5$    [NC]
RewriteRule ^whcms/cart\.php$ /lxc/basic [NC,L]

Das Ganze wäre schneller und einfacher gegangen, wenn du nicht ein völlig anderes Beispiel benannt hättest. Deine zukünftigen Kunden würden solch prinzipielle Offenheit sicher auch zu schätzen wissen.

Das sollte genau so, wie gepostet, funktionieren.

An welcher Stelle wurde die Codezeile eingefügt?

Dein Problem ist dieses File

http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js

Ich würde deine WordPress-Installation mal gezielt danach oder nach Bestandteilen dieser URL durchsuchen, dann solltest du die entsprechende Stelle finden.

Hervorragend testen lässt sich das übrigens über den Inspector des Browsers deiner Wahl oder webpagetest.org: https://www.webpagetest.org/result/180701_…014b/1/details/

Ist deine Datenbank möglicherweise korrumpiert oder hast du sehr lang laufende Queries gestartet, welche ein locking erfordern?

Mit einem

SHOW PROCESSLIST;

auf der Datenbank ließe sich letzteres schonmal ausschließen oder bestätigen.

Hallo,

zum Beispiel so:

RewriteRule ^(.*)/(.*)/(.*)$ /$1$2$3 [L]

oder

RedirectMatch 302 ^(.*)/(.*)/(.*)$ $1$2$3

(Vor "RewriteRule . /index.php [L]" einzufügen.)

EDIT: Testen kannst du das übrigens hervorragend hier.

• Hartkodierte Verweise bei der Gestaltung verwendet?
• WP Migration Plugin nicht alle Links gesucht und ersetzt? (Habe keine Erfahrungswerte davon, wie zuverlässig dieses Plugin arbeitet.)

Auch hier ist ein Link zur Seite hilfreich, dann findet man recht schnell die fehlenden Ressourcen. ;)

Erledigt, viel Erfolg!

Um das genauer zu beurteilen fehlen grundlegende Informationen.

• Link zur Seite?
• extern eingebundene Schriftart?
• CORS/CSP-Probleme? (mit einem Link zur Seite könnte man das prüfen)
• welche anderen Browser und deren Version?

Bitte die entsprechenden Informationen nachliefern, dann kann man das Problem mit Sicherheit etwas besser analysieren.

Zitat

Wie ist eure Erfahrung bei Updates - funktionieren die reibungslos?

Ja.

Folgende Reihenfolge:

• Backup von DB und Daten (sollte ohnehin regelmäßig erfolgen)
• Theme- und Plugin-Updates
• WordPress-Update
• Funktioniert alles? Ja: Gut. Nein: Backups zurückspielen.

Und wenn was schief geht, weißt du ja wo du fragen kannst...

Viel Erfolg!

Link teilbar?

Es ist zwar unwahrscheinlich, aber es kann schon mal sein, dass bei sehr alten, leistungsschwachen Webservern, nach der Aktivierung von SSL die Seite langsamer wird. Um dies und andere Faktoren auszuschließen würde ich jedoch mal mit webpagetest.org oder dem Webseiten-Analysetool deiner Wahl schauen, was da so lange dauert. Von allein wird sich daran nichts ändern, es sei denn die Ladezeiten sind auf ein temporäres Lastproblem beim Webhoster zurückzuführen.

Wenn dieses Plugin ganz herkömmlich mittels wp_mail() und damit PHP's mail()-Funktion verschickt und auch etwas ankommt, ist das schonmal ein gutes Zeichen.

Von welcher Domain*, welchem Webspace* an welchen Mailprovider* schickst du die Mails? (Das wäre wichtig in Bezug auf SPF, etc.) Möglicherweise hat sich ein Schreibfehler in der Mailadresse eingeschlichen oder die Mails werden durch einen Filter, sei es ein Filter in WordPress oder ein Filter des Ziel-Mailservers, entfernt/verschoben?

* kannst du mir gerne per PN schicken

Es kann auch schon mal vorkommen, dass Mails von bestimmten Mailprovidern aufgrund von günstigen Keyword-Konstellationen abgewiesen werden und daher noch beim Quell-Mailserver in der Warteschlange "hängen".

Ist alles akzeptabel schnell. Liegt das Problem womöglich bei dir?

http://www.webpagetest.org/result/150831_8K_FWW/

gericoach:

Und ich bewundere immer, wie jemand bei so einer Lappalie in so kurzer Zeit einen so dicken Hals bekommen kann.

Vielleicht einfach mal die Füße stillhalten und den Antworten-Button verschonen.