Dear PBXs
I Have a FreePBX in the cloud (digital ocean), and it’s working with SIP UDP fine, but I’m worried about security. So I’m thinking of moving SIP TLS and wanted advice.
How important is it to encrypt the Sip signal?
Is it okay If I encrypt the sip but not the RTP?
What risk will I face if I don’t do it?
The chance of penetration will go down by many orders of magnitude using TLS over UDP:5060 , encrypting the media is needed if you suspect there are bad actors inside your network that want to eavesdrop on phone calls.
Another way of approaching this question: shouldn’t this kind of traffic be encrypted by default? And how do I do about this?
In theory yes.
However, realistically speaking:
With that being said, I still believe that the using TLS/SRTP is a good idea. But as mentioned, it takes a lot of extra effort.
Not by default as there is a performance penalty, There are cheaper ways to eliminate most of UDP/5060’s insecurities, first off don’t use 5060, second off, don’t use UDP. SRTP comes also at a cost and is not needed for fraud avoidance, it just makes the ‘media’ (audio) not susceptible to MITM interception.
It is good to understand that SIP(S) only negotiates connections, after a successful negotiation, even if you don’t like it, SDP channel(s) can then be negotiated that will contains the ongoing ‘messaging’ and that will accrue cost and possibly data leaks
So basically what you’re saying is dropping udp and moving to something other than the default port number (over tcp?) is already a big step in securing the system? Any other benefits? Stability in connection and keeping connected maybe?
Pretty well, I’ve been saying that for years, any one who tries it will only but agree, ask them 
Now, TCP is a little heavier as it is not connection-less, TLS, which is kindaTCP on steroids, needs your extensions to connect to a name that is successfully certified , IP only connections will fail, so way more robust but a little more process intensive.
(Currently there are over 200000 IP’s in the various blacklists that are known to have been probing UDP/5060, I have never seen even one bogus connection succeed over TLS, very few try TCP outside of 5000-5999)
Thanks, I’ll give tcp a try then. I have this client that often drops all extensions, so when a call comes in there’s none to connect to. I Macgyvered this by checking if there aren’t any extensions and if so, forwarding the call to a pstn line, but I wonder if tcp could solve this issue.
Remember that Asterisk is a B2BUA so calls ‘come in’ on one channel but successful bridging needs extensions available by a different process, Asterisk’s ‘routing’ should take care of redirecting calls to ‘unavailable’ extensions so not sure why you need to otherwise MacGyver anything
“The unavailable send to voicemail” wasn’t cutting it for me at the time, so that is why I went for this route. It has been working for over a year now and is something that only occurs once every few weeks. I’m open to better solutions, but I’m already hijacking someone else’s topic. Besides, I remember posting this a while back and not getting a solution that worked for me, so that’s why I did some scripting. Another great use for “Dynamic Routes”.
But if you want to give your 2 cents, my problem is that every now and then all extensions are unregistered for only a few seconds. When this occurs and a call comes in, the call could not be connected and the caller would get the unavailable dial tone. At first I thought of an unstable internet connection, but I guess that would mean other tasks would also be interrupted, tasks like my clients online CRM, but this wasn’t the case.
I would consider your case as ‘edge’, I have never had to deal with such a situation
Thanks alot for the advice,
I did, in fact, change the sip port to another one, and I stopped seeing failed attempts to register on my log.
I have no plan to use SRTP, as I’m not worried for now from MITM; I was only planning to encrypt the sip part only, but from what I understood from you. moving to TCP is actually enough to increase the security to an acceptable level
did I understand you correct?
Hay PitzKey ,
I understand your point, and Thanks for the heads up.
I had no plan to encrypt the RTP as, in my opinion, Sip is good enough to be encrypted ( before @dicko changed my mind 
)
I never used sngrep, so I guess I will need to look into it and see what it is doing
Are you aware of any case when SIP(S) becomes necessary?
Changing to a port outside 5000-5999 removes you from being stood directly in the firing line, TCP is even less targeted but TLS has much increased security at little cost over TCP.
Thanks a lot,
I did change my configuration to follow your advice.
But I think rather than encrypting the SIP and RTP; it isn’t better to make accessing the system through VPN
so debugging the system is easy, but I guess you will ask every user to install that VPN
Hey Akkilah, just wanted to give my opinion on the discussion…
Everything dicko is saying are considered ‘best practices’ for many reasons but mainly because it’s what he and many others have seen work in the security bubble of these PBX systems… Many bots literally watch and listen to large chunks of IP addresses that come from these data centers. Typically they’re checking ports 5000-15000 for your PBX and it’s "Hey, I’m a PBX’ messages that it blasts across applicable ports. After your system has been flagged as a potential target, they go into a secondary list for bad actors to run scripts. The level of sophistication on these attacks has increased by many orders of magnitude over the last 4 years alone, let alone since these standards have been codified.
The best thing to do is bury the signal as deep as you can… VPN, port obfuscation, Cloudflare domains, SRTP and TLS both over VPN would be best, along with using HTTPS on any management functions, frequent backups, securing your outside trunk and watching your logs for suspicious activity.
Can’t disagree with any of that, but If you insist on UDP, adding a rule using CONN-TRACKing to block port scanners is much easier.
Using only TLS and strict SNI checking against domains unrelated to any public facing Services will make your life far easier though and this rubric pertains to far more than just VOIP
(Adding ‘server checking’ and certs to your extensions also pretty rock solid but a real pain in the ass to do every 80days)
Super curios about this part. Adding CONN-TRACKing to what?
Your Firewall, iptables or perhaps nftables if you are ‘trendy’
Easy solution for tried and true iptables
https://configserver.com/configserver-security-and-firewall/
has it ‘baked in’
Hmm, we use quite a lot of pfsense firewalls. I’ll do some googling to see how to do this on a pfsense box (if it’s even possible).
Thanks for the pointer.