There are comments in the /etc/rsyslog.d/20-ufw.conf file that give you the option to keep UFW-events from being logged to the kernel and message logs, which i have done.

I would really like to get UFW-events out of the dmesg as well, but how to accomplish that?

  • 4
    As a work around for now I've just aliased dmesg with dmesg | grep -v UFW. Nov 2 '10 at 14:10
  • Related bugs on Launchpad: 1264621 and 1475676. Jul 16 '17 at 16:21

You can disable UFW logging with following command from shell:

sudo ufw logging off

Default loglevel is low. From UFW man page:

  • off disables ufw managed logging
  • low logs all blocked packets not matching the default policy (with rate limiting), as well as packets matching logged rules
  • medium log level low, plus all allowed packets not matching the default policy, all INVALID packets, and all new connections. All logging is done with rate limiting.
  • high log level medium (without rate limiting), plus all packets with rate limiting
  • full log level high without rate limiting

You can get current log level with sudo ufw status verbose.

  • Do you have to do that at each boot?
    – Matthieu
    Jan 9 '20 at 19:08
  • 2
    @Matthieu No, this command changes the configuration in /etc/ufw/ufw.conf and survives reboot
    – Sentry
    May 1 '20 at 19:53

I have done some investigation into this issue.

I don't believe there is a way around this.

The dmesg command directly prints the contents of the Kernel Ring Buffer. This contains all the ufw log entries that you are seeing.

The /etc/rsyslog.d/20-ufw.conf file is telling rsyslog which of the ufw entries in the Kernel Ring Buffer to log to either the /var/log/ufw.log or /var/log/kern.log.

You can prevent the ufw entries from being logged to /var/log/kern.log (to remove duplication) by uncommenting the line in /etc/rsyslog.d/20-ufw.conf that contains & ~.

Unfortunately there is no way to prevent the dmesg command from displaying these messages. Your work around is the best I can come up with.

  • Chris thanks for looking into this. +1 for the effort. I'm going to leave the question unanswered for now though to see if anyone else has any ideas. Perhaps there's no solution to this and I'll file a bug on launchpad as I'm sure there are others who like to keep an eye on dmesg to make sure there's no hardware issues going on with their server and don't care to see the UFW entries. Nov 6 '10 at 2:10
  • Just to pick up on your mentioning bug reports: (archived) Debian bug #664748 and Launchpad bug #555852 now seem to track this issue. Feb 18 '13 at 15:27

For people who would like to fine tune the log level further, I suggest using 'log' or reject/deny rules (see the ufw man page for details). For exampe, you can use 'logging off' and then insert explicit logging rules for what you want to log. Alternatively, you can use 'logging low' and then insert explicit deny/reject rules to quietly deny matches that would otherwise be logged.


You could also just use grep to filter out the UFW messages. For instance,

dmesg | grep -v UFW

This way you can also keep the logging for reviewing.

  • 3
    This is hardly useful because on any actual server facing the internet there is nothing else in any logs besides the UFW messages. May 14 '19 at 10:29

The above answer is the only way:

    dmesg | grep -v UFW

But you can use this more easily, by setting an alias like this:

    alias dmesg='dmesg | grep -v UFW'

This will execute dmesg | grep -v UFW if you enter dmesg.

If you want to keep the colorful version of dmesg, you can use the following command:

    alias dmesg='dmesg --color=always | grep -v UFW --color=always'

This way dmesg use colors over the pipe too.

WARNING! Only use this method while viewing logs and searching for something, because this might break some 3rd party scripts in that session.


To get rid of the warnings, you can also block the IPs explicitly in case you are sure they are malicious, see UFW BLOCK entries in the log

It uses the command sudo ufw deny from XXX to YYY so that those IPS cannot ping or ssh your server. The script in the link above parses all those malicious IPs from the syslog.

  • You should provide some details from the link to give a complete answer. Apr 30 '21 at 10:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.