Redirecting Firewall Messages in Linux

The Linux firewall is a great way to secure a server, especially one that is Internet facing. Together with ipset and an appropriate blacklist, it can protect your server from the worst the Internet can throw at it. However, netfilter (aka iptables), can generate a lot of messages. By default they go to the kernel logging channel, flooding out log files such as messages, syslog and kern.log.

It is important to keep log files clear so that system issues are not missed. For example, a hardware or memory error message might be written to kern.log, but could be difficult to notice due to many thousands of firewall messages. Worse, over time, the important message will be moved into a historical log files due to the action of logrotate.

This article explains how to send firewall messages to their own log file, using the example of a Raspberry Pi running Raspbian 9 (Debian Stretch). After a small configuration change, netfilter messages go to their own file instead of clogging up the general logs.

Firewall Message Example

This is the stuff we are talking about. IPtables wrote the following message after it blocked a packet from, a known comment spammer. Over several hours, the same address was blocked about 1300 times, leaving behind 1300 similar messages in the system log files.

Apr 26 12:20:16 pluto kernel: [239826.246625] IN=eth0 OUT= MAC=b8:27:eb:d3:82:f6:b1:4f:b9:43:e5:1b:44:00:45:00:10:4b:8d:18:32:00:1e:a5:b0:da SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=36121 DF PROTO=TCP SPT=58201 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 

System Logs

The above firewall message was taken from a Raspberry Pi running Raspbian Stretch (based on Debian 9). Along with thousands of similar messages, it was written to log files kern.log, messages and syslog, flooding out all other messages in those files (all under /var/log).

How much other Linux distributions will suffer the same problem depends on their (default) configuration of rsyslog.

However, a quick configuration change can send firewall messages to their own file. Proceed as follows.

Reconfigure the Firewall

First, change the relevant firewall rules to include a string we can filter on. In your firewall rules, find the rule(s) that are producing the log messages, and “--log-prefix” with an appropriate string. In the above example, the rule which writes the message is:

iptables -A INPUT -m set --match-set blacklist src -j LOG --log-level warning

It was modified to include a recognizable string:

iptables -A INPUT -m set --match-set blacklist src -j LOG --log-level warning --log-prefix "netfilter: "

And the firewall was restarted.

Incidentally, notice this rule is blocking / logging IP addresses based on a blacklist created with ipset. Ipset is a great way to protect your server, especially if you are running a commonly targeted service like WordPress.

Reconfigure Rsyslogd

Next, created a file /etc/rsyslog.d/50-my_iptables.conf, containing these two lines:

:msg,contains,"netfilter:" /var/log/iptables.log

The first line directs messages containing the string “netfilter:” into the given file, /var/log/iptables.log. The “&stop” line stops processing at that point, so that the messages are not duplicated to the above files (where rsyslog sends them due to its main config file).

Finally, restart the rsyslog service:
$ sudo service rsyslog restart

After rsyslog has been restarted, firewall messages should start being written into their own file, and will no longer be written to the general log files like messages, syslog and kern.log.

Configure Logrotate

In order that the new log file is rotated along with other system logs, we will add it to the logrotate configuration. Edit the file /etc/logrotate.d/rsyslog. Add the line “/var/log/iptables.log” as shown, among the list of similar logs:


The file iptables.log will henceforth be rotated automatically, in the same way that (for example) kern.log and auth.log are.

Verify Log File Rotation

In order to verify rotation of the new file, check back after a few days. As well as the iptables.log file, you should see the preserved file “iptables.log.1“. If not, force a rotation by typing:

# logrotate --force /etc/logrotate.d/rsyslog

and look again for the rotated file “iptables.log.1“.


There are several other ways to decrease or change firewall logging. Easiest of all is probably just to remove, or comment out from the netfilter configuration, lines that create the unwanted messages (being careful not to materially alter the firewall functioning). You will be untroubled by excessive messaging, but won’t have any log record of packets dropped.

The kernel ring buffer (whose contents are viewed with the dmesg command) will continue to receive netfilter messages, regardless of the above configuration changes. It is not managed by rsyslogd.


The default configuration of rsyslogd in Raspbian 9 is perhaps too verbose. There is much duplication of messages due to the bundled /etc/rsyslog.conf file. I haven’t checked many other distributions, but Mint 18, for example, is much less chatty.

4 thoughts on “Redirecting Firewall Messages in Linux

  1. Pingback: Protect Your Web Server With Ipset | Unix etc.

  2. Thank you for this, but surely there is a way to redirect firewall messages that does not involve adding a prefix to every firewall rule. Failing that, I hope for a way of automating that addition.

    • Hi JL, adding a prefix to every rule isn’t necessary and isn’t suggested in the article. To clarify, in this case nearly all messages are produced by one firewall rule, because it references a blacklist containing thousands of IP addresses. Attempted connections from forbidden IP addresses are logged, leading to thousands of messages.

      That is, the rule is designed to be “noisy” and is the only one requiring re-direction. In general, firewall rules are silent

      At the time of writing (2019), it wasn’t possible for rsyslog to route specific subsystem (eg. netfilter) messages to specific files, except through pattern matching as above. That might still be the case with Bullseye, though I haven’t researched it extensively.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.