Configuring DoS Security
This section explains how to configure the Oracle Communications Session Border Controller for DoS protection.
Configuration Overview
Configuring Oracle Communications Session Border Controller DoS protection includes masking source IP and port parameters to include more than one match and configuring guaranteed minimum bandwidth for trusted and untrusted signaling path. You can also configure signaling path policing parameters for individual source addresses. Policing parameters are defined as peak data rate (in bytes/sec), average data rate (in bytes/sec), and maximum burst size.
You can configure deny list rules based on the following:
- ingress realm
- source IP address
- source port
- transport protocol (TCP/UDP)
- application protocol (SIP or H.323)
Exercise caution when configuring ACLs, noting that the syntax of your entry is correct. The SBC sets ACL fields with incorrect syntax to their defaults.
For example, the default source IP address for an ACL is 0.0.0.0. If using dynamic ACLs, this default address can overwrite the applicable realm's default ACL. If this ACL also has the default trust level of none, it would prevent the SBC from promoting any traffic on that realm to trusted.
Confirm the syntax of your configured ACLs before you save and activate them.
Changing the Default Oracle Communications Session Border Controller Behavior
The Oracle Communications Session Border Controller automatically creates permit untrusted ACLs that let all sources (address prefix of 0.0.0.0/0) reach each configured realm’s signaling interfaces, regardless of the realm’s address prefix. To deny sources or classify them as trusted, you create static or dynamic ACLs, and the global permit untrusted ACL to specifically deny sources or classify them as trusted. Doing this creates a default permit-all policy with specific deny and permit ACLs based on the realm address prefix.
You can change that behavior by configuring static ACLs for realms with the same source prefix as the realm’s address prefix; and with the trust level set to the same value as the realm. Doing this prevents the permit untrusted ACLs from being installed. You then have a default deny all ACL policy with specific static permit ACLs to allow packets into the system.
Example 1 Limiting Access to a Specific Address Prefix Range
The following example shows how to install a permit untrusted ACL of source 12.34.0.0/16 for each signalling interface/port of a realm called access. Only packets from within the source address prefix range 12.34.0.0/16, destined for the signaling interfaces/port of the realm named access, are allowed. The packets go into untrusted queues until they are dynamically demoted or promoted based on their behavior. All other packets are denied/dropped.
- Configure a realm called access and set the trust level to low and the address prefix to 12.34.0.0/16.
- Configure a static ACL with a source prefix of 12.34.0.0/16 with the trust level set to low for the realm named access.
Example 2 Classifying the Packets as Trusted
Building on Example 1, this example shows how to classify all packets from 12.34.0.0/16 to the realm signaling interfaces as trusted and place them in a trusted queue. All other packets from outside the prefix range destined to the realm’s signaling interfaces are allowed and classified as untrusted; then promoted or demoted based on behavior.
You do this by adding a global permit untrusted ACL (source 0.0.0.0) for each signaling interface/port of the access realm. You configure a static ACL with a source prefix 12.34.0.0/16 and set the trust level to high.
Adding this ACL causes the Oracle Communications Session Border Controller to also add a permit trusted ACL with a source prefix of 12.34.0.0/16 for each signaling interface/port of the access realm. This ACL is added because the trust level of the ACL you just added is high and the realm’s trust level is set to low. The trust levels must match to remove the global permit trusted ACL.
Example 3 Installing Only Static ACLs
This example shows you how to prevent the Oracle Communications Session Border Controller from installing the global permit (0.0.0.0) untrusted ACL.
- Configure a realm with a trust level of none.
- Configure static ACLs for that realm with the same source address prefix as the realm’s address prefix, and set the trust level to any value.
The system installs only the static ACLs you configure.
Packet Loss Alarms for Access Control Lists
The Oracle Communications Session Border Controller reports packet loss on traffic associated with Access Control Lists (ACLs) using alarms. These alarms use the Oracle Communications Session Border Controller's system's alarm management and user display mechanisms. The user can configure three media-manager parameters to set thresholds for these alarms.
Packet drops occur when the system enforces its traffic management rules. These alarms require user configuration using media manager threshold parameters as a percentage of traffic for each type of ACL. When traffic volume exceeds these thresholds, the Oracle Communications Session Border Controller generates these alarms every 30 seconds until the traffic falls back below the threshold. The system synchronizes this configuration and current status with High Availability (HA) processes, maintaining these alarms across failover events.
The Oracle Communications Session Border Controller ACL traffic categories that have complementary alarms are Untrusted ACL and Trusted ACL.
The applicable media manager threshold parameters include:
- untrusted-drop-threshold
- trusted-drop-threshold
Applicable alarms include:
- ACL_UNTRUSTED_DROP_OVER_THRESHOLD
- ACL_TRUSTED_DROP_OVER_THRESHOLD
The syntax below shows how to set the untrusted drop threshold.
OC-SBC>enable
OC-SBC#configure terminal
OC-SBC(config)#media-manager
OC-SBC(media-manager)#media-manager-config
OC-SBC(media-manager-config)#select
OC-SBC(media-manager-config)#untrusted-drop-threshold 70
OC-SBC(media-manager-config)#done
Refer to the platform support table above. The range for all thresholds is 0 to 100, with defaults of 0. The default of 0 disables the threshold. All of these parameters are real-time configurable.
Packet Loss Trap for Access Control Lists
You can configure the Oracle Communications Session Border Controller (SBC) to generate an SNMP trap upon the expiration of a configurable time period during which the ACL packet drop ratio has exceeded a configured drop threshold. This trap reports the total number of dropped packets in that time period. The feature is disabled by default, and requires SNMP traps and DoS enabled.
To enable this feature, set either the untrusted-drop-threshold or the trusted-drop-threshold field in media-manager to a non-zero value between 1-100, then save and activate configuration changes. To disable, set both back to zero. Changes to these parameters do not require a reboot.
The feature also uses the media-manager's acl-monitor-window to specify the monitoring window. The default value is 30 seconds, and the range is 5 to 3600 seconds. To change the monitoring window, set the acl-monitor-window to the desired value in seconds. Changes to the acl-monitor-window requires a reboot.
This SNMP trap includes the following information:
- The drop type (which is the same as the ACL type)
- The number of dropped packets during the monitored time period.
- The drop ratio during the monitored time period, reported as permillage (per thousand).
If the monitoring period expires and the percentage of dropped packets in that period is below the configured percentage value, the system does not send the trap, but does create a log entry in log.platform with the dropped packet value.
The following MIB objects are included in the ap-agentcapability.mib to support this feature.
apAclDropMibCapabilities 1.3.6.1.4.1.9148.2.1.31
apAclDropCap 1.3.6.1.4.1.9148.2.1.31.1
description "Acme Packet Agent Capability for ACL drop monitoring MIB"The ap-apps.mib includes the following MIB objects to support this feature.
apAppsAclNotif 1.3.6.1.4.1.9148.3.16.2.2.4
apAppsAclNotifications 1.3.6.1.4.1.9148.3.16.2.2.4.0
apAclDropOverThresholdTrap 1.3.6.1.4.1.9148.3.16.2.2.4.0.1
description "The trap will be generated when acl drop ratio has exceeded the configured threshold"
apAclDropOverThresholdClearTrap 1.3.6.1.4.1.9148.3.16.2.2.4.0.2
description "The trap will be generated when acl drop ratio has gone below the configured threshold"
apAclNotificationGroups 1.3.6.1.4.1.9148.3.16.3.2.4
apAclDropNotificationsGroup 1.3.6.1.4.1.9148.3.16.3.2.4.1
description "Traps to monitor acl drops"
apAppsAclObjects 1.3.6.1.4.1.9148.3.16.4
apAclDropObjects 1.3.6.1.4.1.9148.3.16.4.1
apAclDropType 1.3.6.1.4.1.9148.3.16.4.1.1
description "ACL drop type"
apAclDropCount 1.3.6.1.4.1.9148.3.16.4.1.2
description "ACL drop count within monitor time window"
apAclDropRatio 1.3.6.1.4.1.9148.3.16.4.1.3
description "ACL drop ratio as permillage of current time window. Valid range 0-1000"This feature is supported on HA configurations.
Host Access Policing
You can configure the Oracle Communications Session Border Controller to police the overall bandwidth of the host path.
To configure host access policing:
Configuring ARP Flood Protection
You do not need to configure the Oracle Communications Session Border Controller to enable the use of two separate ARP queues; that feature is enabled automatically.
If you want to configure the ARP queue policing rate, you can do so in the media manager configuration.
Note:
this feature is not RTC-supported, and you must reboot your Oracle Communications Session Border Controller in order for your configuration changes to take effect.To set the ARP queue policing rate:
Access Control for a Realm
Each host within a realm can be policed based on average rate, peak rate, and maximum burst size of signaling messages. These parameters take effect only when the host is trusted. You can also set the trust level for the host within the realm. All untrusted hosts share the bandwidth defined for the media manager: maximum untrusted bandwidth and minimum untrusted bandwidth.
To configure access control for a realm:
Configuring Overload Protection for Session Agents
The Oracle Communications Session Border Controller offers two methods to control SIP registrations to smooth the registration flow.
You can limit the:
- number of new register requests sent to a session agent (using the max-register-sustain-rate parameter)
- burstiness which can be associated with SIP registrations
The first method guards against the Oracle Communications Session Border Controller’s becoming overwhelmed with register requests, while the second method guards against a transient registration that can require more than available registration resources.
SIP registration burst rate control allows you to configure two new parameters per SIP session agent—one that controls the registration burst rate to limit the number of new registration requests, and a second to set the time window for that burst rate. When the registration rate exceeds the burst rate you set, the Oracle Communications Session Border Controller responds to new registration requests with 503 Service Unavailable messages.
Note that this constraint is not applied to re-registers resulting from a 401 Unauthorized challenge request.
To configure overload protection for session agents:
DDoS Protection from Devices Behind a NAT
A DDoS attack could be crafted such that multiple devices from behind a single NAT could overwhelm the Oracle Communications Session Border Controller. The Oracle Communications Session Border Controller would not detect this as a DDoS attack because each endpoint would have the same source IP but multiple source ports. Because the Oracle Communications Session Border Controller allocates a different CAM entry for each source IP:Port combination, this attack will not be detected. This feature remedies such a possibility.
Restricting the Number of Endpoints behind a NAT
Each new source IP address and source IP port combination now counts as an endpoint for a particular NAT device. After the configured value of a single NAT’s endpoints is reached, subsequent messages from behind that NAT are dropped and the NAT is demoted. This is set with the max-endpoints-per-nat parameter located in both the access-control and realm-config configuration elements.
Counting Invalid Messages from Endpoints behind a NAT
The Oracle Communications Session Border Controller also counts the number of invalid messages sent from endpoints behind the NAT. Once a threshold is reached, that NAT is demoted. Numerous conditions are counted as Errors/Invalid Messages from an endpoint. The aggregate of all messages from endpoints behind the NAT are counted against the NAT device, in addition to the existing count against the endpoint. This threshold is set with the nat-invalid-message-threshold parameter located in both the access-control and realm-config configuration elements.
As a unique case, the absence of a REGISTER message following a 401 response is counted as an invalid message from the end point. And if that endpoint is behind a NAT, this scenario will be counted as invalid message from that NAT device as well. You set a timeout period in which the REGISTER message must arrive at the Oracle Communications Session Border Controller. This period is set with the wait-time-for-invalid-register parameter located in the realm config.
DDoS Protection Configuration realm-config
To set the DDoS Protection from devices behind NATs in the realm-config:
DDoS Protection Configuration access-control
To set the DDoS Protection from devices behind NATs in the access-control configuration element:
SNMP Trap support
The Oracle Communications Session Border Controller sends the following trap when a NAT device is blocklisted due to the triggers listed. The trap does not include reasons, which are available from the syslogs.
apSysMgmtExpDOSTrap NOTIFICATION-TYPE
OBJECTS { apSysMgmtDOSIpAddress, apSysMgmtDOSRealmID ,
apSysMgmtDOSFromUri }
STATUS deprecated
DESCRIPTION
"This trap is generated when an IP is placed on a blocklist due
to denial-of-service attempts, and provides the IP address that
has been demoted, the realm-id of that IP, and (if available)
the URI portion of the SIP From header of the message that
caused the demotion."
::= { apSysMgmtDOSNotifications 2 }Ensure that the enable-snmp-monitor-traps parameter in the system-config configuration element is enabled for the Oracle Communications Session Border Controller to send out this trap.
Syslog Support
Set the syslog-on-demote-to-deny parameter in the media-manager-config to enabled to generate syslog on endpoint demotion from untrusted to deny. NAT device demotion will also generate a unique syslog message with accompanying text explaining that it is the NAT device demotion event.
Debugging
The show sip acl command now includes counts of Blocked NAT devices.
ACMEPACKET# show sipd acl
13:57:28-71
SIP ACL Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Total Entries 0 0 0 0 0 0
Trusted 0 0 0 0 0 0
Blocked 0 0 0 0 0 0
Blocked NATs 0 0 0 0 0 0
ACL Operations ---- Lifetime ----
Recent Total PerMax
ACL Requests 0 0 0
Bad Messages 0 0 0
Promotions 0 0 0
Demotions 0 0 0
Trust->Untrust 0 0 0
Untrust->Deny 0 0 0DoS Threshold Configuration
This section describes how to configure DoS traffic thresholds to alert you of high traffic conditions.
Configure DOS Protection at the Session Level
You configure Session Level DoS Protection on the SBC on either the realm-config or the session-agent elements. The session-agent configuration takes precedence. This procedure makes this configuration on a realm-config, which allows the procedure to include required realm configuration which is not available from a session-agent. These settings are still, however, required on the realm to which that session-agent belongs.
To set the dos-action-at-session parameter: