Score:1

Why does UFW keep logging to syslog even when I turn it off through rsyslog settings?

jm flag

I've uncommented

& stop

in /etc/rsyslog.d/20-ufw.conf.

I've set

StandardOutput=null

by using

systemctl edit ufw

which shouldnt help anyway because the syslog messages are sent by a "kernel" unit, not the "ufw" service, but I tried it anyway.

Ive restarted ufw and rsyslog through

systemctl daemon-reload
systemctl restart ufw
systemctl restart rsyslog

and yet, journalctl is filled with [UFW BLOCK] messages. I see them. Once every 5-20 seconds. filling the log. Hiding the messages I care about from the various samba related systems that are difficult to filter using -u.

I know I can grep them away but I want to understand why I can't turn them off, because there is something I don't understand.

---- Edit

Ok, step one in understanding why editing the rsyslog rules don't do what I thought they should:

The ufw logs are mirrored to the kernel log, not the syslog. putting "& stop" in the rsyslog config only says that it stops logging to the syslog. So, perhaps being unable to separate logging between kern.log and ufw.log is a feature.

It still does not make sense to me in the slightest.

eDonkey avatar
ss flag
Do you want to discard the `[UFW BLOCK]` messages or stop logging ufw messages altogether? Or do you want to stop rsyslog from forwarding ufw messages to journald?
Jonatan Pipping avatar
jm flag
I only want to stop seeing the log messages in the journal. I definitely want to keep the messages in ufw.log.
eDonkey avatar
ss flag
As far as I know, the *best* solution then, is the one written by @steeldriver. The problem is, that journald doesn't perform any filtering; that is usually done using journalctl. See [Filter mechanism for logs in journald #6432](https://github.com/systemd/systemd/issues/6432). Therefore you can either have the logs in both rsyslog and journald, or in neither of them. Furthermore when using journalctl to display the logs, it's still not possible to exclude a specific unit (without grep etc.). See [RFE: add NOT operator to journal matching #2720](https://github.com/systemd/systemd/issues/2720).
meuh avatar
cn flag
Perhaps you should attack the problem from the other end, and configure rsyslog to match the "messages I care about from the various samba related systems" into a separate log file, then you won't need to fight with journalctl, and you can easily tail the log and so on.
Score:2
hr flag

I think what you're seeing here is the result of the default ufw logging level, which creates the following iptables rules:

$ sudo iptables --list-rules | grep prefix
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "

It looks like these rules may be modified by turning logging off:

$ sudo ufw logging off
Logging disabled
$ sudo ufw reload 
Firewall reloaded

then

$ sudo iptables --list-rules | grep prefix

returns nothing.

Jonatan Pipping avatar
jm flag
Jesus my rambling comments. Lets try this again. I don't want to stop logging, and I definitely want to keep the logs going to /var/log/ufw.log. I only want to stop the logs from being mirrored to kern.log, because when they are mirrored to kern.log they also end up in the output of journalctl.
hr flag
@JonatanPipping I think what you're bumping up against is that UFW logs aren't "mirrored" to the kern.log - if anything, it's the other way around. In fact, UFW itself doesn't log anything, it just writes rules (including logging rules) to the kernel's internal packet filter (netfilter/iptables) at boot time, then exits. Then, as I understand it, systemd-journald reads /dev/kmsg, which is how the UFW messages end up in the journal, and optionally forwards them to the syslog daemon and hence (again optionally) to /var/log/ufw.log
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.