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.
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.
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.
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