John, you have been a tremendous amount of help. I am posting my reply to the list as well as direct to you because your answer may be of benefit to the list members and the question I pose may also be of significance John Andersen wrote:
On Tuesday 17 July 2007, Richard Creighton wrote:
I am wondering if you know if that is even close to your recommendation....or should I try 60 instead of 120 or is that even an equivilent field. Or like me, is that so obtuse that you too do not know the answer and would be guessing as did I when I tried to set it up :) ??
If you look at the times Jul 17 00:38:27 raid5 sshd[625]: Invalid user staff from 83.18.244.42 Jul 17 00:38:32 raid5 sshd[628]: Invalid user sales from 83.18.244.42 Jul 17 00:38:37 raid5 sshd[630]: Invalid user recruit from 83.18.244.42 Jul 17 00:38:42 raid5 sshd[632]: Invalid user alias from 83.18.244.42 Jul 17 00:38:48 raid5 sshd[634]: Invalid user office from 83.18.244.42 Jul 17 00:38:53 raid5 sshd[636]: Invalid user samba from 83.18.244.42
You see that they are around 5 seconds beteeen each attempt.
Therefore your 3 in 120 should have started blocking after the 4th connection attempt.
But it didn't, that's why I think your firewall is not honoring this setting at all, which is what I mentioned in my first post.
It is possible that your version of the kernel does not have "recent match" support turned on.
This is a feature that not all kernels have. Explained here: http://snowman.net/projects/ipt_recent/
To see if this is in your kernel type this as root in a shell iptables -m recent --help
That should give a lot of help text which ends with " ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>"
If it says "Couldn't load match `recent' ..." then you don't have recent match installed.
This is what the last line says, once I found it in /usr/sbin as root: ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/ I also found this when I dumped the contents of my IPTABLES with sudo /usr/sbin/iptables -L > iptables.txt and extracted what I think pertains to the settings I *used* to have. For some reason (maybe I have to reboot ----nah, this is Linux but I must have to do something I forgot) the settings didn't take. I used to have settings of 5 and 300 instead of 3 and 120 but the numbers stood out. I don't know where the limit: avg 3/min burst setting comes in. LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh state NEW recent: CHECK seconds: 300 hit_count: 5 name: ssh side: source LOG level warning tcp-options ip-options prefix `SFW2-INext-DROPr ' DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 300 hit_count: 5 TTL-Match name: ssh side: source
But in any event, I don't believe its being honored. What I'm wondering is if it *is* being honored as far as the hacker is concerned, ie, he is not getting past the 'DROP', but because of the LOG setting, I am still getting notice???? Does that seem plausible to you and if so, can you think of a way to test it?
Thanks again, Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org