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?
iptables -A INPUT -p tcp -j LOGdo you see any logging? – slillibri Jun 5 '11 at 12:22$ dmesgthough – floorish Jun 5 '11 at 14:03/var/log/kern.logshowskernel: imklog: Cannot read proc file system, 1.– floorish Jun 5 '11 at 17:45