Update 3 Final: Wake Up with PUSH for the Web Client & PWA

[ivan.antic]

+1

 

[NickD_3CX]

You need to understand that you are selling telephony system, hence you can't make changes like this in order to "boost" security of customers because we (MSPs) are bound by contracts to provide certain services to the customers, which includes 3cx PBX + additional things on top of that.

I understand that our PBX will be unsupported if we modify the system, but we need to make those changes to meet our contractual obligations that were made prior to these changes...

Furthermore, you can always give an option to the customer without much knowledge to use your recommended best practice approach, but you have to allow others to use 3rd party software at their own risk.

Now you'll probably repeat the above "As you seem quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?". We are not here to fight with 3cx about ownership of the virtual machine, I don't want to develop/run scripts on 50-100 PBXs after every update because you think it's fine to make changes like this. We where just developing ansible playbook for automatic welcome email update on all our PBXs, when we suddenly realized that we can't use certain packages anymore...

You are exactly right, I will quote myself again by saying "As you seem quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?"

Let's not go into how easy this thing is to do, it will literally take 2 minutes for someone that knows their stuff, and another hour MAX to apply to 100 machines.
I wouldn't even characterize this as "development" due to how easy it is, if you insist of running an unsupported/untested/non-recommended setup to meet contractual obligations.

As someone already said, SNGREP as a MUST have software on any VOIP system is not available anymore because of these changes, which is ridiculous considering how powerful the tool is, especially compared to activity log which can't be tracked live compared to SNGREP.

If you have done the above, then this is not a problem. Let's not forget that 3CX has built-in packet capturing which allows you to download the capture right from the Management Console and open it with Wireshark, which I think we can all agree is one of the best tools out there for packet analysis.
Alternatively there is also "tshark" available in the repo.
We will though take your comment regarding sngrep into consideration for the future.

 

[PhonerBY]

Continue reading the Original Blog Post.

Hi Nick,

can you give us a statement, if 3CX uses PJSIP, please ? There's a critical bug in that library as stated f.e. here:
https://thehackernews.com/2022/03/critical-bugs-reported-in-popular-open.html

 

[Anaphylaxis]

You are exactly right, I will quote myself again by saying "As you seem quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?"

Let's not go into how easy this thing is to do, it will literally take 2 minutes for someone that knows their stuff, and another hour MAX to apply to 100 machines.
I wouldn't even characterize this as "development" due to how easy it is, if you insist of running an unsupported/untested/non-recommended setup to meet contractual obligations.



If you have done the above, then this is not a problem. Let's not forget that 3CX has built-in packet capturing which allows you to download the capture right from the Management Console and open it with Wireshark, which I think we can all agree is one of the best tools out there for packet analysis.
Alternatively there is also "tshark" available in the repo.
We will though take your comment regarding sngrep into consideration for the future.

Nick,
It shouldn't be our responsibility to fight against the system we pay money for. What's to stop you putting an "UNSUPPORTED -- DISABLE APT CHANGE" or having a "HARDCORE" mode which enforces the system is iron-clad to what you want. It is your responsibility to test on regular, unmolested hardware, that's correct, however it is not your duty to protect me from myself. I know what's best for my clients, and our servers: you don't. If I wanted to have no control over my instance I would go with Hosted by 3CX, after all, isn't that the entire purpose of that service? You are 2 steps away from just managing my server for me, which, sorry Nick, I don't want. I just want a PBX.

 

[GoranC]

Anaphylaxis​

+1

 

[ivan.antic]

+1

 

[Pierre_3CX]

Hi Nick,

can you give us a statement, if 3CX uses PJSIP, please ? There's a critical bug in that library as stated f.e. here:
https://thehackernews.com/2022/03/critical-bugs-reported-in-popular-open.html

We have checked this internally with our development team and the PJSIP library is used only on client mobile apps and on the legacy windows app but not on the server-side.
Furthermore, although vulnerable/previous versions are in use on those client apps at the moment, the API functions affected by this issue aren't implemented on our end apart for pjsua_call_dump which is called with a large enough buffer.

We will still look into updating to latest version in a future release of course out of a good practice, but you can safely ignore this alert or rank it as false positive.

 

[GoranC]

NickD_3CX,

Let's say your antivirus vendor decides to lock all other applications on your PC with this explanation "Following our recommendations, you shouldn't be using this PC for anything else other than antivirus software, hence we will block them all"?

Do you think this is the way to go?

Also, you need to understand that many people won't even notice these changes, but they will cause certain things to stop working, which might cause loss of data... In your opinion, who will be responsible for data loss if that happens?

Regards
Goran

 

[N_G]

No its not the same at all. We have said right from the start these machines need to be dedicated to 3CX. So it has absolutely nothing to do with a virus application that is designed to protect the host.

In this case the host OS is designed (although of course debian) by 3CX and locked down to work with 3CX. Yes we will control what updates are shipped downstream by Debian to the OS because it is in the interest of our users. This is the way we are doing 3CX on Linux for a long time now, for good reason and for 250K+ customers. If you modify 3CX or its bundled OS, then of course you are fully responsible for any data loss that might ensue.

Now if you want to run other apps on the OS we have a great solution for you - 3CX on Windows. Windows is much more suited for this and in fact our upgrade process is also different on Windows and caters for this.

If you want to kiss your weekends goodbye for the rest of your life there are also a couple of open source solutions

 

[ivan.antic]

Look like 3CX becoming as same as GrandStream PBX solutions.

Indeed it get you the feeling you are an administrator of a 3CX system, share the same level of access with customer his administrator

I expect tighter and tighter updates in future, so we will end up to be on a same level as our customers. Right.
Why would any company hire IT support different then 3CX, it is same now.

I really don't understand why 3cx did this huge change with U3?, as I haven't seen or heard any security issues with previous versions (both OS level and 3CX level) if it's maintained properly as any other hardware and software. I have seen even V14 and V15 running just fine.

Hope for that you will release at least an API for V18 soon, and provide some flexibility to already rigid and limited update

 

[N_G]

Hi @ivan.antic

To be clear - We have not tightened down to limit control of partner/customer/admin. We have tightened the way updates are sent "downstream" to the OS by Debian. Debian are making frequent updates to the OS which - if untested - can mean that things break. So the update is designed to give us as 3CX more control of what upgrades Debian can automatically ïnsert" into the OS. The old way was very time consuming and error prone. The new way is much more reliable for us and therefore will result in more reliable updates and upgrades and way less support issues for partners and customers and of course us.

Now i fully understand that some partners with advanced linux skills want to bypass this. Its fine with us and if they know their "Linux stuff" they know how. They also know that they will be responsible for any changes they make and any downtime or dataloss will be at their own risk.

Now in regards to @GoranC comments about a REST API and more configurability/manageability via an API - we are working on this as we speak. I know we have said this for a long time but this time its coming - sooner then you think.....

 

[Evolute IT]

Now in regards to @GoranC comments about a REST API and more configurability/manageability via an API - we are working on this as we speak. I know we have said this for a long time but this time its coming - sooner then you think.....

So U4 for some parts of the API? WebMeeting is nice but we need system management more than anything right now!

 

[N_G]

@ConceptsWeb Yes an API for configuration of 3CX..... its going to have a lot of things for partners to manage more small businesses more easily

 

[rc@cn]

Pertaining to the monitoring software: we have our instances hosted in AWS, which offers some monitoring and alerts for things like CPU, network traffic, and a few other things. I have always assumed using these features from AWS did not require anything extra to be installed on the actual host OS, but if you know different please let me know.

 

[N_G]

@Robbie Cantey Thats a good question. The amazon tools can most definitely be installed. It somehow supercedes it since the images are managed by Amazon.

Also we could consider adding some popular tools to the ISO / source list so that they are maintained together with the PBX.

 

[Nick Shortal]

@Nick Galea, does the 3CX Desktop Apps v 18.7.10 have feature parity with the Windows 3CX Client for 3CX Phone system version 16.3.0.264? I was advised internally that we could not consider a jump to production use of the v18 Desktop App due to a lack of access to call queues. Just want to know if this information is out of date.

 

[infused]

I am really concerned by the removal of these sources. This isn't something 3CX should be doing except on their own hosting platform, since you run it, you're responsible for it.

Anyway, like the others have said, you'd need to add some common packages. The AWS/Azure monitoring ones are a must.

 

[NickD_3CX]

@Nick Galea, does the 3CX Desktop Apps v 18.7.10 have feature parity with the Windows 3CX Client for 3CX Phone system version 16.3.0.264? I was advised internally that we could not consider a jump to production use of the v18 Desktop App due to a lack of access to call queues. Just want to know if this information is out of date.

Hi!

Allow me to answer, this is incorrect. All Queue functions are there, just like in the legacy Windows Client app.

 

[PhonerBY]

We have checked this internally with our development team and the PJSIP library is used only on client mobile apps and on the legacy windows app but not on the server-side.
Furthermore, although vulnerable/previous versions are in use on those client apps at the moment, the API functions affected by this issue aren't implemented on our end apart for pjsua_call_dump which is called with a large enough buffer.

We will still look into updating to latest version in a future release of course out of a good practice, but you can safely ignore this alert or rank it as false positive.

Thank you for this quick check and reply !!!!

 

[VoIPQZ]

Really disappointing to see these updates rolling in and still no "fix" on the items hidden behind "..." menu.

How is this not a top priority? Such an easy update to do and you cant tell me there's ANYONE looking at their 3cx client and going "you know what, I'm so glad my voicemails are hidden behind a contextual menu that only lights up blue to tell me I have a voicemail. Would've been so hindering to see that I have voicemails and how many!". Not even sure how that passed QA in the first place.