FreePBX Responsive Firewall 13.0.24 not detecting attacks

I have the firewall version 13.0.24 installed.

My logs are full of anonymous sip attacks trying to call random numbers which are rejected.

The IP addresses change often, but many attacks are from the same IP. In some cases there are many attempts from the same IP, but no attackers are being rate limited or blocked by the Responsive firewall.

I have resorted to manually blacklisting the CIDR range of persistent attackers and this has calmed things down a bit, but the attempts keep coming.

What should I be looking for to diagnose or fix this?

I think “fail2ban” helps you more.
Please change default SIP/PJSIP port (5060) and SSH (22) too, and use stronger passwords.

are you allowing anonymous sip callers in the sip settings? if so, turn it off. and in the chan sip setting make sure you have sip guests off

How do you change the ports please? I’ve been having similar problems to OP.

Follow issue reported here:

1 Like

Settings–> Asterisk SIP settings---->chan SIP settings or chan PJSIP settings

you can change “Bind Port”

1 Like

Thanks for the input,

I do, of course, have fail2ban installed already. I understand it works in tandem with the Firewall.

I cannot change the main listening SIP ports for Asterisk as we are connected to external providers. Remote peers are on different ports and SSH is also different.

We have no issues with passwords and no-one has successfully hacked the system, but there are many brute-force attempts to do so on SIP which we want to at least rate limit or preferably stop entirely after a FEW unsuccessful attempts.


This would stop inbound SIP calls from my external DID providers (who do not register) and it is not the required solution. I am trying to get the firewall to work properly.


Thanks Lorne,

Your issue is about Fail2Ban not honouring the “DISABLED” status of Responsive Firewall.

My issue is the reverse, in that my Responsive Firewall is “ENABLED” but does not seem to be registering, rate limiting or blocking any attackers.



Actually it’s quite easy to change the “mail listening ports” for SIP, just add iptables PAT rules to redirect the (presumably limited) hosts/networks for your VSP’s that can’t be changed from 5060/1 to your preferred and less blatantly attacked new ports, where you should safely do that with the “responsive firewall” set of iptables would be a question for the author.

Just be careful if you do this if you have external inbound telephone numbers, it will prevent external DID providers from connecting to your system. Most providers will connect on port 5060.

The recommended settings for Asterisk is to NOT Allow anonymous sip calls (NO) in Sip Settings and ALLOW Guest Calls (YES) in Chan SIP Settings.

Allowing guest calls but rejecting the Anonymous SIP calls will enable you to see the call attempts and debug incoming calls that may be mis-configured and appearing as guests.

The Responsive Firewall (which is the case in point) is supposed to monitor unauthorised connections and ban any repeated unsuccessful attempts. This is what I am trying to get functioning correctly rather than changing the default SIP settings.

You can use a Session Border Controller like Sangoma SBC.

Perhaps you miss the point of the pnat rules, ONLY your providers will be redirected, every one else gets effectively “dead-air”

I am sorry, you are right - I don’t understand.

If we redirect port 5060 using pnat to say port 5600, how does that prevent an attacker from entering my system on the new port 5600, if their packets arrive on port 5060?

If my service provider also connects on port 5060, what benefit does redirecting him to port 5060 have?

Very simply, I am trying to get the Responsive firewall to detect intrusion attempts and then blacklist the source IP.

You don"t, you port translate (no ip address translation) port 5060 only for your vsps to 46578 which is the port sip is bound to on your box. You can have port 46578 wide open on your firewall, there will be very few sip attacks against it :slight_smile:

Thanks again for this.

I am obviously missing something… If I port forward 5060 to [something else] then how can I do this > only for your vsps

AFAIK, everything outside my network uses port 5060 for SIP, including my ISPs and every chinese hacker. So even if I write a rule in iptables such as:

iptables -t nat -I PREROUTING -p all --dport 5060 -j REDIRECT --to-port 46578

…then everything arriving on port 5060 just gets forwarded to a different port. Are you suggesting I include -src ? If so, I would have to do this for every VSP and how would it deal with dynamic IP connections from mobile users?

Also, would the FreePBX Firewall and Fail2Ban know how to handle this?

Sorry if I am being a bit slow…

I am sorry psdk, I have no idea what a session border controller is - but it sounds expensive!

I would much rather just get the FreePBX firewall working as advertised :slight_smile:

Yes you include src hosts and/or networks in those rules. Few vsps will be more than a dozen many just one. Many allow you to change 5060 at source.

You already said you changed the ports for the extentions, now they can all traverse the firewall on your chosen registration port which is of course open to the world.

fail2ban is a set of chains designed to run after your main iptables these port translations should run early in the INPUT chain hence ny suggestion that you ask the author where. I can’t yet use that firewall on my chosen os so can’t advise.

A new version of Firewall was published last night, 13.0.26. I have started from scratch and have confirmed that responsive firewall works as expected:

  1. You need to ensure that your public interface(s) are set to external
  2. Ensure that responsive is enabled as well as the individual protocols you are using are enabled
  3. Check Services, Services and ensure the responsive protocols you’ve selected are marked as being managed by responsive
  4. Ensure that the IP address you are using to test with is not listed in Status, Registered Endpoints, known hosts shouldn’t be blocked
1 Like

Thanks for that. I understand now.

As the interaction with the firewall is unknown I will leave this for now, and await the update to the firewall 13.0.26 which Lorne has mentioned below, to see if that resolves the issue.

Many thanks for your help.