fail2ban - keyhelp-phpmyadmin [GELÖST]

[Ralph]

KH: v24 (upgrade von 23.2.1)
Debian12

Funktioniert bei euch der fail2ban filter für PMA -> keyhelp-phpmyadmin.conf?
Im jounal scheint der log mit der filter regex übereinzustimmen:

Code: Select all

phpMyAdmin[282243]: user denied: mysqladmin (mysql-denied) from xxx.xxx.xxx.xxx

Bei PMA Fehl Logins zeigt das journal diese genau so an, allerings reagiert F2B nicht mehr darauf, keine fail logs oder bans ...

Code: Select all

grep "keyhelp-phpmyadmin" /var/log/fail2ban.log

Könnte es etwas mit der UID/GUID keyhelp:keyhelp zu tun haben?

[Ralph]

yup, daran hat es gelegen, der Filter keyhelp-phpmyadmin.conf wird beim Upgrade auf KH 24 auf owner/group keyhelp:keyhelp gesetzt ...
ein

Code: Select all

chown root:root /etc/fail2ban/filter.d/keyhelp-phpmyadmin.conf && systemctl restart fail2ban

behebt das Problem

Code: Select all

2024-02-13 18:14:03,066 fail2ban.filter         [2257]: INFO    [kh-phpmyadmin] Ignore xxx.xxx.xxx.xxx by ip

meine IP ist in der ignoreip list, die Bans funktionieren allerdings jetzt auch wieder

[Alexander]

der Filter keyhelp-phpmyadmin.conf wird beim Upgrade auf KH 24 auf owner/group keyhelp:keyhelp gesetzt

Nur zur Info: Seitens KeyHelp wurde der Eigentümer diese Datei noch nie geändert - auch nicht im Update. Sie wird immer mit dem Besitzer, der das Update ausführt angelegt und der ist 'root'.

Die einzige Datei, die im Fail2Ban Ordner KeyHelp gehören soll wäre die Jail hier: /etc/fail2ban/jail.d/keyhelp.conf

[Ralph]

der Filter keyhelp-phpmyadmin.conf wird beim Upgrade auf KH 24 auf owner/group keyhelp:keyhelp gesetzt

Nur zur Info: Seitens KeyHelp wurde der Eigentümer diese Datei noch nie geändert - auch nicht im Update. Sie wird immer mit dem Besitzer, der das Update ausführt angelegt und der ist 'root'.
Die einzige Datei, die im Fail2Ban Ordner KeyHelp gehören soll wäre die Jail hier: /etc/fail2ban/jail.d/keyhelp.conf

Ja, ich war auch etwas verwundert, der Eigentümer des Filters wurde von meiner Seite aus nicht geändert und hatte unter 23.2.1 (root:root) immer funktioniert. Oder setzt F2B möglicherweise die UID/GUID auf die Filter nach den Eigentümern der confs unter /jail.d?

Sie wird immer mit dem Besitzer, der das Update ausführt angelegt und der ist 'root'.

Also das KH Update habe ich manuel im Panel angestossen (panel update cronjob ausführen) und das läuft unter dem User keyhelp ....

[Alexander]

Oder setzt F2B möglicherweise die UID/GUID auf die Filter nach den Eigentümern der confs unter /jail.d?

Ich denke nicht, zumindest habe ich dieses Verhalten noch nie beobachtet. Wäre auch irgendwie komisch.
Ich schließe nicht aus, das es irgendwann vielleicht doch mal ein Bug gegeben haben könnte, der das verursacht hatte. Aber aus sämtlichen alten sowie neuen Systemen auf denen ich jetzt geschaut habe, gehört die Datei root. Ich finde auch nichts im Code, dass ich irgendwann den Eigentümer der Datei mal auf 'keyhelp' gesetzt hätte.

Also das KH Update habe ich manuel im Panel angestossen (panel update cronjob ausführen) und das läuft unter dem User keyhelp ....

Nee . Zum Hintergrund: Jede Minute läuft auf dem System der Aufgaben-Verteilungscronjob - der schaut ob Dinge zu erledigen gibt. Dieser Cronjob läuft unter "root", denn es müssen ja stellenweise auch Aufgaben umgesetzt werden, für die man zwingend root-Rechte braucht.

Du initiierst die Aufgabe zwar im KeyHelp-Kontext (Über die Benutzeroberfläche) aber die Ausführung übernimmt immer 'root'.

Mein Satz "Sie wird immer mit dem Besitzer, der das Update ausführt angelegt und der ist 'root'." war vielleicht auch etwas irreführend, denn es ist eigentlich auch nicht möglich, das das Update in einem anderen Benutzerkontext laufen kann, als 'root'.

[Ralph]

hm, ich habe sonst immer keyhelp-toolbox verwendet ... das ausführen aus dem Panel habe ich zum esrten Mal angewendet.

Fallen Dir auf Anhieb noch weitere Dateien ein wo ich die Eigentümer in dem Fall überprüfen sollte?
L.G.

[Ralph]

Die Panel *.php cronjobs gehören alle keyhelp, ich kann halt nicht reinschauen weil ioncubed aber wenn Du sagst dass der Update Task unter root ausgeführt wird, dann habe ich keinen Grund daran zu zweifeln
Ist zwar seltsam und ich kann mir nicht erklären warum der Filter keyhelp als Eigentümer bekommen hat, aber kein großes Problem in dem Fall.
Danke für die Rückmeldung und Prüfung!