Blocklisting with Local Routing Tables

E Blocklisting 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 blocklist 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 blocklisting 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.

To create the blocklist for routing you need to:

Enter your FROM or TO blocklist 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:blocklist;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:blocklist;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

Create the LRT configuration referenced above. Note that the “best” match mode matches from most specific to least specific in the LRT table (greatest number of digits matched to fewest).

local-routing-config
        name                           blocklist
        file-name                      blocklist.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

Sample Entries from the LRT are seen below. In this case I’ve opted to forward the blocklist call onto a “dummy” session agent. You may opt to forward the call onto a recording, or session agent that handles fraud calls.

<?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 blocklist 3712900” at the ACLI (or any of the other blocklist 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 blocklisted calls vs. just valid errors.

Make sure the session-agent state is disabled so traffic or error messages are not sent to a real host. It should be noted that use of a real hostname will not work due to the way DNS resolution works in conjunction with disabled session-agents.

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

Next, map the error to an error code we can identify and log / reject for trap.

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)

On the access realm, the out-manipulationid should reference the “logBlocklist” HMR below. Note that if there is already an outbound HMR in ploce that the header rules below can be added to the existing HMR.

sip-manipulation
        name                           logBlocklist
        description
        split-headers
        join-headers
        header-rule
                name                           logBlocklist
                header-name                    @status-line
                action                         manipulate
                comparison-type                case-sensitive
                msg-type                       reply
                methods
                match-value
                new-value

(Log the call that matched the blocklist to a local file “matched.log” on the SBC)

element-rule
        name                           logstatus
        parameter-name
        type                           status-code
        action                         log
        match-val-type                 any
        comparison-type                case-sensitive
        match-value                    678
        new-value

(Replace the SIP status code and reason message with whatever you want to send back to the service provider or client.)

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

(Finally, invoke the SBC message rejection via HMR.)

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.

The “reject” action in “rejectDeclined” will cause the “Rejected Messages” count to increment in the show sipd display. If you wish to send traps to a management station when this HMR fires, update the settings in session-router-config. The configuration below will send a apSysMgmtRejectedMesagesThresholdExeededTrap whenever more than one blocklisted call is seen inside a 30 second window. This is an indicator that the administrator should examine the matched.log file to determine the number pattern that was seen.

session-router > session-router > sel
reject-message-threshold	1
reject-message-window		30

Blocklist Table Maintenance

As new blocklist 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=blocklist file name=blocklist.xml.gz prefixLength=15

selection: 1

Use the “show” command to verify the local-routing-config entry’s configuration

ACMEPACKET(local-routing-config)# show
local-routing-config
        name                           blocklist
        file-name                      blocklist.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                           blocklist
        file-name                      blocklist102612.xml.gz
        prefix-length                  15
        string-lookup                  disabled
	  match-mode			   best

Exit out of configuration mode, save, and activate the configuration.

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 blocklist 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.