Keine Einträge von dmesg im journal / systemd

[Mike Thebo]

Hallo Community,

ich bin durch installieren von ufw darauf aufmerksam geworden, dass ich
keinerlei messages von dmesg im Log finden kann und damit auch keine
Logeinträge von ufw. Da das auch unabhängig von ufw der Fall ist, poste
ich hier allgemein.

Hintergrund:
- neue Installation von Debian 8.6 auf einem Virtual Server (VS
vielleicht Teil des Problems?)
- systemd 230-7~bpo8+2
- ufw 0.33-2
- kein rsyslog installiert

***@xyz:~# journalctl -k
-- No entries --

***@xyz:~# journalctl --dmesg
-- No entries --

***@xyz:~# dmesg -H
[Nov25 02:44] 3 WINDOW=9933 RES=0x00 SYN URGP=0
[Dez29 15:45] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +12,804260] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +11,989585] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[Dez29 15:46] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
usw.

Die einzigen ufw Einträge, die ich nach einem Reboot jemals überhaupt im
journal finden kann sind die unten stehenden. Diese werden aber nicht
mit journalctl -k oder --dmesg angezeigt. Diese Ausgabe ist weiterhin leer.

***@xyz:~# journalctl --no-pager | grep -i ufw
Dez 28 23:11:10 xyz ufw[175]: Starting firewall: ufw...modprobe: ERROR:
../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file
'/lib/modules/3.16.0-042stab120.6/modules.dep.bin'

Dez 28 23:11:10 xyz ufw[175]: modprobe: ERROR: ../libkmod/libkmod.c:557
kmod_search_moddep() could not open moddep file
'/lib/modules/3.16.0-042stab120.6/modules.dep.bin'

Dez 28 23:11:10 xyz ufw[175]: modprobe: ERROR: ../libkmod/libkmod.c:557
kmod_search_moddep() could not open moddep file
'/lib/modules/3.16.0-042stab120.6/modules.dep.bin'

Dez 28 23:11:10 xyz ufw[175]: sysctl: permission denied on key
'net.ipv4.tcp_sack'

Dez 28 23:11:10 xyz ufw[175]: Setting kernel variables
(/etc/ufw/sysctl.conf)...done.

Hat jemand einen Tipp, nach was ich noch schauen kann?

Gruß
Mike

[Sven Hartge]

Post by Mike Thebo
- neue Installation von Debian 8.6 auf einem Virtual Server (VS
vielleicht Teil des Problems?)

Ich wette mit dir, dass das Paket rsyslog fehlt. Das hatten wir neulich
im Kontext von VPS schon einmal.

Post by Mike Thebo
- kein rsyslog installiert

Aha.

Post by Mike Thebo
Hat jemand einen Tipp, nach was ich noch schauen kann?

Installiere rsyslog und schaue, was passiert.

S°

[Mike Thebo]

Hi Sven,

also im Zusammenhang mit ufw bin ich auch über rsyslog gestolpert. Zumal
es dazu ein conf-file gibt: 20-ufw.conf.

Aber jetzt mal ufw außen vo,r muss ich gestehen, dass ich dann den Sinn
von systemd/journald nicht ganz verstehe. Ich dachte entsprechend
eingerichtet sei das ein vollständiger Ersatz für sysinit/syslog. Und
eigentlich sieht doch auch journald das Loggen von Kernelmessages vor,
wenn ich die HowTos und Beschreibungen so verfolge.

Post by Sven Hartge
Installiere rsyslog und schaue, was passiert.

Du wirst lachen. Aber das habe ich schon vor meinem Post gemacht. Habe
es nur nicht erwähnt, weil ich nicht gedacht hätte, dass es für dmesg
notwendig wäre. Leider hat sich dabei aptitude an der Stelle ...wird
eingerichtet aufgehängt. Nach einen Reboot war das System nicht mehr
erreichbar :-(. Ich hatte zum Glück einen Snapshot. Allerdings hält sich
meine Motivation zu einem erneuten Versuch in Grenzen. Zumindest nicht
mehr dieses Jahr ;-).

Ggf. teste ich vorher noch mal lokal in einer VM.

Gruß
Mike

Post by Sven Hartge

Post by Mike Thebo
- neue Installation von Debian 8.6 auf einem Virtual Server (VS
vielleicht Teil des Problems?)

Ich wette mit dir, dass das Paket rsyslog fehlt. Das hatten wir neulich
im Kontext von VPS schon einmal.

Post by Mike Thebo
- kein rsyslog installiert

Aha.

Post by Mike Thebo
Hat jemand einen Tipp, nach was ich noch schauen kann?

Installiere rsyslog und schaue, was passiert.
S°

[Sven Hartge]

Post by Mike Thebo
Aber jetzt mal ufw außen vo,r muss ich gestehen, dass ich dann den Sinn
von systemd/journald nicht ganz verstehe. Ich dachte entsprechend
eingerichtet sei das ein vollständiger Ersatz für sysinit/syslog. Und
eigentlich sieht doch auch journald das Loggen von Kernelmessages vor,
wenn ich die HowTos und Beschreibungen so verfolge.

Die Frage ist: loggen die ufw-Regeln überhaupt ins Kernel-Log oder
loggen sie via NFLOG-Target in den Userspace? Bei letzterem braucht es
dann ulogd2, um die Daten in ein Log-File zu schreiben.

Letzteres ist eigentlich die empfohlene Variante, weil NFLOG einen
deutlich geringeren Overhead hat und man via ulogd2 z.B. in anderen
Formaten loggen kann, nicht nur als Text-Datei, sondern z.B. in eine
SQL-Datenbank oder via JSON in Elasticsearch oder Greylog.

S°

[Mike Thebo]

Hallo Sven,

Post by Sven Hartge
Die Frage ist: loggen die ufw-Regeln überhaupt ins Kernel-Log oder
loggen sie via NFLOG-Target in den Userspace?

Das kann ich leider nicht beantworten. Beim Googlen kam auch nicht viel
hilfreiches, außer 1 Bug Eintrag (Wishlist), in denen es unter anderem
heißt "please add NFLOG support". ;-). Die sind von 2015.

Allerdings wenn ich das richtig sehe, kann ich mir doch die erstellten
Rules von ufw im iptables anschauen und diese dann neu rein schreiben
mit NFLOG als target und die anderen löschen, oder? Gut nachdem ich ufw
habe was am Logging ändern lassen, müsste ich jeweils ein Script laufen
lassen, welches die targets ändert.

Habe inzwischen ein Python Skript geschrieben, welches die
entsprechenden Regeln austauscht. Habe ulogd2 installiert und bekomme:
unable to bind to log group 0
error starting `log1'
not even a single working plugin stack

Ich kann auch nicht überprüfen, ob die nötigen Kernelmodule geladen sind.

Nach einigem Googlen scheint das auch wieder mit OpenVZ
zusammenzuhängen. Zeit mal beim Support nachzufragen.

Gruß und frohes neues Jahr noch.
Mike

Post by Sven Hartge

Post by Mike Thebo
Aber jetzt mal ufw außen vo,r muss ich gestehen, dass ich dann den Sinn
von systemd/journald nicht ganz verstehe. Ich dachte entsprechend
eingerichtet sei das ein vollständiger Ersatz für sysinit/syslog. Und
eigentlich sieht doch auch journald das Loggen von Kernelmessages vor,
wenn ich die HowTos und Beschreibungen so verfolge.

Die Frage ist: loggen die ufw-Regeln überhaupt ins Kernel-Log oder
loggen sie via NFLOG-Target in den Userspace? Bei letzterem braucht es
dann ulogd2, um die Daten in ein Log-File zu schreiben.
Letzteres ist eigentlich die empfohlene Variante, weil NFLOG einen
deutlich geringeren Overhead hat und man via ulogd2 z.B. in anderen
Formaten loggen kann, nicht nur als Text-Datei, sondern z.B. in eine
SQL-Datenbank oder via JSON in Elasticsearch oder Greylog.
S°

[Sven Hartge]

[Vorweg: Bitte schicke mir keine Kopien deiner Mails zu, ich lese die
Liste, in der ich schreibe.]

Post by Mike Thebo

Post by Sven Hartge
Die Frage ist: loggen die ufw-Regeln überhaupt ins Kernel-Log oder
loggen sie via NFLOG-Target in den Userspace?

Das kann ich leider nicht beantworten.

Doch. Die entsprechenden Regeln sind z.B. via "iptables -v -L" sichtbar.
Sieht z.B. so aus:

,----
| Chain killgeo (2 references)
| pkts bytes target prot opt in out source destination
| 248K 12M NFLOG all -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "GEO:"
| 248K 12M rej all -- * * 0.0.0.0/0 0.0.0.0/0
`----

S°

[Mike Thebo]

Hallo Sven,

Post by Sven Hartge
,----
| Chain killgeo (2 references)
| pkts bytes target prot opt in out source destination
| 248K 12M NFLOG all -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "GEO:"
| 248K 12M rej all -- * * 0.0.0.0/0 0.0.0.0/0
`----

Hmm...mein ufw nutzt das LOG target. Vielleicht auch noch eine Sache der
Version. Es ist nur jetzt ohnehin so, dass mir das nötige Kernelmodul in
meinem Container nicht zur Verfügung steht und sich das auch nicht ohne
Weiteres erweitern lässt, bzw. nur auf Basis der Hardwarenodes. Und das
sei derzeit nicht angedacht, so der Provider.

Ich habe jedenfalls eine Menge dazugelernt und danke euch für die
Unterstützung. Dann muss es eben watch und dmesg tun.

Gruß
Michael

[Sven Hartge]

Post by Mike Thebo
Hallo Sven,

Post by Sven Hartge
,----
| Chain killgeo (2 references)
| pkts bytes target prot opt in out source destination
| 248K 12M NFLOG all -- * * 0.0.0.0/0 0.0.0.0/0 nflog-prefix "GEO:"
| 248K 12M rej all -- * * 0.0.0.0/0 0.0.0.0/0
`----

Hmm...mein ufw nutzt das LOG target. Vielleicht auch noch eine Sache der
Version.

LOG läuft in das Kernel-Log.

Post by Mike Thebo
Es ist nur jetzt ohnehin so, dass mir das nötige Kernelmodul in meinem
Container nicht zur Verfügung steht und sich das auch nicht ohne
Weiteres erweitern lässt, bzw. nur auf Basis der Hardwarenodes. Und
das sei derzeit nicht angedacht, so der Provider.

Container-basierte Virtualisierung ist immer voll von diesen
Überraschungen. Vor nicht allzu langer Zeit konnte man z.B. in
Containern gar keine iptables-Regeln benutzen, teilweise hatte man nicht
einmal das Interface "lo" (und damit 127.0.0.1) zur Verfügung, was Dinge
wie "Daemon nur an localhost lauschen lassen" unmöglich machte.

S°

[Heiko Schlittermann]

Post by Mike Thebo
Hallo Community,
ich bin durch installieren von ufw darauf aufmerksam geworden, dass ich
keinerlei messages von dmesg im Log finden kann und damit auch keine
LogeintrÀge von ufw. Da das auch unabhÀngig von ufw der Fall ist, poste
ich hier allgemein.
- neue Installation von Debian 8.6 auf einem Virtual Server (VS
vielleicht Teil des Problems?)

Vermutlichlich.
Was sagt

systemd-detect-virt

?
In meiner Umgebug hier habe ich einen systemd-nspawn Container, der hat
bei `journalctl -k` auch nichts, wohl aber bei `dmesg`.

Post by Mike Thebo
[Nov25 02:44] 3 WINDOW=9933 RES=0x00 SYN URGP=0
[Dez29 15:45] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +12,804260] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +11,989585] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[Dez29 15:46] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...

Das ist vermutlich das Log vom Host (Wirt).

Post by Mike Thebo
Dez 28 23:11:10 xyz ufw[175]: sysctl: permission denied on key
'net.ipv4.tcp_sack'

Sollte man sich fragen, warum "Permission denied". In einer
containerbasierten Virtualisierung wÀre das aber nicht unnormal.
Denn da gibt es nur den Kernel des Wirts, und den kannst Du nicht
beeinflussen.

Best regards from Dresden/Germany
Viele GrÌße aus Dresden
Heiko Schlittermann

[Mike Thebo]

Hallo Heiko,

vielen Dank für die Rückmeldung.

Post by Heiko Schlittermann
Was sagt
systemd-detect-virt

Liefert: openvz

Ja dmesg -H zeigt mir ja auch die ufw Einträge. Ich sehe auch meine IP
bei Port-Scans.

Also nehme ich mit, dass das bei Virtualisierung nicht ungewöhnlich ist?

Gruß und ein gutes neues Jahr noch!
Mike

Post by Heiko Schlittermann

Post by Mike Thebo
Hallo Community,
ich bin durch installieren von ufw darauf aufmerksam geworden, dass ich
keinerlei messages von dmesg im Log finden kann und damit auch keine
Logeinträge von ufw. Da das auch unabhängig von ufw der Fall ist, poste
ich hier allgemein.
- neue Installation von Debian 8.6 auf einem Virtual Server (VS
vielleicht Teil des Problems?)

Vermutlichlich.
Was sagt
systemd-detect-virt
?
In meiner Umgebug hier habe ich einen systemd-nspawn Container, der hat
bei `journalctl -k` auch nichts, wohl aber bei `dmesg`.

Post by Mike Thebo
[Nov25 02:44] 3 WINDOW=9933 RES=0x00 SYN URGP=0
[Dez29 15:45] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +12,804260] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[ +11,989585] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...
[Dez29 15:46] [UFW BLOCK] IN=venet0 OUT= MAC= SRC=...

Das ist vermutlich das Log vom Host (Wirt).

Post by Mike Thebo
Dez 28 23:11:10 xyz ufw[175]: sysctl: permission denied on key
'net.ipv4.tcp_sack'

Sollte man sich fragen, warum "Permission denied". In einer
containerbasierten Virtualisierung wäre das aber nicht unnormal.
Denn da gibt es nur den Kernel des Wirts, und den kannst Du nicht
beeinflussen.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann