crontab -u root -l returned nothing
crontab -u asterisk -l output below
https://pastebin.freepbx.org/view/3a614444
Well thereâs nothing weird there. Looks like it supposed to. So they arenât running cronjobs to give them access again.
Just want to point out that youâre showing a couple lines from the CDR reports that show calls going to a 607 area code, which is a high cost pump and dump location, but your pastebin is a call for the 303 area code Denver. It doesnât match up.
I am a little confused whatâs happening here. Can OP please elaborate on the below?
Where are the calls coming from? Is it an active extension which gets a new registration from these hackers?
Since this started happening, is it happening from one extension only?
Did you change the password(s)?
If the calls are coming from the same IP as the legit phone is registered from, have you looked into if the calls are actually being generated from the real phone?
Hello,
I have a different telephone system, but it sounds exactly what was happening to us. Sorry if I missed what type of service provider that you are using, but we are using a SIP Trunk. What I found out is that we were under a SIPVicious attack. Below is a summary of a debug.
SIP : Ghost call. SIP Port scanned from outside.
Symptom Ghost call. It appears that the codec is calling itself automatically. Placing a codec on a public IP will cause calls from SIP scanners. These scanners (e.g. SipVicious) are used to detect possibilities for exploiting PSTN trunks.
Condition The system is on public IP or reachable from the outside and not protected well enough. This makes it possible to initiate SIP calls over direct IP.
Workaround Make sure the system is well protected and that it is placed in DMZ if you need to have it on public IP. It is possible to only allow calls from the VCS by disabling the listenport on 5060/5061, but then SIP outbound needs to be enabled so that the VCS can reach the endpoint.
xConfiguration SIP ListenPort: On
xConfiguration SIP Profile 1 Outbound: On
What I did was a UDP port scan from the pubic internet against our IP address xxx.xxx.xxx.xxx for port 5060 and itâs open. I did a Wireshark and found that the attacks were coming from my SIP trunk provider through their public internet and into our SIP Trunk. They put on an ACL to block 5060 access from the internet to our SIP Trunk VPN, and that fixed it!
I hope that you find a solution, it took me 4 months and a support tech from the SIP Trunk provider and from my telephone engineers to figure this one out with both pointing the finger at each other, when I was the one that ended up finding this problem out and told them both what was going on.
Disable SIP Guest.
It is and has been disabled.
Hi. I had the same issue and it was affecting all my customer PBXs. I am using Flowroute as the SIP carrier. I finally solved the issue by turning off Responsive Firewall, and putting all my Internet-facing systems behind firewalls. I made NAT policies to allow 5160 PJSIP traffic only from the Flowroute POP IPs and made sure the WAN to LAN firewall rules only allowed 5160 from the FLowroute IPs. I havenât had a problem since. I want to give thanks to Lorne Gaetz, Dicko, Cynjut and Stewart1 among others who pointed me in the right direction. Dicko suggested that I use SNGREP which is very revealing and helped me to see what was really happening in those calls.
Having ârevealedâ all these connections, again I suggest (yeah, just like a broken record) why donât you just NOT use 5000-5999/UDP for your SIP signalling. If you donât , you will still âhearâ all that crap, but it canât go anywhere detrimental.
The App column in my CDR report shows Return for these calls. Any idea what Return means here and did you see this in your situation?
I actually am using your advice on all new systems. The few that I already built are accessed by softphones and remote phones so changing the port was problematic for some users of the high whine variety.
Have them replace whine with p(h)ort , (it is after all a âfortified whineâ) adding :54367 or another filled field is not hard.
Edit:-
How are you provisioning these phones? if under your control, pre-prepare the new provisioning files with the new port, send âsip notifiesâ while they are still on 5060 if you can so the phones reboot, restart asterisk so the new ports are being used, wait for the BMWâs (BitchMoanWhineâs) , you will be pre-prepared while watching sngrep for the failures, and fix them pro-actively as needed.
Additional advice, replace any IPâs in the provisioning with a real domain and limit access only to registrations and invites to that domain and not to the IP.
If you click on the blue highlighted links you will be able to see more of the path the call took.
Please explain âNOT use 5000-5999/UDP for your SIP signallingâ
âSIP signalling.â
Is this the Port To Listen On in Asterisk SIP Settings or the SIP Server Port in Trunk or something else completely?
Is this port for an extension to talk to the PBX or the port for the PBX to talk to the SIP provider?
One of my problems is my background is computers and network, not telephony. I probably know more than most not telephony techs but I have to keep looking up telephony terms and am approaching this without a lot of depth. Folks are great and want to help but I often get suggestions without enough details to implement the change, âReplace the gizmoâ but no mention of where that setting is or what the effect of the change is. I am paddling as fast as I can.
There used to be Theory Of Operation manuals and I find myself really lacking that kind of overview.
Using obscure bind addresses for SIP signaling is fine for keeping logs quiet, but not a strong security step in and of itself. If provisioning files are exposed to untrusted traffic [which is very likely given the small amount of info provided] hiding your signaling ports will have ZERO effect.
As such, you probably know that ssh on 22 is noisy and insecure, can I assume for ssh you
- Changed the port
- denied root login
- denied password logins
If so you should be following on. . .
It is analogous, SIP connections by default use UDP/5060 once upon a time in FreePBX chan_sip, now chan_pjsip, and chan_sip is 5160, but everyone knows that so that is where you expose yourself as 99.99% of the attacks are directed at those protocol/ports.
So yes, contrive to listen on other ports (by experience few will look outside 5000-5999 and any firewall worth itâs salt will stop port scans dead in their tracks)
Some VSPâs wonât allow you changing that port so a simple firewall rule to only allow those originating IPâs on that port will suffice for outbound calls. But trunks are either by IP or registration, so you are not actually listening for inbound calls to open the connection.
All other extensions will need to contact your PBX on the defined listening ports , UDP/5060 is the least secure, then UDP/5160, then TCP/506[01] , so move them. Adding a conditional domain name to allowed connections effectively drops âdrive-byâ attempts at your IP address
TLS/5061 is pretty well universal but only works with domain names and certificates, you can make that much more secure by having the connections check client and server certs, which the knuckle draggers very rarely attempt for obvious reasons.
Edit: in response to @lgaetz post.
Provisioning over https provides good protection against drive-byâs be wary of MITM vulnerabilities, for very solid security add an HAproxy with SNI lookup and verification between your PBX and the internet, relatively easily done on the PBX itself and stops any leaks for connections without a server name attached. I would add that that should be totally transparent to FreePBX operations, it would just send the crap to the bit-bucket. (Would that HAproxy could proxy SIP, alas, not yet . . .)
Hope that helps a little.
I minimize conversion pain with a port forward so both ports work during a transition period. Pick off the stragglers at your convenience and kill the forward once everyone is cut over.
1 Like
Nice call !
Additionally make sure your fail2ban is +0.8 and the recidive jail is enabled and the bantime etc. are âhorridâ , enable jails for otherwise ignored probes as rarely do I see an intensive attack that is not precursed by other probes identifying your server as a FreePBX deployment.
Re: Provisioning files exposed.
This is how it is set from instruction given earlier regarding the weakness of provisioning with FTP. It was explained that TFTP and HTTP were more secure.
Disable the TFTP server. Itâs insecure as hell.
1 Like