I have a few remote extensions that are registered to my PBX. All of them are fine except for one. It is getting random phone calls from extension numbers that are not registered on my system. They only last for a few seconds and show up as caller ID SIP:601, 400, 300 and etc. I do not see any of these numbers in sngrep attempt to register. This is the only endpoint to appear to have this issue. Possibly line interference?
SIPVicious. Easy way to handle is to set your phones to only allow SIP from your registrar and/or proxy server. Also disable IP calling if you don’t use it.
1 Like
SIPVicious? possibly or one of many other vectors that glom on servers with UDP/5060 open. Even better way to handle is to set your PBX to only allow SIP connections from your extensions, registrar and/or proxy server on a port outside the 5000-5999 range. Pinhole any recalcitrant servers if necessary, (Your extensions will never be recalcitrant.)
Not related to the OP’s issue. The attacks are going directly to the remote phones.
How do I turn these off?
Just so there is more context, I have 5 remote extensions. There is only one that is getting random calls, and I can’t even see these calls from the UCP end of things. Just in the recent calls of the polycom phone. The phone even rang when it was on DND mode so I suspect there is either an issue with the phone or something really weird happening on the PBX end.
When you set your extensions to be working with your now more secure PBX (not using UDP/5060) , it should be obvious that they would no longer be responding on UDP/5060 unless you had them do back-flips
Not true. The problem is that the local port on the phone is 5060. You can change that without doing anything at the PBX (other than running EPM, if applicable).
However, if supported by the phone, @adell4444 's solution is more robust.
1 Like
Either you or I have strange phones, If mine are set to use my proxy and my registrar they are well behaved. The more layers of security you add can only be more secure. Wanna be well covered, then just use TLS. Then even the most vicious Sid can’t ring your bell.
Sure, and it’s the best long term solution. But it’s a lot of work and the OP just wants to push a button and make the damn ghost calls stop. This is a well understood problem and there are usually several easy solutions. For example, see
https://support.yealink.com/en/portal/knowledge/show?id=14404b55bd9e4ca05aba334b
Not quite a button push but close, do what I suggest and
“iptables -A INPUT -p any –dport 5000-5999 -j DROP”
TLS takes a couple more and a valid certificate, that’s all
Not true. The connection is being made from the attacker directly to the remote phone. The PBX is not involved at all.
Depending on the equipment at the remote site, fixes that don’t involve TLS include:
Setting the router/firewall to not accept packets from the attacker’s IP (address-restricted or symmetrical NAT, filtering by source IP, etc.), setting the phone to only accept packets from the registrar, setting the phone to only accept requests with the correct extension number, or using an obscure local port.
1 Like
Is the port 5060 forwarded to the phone in the router ? I had this once (UPNP, SIP ALG or something like that caused it, I don’t quite remember)
2 Likes
On my network 5060 is forwarded. But on the net work of that (getting random SIPvisous calls) phone, 5060 is not opened.
What is the make/model of the phone getting the ghost calls? Make/model of the router/firewall to which it is connected?
It was a Polycom VVX301, he is connected to an acer router. My equipment is behind a Cisco RV310
See
In addition to the two validation methods suggested there, I would also change
voIpProt.SIP.local.port to an obscure value (not 5060 or other commonly probed port).
2 Likes
I would suggest that any firmware that is 8 years out of date be replaced, we have several hundred Polycoms in the 3,4 and 5 hardware series, all have Firmware installed at ‘level 5 firmware’ none seem open to such attacks. but very old firmware needs a careful upgrade process, (RTFM here )
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.