[Eisfair] [E64] exim: "systemd: Failed to resolve symlink /usr/local/share/systemd/user, ignoring: Permission denied"

[Rolf Bensch]

Hallo Kay,

Am 03.11.24 um 17:51 schrieb Kay Martinen:
> Am 01.11.24 um 08:40 schrieb Rolf Bensch:
> 
>> mehr durch Zufall entdecke ich folgendes in /var/log/messages:
>>
>> Oct 27 05:44:46 eis64-3 kernel: ATTACKER..IN=enx525400b7e655 OUT= MAC=52:54:00:b7:e6:55:0c:72:74:fe:2a:23:08:00 SRC=80.64.30.52 DST=192.168.0.207 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=18877 DF PROTO=TCP SPT=62506 DPT=25 WINDOW=32120 RES=0x00 SYN URGP=
>> 0
> 
> 80.64.30.52:62506 spricht TCP mit 192.168.0.207:25 was offensichtlich ein Versuch ist deinen Mailserver zu erreichen. Mehr kann ich da erst mal nicht raus lesen, auch nicht ob das ein Angreifer wäre, ein portscan oder sonst was.

Korrekt. Ist nur leider nicht Ursache für das Problem.


> Was mir nur "leider" unerfreulich auffällt ist, das...
> 
>> Oct 27 05:45:55 eis64-3 su[4714]: (to exim) root on none
>> Oct 27 05:45:55 eis64-3 (systemd): pam_unix(systemd-user:session): session opened for user exim(uid=488) by (uid=0)
> 
> ... sich in den folgenden dutzenden Zeilen systemd scheinbar mehr mit sich selbst beschäftigt oder kundtut welche heldentaten (stopped, started, closed user, slice, session target, blah-blah) er da vollbringt.
> 
> Das mag an mir liegen das ich mich einfach nicht damit anfreunden kann das; und warum oder wozu; es ein main user target gibt u.s.w. aber mein Eindruck ist der einer geringeren Informativen Dichte zugunsten eigentlich nutzloser geschwätzigkeit - des init.
> 
> So weit ich dunkel an früher logs erinnere war dort mehr abwechslung drin und es lief serieller. Will sagen; man konnte es besser von oben nach unten lesen und dem grund leichter auf die spur kommen. Einfach weil der grund sich oft schon zeilen vorher mit einem eintrag ankündigte und die Folgen in weiteren logzeilen festgehalten wurden.
> 
> Das war's schon mit der allgemeinen Kritik. Nur noch die Frage: Hast du evtl. den loglevel irgendwo hoch gedreht?

Hmmm, gute Frage. Wissentlich nicht. Habe mal in /etc/config.d nach "debug" und "loglevel" gesucht. Hier gab es 2 Fundstellen in der BFB-Config:

/etc/config.d/brute_force_blocking:BFB_LOGLEVEL='debug'
/etc/config.d/brute_force_blocking:BFB_MESSAGE_LOGLEVEL='debug

Das sind jeweils die default-Einstellungen. Habe testweise diese Einträge nach "info" geändert, die Meldungen von systemd bleiben.

>> "Monitoring" meldet um 05:45 "Es steht kein Alarm (mehr) an!". Wird hier irgendwas blockiert und wieder freigegeben? Die Meldung aus dem Kernel wird vermutlich von BFB getriggert. Was läuft hier aus dem Ruder?
> 
> Ich erkenne neben der "Attacker" meldung des Kernels (BFB?) nur noch die permission denied meldungen als wichtigeres Problem dem du mal auf die Spur kommen müßtest.

Das war der Aufhänger meiner Frage.

> Sprich: welchen user und rechte hat der aufrufende Prozess und welche user und Rechte bestehen auf dem Weg zum inkriminierten Pfad?
> 
> Und, kannst du mit 'su' zu dem user wechseln und dann an dem ort die gegebene datei/ordner öffnen?

Und wie ermittele ich um welchen User und Prozess es sich handelt? Der user exim hat keine Shell (könnte ich ihm manuell geben)

Grüße

Rolf