1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Datenbankabfrage, Fehler 'max_user_connections'

Dieses Thema im Forum "Allgemeines" wurde erstellt von rainerb, 15. Januar 2023.

Schlagworte:
  1. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    10.539
    Zustimmungen:
    1.487
    Wenn man sich eingehend mit der entspr. Plugin Dokumentation beschäftigt, möglicherweise ja, allerdings lt. Dokumentation nur mit der Pro Version des Plugins.
     
    Kurt Singer gefällt das.
  2. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    6.367
    Zustimmungen:
    413
    Ursache für die vielen WordPress Anmeldungen könnten DDoS und Brute-Force Angriffe sein. Diese können bei WordPress zum Beispiel durch Pingback und XML-RPC Pingback sieht so aus https://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html und ein Angriff über XML-RPC https://blog.sucuri.net/2014/07/new-brute-force-attacks-exploiting-xmlrpc-in-wordpress.html

    Gegen Brute-Force-Angriffen hilft eine eine Zwei-Faktor-Authentifizierung.

    Die Log Files vom WebServer solltest du auswerten.
    Und du kannst für deinen Kunden gleich einen neuen Hoster suchen,
    Fehler 'max_user_connections' ist ein Provider Problem.



     
  3. Kurt Singer

    Kurt Singer WPDE-Team
    Mitarbeiter

    Registriert seit:
    28. Mai 2017
    Beiträge:
    1.665
    Zustimmungen:
    257
    Also ist die Free-Version für Nutzer wie mich auch nicht brauchbar? Ich nutze immer noch das von Dir abgelehnte WP Cerber, möchte es aber adäquat ersetzen.
     
  4. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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...
     
  5. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.082
    Zustimmungen:
    259
    Und das die Seite nicht gehackt ist hast du also geprüft uns sichergestellt?
     
  6. arnego2

    arnego2 Well-Known Member

    Registriert seit:
    10. Januar 2021
    Beiträge:
    521
    Zustimmungen:
    58
    DDoS Angriffe zu Dutzenden Aufrufen ohne mal in die Millionen die nächste Woche ankommen sind sehr unwahrscheinlich.

    Wenn Logs dann Accesslogs und da noch GET suchen. Diese GET anfragen hat so gut wie jede Seite die im Netz gefunden wird. Bei mir habe ich ca 25 pro Monat die nach wp-admin suchen und das obwohl ich keine WP Seite hab.
     
  7. Kurt Singer

    Kurt Singer WPDE-Team
    Mitarbeiter

    Registriert seit:
    28. Mai 2017
    Beiträge:
    1.665
    Zustimmungen:
    257
    Uups...das habe ich gelegentlich noch laufen. Wird also höchste Zeit, etwas anderes zu installieren. Aber was? (Super gut und free o_O )
     
  8. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.082
    Zustimmungen:
    259
    Warum nur sind alle immer der Meinung, Software sei im Web ein Allgemeingut und müsse von den Entwicklern kostenlos zur Verfügung gestellt werden?:rolleyes:
     
  9. Kurt Singer

    Kurt Singer WPDE-Team
    Mitarbeiter

    Registriert seit:
    28. Mai 2017
    Beiträge:
    1.665
    Zustimmungen:
    257
    Der Meinung bin ich überhaupt nicht. Aber für mein Hobby möchte ich nicht übermäßig viel Geld ausgeben. Es gibt nun mal kostenlose und gute Software und ich wäre schlecht beraten, diese nicht nutzen zu wollen. Aber bei der Anzahl dieser Software darf man doch gerne auf Empfehlungen zurück greifen.

    Warum eigentlich nutzen so viele das kostenlose WordPress?
     
  10. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.082
    Zustimmungen:
    259
    Ja, darfst du – zumal deine Website nicht kommerziell ist. Mir fiel es nur in letzter Zeit verstärkt auf, dass hier immer alle alles umsonst haben wollen. Und es ist mir auch schleierhaft, warum so viele Softwareentwickler ihre Software verschenken und diesen "Anspruch" damit noch verstärken.
     
  11. Kurt Singer

    Kurt Singer WPDE-Team
    Mitarbeiter

    Registriert seit:
    28. Mai 2017
    Beiträge:
    1.665
    Zustimmungen:
    257
    Ja, das fällt mir auch auf. Aber viele Programme, die frei sind, machen Lust auf mehr, und dann wird eben noch eine "Plus"-Version angeboten. Das ist z.B. bei einer Menge von Plugins so, wer die volle Leistung haben möchte muss dann auf diese manchmal recht teure Software zurück greifen. Ein legitimes Mittel, seine Softwareentwicklung dann doch an den Mann/die Frau zu bringen. Für meine Bildbearbeitung kaufe ich regelmäßig Upgrades, denn da will ich auch nur das bestmögliche bieten, Fotos sollen ja schön anzuschauen sein. Also ganz kostenlos und frei sind auch meine Hobbyseiten nicht, aber das ist es mir dann auch wert. Ich habe in der Vergangenheit auch Fremdseiten entworfen, da habe ich dann auch entsprechend der Ansprüche des Betreibers kostenpflichtige Software genutzt.

    Uups-jetzt haben wir uns aber vom Thema entfernt und ich habe immer noch keine Empfehlung für Sicherheitssoftware.
     
  12. meisterleise

    meisterleise Well-Known Member

    Registriert seit:
    18. Januar 2012
    Beiträge:
    1.082
    Zustimmungen:
    259
    Äh doch, @threadi hatte dir schon iThemes Sec. genannt, weiter oben Stand All in One Sec. ich kann noch Wordfence in den Raum schmeißen (ohne all zu tiefgreifende Erfahrung).
     
    Kurt Singer gefällt das.
  13. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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.
    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!
     
    #33 rainerb, 20. Januar 2023
    Zuletzt bearbeitet: 20. Januar 2023
  14. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    10.539
    Zustimmungen:
    1.487
    Bei einem Fehler 'max_user_connections' landet nichts in der WP-Slimstat Datenbank, somit kannst Du das auch nicht sinnvoll auswerten.
     
  15. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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.
     
  16. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    10.539
    Zustimmungen:
    1.487
    Es landet bei weitem nicht alles mit 200 in WP-Slimstat, z.B. XML-RPC, REST-API, ggf. auch keine Formularabsendungen oder Login-Seiten.

    Dein Website ist nach kurzem Querlesen des Threads nicht angegeben, sonst könnte man ggf. mehr aus dem Quelltext ableiten.
    Wenn eine WordPress Installation gehackt ist, dann ist alles darin als kompromitiert zu betrachten, inklusive aller installierten Plugins, Scanner usw., die von einem Hack jederzeit ausgehebelt werden können.
     
    #36 b3317133, 20. Januar 2023
    Zuletzt bearbeitet: 20. Januar 2023
    arnego2 gefällt das.
  17. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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.
    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?
     
  18. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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...
     
  19. b3317133

    b3317133 Well-Known Member

    Registriert seit:
    21. November 2014
    Beiträge:
    10.539
    Zustimmungen:
    1.487
    Zugriffszahlen mit Datenbanknotwendigkeit und damit -last können sehr unterschiedlich sein, wenn ein Cache Plugin, z.B. hier lt. REST-API Route offenbar WP Super Cache verwendet wird. Wenn ein neuer Beitrag kommt, wird ggf. erstmal alles neu in den Page Cache abgelegt und das erzeugt dann temporär hohe Datenbanklast bis wieder der Page Cache "an WordPress vorbei" ausgeliefert wird.

    Weiterhin läuft lt. REST-API Route offenbar auch ein Plugin Post Views Counter, auch sowas kann Datenbanklast verursachen, je nachdem wie es eingebunden wird (falls es überhaupt aktiv zählt, wenn ein Page Cache läuft).
     
  20. rainerb

    rainerb Member

    Registriert seit:
    14. Januar 2020
    Beiträge:
    12
    Zustimmungen:
    0
    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:

    class_admin_controller.php
    public function register_post_type() {

    $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...


    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!!
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden