02.11.2010 00:11, Yaroslav Halchenko пишет:
Hi Renat,
On Mon, 01 Nov 2010, Renat Sabitov wrote:
After futher investigation I found that all this issue was just my
fault of fail2ban misconfiguration. I wrote "banaction" instead of
"action" and my jail worked as tcp multiport instead of all protocol
filter.
Hm... I am sorry but I am a bit confused... Is that correct:
before you had following situation: iptables-multiport used for banning
which did not actually ban the IP, thus you were receiving consecutive
'already banned' (due to banning being ineffective due to misspecified
port) and 1 second sleeps after each new "ban".
The situation was exactly as you wrote :)
According to that code review, it seems to remain that fail2ban
sleeps for 1 second after each new ban action, which might be undesired
if there is a flood of attempts; thus might need an improvement to
provide timely banning if illegal attempts are "concentrated in time"...
or am I wrong?
It sleeps for 1 second only if __checkBan returns False, which happens
if there is no tickets in queue or "already banned" error occured. There
might be protection against flood somewhere else in code, I'm not sure.
However there haven't been more "overload" of fail2ban after correction
of jail rule.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
