If you use netfilter's iptables, you may know that a target could be LOG (with a prefix that can be configured) sending detailed information in the kernel log (since netfilter runs in the kernel). Rsyslog and syslog-ng regularily read the kernel log and save it to kern.log (among others).
The common issue is: how to write netfilter messages into a specific log file ?
As explained on this good blog, the first solution can be to send netfilter messages with a fixed priority (let's say DEBUG, the highest) and then, in rsyslog/syslog-ng filter out messages with that priority to save them into another log file, e.g. iptables.log. However, all messages, especially those not sent by netfilter, are saved in this log file, which make this solution not acceptable. The second solution is to use rsyslog's instructions to match the contents of message. Assuming netfilter sends message starting with "iptables: " (using iptables' --log-prefix) we can easily filter these messages with rsyslog and save them into iptables.log.
To do this, just create /etc/rsyslog.d/iptables.conf with the following:
:msg, startswith, "iptables: " -/var/log/iptables.log & ~ :msg, regex, "^\[ *[0-9]*\.[0-9]*\] iptables: " -/var/log/iptables.log & ~
According to rsyslog.conf(5) man page, the first line matches all messages that starts with "iptables: " using startswith instruction, save them into /var/log/iptables.log, then the second line ("& ~") says to delete the message otherwise it would be logged in kern.log and other kernel logging files. Third and fourth lines do the same with messages starting with kernel time. For instance, "[ 123.456] iptables: " would also match.
Reload rsyslog and you're done.
- on some distributions, rsyslog configuration is saved in /etc/rsyslog.d/50-default.conf. To avoid logging in main files, you need to rename iptables.conf to something like 10-iptables.conf to be processed before the default configuration (because with directive "& ~", iptables messages are discarded).
- on some distributions, rsyslog drop privileges to user:group such as log:adm. If your logs are empty, check user/group and permissions ;)