Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 ?

share|improve this question
    
What's the point in logging everything anyway? –  0xC0000022L May 11 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. –  Andreas Wiese May 11 at 21:47
    
@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. –  Martin Vegter May 12 at 7:13

3 Answers 3

You could use the NFLOG target instead of LOG:

NFLOG
    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.

share|improve this answer
    
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. –  Martin Vegter May 20 at 21:25

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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