saygon90 11mo ago • 100%
don't have the webinterface exposed to the Internet.
+1
I will try to hide FreePBX behind an SBC like LibreSBC.
saygon90 11mo ago • 100%
Don’t allow 5060/UDP.
Here is the crux of the matter. The provider registers with the PBX, unlike the usual scenario where the PBX registers with the provider. Consequently, I cannot close or change this port. If I do, the telephony will stop working altogether.
Also, can you configure an external firewall? (Router if local or cloud firewall)
Currently, the router only allows traffic on port 5060/UDP-TCP from a specific IP address. It's safe enough, but only until we open the ports to the entire internet.
One of the reasons I posted this question here is, among other things, an attempt to filter out fake calls from CDR Reports. Even if a call doesn't go through, the attempt will be recorded in the report. So instead of 100 records a day, it could be even 10,000, and that's exactly what I don't want.
saygon90 11mo ago • 100%
Is this script actively developed and updated, or are you using your own solution?
saygon90 11mo ago • 100%
My suggestion would be that you should know which extensions are nomadic and setup your configuration such to only allow those to register from outside your network and the non-nomadic ones only from within.
The main challenge with such solutions is the dynamic IPs of clients. Unfortunately, I cannot whitelist clients because they will be logging in from different IPs every day.
Make sure you are using complex passwords and different ones for each extension.
I use passwords that are generated automatically by FreePBX, and these passwords are presumably complex enough.
saygon90 11mo ago • 100%
The exploit you mentioned was targeted at the REST API or the web interface, if I'm not mistaken. Both of these components will not be exposed to the network.
Consider installing a Session Border Controller (SBC) for more security.
Regarding the Session Border Controller (SBC), I found a very interesting project, LibreSBC.
Hi, due to a very extensive project, we need to expose FreePBX to the internet. Specifically, we are concerned with the SIP and RTP ports. The purpose of this action is to allow logging into the system using softphones and configured phones without the need for VPN. In the past, I noticed that exposing port 5060 results in numerous brute force attacks where the attacker tries to impersonate an extension that exists in the system. However, due to the lack of a password, they are unable to make a phone call. Does an attacker, without knowledge of the extension password, have the ability to make calls at the expense of the client? Ports such as 443, 80, 22, etc., will not be exposed to the world, only the ports required for telephony.