In my iptables, I have a rule which logs dropped packets:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7
-A INPUT -i eth0       -j   DROP

And in /etc/rsyslog.conf, I have another rule which sends these logs to a dedicated file /var/log/firewall.log.

:msg, contains, "FW: "                    -/var/log/firewall.log
& ~

The & ~ deletes the logs immediately, so that they don't flood syslog or other log files.

This works well, except that it floods dmesg with those firewall logs (not /var/log/dmesg but the output of command dmesg).

Is there a way to prevent these logs being shown in dmesg ?

  • What's the point in logging everything anyway? May 11, 2014 at 19:26
  • 1
    It's really no good idea to log all dropped packets. Better thing than eliminating the symptoms would be being more specific with your logging rule. E.g. it's not very wise to log any packets that are not related to any connection and don't do anything »special« (like connection initation). Would be much better to cut this down to relevant things like »Host A wanted to connect to port B«. Potentially the number of reasons a packet is dropped is massively greater than the number of reasons you would drop it for a relevant reason. May 11, 2014 at 21:47
  • 1
    @Andreas Wiese - I have simplified my rule for the sake of this question. My rules are more sophisticated and specific. But anyway, the question is how to prevent dmesg being flooded, not about firewall rules. May 12, 2014 at 7:13
  • See also this answer about the Netfilter logging daemon ulogd2. That is how I solved the problem.
    – mivk
    Feb 20, 2019 at 12:52

4 Answers 4


You could use the NFLOG target instead of LOG:

    This target provides logging of matching packets. When this  target  is  set  for  a
    rule, the Linux kernel will pass the packet to the loaded logging backend to log the
    packet. This is usually used in combination with nfnetlink_log as  logging  backend,
    which  will multicast the packet through a netlink socket to the specified multicast
    group. One or more userspace processes may subscribe to the  group  to  receive  the
    packets.  Like  LOG, this is a non-terminating target, i.e. rule traversal continues
    at the next rule.

All you'd need is a nfnetlink_log capable logging program. Messages would go there and the userspace process would decide whether to log the packet or not.

Another thing you could try would be limiting the LOG rule to a specific threshold:

-A INPUT -i eth0 -m limit --limit 10/minutes -j LOG --log-prefix "FW: " --log-level 7
-A INPUT -i eth0 -j DROP

This would on average log 10 packets per minute. You could of course adjust this at your needs.

  • I was not able to find any information how to configure rsyslog to log NFLOG packets. I need some solution that will work with rsyslog. May 20, 2014 at 21:25
  • 2
    @MartinVegter - NFLOG will work with rsyslog. For NFLOG, you would use ulogd (I think ulogd2 is needed) as the go-between. It will listen on the netlink socket to get the logs, and deliver them (as configured) to syslog. If ulogd2 is not available, use ulogd (1.x) and the ULOG target. May 7, 2015 at 15:28

When you have set the log level to 7 with the command:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7

Then you can simply filter out these messages by passing the level threshold to the dmesg:

dmesg --level=err,warn

It may be related to the log-level you are using in iptables. As I understand it from the rsyslog documentation log levels are: "The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg)." What about trying to specify the log level in iptables by using its name, i.e. 'notice'. Well serves me right for posting without checking as I now think that is not the issue at all. I implemented a similar scheme to that outlined above and I get the same issue. My centos 7 kernel is v3.10.0 and apparently since v3.5 it seems that kernel logging is done using /dev/kmsg and I presume dmesg somehow gets its input from there.


Why do you care? dmesg is a low-level tool to print recent kernel messages, and you did ask for the kernel to log dropped packets.

Configure your system's syslog system to log iptables messages in a separate log file from other kernel messages, and use the log files that it writes instead of dmesg.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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