Now I have a different issue. The phones aren’t registering with FreePBX because “wrong password”, even though the passwords are correct. Any ideas?
If you are using the randomly automatic generated passwords from FreePBX, it is possible that your phones can’t use them due to excessive lengrh. Try a shorter password.
I reset the passwords due to a possible security breach, same length as before and they accepted them fine. But now I can’t get certain phones to accept their passwords.
Probably a typo
You’d think that, but I’m literally copying and pasting the passwords in.
If you are 100% sure that the password is OK, your phone IP might have been blocked by fail2ban due to multiple failed logins.
Could that be due to the breach we just had? Long story short a SIPVicious scan came through via our trunk’s public IP address and the intruder made their way into the system and started making a few calls. I’m in the process of changing all the passwords because of it but some of the phones won’t accept their new password.
Once your system has been breached, anything can be possible, worst should be assumed. If it were me, I would erase and reinstall from scratch, there is no way of knowing what kind of backdoors might have been left around, sitting there just waiting for the attacker to come back at you once again at any time. But hey, that is the paranoid in me talking.
Great minds think alike because I’m planning on doing exactly that: reinstalling from scratch and using a backup I created long before the breach.
Do you have your SIP ports open to the WWW?
If I understand port forwarding correctly, only the trunk’s public IP addresses are allowed to access the FreePBX systems. However the SIPVicious scan came from the trunk’s public IP address. VoicePulse claims there’s no intrusion on their end, but I’ve taken that with a grain of salt. I’m redoing the entire system today, changing passwords, port numbers, using TLS, IP authentication, etc.
You shouldn’t need to open port 5060 to everybody, just IPs absolutely known to you, like your VoSP. If you are expecting external endpoints to connect to your FreePBX, then that’s another story.
The ports were forwarded to only allow VoicePulse’s network through via those ports. What ended up happening was a SIPVicious scan came from one of those addresses within their network, allegedly.
I don’t have the best experience… But if you have your ports restricted to them, then they were the ones who got hacked, not you.
If someone hacks a SIP Provider, they gotta be crazy to try to connect to a PBX through the Trunk.
That’s exactly what I’ve been trying to tell VoicePulse but they insist it was on my end and not theirs. But the SIPVicious scan came through their network and the intruder has made some calls at our expense.
Maybe not. Note that according to RFC3261, the response to a SIP request that does not have an rport tag in the Via header will be sent to the address/port in Via, not the address/port that the request came from. So, an attacker with the ability to spoof the source IP address could bypass your whitelist and still have the response sent to his IP address.
This is difficult because most data centers and ISPs filter outbound packets whose source address is not assigned to them. The attacker would either need to use a data center without such filtering, or have a server in a center used by VoicePulse.
If you have packet captures of some of the SIPVicious traffic, you can determine whether this actually happened.
This is serious social engineering, if this is the case then i suggest you hiring a InfoSec professional and purchase some protection services, including a nice upgrade to your firewall. Otherwise, it WILL happen again.
I still believe that your SIP ports were/are not full locked down, I’d run a port scan with nmap against your public IP, see what ports are open etc.
IP spoofing was an idea I had in my head after the fact it happened. The plan for tomorrow is to lock down the firewall some more. Right now I’m rebuilding the FreePBX systems from scratch; stronger passwords, domain names instead of bare IP address, TLS, and IP authentication are high on the list. Once all that is finished and confirmed working I’ll go from there.
Rebuilding with stronger auth and encryption is a good idea, but you gotta find the root cause.
If your PBX or SIP ports are somehow exposed, you are facing the same problem, the only difference is that you are challenging the attacker with more advanced auth. Which is wrong.
Don’t expose your server again before you know what happened.
I’m not sure what firewall you use, but I’d go true every inbound and routing rule or run a port scan as mentioned earlier.
We use pfSense as our firewall. If I had to guess they got in via 5060 since that’s a very-well known port for SIP traffic and I used the defaults (bad I know now) to set this up.