On Tue, 2004-03-09 at 17:02, Michael Kearey wrote: > Don Levey wrote: > > The man page is my friend. I am somewhat less confused than before (I > > hope). ... > I tell anything kernel* level of syslog to be logged in a file > /var/log/kernelmessages in /etc/syslogd.conf by modifying the kernel* > line - > > kern.* /var/log/kernelmessages > > I think I've got it now. I've set that in my syslog.conf. I've also gotten messages from it (below). > I then use a rule like: > > -A RH-Lokkit-0-50-INPUT -s 61.78.0.0/16-j LOG --log-level debug > --log-prefix "IPTABLES-REJECT: " --log-ip-options --log-tcp-options > > There are other ways to acheive a similar thing BTW, by using a local > unused syslog level perhaps. > > Logging from iptables also tends to generate a big log file, so it may > be helpfull to -m limit --limit 5 --limit-burst 10 as well. This > will help prevent monster log files... That I'm not overly worried about. The explicit blocks are a small and select group pf spammers that don't seem to take no for an answer. Most I keep in my access files for sendmail, but two in particular (hanmail.com and hinet.net) I want to block from even getting at the server. This is the firewall on the mail server itself; the rest of the network is otherwise protected by another firewall. Interestingly, shortly after I enabled these logs, I'm noticing two logged block messages. However, they are from addresses I didn't think I was blocking. The addresses in question are: 218.9.130.252 218.72.107.86 but the only rule I have that's even close is: -A RH-Lokkit-0-50-INPUT -s 218.148.121.0/8 -j LOG --log-level WARN --log-prefix IPTABLES-REJECT-09- --log-ip-options --log-tcp-options -A RH-Lokkit-0-50-INPUT -s 218.148.121.0/8 -j REJECT (I've added numbers to the prefixes for debugging purposes, but so far I haven't logged another message). I would imagine that these messages wouldn't be from the rules above, as the addresses don't match. However, the overall blanket blocks at the end aren't logged, and the outside firewall seems to log other accesses to that server which are *not* getting logged but are also not on permitted ports (in particular, 135). Any thoughts? -Don
