Accessing the FreePBX UCP
-
Which makes sense, as the web management service is configured (by default) to only be accessible by traffic from the "local" zone. So I would expect traffic to 443 to be dropped from other networks.
From this, it looks like there would be some intelligence within FreePBX that would foward requests for the UCP page to a port other than 443, as the default non-secure port is 81 instead of 80. -
The solution might be train external users to go to https://freepbxhost.tld:4443, but methinks there has to be a way to be able to use https://freepbxhost.tld/ucp.
-
@eddiejennings said in Accessing the FreePBX UCP:
Which makes sense, as the web management service is configured (by default) to only be accessible by traffic from the "local" zone. So I would expect traffic to 443 to be dropped from other networks.
From this, it looks like there would be some intelligence within FreePBX that would foward requests for the UCP page to a port other than 443, as the default non-secure port is 81 instead of 80.What about your outside firewall. Is there no firewall in front of the FreePBX box?
-
@scottalanmiller Only firewall between the FreePBX VM and the Internet would be whatever Vultr has on their network.
So I decided to take a step back, and restore the default configuration (setting the insecure port for UCP to Port 81 from the graphic above).
Afterward I did a few tests, and I believe this is the deal: /ucp must be serviced by port 80 / 443. Here is the default configuration from Connectivity > Firewall > Services.
With this configuration, the following URLs fail from the non-office network:
http://freepbxhost.tld
http://freepbxhost.tld/ucpIf I set the Web Management service to be accessible from both Internet and Local, then those two URLs load when requested from the non-office network. This tells me that /ucp is directed to port 80, since, as an additional test, I went back into the System Admin (first graphic of the thread), disabled the UCP port 81, and was still able to load the /ucp URL.
As a final test I re-enabled Port 81 for UCP in the System Admin module, kept Web Management accessible for Internet and Local in the Firewall module, and removed UCP from Internet accessibility in the Firewall module.
From the non-office network, I was still able to access http://freepbxhost.tld/ucp. Just to see what would happen, I set the zone for UCP to reject (removing it from local and other) and was still able to access that URL.
I replicated the same steps using https settings and https URLs instead. I also replicated this from two different networks.
The conclusion seems to be that http(s)://freepbxhost.tld/ucp is serviced on port 80/443. The way to prevent external users from using the UCP over an insecure connection is by not adding Web Management to the Internet zone in the Firewall, but adding Web Management (Secure). Futher (and this seems wrong), it seems that the UCP service in the Firewall configuration doesn't seem affect accessing the UCP.
-
I wonder the need for the UCP direct link? If you just load the default page with Web Management Secure enabled, there is a button on the page for UCP, click it and go. Why manage this separately, unless you really need to make the admin page unaccessable via the internet in general.
-
@dashrender in absolutely zero locations do I have the admin page open the the public.
-
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
Do you have any instances where the UCP page is available to the public?
-
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
And when possible, not the UCP page either!
-
Alas, I don't see a way to not have my UCP page available, hence, the challenge
-
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
If I remember correctly, you have your home and office IP whitelisted on the pbxs. Right? Or some other “jump box” type solution...
-
@fuznutz04 said in Accessing the FreePBX UCP:
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
If I remember correctly, you have your home and office IP whitelisted on the pbxs. Right? Or some other “jump box” type solution...
And if I need random access, I log into the host system (Vultr) and then grant access to my current IP.
-
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
OK I over stated this - what I meant was - every location where a phone registers, it appears that have access to the admin page, and by extension the UCP page.
I happen to be out of town now and I just checked. I don't have a phone registered here and I don't have access to either site.
-
@dashrender said in Accessing the FreePBX UCP:
@jaredbusch said in Accessing the FreePBX UCP:
@dashrender in absolutely zero locations do I have the admin page open the the public.
OK I over stated this - what I meant was - every location where a phone registers, it appears that have access to the admin page, and by extension the UCP page.
That should be the behavior; however, none of my test users can access the UCP page (they have phones registered at their homes). One of my tasks on Monday is setting up a phone at my own home to see if I, myself, can't access the UCP from my home network.
-
I will test the two office locations where I have phones tomorrow. This is a brand new install and they haven't used UCP yet.. not a lot of need at this point so we haven't tried it.
-
I am not sure why FreePBX doesnt allow the same responsive firewall setup for web based logins. If you have a phone and it authenticates from an IP, then the User CP is available on the public side.
The idea of "I never expose XYZ portal to the public" isnt very helpful with a remote workforce. Imagine if you have to VPN to login to Office 365 or Gmail.
I set the admin interface to a random port number and the default port 443 or 80 to the UCP, so no path is needed. I thought that was the standard way to do it. Where a phone has authenticated from a public IP so should the UCP then be accessible.
I have moved entirely away from FreePBX so I have no instance to log in to ATM.
-
@bigbear said in Accessing the FreePBX UCP:
I have moved entirely away from FreePBX so I have no instance to log in to ATM.
What do you use now?
-
@bigbear said in Accessing the FreePBX UCP:
Where a phone has authenticated from a public IP so should the UCP then be accessible.
Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.
-
This post is deleted! -
@dashrender said in Accessing the FreePBX UCP:
@bigbear said in Accessing the FreePBX UCP:
Where a phone has authenticated from a public IP so should the UCP then be accessible.
Right, this is my understanding as well. But this not exposing UCP to the public. This is the responsive firewall only opening UCP for those IPs that have valid registered extensions.
And I guess my point to that is what if someone wants to log in from home and change the main menu schedule (this actually happened to me with a couple customers) and they have no phone at home so they cant log in to the admin interface.
-
@dashrender said in Accessing the FreePBX UCP:
@bigbear said in Accessing the FreePBX UCP:
I have moved entirely away from FreePBX so I have no instance to log in to ATM.
What do you use now?
(edit: deleted my last post because I replied to the incorrect comment of your last two)
Fusion PBX, Freeswitch, OpenSIPS for a few things but I am doing a multi-tenant thing. I would still agree if you want to run your own single tenant cloud PBX that FreePBX is easier in most respects.
One thing I do love about anything Freeswitch-oriented is the use of domains over IP's for a better layer of security. You can afford to allow web UI logins from anywhere for a number of attempts when the attacker has to also discover the DNS name mapped to the IP to make the attempt. I shut off an IP from a web portal login after 10 attempts.
Also for roaming mobile devices and Bria apps, etc there is no grief as there always is with FreePBX. And no updates that occasional broke my FreePBX installations.
