banip not working anymore

[voidzero]

I'm using fail2ban version on debian stable, version 0.8.4-SVN. For some reason fail2ban declines to ban ips with banip. If I try IP addresses that are already banned I see a warning in fail2ban.log telling me that the IP is already banned. But if I try to ban new IPs then nothing is happening, not even when I ban them multiple times.

[buanzo]

Run the banip command "maxretries" times.

On 4/14/12, slacks42
reply@reply.github.com
wrote:

I'm using fail2ban version on debian stable, version 0.8.4-SVN. For some
reason fail2ban declines to ban ips with banip. If I try IP addresses that
are already banned I see a warning in fail2ban.log telling me that the IP is
already banned. But if I try to ban new IPs then nothing is happening, not
even when I ban them multiple times.

---

Reply to this email directly or view it on GitHub:
#45

Sent from my mobile device

[yarikoptic]

yeap, and see #31 which desires a more straightforward behavior

[voidzero]

Hi, well that's the entire problem.... even when maxretry = 1, it still does not work after multiple iterations. So I'd like your suggestions to hunt this down.

It seems that addFailure is only used by banip in filter.py, could the bug be there?

I saw #31 and while it's related somewhat, it doesn't solve anything :-)

[yarikoptic]

ah -- let's reopen then ;-) although not sure if we would do anything about it unless it replicates with the current master.
Debian stable version supported only for critical security and functionality issues and this one is not one of them

[yarikoptic]

and by "not working anymore" did you mean that it was working before and stopped working now? what has changed meanwhile?

[voidzero]

Actually I'm not so sure if it ever worked. Semantics... I meant "not working even though a patch was added in the past."

I have tried to set maxretry = 1, maxretry = 2, findtime = 10, and repeatedly punched 'up, enter' so that it would add the ip manually.

Trying to trace it down. Looks like the actual action is done by addBannedIP which runs

self.failManager.addFailure(FailTicket(ip, unixTime))
return ip

ip is then returned and visible on the command line.

It looks as though addFailure (defined in failmanager.py) is only used by banip.I am not sure and can't really base it on anything solid but right now I have a feeling that ticket.py might have time issues... so if you have a second (grin) please look into that for me.

[voidzero]

Or explain a simple data flow to me so I can track it down a bit better...

[voidzero]

Finally found it. After doing 'banip', one has to 'touch $logfile'. That one triggers the actual banning. So the issue wasn't time or code but file change notification. Closing this bug... though one might want to omit the "file changed" check for banip. :-)

[ThomasCr]

Is the bug with touching the logfile fixed?
I also cannot use banip without I have to touch the syslog file...

I use v0.8.7

[ThomasCr]

hmm.. its like something else...

root@web1:~# touch /var/log/auth.log && touch /var/log/syslog 
root@web1:~# fail2ban-helper -a restore && fail2ban-client status ssh
fail2ban-helper: 5 IPs restored
Status for the jail: ssh
|- filter
|  |- File list:        /var/log/auth.log 
|  |- Currently failed: 5
|  `- Total failed:     210
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     0

I issued the commands two times, in hope is changes... but it is impossible to restore ips :(

on some of my hosts it works.. but also not every time.. thats really buggy

I am use my package from https://launchpad.net/~thomas-creutz/+archive/fail2ban