Fail2ban questions

(Moussa) #1

I have few questions about the default fail2ban setting in FreePBX 14 which look like below:

 #Fail2Ban filter for asterisk authentication failures

 # Read common prefixes. If any customizations available -- read them from
 # common.local
 before = common.conf


 _daemon = asterisk

 __pid_re = (?:\[\d+\])

 iso8601 = \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d+[+-]\d{4}

 # All Asterisk log messages begin like this:
 log_prefix= (?:NOTICE|SECURITY)%(__pid_re)s:?(?:\[C-[\da-f]*\])? \S+:\d*( in \w+:)?

 failregex = ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Registration from '[^']*' failed for '<HOST>(:\d+)?' - (Wrong password|Username/auth name mismatch|No mat$
        ^(%(__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) [^@]+@<HOST>\S*$
        ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s hacking attempt detected '<HOST>'$
        ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s <HOST> tried to authenticate with nonexistent user.+$
        ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s <HOST> failed to authenticate as.+$
        ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s Request from '[^']*' failed for '<HOST>:\d+' .+ No matching endpoint found$
        ^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s SecurityEvent="(FailedACL|InvalidAccountID|ChallengeResponseFailed|InvalidPassword)",EventTV="([\d-]+|%(i$
 # These WARNINGS do not have a file attribute, as they're generated dynamicly
        ^(%(__prefix_line)s|\[\]\s*WARNING%(__pid_re)s:?(?:\[C-[\da-f]*\])? )[^:]+: Friendly Scanner from <HOST>$
        ^(%(__prefix_line)s|\[\]\s*WARNING%(__pid_re)s:?(?:\[C-[\da-f]*\])? )Ext\. s: "Rejecting unknown SIP connection from <HOST>"$

 ignoreregex =

 # Author: Xavier Devlamynck / Daniel Black
 # Update: 2016-05-10 by
 # - Detect PJSIP Scans
 # - Detect AMI events that may be missed by having SecuritEvents disabled
 # - Support WSS
 # General log format - main/logger.c:ast_log
 # Address format - ast_sockaddr_stringify
 # First regex: channels/chan_sip.c
 # main/logger.c:ast_log_vsyslog - "in {functionname}:" only occurs in syslog

I am not an expert so I am seeking some help here:

Thanks for your input.


There is no reason for your PBX to EVER listen on TCP/5038 outside your localhost.

(Moussa) #3

Thank you @dicko, the reason I asked about TCP/5038 is because this article here I tought if the FreePBX is open to the internet then the AMI is also open to the internet? does not mean any IP?

This is the default setting in /etc/asterisk/manager.conf:

; AMI - Asterisk Manager interface - Generated at 2019-10-10T20:27:03+00:00
; FreePBX needs this to be enabled. Note that if you enable it on a different IP, you need
; to assure that this can't be reached from un-authorized hosts with the ACL settings (permit/deny).
; Also, remember to configure non-default port or IP-addresses in amportal.conf.
; The AMI connection is used both by the portal and the operator's panel in FreePBX.
; FreePBX assumes an AMI connection to localhost:5038 by default.
enabled = yes
port = 5038
bindaddr =
displayconnects=no ;only effects 1.6+

secret = secret
read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
writetimeout = 5000

#include manager_additional.conf
#include manager_custom.conf


My understanding is that yes, the distro leaves that port open to the internet. This in my humble opinion is not a good choice


Change your bindaddress to, It wont be overwritten by a FreePBX reload

(Moussa) #6

I see the statement saying “FreePBX needs this to be enabled” and I was wondering what damage (benefit vs harm ) it cause by turning it off enabled = no?! I use the system mainly to make calls


you will have quote that reference, it is likely wrong, yes it needs to be enabled, but no, not for anything outside your network.

(Moussa) #8

Done. Created snapshot, and changed the bindaddress to

Thanks again @dicko

(Aaron) #9

Only open ports you actually need. And block everything else. Run on non standard higher ports if you truly need something open to the world. Lets say you leave UCP open. Eventually a vulnerability will come out. Running UCP on a non standard higher web port means that the auto injection scripts which scan and attack that specific vulnerability wont work without knowing which port its on. Dont be low hanging fruit.

(Dave Burgess) #10

The comments in the file basically say everything that was just said.

Asterisk Management Interface is a “kind of” API that can be used for lots of automated tasks. It is really powerful, which is also why the username/password combo is backed by an address specific ACL. This way, if you do need an AMI process running somewhere else in your network, you can lock that user down to a specific IP.

You do need AMI, but how you open it to your world is your choice. Also, if you are running behind a NAT, you would never open 5038 outside your local network and never forward 5038 from the router to the machine.

Like most other powerful features of Asterisk, the use of 5038 comes with great responsibility.

(Moussa) #11

Thank you for the explanation, Dave. I believe that I have three users: admin (in /etc/asterisk/manager.conf), cxpanel and firewall (from the GUI). Although I have one FreePBX server, I feel that the passwords for cxpanel and firewall users are the same across all freepbx servers (they seem to have specific pattern)

  • My question is, if I change the passwords in the GUI or the /etc/asterisk/manager.conf to make them stronger do I need to make changes anywhere else? my plan is to avoid situation similar to this one Fortigate exploit .
    (For example for the extensions, if the secret is changed in the GUI then I need to change it in the endpoint / the phone)

(Dave Burgess) #12

There are a couple of caveats, but yeah.

  1. The passwords for the automated tasks run on the local server (unless you’ve moved them), so someone getting onto your server and reusing that username and password to get into AMI is remote. Not undoable, but remote.
  1. With cxpanel and the firewall, I don’t know that there’s a way to change the manager password for those processes that you can easily access or that would survive an update. TBH, I’ve never looked, because if someone has CLI access to the server (either as root or as the Asterisk user), your problems are much bigger than someone being able to pull the information.

(Moussa) #13

Thank you, Dave, for sharing your input.

I downloaded FreePBX 14 iso and install it on a VM and I can confirm that the passwords for cxpanel and firewall users is NOT secret. They were the same for both my production and VM FreePBX servers.

I agree that the risk of unauthorized access to FreePBX from LAN is low but better be safe than sorry. We know that such incidents have happened in the past and can happen in the future. In the Fortigate exploit example, hackers were able to access LAN net and from there they were able to crack the provisioning services. By having the same Asterisk Manager Interface users and passwords across all FreePBX server, hackers do not have to guess or crack any password and the step by step on how to make SIP calls using AMI is outlined publicly

  • My plan is to change the passwords for AMI users admin, cxpanel and firewall to make them stronger.
  • Also, I appreciate if someone can tell if the current FreePBX fail2ban regex are able to recognize failed AIM login / calls attempts?

Appreciate anyone’s thoughts.

(Lorne Gaetz) #14

cxpanel and firewall AMI users are locked to localhost with access control lists. There is no possibility of access from LAN for these users: