banip not working anymore about fail2ban HOT 10 CLOSED

Run the banip command "maxretries" times.

On 4/14/12, slacks42
[email protected]
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

from fail2ban.

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

from fail2ban.

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 :-)

from fail2ban.

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

from fail2ban.

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

from fail2ban.

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.

from fail2ban.

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

from fail2ban.

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. :-)

from fail2ban.

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

from fail2ban.

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

from fail2ban.