Telephony Fraud Protection
You can use the Oracle® Enterprise Session Border Controller (ESBC) to protect against fraudulent calls by enabling Telephony Fraud Protection and creating lists of phone numbers to block, allow, redirect, and rate limit calls. The lists reside together in a single source-file that you create and manage. The source-file can contain any combination of the list types and it can reside on either the ESBC or in Session Delivery Manager (SDM) because you can manage Telephony Fraud Protection from either one. The following information explains using Telephony Fraud Protection on the ESBC. See the Oracle Communications Session Element Manager User Guide for the Enterprise Edge and Core Plug-in for managing Telephony Fraud Protection from SDM.
Note:
The Enterprise Session Router does not support Telephony Fraud Protection.Fraud Protection List Types and Uses
The ESBC supports the following types of lists for protecting against fraudulent calls.
Blocklist—Use the blocklist to specify a fraudulent call based on the destination phone number or URI. You can add a known fraudulent destination to the blocklist by prefix or by fixed number. When the ESBC receives a call to an entry on the blocklist, the system rejects the call according to the SIP response code that you specify. When the system determines a match and blocks a call, the default response is "403 Forbidden." You can set another SIP response code from the standard list of responses defined in RFC3261 by way of the Local Response Map configuration and the local error Fraud Protection Reject Call setting.
Allowlist—Use the allowlist to manage any exception to the blocklist. Suppose you choose to block a prefix such as +49 555 123 by way of the blocklist. This action also blocks calls to individual numbers starting with this prefix, such as +49 555 123 666. If you add a prefix or individual number to the allowlist, the system allows calls to the specified prefix and number. Continuing with the example, if you add +49 555 123 6 to the allowlist, the system allows calls to +49 555 123 666, which was blocked by the blocklist entry of +49 555 123.
Redirect List—Use the redirect list to send a fraudulent call to an Interactive Voice Response (IVR) system, or to a different route. For example, you can intercept and redirect a call going to a revenue-share fraud target in a foreign country to an end point that defeats the fraud. Or, you might want to redirect subscribers dialing a particular number and URI to an announcement to make them aware that an account is compromised and tell them what they should do. You can use an external server to provide such an announcement or you can use the ESBC media playback function.
Rate Limit List—Use rate limiting to limit the loss of money, performance, and availability that an attack might cause. While local ordinances may not allow you to completely block or suppress communication, you may want to reduce the impact of a disruption with rate limiting until a network engineer can analyze an attack and plan remediation. For example, you might want time to find the origin of an attack or to add attackers to a blocklist. Note that rate limiting may not function immediately after a High Availability switch over because the newly active system must re-calculate the call rate before it can apply rate limiting.
Configuration
- Enable Telephony Fraud Protection
- Specify the source of fraud protection management
- Create the file that contains the list of phone numbers to manage
- Activate the fraud protection file
You can create the fraud protection phone number list on the File Management page on the Web GUI, or you can create it externally in XML and upload it to the ESBC. Save the file to /code/fpe/<filename>. In the Web GUI User Guide, see "Configure Telephony Fraud Protection," "Create a Telephony Fraud Protection File," and "Telephony Fraud Protection File Activation." If you want to create the fraud protection file externally, see "Fraud Protection XML Source File Example."
You can enable Telephony Fraud Protection from either the Web GUI or from the ACLI command line, but you cannot manage fraud protection from the ACLI. You must use the Web GUI for management.
Telephony Fraud Protection is included in the advanced license.
Note:
See the following topics in the Release Notes for important information about "Fraud Protection File Rollback Compatibility" and "Fraud Protection Upgrade Compatibility."Administration
- An Administrator with privileges can Refresh, Add, and Upload an unselected file, and Edit, Download, and Delete a selected file.
- An Administrator with no privileges can only view the fraud protection file.
- From the ACLI, use the show commands to view fraud protection statistics. See "Telephony Fraud Protection Show Commands."
- From the Web GUI, use the Show Summary, Show Blocklist, Show Allowlist, Show Call Redirect List, and Show Rate Limit Widgets.
Note:
The Telephony Fraud Protection feature does not affect emergency calls or block any calls while you are loading entries.High Availability
- When the ESBC manages the Telephony Fraud Protection file—Use the synchronize file <filename> command to copy the Telephony Fraud Protection file to the standby after an HA switch over.
- When the Enterprise Telephony Fraud Manager in SDM manages the Telephony Fraud Protection file—After an HA switch over, the newly active ESBC sends the RESYNC command to the Fraud Manager on SDM, requesting the latest file. SDM responds with the name and location of the file, which the ESBC downloads from SDM.
- Note that after a switch over, rate limiting may not take effect immediately because the new Active system needs time to recalculate the call rate before it can apply rate limiting.
Whenever you refresh the telephony fraud protection file from the ACLI with the notify fped refresh command, this updates the runtime table by reloading the entries in the file specified in the fraud-protection configuration, only for the active ESBC. To update the FPE runtime table on the standby ESBC,run the synchronize file <filename> command on the active ESBC and then run the notify fped refresh command on the standby ESBC.
Oracle recommends you to update and save the telephony fraud protection file using the Web GUI as it automatically updates the FPE runtime table on the active ESBC and synchronizes the modified value to the standby ESBC. To load the updated entry to the FPE runtime table, run the notify fped refresh command on the standby ESBC.
Telephony Fraud Protection Management from SDM
If you prefer to manage Telephony Fraud Protection from the Enterprise Fraud Manager in SDM, rather than from the ESBC, store the fraud protection list in a file named sbc_fpe_entries.xml (case sensitive) in SDM. You can edit the file in SDM, which will notify the ESBC afterward to download the file to its /code/fpe directory. When the ESBC is part of an HA pair, the Active partner automatically pushes the updated file to the Standby partner. In the event of an unsuccessful download, the system raises an SNMP alarm. Should the connection to SDM ever go down, the system also raises an SNMP alarm and sends a trap. When the connection gets re-established, the alarm and trap clear, and the ESBC sends a RESYNC command to SDM.
Unsupported Functions
Telephony Fraud Protection for the ESBC does not support the following:
- IPv6
- H.323
- InterWorking Function (IWF)
- Comm Monitor
Telephony Fraud Protection Target Matching Rules
- Longest match—The most specific entry takes precedence. For example, when 555-123-4000 is block listed and 555-123-* is allow listed, the system blocks the call from 555-123-4000 because it is the longest match.
- Destination—When the system detects matches in both the SIP From header and the SIP To header, the match for the To header takes precedence.
- URI—When the system detects matches in both the USER and Host parts of a SIP URI, the match for the USER part takes precedence.
- SIP User-Agent header—Lowest priority. When nothing else matches, and there is a match for the User-Agent field, the ESBC acts as instructed.
- Multiple instances—When the system detects multiple instances of the same match length, or when the target resides in multiple lists, the system uses the following order of precedence:
1. Allowlist—Entries on the allowlist take precedence with no restrictions. For example, when 555-123-4567 is on both the blocklist and the allowlist, the system allows this call because the number is on the allowlist.
2. Blocklist
3. Redirect
4. Rate limiting
Note:
The telephony fraud protection feature does not affect emergency calls.The telephony fraud protection feature uses source or destination IP, source or destination name or phone number, and caller user-agent to identify a caller. The system enforces the following rules for formatting entries on a fraud protection list:
Hostname
Format: Enter the exact IP address or FQDN.
User name
Format: Enter the exact user name. For example: joe.user or joe_user.
User-Agent-Header
The User-Agent header text in the INVITE message from the first call leg. This text usually contains the brand and firmware version of the SIP device making the call. For example, sipcli/v1.8, Asterisk PBX 1.6.026-FONCORE-r78.
Format: Enter the exact text.
Phone Number
Format: Enter the exact number or a partial number using the following characters to increase the scope of the matches.
Asterisk * | Use to indicate prefix matching, but only at the end of the pattern. For example, use 555* not *555. Do not use * in any other patterns, for example, in brackets [ ], parentheses ( ), or with an x. |
Square Brackets [ ] | Use to enclose ranges in a pattern. Syntax:
[min-max]. For example: 555 [0000-9999].
The system considers 8[1-20]9 and 8[01-20]9 to
contain the same number of characters because the leading 0 is implied. The
system strictly enforces this pattern with respect to the range and the number
of characters, as follows:
|
Character x | Use as a wild card a the end of a dial pattern to mean 0-9. For example: 555xxx means match a number starting with 555 followed by 3 digits from 0-9. |
Parentheses ( ) | Use to enclose optional digits in a pattern. For example: 555xx(xxxx) means match a number starting with 555 plus a minimum of 2 digits, and optionally up to 4 more digits. |
Telephony Fraud Protection File Activation
After you create, edit, or upload the telephony fraud protection file, you must activate the file before the Oracle® Enterprise Session Border Controller (ESBC) can use it as the source of the fraud protection lists. The system recognizes only one file at a time as the active file.
The first time you configure the ESBC to manage fraud protection, the system activates the file when you save and activate the configuration. After the initial configuration, the system does not automatically refresh the fraud protection file when you save and activate other configuration changes on the ESBC. You must upload a new file or edit the existing file and activate it to update the file. The exception occurs when you specify a new file name in the fraud protection configuration and coincidentally make changes to other configurations, and then save and activate all of the changes at the same time.
After the initial configuration, use the following methods to activate the fraud protection file.
- New File—After you create or upload a new file, go to Fraud Protection configuration, enter the name of the new file, and click Save. The system prompts for activation upon a successful Save. Note that you can decline the inline activation and manually activate the file later. For example, you might want to edit an uploaded file before activation.
- Overwrite File—When you upload a file with the same name as the existing file, the system prompts for activation upon upload.
- Edit File—When you edit the existing file directly from the Web GUI, the system prompts for activation after you save the edits.
- Refresh File—When you want
to use the ACLI to refresh the fraud protection file, send the file to the
ESBC and use the
notify fped refresh
command. The name of the file that you refresh must match the name of the file specified in the configuration.
Note:
The system displays an alert on the Notifications menu to remind you that the fraud protection file needs activation.Telephony Fraud Protection Data Types and Formats
Use the information in the following tables when you create or edit a fraud protection list in the Add Fraud Protection Entry and Modify Fraud Protection Entry dialogs.
Data Type Descriptions
The following table describes the data types listed in the Type drop-down list.
from-hostname | The hostname from the SIP FROM header. |
from-phone-number | The phone number from the SIP FROM header |
from-username | The user name from the SIP FROM header. |
to-hostname | The hostname from the SIP TO header. |
to-phone-number | The phone number from the SIP TO header. |
to-username | The user name from the SIP TO header. |
user-agent-header | The SIP User-Agent header. |
Match Value Formats
The following table describes the formats required for the data types.
hostname | Enter the exact IP address or FQDN. |
username | Enter the exact user name. For example: joe.user or joe_user. |
user-agent-header | Enter the exact text match to the SIP User-Agent header. For example: equipment vendor information. |
phone-number | You can use the following characters for
phone-number:
|
Caution:
The use of encoding characters is especially susceptible to creating overlapping dial pattern matches that can result in unexpected behavior.Configure Telephony Fraud Protection
The telephony fraud protection feature requires configuration, which you can perform from the Oracle® Enterprise Session Border Controller (ESBC) ACLI by way of the fraud-protection configuration element under System.
- Confirm that you own the Advanced license.
- Add or upload at least one telephony fraud protection file to the ESBC.
- Note the name of the fraud protection file that you want to use.
Use this procedure to enable telephony fraud protection on the ESBC. You must specify the fraud protection file name and activate the configuration. You cannot specify multiple fraud protection files because the system recognizes only one file as the active source file.
Refresh the Telephony Fraud Protection File
You can refresh the telephony fraud protection file from the ACLI with the notify fped refresh command. This command updates the runtime table by reloading the entries in the file specified in the fraud-protection configuration.
- SFTP the updated file to the ESBC.
- Confirm that the name of the updated file matches the name of the file specified in the configuration.
Use the following procedure apply updates to the telephony fraud protection file.
Telephony Fraud Protection ACLI Show Commands
The Oracle® Enterprise Session Border Controller (ESBC) supports viewing and refreshing telephony fraud protection statistics by way of ACLI commands. The displayed data is read-only.
The following ACLI commands provide displays of telephony fraud protection statistics.
show-fraud-protection <list
type> <matches-only>
—Use this command to display all entries
or only entries on a particular fraud prevention list, and optionally, to show
only the entries on the specified list that incurred a match. Use one of the
following variables for <list type>:
- all—displays all entries
- blocklist—displays only the blocklist matches
- allowlist—displays only the allowlist matches
- redirect—displays only the redirect matches
- ratelimit—displays only the rate limit matches
show-fraud-protection all
—displays all blocklist, redirect, allowlist, and rate limit entries.show-fraud-protection all matches-only
—displays only the matches for blocklist, redirect, allowlist, and rate limit entries.show-fraud-protection blocklist
—displays only the blocklist, showing all entries.show-fraud-protection blocklist matches-only
—displays only the matches for blocklist entries.
Display Examples
BLOCKLIST
show-fraud-protection
—Use to
display all entries with matches-only
show fraud-protection
stats
—Use to display Recent, Total, and Period Maximum statistics for
the fraud protection lists: For example: STATS
The following ACLI commands refresh displays of fraud protection entries.
notify fped refresh
—Use to
update the fraud protection lists table after you make changes. If for some
reason the refresh command is unsuccessful and cannot update the list with new
data, the system preserves the existing data.
notify fped reset-stats
—Use
to reset the fraud protection statistics counter to zero, for example, to begin
a new data collection period.
Telephony Fraud Protection verify-config
When you run the verify-config command for Telephony Fraud Protection, the system verifies the following:
- When you set the Fraud Protection mode to comm-monitor, verify-config confirms that a comm-monitor configuration exists.
- When you set the Fraud Protection mode to disabled, verify-config confirms that the Fraud Protection file name is empty. You cannot specify a file when the Sesssion Border Controller is connected to Session Delivery Manager.
Fraud Protection File Upgrade Compatibility
As of the S-Cz9.1.0 release, Oracle changed some of the Oracle® Enterprise Session Border Controller (ESBC) Fraud Protection file list type names to eliminate certain culturally undesirable terms and replace them with more acceptable terms.
Previous versions of the Fraud Protection file included list types named call-whitelist and call-blacklist. The upgrade process automatically modifies the Fraud Protection file by changing the former names to call-allowlist and call-blocklist. The file is located in /code/fpe/directory with file extensions .xml. .gz, or .gzip.
The upgrade process does not delete the existing file and replace it with a new one. The upgrade changes only the list type names within the existing file.
Note that previous versions of the Fraud Protection software do not support the new list type names and you must take action to ensure compatibility in a rollback scenario. See Fraud Protection File Rollback Compatibility for information about what to do in a rollback scenario.
Fraud Protection File Rollback Compatibility
As of the S-Cz9.1.0 release, Oracle changed some of the Oracle® Enterprise Session Border Controller (ESBC) Fraud Protection file list type names to eliminate certain culturally undesirable terms and replace them with more acceptable terms. The changes impact your Fraud Protection file with consequences in rollback scenarios.
As of the S-Cz9.1.0 release, the upgrade process automatically changes the former Fraud Protection list types named call-whitelist and call-blacklist to call-allowlist and call-blocklist.
- Back up of your existing Fraud Protection configuration file before upgrading to S-Cz 9.1.0, and use it for previous versions of the software in a rollback scenario.
- Perform the upgrade to S-Cz9.1.0, which automatically changes
call-whitelist and call-blacklist to call-allowlist and call-blocklist. Before
you rollback, edit your S-Cz9.1.0 Fraud Protection file by replacing
call-allowlist and call-blocklist with call-whitelist and call-blacklist,
respectively.
Note:
You do not need to reverse this method when you upgrade to S-Cz9.1.0 again. The upgrade process makes the changes automatically.
Fraud Protection XML Source File Example
When you enable the Oracle® Enterprise Session Border Controller (ESBC) to protect against fraudulent calls, you must create lists of phone numbers or IP addresses to block, allow, redirect, and rate limit calls. The lists reside together in a single file that you specify as the source file in the fraud protection configuration. The source file can contain any combination of the list types, but the system limits the size of the fraud protection file to 100,000 total entries.
The following example shows an XML file created as the source file for fraud protection. The file includes a section for each type of list, which includes call-blocklist, call-allow list, call-limit, and call-redirect. The example shows the coding for adding the source-ip, destination-phone, realm, calls-per-second for rate limiting, and the target for a redirected call.
<?xml version='1.0' standalone='yes'?>
<oracleSbcFraudProtectionApi version="1.0">
<call-allowlist>
<userEntry>
<to-phone-number>1234567[0000-9999]</to-phone-number>
<realm>Core</realm>
</userEntry>
<userEntry>
<to-phone-number>12345678901</to-phone-number>
<realm>DefaultSP</realm>
</userEntry>
<userEntry>
<from-hostname>123.45.67.8/90</from-hostname>
<realm>*</realm>
</userEntry>
</call-allowlist>
<call-blocklist>
<userEntry>
<to-hostname>12345678901</to-hostname>
<realm>*</realm>
</userEntry>
<userEntry>
<from-hostname>123.45.67.8/90</from-hostname>
<realm>*</realm>
</userEntry>
</call-blocklist>
<call-redirect>
<userEntry>
<from-hostname>19877654321</from-hostname>
<realm>Core</realm>
<target>sip:support@phonesystem.com</target>
</userEntry>
</call-redirect>
<call-rate-limit>
<userEntry>
<from-hostname>19877654321</from-hostname>
<realm>DefaultSP</realm>
<calls-per-second>5</calls-per-second>
<max-active-calls>0</max-active-calls>
</userEntry>
</call-rate-limit>
Note that the ESBC enforces an order of precedence among the lists. See "Telephony Fraud Protection Target Matching Rules."
Note:
If you rollback to a previous version of the software, you must edit this file by changing Allowlist to Whitelist and Blocklist to Blacklist. When you return to the SC-z9.1.0 or higher version of the software, revert to Allowlist and Blocklist.