DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

In this section:

Related articles:

Access Configuration Security Settings

Several important settings are available to improve the security of Access configurations.

Table 1: Access Configuration Security Settings

Configuration

Setting

Details

SIP Sig Controls

Multiple Contacts per AOR

Enable this flag to pass REGISTRATIONs from a different IP address/port than the currently successful REGISTRATION (for example a second SIP client using the same username) to the Feature Server for authentication. If this setting is not enabled, a fraudulent user that has the details of a legitimate user could make and receive calls.

View settings: > show configuration details global signaling sipSigControls

Set command: % set global signaling sipSigControls multipleContactsPerAor enabled

References: Signaling - Global - CLI, Signaling - SIP Sig Controls (EMA)

SIP Sig Controls

Registrar Support Contact Param

Enable this flag to support parameters in the Contact header. Many feature servers require this setting.

View settings: > show configuration details global signaling sipSigControls

Set command: % set global signaling sipSigControls registrarSupportContactParam enabled

References: Signaling - Global - CLI, Signaling - SIP Sig Controls (EMA)




Trunk Group

Require Registration

On the trunk group facing the phones (PHONES in our example), the requireRegistration parameter must be set.

This setting ensures that calls from subscribers that arrive on this trunk group are only allowed if a valid registration for that subscriber has occurred. Calls that arrive from endpoints that are not registered are not allowed.

View settings: > show configuration details addressContext <ac name> zone <zone name> sipTrunkGroup <tg name> signaling registration

Set command: % set addressContext <name> zone <name> sipTrunkGroup <name> signaling registration requireRegistration <required | required-nonpriority | required-group | required-group-nonpriority>

References: SIP Trunk Group - Signaling - CLI, Trunk Group - SIP Trunk Group (EMA)

Expires timer and Inside Expires timer

Set the Expires timer which controls how often the phones will Register, and the Inside Expires timer which is how often the SBC registers with the Feature Server (PBX or Class-5 Softswitch) on behalf of the phone. The Inside timer is typically set to 1 hour while the phones Registration timer is typically set to 60 seconds.

View settings:

Set command:

References:  SIP Trunk Group - Signaling - CLI, Trunk Group - SIP Trunk Group (EMA)

Relay Non-Invite Request

This setting should be "disabled".

Note that SUBSCRIBE for Registered Users will still be sent to the feature server.

View settings:

Set command:

References: SIP Trunk Group - Signaling - CLI, Trunk Group - SIP Trunk Group (EMA)

Number of simultaneous calls per
REGISTERED user

In the case where a username and password have been compromised, limiting the number of simultaneous calls can reduce the impact of fraud.

This SBC feature can be activated by assigning a CAC profile to the trunk group facing the phones (PHONES). The field is called: registeredEndpointCacProfile

This profile should be set to limit the number of simulation calls.

Use this command to display CAC profiles:

% show configuration profiles sipCacProfile

View settings:

Set command:

References:

Feature Server

Number of simultaneous calls per subscriber on the feature server

In the case where a username and password have been compromised, limiting the number of simultaneous calls can reduce the impact of fraud.

This function may be available at the feature server.

 


IP Access Control Lists (ACL)

IP Access Control Lists (ACLs) are used to protect the SBC Core from attacks. IP ACLs allow you to specify rules that permit or deny packets into the SBC. For example, you can permit traffic from one particular IP address, but deny traffic from all other IP addresses.

Only signaling and management IP traffic is subjected to IP ACL filtering. Media IP traffic (RTP) is not subject to IP ACL filtering. In most cases, you only need to define ACLs on the UNTRUSTED or EXTERNAL interface groups. These are the interfaces used to communicate with third parties such as a trunk group to another service provider or phones from the public Internet.

Each ACL is configured with a unique precedence, between 1 and 65,535. ACLs are evaluated in the order of precedence, with 1 being the highest priority, and the first ACL evaluated. For a rule that is matched by two separate ACL, the one that is evaluated first (lowest number= higher priority) takes precedence.

When you create a SIP Port, the system also creates an ACL that allows connection attempts to all ports on the IP address of the SIP Port. For example, SSH to the IP address is allowed. To prevent unwanted access, ACLs should be used.

SIP Trunking Details

For a SIP Trunking configuration, you should define ACL "white lists" that only allow traffic from the far ends (IP address) you are peering with. ACLs are used to prevent traffic from all other IP addresses except those on the "white list".

For each trunk group, an ACL that allows traffic from the far end should be created with a high priority (low precedence value). Then, a "Block Everything Else" ACL should be created at a lower priority (higher precedence value). This has the effect of blocking all traffic EXCEPT traffic that is explicitly allowed.

The below rule allows unlimited traffic from "10.35.66.187" (this is the IP address of the far end in our example configuration in this document. This IP address would also be an IP Peer, and in the trunk group ingress IP prefix) to destination port 5060.

set addressContext "default" ipAccessControlList rule "WHITELIST_PEER_01" precedence "1000" protocol "udp" ipInterfaceGroup "EXTERNAL.IPIG" sourceIpAddress "10.35.66.187" sourceAddressPrefixLength "32" destinationPort "5060" state "enabled"
Make sure the sourceAddressPrefixLength is set ("32" is used in the above example).Otherwise, the parameter defaults to "0" which will allow all IP addresses to get "white listed".

The below rule blocks all traffic that is not explicitly allowed:

set addressContext "default" ipAccessControlList rule "DENYALL_UNTRUST" precedence "65015" ipInterfaceGroup "EXTERNAL.IPIG" action "discard"
Enable the ACLs in precedence order. So this ACL should be the last one enabled

The precedence of WHITELIST_PEER_01 is a lower value than DENYALL_UNTRUST. This causes WHITELIST_PEER_01 to take precedence over DENYALL_UNTRUST, which allows traffic from 10.35.66.187 to be accepted by the SBC.

SIP Access Details

For a SIP Access configuration you do not manually "white list" the IP address of all the phones that will be registering (since the address may change and there are so many). Instead you create a rule that allows traffic destined for the SIP Port of the SBC.

Summary of Steps Needed:

  1. Create an ACL that allows traffic FROM any IP address destined for only the SBC SIP Port. This ACL should specify the protocol, destination IP address, destination port, and have a low precedence value. This ACL could also be used to limit the rate of traffic allowed on the SIP Port. See IP ACL Policing - Packet Filtering.
  2. Create a "Block Everything Else" ACL with a high precedence value. In conjunction with the ACL from step #1, this has the effect of only allowing traffic destined to the SBC SIP port.
  3. The SBC automatically allows ("white list") traffic from phones once REGISTRATION has been successful. This automatic step allows the traffic from these phones to not be included in the total traffic allowed for the ACL if included in step #1.

The below rule is an example for Step #1, where 10.35.66.143 is the SBC SIP Port IP address that phones register with, and 5060 is port.

set addressContext "default" ipAccessControlList rule "ALLOW_SIP_PORT_ACCESS" precedence "1001" protocol "udp" ipInterfaceGroup "EXTERNAL.IPIG" destinationIpAddress "10.35.66.143" destinationPort "5060"


The below rule is a step 3 example.

% set addressContext "default" ipAccessControlList rule "DENYALL_ACCESS" precedence "65020" ipInterfaceGroup "EXTERNAL.IPIG" action "discard" 
Enable ACLs in order of precedence. For this example, this ACL should be enabled last.

Allow Some ICMP (Ping) Traffic

You may wish to allow some ICMP traffic. This can be useful for network debugging situations. Also, if you have the SBC Link Detection feature enabled with Ping Targets, then you must allow Ping traffic. Make sure this has a lower precedence value than your "discard all" rule.

The below command allows a small amount of ICMP traffic:

set addressContext "default" ipAccessControlList rule "AllowICMP_UNTRUST" precedence "64985" protocol "icmp" ipInterfaceGroup "EXTERNAL.IPIG" fillRate "10" bucketSize "10" state "enabled"

System Defined ACL

Some system-defined ACLs are automatically set up on the SBC for known services such as SNMP, SSH, SFTP, HTTP, HTTPS. Refer to IP ACL Policing - Packet Filtering for more details.

You can display the system defined ACL status:

% show status addressContext default ipAccessControlList

When you define an ACL, it takes precedence over a similar system-defined ACL. For example, if you have a third-party management system that exceeds the predefined rate for SNMP traffic, you can set up an ACL to override the default rules and allow traffic. You could, for example, allow all traffic ("white list") from the IP of the third-party management system.


  • No labels