FreePBX "forgets" permit setting for SIP extension

Somehow FreePBX keeps forgetting the permit setting on a SIP extension and that account keeps getting compromised.

Set. Submit. Apply. Reboot.

Setting still there.

Wait a few days… account is calling all over hell and the permit setting is back to 0.0.0.0.

I’m more inclined to think that someone is doing this than FreePBX is erroring, but as there’s no auditing, I’m not sure how to check.

Am I reading this right???

You have someone comprising an extension by you did not block the attacker? Even more, you have port 80 or 22 open to the WWW?

There’s no nice audit log at the moment, but have you tried searching the community?



https://wiki.freepbx.org/display/FPG/Asterisk+Logfiles

I suggest you taking a look at the firewall module and start locking things down…

Searching the community is how I found out there is not currently an audit log, but that they are open to someone else coding it.

Blocking the attacker… that’s a fruitless endeavor.

Port 22 isn’t a concern. It’s a strong password on a unique username and if OpenSSH is compromised, we all have bigger things to worry about.

Port 80 is open so users can access the UCP. There’s no viable way around that, but that is also why I was looking for suggestions on how it might be changed so I can attempt to shore that up.

There’s not much else I can lock down at layers 3 and 4.

Did you read the links I shared?

Wut? Use long passwords, use fail2ban, FreePBX Firewall etc.

Not sure why you are saying this, you can set UCP on a custom port.

There were plenty discussions here how to secure your PBX while having remote connections, some techniques I mentioned above, you can also use Dyn DNS to update IP’s in your FreePBX Firewall to allow traffic. There’s a lot what you can do.

disable http in the firewall and allow only https. as long as it Is setup right ucp will work by going to https://ip-of-the-pbx:4443 (assuming you are using the default port setting). be sure to install a certificate - the let’s encrypt works perfectly for this. do the same thing for the pbx gui interface - allow only https. we have our set so that you can access the pbx gui only via https and only from specific ip addresses. if you need to be mobile, use dyndns and their software client updater and put your url into the firewall (note I said url not ip address). we always use certificates for ssh access and disable the ability to get in using a password.

I use all of those things. Somehow the permit line still gets changed.

I can, but changing to a non-default port doesn’t exactly stop the problem. They’ll find it.

I don’t see what relevance HTTP vs. HTTPS has. Let’s Encrypt is setup, but being HTTPS wouldn’t have any meaningful change.

just trying help. Https is generally more secure (encryption, etc) if setup properly so that if someone were monitoring your web traffic they could not see your user id and password. by the way be sure to white list your management ip’s in fail2ban and set the ban time to a really big number, set the retry to 1 or if you are bold 2, and set the find time to a pretty big number. this will not stop guys trying to get into the system, but when they do their ip is blocked for the duration of the ban time. it sounds to be that someone has already gotten into your system. I would not trust anything. there is no auditing of the changes themselves but you should be able to see who has logged into the system. if you don’t want to start over, then look at what ssh users have been created on the system and if there any you don’t recognize get rid of them. do the same thing for the pbx gui. change all the passwords. as I said though, we only allow https access to the gui and only from specific ip addresses.

You are apparently still allowing the attacker to make changes. Is 5060 open publicly?

Of course it’s open publicly. There are no other viable options of connecting to clients. 5060 being open wouldn’t have any impact on FreePBX’s configuration changing.

Of course you can, either restrict to known IP’s or use the FreePBX firewall and allow only from dyn addresses.

5060 is enough for the attacker to place calls.

I’m concerned with the changing of the FreePBX configuration at this point. You’re trying to solve the wrong problem.

If you don’t like help, just say it.

You said you have port 80 and 5060 open publicly, I gave you ideas how to lock it down, you refused to acknowledge that by saying “there’s no other way around besides having it public”

AFTER you have your PBX secured, i’d start looking for users who have admin rights, perhaps check under administrators if there’s a suspicious account

As you should be, any other considerations in this thread are secondary. I can think of no other explanation other than the box is compromised.

3 Likes

I totally agree. The activities that you are reporting are unheard of except within systems that are no longer under administrator control. Your only option at this point is to start over and reinstall the system, but this time, don’t leave the box exposed to the Internet as you have in the past.

It might be too late now, but if you had rkhunter installed

http://rkhunter.sourceforge.net/
https://sourceforge.net/p/rkhunter/rkh_code/ci/master/tree/files/README

and you added

USER_FILEPROP_FILES_DIRS=/etc/asterisk

to /etc/rkhunter.conf, then you would get an email whenever A) any file in that directory had changed AND B) rkhunter was run, by default that s once a day but edit the cron job if you want better granularity. Of course you will get an email when you intentionally madew a change, but of course you could ignore such emails

There are many other advantages to having rkhunter available

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.