These are Grandstream 2140’s. Not sure if FTP is a possibility but I have one in house I can look at to see. Alternatively I could simply block the TFTP ports entirely from the outside world until a re-provision is needed.
2140’s will do FTP and HTTPS - Check into it - We have a ton of 2135’s/2170’s deployed all using HTTPS provisioning - but FTP works with them too.
If you are going to use HTTPS provisioning, you might have to tweak your SSL cert if you are using Let’s Encrypt - Look here for the gory details: Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14 - FreePBX / Endpoints - FreePBX Community Forums
But for sure, those phones will do FTP and HTTPS provisioning - you just need to set it up.
Thanks for the info and advice! I’ll look into it. For now I’ve blocked port 69 to all PBX’s.
1 Like
That will help a lot! Good luck!
Lorne, what protocol does the older Digium Phone Configuration module use to provision phones? 98% of my systems use that still. Only started using EPM recently.
You also need to assume that all the passwords are compromised and change them.
I’m not sure why only the remote user was hit, unless this was an eavesdropping attack, in which case FTP wouldn’t be safe, either.
You also need to assume that all the passwords are compromised and change them.
I’m not sure why only the remote user was hit, unless this was an eavesdropping attack, in which case FTP wouldn’t be safe, either.
password changes were the first thing I did.
I’m not sure either why only that remote user softphone was hit. It happened once before but I caught it before too much damage was done. This one is gonna cost me. I do know (now…) that the config for that ext should never have been in EPM.
Since it’s necessary for the brute forcer to successfully guess a valid provisioning filename, it’s common for only a single file (or 2) to leak this way.
DPMA, which relies on a cert in the phone so less of a concern, but should not be exposed to untrusted traffic if possible.
@lgaetz
DPMA, which relies on a cert in the phone so less of a concern, but should not be exposed to untrusted traffic if possible.
Thanks Lorne!
Greg,
I’ve got my test phone provisioning via HTTPS, it was pretty trivial but I did have to go into the phone gui to do set the provisioning server. With a large install this could be tedious.
Does DHCP option 66 only work with TFTP or can it work with HTTPS as well?
No, it works with HTTPS - You can also use Option 160 - it’s a Polycom setting, but the Grandstreams will use it too - here: DHCP_Options_Guide_Linux.pdf (grandstream.com)
I like Option 66 - it would look like this:
https://username:[email protected]:https-port
That worked. I initially didn’t have the HTTPS:// in the option 66 string. Thanks again Greg!
If using EPM with DPMA, can TFTP be safely disabled? I would assume so.
And the same for the sangoma Dect base stations?
Yes. General recommendation now is to leave it disabled. The only use for tftp is for legacy devices that don’t support any other provisioning method.
1 Like
@lgaetz
@GSnover
@PitzKey
@david55
Thanks everyone for all your advice on this! I think I have a much better handle on this now.
1 Like
I’ve blocked port 69 at the firewall so not too concerned at this point but going through all my PBX’s and they ALL have TFTP enabled in provisioning protocols. Is ENABLED the default? is so, perhaps it shouldn’t be?
It was once, but starting in 13? 14? it was changed to disabled by default.
Not so much an issue its enabled by default, more so that your firewall should not have ports exposed that are not needed. The bigger question would be, how many other ports are open to the wild wild web?
No, I opened port 69 purposely for provisioning in my ignorance. My firewall is deny by default (As it should be). “Sorry folks, port 69 is not closed, moose out front should have told ya…”
2 Likes