F Intrusion Detection System
The SBC supports intrusion detection and protection capabilities using anomaly based detection. SIP messages are compared to their expected format per the SIP RFCs, and may be repaired or rejected based on the severity of the issue and the settings defined by the administrator. The Intrusion Detection System (IDS) provides notification of unexpected events using all of the SD’s configured monitoring methods, though the amount of detail in each may vary. An optional IDS Reporting Feature Group license provides additional detail for attempted intrusions and suspicious behavior. The IDS feature is part of the SBC Base Entitlement Group, and no extra license is required.
This section details the security related events and statistics the SBC monitoring features can provide, some of which may be used as input to a security monitoring platform. Some of the following information may be partially repeated in other sections, however the intent is to provide further details and depict the relationship of various indicators here.
IDS Details
- Media manager
configuration elements visible after installing the license:
- trap-on-demote-to-deny – controls traps for deny events
- trap-on-demote-to-untrusted – controls traps for untrust demotion events
- syslog-on-demote-to-deny – controls syslogs for deny events
- Access control list
configuration elements visible after installing the license:
- cac-failure-threshold –contributes to demotion
- untrust-cac-failure-threshold –contributes to demotion
- Endpoint demotions based on admission control failures
- When the IDS license is installed, the apSysMgmtInetAddrWithReason-DOSTrap trap (described below) is available and the apSysMgmtExpDOSTrap is disabled. Without an IDS license installed, only the apSysMgmtExpDOSTrap trap is available.
Endpoint Promotions and Demotions
Endpoints, irrespective of whether or not they are defined as session-agents are promoted/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.
- It receives too many signaling messages within the configured time window (maximum-signal-threshold in the realm or static ACL)
- It receives too many invalid signaling messages within the configured time window (invalid-signal-threshold in the realm or static ACL)
- It receives too many signaling messages from an untrusted source within the configured time window (untrusted-signal-threshold in the realm or static ACL)
- A trusted endpoint exceeds the call admission controls and the cac-failure-threshold defined in an ACL (the call admission control limits are defined in media profiles)
- An untrusted endpoint exceeds call admission controls and the untrust-cac-failure-threshold defined in an ACL
- It received a 200 OK response to a registration
- The registration overload protection (reg-overload-protect) option has been set globally in the sip-config element (this is temporary, and only if a 401 or 407 response is received)
- The deny-period has expired
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 0SNMP MIB OIDS
The ACL statistics counters described above 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.
- apSysMgmtDOSInetAddressType—Blocked IP address family (IPv4 or IPv6)
- apSysMgmtDOSInetAddress—Blocked IP address
- apSysMgmtDOSRealmID—Blocked Realm ID
- apSysMgmtDOSFromURI—The FROM header of the message that caused the block (If available)
- apSysMgmtDOSReason—The
reason for demoting the endpoint to the denied queue: This field can report the
following three values:
- Too many errors
- Too many messages
- Too many admission control failures
HDR
- Demote Trust-Untrust - Global counter of endpoint demotion from trusted to untrusted queue
- Demote Untrust-Deny - Global counter of endpoint demotion from untrusted to denied queue
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 0Syslog
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 Black-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 Black-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- What are the stable and “common” values of these counters
- On-going demotions/promotions on ACLs and to which SIP UAs they refer to
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. However, if an endpoint fails re-registration, it will be demoted from trusted to untrusted.
Similarly, if an endpoint sends an INVITE with authentication, but the credentials do not match what is known to the registrar, it will be demoted as well.
In these cases, 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. If 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
If an endpoint exceeds the following CAC thresholds, the SBC will demote 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 sessio
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 outlined in the DDoS BCPs [10, 11]. These settings are considered the minimum configuration required to protect the SD. Upon deployment of a DDoS provisioned SBC it’s recommended that customers continuously monitor common traffic load and patterns of services traversing their SBC, and understand any alarms received.
Regardless of the monitoring method used (i.e. SNMP, CDR, HDR, Syslogs), during the initial period after implementation it’s 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 via 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/promotions on ACLs, and to which SIP UAs they refer to
- Why there are any deny entries and to which SIP UAs they refer to
- Whether the deny period set is helping or causing more issues
- Whether the assigned trust level is denying more than one endpoint (e.g. issues with NAT)
- CAC or session count thresholds, and whether they are impacting service
Once this knowledge base is built and properly document 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 Session Border Controller.
It’s strongly recommended to parse and evaluate 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 Session Border Controller 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 Session Border Controller 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.
- name - name of the session-constraint, this must be an unique identifier
- max-sessions - maximum sessions allowed for this constraint
- max-inbound-sessions - maximum inbound sessions allowed for this constraint
- max-outbound-sessions - maximum outbound sessions allowed for this constraint
- max-burst-rate - maximum burst rate (invites per second) allowed for this constraint
- max-inbound-burst-rate - maximum inbound burst rate (number of session invitations per second) for this constraint
- max-inbound-sustain-rate - maximum inbound sustain rate (of session invitations allowed within the current window) for this constraint
- max-outbound-burst-rate - maximum outbound burst rate (number of session invitations per second) for this constraint
- max-sustain-rate - maximum rate of session invitations allowed within the current window for this constraint
- max-inbound-sustain-rate - maximum inbound sustain rate (of session invitations allowed within the current window) for this constraint
- max-outbound-sustain-rate - maximum outbound sustain rate (of session invitations allowed within the current window) for this constraint
- min-seizures - minimum number of seizures for a no-answer scenario
- min-asr - Enter the minimum ASR in percentage
- time-to-resume - number of seconds after which the SA (Session Agent) is put back in service (after the SA is taken out-of-service because it exceeded some constraint)
- in-service-period - Enter the time in seconds that elapses before an element (like a session agent) can return to active service after being placed in the standby state
- ttr-no-response - Enter the time delay in seconds to wait before changing the status of an element (like a session agent) after it has been taken out of service because of excessive transaction timeouts
- burst-rate-window - Enter the time in seconds used to measure the burst rate
- sustain-rate-window - Enter the time in seconds used to measure the sustained rate
Oracle recommends use of session constraints on external SIP interfaces to limit the total number of sessions and / or 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.033Message 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 108SNMP 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