Yealink Forums

Full Version: Ghost Calls from Port Scanning
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
(12-04-2014 07:24 AM)bnelson Wrote: [ -> ]Remstar:

Changing to TCP an a non 5060 port has worked for us in stubborn scanner situations. Scanners are generally kinda lazy and don't hit TCP ranges...yet.

I too am having trouble getting sip trust control to work properly. It works great if we only use our registration server's A-record, but using DNS-SRV records for redundancy results in a rejection since the SRV record technically doesn't match the actual name of the server communicating. The A-records are being stored in the local DNS cache, and are provisioned into the cache manuallly.

Anybody had success using this feature? Shuffling ports, and suggesting higher power routers with a decent firewall are not always good options.

How is changing TCP port doing anything when SIP uses UDP?
Our service supports using TCP as the SIP transport. Adds some latency, but it can be useful for situations like this, better battery life on mobile, bypassing SIP-ALG on verizon 4G hotspots, etc...

It does use more resources on the server however.

Edit: I just tested the "Allow IP Call" = No and I am no longer able to make an unsolicited call to the extension.

Looks like newer firmware versions may have fixed this since I last tried. I will test more, and update here with results. Looks like the sip trust control is not required to kill generic sip vicious scanner calls. A more advanced scann attack might still be able to gather the extension, but I'll cross that bridge when it happens...
(12-04-2014 07:34 AM)bnelson Wrote: [ -> ]Our service supports using TCP as the SIP transport. Adds some latency, but it can be useful for situations like this, better battery life on mobile, bypassing SIP-ALG on verizon 4G hotspots, etc...

It does use more resources on the server however.

Edit: I just tested the "Allow IP Call" = No and I am no longer able to make an unsolicited call to the extension.

Looks like newer firmware versions may have fixed this since I last tried. I will test more, and update here with results. Looks like the sip trust control is not required to kill generic sip vicious scanner calls. A more advanced scann attack might still be able to gather the extension, but I'll cross that bridge when it happens...

Hi all,

We have found that using a router with the tomato firmware fixes all theese issues.
Pages: 1 2 3
Reference URL's