SIP ALG is not good to enable as you have a sip interpreter who modifies "uncontrolled" the sip messages to and from your 3CX. Most commonly this is better to be used at the client-side to ensure that the public IPs are inserted into the sip request and to overcome NAT issues. Most of the time I have seen it, it still breaks more than it solves.
The best protection is to limit the exposure of your sip port and may use a different sip port than the default 5060 port. This of course comes with its challenges when you have direct stun connected IP on dynamic IP addresses out there. Best to replace the remote workers with the 3CX Apps as they do not need the sip port to operate.
Now the truth to be told, if you expose any service, 3CX, WebSites or OWA you face the same challenge that someone rents a botnet and targets your WAN IP until your bandwidth is out of capacity. General, you have better chances to mitigate DDoS when you run services in the cloud as there is more capacity to play with. As 3CX is a 100% distributed system the thread is less for you than when you would be 1 of 100 thousand in a multi-tenant system.
I read a lot of comments online after the recent attacks to just use Cloudflare and all is solved. Unfortunately, this is not true. CF does and can not protect SIP, it is great for everything HTTP related though. Also if your sip trunk provider is targeted, porting numbers out is generally not beneficial. It takes time and it does not ensure that the next one you use will not be the next target. In case your provider is under attack 3CX offers you many peer-to-peer communications options to keep coms with your customers alive. Click2Call, Click2Meet and LiveChat can be greatly used in these cases.
Therefore, hiding as long as possible is the best start, have a contingency plan in place what to do in this case and apply all common IT related security takes to mitigate access to the system..
