For now, we have decided to temporarily close port 8089 from abandoning webrts.
I’m pretty sure this hack is a user authentication bypass for [freepbxuser]
As you rightly noted [MAWalker]
In our installation, we use passwords of 32 characters (letters, numbers, special characters). Even for extensions.
I’m sure it’s a real backdoor that’s still open.
Asterisk 16.28.0
FreePBX 16.0.33
1 Like
Our current thinking is summarized here Recent reports of ARI exploit on FreePBX systems - #2
1 Like
Why in the world was this post flagged? Seriously. Me asking what version of Asterisk they had to I could try and replicate their issue was something that needed flagging?
GDJFC maybe ?
Oh I see, I can’t express any feelings. Got it.
Feelings accepted, nastiness less so ,honey vs vinegar . . , BAAMYSTYT
I’m going to do clean install Asterisk & FreePBX on Ubuntu 22.04 without all commercial modules which I absolutely do not need.
Just a single module - sysadmin. But I’m ready to give it up. Now it’s funny for me to watch unthinkable firewall settings in FreePBX.
I completely revised the security policy on the firewall before PBX.
And what is unthinkable about it? Seriously.
And if the only module wanted is sysadmin, then you are SOL on Ubuntu
- I really don’t like this module because I find the settings for trusted networks and hosts completely absurd.
- All I needed was solved by fail2ban.
In addition, I definitely recommend using a firewall before PBX.
For example pfSense.
The built-in firewall has already shown its “efficiency”. That a third-party application can easily connect like AMI (Stasis).
In this module it’s just convenient to set up email notification settings. No more.
It is not even capable of listening on the SNMP port to properly shut down the server.
I am not sure you fully understand how firewalls work.
I know how it works.
I said that I don’t like how it works. And how it is implemented in general.
The default firewall settings do not allow this access, that has been established. Exposing these ports to the public was done by a person. So no, a third party application cannot easily connect unless it was opened for them to connect to, which as we’ve been over a few times, requires someone to open it.
Yeah, I’m sure it was.
I totally agree. That is like walking around with a toolbox and the only thing in it is a hammer.
Yeah except, since I’m the one being referred to in that quote, I never said the ultimate answer is a firewall. Some how me asking about a firewall config meant that I was only focusing and blaming the firewall. Not that it might have been one question of many to gather info.
1 Like
All this is understandable and all this has already been discussed.
Yes, Port 8089 was open. And this is the back door for the attacker. We used the “Clicks for Call” buttons on the websites of our customers and because of this we suffered losses, fortunately small. Now we completely abandoned this function.
In my message, I only wrote that the built -in firewall is not proper protection.
Asterisk 16.28.0
FreePBX 16.0.33
Yes and that statement isn’t really correct or true. In fact, let’s see what your solution is so we can do a real comparison.
Firstly, I set that the connection to port 8089 can produce trusted devices (MAC address) and from trusted networks.
I also closed access to the web-gui and the UCP only from trusted networks. According to the logs - an incredible number of unsuccessful attempts was every day. In this case, the port of the connection.
I also had to configure the pfBlocker (on our pfSense) to block dubious addresses by GeoIP
(China, Asia, etc…).
This is definitely efficient. Now I see nothing suspicious with the PBX.