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.
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”
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 , 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.
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.
http is also insecure. https authentication deemed absolutely essential, but even then https connections ‘leak’ critical info without SNI verification before forwarding to the provisioning server.
Noisy? Yes. Insecure? No.
sshd be configured insecurely? Yes.
As I posted, if you
- denied root login
- denied password logins
Then you are still noisy but secure. it would assume public key logins, unless you leak your cert. If 2 then you don’t need 1, I like quiet and secure. If you are hyper paranoid then you can PAM rotate and more such . . .
Thanks for the help here. In context Freepbx GUI this refers to Port To Listen On, Domain the transport comes from in Asterisk SIP Settings?
This system is not in a domain.
It will behoove you to get a domain, either real or by dynamic dns, That way incoming connections will only pass muster if they are directed to that domain and you tell the client to register against such domain and not an IP address, even the dynamic DNS IP will generally be quite stable as to what the ip address is.
Meaning the SIP Server value changes to host.domain.com rather than the IP xxx.xxx.xxx.xxx
A caller would be firstname.lastname@example.org and having Domain the transport comes from means any callers not @host.domain.com are rejected. Correct?
Implementing a domain for this box immediately.
If using chan_sip add to /etc/asterisk/sip_general_custom.conf
if using chan_pjsip, as you noted
current versions of fail2ban should capture the bad guys