Those that are running IDS/IPS on your DMZ-PBX, what are some of the rules you choose other than Suricata’s emerging-voip rules or Snort’s protocol-voip and Snort’s subscriber voip rules? Research suggests security problems voip faces are malware, voip phishing, DoS or MITM, etc.
After researching this a little, it appears that Snort’s protocol-voip rules are the one to use and even better is the Snort’s VRT subscriber protocol-voip rules, but as implied one need to subscribe to the free subscription. According to the emerging threats used with Suricata: VOIP Rules: A new and emerging ruleset. Small at the moment, but we expect it to grow soon. Whereas Snort has two hundred and sixty-six (266). I also found this paper making the case to use IDS on one’s VOIP system from Purdue University for reading and hope it’s okay by moderators…got new users cannot post like despite joining 2019 I think.
engineeringDOTpurdueDOTedu/dcsl/publications/papers/2009/voipids_ijis09_submit.pdf
so you will need to add the https colon two forward slashes and add real dots in the appropriate places. Moderators, please change the link if you find it acceptable, thank you!
Link:
IMO, this technology would not provide practical protection for a FreePBX system.
Consider four levels of potential attackers:
- Random attacks from malicious automated tools that probe every IPv4 address on the internet, looking for vulnerabilities.
- An outsider targeting your system, typically a competitor.
- An attacker with specific knowledge of your system, typically a disgruntled employee, former employee or contractor.
- A skilled and well-funded cyberwarfare group, usually run by a nation-state.
Protection against (1) is easy: require a ‘secret’ domain name to access any service, also limiting access to authorized whitelisted addresses when practical.
Protection against (2) can be done by requiring a VPN connection for any external access, or permitting only TLS connections with verified client certificates.
Protection against (3) requires educating the staff about phishing attacks, protecting certificate material from end user access, and many other factors unrelated to VoIP, e.g. automated detection of malware and phishing in incoming emails.
Protection against (4) is impossible.
1 Like
This is very good Steward1 and I do my best to protect my system with one of the world’s best firewall…I see the constant IPv4 probing of my old PBX address although it doesn’t exist. I would prefer the competitors offer better deals for better service instead. I know as employment grows so does the need to share some info regarding some portion of the network administration; and, that treating employees the best one can possibly do is no guarantee there wouldn’t a disgruntled one…
You appear well-informed and could be an expert in the PBX world.
You could perhaps combine 1, 2 and try and evade 4 by enforcing SNI (ServerNameIdentification) by reverse proxying connections to your domain names while dropping any IP based connection attempts before they leak anything.
As suggested , use ‘secret’ domains for provisioning and management and phone calls, but your Internet facing presence https:// (UCP/FOP2/ etc) is pretty well protected, no ability to snoop anything at your domain URL by connecting to your IP address if you get that strict SNI enforcement right because of the proxy
I use haproxy, it has the added advantage of easily delegating your Cert issuance for all your ‘sservices’, including mail/ftp, whatever away from FreePBX, which some consider largely broken in 2022 .
1 Like
This is also great Dicko…I was thinking a few days that I should look into adding Haproxy package…now, I am convinced to make the move.
As to provisioning, I was wondering why I am getting so much TCP-s from bad IPs to my old PBX address. I had used a SIP trunk provider free period back 2019 for evaluation but had to give on the PBX phone project for a while and now that I am back on it could PBX left a footprint out there? If so, how to resolve it?
Mostly the crap is UDP/5060 ( so just don’t listen to it) in your case can you expand on where the TCP traffic is originating from and how you are seeing it going to your ‘old PBX’ address’
It’s stopped at the firewall, and I see it on the log…sometimes it’s from Europe; the last one was from netsystemreseach.com.
Hey Dicko,
I want to be clear on the use of Haproxy…so, calls come in, hits firewall where rule says all calls coming in from SIP trunk provider IP on port 5060 or 5161 or udp 10,000:20,000, send them to Haproxy frontend where it is reverse proxy to a “secret” domain validated by a key certificate (wildcard certificate since it’s only used locally) to Haproxy backend that would be FreePBX IP, then phone rings?
Haproxy can handle your TCP/TLS/HTTPS/HTTP connections, UDP traffic, not so much, but yes your front-ends handle those connections including ports, all HTTP connections should be redirected to https protecting your web facing sites, qualified by your certs and handled by ha proxy with strict SNI set which means IP based connection get ‘ghosted’ , then sent to your back-ends rewriting ports if you need to. So no UDP connections work through this method. And just inncase you missed it, don’t setup certificates or https on your server, and consider never using any port between 5000 and 5999 for obvious reasons (that’s were the bad guys roam 
)
I might add that any ‘firewall’ you might have in place might not be very helpful here as you develop your solution, in itself it is a quite solid filter for SS* connections, consider adding proxies for your SSH and mail services perhaps FOP2 or other secure protocol enabled services you might have in place
Ok, I understand that this approach is kinda of ’ disruptive’ to FreePBX, and my solution is not easily globalized.
For me it works, but would love to collaborate with any one who ‘gets it’ . . .
Any takers ?
Haproxy would only use 443. How is NAT…my firewall is configured for 1:1 NAT.
I think I get it…I just installed FreePBX 16 and with there so-called smart firewall, I hope it won’t cause problems with call connection or quality. It certainly adds another lever of security to a DMZ. I am contemplating on ditching the ESXI server and install FreePBX on the lenovo i5 SFF with 16GB RAM 250SSD. It serious overkill for maybe three phone at most.
This was a lot of homework! 
I am hoping to have everything fully configured at the end of the weekend so I can start test sip trunk providers next week.
Dicko, the part I am struggling with is how, when the calls arrive at the firewall as UDP 5061 or 5161 then reversed Haproxy on port 443 frontend and delivered to the backend on port 443, is FreePBX FQDN will be listening on port 443? Hope you’re still here…I figured out the HAproxy side and now visual the actual calling process.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.