Fail2Ban & Securing PBX behind router with port forwarding

freepbx
configuration
Tags: #<Tag:0x00007f70206f7e98> #<Tag:0x00007f70206f7c90>

(Jklin) #1

I am considering exposing my PBX extensions to the internet to allow offsite-colleagues to remotely register their softphones and make&receive calls.

The PBX is running in our small office, which uses a router (specifically AVM FritzBox) to connect to the internet. To make extensions accessible, I would need to create a port forwarding for SIP registration (port 5060) and RTP (e.g. 10000 - 10250).

At the same time, I am concerned about being hacked/hijacked and would appreciate feedback on the following:

  • Fail2Ban seems like a must to slow down and prevent brute force attacks. However, with port-forwarding, will fail2ban not block my router rather than the actual intruder’s IP?
  • would it be advised to also change the default 5060 port to the outside world, e.g. rather than 5060 (router) to 5060 (pbx) use 5555 on the router, but leave 5060 on the pbx? Is that a good or a bad idea?
  • I would perhaps want to block outgoing calls to cost-intensive numbers (e.g. premium numbers, certain countries, …). Is there a way to configure call routes so that these numbers can be dialed, but require a pin code to authorize?
  • I would not expose my admin UI or ssh to the internet

Any other suggestions for added security?


(Nexar) #2

Fail2Ban is a must, yes, however it won’t ban your router IP as the connections from public internet still carry their source IP as part of the packet that reaches your PBX server, and is what will be used for blocking.

That being said, it would be safer to allow your offsite devices to vpn into your network. That way no port forwarding is required, nor is anything exposed to the internet other than your vpn listener which you can secure with certificates and key pair.

If you forgo the VPN route;

You can change the port, it’s not a bad idea, but will make setting up endpoints a little more inconvenient unless you provision with Endpoint Manager. Not an issue though.

I’d suggest enabling ssl for your offsite connections at the very least.

Look under outbound routes, there’s a “Route Password” option you can set for outbound routes. You will have to split outbound routes - one that accepts local format calls making use of dialing patterns that match local numbers, and another dialing plan for international. The international dialing plan is the one you set the pin/password for that staff have to enter before the call is allowed to proceed.


#3

It’s a good idea to use a non-standard port, but SIP has port numbers in various headers, so forwarding external 5555 to internal 5060 won’t work. Change the PBX port number to 5555 and forward external 5555 to internal 5555. Unfortunately, this requires changing the port number to which your internal extensions register.


(Jklin) #4

Great feedback - thanks.

I found our VPN solution to be not reliable enough. It seems to drop/disconnect throughout the day several times without the user noticing - not too bad if they are just accessing intranet-websites and simply re-connect, but not acceptable if they are missing calls that way.


(Jklin) #5

Ah, ok - I did not know that.

A little more complicated, but certainly doable. Is there a central setting in FreePBX to change the default 5060 port or do I need to do that per extension?


(Nexar) #6

Go to Settings->Asterisk SIP Settings->SIP Settings[chan_pjsip]

Look for “Port to listen on”.
While there, set your TLS/SSL up to secure the connection.


(Lorne Gaetz) #7

This is true, but there was a router exploit floating around a year or so that allowed malicious access to your internal LAN by proxying thru the router, in which case it would appear that your router IP is doing the hacking.


(Moussa) #8

Keep the PBX locked. Use Find Me/Follow Me to send incoming calls to external (cellphone) numbers. Use the VPN for outbound calls. Once the phone is unlocked, phone app in the foreground and connected it is less likely to disconnect during active calls.


(Jklin) #9

Sending incoming calls to external / cellphone numbers is an issue in two ways: (a) the cost of forwarding to a cell-phone - could be managed if it was the only issue and (b) the limit of concurrent calls we can make - currently 3 and no way to increase that - means an incoming call forwarded externally uses 2 calls/lines and the next incoming call cannot be forwarded any more.


(system) closed #10

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.