phpBB.de

Verfasst: **17.05.2024 15:10**

Hallo zusammen!

Da ich seit einigen Tagen so zwischen 90 und 150 Anfragen vor allem an die app.php bzw. auch teilweise viewtopic etc. verzeichne und die IPs von der Google Cloud kommen und sich nicht als Bot kennzeichnen, versuche ich, diese möglichst fern zu halten.

Dabei habe ich bemerkt, dass die phpbb_sessions einige hunterttausend Einträge hat und schnell wächst (entsprechend der Aufrufe).
Es werden dort auch pro IP mehrere Einträge gespeichert, zum Teil mehrere Tausend (bei den Cloud-Aufrufen)
In der phpbb_sessions_keys sind ebenfalls pro User (nicht aber Gäste!) mehrere IPs gespeichert, viele davon aber deutlich länger als die eingestellte Session-Dauer.

Meine Fragen:
- ist das Verhalten in der phpbb_sessions so gewollt?
- ist es ebenfalls gewollt, dass für User die benutzten IPs länger als die Sessiondauer aufgehoben werden? (habe da trotz Sessionzeit von 1800 als last_login zB. 1392011556 drin)
- kann ich zB. mit $user->session_kill(); eine lösche der aktuelle Session erzwingen, sofern es sich um einen Gast handelt der nicht Bot ist?

Kann ich zB. in der app.php das hier nach dem Session-Beginn einbauen

Code: Alles auswählen

if ($user->data['user_id'] == ANONYMOUS)
{
	if ($user->data['is_bot'] == false)
	{
		#header('Location: [your phpbb location]/ucp.php?mode=login');
		$user->session_kill();
		exit;
	}
}

damit alle Gäste, jedoch nicht Bots die app.php nicht fertig aufrufen können?
(zählen Bots zu den Gästen?)

Vielen Dank!

Verfasst: **17.05.2024 15:36**

Hi,

unbekannte Bots zählen zu Gästen, ja.

Die bekannten Bots sind im ACP hinterlegt.

Da auch ich mal vor längerer Zeit mit unzähligen Spidern, Crawlern und AI Bots überrannt wurde, habe ich mir "CIDRAM" implementiert:

https://github.com/CIDRAM/Docs/blob/master/readme.de.md

Den Beispiel Code : (Pfad muss natürlich angepasst werden)

Code: Alles auswählen

require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\Core())->protect();

habe ich einfach in der "common.php" eingeschleust. (Man muss natürlich bei jedem phpBB Update diesen Beispiel Code erneut einpflegen.

Dadurch kommen die Bots usw. erst garnicht zum Main Core von phpBB und können daher auch keine Session in der DB anlegen.

Du kannst ja mal den User Agent in Deinem Browser faken, nur "Bot" eintragen und mein im Profil hinterlegtes Forum aufrufen

Verfasst: **17.05.2024 16:23**

Danke für die rasche Antwort!

Leider haben keine Kennzeichnung als "bot"
nur das hier:

Code: Alles auswählen

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36

Darum möchte ich von der app.php auch alle Gäste aussperren, welche Gäste sind, aber eben keine offiziellen "bot"s.

Wenn das ohne Erreichen des Main Cores klappt, wäre das noch besser, dann füllt es mir die sessions-Tabelle nicht so an (seit meinem letzten Posting sind über 250.000 Einträge dazugekommen.

*edit*
es sind halt keine Google Bots, sondern die IP's gehören zur Google Cloud (lt. ip-location)

Verfasst: **17.05.2024 16:57**

Erhöhte Tätigkeit von Bots tritt nicht nur bei dir auf, sondern vermehrt über alle Foren hinweg. Siehe beispielsweise auch hier:

https://www.phpbb.com/community/viewtop ... #p16008259

https://www.phpbb.com/community/viewtopic.php?t=2652265

https://www.phpbb.com/community/viewtopic.php?t=2550501

- und andere

Verfasst: **17.05.2024 17:13**

Danke!
Dann werde ich mich da mal einlesen...

"Gut", wenn es nicht nur uns so geht

Verfasst: **17.05.2024 22:19**

Leider beziehen sich diese Artikel alle auf bestimmte Bots (claudebot, bytespider, etc) - die Aufrufe bei mir habe keine bot-Kennung (s.o.), daher fällt eine robots.txt flach genauso wie eine .htaccess-Sperre anhand der Botkennung.

wenn ich das in der app.php nach dem Session-Start einfüge

Code: Alles auswählen

if ($user->data['user_id'] == ANONYMOUS)
{
	if ($user->data['is_bot'] == false)
	{
		#header('Location: [your phpbb location]/ucp.php?mode=login');
		$user->session_kill();
		exit;
	}
}

klappt es auch nicht, da die Sessiontabelle trotzdem zugemüllt wird und dann das zählen der Sessions für die Sessionbeschränkung lange dauert, weil er ja ein paar Hunderttausend sessions zählen muss (x-mal in der Sekunde)
ok, man kann die Sessions beschränken im ACP, aber dann werden wohl oft auch echte User mit einem 503er beglückt, da dieser "Bot" bereits die möglichen Session für sich beansprucht hat.

Der obige Code sollte doch klappen, oder? ich möchte alle Gäste (ausgenommen Bots) exit-en lassen, wenn die app.php aufgerufen wird

Verfasst: **18.05.2024 20:43**

Hallo Gumfuzi

Ich selber kenne das Problem so nicht, daher kann ich hier nur wenig sinnvolles beitragen. Aber was mir dazu einfällt:

Da auch bei mir durchaus Situationen eintreten, wo innerhalb kürzester Zeit mehrere tausend Bot Zugriffe auftreten, habe ich eben mal in meine Sessions Tabelle geschaut: gerade mal 141 Einträge, der älteste Eintrag - der nicht von einem meiner eigenen Accounts stammt - ist von heute 15:05:54. Der liegt ebenfalls ausserhalb meiner eingestellten Sessiondauer.

Allerdings weiss ich durch die Entwicklung von Force Account Reactivation, dass eine Bereinigung periodisch durch das Cron System von phpBB durchgeführt wird. Und diese Jobs werden ja nicht jede Sekunde ausgeführt, sondern in teilweise grösseren Abständen. Da kannst du also nicht nach dem Timestamp alleine gehen. Wenn du aber viele sehr alte Einträge da hast, die nicht bereinigt werden, könnte es vielleicht wirklich am Cron System liegen.

session_kill() wäre da also ein bisschen "basteln am Symptom". Wenn phpBB das nicht alleine bereinigt, dann müsste man eher mal nach der Ursache forschen. Und damit eine Antwort auf deine Frage: nein, das Verhalten bei dir ist so nicht gewollt.

Die zusätzliche Abfrage auf Bot bräuchte es übrigens nicht, denn wenn phpBB den Besucher bereits als Gast identifiziert hat, also die User ID bereits ermittelt wurde, kommt ein Bot gar nicht mehr in Frage. Ein Besucher ist entweder ein Gast oder ein Bot, er kann nicht beides sein. Das heisst deine sekundäre Bedingung ($user->data['is_bot'] == false) ergibt in deinem Code immer true und ist somit unnötig.

Verfasst: **19.05.2024 13:58**

Hi, schafft dieses Vorgehen ggf. Abhilfe? Dank dem Co-Admin von meiner Seite!

ACP / Allgemein

Sitzungsdaten löschen
Alle Sitzungsdaten löschen. Dies wird alle Benutzer abmelden, indem die Sitzungstabelle geleert wird.

=> Jetzt ausführen

Vor Monaten hatte ich 2099 Seiten im ACP sowie unendliche Logs.

Und das Einbinden jener Vorgehensweise schaffte erst einmal Ruhe.

BTW:
Dem Bot selbst ist die Groß-/Kleinschreibung möglicherweise egal, aber das robots.txt-Protokoll unterscheidet zwischen Groß- und Kleinschreibung. Ebenso unterscheidet Linux Apache .htaccess die Groß-/Kleinschreibung nicht - und Windows m.W. auch nicht (?).
Das war mir jetzt egal und habe Groß-/Kleinschreibung beide Male verwendet.

Interessante Thematik, bin schon jetzt gespannt auf einen Lösungsansatz für Gumfuzi.

LG und erfolgreiches Gelingen für euer Vorhaben.

Edit:
Klar ist, dass sein Einzelfall entscheidend ist (Server / Strukturen etc.). Jedenfalls hatte ich mich heute wiederkehrend durch´s IT gewühlt und Meinungen stehen sich oft konträr gegenüber im Sinne von Nutzen und Lasten usw. usf.
Viel Glück und Erfolg.

Verfasst: **20.05.2024 10:44**

Danke für die Antwort!

Zuerst vorneweg ein mini-Auszug:

Code: Alles auswählen

INSERT INTO `phpbb_sessions` (`session_id`, `session_user_id`, `session_last_visit`, `session_start`, `session_time`, `session_ip`, `session_browser`, `session_forwarded_for`, `session_page`, `session_viewonline`, `session_autologin`, `session_admin`, `session_forum_id`, `session_album_id`) VALUES
('03546f73f24105491861c0127602c22d', 1, 1716022523, 1716022523, 1716022523, '34.141.253.177', 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36', '', 'app.php/feed/forums', 1, 0, 0, 0, 0),
('03546f73f24105491861c0127602c22d', 1, 1716022696, 1716022696, 1716022696, '34.141.253.177', 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36', '', 'app.php/feed/forums', 1, 0, 0, 0, 0);

warum in der Session-Tabelle mehrere Einträge mit den gleichen Daten (bis auf die Zeitpunkte) stehen, erschließt sich mir nicht, aber gut. Evtl. beziehen sich dieses auf verschiedene IPs, aber warum dann 2x die gleiche sid?

------------

Ich habe es nun erstmal so gelöst:
den Bereich in der app.php habe ich nun so gestaltet:

Code: Alles auswählen

// Start session management
$user->session_begin();

// bei allen Gästen (ggf. ausgenommen Bots) abbrechen und Session löschen!
if ($user->data['user_id'] == ANONYMOUS)
{
	if ($user->data['is_bot'] == false)
	{
		$sql = 'DELETE
			FROM ' . SESSIONS_TABLE . '
			WHERE session_id = \'' . $db->sql_escape($user->data['session_id']) . '\'
				AND session_user_id = ' . ANONYMOUS;

		$result = $db->sql_query($sql);

		header('Location: https://www.leider-nur-fuer-registrierte-user.de');
		exit;
	}
}

$auth->acl($user->data);
$user->setup('app');

Wichtig war mir der Code noch vor dem setup bzw. dem Rest, um weitere CPU-Last zu vermeiden.
Hat aber auch die Auswirkung, dass man nur mehr als reg. User den Feed, das Melden von Beiträge und das Bedanken (Modifikation) möglich ist - aber das ist ok bei uns.

Zusätzlich habe ich ein Skript gebastelt, welches per Conjob stündlich die Session-Tabelle von den ca. 10k - 15k Einträgen befreit, welche diese IP-Adressen in den anderen Bereichen produzieren (viewtopic, memberlist, etc.), aber das sind bei weitem nicht so viele Aufrufe wie bei der app.php, wo es wie erwähnt zw. 90 - 150 Aufrufe pro Sekunde(!) sind.
der SQL-Befel dazu:

Code: Alles auswählen

DELETE FROM phpbb_sessions WHERE session_user_id = 1

(Tabellennamen anpassen, falls es jemand verwendet

)

Damit ist nun die CPU-Last wieder auf dem Normbereich.

Anmerken möchte ich aber noch, dass mein Problem nicht mit den KI-Bots oder anderen Bots zu tun hat, welche eine Kennung mitliefern, weshalb die verlinkten Einträge in der Robots bzw. .htaccess wohl hier ins Leere laufen mangels Kennzeichnung.
Da aber heutzutage vermutlich viele sich eine KI zusammenbasteln und auf das Internet loslassen können und die Angabe einer Bot-Kennung IMO freiwillig ist, darf man gespannt sein, wie sich das für Webseitenbetreiber weiter entwickelt.

Nichtdestotrotz werde ich vermutlich die von dir verlinkten KI-Stopp-Maßnahmen noch einbauen - danke auch dafür!

Verfasst: **20.05.2024 15:28**

Hi Gumfuzi, danke für dein Feedback und deinen (vorläufigen) Lösungsansatz.

Dazu können dir Luke und/oder weitere Spezialisten sicherlich mehr sagen. Sie stecken in jener Thematik eher drinnen.

Prima,

Damit ist nun die CPU-Last wieder auf dem Normbereich.

Was ich noch nebenbei gefunden habe:
[CDB] Cron Status => Diese kommt jedoch aus "grauer Vorzeit" ..., dennoch spannender Lesestoff (Entwicklungsphase).

https://www.phpbb.com/community/viewtop ... ron+Status

Jedoch hat sich gemäß Supportbereich zu jener EXT jemand erbarmt einen FORK für phpBB-3.3.10 zu schreiben:
https://www.phpbb.com/customise/db/exte ... 69#p867169

Tja, ob sich zwischenzeitlich phpBB andersartig verhält? Das ist wohl die Frage aller Fragen bzw. das Rätsel des Tages, ob dieser FORK noch brauchbar ist. Im erneuerten phpBB-Wiki gibt´s leider auch nichts. Jedenfalls habe ich nichts finden können.

Da aber heutzutage vermutlich viele sich eine KI zusammenbasteln und auf das Internet loslassen können und die Angabe einer Bot-Kennung IMO freiwillig ist, darf man gespannt sein, wie sich das für Webseitenbetreiber weiter entwickelt.

KI: Bin jetzt schon gespannt, was dabei herauskommt, wenn Kürzel, wie im IT-Bereich oftmals üblich, verwendet werden ....

LG und viel Glück

phpBB.de

[3.2] Sessions-Tabellen

[3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen

Re: [3.2] Sessions-Tabellen