Blacklisting with Local Routing Tables
Several industry groups such as the GSMA Fraud Forum and the Communications Fraud Control Association (CFCA) track phone numbers and number prefixes that have been verified as participating in various types of fraud. These numbers are published as a list for their members. Many organizations also track numbers that abuse their network on a regular basis.
While it can be more of an art than a science, some customers wish to blacklist incoming or outgoing calls based on a dialed number prefix, or the entire dialed number. While complex or expensive fraud management solutions can be used, this Appendix provides a simple way to perform this blacklisting on the SBC.
Note:
This procedure will end up denying calls coming into your network. Be sure to test your local route tables (LRT) in a test environment before deploying in production.It is assumed that as calls have been sent to the SBC or as they enter the SBC that they will be “normalized” by either the directly connected agent or an incoming HMR to match the local dial plan. For example in North America it is necessary to include the leading “1” for NANP and remove the “011” for calls outside of the NANP. If this is not possible, then the “011” can be pre-pended onto the number matches in the LRT file.
Depending on what you are trying to prevent, you may want to check both the FROM and TO fields in SIP messages. This same strategy can be used on your access realm, or even your core realm if you so choose.
- Enter your FROM or TO blacklist numbers into one or more LRTs - and save them with an “.xml” extension. Next gzip them (.gz format). A sample LRT format is found below.
- Upload the .xml.gz file to the to SBC in the /code/lrt directory (which will need to be created the first time)
- Update SBC config as depicted below
Apply an LRT check for the SIP From and To headers as the first two policy-attributes on all incoming realms, and on the core side if you want to detect outgoing fraudulent calls.
local-policy
from-address
*
to-address
*
source-realm
access
description
activate-time N/A
deactivate-time N/A
state enabled
policy-priority none
last-modified-by admin@10.0.240.19
last-modified-date 2012-10-26 17:13:15
(The first policy checks the FROM field. Note that the .xml.gz file extension is not specified.)
policy-attribute
next-hop lrt:blacklist;key=$FROM
realm
action none
terminate-recursion enabled
carrier
start-time 0000
end-time 2400
days-of-week U-S
cost 0
app-protocol
state enabled
methods
media-profiles
lookup single
next-key
eloc-str-lkup disabled
eloc-str-match
(The second policy checks the TO field. This is OPTIONAL, and only if you want to check the number being dialed. You can use the same LRT file, or a different file.)
policy-attribute
next-hop lrt:blacklist;key=$TO
realm
action none
terminate-recursion enabled
carrier
start-time 0000
end-time 2400
days-of-week U-S
cost 0
app-protocol
state enabled
methods
media-profiles
lookup single
next-key
eloc-str-lkup disabled
eloc-str-match
(The third and last policy is essentially a default SIP route that forwards calls onto the core.)
policy-attribute
next-hop 192.168.60.10
realm core
action none
terminate-recursion disabled
carrier
start-time 0000
end-time 2400
days-of-week U-S
cost 0
app-protocol
state enabled
methods
media-profiles
lookup single
next-key
eloc-str-lkup disabled
eloc-str-match
local-routing-config
name blacklist
file-name blacklist.xml.gz
prefix-length 15
string-lookup disabled
retarget-requests enabled
match-mode best
last-modified-by admin@10.0.240.19
last-modified-date 2012-10-26 15:40:48
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <localRoutes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <route> <user type="E164">3712900</user> <next type="regex">!(^.*$)!sip:\110.11.12.13!</next> </route> <route> <user type="E164">88183521</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">2637749</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">3718104</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">3718103</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">3716852</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">447924</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> <route> <user type="E164">3712769</user> <next type="regex">!(^.*$)!sip:\1@10.11.12.13!</next> </route> </localRoutes>
Once the configuration has been saved and activated, the LRT file contents can be confirmed by executing the command “show lrt route-entry blacklist 3712900” at the ACLI (or any of the other blacklist prefixes, or numbers that contain the prefix).
Next, the dummy session agent must be set up. The hostname must match the LRT host entry. Note that the response-map AND local-response map are required to identify blacklisted calls vs. just valid errors.
session-agent
hostname 10.11.12.13
ip-address
port 5060
state disabled
app-protocol SIP
app-type
transport-method UDP
realm-id
response-map 503Fraud
local-response-map 503Fraud
session-router > sip-response-map
response-map
last-modified-by admin@10.0.240.19
last-modified-date 2012-10-26 17:06:07
name 503Fraud
entries 503 -> 678 (Fraud)
sip-manipulation
name logBlacklist
description
split-headers
join-headers
header-rule
name logBlacklist
header-name @status-line
action manipulate
comparison-type case-sensitive
msg-type reply
methods
match-value
new-value
element-rule
name logstatus
parameter-name
type status-code
action log
match-val-type any
comparison-type case-sensitive
match-value 678
new-value
element-rule
name replaceStatus
parameter-name
type status-code
action replace
match-val-type any
comparison-type case-sensitive
match-value 678
new-value 603
element-rule
name replaceReason
parameter-name
type reason-phrase
action replace
match-val-type any
comparison-type case-sensitive
match-value Fraud
new-value Declined
element-rule
name rejectDeclined
parameter-name
type reason-phrase
action reject
match-val-type any
comparison-type case-sensitive
match-value Declined
new-value
Notice that this config will send along the 603 error code which should be enough to refuse a call and stop recursion. If your trunking provider has a different standard message this can easily be changed.
session-router > session-router > sel reject-message-threshold 1 reject-message-window 30
Blacklist Table Maintenance
As new blacklist tables are released the customer can upload to /code/lrt and execute the following commands:
ACMEPACKET# config t ACMEPACKET(configure)# session-router ACMEPACKET(session-router)# local-routing-config ACMEPACKET(local-routing-config)# select <name>: 1: name=blacklist file name=blacklist.xml.gz prefixLength=15 selection: 1
ACMEPACKET(local-routing-config)# show
local-routing-config
name blacklist
file-name blacklist.xml.gz
prefix-length 15
string-lookup disabled
match-mode best
Change the “file-name” parameter to reflect the original compressed XML file
ACMEPACKET(local-routing-config)# file-name lookup.xml.gz
ACMEPACKET(local-routing-config)# done
local-routing-config
name blacklist
file-name blacklist102612.xml.gz
prefix-length 15
string-lookup disabled
match-mode best
ACMEPACKET(local-routing-config)# exit ACMEPACKET(session-router)# exit ACMEPACKET(configure)# exit ACMEPACKET#save-config ACMEPACKET#activate-config Activate-Config received, processing. waiting for request to finish Request to 'ACTIVATE-CONFIG' has Finished, Activate Complete
After applying a new LRT, verify if by doing the same command from above “show lrt route-entry blacklist 3712900” at the ACLI (again, any of the hotlist numbers can be used). If something went wrong, change your config back to the old file and re-test.
After you have a few LRT files on the SBC you may want to clean the old ones up.
