I apologize if I have missed someone’s post, but I have four different customers using a mix of PBXact and Freepbx free distro that have been used to make calls to (for some reason) South Dakota (area code 605) and Iowa (area code 641). All these customers are using Flowroute and each has on their respective Flowroute account IP authentication on and outgoing credentials disabled. But that’s not the source of the problem, it’s the PBX that’s being used to making the unauthorized calls.
I really did a lot of research before I decided to post this and I learned from posts by Lorne Gaetz, Dicko, and a few other experts that I needed to do a few things like remove the T from the Asterisk Outbound Trunk Dial Options in Advanced Settings and remove the Tt from the Asterisk Dial Options in Advanced Settings. I also have fail2ban on and all extensions are using the default complex password assigned by the system.
So the question is this: what else do I need to do to totally stop unauthorized calls from being made? My customers are hopping mad that almost $100 worth of calls were made from people’s extensions (usually, one or two extensions on each system).
To stem the tide of calls to those area codes, I used the advice put forth in this post: https://www.freepbx.org/restricting-outbound-calls-in-freepbx-blacklist/ but I’m not sure that the things I put in place from that post are the right things to do because tomorrow, someone could breach a system and call a completely different area code.
Again, I have searched the forums and the rest of what Google has to offer using all kinds of search terms and all I came up with is mentioned in this post.
Is there a definitive guide that details without a bunch of Linux file manipulation how to make a system bulletproof against unauthorized calls?
Generally, security should be your top priority. I’d make sure anonymous login and ‘sip guests’ are disabled, use complex passwords and non-standard extension starting points (one client of mine starts at 8902, 8903 and so on), don’t expose ports to clearnet (internet) unless that port exposure is explicitly necessary. Responsive firewall should be off and if you have remote employees, use the builtin vpn that comes with the $25 sysadmin pro module. Use TLS and SRTP whenever possible, as well.
Thanks, Two of the systems are using both a WAN IP and a LAN IP because they have no firewall. Others are using just a LAN port because they are behind a SonicWALL firewall. Yet, all were breached for unauthorized calls from people’s extensions. I read somewhere that this is done by calling the Inbound Route, getting an IVR or someone’s voicemail, and then pressing key sequences to open up outside lines. All the unauthorized calls were sequential numbers so it looks like someone used the systems to make SPAM calls. Anonymous login and SIP guests are disabled on all my systems from the time I built or configured them. All ports exposed to the Internet are either firewalled to only accept certain IPs or they are set to Local in the Services section of the Firewall. I use for the root and GUI passwords that are 12 characters and complex using all four of the character types.
Is Responsive Firewall supposed to be off if the system is not behind an external firewall? Unfortunately, I don’t have much say with extension starting points because I usually replace outdated analog systems where extensions are ingrained in the customer’s culture.
I do use the VPN for any remote employees. I always sell Sangoma phones with my systems, except for free distro systems to churches who can’t afford them so they use cheap Polycoms and other brands.
sngrep is a good starting point tool to give you the ability to drill-down into calls but a nice addition is pcapsipdump that separates all the calls into identifiably named .pcap files in identifiable directories named by day and hour, these pcaps can be analysed more by sngrep and wireshark quite painlessly.
Turning on DTMF logging might also help if the calls are so ‘escaping’. But the pcap files and wireshark might be a more direct route.
Did any of these calls occur within the past week? If so (with default settings), the Asterisk log for the calls will still be on the system. If possible, pick one that occurred when the business was closed and the system was otherwise idle or nearly so. Paste everything starting one minute before the 605 or 641 number appeared, through the end of the call, at pastebin.freepbx.org and post the link here.
Thanks, Dicko! I have found your posts to be incredibly helpful since I started dealing with Freepbx a year and a half ago. You’re a national treasure!
The last illicit call was made on August 5, and I checked the /var/log/asterisk/full log but could not find anything with that date. The call does show up in the CDR reports, but I don’t know what could be garnered from that.
I do see a few attempts at registering extensions that I didn’t configure but they all fail with wrong passwords.
Example: [2020-08-08 04:30:58] NOTICE[10107] chan_sip.c: Registration from ‘“1000” sip:[email protected]’ failed for ‘51.89.16.194:6089’ - Wrong password
What can be determined from this? I just took this screenshot from sngrep and it shows that there are multiple attempts to make international calls from the PBX. How do I stop this?
OK, you need to RTFM a little for sngrep , filter only the “INVITES” to unclutter the screen ( F7 ) then press enter on the call of interest, most of the calls I see are being blocked (no replies from the PBX) so find one that has more than 1 in the ‘message’ column, that will show all of the messages which you can scroll through, for more detail press enter or space on one suspect,
Sorry for the delay. Here’s the URL for the pastebin entry. As you requested, I copied one minute before the call, the call, and one minute after the call. The call starts on line 212.
Some hacker in Palestine has the password for extension 122. At least two things are likely wrong. First, why are you allowing an unknown IP to access the system? But more importantly, how did he get the password? My suspicion is that your provisioning system is wide open and he guessed the MAC address for the device on ext. 122.
To which password are you referring? His extension password was produced by the system and is complex, as is the User password in the extension settings (both 32 characters). He is also the second person there to have his extension used for unauthorized calls. The customer uses Flowroute and only their IPs are entered in the Match field in the trunk configuration. What else can I do to secure this system?
This also happened to three other customers, so obviously I’m not closing all the holes, but as I mentioned in my original post, I did configure everything that I saw detailed in other posts like mine.
I’m not sure what you mean by the provisioning system being wide open; both the root account and the GUI admin account are equipped with 12-character complex passwords. I’m too much of a neophyte to tell right away what you identified, but considering that this particular system is not behind a firewall and has no edge device, and the same thing happened to boxes that were behind firewalls, I’m at a loss about how to stop this.
I will say that when I changed the Asterisk Trunk Dial Options by removing the T, and removing the Tt is the dialing options in Advanced Settings, the calls stopped. Could this be a case where the caller just called the business, entered the transfer codes through some sort of automatic dialing process, and made all those calls?
Make/model of the phone(s) used on this extension? How provisioned (TFTP, HTTP, HTTPS, etc.)? Provisioning data created how (manually, OSS EPM, commercial EPM)? What, if anything, prevents an intruder from accessing this data (which of course contains the extension number and password)?
Yes. In my opinion these are dangerous and obsolete options that are only needed if you use analog devices and only in few situations. These options should be disabled by default!
Possibly, you have had other fraudulent calls that used the transfer codes, but in this call, the attacker registered his software as if it were a normal device and made a normal outbound call.
I thought the “Disallow transfer features for inbound callers” = yes in Advanced Settings removes the ability for the *2 and ## in-call transfers from happening, for callers that enter from an inbound route?
There was a bug fixed. Maybe there’s another one. My point remains that if you don’t need this feature it should not be enabled. Most any modern SIP phone can do SIP transfers and this inband stuff is not needed.
