IDS Details

Endpoint Promotions and Demotions

Endpoints, whether or not they are defined as session-agents, are promoted and demoted between hardware-enforced trusted, untrusted, and denied Access Control List traffic queues based on trust level configuration. Static ACLs are also configurable to further classify signaling traffic as being permanently assigned to the appropriate trust queue.

Trust is assigned through several mechanisms including the access-control-trust-level parameter of the realm the session-agent or end point is a member of, trust-level of provisioned ACLs, and the allow-anonymous setting on the applicable sip-interface.

Statistics

Each promotion and demotion event, between trusted, untrusted, and deny queues is counted and kept as an ACL statistic. These counts are maintained separately for signaling applications.

ACMESBC# show sipd acls
16:25:48-180
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

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       0

SNMP MIB OIDS

The ACL statistics counters described previously are also available for SNMP polling under APSYSMGMT-MIB -> acmepacketMgmt -> apSystemManagementModule -> apSysMgmtMIBObjects -> apSysMgmtMIBGeneralObjects

• apSysSipEndptDemTrustToUntrust (.1.3.6.1.4.1.9148.3.2.1.1.19) - Global counter for SIP endpoint demotions from trusted to untrusted.
• apSysSipEndptDemUntrustToDeny (.1.3.6.1.4.1.9148.3.2.1.1.20) - Global counter for SIP endpoint demotions from untrusted to denied.

SNMP Traps

Enabling the trap-on-demote-to-deny parameter located in the media-manager-config configuration element enables SNMP traps to be sent for demotions to the denied queue.

When the IDS license is installed, the apSysMgmtInetAddrWithReasonDOSTrap trap is sent. Otherwise, only the apSysMgmtInetAddrDOSTrap trap is sent.

The IDS Reporting Feature Group added the capability for the SBC to send a trap when the SBC demotes an endpoint to the untrusted queue. Enabling the trap-on-demote-to-untrusted parameter located in the media-manager-config configuration element enables these. The same apSysMgmtI-netAddrWithReasonDOSTrap is sent.

When the IDS license is installed and the trap-on-demote-to-deny or trap-on-demote-to-untrusted parameters are disabled, the apSysMgmtI-netAddrWithReasonDOSTrap trap is not sent from the SBC, even when an endpoint is demoted.

HDR

TimeStamp  ACL Requests Bad Msgs Promo Demo Demote Trust-Untrust Demote Untrust-Deny
1369338880 0            0        0     0    0                    0
1369338940 0            0        0     0    0                    0
1369339000 0            0        0     0    0                    0
1369339060 0            0        0     0    0                    0

Syslog

A syslog message can also be generated when an endpoint is demoted. Setting the media-manager config -> syslog-on-demote-to-deny parameter to enabled writes an endpoint demotion warning to the syslog every time an endpoint is demoted to the denied queue. Demotions from trusted to untrusted can also be reported by setting the media-manager -> syslog-on-demote-to-untrusted parameter to enabled. By default, these configuration options are set to disabled.

Without the IDS Reporting Feature Group license applied, the syslog messages have a WARNING level and look like this:

Jan 15 12:22:48 172.30.60.12 ACMESYSTEM sipd[1c6e0b90] WARNING SigAddr[access:192.168.24.40:0=low:DENY] ttl=3632 guard=798 exp=30
Demoted to Block-List (Too many admission control failures)

The IDS Reporting Feature Group will provide an ERROR message with further detail like this:

Nov 28 17:53:47 172.41.3.41 ACMESYSTEM sipd[2dcc32a4] ERROR [IDS_LOG] SigAddr[access:192.168.101.120:0=low:DENY] ttl=86400 exp=30 Demoted to Block-List (Too many messages) last msg rcvd=REGISTER sip:192.168.66.2 SIP/2.0
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR Via: SIP/2.0/UDP 192.168.190.144:20928;branch=z9hG4bKdeadb33f
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR From: <sip:47097@192.168.190.144:20928>
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR To: <sip:47097@192.168.66.2:5060>
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR Call-ID: f9844fbe7dec140ca36500a0c9119870@192.168.66.2
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR CSeq: 1 REGISTER
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR Contact: <sip:47097@192.168.190.144>
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR User-agent: UAC
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR Max-Forwards: 5
Nov 28 17:53:47 172.41.3.41 CSE-4500-6 sipd[2dcc32a4] ERROR Content-Length: 0

Monitoring systems need to be configured to take these normal variations into account, and have appropriate thresholds defined. Note that the thresholds, as well as the SBC DoS or CAC parameters may need to be adjusted over time as the network being monitored grows and changes.

Authentication Failures used for Endpoint Demotion

Endpoints that have become trusted due to successful registration are entered into the registration cache. The cache is used to store the user and location information for authenticated endpoints. It may also be used to shield the registrar from having to respond to re-registrations by providing the SBC the data to reply to a portion of re-registrations locally. When an endpoint fails re-registration, it will be demoted from trusted to untrusted.

When an endpoint sends an INVITE with authentication, but the credentials do not match what is known to the registrar, it will be demoted.

In these scenarios, 401 or 407 responses are received from the registrar, and the demotion occurs.

Per-endpoint Call Admission Control

The SBC can demote endpoints from trusted to untrusted, or untrusted to denied queues when CAC failures exceed a configured threshold. The SBC maintains CAC failures per-endpoint. The CAC failure counter is incremented upon certain admission control failures only if either: cac-failure-threshold or untrust-cac-fail-threshold is set to a non-zero integer.

The cac-failure-threshold parameter is configurable in the access control and realm configuration elements. Exceeding the threshold integer defined in this parameter demotes an endpoint from the trusted queue to the untrusted queue. Additionally, the untrust-cac-failure-threshold parameter is configurable in the access control and realm configuration elements. Exceeding the threshold integer defined in this parameter demotes an endpoint from the untrusted queue to the denied queue. When both the cac-failure-threshold and untrust-cac-failure-threshold are configured to 0, admission control failures are considered and counted as invalid signaling messages for determining if the invalid-signal-threshold parameter value has been exceeded.

CAC failures used for Endpoint Demotion

The SBC determines CAC failures only by considering the number of signaling messages sent FROM an endpoint TO the realm its signaling messages traverse

When an endpoint exceeds the following CAC thresholds, the SBC demotes the endpoint when the CAC failure thresholds are enabled.

• sip-interface user CAC sessions (realm-config > user-cac-sessions)
• sip-interface user CAC bandwidth (realm-config > user-cac-bandwidth)
• External policy server rejects a session

Thresholds and Trending Analysis

Thresholds and trending analysis are important concepts that must be well understood and implemented during initial installation of the SBC. Thresholds should be monitored and settings periodically adjusted as network usage or capacity requirements change. To be supported by Oracle TAC, SBC deployments require a minimum set of standard configurations explained in the DDoS Prevention appendices. These settings are considered the minimum configuration required to protect the SD. Upon deployment of a DDoS provisioned SBC Oracle recommends that you continuously monitor common traffic load and patterns of services traversing your SBC, and understand any alarms received.

Regardless of the monitoring method used (for example, SNMP, CDR, HDR, Syslogs), during the initial period after implementation it is crucial to understand:

• The number of active SIP sessions seen during normal and peak periods
• Average call hold times
• Average signaling messages for a call (usually best collected through Wireshark or other network capture tool)
• What are the stable and “common” values of these for the different counters
  • Trusted to Untrusted Demotions
  • Untrusted to Deny Demotions
  • Demotions
  • Promotions
• On-going demotions and promotions on ACLs, and to which SIP UAs they refer
• Why there are any deny entries and to which SIP UAs they refer
• Whether the deny period set is helping or causing more issues
• Whether the assigned trust level is denying more than one endpoint (for example, issues with NAT)
• CAC or session count thresholds, and whether they are impacting service

When this knowledge base is built and properly documented for future reference, threshold values for reasonable variations in these counters should be defined and implemented in the monitoring platforms handling the SNMP Traps, HDR data, Sys-logs provided by the SBC.

Oracle recommends parsing and evaluating the information provided in any apSysMgmtInetAddrWithReasonDOSTrap SNMP traps received. Using this information it should be possible to identify SIP UAs and accounts involved, and understand whether legitimate traffic is being denied. Further actions may be required after this analysis; for example: configuration improvements to avoid illegitimate traffic from reaching the Host CPU may be needed, or, if the traffic is expected, adjustment of the appropriate constraints to allow the legitimate traffic to flow properly.

This process is an iterative loop where the fine-tuning and documenting illegal behavior flows can be continuously improved. This is especially true if the SBC is exposed to the Internet in an Access Scenario. When connected to the Internet, different trends and attempted illegal behaviors may be seen as the complexity of SIP attacks and trends evolve.

Constraints Limiting

The SBC provides two distinct mechanisms to throttle any SIP method: session constraints and rate-constraints. While session constraints are responsible for throttling both INVITE and REGISTER methods, rate constraints are used for throttling any other type of SIP method. Session constraints and rate constraints can be configured in either Session-Agent or SIP-interface config objects (via session-constraints). Note: Make sure to enable the sip-config > extra-method-stats option before configuring any constraints since this enables the constraint counters.

Session-Constraints

The session-constraints configuration element defines session layer constraints for session measurements such as maximum concurrent sessions, maximum outbound concurrent sessions, maximum session burst rate, and maximum session sustained rate.

Oracle recommends use of session constraints on external SIP interfaces to limit the total number of sessions and traffic bursts that the combined configured session agents can handle for that service. Additionally, having multiple public SIP interfaces defined can limit the resources a particular SIP interface can provide based on service level agreements or the trust level of the endpoint.

Rate constraints

The rate-constraints sub-element is configurable under both the session-constraints and session-agent configuration elements (though they are not shared). It allows configuration of rate limiting based on specific method types. These further restrict any defined constraints of the parent, so they cannot exceed the rates defined at the level under which they are set.

• method—the SIP method name for the method to throttle, possible values are: NOTIFY, OPTIONS, MESSAGE, PUBLISH, REGISTER
• max-inbound-burst-rate—For the SIP method configured in the method parameter, this number will restrict the inbound burst rate on the SIP interface.
• max-outbound-burst-rate—For the SIP method configured in the methods parameter, this number will restrict the outbound burst rate on the SIP interface.
• max-inbound-sustain-rate—For the SIP method configured in the methods parameter, this number will restrict the inbound sustain rate on the SIP.
• max-outbound-sustain-rate—For the SIP method configured in the methods parameter, this number will restrict the outbound sustain rate on the SIP interface.

Each rate constraint configured for a SIP method maintains its own counters. For example, if a rate constraint for the PUBLISH method is configured, the burst and sustain rates set for it apply only to the PUBLISH method and not to any other methods.

The SBC captures statistics for SIP methods that have already been throttled by rate constraints for SIP interfaces and session agents; it does not capture these statistics for the global SIP configuration. SIP interfaces have two states: “In Service” and “Constraints Exceeded.” When any one of the constraints is exceeded, the status of the SIP interface changes to “Constraints Exceeded” and stops accepting traffic. It remains in that state until the time-to-resume period ends. The session constraint timers that apply to the SIP interface are the time-to-resume, burst window, and sustain window.

Oracle recommends configuration of INVITE and REGISTER method rate constraints on session agents.

For SIP access deployments, rate constraints for individual method types along with a set of burst and sustain rates should be considered. These constraints can help to avoid overloading the core network. In addition, they restrain the load non-INVITE messages use, thus reserving capacity for INVITE-based sessions and registrations.

In order to properly configure constraint limiting, either at SIP interface level or per Session-Agent (SA), it’s essential to have an accurate understanding of the SIP Message flows that exist in the network. Contributing factors include: factors such as which SIP requests are authenticated, what Call flows and Session Agents require re-INVITEs, maximum CPS per SA, etc. The reason why these details are so important is the SBC is making dynamic decisions and acting on this traffic in real time.

SNMP traps will be sent when constraints are exceeded. Constraint threshold crossing alarms or statistics are not necessarily a security issue since legitimate traffic overloads or mass network restarts may also cause them. It is up to the customer to assess if they should investigate alarms as possible security incidents.

To monitor SIP interface and Session Agents, two commands are most useful. The following commands include statistics on how many times the constraints were exceeded and the interface or session agent was temporarily taken out of service.

show sipd interface <realm name> and show sipd agents <agent name>

ACMEPACKET# show sipd interface access
00:51:55-34
Sip Interface access
                             -- Period -- -------- Lifetime --------
                   Active    High   Total      Total  PerMax    High
Inbound Sessions     9000    9002    1715   14244739    1501    9009
  Rate Exceeded         5       5       5          5       5       5
  Num Exceeded          -       -       0          0       0       -
  Burst Rate            0      50       0          0       0      51
Outbound Sessions       0       0       0          0       0       0
  Rate Exceeded         -       -       0          0       0       -
  Num Exceeded          -       -       0          0       0       -
  Burst Rate            0       0       0          0       0       0
Local Contacts          0       0       0          0       0       0
HNT Entries             0       0       0          0       0       0
Non-HNT Entries         0       0       0          0       0       0
Subscriptions           0       0       0          0       0       0
Out of Service          -       -       0          0       0       -
Trans Timeout           0       0       0          0       0       0
Requests Sent           -       -       0        284       1       -
Requests Complete       -       -       0          0       0       -
Seizure                 -       -       0          0       0       -
Answer                  -       -       0          0       0       -
  ASR Exceeded          -       -       0          0       0       -
Messages Received       -       -   14097  114313292   12405       -
Latency=0.000; max=0.000

ACMEPACKET# show sipd agents 192.168.60.10
00:54:10-49
Session Agent 192.168.60.10() [In Service]
                             -- Period -- -------- Lifetime --------
                   Active    High   Total      Total  PerMax    High
Inbound Sessions        0       0       0          0       0       0
  Rate Exceeded         -       -       0          0       0       -
  Num Exceeded          -       -       0          0       0       -
  Burst Rate            0       0       0          0       0       0
  Reg Rate Exceeded     -       7      21         21      21      21
  Reg Burst Rate        0       0       0          0       0       0
Outbound Sessions    9000    9003    2452   14251475    1501    9009
  Rate Exceeded         -       -       0          0       0       -
  Num Exceeded          -       -       0          0       0       -
  Burst Rate            0      50       0          0       0      51
  Reg Rate Exceeded     -       -       0          0       0       -
Local Contacts          0       0       0          0       0       0
HNT Entries             0       0       0          0       0       0
Non-HNT Entries         0       0       0          0       0       0
Subscriptions           0       0       0          0       0       0
Out of Service          -       -       0          3       1       -
Trans Timeout           0       0       0         44       1      40
Requests Sent           -       -   17666  100035216   10906       -
Requests Complete       -       -   17671  100035175   10905       -
Seizure                 -       -    2456   14251479    1501       -
Answer                  -       -    2456   14250766    1502       -
  ASR Exceeded          -       -       0          0       0       -
Messages Received       -       -   22595  128521055   13904       -
Latency=0.002; max=0.033

Message Rejections

The action type called reject is available to all header manipulation rules. When this action type is used, and a condition matching the manipulation rule arises, the SBC rejects the request, provides a SIP error, and increments a counter.

• If the msg-type parameter is set to any and the message is a response, the SBC increments a counter to show the intention to reject the message—but the message will continue to be processed.
• If the msg-type parameter is set to any and the message is a request, the SBC performs the rejection and increments the counter.

The header manipulation rule -> new-value parameter is designed to supply the status code and reason phrase corresponding to the reject. The following syntax is used to supply this information: status-code[:reason-phrase] . The status-code and reason phrase information is not required since by default the system uses 400:Bad Request.

If this information is not supplied, the status code must be a positive integer between 300 and 699. With this defined, the SBC will use the applicable reason phrase corresponding to the status code in responses. To customize the reason phrase, enter the status code followed by a colon (:). NOTE: be sure to enclose the entire entry in quotation marks (ex: “400:Go Away” ) if the reason phrase includes spaces.

When the SBC performs the reject action, the current SIP manipulation stops processing and does not act on any of the rules following the reject rule. This course of action is also true for nested SIP manipulations that might have been constructed using the sip-manip action type. Keeping that in mind, the reject rule is usually the last rule in a long HMR.

Reject actions may also indirectly generate SNMP traps. Two parameters in the session-router-config define how many messages within a window of time cause the SBC to generate an SNMP trap.

• reject-message-threshold— defines the minimum number of message rejections allowed in the reject-message-window time on the SBC (when using the SIP manipulation action reject) before generating an SNMP trap.
• reject-message-window—defines the time in seconds that defines the window for maximum message rejections allowed before generating an SNMP trap. This should be set to something like 30 seconds to a minute. If set too low traps may be missed.

The SBC tracks messages that have been flagged for rejection using the reject action type. In the show sipd display, refer to the Rejected Messages category. Note that there is no distinction between requests and responses.

SIP Status                -- Period -- -------- Lifetime --------
                Active    High   Total      Total  PerMax    High
Sessions             0       0       0        538     211      38
Subscriptions        0       0       0          0       0       0
Dialogs              0       0       0        276      74      74
CallID Map           0       0       0       1076     422     386
Rejections           -       -       0          0       0
ReINVITEs            -       -       0          0       0
ReINV Suppress       -       -       0          0       0
Media Sessions       0       0       0        538     211      76
Media Pending        0       0       0          0       0       0
Client Trans         0       0       0        814     241      76
Server Trans         0       0       0       3626     366     193
Resp Contexts        0       0       0        538     211     193
Saved Contexts       0       0       0          0       0       0
Sockets              3       3       0          3       3       3
Req Dropped          -       -       0          0       0
DNS Trans            0       0       0          0       0       0
DNS Sockets          0       0       0          0       0       0
DNS Results          0       0       0          0       0       0
Rejected Msgs        0       0       0        200     108     108

SNMP support

• apSysRejectedMessages (.1.3.6.1.4.1.9148.3.2.1.1.18.0) - Number of messages rejected by the SBC due to matching criteria
• apSysMgmtRejectedMesagesThresholdExeededTrap (.1.3.6.1.4.1.9148.3.2.6.0.57) - The trap will be generated when the number of rejected messages exceeds the configured threshold within the configured window.
• apSysMgmtSipRejectionTrap (.1.3.6.1.4.1.9148.3.2.10.0.1) - Generated when a SIP INVITE or REGISTRATION request fail.

Log Action

The action type called: “log” is available to all header manipulation rules. When this action type is used, and a condition matching the manipulation rule arises, the SBC logs information about the current message to a separate log file.

This feature can be used to log important details from specific suspicious users, such as well-known SIP User-Agents, call attempts to undesirable destinations (known “hotlist” numbers, unassigned numbers, Premium Rate numbers, etc.).

If a match is found in an HMR, and the action is set to “log”, a logfile called matched.log will be created. The matched.log file contains a log message that contains a timestamp, destination IP address:port information, and the source IP address:port. It also specifies the rule that triggered the log action. The request URI, Contact header, To Header, and From header are also recorded. See the example below.

Apr 17 14:17:54.526 On [0:0]192.168.1.84:5060 sent to 192.168.1.60:5060
element-rule[checkRURIPort]
INVITE sip:service@192.168.1.84:5060 SIP/2.0
From: sipp <sip:+2125551212@192.168.1.60:5060>;tag=3035SIPpTag001
To: sut <sip:service@192.168.1.84>
Contact: sip:sipp@192.168.1.60:5060