I know that you indicated that “everyone” says that you should change the default bindport, but I disagree. I do NOT recommend changing your default bindport. Doing so can create all sorts of problems, especially if your packets are going through a NAT router (which they should be and which offers far more security than changing your port). The much better approach to safety is to keep your system behind a secure firewall (that only allows packets from expected sources) and a separate NAT router (don’t forward port 5060 or open DMZ).
However, the fact that this is working fine with FreePBX 12 and NOT with FreePBX 13 suggests that FreePBX 13 may have a bug related to registration. It may not be using your custom bindport value when registering the trunk. You (or perhaps Rob since he’s been here) may want to open a bug report ticket.
While NAT does indeed provide obscurity, that obscurity also creates security. If you cannot be seen (or reached), you cannot be hacked. NAT, by its nature, prevents someone from reaching you unless you have reached out to them in the first instance.
NAT is only problematic for SIP, and not for VOIP in general. IAX, for example, has no trouble with NAT. And the obscurity isn’t the cause of the SIP/NAT troubles. Rather, its the fact that SIP includes IP addresses and port numbers in its signalling, and uses separate ports for RTP and for signalling. Most of the troubles that SIP has with NAT relate to mismatches between the IP addresses and ports included in the signalling layer with the actual IP addresses and ports that the signals come from after NAT (the IP layer).
TLS, on the other hand, does almost nothing to protect you from DDOS attacks and does absolutely nothing to prevent someone from exploiting Asterisk or system-level exploits. A properly functioning NAT prevents anyone from the outside from getting into your system on any port unless you have first reached out to them from that port.
When you combine a NAT router (which includes a firewall) with a properly functioning firewall on your PBX system, you get two layers of protection from external threats and one layer of protection from internal threats.
Changing the default signalling port from 5060 to something random adds virtually no security whatsoever. It won’t even take 5 minutes to conduct a complete scan of all available ports on your public IP address. While there are some scanners that only scan port 5060 for Asterisk systems, those scanners would never even get through a NAT, much less a firewall.
TLS and SRTP are useful if you want to have remote extensions. But, before you bother with that, why not just set-up a remote PBX and set-up an interoffice trunk with a firewall that only allows traffic from the remote PBX? And if you want encryption across that trunk, set-up a VPN between the two offices.
Any firewall without port scanning amelioration is incomplete IMHO. If you have external phones, you will need to allow incoming registration, using 5060 or anything close is foolhardy if another option is available.
Your firewall exposes a “fingerprint” to the internet and it looks like a lot more than a SIP server, modern scripts seem to look for that fingerprint before directing attacks against SIP and carefully try and keep “under the radar” , early DROP rules and ipsets can reduce your log sizes with little effort, enabling no-nome and no-script jails to fail2ban also often catches the latest “Scripts” at an early stage, look at your apache logs to see who’s calling.
I think most people will agree that your security doesn’t have to nor will ever be perfect. It just has to be more secure than the next guy’s.
I have my SIP trunk provider as the only IP allowed to communicate to and from my firewall on port 5060 and 10000-20000.
All my endpoints connect on TLS on a port outside Asterisk’s RTP range.
The smart/responsive firewall in FreePBX takes care of the junk packets - of which have been zero since enabling my setup. No random sip calls. No random login attempts.
Remote locations are on static IP’s. CIDR’s of local cellular network towers are added too. Data plans in Canada are too prohibitive to launch cyber attacks anyways. Lol
Also, @AdHominem NAT has nothing to do with accepting or rejecting packets. It is simply masquerading. There are separate rules for packets based on related or established connections.
I don’t agree with your statement that security “just has to be more secure than the next guy’s.” Network security is not the same as running away from a lion. When running away from a lion, you really only need to run faster than the person next to you. The lion’s only going to eat one of you. That’s not the case with network security, though. Hackers are more than happy to hack multiple systems at the same time.
You’re confused about NAT masquerading and how it works along with firewall rules. With respect to an inbound packet that has no entry in the NAT translation table, the NAT router will never re-write the packet and send it to your PBX. In that case, NAT blocks the packet from ever reaching your PBX by failing to forward it on to your PBX. Instead, it will present the packet to local (the router itself) and the router’s firewall will either accept, drop or reject the packet in accordance with the router’s rules. Regardless of the router’s firewall, the NAT masquerading blocked the packet from ever reaching your PBX by virtue of the fact that there was no entry in the translation table telling NAT how to re-write the packet and send it on.
Also, there can be a direct relationship between NAT masquerading and the firewall rules. Both are managed by the same linux process (Netfilter). When you allow related packets on an interface that also has NAT enabled, Netfilter will both update the NAT translation table AND open the firewall temporarily to allow the packets in.
I’m glad to see that you agree that changing port 5060 is not a necessary security protocol. I agree completely. If you have NAT and firewall rules properly configured, it is never necessary, and likely to be counterproductive since the firewall’s “related” and “established” rules recognize that port 5060, used for SIP signalling, is tied to ports 10000-20000, used for RTP packets. If you change to another port, some firewalls won’t recognize the communications as SIP and won’t update either the NAT table or the firewall to re-write/allow inbound RTP packets right away (or at all).
I have never set-up TLS or SRTP, so I don’t know as much about those features. When I started using FreePBX, neither was supported. It was easier just to setup OpenVPN.
I have about 20 roaming phones that will connect to the Cloud PBX in near future without a static IP address. Many of these phones will be used by sales people who travel a lot. I know I could have setup a VPN but didn’t really want to. I have a firewall setup on the PBX server and does a good job at stopping attacks. I have changed the port and my server has not even been scanned even once in six days. I was getting scanned and attacked a minimum of 4 - 5 times everyday on port 5060.
I know that changing your port from 5060 to a random number alone is not secure, I have a firewall that still provides the same level of protection as it did when I ran it on port 5060. The only difference is that I am not being detected by by these drive by scanners looking for SIP boxes. I was seeing attacks being blocked by my firewall everyday and now in past 6 days my firewall has detected / blocked 0
Let’s face it most of these hackers are not targeting me or anyone in particular, they are looking for the easy targets. Scan for port 5060 find a SIP box and then try all known exploits or password attack to gain access.
If an experienced hacker wanted to hack a particular IP address they would find a way to do maximum damage. I am just trying to stay below the radar.
As of right now I have tested the phone system on 7 different offices all using different firewall / routers and have not had any problems with connectivity or quality.
