Monday, February 23, 2015

Phantom Calls to Cisco Phone with Hosted VOIP Service - How to Lockdown

An issue was experienced where a number of VOIP phones on a customer network were experiencing phantom calls from the Internet.  A phantom call generally occurs when someone is scanning for SIP devices on a network using a port scanning program.  A port scan against SIP (usually UDP 5060 and 5061) will cause many SIP handsets to annoyingly ring and when the user answers, no one is there!

As you could gather, this is very annoying for users on the network.

The solution for this is locking down SIP to only the Public IP addresses of your SIP IP Gateway from your VOIP provider on the public interface of the router.  This customer was using a Cisco 887va router connected on a DSL connection so the public interface in this instance is dialer0.

First of all you need to create a access rule.  Here is the Access Rule I created (this matches the Faktortel VOIP providers public IP addresses here in Australia).  Faktortel also use 5062, 5063, 5064 and 5065 UDP ports for SIP communication.

ip access-list extended VOIPLockDown
remark allow SIP from certain addresses
permit udp host 202.43.66.55 any eq 5060
permit udp host 202.43.66.55 any eq 5061
permit udp host 202.43.66.55 any eq 5062
permit udp host 202.43.66.55 any eq 5063
permit udp host 202.43.66.55 any eq 5064
permit udp host 202.43.66.55 any eq 5065
permit udp host 202.43.66.1 any eq 5060
permit udp host 202.43.66.1 any eq 5061
permit udp host 202.43.66.1 any eq 5062
permit udp host 202.43.66.1 any eq 5063
permit udp host 202.43.66.1 any eq 5064
permit udp host 202.43.66.1 any eq 5065
permit udp host 202.43.66.2 any eq 5060
permit udp host 202.43.66.2 any eq 5061
permit udp host 202.43.66.2 any eq 5062
permit udp host 202.43.66.2 any eq 5063
permit udp host 202.43.66.2 any eq 5064
permit udp host 202.43.66.2 any eq 5065
permit udp host 202.43.66.3 any eq 5060
permit udp host 202.43.66.3 any eq 5061
permit udp host 202.43.66.3 any eq 5062
permit udp host 202.43.66.3 any eq 5063
permit udp host 202.43.66.3 any eq 5064
permit udp host 202.43.66.3 any eq 5065
permit udp host 202.43.66.4 any eq 5060
permit udp host 202.43.66.4 any eq 5061
permit udp host 202.43.66.4 any eq 5062
permit udp host 202.43.66.4 any eq 5063
permit udp host 202.43.66.4 any eq 5064
permit udp host 202.43.66.4 any eq 5065
permit udp host 202.43.66.5 any eq 5060
permit udp host 202.43.66.5 any eq 5061
permit udp host 202.43.66.5 any eq 5062
permit udp host 202.43.66.5 any eq 5063
permit udp host 202.43.66.5 any eq 5064
permit udp host 202.43.66.5 any eq 5065
remark
remark block SIP from all other addresses
deny udp any any eq 5060
deny udp any any eq 5061
deny udp any any eq 5062
deny udp any any eq 5063
deny udp any any eq 5064
deny udp any any eq 5065
remark
remark Allow all other IP traffic
permit ip any any


This rule permits all SIP traffic to all of their public IP addresses then blocks all other traffic entering on these ports and finally permits any/any.

Next you need to assign the access rule to the public interface on the router you wish to filter.  Because this is a Cisco 887va router on DSL, the public interface is Dialer0.  Simply apply the access rule to Dialer0 as follows:

interface dialer0
ip access-group VOIPLockDown in


After applying this config change, all phantom calls to phones on the network stopped.

Important: Some SIP providers use both TCP and UDP for SIP, so it can be useful to block both UDP and TCP on these port numbers.  For this customer, the SIP handsets only supported UDP so there was no point blocking the TCP ports.  If your not sure, block both by slightly modifying the config above.

2 comments:

  1. Fabulous Post! I like this topic.This site has lots of advantage.I found many interesting things from this site. It helps me in many ways.Thanks for posting this again. Thanks a million and please keep up the effective work Thank yo so much for sharing this kind of info- Same day delivery of a Skip

    ReplyDelete
  2. Hi Clint,

    Unfortunately this was only a temporary fix for me, with ghost calls still occurring. I suspect the portscan was run on a whole range of ports, not just common SIP ports.

    From the nat translations table...

    Router#show ip nat translations | in 5060
    udp 11.17.2.1:1150 192.168.21.16:5060 P.A.B.X:5060 P.A.B.X:5060

    I suspect that if the SIP invite scan was run on router address 11.17.2.1, and lets say they found port 1150 open (because of the nat translations dynamically mapping "11.17.2.1:1150" to the handset address "192.168.21.16:5060") the ghost call was successful. This is my theory.

    Would be interested to know your thoughts.

    FYI - We managed to completely stop ghost calls by applying a fix on the handset as suggested by the handset vendor. My other option was to make the router perform as a SPI firewall.

    ReplyDelete