iptables logs going straight to console... why?

[root.veg]

I just logged in properly (ie plugged in a monitor, keyboard and mouse) to my gateway machine for the first time in weeks, and noticed a strange thing:

When logged in in console mode, the log entries that iptables creates get printed straight to the terminal screen. They DO go to the files /var/log/messages and /var/log/syslog as expected, but whenever iptables decides to log a packet, it also gets printed straight to the console, no matter what I'm doing. I'll be typing a shell command, it'll happen in the middle of me typing, and I'll press return before I've realised it and submit a long string of gibberish to the shell. Very annoying. And just possibly damaging if I'm logged in as root (it happens whatever user I'm logged in as).

How do I stop this? I've read the iptables man page and it only talks about sending log entries to log files, and doesn't mention re-directing the entries anywhere else. Plus it doesn't happen when I'm logged in using X on the gateway machine, or using ssh (in X or console-mode) from another machine on my network. Hence why I haven't noticed it until now.

[root.veg]

Sorry people, just realised someone else posted the exact same problem about a week ago. But they did have no response, so please forgive me :o

[bwkaz]

You won't submit any of the logged messages to the shell. They're just printed to the current console, if it's a VC (i.e. if the device file is named /dev/vc*). Or perhaps a serial console -- /dev/ttyS* -- but I'm not sure on that one.

If you're logged in on a VC, then take a look at dmesg's -n option to control the severity of log messages that get printed to the current VC. For example, a lot of distros set up dmesg -n 4 in their init scripts, so that only severity 4 or higher messages (that is, KERN_WARNING or more severe) get logged to the console. For an explanation of what the various values mean, look in /usr/src/linux/include/linux/kernel.h, at the KERN_XXX defines. The values they're defined to are the numbers you'd use in the dmesg command.

[root.veg]

That makes sense. I'll try it today!

[bastard23]

root.veg,
Another thing is to look into your syslogd (man 8 syslogd) and iptables configurations. Especially your /etc/syslog.conf (man 5 syslog.conf) file. There you can configure what log messages go where. Then use the --log-level option of iptables to say what level it goes to. I'm not positive, but iptables probably defaults to the "kern" level. I suspect that your syslog configuration has kern.* going to /dev/console.

bkwaz,
Thanks, I didn't know dmesg did that. What distros set this? Debian doesn't (quick grep of my init scripts).

Thanks,
chris

[bwkaz]

I know Mandrake does it. My version of LFS does it, but only because it was logging KERN_INFO messages to the console by default, which got annoying until I looked through my Mandrake init scripts and found how it turned that stuff off. So LFS by default does not do it.

I don't know about any others. I would have thought they would do it, but guess not. Hmm.

[Mr_Rage]

I've been having the same probem since I upgraded from Red Hat 7.0 to 7.3 (moved from ipchains to iptables). At first I thought it was syslogd logging messages of a certain severity to the console so I played with syslog.conf changing settings until nothing should have been routed to the console. Now I've discovered that even with both syslogd and klogd not running, the iptable log messages still get displayed to the console. If syslog isn't running, what's logging this stuff?

One more thing. On stopping syslog, I notice that a minilogd process comes to life but no one I talk to knows what it is. It also tends to die when syslog is brought back up. I tried killing minilogd but the messages are still logged to the console so it can't be the cause either.

Any thoughts?

Rage.

[bwkaz]

No idea, but if I was forced to guess I'd have to say it's something RedHat-specific...

Does using dmesg -n <some number> help at all?

[Mr_Rage]

dmesg -n (value greater than five) did the trick.

Still unsure what was logging the info to the screen when syslogd and klogd aren't running. Looked a little more at minilogd. Apparently it's a simple logger that is brought up to log system/kernel messages in place of syslogd to hold the messages until syslogd comes back on the scene to process them.


Since Syslogd, Klogd and Minilogd aren't responsible for logging messages to the Kernel Ring Buffer, I'm assuming that this is something built into the kernel itself. Setting the value of dmesg -n <level> must determine whether the kernel outputs it to the console as well. - no other processes/deamons involved.

There's not a lot of info on this stuff out there. I've looked at a couple of so called "Administration Guides" and they just skim over the whole topic.

[bwkaz]

Oh, yeah, that is a definite possibility. The kernel does control all the VCs, after all, and it knows which one is current. Didn't even think of that... :)