It is understod *now* but was not then. As in my other post this is ONLY an issue for me in the limited circumstance of reinstalling a system without having access to cut off the phones somehow during install. There may be ways to integrate and incorporate these two or maybe it's best they stay as they are. The biggest issue here imo was just one of knowing. To that end I made my suggestions above how I think can improve it.I think what is being misunderstoop is that fail2ban will ban any ip it can identify by the regexes in
in my case
failregex = ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Registration from '[^']*' failed for '<HOST>\d+)?' - (Wrong password|Username/auth name mismatch|No matching endpoint found|No matching peer found|Not a local domain|Device does not match ACL|Peer is not supposed to register|ACL error \(permit/deny\)|Not a local domain)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Call from '[^']*' \(<HOST>:\d+\) to extension '[^']*' rejected because extension not found in context
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Host <HOST> failed to authenticate as '[^']*'$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s No registration for peer '[^']*' \(from <HOST>\)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Host <HOST> failed MD5 authentication for '[^']*' \([^)]+\)$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Failed to authenticate (user|device) [^@][email protected]<HOST>\S*$
^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s hacking attempt detected '<HOST>'$
^(%(__prefix_line)s|\[\]\s*WARNING%(__pid_re)s:?(?:\[C-[\da-f]*\])? )Ext\. s: "Rejecting unknown SIP connection from <HOST>"$
So if and ONLY if you have a host that violates any of those rules for 'maxretry' times in any 'findime' period they will be banned for 'bantime', that is very simply just how it works!!
So as Ward said if your clients are doing ANY of that, they plain shouldn't, a valid extension needs a valid password,if they have that then NONE of those regexes could possibly match, NO?, the only solution is to add anything that misbehaves ( or preferably their underlying CIDR) either to the ignoreip= line OR PREFERABLY and this is as I have said CRITICAL, "ALLOW" them in a part of iptables BEFORE the fail2ban chains, so if TM3 or CSF or your personal IPSET rules preceded fail2ban and has "ALLOWED" that host, then fail2ban will never see it so will never ban it., The same of course goes for every other jail you enable in fail2ban.
(CSF/LFD are well worth looking at, if you like the extra protection then just start TM3 and THEN fail2ban in /etc/csf/csfpost.sh and stop them in /etc/csf/csfpre.sh, it will be seemless, no harm and no foul, it will just simply reorder your ipchains in a sane fashion)
If you don't like CSF/LFD then just make sure TM3 is started BEFORE fail2ban, Ward assures us that is really good, and so is fail2ban, but if you have anything that is really bad then fail2ban will likely catch it if TM3 misses it
@Lonnon: Did you modify the jail settings for bantime and ignoreip in the correct whitelist file for Issabel??One reason I can't don't use Issabel: It has it's own Fail2Ban and the one we are used to is not honored when the jail.conf is updated with the IP of your computer.
Wazo Honors it but is so confusing to do ANYTHING in unless you are REALLY into IT or Telephony as a career, then it is probably as simple as Pi. Although Pi is not simple, it's neverending (3.14159..........)
If PBX was my day job perhaps but I'm neither capable of contributing much (I'm far from even "power user" let alone any sort of expert) nor am I flush with time. I hear you about the maintenance and it's not trivial for sure - don't think I'm blind to that .We've tried a wiki before. For whatever reasons, 99% of folks prefer to ask their question and get a prompt reply. I'm not saying it's a bad idea, but someone has to create it AND maintain it. Are you volunteering?
Hello,The whole purpose of Fail2Ban is to block those who make unsuccessful attempts to log into SIP or web resources. If this is that frequent a problem and you've whitelisted the IP addresses, then perhaps you should just turn off Fail2Ban. The firewall will block strangers from attacks anyway.
Well, most of the time it =doesn't= get in the way. I have Fail2Ban running on 4 boxes right now, each doing different things, and it performs well and as it should. Your particular scenario may just be something that doesn't agree with Fail2Ban...But seriously, what's the purpose of fail2ban if it keeps getting in the way?