I changed the system from port 80 to a obscure port and firewalled port 80, (stand alone firewall in front of pbx) the gui works fine but I can not provision phones unless I open port 80, I tried adding http://YOUR-SERVER-IP/xepm-provision:XXXX but it did not work. system is hosted so phones are remote with dynamic IP’s is the EPM locked to port 80/443
I just had a very big supprise, i put that string into a browser followed by a mac address and the config file was displayed, this leaves the system wide open. Is there a secturity setting I have not enabled.
My existing provider has a provisioning lock process, where they lock the provisioning after 15 minutes so SIP Username and Password are no longer sent to the phone… If we need to update the U/P settings on a phone, we need to login to the portal and unlock provisioning which gives us 15 minutes to auto-provision/reboot the handset to receive U/P settings. Other info still auto-provisions daily as normal.
Although they have also managed to completely avoid having info public.. Haven’t worked out how they do that but it looks like they may run their own provisioning server. If you try browse to http://provisioning.XXXXXXX.co.uk/ it comes up with a message saying you can not visit the provisioning server using a standard browser and “Only VoIP devices can access this area.”.. If you add the /Yealink/mac.cfg to the end you just get a blank page and no provisioning info…
The first paragraph is a VPBX suggestion, the 2nd is just information.. considering all the great work already put into VPBX this seems a simple task for the guys to implement.
Yes i know they have but avoiding brute force attacks is not enough. Anyone malicious with access to the site can obtain a MAC address from the back of the phone and it’s not difficult to find out what server that phone is connected to without even gaining access to the phone’s config page.. Even a simple arp -a will give you the MAC address let alone a MITMA… It wouldn’t take long to add this info together and get ALL details to connect to that SIP user and make malicious calls..
As a Hosted Multi-Tenant provider and not a single on-site system end user/customer this is a bit scary as we have limited ways to stop people from accessing the customer’s building / LAN /WiFi.. Let alone anyone external who manages to access the network via the WAN.. (some sites have very basic LAN/WAN CPE)
SIP credentials are far too risky to leave out in the wild and hope no-one will find the MAC…
We do have daily call spend limits at network level with notifications to mitigate the issue a bit but this is a pain to manage and isn’t bulletproof…
Would love to hear any suggestions to get around this.. (ideally keeping things simple that fits for all customers..)
.
