[3.2] Server ruft tausendfach file.php auf

[Wuppi]

Hallo in die Runde,

wir hatten gerade ein größeres Problem mit MetaAI - das haben wir gelöst und jetzt flooded uns der Server selber.

Es bauen sich gerade in der Session-DB immer mehr Sessions mit der IP vom Server auf. Im Serverlog sieht man: er ruft die /download/file.php?...." auf ... die Attachments. Wir wissen aber nicht warum.

Ich hab vorher die max. Attachmentgröße reduziert - aber das betrifft ja nur den Upload. Zudem hab ich über die Admin-Funktion Verwaiste Attachments gelöscht - das aber schon über eine Stunde her. Ca. 2500 müssten das gewesen sein.

Jemand eine Idee was das sein könnte? Wie stoppen wir das? Mittlerweile 1500 Sessions - Wenn der jetzt jede Datei runter lädt - das sind 15Gbyte! ..... das wird dauern... Normal ist doch nicht?

Danke schon mal für hilfreiche Tipps!

EDIT:
Es werden massenhaft Dateien in cache/production erstellt
Inhalt ein SQL-Aufruf: SELECT attach_id FROM phpbb_attachments WHERE post_msg_id = 55979 AND extension IN ('jpg', 'jpeg', 'png', 'gif') AND is_orphan = 0 ORDER BY attach_id ASC LIMIT 3
msg_id ist natürlich wechselnd ....

[LukeWCS]

Hallo

Klingt erstmal sehr seltsam für mich. Mal bitte die Eckdaten angeben:

phpBB Version
PHP Version

1. Dann, was genau ist "MetaAI" und inwiefern hat das was mit eurem phpBB zu tun?
2. Wenn ich ältere Beiträge von dir sichte, sieht es so aus, das du mit Custom Code hantierst. Hast du den phpBB Core in irgendeiner Form modifiziert?
3. Welche Exts sind im Einsatz?
4. Wenn der Server selber phpBB Komponenten aufruft, ist da vielleicht irgendwas mit Cron Jobs eingerichtet worden?

[Wuppi]

Version phpBB 3.2.7 (update auf 11 und dann 3.3.x ist für die nächsten Tage geplant; ist bei der Größe und dem Server aber nicht so einfach)
PHP 7.2.24 (ebenfalls geplant)

zu 1) Meta AI -> Der Trainingsbot für AI von Meta / Facebook. Der hatte >4000 Sessions bei uns auf gehabt. In folge dessen haben wir anschließend, als wir das Problem gelöst hatten (den UA gesperrt via htaccess) super Performance und dann kam der Server an und hat innerhalb kurzer Zeit über 1500 Sessions angelegt - die Performance ging wieder runter. Gerade ist die Performance relativ gut.

zu 2) nur ein eigenen Style der saubere SEO-Headers reinsetzt. Am Core hab ich nichts geändert.

zu 3) Die Extension wurden in den letzten Monaten nicht neu angepackt - nichts neues dazu etc. Da ist aber keine Ext dabei die mit Attachments was zu tun hat (und hier wird ja die Attachment-Anzeige-Datei aufgerufen + irgendwelche DB-Abfragen auf Attachments): Prime Links, Privacy Protection, SEO Metadata, Themenvorschau, Stop Forum Spam, Präzise Vergleichbare Themen, Thanks. Das sind die Ext. Der Server ruft halt direkt file.php auf und scheinbar geht er alle Attachments durch (bei 190.000 dauert das etwas....)

zu 4) "cronjob": Das ist die Frage - also wir nicht! Was ich kurz gedacht hatte: ich hatte über 2500 verwaiste Dateien via ACP gelöscht. Aber das macht alles kein Sinn. Warum soll das System die verwaisten Dateien alle aufrufen. Wenn die Dateien aus der DB gelöscht werden sollen bzw. vom Filesystem und das aus performancegründen vielleicht nicht an einem Stück gemacht werden soll, würde doch eine Mechanik laufen die das ganze auf auf andere weise lösen. Was macht das Script den wenn ein Attachment eine Berechtigung war. Die Session liefen als ID 1 - also anonymous. Und warum zu löschen die file.php aufrufen - nein der Gedanke macht keinen Sinn.


PS: aktuell hat die session-db 24233 Sessions nur für die ServerIP (das ist fast ein 1/3 aller Sessions) - alle auf file.php?... Ist bei den 6stelligen IDs aber hier auch viele mehrfach. Wenn ich die jetzt lösche, baut sich das wieder langsam auf. [nach 5min Korrekturlesen: 24694)

PPS: was passiert wenn ich die Server-IP blocke (htaccess)? Da das Forum sich ja eigentlich nicht selber aufruft, sollte ja nichts passieren? Oder gibt es Funktionen die mit Server-IP im Forum "aktiv" sind?

PPPS: das mit der file.php von der ServerIP muss "neu" sein. Ich marschiere gerade auf die 100.000 Sessions (also alle!) zu. Gerade kommt pro Sekunde kommt eine Server-Session dazu. Gestern hatten wir diese MetaAI-K**** gesehen und da waren wir bei 65.000 Sessions - Relativ konstant. Dann haben wir u.a. alle ID 1-Sessions gelöscht und dann gings los. Komischer Zusammenhang.

[LukeWCS]

Danke für die Angaben. Wenn man so "dubiose" Fälle untersuchen muss, ist jedes Detail nützlich.

1. Ach diese Richtung. Okay, also ein simples AI Bot Problem. Kann ich nachvollziehen, ich habe sämtliche AI Bots hart gesperrt, weil deren Verhalten hatte nichts mit normalem crawlen zu tun, sondern eher mit gezielter Störung und konnte schon fast als "Angriff" gewertet werden.

3.

Da ist aber keine Ext dabei die mit Attachments was zu tun hat

Genau das war mein Gedanke. Dann fällt das auch weg.

4. Bei deinen Gedankengängen kann ich mitgehen.

Okay, an der Stelle wäre jetzt mein erster Impuls den Hoster Support anzuschreiben, ob die feststellen können, was genau da passiert. Und ja, eine Bereinigung der verwaisten Anhänge über das Web Interface von phpBB zu realisieren, wäre wohl hochgradig ineffizient und lahm ohne Ende. Ich kann jetzt nicht aus dem Stand sagen, wie genau das vonstatten geht, aber sicher nicht über URL-Aufrufe.

phpBB selber hat ein Cron System. Aber soweit ich weiss, ist das kein - in dem Sinne - separates System, sondern wird im Zuge normaler Seitenaufrufe ausgeführt. Aber da muss jemand was dazu sagen, der wirklich weiss was da passiert. Ich hatte noch zuwenig (eher keine) Probleme damit, um mich näher damit zu befassen.

[Dr.Death]

Für einen Schutz dieser Art benutze ich seit längeren CIDRAM. -->
https://github.com/CIDRAM/CIDRAM
https://github.com/CIDRAM/Docs/blob/master/readme.de.md

Einbinden in phpBB geht auch relativ einfach in der common.php

nach einer Installation des CIDRAM einfach in der common.php

SUCHEN

Code: Alles auswählen

if (!defined('IN_PHPBB'))
{
	exit;
}

DANACH EINSETZEN

Code: Alles auswählen

require_once($phpbb_root_path . 'cidram_v3/vault/loader.' . $phpEx);
(new \CIDRAM\CIDRAM\Core())->protect();

Wie Ihr sehen könnt, habe ich für meinen persönlichen Geschmack die CIDRAM Installation in ein Verzeichnis "cidram_v3" unterhalb des phpbb Forums root gepackt.

Das ganze noch per admin gut etwas tunen und schon werden alle bösen bots, spider, ai usw. hard geblockt, noch bevor eine DB Session eröffnet wird