Beiträge von rainerb

Vielen Dank b3317133 für deinen letzte Antwort!

Das Problem ist seit 2 Tagen im debug.log und Betrieb nicht mehr aufgetreten.
Und zwar nach zwei Änderungen:
1. Umstellung v PHP 7.4 auf 8.0
2. Beseitigung eines beim 8.0-Test angezeigten PHP-Fehlers im podcast plugin Seriously Simple Podcasting (SSR). Vermutlich ein Tippfehler bei 'search_items' %a statt %s. Zumiindest war nach Änderung der PHP-Error weg und 8.0 lief:

[size=12]class_admin_controller.php
public function register_post_type() {[/SIZE]
[size=12] $labels = array(
'name' => _x( 'Podcast', 'post type general name', 'seriously-simple-podcasting' ),...
'singular_name' => _x( 'Podcast', 'post type singular name', 'seriously-simple-podcasting' ),...
'add_new' => _x( 'Add New', 'podcast', 'seriously-simple-podcasting' ),...
'add_new_item' => sprintf( __( 'Add New %s', 'seriously-simple-podcasting' ),...
'edit_item' => sprintf( __( 'Edit %s', 'seriously-simple-podcasting' ),...
'new_item' => sprintf( __( 'New %s', 'seriously-simple-podcasting' ),....
'all_items' => sprintf( __( 'All %s', 'seriously-simple-podcasting' ), ...
'view_item' => sprintf( __( 'View %s', 'seriously-simple-podcasting' ),...
'search_items' => sprintf( __( 'Search %a', 'seriously-simple-podcasting' ),...
'not_found' => sprintf( __( 'No %s Found', 'seriously-simple...[/SIZE]

Nach der PHP-Umstellung war dann max_user... im debug.log verschwunden. Als ich das bemerkte, war allerdings das Zeitlimit für eine Rückstellung auf 7.4 schon vorbei, sodass ich nicht mehr prüfen konnte, ob durch Zurücksetzen auf %a sich der Fehler max_user... reproduzieren lässt und damit als Ursache indentifiziert werden könnte. Dagegen spricht allerdings, dass ich das Plugin mehrere Stunden deaktiviert hatte, aber max_user im debug.log weiter angezeigt wurde und auch Fehler 500 weiter auftraten.

So bliebe nur die Möglichkeit, dass irgendein anderer unbekannter Fehler mit 8.0 eliminiert wurde. Keine Ahnung...

Problem ist aber derzeit gelöst. Wie gesagt: Nichts gefunden - viel gelernt....

Besten Dank noch mal an alle für Eure Hinweise!!

Ich hab die access.log Zeitangaben mal geprüft. Die sind natürlich korrekt, andernfalls hätte das log ja gar keinen Sinn für Analysen aller Art.

Aber was könnte es bedeuten, dass zu den Warnungen max-user... im debug.log keine synchronen 500 im acces.log auftauchen, was ja die Folge von max_user... sein müsste, oder nicht? Man macht sich als Laie so seine Gedanken...

Seit 3 Tagen keine Einschränkungen in der Sichtbarkeit bei fortbestehendem max_user.... Heute bis 20 Uhr nur bei 2 Nutzeranfragen error500, bei 2500 Zugriffen. Allerdings wurden gestern und heute keine neuen Beiträge eingestellt, sodass abzuwarten bleibt, was passiert, wenn die Zugriffszahlen wieder über 10k oder 20k steigen...

Zitat von b3317133

Dein Website ist nach kurzem Querlesen des Threads nicht angegeben...

Entschuldige, sie war im 1. Beitrag angegeben. Hatte den Admin nachträglich gebeten, statt der Klaradresse unter 'Blog' zu verlinken. Nun hat er die Verlinkung aber ganz entfernt. Also hier nochmal der Blog verlinkt.

Was mir beim Abgleich von wp-debug.log und access.log noch aufgefallen ist, dass für eine max_user.. im debug keine synchrone 500 im access.log vorhanden ist. Also wenn im debug max_user.. innerhalb 4s 30x aufgelistet wird, gibt es im access.log zum gleichen Zeitpunkt keine 500. (Wie gesagt, ich weiß von der techn Seite nicht, ob so eine Folgerung überhaupt zutreffend ist.) Es wäre ja möglich, dass im access.log auch die Zugriffszeit asynchron zu den Nutzern anonymisiert ist. Da muss ich nochmal beim Hoster nachschauen bzw an einem eigenen Zugriff überprüfen.

Zitat von b3317133

Wenn eine WordPress Installation gehackt ist, dann ist alles darin als kompromitiert zu betrachten...

Ich meinte dann wohl eher Viren u dgl., die aber in diesem Fall zu einer DB-Belastung führen müssten. Nach dem Malcure-Scan müsste das jetzt aber zumindest ausschließbar sein?

Zitat von b3317133

Bei einem Fehler 'max_user_connections' landet nichts in der WP-Slimstat Datenbank, somit kannst Du das auch nicht sinnvoll auswerten.

In der Slimstat-Tabelle landet doch alles, was nicht per 500 vom Server abgewiesen wird, also alle 200 usw. Verbindungen. Der Server kann sicher nicht bei der DB-Zugriffsbegrenzung zw. normaler Nutzeranfrage und DoS unterscheiden, wie das bei einer DoS-Filterung der Fall wäre. Also müsstens mE auch viele DoS-Anfragen regulär unterhalb der DB-Zugriffsbegrenzung bedient und somit bei Slimstat landen und evtl als IP-Muster erkennbar sein. Oder hab ich da einen Denkfehler?

Ich kann es hier nur mit Logik versuchen, weil ich keine Kenntnisse habe, was ein Server bei max_user_connections technisch wirklich macht.

Hallo,

ich muss/kann für diesen Beitrag mal alles auf Null setzen. Tut mir leid um Eure bisherige Denkarbeit!

Eine DoS lässt sich nicht bestätigen:

• Es war ein Irrtum meinerseits, DoS-Muster über das access.log des Hosters erkennen zu können, weil dessen IP-Anonymisierung unabhängig von den tatsächlichen Zugriffsverlauf erfolgt. Unter einer "verdächtigen" langen Reihe anon-0.0.0.93.ip6.invalid habe ich nämlich auch meine eigenen Zugriffe und Agentangaben gefunden.
• WP-Slimstat (jetzt von VeronaLabs übernommen) bietet eine Echtzeit-Zugriffsanzeige, mit der ich die Klar-IPs optisch überprüfen konnte. Die DB-Tabelle dazu, allerdings ohne Zeitverknüpfung, hab ich exportiert und nach Häufigkeit sortiert. Dabei ergibt sich aber nichts, was auf DoS hindeuten könnte. Alles normales Nutzerverhalten.

Zitat von meisterleise

Und das die Seite nicht gehackt ist hast du also geprüft uns sichergestellt?

Zur Sicherheit hab ich noch mal einen Scan (1,5h) mit einem zweiten Malware-Scanner gemacht. Ein "DeepScan" von Malcure hat auch keine Malware gefunden, sodass ich als davon ausgehe, dass kein Hack vorliegen kann.

Wie schon gesagt, wp6.1.1.1 und alle Plugins aktuell. Nur ein podcast wegen Layoutproblemen nicht. Dieses Plugin habe ich aber testweise über mehrere Stunden deaktiviert, ohne dass sich an max_user-connections etwas änderte.

Da bin ich als Laie momentan am Ende mit meinem Latein.
Nichts gefunden, aber viel gelernt!

Auf jeden Fall wird es wohl einen Wechsel zu DomainFactory geben. Die bieten einen Überlastungsschutz durch Separierung bei hohem Zugriffsvolumen. Damit müsste der Blog dann gegen tatsächliche DoS zeitnah geschützt sein.

Besten Dank bis hierhin an alle!

Danke r23 und andere!

Ich hab die Logs angesehen und würde laienhaft vermuten, dass ein DoS-Angriff vorliegt. Über Stunden gehende, periodisch auftretende große Abfragen von mehreren ip6.invalid. Da es ein politischer Blog ist, könnte ich mir Angreifer vorstellen, die sich kein Botnetz leisten können und es daher mit wenigen Engeräten versuchen.

Ich hab jetzt erst mal den Cache verbessert, sodass dadurch die DB-Zugriffe reduziert werden. Der Blog läuft derzeit eigentlich. Wp debug.log zeigt aber weiterhin einige kurzeitige max user connections im 5-30min Abstand. Also die von mir vermuteten DoS-Angriffe laufen weiter aber meist unter der Sichtbarkeitsgrenze. Ich hab jemand gefunden, der die Logs mal anschaut, weil ich für eine DoS-Mustererkennung in Logs keine Erfahrung habe.

Ob dieses "kleine" Problem auf Domainebene vom Hoster erkannt und gefiltert werden kann, weiß ich momentan nicht. Es läuft ein Ticket... Ich informiere.

Nebenbei: Da öfters Cerber genannt wurde. Das Plugin wird v. Wordpress wegen "Security issue" nicht mehr angeboten. Die Info könnte auch von einem Satiriker stammen...

Schon mal herzlichen Dank an Euch, dass ihr am Sonntag hier unterstützt!!

Die Anfragen führen nicht auf's Login, sondern den podcast, den aktuellen Beitrag u.a., also alles Inhaltsabfragen.

Die Quelle ist vlt ein Botnetz, weil verschieden. Mal ein Mac, dann Win oder Handys.

Crawler? Da müssten doch auch robot oder sitmap mit abgefragt werden. Das ist aber nicht zu sehen.

Also, ich denke auch, hier muss ein Sicherheitsplugin her. Habt ihr einen passenden Tipp angesichts des Problems, damit ich mir das Ausprobieren sparen kann?

Danke Euch!

Ja, der Hostwechsel ist ein anderes Thema. Bisher lief die Seite aber problemlos.

Meine IP-Sperrung war etwas naiv, da ich jetzt beim Runterladen der access.log gelesen habe, dass IP und Hostnamen darin anonymisiert sind und das Problem der gehäuften DB-Abfragen auch weiterhin ersichtlich.

Ich komme wohl nicht um eine IP-Erfassung zwecks Sperrung herum. Die Statistik läuft jetzt ohne solche.

Kann jemand ein kleineres Plugin empfehlen, mit dem ich IPs erfassen und auswerten kann? (Aber nicht WPstatistic, das hatte sich aufgebläht und zur DB-Sperrung wg Speicherüberschreitung geführt.)

All-in-one-WP-Securitiy lese ich oft, aber das scheint sehr umfänglich zu sein?

Besten Dank!

Danke für deine schnelle Antwort!

Ist ja witzig: user o197xxxx, dessen Identität ich enttarnen wollte, ist also der Blog selbst... haha

Der Hoster erkennt wohl leider nichts, sondern schreibt: "Sie müssten nun also prüfen, warum Ihre Webseite so viele Verbindungen aufbaut und dies reduzieren." - auch witzig...

Also habe ich noch mal in der access.log genauer reingeschaut. Ein Verdachtsfall war mir schon aufgefallen, aber wenn man sich nicht sicher ist, ob die Störung von außen kommt, kann man als Laie nicht wirklich zu Erkenntnissen kommen. Insofern war dein Hinweis auf eine externe Störung eine sehr hilfreiche Bestärkung.
Ich hab jetzt drei IPs von ip6.invalid herausgefunden [size=12](0.0.0.171, 0.0.0.193, 0.0.1.25)[/SIZE], die zeitlich aufeinanderfolgend (nicht abwechselnd) ca. ein Dutzend Anfragen/s stellen.

In der htaccess hab ich jetzt den Adressbereich 0.0 gesperrt und werde dann in der access.log kontrollieren, was passiert. Dazu geb ich hier noch Bescheid.

Nochmal besten Dank!

Hallo,

laut Forumsuche scheint es ein seltenes Problem zu sein:
Der Blog [size=12](WP 6.1.1. PHP 7.4)[/SIZE] war am 10.1.23 nur mit viel Glück aufrufbar. Die Meldungen "Fehler beim Aufbau einer Datenbankverbindung" und "Internal Server Error 500" wechselten sich ab, mit Schwerpunkt auf ersterer. Seitdem tritt der Fehler für Nutzer weiterhin sporadisch auf.

Der Hoster sagt serverseitig alles i.O., registriert aber eine zu hohe Zahl an DB-Abfragen, die die eingestellte Zugriffsobergrenze 'max_user_connections' übersteigt.

Im wpdebug_log erscheint die Störung mit kurzen Unterbrechungen sich ständig wiederholend so:

[size=12]PHP Warning: mysql_connect(): User .... already has more than 'max_user_connections' active connections in /.....htdocs/home/wp/wp-includes/class-wpdb.php on line 1807
PHP Warning: mysqli_real_connect(): (42000/1203): User .... already has more than 'max_user_connections' active connections in /...../htdocs/home/wp/wp-includes/class-wpdb.php on line 1775
[PHP Warning: mysqli_real_connect(): (42000/1203): User ..... already has more than 'max_user_connections' active connections in /...../htdocs/home/wp/wp-includes/class-wpdb.php on line 1775
PHP Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /...../htdocs/home/wp/wp-includes/class-wpdb.php on line 1807[/SIZE]

Der "Problem"-User hakt also permanent in der class-wpdb.php bei Zeile 1775:

[size=12] if ( WP_DEBUG ) {[/SIZE]
[size=12] mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );
}
else...[/SIZE]

[size=14]bzw. 1807:
[/SIZE]
[size=12] if ( WP_DEBUG ) {
$this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, $new_link, $client_flags );
}
else...
[/SIZE]
[size=14]Und hier bin ich leider am Ende meines Lateins: Wer ist User ..... ? Wo und mit was kann ich ihn finden - wp intern oder extern? Plugins hab ich alle deaktiviert - erfolglos.[/SIZE]
[size=12][/SIZE]
[size=12][size=14]Besten Dank für alle Hinweise, die zur Ergreifung des Übeltäters führen![/SIZE][/SIZE]

Das ist hier ja rekordverdächtige Live-Betreuung innerhalb 7min...! Oder einfach der Standard? Jedenfalls besten Dank für deine prompte Antwort!

Die fehlende Schlagwortauswahl ist also der neuste Stand der Entwicklung... Ich versteh's nicht. Was soll der techn. Unterschied zw. dem Kategorie- und Schlagw.modul sein, dass in ersterer eine Checkbox integriert ist und in letzterer nicht? Rätsel über Rätsel...

Danke für den Hinweis Classic Editor, immerhin bietet der die meistgenutzten Schlw., aber anscheinend dann auch nicht alle. Selbst da muss man wohl zurück in alle Beiträge, um seltene Schlw. zuweisen zu können. Oder man heftet sich einen Zettel an den Bildschirm... :-)))

Ich werde im verlinkten Thema mal mein ungläubisches Staunen hinterlassen...

Nochmal besten Dank und schönen Tag noch!

Hallo,

beim Erstellen eines neuen Beitrages zeigt das Schlagwort-Modul die schon angelegten Schlagwörter nicht zur Auswahl an. Es gibt nur Neues Schlagwort anlegen. Schlagwörter sind jedoch schon vorhanden und können auch neu angelegt werden. Sie erscheinen aber nicht im Schlagwörter-Modul. Im Kategorien-Modul werden dagegen alle Kategorien exakt angezeigt.
Alle Plugins deaktiviert, Theme gewechselt: keine Änderung.

Ich kann allerdings nicht sagen, ob überhaupt bzw. seit wann das Schlagwörter-Modul nicht arbeitet, da ich noch keine Beitrag mit Schlagwort versehen habe. Die WP-Seite ist neu aus einem Joomla-Import.
In der Beitragsübersicht haben die Beiträge Schlagworte.
Unter Beiträge-->Schlagwörter werden alle Schlagwörter mit zughöriger Beitragsanzahl angezeigt.

Danke für einen Tipp!