Is your Polycom Phone under attack?

Anyone that has worked in telecom long enough has been hit by a SIP scanner at some point in time.

For people in NOC / Support teams, they often have a customer open a ticket where the call goes like this:

Caller : “My phone is randomly ringing and will not stop.”

Tech Support : “Let me look at the logs.”

Tech Support reviews the logs, while the customer enjoys hold music that isn’t even fit for an elevator. 

10 minutes later

Tech Support : “I’m happy to report that we are not sending any calls to your device during that time. Your ticket number is 222444555, have a great day”

A few days later the caller is back on the phone. They are furious as the issue is still happening. The support team doesn’t see the call in the logs, as it didn’t traverse through the VoIP providers core.

Thankfully for those with Polycom phones, you can make a change to the device’s XML file to block unsolicited INVITES.

All you need is this:

< voIpProt.SIP.requestValidation.1.request=”INVITE” voIpProt.SIP.requestValidation.1.method=”source”/>

Once applied, if the phone receives an INVITE from a device other than the IP of reg.1.server.address, it will reject the request with a SIP 400 BAD REQUEST.

Now instead of the user experiencing a phone that rings non-stop, they see and hear nothing.

Bad Guy – Blocked!

 

Research: I tested this with a VVX 500 (5.2 software)  and a SIP testing tool know as SIPP. I sent over 50 calls per second to the device while it was on an active call. During the active call I did not experience any audio issues.

When the call was disconnected, I did experience a phone that acted “slower” than normal to return to the home screen. Going off hook also introduced about a 1 second delay before presenting dial tone.

 

 

 

 

 

 

 

 

Acme Packet – Reject calls from a specific number

It’s been a while since my last update. Having another kid definitely limits the time to create a post, however she is sleeping right now. I’m sitting here with a Red Bull in one hand and a Secure CRT window open and ready to go.

Occasionally in the carrier world, your network might be blasted with a large number of calls from a dialer. While certain devices on the network might be able to handle the calls per second increase, others could experience an issue due to licensing. For instance, if you are running a BroadWorks Network Server and you are licensed for “X” transactions per second and this dialer puts you over the limit , you will start rejecting calls from valid subscribers.

Using the Acme Packet Net-Net series you have a few options for blocking these call attempts. One way is to route the calls to a fake realm / session agent and reject it from there. The issue with this method is that a SIP 503 is sent back up stream. If you have requested your upstream carrier to route advance upon receiving a 503, you’ve succeeded in migrating these call attempts to a different trunk on your network. This is most likely not what you are looking for. Instead you will need to have the SBC translate the 503 to a different response code.

Lets start with the mechanics of the response map. This actually very straight forward. you first supply a name for the response-map. Next you enter the transmitted code (recv-code : 503) and what you want it translated to (xmit-code : 404). You can also add a custom reason to the response code.


session-router
sip-response-map
name rejectCaller
entries
recv-code 503
xmit-code 404
reason "User not Found"
method
done
exit
done
exit


From here, you need a few more items in place (a realm, local-policy, an interface and a session-agent)

conf t
media-manager
realm-config
identifier rejectCaller
addr-prefix 0.0.0.0
network-interfaces M00:
average-rate-limit 16000
access-control-trust-level low
invalid-signal-threshold 1
maximum-signal-threshold 100
untrusted-signal-threshold 30
deny-period 60
done
exit

Next, you need a sip-interface:


sip-interface
state enabled
realm-id rejectCaller
description
sip-port
address 1.1.1.1
port 5060
transport-protocol UDP
tls-profile
allow-anonymous all
ims-aka-profile
done
exit
done
exit

…a Session Agent (notice the ‘local-response-code’ value is populated. This is where you enter the name of the response map that you have created)


session-agent
hostname 1.1.1.2
port 5060
state enabled
app-protocol SIP
transport-method UDP
realm-id rejectCaller
egress-realm-id
description "SA to apply response-map"
carriers
allow-next-hop-lp enabled
constraints disabled
max-sessions 1
max-inbound-sessions 1
max-outbound-sessions 1
max-burst-rate 1
max-inbound-burst-rate 1
max-outbound-burst-rate 1
max-sustain-rate 1
max-inbound-sustain-rate 1
max-outbound-sustain-rate 1
min-seizures 1
min-asr 1
time-to-resume 1
ttr-no-response 1
in-service-period 1
burst-rate-window 1
sustain-rate-window 1
local-response-map rejectCaller
done
exit

…A local-policy for routing of course :


local-policy
from-address +14801111111
to-address *
source-realm
description "Policy to send harassing calls to a fake SA"
activate-time N/A
deactivate-time N/A
state enabled
policy-priority none
policy-attribute
next-hop 1.1.1.2
realm rejectCaller
action none
app-protocol SIP
state enabled
methods INVITE
done
exit
done
exit

Add these config sections, perform a save / activate and you should be set.