Malicious Remote Registration Attempts

[forever]

Hi all,

I hope that you are well.

We've been getting numerous and regular email alerts of this nature for one of our customer instances:

IP 160.116.0.29 has been blacklisted on PBX ****.3cx.co.uk.
Affected Module: SIP Server/Call Manager
User agent: PolycomVVX-VVX

Interestingly enough the specific user agent in these attempts varies. Asterisk, VOS3000, etc etc.

Obviously it's someone taking the p*ss - but the network engineer in me simply wants to block the connections at firewall level - and either prevent remote IP phone registrations entirely (client uses 3CX Windows softphone) or at least isolate to their office IP in future.

However, despite research including 3CX own firewall port guidance I cant quite see how to block remote IP phone registration entirely without risking affecting other parts of the system. All of the guidance seems to suggest that the same port(s) are also shared with VoIP provider connectivity etc.

Can you please do me a favour and provide some guidance as to which port(s) I would need to change or restrict just to exclusively block remote IP handset registration.

I did also look through the parameters in 3CX settings and I couldn't see one that seemed relevant.

I know that this must be possible because I understand that the new 3CX Hosted service via Digital Ocean supports remote IP phone extensions only when behind an SBC and not via direct connection (perhaps in part due to this automated password spray problem).

Your support is appreciated.

Thank you,

Dave

 

[NickD_3CX]

Hi Dave,

First of all, yes, some ports used by certain services are used for multiple purposes. In your case, port 5060 which is the SIP Port (I presume it is as most people leave it default) is indeed used for all SIP traffic from and to your PBX. That includes:

• Extension
• SIP Trunk Providers

This is also the port you need to close to stop getting the emails about blacklisted IPs, although the danger is fairly small if you all extensions are using random passwords auto generated by the system.

If you want to this however, the IPs you would need to allow are:

• All remote locations where your customer has STUN IP Phones (not SBC, SBC uses a different Port and protocol, as do the Mobile apps and windows All and WebClient)
• All the IPs that your SIP Trunk Provider uses ***

*** Providers are known for sometimes adding new IPs, so you must somehow inform them that the moment they add or change an IP, you need to be notified, otherwise you'll have problems with external calls.

 

[forever]

Hi Nick

Thank you for this, very helpful.

Yes, we are using the auto-generated system passwords which helps.

It's a shame that there isn't a toggle for this within 3CX, as yes I do have concerns that BT (who publish DNS records for the SIP trunks we use for this instance) will add or change IP addresses without telling us which could cause outages. BT can be a pain.

Perhaps it is something that could be fed back for development? The limitation around needing to manually specify SIP trunk provider IP addresses to 3CX at firewall level - does not seem to be apparent for the new 3CX hosted version (which still blocks remote IP handset registration inherently) so I'm assuming they may have found some other way or configuration to do this without using the firewall?

I'm sure that with increasingly decentralised workplaces there will be more and more deployments that do not wish to use direct handset IP registration at all and good practise for any system would suggest disabling features that are not desired when they are demonstrably open to attack. Although the attack window (with random passwords and IP address lockouts) is of course slim, I agree.

At the moment, having the only way to prevent direct IP handset registration using IP-specific firewall rules that could adversely affect SIP trunks is solving one problem to potentially create another. After all, this is exactly why providers now use DNS records. But of course the amount of firewall vendors that will accept firewall rules based on DNS resolution I expect is very slim. Just my feedback of course.

Thanks again - off to find BT's current IP address list now and hope it is up-to-date!

All the best,

Dave

 

[NickD_3CX]

As I said, that's what the in-built Security feature does, it allows you to "whitelist" certain IPs, which means they will never get blacklisted.
To ramp up security, you could go with whitelisting the IPs you know (BT, STUN phones, etc) and then under Settings --> Security, set the "Failed Authentication Attempts" counter to something lower, like 5 (don't go below 3). This would allow for a significantly smaller of "hack attempts" from a single IP. Also, if you couple that with an increased "Blacklist time interval" like 86400 (24 hours), then you should be fairly safe.

That is what our hosted platform utilizes.

Finally, a few service packs ago we implemented the "Global 3CX IP Blacklist", where if enabled, you receive a list of IPs that we have collected from all 3CX systems that have this option enabled, that hare known for "not playing nice".

 

[forever]

Hi Nick

Thank you again for the useful feedback.

We do have the 3CX Global IP blacklist feature enabled, it's a good idea and nice to see it implemented. Wordpress do something similar I believe.

Funnily enough I did look at the failed authentication attempt thresholds and lockout periods this morning. I'll change ours with parity to your hosted service and update our internal documentation/knowledge base to do this for future deployments.

I'll configure the firewall at the hosting provider to block all traffic on port 5060 save for the published ranges from the SIP trunk provider.

Thanks as always

Dave

 

[AWS2P]

don't forget to close 5061 too, default pbx rule created port 5061 to be open (cloud pbx) and not used in my case ,I got hack attempt on this port last week