Someone hacking into my FreePBX server?

To start off with, this server is NOT in production use. It has no paid trunking provider attached to it. I started TESTING some trunking providers through it is all. I’ve run FreePBX servers for years without a problem. So I’m trying to determine what I might have done wrong in this situation and am looking for insight. I thought it was setup the same as other machines I’ve done. It looks like someone got in, but perhaps it is something else (FYI, the test SIP trunks show no activity over them),

What I see in the CDR logs is a bunch of calls with a CallerID of 2022, that get Congestion, and have a destination of s[from-sip-external].

It then seems to start incrementing the Caller ID by 1. There were 2 attempts to dial 10 digit numbers as well it seems.


This got to something like 600 or so.

Fail2Ban blocked the offender, 74.36.254.123. IP lookup HERE implies it’s from Virginia and the Softlayer ISP

nslookup

[root@pbx]# nslookup 174.36.254.123
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
123.254.36.174.in-addr.arpa     name = 7b.fe.24ae.ip4.static.sl-reverse.com.

dig;

[root@pbx]# dig
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41122
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       17682   IN      NS      m.root-servers.net.
.                       17682   IN      NS      j.root-servers.net.
.                       17682   IN      NS      e.root-servers.net.
.                       17682   IN      NS      l.root-servers.net.
.                       17682   IN      NS      k.root-servers.net.
.                       17682   IN      NS      i.root-servers.net.
.                       17682   IN      NS      g.root-servers.net.
.                       17682   IN      NS      h.root-servers.net.
.                       17682   IN      NS      b.root-servers.net.
.                       17682   IN      NS      d.root-servers.net.
.                       17682   IN      NS      c.root-servers.net.
.                       17682   IN      NS      a.root-servers.net.
.                       17682   IN      NS      f.root-servers.net.

;; ADDITIONAL SECTION:
m.root-servers.net.     1543    IN      A       202.12.27.33
f.root-servers.net.     1697    IN      A       192.5.5.241

;; Query time: 16 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan  6 14:26:30 2016
;; MSG SIZE  rcvd: 273

fail2ban log shows;

[root@pbx jgould]# grep "Ban " /var/log/fail2ban.log | awk -F[\ \:] '{print $10,
1 174.36.254.123 [asterisk-iptables]

The FreePBX server is fully updated. It sits on the LAN behind a hardware firewall. To test out some service providers (twilio, voip.ms, flowroute, etc) I port forwarded UPD 10000-20000 like so many times before. I also port forwarded UDP 5060 as many ask you to do that (although I don’t currently have to do this in my other environments). I didn’t restrict those forwarded ports to specific IP addresses in the firewall, as I’ve never had to do that in the past. All providers use IP authentication (NOT SIP username/password registration). That is all I did. From there I set the trunks, outbound, and inbound routes for the SIP providers.

Unless something strange is going on at the SIP Trunking side, it seems like someone, somehow, got into the server. I’ve since disabled the trunks and stopped forwarding port 5060. After removing the IP from fail2ban, I don’t see anything. Could UDP 5060 being forwarding have been the problem?

FYI, had only setup and tested Twilio and Voip.ms.

@JayG30,

That is simply a random script (probably) that hit your system since 5060 is forwarded to your server. Since it appears you ‘allow guests’ but have anonymous SIP disabled, the calls are not recognized as coming from any configured trunks, and as such they are hitting the from-sip-external context which results in playing ss-noservice followed by congestion back to the caller, thus the final destination being the congestion app and thus the reason that each call is the exact same length.

There’s no security risk as far as the call making it any further. Of course if they happened to get lucky and hit an extension number and guess the password, then they could masquerade as an external extension and make fraudulent calls, but that’s always the risk of allowing external extensions and putting bad passwords.

Bottom line, no one broke into your system. If you don’t want to have it even hit your dialplan, then don’t allow SIP Guests from the SIP Settings module and you shouldn’t see anything anymore. Alternatively, if you have a finite set of IP addresses from your providers from the SIP ports, you could use your firewall to block those, though you probably can’t do the same for the UDP ports though that is not a big deal.

Thanks!

So this most likely wasn’t coming from the SIP provide(s) I was testing right? Someone just happen to hit this sites IP, saw the open 5060 port, and started running a script to attempt to make calls?

All extensions are local. No remote users (if I ever did, they would use a VPN). I was looking for the setting to turn off SIP Guest but was having a hard time finding it since the GUI update for 13. I tracked it down a bit before your post. I guess I turned this off in older version, as it seems to be on by default, but I can’t remember.

What I found odd was that a few years back I ran a PBX with my firewall port forwarding UDP 5060 and never got hit, and I don’t believe I restricted it to the IP of the SIP provider even. However, I was using a better router/firewall (like being able to accept/deny based on new, established, invalid, related state) and those sites didn’t seem to get hit with any of the common attacks you see scanning the web. This site with the PBX I’m testing has been hit with crytolocker attacks, RDP attacks, and last time I looked into the traffic they were constantly being attacked, probably because they were attacked years ago.

I highly recommend that you restrict SIP port 5060 to known IP addresses (or hostnames) on your firewall. You can’t do that for RTP ports, but the signaling port is where it matters.
Not doing so is bad security practice and invites hackers to make fraudulent calls from your system.

Someone needs to guess an existing extension and password, and will be able to register a client to your server as a remote extension and make calls. Guessing a long password is hard, but still, I wouldn’t risk it.
Lock SIP port 5060 down to known IP addresses and you will never see those hacking attempts.

If you want to use remote extensions with dynamic IP addresses, then use VPN for those.

On my production boxes I didn’t even have to open 5060.

@avayax is correct that where possible, if you know all the source IP addresses for your SIP signaling, then locking them down gives you the best protection. With external extensions, if you can restrict those to always use a VPN, then that id ideal.

If you have external extensions and can not require VPN access to them, you should use the Responsive FreePBX Firewall. There is a lot of intelligence built into this mode that will watch and throttle SIP registration and call attempts from outside sources such as external extensions. It has the affect of allowing all ‘honest’ attempts in and once recognized and validated, restrictions are removed. If those attempts are not able to properly validate (register or authenticate a call challenge) within a very few tries, the IP will be rejected. This means that a hacker must guess your password within a couple attempts or so or they will be rejected. As such, between this and a strong password, you are affectively guaranteed that attacks will be stopped in their tracks, while all your honest users will be let in, even if they accidentally fumble once or twice with the wrong password at first.