I’m very new to this, and not terrifically qualified to handle some of these issues…
We are running a FreePBX system in association with trixbox. We just recently took the system online and began making updates to get it setup with sipstation. In the process of launching that update, the system was hacked. Luckily, sipstation on my system isn’t setup for international calls, so that isn’t working, but the system itself has been compromised. We were hooked up to land lines, and they were able to use those for a night, those have since been disabled.
I’m trying to figure out how to fully lock it down so they can’t get in. It seems that per the logs, they’re still able to access, they just can’t make the phone calls they want to. They’re playing with different extensions that I haven’t built.
I was running freepbx 2.4, updated it to 2.8 with the update tool, but I’m not sure if fail2ban is even on this system, or how to get it there.
Sorry, I’m in a bit over my head here, just wanted to see if someone could point me in the right direction.
I don’t understand what “in association with trixbox” means.
You are using very old versions of FreePBX and if this was installed by trixbox then they are not even real FreePBX.
The trixbox project was abandoned several years ago.
If this is a new installation you should be using a supported version.
Security best practices for Asterisk and FreePBX are well documented on the Internet. If you are not familiar with IP security I would suggest you engage someone who does.
Now that you are compromised it is going to be best to wipe and start over on a newer currently supported distro, as you really have no way of knowing what has been changed or how deep the compromise is.
If you are still running trixbox you are asking for trouble. Download the latest FreePBX distro and install everything from scratch. Once the system is up the first thing you do is setup your iptables firewall. Then set “Allow Anonymous Inbound SIP Calls” to NO and allow guests to NO. This will only allow SIP calls from registered trunks. Create your extensions with proper “secrets” not 1234.
Another option is to outsource the whole system and just register your extensions with a FreePBX provider. That way you don’t have to worry (too much) about security and maintaining the system.
And you should start by not exposing the box to the Internet.
Like any untrusted IP device you should start with a deny all policy and only open up needed services to known hosts.
BTW, SIP port 5060 can’t be used to make any changes to the system. It can be used to mount denial of service attacks and steal service. To be able to modify the system you must have SSH, SSL, HTTP, RLOGIN or other Linux services that allows remote sessions or RPC’s
The only thing part of the box exposed to the net are the port forwards for the sipstation trunk lines. Everything else is behind a firewall.
I’ll begin making plans to rebuild the entire system with the latest distro, that sounds like the best course of action, then I can easily rebuild the extension list and re-program the phones, it’s a small system, only 14 extensions exist.
Thanks for all your assistance, I appreciate it greatly.
You can install the FreePBX 2.6 bulk extensions module on the tribox and then reimport them on the new FreePBX.
You can also copy greetings from the /var/lib/asterisk/sounds/customer directory to the new machine and the whole voice at /var/lib/asterisk/voicemail (after recreating extensions).
My first recommendation would be not to use Trixbox because it still has many well know FreePBX vulnerabilites that everyone else has fixed. If that doesn’t work for you my second recommendation is to disable apache when you are not using the gui because it’s easy and I think everything still works without it and should (although I make no guarantees and will not be held responsible) prevent any hacker access. That way you just turn on apache when you need to make a config change which is all the gui is used for. It just generates asterisk config files.
Of course you could also explore vpn type solutions to block http access. You could explore going in and patching all the security problems but I wouldn’t recommend going that route. There are several and I’m not sure if it’s possible to do a proper job of it.
If it’s already been exposed then you need to go in there and clear out anything the hacker may have done to give themselves more access. Go into /etc/shadow and make sure nothing has a password that shouldn’t. Usually only root will have a password unless you created additional accounts. You can tell which users have passwords because they are the only ones with a long hash #. Also check /home/ for any user accounts and any public keys in those accounts. Check /root/.ssh for a key as well. If you find none of these things then they probably never got root access and the server is probably still in good shape.
Then you gotta clean out the c99shell script they probably injected which is what gives them access in the first place. You will usually find that in /var/www/html/panel and/or /var/www/html/recording. It’s a php file that is about 160kb in size which makes it stand out in those directories. There are some other easy ways to find them which I don’t want to share and give hackers ideas how to mask their activity. I’ll just say that basically hackers are lazy and self serving so they have blind spots when it comes to their activity and I use that to my advantage.
I have a lot of first hand experience with this unfortunately back when FreePBX still had these vulnerabilities and in the case of Trixbox…still does. More recently with Elastix because of a relatively new vulnerability found with vtiger which Elastix installs by default.