• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] audit Spam im journal

gehrke

Administrator
Teammitglied
Moin *

Seit einiger Zeit wird mein Journal vollgespamt mit Meldungen, die irgendwie aus dem Kontext von SSH / SElinux zu kommen scheinen:
Code:
Dez 29 08:44:16 j2 audit[26546]: CRYPTO_KEY_USER pid=26546 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:19:17:69:e2:69:92:9d:4e:76:02:ae:08:5a:2b:a9:a4:1d:cd:59:c1:ed:41:d5:87:91:f5:12:0e:12:b7:04:3e direction=? spid=26546 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26546]: CRYPTO_KEY_USER pid=26546 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:cd:aa:4f:72:39:31:4f:94:a1:2f:21:b9:23:0a:f3:12:ff:66:a9:e4:44:dd:fa:49:94:67:0c:72:46:50:05:4b direction=? spid=26546 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26546]: CRYPTO_KEY_USER pid=26546 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:2a:0a:50:82:1b:22:4e:69:29:c3:3b:6d:6e:47:97:4e:07:29:98:07:bb:bb:60:a1:bf:44:04:fb:b7:92:e2:d8 direction=? spid=26546 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 sshd[26545]: Connection closed by 127.0.0.1 port 60906 [preauth]
Dez 29 08:44:16 j2 audit[26545]: CRYPTO_KEY_USER pid=26545 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:2a:0a:50:82:1b:53:4e:69:29:c3:3b:e1:6e:47:97:4e:07:29:98:07:bb:bb:60:a1:bf:44:04:fb:b7:92:e2:d8 direction=? spid=26546 suid=74  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26545]: CRYPTO_KEY_USER pid=26545 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:19:0e:69:e2:69:92:9d:4e:76:02:2b:08:5a:2b:a9:a4:1d:cd:59:c1:ed:41:d5:87:91:f5:12:0e:12:b7:04:3e direction=? spid=26545 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26545]: CRYPTO_KEY_USER pid=26545 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:cd:aa:4f:72:39:31:4f:94:a1:2f:19:b9:23:0a:f3:12:ff:66:a9:e4:44:dd:fa:49:94:67:0c:72:46:50:ab:4b direction=? spid=26545 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26545]: CRYPTO_KEY_USER pid=26545 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:2a:0a:50:82:1b:53:4e:33:29:c3:3b:6d:6e:47:97:4e:07:29:98:07:bb:bb:60:a1:bf:44:04:fb:b7:92:e2:d8 direction=? spid=26545 suid=0  exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success'
Dez 29 08:44:16 j2 audit[26545]: USER_LOGIN pid=26545 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed'

OS: Fedora 29

Wobei, auch mit abgeschaltetem SElinux ('setenforce 0') tritt das Problem auftritt.

Habe bislang noch keinen Ansatz gefunden, die Ursache zu finden und das abzuschalten.

Irgendwelche hilfreichen Hinweise?
TNX
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ein Dump legt nahe, dass dies Resultate von SSH-Zugriffen sind, welche von der selben Maschine kommen (localhost):
Code:
# tcpdump -i lo -vv -X -s 500 port 22            
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 500 bytes
09:59:01.824571 IP (tos 0x0, ttl 64, id 56505, offset 0, flags [DF], proto TCP (6), length 60)
    localhost.33372 > localhost.ssh: Flags [S], cksum 0xfe30 (incorrect -> 0x2499), seq 1712877610, win 43690, options [mss 65495,sackOK,TS val 3927588294 ecr 0,nop,wscale 7], length 0
        0x0000:  4500 003c dcb9 4000 4006 6000 7f00 0001  E..<..@.@.`.....
        0x0010:  7f00 0001 825c 0016 6618 702a 0000 0000  .....\..f.p*....
        0x0020:  a002 aaaa fe30 0000 0204 ffd7 0402 080a  .....0..........
        0x0030:  ea1a 3dc6 0000 0000 0103 0307            ..=.........
09:59:01.824604 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    localhost.ssh > localhost.33372: Flags [S.], cksum 0xfe30 (incorrect -> 0xdd54), seq 2425654973, ack 1712877611, win 43690, options [mss 65495,sackOK,TS val 3927588294 ecr 3927588294,nop,wscale 7], length 0
        0x0000:  4500 003c 0000 4000 4006 3cba 7f00 0001  E..<..@.@.<.....
        0x0010:  7f00 0001 0016 825c 9094 8ebd 6618 702b  .......\....f.p+
        0x0020:  a012 aaaa fe30 0000 0204 ffd7 0402 080a  .....0..........
        0x0030:  ea1a 3dc6 ea1a 3dc6 0103 0307            ..=...=.....
09:59:01.824623 IP (tos 0x0, ttl 64, id 56506, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.33372 > localhost.ssh: Flags [.], cksum 0xfe28 (incorrect -> 0xaf99), seq 1, ack 1, win 342, options [nop,nop,TS val 3927588294 ecr 3927588294], length 0
        0x0000:  4500 0034 dcba 4000 4006 6007 7f00 0001  E..4..@.@.`.....
        0x0010:  7f00 0001 825c 0016 6618 702b 9094 8ebe  .....\..f.p+....
        0x0020:  8010 0156 fe28 0000 0101 080a ea1a 3dc6  ...V.(........=.
        0x0030:  ea1a 3dc6                                ..=.
09:59:01.844421 IP (tos 0x0, ttl 64, id 8749, offset 0, flags [DF], proto TCP (6), length 73)
    localhost.ssh > localhost.33372: Flags [P.], cksum 0xfe3d (incorrect -> 0xe6bf), seq 1:22, ack 1, win 342, options [nop,nop,TS val 3927588314 ecr 3927588294], length 21
        0x0000:  4500 0049 222d 4000 4006 1a80 7f00 0001  E..I"-@.@.......
        0x0010:  7f00 0001 0016 825c 9094 8ebe 6618 702b  .......\....f.p+
        0x0020:  8018 0156 fe3d 0000 0101 080a ea1a 3dda  ...V.=........=.
        0x0030:  ea1a 3dc6 5353 482d 322e 302d 4f70 656e  ..=.SSH-2.0-Open
        0x0040:  5353 485f 372e 390d 0a                   SSH_7.9..
WTF?
 
OP
gehrke

gehrke

Administrator
Teammitglied
Es tritt minütlich auf, jeweils nach 16 Sekunden.

Ich versuche, Information über die PID zu erlangen, aber die sind immer schnell wieder weg.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ah, ich glaube den Verursacher gefunden zu haben:
Code:
[root@j2 ~]# systemctl status icinga2.service
● icinga2.service - Icinga host/service/network monitoring system
   Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/icinga2.service.d
           └─limits.conf
   Active: active (running) since Wed 2018-12-26 07:57:18 CET; 3 days ago
 Main PID: 1688 (icinga2)
    Tasks: 13
   Memory: 25.1M
   CGroup: /system.slice/icinga2.service
           ├─1688 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log
           └─1762 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log

Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars'
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/ConfigObject: Restoring program state from file '/var/lib/icinga2/icinga2.state'
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/ConfigObject: Restored 262 objects. Loaded 0 new objects without state.
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/ConfigItem: Triggering Start signal for config items
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/FileLogger: 'main-log' started.
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/CheckerComponent: 'checker' started.
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/NotificationComponent: 'notification' started.
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/ConfigItem: Activated all objects.
Dez 26 07:57:18 j2 icinga2[1688]: [2018-12-26 07:57:18 +0100] information/cli: Closing console log.
Dez 26 07:57:18 j2 systemd[1]: Started Icinga host/service/network monitoring system.
Wenn dieser Service gestoppt ist, ist auch Ruhe im Journal.

Icinga ist eh noch eine offene Baustelle, ich setze den Thread hier auf [Gelöst].
 
gehrke schrieb:
Es tritt minütlich auf, jeweils nach 16 Sekunden.
Das kann nur ein daemon sein.

gehrke schrieb:
Ich versuche, Information über die PID zu erlangen, aber die sind immer schnell wieder weg.
Ich würde die Information über das Port holen.

Schreibe ein simples script mit
Code:
# tshark -o "gui.column.format:\"src port\",\"%S\"" -i lo -c1 src host 127.0.0.1 and tcp port 22 2> /dev/null
Das bricht nach dem ersten connect() auf port 22 ab und liefert das src_port.
Sobald port bekannt
Code:
# lsof -a -i4:$SRC_PORT -P
Damit weißt du alles über den Verursacher

Nochetwas abseits des Themas:
setenforce 0 hilft nicht. SElinux muß aus dem kernel.
Wenn du Wert auf ein System legst, das tut was DU willst, dann entferne es!!
 
OP
gehrke

gehrke

Administrator
Teammitglied
Dank für die zusätzlichen Infos, auch wenn die Ursache schon gefunden ist. Diese Vorgehensweise kann ich sicherlich an anderer Stelle nochmal gut gebrauchen.
Damit weißt du alles über den Verursacher
Den Port kannte ich schon aus dem Dump. Es ist nur scheinbar so, dass der Prozess zum Zeitpunkt der Ausführung von 'lsof' schon wieder weg ist:
Code:
# tshark -o "gui.column.format:\"src port\",\"%S\"" -i lo -c1 src host 127.0.0.1 and tcp port 22 2> /dev/null | xargs -I {} lsof -a -i4:{} -P
<kein Ergebnis>

SElinux muß aus dem kernel.
Wenn du Wert auf ein System legst, das tut was DU willst, dann entferne es!!
Danke, aber SElinux bleibt.
 
gehrke schrieb:
Es ist nur scheinbar so, dass der Prozess zum Zeitpunkt der Ausführung von 'lsof' schon wieder weg ist:
Code:
# tshark -o "gui.column.format:\"src port\",\"%S\"" -i lo -c1 src host 127.0.0.1 and tcp port 22 2> /dev/null | xargs -I {} lsof -a -i4:{} -P
<kein Ergebnis>
Wenn du es in das Terminal schreiben willst, dann sollte die Zeile so aussehen:
Code:
# lsof -a -i4:$(tshark -o "gui.column.format:\"src port\",\"%S\"" -i lo -c1 src host 127.0.0.1 and tcp port 22 2> /dev/null) -P
Der handshake prozess zwischen ssh client und server ist > 20 bis zur erfolgreichen, verschlüsselten Verbindung.
Die Zeile liefert an lsof schon nach dem ersten connect() das port.
Da ist das eigentliche handshake noch gar nicht passiert und der Verursacher ist noch mit dem Verbindungsaufbau beschäftigt.
Es würde mich interessieren, ob du damit Erfolg hast.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Code:
# lsof -a -i4:$(tshark -o "gui.column.format:\"src port\",\"%S\"" -i lo -c1 src host 127.0.0.1 and tcp port 22 2> /dev/null) -P
<kein Ergebnis>
 
Oben