Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to defend my server (Ubuntu Lucid 10.04) from some brute force ssh attacks by configuring the iptables. I want to log the matches to DROP rules, but it wasn't working, so I tried the very basic:

iptables -A INPUT -p tcp --dport 22 -j LOG --log-level info --log-prefix "TEST: "

But it doesn't log anything! I tried changing the log-level: debug or 7 and adding kern.=debug -/var/log/firewall to /etc/syslog.conf but nothing gets written to/var/log/messages or /var/log/firewall

The rule does get some matches:

$ iptables -L -v
pkts bytes target     prot opt in     out     source               destination
44  5543 LOG        tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh LOG level debug prefix `TEST: '

iptables logging not working has a solution to update rsyslog to a newer version. However according to this source "this solution is messing with the default logging system"

Does anybody know a better solution?

If not, I could try updating rsyslog (compile from source), but how can I revert to the default rsyslog if it messes things up?

EDIT: rsyslog drops it's privileges, so it can't read /proc/kmesg. This should be solved in newer kernels but unfortunately, I'm stuck on 2.6.18.

"the fact it doesn't read kmsg on older kernels is DELIBERATE and will not be fixed."

I tried to let rsyslog keep it's root privileges, by altering /etc/rsyslogd.conf

$PrivDropToUser root
$PrivDropToGroup root

But that doesn't work either, which confuses me. Why can't this root process read a file root owns?

share|improve this question
If you switch your rule to just iptables -A INPUT -p tcp -j LOG do you see any logging? – slillibri Jun 5 '11 at 12:22
Nope, nothing. All messages do show up in $ dmesg though – floorish Jun 5 '11 at 14:03
What version of rsyslog are you running? When I added the above rule into a default Debian stable system, it logged to kern.log as expected (using rsyslog 4.6.4-2). – slillibri Jun 5 '11 at 16:03
rsyslogd 4.2.0-2ubuntu8, Ubuntu 10.04 2.6.18-028stab089.1. /var/log/kern.log shows kernel: imklog: Cannot read proc file system, 1. – floorish Jun 5 '11 at 17:45

You could install fail2ban and configure the ssh jail to automatically ban the IP addresses that are attacking your server based on the messages that sshd puts in the logs. This is a fairly standard way of doing what you want.

If you haven't already done so you should disable root logins via ssh as well as enabling and using key based authentication.

share|improve this answer
The iptables config works, just the logging doesn't, so I don't really need another third-party package. Root login is disabled and key authentication is required of course ;) – floorish Jun 5 '11 at 17:14

You're setting log-level info, but, your syslog config is outputting log-level debug. Either change syslog to output or your iptables rule to output to log-level debug to match your ruleset config.

share|improve this answer
I tried that already, but by default it should write to /var/log/messages (without the kern.=debug). Doesn't work unfortunately.. – floorish Jun 5 '11 at 12:24

Your Answer


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.