Security Alert for Systems with IP Based SIP Trunks

[aholmes-think]

If anyone needs a way to push this update to all of their self hosted 3CXs in a few clicks, shoot me a PM.

 

[SKDamon]

Would it be correct to assume if there are no IP based external trunks, the system was not vulnerable?

Some supported provider templates omit the registration type, but when exporting the trunk there should be a line like

<field name="RequireAuthFor">4</field>

I assume the value (4 in this example) maps to the 4 available authentication methods in generic trunks:
1: Not needed - IP-based
2: Inbound - only incoming
3: Outbound - only outgoing
4: Register/Account-based
(rough translation from German)

So my guess is that only systems that have a trunk using RequireAuthFor = 1 would've been affected, can someone confirm or deny?

 

[GigCityCloud]

I'm assuming fqdn authentication is the same thing correct? can we get more info on what the attack involves? was there a hardening configuration we could apply before this update to prevent this attack surface?

It sounds like if you use authentication to register your SIP trunks, you are not vulnerable. If you don't send credentials to register, you need to patch.

 

[Tamer Ali]

The new PWA app with the latest update needs a lot of work. It looks terrible, the older version was much better.

 

[N_G]

You mean the new update 9 interface? You don't like the look or you have specific issues with different pages in terms of sizing or incompatibility?

 

[Alphabetic]

The new PWA app with the latest update needs a lot of work. It looks terrible, the older version was much better.

Terrible is a bit harsh, its not that much different.. the new lick of paint looks very nice - stick it in dark mode and its easier on the eyes.

 

[KoesioOccitanieTech]

You mean the new update 9 interface? You don't like the look or you have specific issues with different pages in terms of sizing or incompatibility?

I really love the new design and the notification tab but I feel it a bit "over-sized" compare to the old one.



Another question, does the admin side will get the same treatment ?

Thank you.

 

[Benedikt Machens]

Please dont get me wrong, but the topic is "Security Alert for Systems with IP Based SIP Trunks"
Maybe webclient design discussions are a bit wrong at this place.

 

[Guillaume Bourgeois]

Please dont get me wrong, but the topic is "Security Alert for Systems with IP Based SIP Trunks"
Maybe webclient design discussions are a bit wrong at this place.

You are right, I was about to add my opinion as well, so you did the right thing by reminding.



@Alphabetic @KoesioOccitanieTech
I will continue in thread “V20 Update 9 Alpha - Web Client Gets a New Look”


.

 

[HarryI]

Terrible is a bit harsh, its not that much different.. the new lick of paint looks very nice - stick it in dark mode and its easier on the eyes.

Is there something else except dark mode (for EVERYTHING)???

 

[UCMUserAZ]

Updated. No issues. Thanks.

 

[tronic]

In the 3CX users' guides it should really recommend allowing the SIP ports to your provider IPs only.

 

[KyriacosS_3CX]

In the 3CX users' guides it should really recommend allowing the SIP ports to your provider IPs only.

We do have it in several security related guides, but it's difficult to offer as a blanket advice - there are many SIP providers that have IP address pools that can change somewhat dynamically, breaking communications if the PBX admins are not getting advanced notice - yes, your point is valid, just difficult to put out as core setup guidance.

 

[tronic]

We do have it in several security related guides, but it's difficult to offer as a blanket advice - there are many SIP providers that have IP address pools that can change somewhat dynamically, breaking communications if the PBX admins are not getting advanced notice - yes, your point is valid, just difficult to put out as core setup guidance.

I guess would also create a support issue, if people dont do it right

 

[guidoq]

Details The IP 77.239.128.11 has been blacklisted for 201 sec. Reason: requests rate is too high!

is this part of what the update does? like some throttle on requests on the trunk ip address?
The ip is the provider ip address, never happened before.
If I allow the ip address in the ip blacklist this shouldn't happen anymore, correct?

 

[KyriacosS_3CX]

Details The IP 77.239.128.11 has been blacklisted for 201 sec. Reason: requests rate is too high!

is this part of what the update does? like some throttle on requests on the trunk ip address?
The ip is the provider ip address, never happened before.
If I allow the ip address in the ip blacklist this shouldn't happen anymore, correct?

Well you should whitelist it, but if proper communication/registration was taking place it should not really be getting throttled.

 

[guidoq]

Well you should whitelist it, but if proper communication/registration was taking place it should not really be getting throttled.

can you explain a bit more in depth what this is about? Before the blacklist took place I have 6 INVITES from sip:nonexistingDID@trunkip, then the blacklist kicked in
is the pbx matching an inbound call from the carrier SBC and the trunk DIDs and if they do not match it blacklists the ip?
what would have happened before 8A if in the configuration there was no inbound rule matching the DID in the invite?

 

[SteveITS]

In the 3CX users' guides it should really recommend allowing the SIP ports to your provider IPs only.

WebRTC needs them, though.