Open Source Auto Provisioner

[Tom]

I know there are quite a few of us running open source Kazoo who would like to auto provision phones but cannot purchase the service from 2600hz for various reasons (if you can buy from 2600hz, I think you should - their auto provisioner is really good). There is an open source solution out there, but it is not secure (Provisioner v4).

I am interested in creating an open source auto provisioner, but I need the community's help to make it a reality.

Right now I could really use help defining a secure, robust, and scalable architecture, specifically the data model, before I begin coding. Right now, I am thinking about creating a separate server that uses mTLS for authentication (I don't know Erlang so a Kazoo app isn't an option) and a Monster UI app.

If the community can help me at this early stage with the architecture and data model, I intend to deliver an MIT licensed auto provisioner on GitHub that incorporates as much of your feedback as possible (similar to what I did for my Ansible roles for those who have checked them out).

I look forward to working with you guys to make this a reality!

-Tom

[tomas_]

Sounds great!

The monster UI part is already in place in the default SmartPBX / voip app (4.1), at least selection of device, MAC address field and feature keys.

Br - Tomas

[Tom]

1 minute ago, tomas_ said:

Sounds great!

The monster UI part is already in place in the default SmartPBX / voip app (4.1), at least selection of device, MAC address field and feature keys.

Br - Tomas

I don't think the provisioning aspects of Monster UI should be reused for a couple reasons:

1. When a device contacts the provisioning server, there needs to be a fast way to lookup the configuration based on mac address. Currently, all of the device data for an account is under an account database, so you'd have to filter by mac under ever account, which will yield low performance. I was thinking of creating a single database just for provisioning (it would store the device config options, mac address, and account owner).
2. I tried examining the Monster UI source code to determine what requests/responses I needed to implement, and this proved to be a difficult endeavor. I would rather code a new app that I fully understand.
3. Coding a new app provides more flexibility than being stuck with whatever UI elements made sense for the 2600hz provisioner. Even 2600hz needed to expose different functionality and created the Advanced Provisioner app, which is not open source.

[amn]

I am working on something.  Not far along yet so send me a PM of what you have in mind.  Have a look here for things I have found so far.

 

 

 

Edited February 5, 2018 by amn (see edit history)

[amn]

duplicate post removed.

Edited February 5, 2018 by amn (see edit history)

[tomas_]

On 2018-02-04 at 9:21 PM, Tom said:

I don't think the provisioning aspects of Monster UI should be reused for a couple reasons:

1. When a device contacts the provisioning server, there needs to be a fast way to lookup the configuration based on mac address. Currently, all of the device data for an account is under an account database, so you'd have to filter by mac under ever account, which will yield low performance. I was thinking of creating a single database just for provisioning (it would store the device config options, mac address, and account owner).
2. I tried examining the Monster UI source code to determine what requests/responses I needed to implement, and this proved to be a difficult endeavor. I would rather code a new app that I fully understand.
3. Coding a new app provides more flexibility than being stuck with whatever UI elements made sense for the 2600hz provisioner. Even 2600hz needed to expose different functionality and created the Advanced Provisioner app, which is not open source.

1. As I see it you could still use the existing Monster UI features and store the data somewhere else, outside Kazoo / CouchDB. Our "Frankenstein" solution ( 
https://forums.2600hz.com/forums/topic/9588-open-source-provisioner/?do=findComment&comment=52427 ) uses PHP and MariaDB.

2. I don't remember exactly, but we also examined what triggers the Monster UI to show the provision details. When looking now it seems like the "provisioner" setting in monster-ui/js/config.js needs to point to a script that returns a json of all the devices available in the provision system:

3. I see your point here, but for me it seems easier for the end user to only have one UI to work in when adding / changing devices. Of course you can have a separate provision system/UI (as we do in our Frankenstein-solution - FusionPBX), but the normal end user shouldn't need to make any further steps to get the new device provisioned directly when adding it to MonsterUI.

 

Edited February 6, 2018 by tomas_ (see edit history)

[amn]

You can just do the provisioner part if you want. Without monster you would have to create your own gui.  The API that ties in with monster could be added later.  

The projects I pointed out further up have the provisioner and the API.  You can't really use either project as is. I just used them to try better understand how it all fits together.

Edited February 6, 2018 by amn (see edit history)

[esoare]

@Tom @tomas_ @amn  

 

Keep it up guys! (gals alos if there are some out there!)

Glad to see the forum is used for open source collaboration / idea flows also! 

Fantastic!

esoare

[VincentdeWit]

Been working on this for a while now, and found out that the existing solutions are a bit outdated.
What we did is build a NodeJS API (based on Express) together with MongoDB where we store information such as MAC address, Account ID and Owner ID (if applicable). 
Our beta solution now basically provides a few things;
- Provisioning based on MAC address
- Remote phonebook support linked to users and groups in Kazoo (CouchDB layer)
- Custom editable fields, such as IP address, DNS, Language etc

There still are some things that we're not sure of on how it would work best; such as security, scalability and overall performance.

Would be happy to share code when it's fully up and running.

[Tom]

3 hours ago, VincentdeWit said:

Been working on this for a while now, and found out that the existing solutions are a bit outdated.
What we did is build a NodeJS API (based on Express) together with MongoDB where we store information such as MAC address, Account ID and Owner ID (if applicable). 
Our beta solution now basically provides a few things;
- Provisioning based on MAC address
- Remote phonebook support linked to users and groups in Kazoo (CouchDB layer)
- Custom editable fields, such as IP address, DNS, Language etc

There still are some things that we're not sure of on how it would work best; such as security, scalability and overall performance.

Would be happy to share code when it's fully up and running.

I believe mTLS is the most secure solution, but it's unfortunately the most difficult to implement properly.

[amn]

9 hours ago, VincentdeWit said:

Been working on this for a while now, and found out that the existing solutions are a bit outdated.
What we did is build a NodeJS API (based on Express) together with MongoDB where we store information such as MAC address, Account ID and Owner ID (if applicable). 
Our beta solution now basically provides a few things;
- Provisioning based on MAC address
- Remote phonebook support linked to users and groups in Kazoo (CouchDB layer)
- Custom editable fields, such as IP address, DNS, Language etc

There still are some things that we're not sure of on how it would work best; such as security, scalability and overall performance.

Would be happy to share code when it's fully up and running.

I would be interested in seeing what you are doing on the back end.  What templating system are you using?  I am looking at maybe using Twig.  Using MySQL as the primary database and php-on-couch for tying in with CouchDB.

https://github.com/PHP-on-Couch/PHP-on-Couch

If you are stuck on how to do something have a look at how FusionPBX does it for an example.  The code on that project is fairly easy to follow.

Edited February 14, 2018 by amn (see edit history)

[VincentdeWit]

16 hours ago, amn said:

I would be interested in seeing what you are doing on the back end.  What templating system are you using?  I am looking at maybe using Twig.  Using MySQL as the primary database and php-on-couch for tying in with CouchDB.

https://github.com/PHP-on-Couch/PHP-on-Couch

If you are stuck on how to do something have a look at how FusionPBX does it for an example.  The code on that project is fairly easy to follow.

Thanks for the tip! I've been using the template files provided by FusionPBX, they've saved a ton of time since they are already in their Github repo.
I've been familiar with Twig, and using the node-twig implementation for templating. It's really easy to understand and one of the simplest out there.

If you're looking into a NodeJS API, take a look at Cradle as CouchDB client.

 

@Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

[Tom]

With MTLS, a client certificate signed by the manufacturer with the MAC address as the subject is embedded with the phone at the factory. As long as you trust the manufacturer's guarding of their private keys and validate the MAC in the certificate, it makes bruteforcing MAC addresses quite difficult.

[amn]

On 2/15/2018 at 2:00 AM, VincentdeWit said:

 

@Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

 

ACL (IP whitelist) for prevention.  For deterrent you can add a delay of several seconds.  Makes brute forcing much more difficult and less practical.  You can also code the software to only respond to phone user agents.  

This software implements the delay and phone user agent trick.
https://github.com/urueedi/kazoo-provision

Anything that makes the hackers job harder and less efficient is worth doing.  The less low hanging fruit the better.

Edited February 21, 2018 by amn (see edit history)

[Tom]

On 2/15/2018 at 5:00 AM, VincentdeWit said:

Thanks for the tip! I've been using the template files provided by FusionPBX, they've saved a ton of time since they are already in their Github repo.
I've been familiar with Twig, and using the node-twig implementation for templating. It's really easy to understand and one of the simplest out there.

If you're looking into a NodeJS API, take a look at Cradle as CouchDB client.

 

@Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

The idea behind mTLS is that knowing the MAC is useless if you don't have the correct client certificate.

[amn]

On 2/15/2018 at 2:00 AM, VincentdeWit said:

Thanks for the tip! I've been using the template files provided by FusionPBX, they've saved a ton of time since they are already in their Github repo.
I've been familiar with Twig, and using the node-twig implementation for templating. It's really easy to understand and one of the simplest out there.

If you're looking into a NodeJS API, take a look at Cradle as CouchDB client.

 

@Tom Hmm, I'll look into that one. The thing I'm more concerned about is security wise for provisioning, such as if I know a phone's MAC I can basically lookup every phone's SIP credentials. I could off-course apply IP address filtering (store an array of IP addresses in the account DB, but sounds too complex (how about different branches, remote working, VPN etc.)).

FusionPBX templates appear to be using Smarty.  Did you convert them all to Twig?

Edited February 21, 2018 by amn (see edit history)

[VincentdeWit]

21 hours ago, amn said:

FusionPBX templates appear to be using Smarty?  Did you convert them all to Twig?

Not yet, just a few for testing purposes. I can share some code and upload it to Github, if I find some spare time this week.