[this post and three that follow moved from unrelated thread - mod]
Ok - Quick question - I have just removed the forwarding for Port 80 on all our Hosted Boxes - but provisioning is on port 84 - is it vulnerable? Let’s Encrypt was using Port 80, so I can leave that off for a little while until the dust settles - I am getting the feeling from the thread that Apache is the problem - does provisioning use Apache to serve the files? Is HTTPS vulnerable?
I have a firewall rule that only allows inbound communication from mirror1.freepbx.org, mirror2.freepbx.org, outbound1.letsencrypt.org and outbound2.letsencrypt.org to port 80 of my FreePBX box. You don’t have to open 80 to the entire world to get your Let’s Encrypt SSL certificate to work.
Isn’t there also code in the new version of the LE Support code that opens port 80 during the LE Updates?
To answer the rest of your question, you shouldn’t open port 84 to the internet.
If you look under Firewall > Services > Extra Services > HTTP Provisioning, it specifically says “Phones that are configured via Endpoint Manager to use HTTP provisioning will use this port to download its configuration. It is NOT ADVISED to expose this port to the public internet, as SIP Secrets will be available to a knowledgeable attacker.”
What really concerns me is HTTPS Provisioning shows the same message. I tried to get some clarification as to why this would be an issue if we are using an SSL certificate, authentication and Sangoma phones but I haven’t been able to get an explanation. I have HTTPS Provisioning closed to the internet until I get a firm answer.
Think of it this way. If you expose your http provisioning service to the internet on a default FreePBX Distro install, then hackers only need to guess one of the provisioning file names in order to download it. Once they have a provisioning file for one of your phones, they have enough info to register their own client to your PBX, provided they also have access to the SIP Signalling port(s).
The next layer of security is adding Apache credentials. This is an option in System Admin pro, or you could configure it manually if you wish. With Apache credentials in place, the malicious user would not only have to guess a valid filename, they would have to guess the Apache user/password. Apache creds for provisioning is a somewhat recent development. Pretty much all popular current SIP phones support it, but legacy devices might not.
Next layer would be fail2ban configured to watch for Apache login failures, which is enabled by default on distro install. If properly configured, malicious hosts that fail the credential challenge get banned temporarily.
Final layer would be to block untrusted access to the provisioning services rendering all the above moot under normal circumstance. It is still wise to keep the above in place in the event that whatever method you’re using to block untrusted access fails and starts allowing access, which is exactly what happened in the exploit I wrote about here.
The above is talking about http, but all of it applies equally to https. https does literally nothing to prevent brute force attempts. What it does do encrypt the data between the pbx and the endpoint, making it more difficult for sophisticated attackers using a packet sniffer to discover Apache credentials or provisioning filenames. Good practice says don’t allow untrusted access. If you must, put as many roadblocks in place that you can, while still keeping the service usable to legit users.
I was under the impression that if you have the FreePBX firewall configured correctly, multiple failed attempts to HTTPS Provisioning TCP port 3443 would end up blocking the user/device that is trying to get in.
What I am doing now is the following
I either have a site to site VPN that allows the phone to communicate via 5060, 10000-20000, etc or I set the extension to SIP TLS and have 5061 opened up in the firewall that goes directly to the FreePBX box. I am still running into some issues with SIP-TLS but that’s my desired way of having it work in order to allow phones to be moved around from place to place without having to create a site to site VPN all the time. Am I nuts for opening TCP 5061 for SIP TLS to the world?
What I would like to be able to do is the same as Jive, Ring Central, etc. and allow the provisioning and communication of whichever phone that is correctly setup from anywhere on the internet. I can’t achieve this at this point.
The Responsive Firewall goes a long way toward that goal. Configure all services to block untrusted access and then enable Responsive with appropriate protocols. This will allow a limited number of registration attempts from any host, and if they register successfully, other services (provisioning, restapps) become open to them. If they fail to register, the IP gets blocked by the Responsive Firewall.
so that being said, if you’re correctly using responsive firewall, zero touch provisioning and have the following ports opened… would this be a secure config?
1443 TCP from ANY for HTTPS Provisioning
3443 TCP from ANY for HTTPS Phone Apps
5061 TCP from ANY for SIP TLS
10000-20000 UDP from ANY for media
4443 and 8003 TCP from ANY for HTTPS User Control Panel (UCP)
80 TCP for Let’s Encrypt ONLY from mirror1.freepbx.org, mirror2.freepbx.org, outbound1.letsencrypt.org, outbound1.letsencrypt.org
5060 TCP/UDP for SIP trunk ONLY from the upstream VoIP SIP Trunk Provider
No. Very broadly, my suggestion is to set your interface(s) to the Internet zone, and then remove Internet zone access for all services. This results in a system only accessible by whitelist and your testing should confirm that. The final step is to then enable responsive which allows limited access to untrusted hosts.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
The interface for the PBX is already set as Internet
When you say the following
No. Very broadly, my suggestion is to set your interface(s) to the Internet zone, and then remove Internet zone access for all services. This results in a system only accessible by whitelist and your testing should confirm that. The final step is to then enable responsive which allows limited access to untrusted hosts.
How can enabling Responsive Firewall allow limited access to untrusted hosts if the Internet Zone is not enabled for such things as HTTPS Provisioning ?
Because your unit would already be provisioned.
The best way to handle it in the scenario outlined above is to provision the units once under control. Then they can register from anywhere.
The problem with that method is if the device attempted to connect too many times checking for updated provisioning files prior to the registration. This is potentially an issue with Yealink phones that have things like address books, saved local configs, etc.
This is what shows in the http log when my phone reboots.
64.53.XXX.XXX - - [27/Sep/2019:09:34:45 -0500] "GET /cm_to_yl_ab.php HTTP/1.1" 200 1713 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:34:52 -0500] "GET /0015XXXXXXXX.boot HTTP/1.1" 404 215 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:34:52 -0500] "GET /y000000000000.boot HTTP/1.1" 404 216 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:34:52 -0500] "GET /y000000000028.cfg HTTP/1.1" 200 11448 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:35:35 -0500] "GET /0015XXXXXXXX.cfg HTTP/1.1" 200 2373 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:35:40 -0500] "GET /0015XXXXXXXX-local.cfg HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - username [27/Sep/2019:09:35:40 -0500] "GET /0015XXXXXXXX-local.cfg HTTP/1.1" 200 2370 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - - [27/Sep/2019:09:35:58 -0500] "GET /0015XXXXXXXX-contact.xml HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
64.53.XXX.XXX - username [27/Sep/2019:09:35:58 -0500] "GET /0015XXXXXXXX-contact.xml HTTP/1.1" 200 2086 "-" "Yealink SIP-T46G 28.83.0.50 00:15:XX:XX:XX:XX"
This might help: