Datenbankabfrage, Fehler 'max_user_connections'

  • 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]

    Einmal editiert, zuletzt von Olaf (17. Januar 2023 um 20:42)

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • o1973794 ist der Datenbanknutzer mit dem sich Wordpress in der von deinem Hoster bereitgestellten Datenbank anmeldet. Solltest Du in deiner wp-config.php finden können. Damit ist alles in Ordnung.

    Was nicht in Ordnung ist, ist die Meldung an sich. Das deutet darauf hin, dass irgendetwas dein Projekt angreift indem es sehr viele Requests dahin schickt. Das sollte im access-Log ggfs. erkennbar sein wenn man dort mal schaut, ob auffällig viele Anfragen reinkommen. Das sollte ein Hoster eigentlich erkennen können ..

  • 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!

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


    Wenn deine Seite wegen ein paar Dutzend Anfragen einknickt solltest du dir einen anderen Hoster suchen.

  • In der htaccess hab ich jetzt den Adressbereich 0.0 gesperrt


    Hmm, aber das sind ja interne IP Adressen, die du da jetzt sperrst. :eek:
    Insgesamt läuft die Seite extrem zäh. Den "internal Server Error" konnte ich auch reproduzieren.

  • 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!


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

    Das sind ipv4-Adressen und in der Form nicht gültig. Ich vermute die IPs werden in deinem Logfile anonyisiert indem die ersten 2 Oktets genullt werden. Das hilft dir beim Aussperren überhaupt nicht da Du das nur mit den echten IPs machen kannst.

    Siehst Du wohin die Requests gehen? Ans Loginformular evtl.? Dann wäre das ein Brutefore-Angriff den man mit einem Sicherheitsplugin abwehren könnte. Falls es Aufrufe von normalen Seiten deines Webs sind, ist es eher ein Crawler der die Seiten absucht. Evtl. könnte man den über seinen UserAgent aussperren (kenne sowas von ahrefs ..).

  • 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!

  • Ich würde vorab erst einmal prüfen, ob deine Website nicht evtl. kompromittiert ist und ggf. gerade so lahmt, weil sie als Mailwareversender fungiert? Will nicht die Pferde scheu machen, aber ich halte es für wahrscheinlicher, dass das System von innen her lahmt und nicht durch äußere Einflüsse. Vielleicht mal ein schneller Test mit wpsec oder hackertarget oder gleich per Plugin wordfence oder so.

  • Ich sehe es als Ergänzung an und frage meinerseits:

    Ich habe mit "wpsec" gescannt und die Antwort erhalten: Your WordPress website is vulnerable to attack!
    Würde wordfence für mich hilfreich sein?

  • Schau dir unterhalb dieser Meldung mal die Auflistung an was als kritisch angesehen wurde. Man muss das nicht abonnieren dazu. Oft sind es fehlende Updates von Plugins oder Themes die dieses Ergebnis von einem Scan schön lösen würden. Ich nutze bisher in den allermeisten Installation iThemeSecurity als Sicherheitsplugin und hatte damit noch nie Probleme.

  • ...SSRF...

    Grundsätzlich gilt für alle diese Scan Tools wie Sicherheit, Cookie/DSGVO-Check, SEO-Check: Sie können einen auch unnötig verrückt machen. Das gilt insbesondere, wenn man die Ergebnisprotokolle nicht bewerten kann. :rolleyes:

  • An den Threadstarter: das ist der mit Abstand interessanteste und lehrreichste Blog, den ich je gelesen habe. Das wird mich noch Nächte kosten ;)


  • Wir entfernen uns hier immer weiter vom eigentlichen Thema ..

    Grundsätzlich nicht. Mein Einwurf beruhte auf #8: "hier muss ein Sicherheitsplugin her." Wobei ich jetzt iThemeSecurity als Plugin nicht finden kann.

  • Dann nimm DAS hier stattdessen. :cool:

    Jo, das kam nur nicht, als ich auf der Site unter "Plugin installieren" danach gesucht habe. Danke, werds ausprobieren bzw. habs eben installiert und konfiguriert, muss da sicher nacharbeiten.

    Würde das den Threadstarter von Problemen befreien?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!