System Admin module and Intrusion Detection

I’ve got my FreePBX Distro set up, but the Intrusion Detection doesn’t seem to be banning an address which clearly should be banned. It’s detecting the “Wrong Password” attempts and logging them, but the IP address has been trying to brute force a SIP login for hours, and it’s not being banned.

I’m not 100% sure I’m understanding the Fail2Ban setup, but here’s how I see it, and I feel like I might be missing something. First off, here’s the (sanitized) offending login attempt:

[2014-06-16 10:08:21] NOTICE[1884] chan_sip.c: Registration from '"108857" <sip:[email protected][my.public.ip.address]:5060>' failed for '[script.kiddie.address]:5130' - Wrong password

I have thousands of these attempts in my logs. The first regex in /etc/fail2ban/filter.d/asterisk.conf is:

NOTICE.* .*: Registration from '.*' failed for '<HOST>:.*' - Wrong password

which should be flagging that log message. However, looking through the config, the file /etc/fail2ban/jail.local contains the following section:

enabled  = true
filter = asterisk-security
action   = iptables-allports[name=SIP, protocol=all]
                   sendmail[name=SIP, [email protected], sender=]
logpath  = /var/log/asterisk/fail2ban

which would appear to be using the /etc/fail2ban/filter.d/asterisk-security.conf. I don’t see an expression in asterisk-security.conf that would catch the logfile message from my would-be attacker. Should the jail.local contain an additional section that references /etc/fail2ban/filters.d/asterisk.conf? It looks like the system-admin GUI is intentionally creating both files.

Admittedly, I could be missing something. I’m not a fail2ban expert. Could it be as simple as putting an include in asterisk-security.conf? Is there some other reference that should be invoking what appears to be a correct regex?

I’m going to try a few things out, but if this is in fact a bug, and I hand-edit the file, it’s likely to be overwritten in the next update. I haven’t put this server into production yet, but I’ve got a lot riding on it, so I’m trying to be thorough. :smile:

Thanks in advance for your time and attention!


First Question… do you have a

It looks as if the jail.local.rpmnew correctly references “filter = asterisk” but the jail.local has been changed to “filter = asterisk-security,” likely when I used the system admin module to customize my values. Does this sound correct and/or reasonable?

Yes, the NOTICE message I quoted was from that /var/log/asterisk/fail2ban

Here is the full error from /var/log/asterisk/fail2ban:

[2014-06-16 10:07:31] SECURITY[1794] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="1402927651-118514",Severity="Informational",Service="SIP",EventVersion="1",AccountID="100955",SessionID="0x7f56a40ede68",LocalAddress="IPV4/UDP/{my.public.ip}/5060",RemoteAddress="IPV4/UDP/{script.kiddie.ip}/5106",Challenge="1b248a1c"
[2014-06-16 10:07:31] NOTICE[1884] chan_sip.c: Registration from '"100955" <sip:[email protected]{my.public.ip}:5060>' failed for '{script.kiddie.ip}:5106' - Wrong password
[2014-06-16 10:07:31] SECURITY[1794] res_security_log.c: SecurityEvent="InvalidPassword",EventTV="1402927651-233416",Severity="Error",Service="SIP",EventVersion="2",AccountID="100955",SessionID="0x7f56a40ede68",LocalAddress="IPV4/UDP/{my.public.ip}/5060",RemoteAddress="IPV4/UDP/{script.kiddie.ip}/5106",Challenge="1b248a1c",ReceivedChallenge="1b248a1c",ReceivedHash="f1e3247221d0bedf595194b9741299ec"

So even though the regex in /etc/fail2ban/filter.d/asterisk-security.conf doesn’t catch the second line, the regex:

SECURITY.* .*: SecurityEvent="InvalidPassword".*,Severity="Error",Service="SIP".*,RemoteAddress="IPV[46]\/(UDP|TCP|TLS)\/<HOST>\/[0-9]+"

should absolutely be catching the third line, and that one is in the asterisk-security.conf file.

So I don’t think it’s necessarily a problem with the jail.local file. The regex should be catching, and it’s not. Is there anything else I could be looking at?

Just because you’ll probably ask for it: :smile:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-FTP  tcp  --  
fail2ban-PBX-GUI  tcp  --  
fail2ban-BadBots  tcp  --  
fail2ban-SIP  all  --  
fail2ban-SSH  tcp  --  
fail2ban-recidive  all  --  

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-BadBots (1 references)
target     prot opt source               destination
RETURN     all  --  

Chain fail2ban-FTP (1 references)
target     prot opt source               destination
RETURN     all  --  

Chain fail2ban-PBX-GUI (1 references)
target     prot opt source               destination
RETURN     all  --  

Chain fail2ban-SIP (1 references)
target     prot opt source               destination
RETURN     all  --  

Chain fail2ban-SSH (1 references)
target     prot opt source               destination
RETURN     all  --  

Chain fail2ban-recidive (1 references)
target     prot opt source               destination
RETURN     all  --  

OK, could it be this simple? In the sysadmin module, I had my whitelist as:

I changed it to:

and the ban shows up immediately.

I suppose if my whitelist is formatted incorrectly, it would be a problem. Perhaps a suggestion then: put something in the help balloon for sipadmin specifying the IP address format it’s expecting. I work a lot between Windows, Linux and BSD, and it’s pretty easy to lose track of what flavor of IP address notation is expected in a given situation… :blush:

At any rate, if it was just that simple, then lesson learned…

I dont think its using is the problem. It really feels to me that fail2ban just was not running. Change your subnet back and test.

Nope… changed it to /, and our wily German friend was right back at it. Changed it back to /16 and he was immediately banned again.

If did try restarting many times before. If it’s supposed to be accepting /, it would appear that it is not. Fortunately, I’m good with my subnetting, so long as I keep with a 16-bit mask. :laughing:

Ok thanks. Can you open a bug report so we can update the help menu and sanitize the input for other users.

Done and done. Issue #146. Thanks!