|Sonus Documentation Portal|
The SBC Core supports traffic filtering and policing mechanisms to block packets that may be harmful to the network. Packet policing is done at several different levels of granularity, with all appropriate levels of policing applied to each packet. This section describes SBC Core policing and filtering mechanisms for providing packet level Denial Of Service (DoS) protection and access control.
IP Access Control Lists (ACLs) are filters and policers that deals only with packets associated with SIP message arriving at the SBC. It is not concerned with SIP message leaving the SBC. ACLs protect the SBC from attacks by preventing traffic from all other IP addresses except those specified on the "white list". However, only signaling and management IP traffic is subjected to IP ACL filtering. Media IP traffic (such as RTCP, SRTCP, SRTP and RTP) is not subjected to IP ACL filtering. For more information on IP ACLs, see Types of ACLs.
An attack is defined as an excessive packet discard rate (of various packet types), when the rate of incoming packets exceeds the Fill Rate. Fill Rate is measured in "packets per second" or "pps". The policing is done based on fill rate and token buckets. Fill rate determines the rate in which credits are applied to the bucket. So a 20 pps Fill Rate means one credit every 50 millisecond. If you have a Bucket Size of 50 packets and Fill Rate of 20 pps, the policer can handle a burst of 50 packets but if the 51st packet arrives 49 millisecond later, that packet will be dropped. This is because the Fill Rate applies credit every 50 millisecond so a packet arriving before that will get dropped. The Bucket Size allows room for sudden bursts of traffic, whereas the Fill Rate indicates the expected steady state flow of the traffic. For more information on Token Buckets and Fill Rates, please consult Token Bucket Policers.
Once recognized, a DoS attacks trigger alarms. Packet discard rate thresholds and duration are defined for recognizing the end of an attack which also triggers an alarm.
The policers monitor all packets. Packet discard rates are measured against the threshold rate and duration levels configured in the Discard Rate Profile. An alarm is triggered when a a threshold discard rate (or higher) is maintained for a prescribed duration. That alarm is cleared when a lesser threshold is met and that discard rate (or lower) is maintained for a prescribed duration. These alarms are configured on a system-wide basis.
On the SBC platforms, network interfaces may be configured with IP policers. Media policing is enabled/disabled on a system-wide basis and operates on a per-media flow basis. The policer configuration, status, and statistics are accessible through EMA or CLI.
The SBC Core supports hardware-based policing to ensure excessive network traffic (due to heavy load or an attack) does not disrupt the system, the internal network, or customers. These hardware-based policers filter packets at wire-rate which means the policers keep up with all the packets arriving on an interface to prevent an attack from overwhelming the protective measures using a significantly high attack rate. Each packet is evaluated and either forwarded or rejected.
Once a received packet is validated by the hardware, it is placed into either a media or non-media stream. The SBC decides if a packet is a media packet, signaling packet, or a management packet.
Dynamic blacklisting is a feature that detects abnormal events from end points, and blocks traffic from those end points for a configured period of time. Dynamic blacklisting is designed to detect misbehaving end points rather than prevent malicious attacks, for which the system already has other mechanisms.
Dynamic Blacklist (DBL) events and the actions to take for each event are configurable using a set of DBL rules in a DBL profile. The DBL profile is then assigned to a SIP trunk group. Any packets entering the system from that trunk group is then compared against the rules configured in that DBL profile.
The SBC Core enhanced Dynamic Blacklist (DBL) feature provides the ability to restrict packets and rejects the SIP messages received from endpoints based on the criteria and action, which are provided in a rule. In this way, the SBC is protected from offending or misconfigured/misbehaving endpoints. The enhanced DBL Profile is configured to contain one or more rules. The profile is then associated with a SIP Trunk Group. The rules contain criteria and action. This SBC enhanced profile supports handling offending events in a flexible way apart from triggers such as the two consecutive 401s for REGISTER messages,
rejectWithResponse action, all SIP requests from that endpoint are rejected with the response configured in the rule for the configured effective period. When the timer expires, the entry is removed.
badSipMessage, and endpoint CAC rejection.
The SBC Core enhanced Dynamic Blacklist (DBL) feature provides the ability to restrict packets and rejects the SIP messages received from endpoints based on the criteria and action, which are provided in a rule. In this way, the SBC is protected from offending or misconfigured/misbehaving endpoints.
The enhanced DBL Profile is configured to contain one or more rules. The profile is then associated with a SIP Trunk Group. The rules contain criteria and action.
This SBC enhanced profile supports handling offending events in a flexible way apart from triggers such as the two consecutive 401s for REGISTER messages,
A summary of the high level SBC Core steps to filter and police policy for media, signaling, and control traffic packets is described below.
Initially, wire-rate policers are applied as soon as the SBC receives a packet at NIF (see Figure 1 for the flow).
The term "wire-rate policer" represents the steps performed before registered/registering peer policing/aggregate policing.
Non-signaling packets are put into specific aggregate policers based on protocol type (management, overhead, ICMP, IKE, ARP, media).
Media is policed at the rate implied by the codec selected during call setup. For the other protocols, a system-installed ACL is used.
When you enable
Signaling Packet Capture without any configuring any signaling filter (the default behavior), the SBC creates a default filter using all the configured signaling IP addresses and ports. The default filter collects only the first fragmented IP packet and ignores the rest. This happens because the UDP/TCP ports are also included in the default filter, but the IP packet fragments except the first fragment does not include the relevant headers. For the same reason, even if you create a filter which includes only the
Local Port Number, the fragments except the first one are not captured.
To capture all packet fragments, create a
Signaling Packet Capture filter with specific
Local IP Address, or
Peer IP Address, or both, and then enable
Signaling Packet Capture.
When an operator configures multiple SIP signaling ports on the same IP address in the same address context, SBC Core creates multiple default system Access Control Lists (ACLs) for SIP signaling traffic including one for each SIP signaling port. Because the SIP signaling ports in this scenario use the same IP address and default system ACLs match only on Address Context, IP Interface Group, and destination IP Address, the default system ACLs use the same packet matching criteria. All SIP signaling packets destined to these SIP signaling ports match the first default system ACL created for these SIP signaling ports.
The default system ACL for SIP signaling ports uses a wild-carded protocol, source IP, source port number, destination port number.
If you need to police packets sent to individual SIP signaling ports, configure 'user' IP ACLs for each SIP signaling port. In an IP ACL for access deployment, specify not only destination address (SIP signaling address), but also protocol (UDP/TCP) and destination port number (SIP signaling port's UDP/TCP port number). In a case where SIP port is used for a peering deployment, the peer's IP address (source IP) and port number (source port) are frequently known and can additionally be specified in the IP ACL.
The table below depicts IP ACLs and the default system ACL for two SIP signaling ports configured with the same IP address (10.10.10.20) with port numbers 5060 and 5070 for peering scenario where port number 5060 supports both SIP-UDP and SIP-TCP and port number 5070 supports SIP-UDP only. The two peers' addresses/ports are 22.214.171.124:5080 (Peer A) and 126.96.36.199:5090 (Peer B), respectively.
Configuration of the IP ACLs is accomplished using lower precedence values ("higher priority") for the IP ACLs and fully specified for the protocol, source-IP, and source-Port.
Scenario / Rule
|Destination||Destination||Users ACL |
|Remote IP||Remote Port||Local IP||Local Port|
|Peering UDP A||188.8.131.52||5080||UDP||10.10.10.20||5060||101|
|Peering TCP Ingress A||184.108.40.206||*||TCP||10.10.10.20||5060||102|
|Peering TCP Egress A||220.127.116.11||5080||TCP||10.10.10.20||*||103|
|Peering UDP B||18.104.22.168||5090||UDP||10.10.10.20||5070||111|
|Default System ACL A||*||*||*||10.10.10.20||*||N/A|
|Default System ACL B||*||*||*||10.10.10.20||*||N/A|
The SBC Core supports tracing routes for specific peer IP addresses. The The To allow the Internet Control Message Protocol (ICMP) packets from different routers when the Note For the
traceroute utility provided by the GNU/Linux is utilized as a base for this functionality. This feature handles and processes the
traceroute requests from the Signaling Gateway (SG).
traceroute functionality for a peer IP address is invoked by sending a
traceroute request message to the
Traceroute module. The message contains details of the peer's IP address, which is processed by the
TRCRT/Traceroute module. This feature supports the following scenarios:
traceroute request to log the route for the blacklisted server.
traceroute request to log the route for the peer GW server.
traceroute starts, an Access Control List (ACL) entry is configured. As soon as the
traceroute output is available, this ACL entry is removed.
traceroute utility to work, a higher precedence "IP ACL rule" is created to accept ICMP traffic on the SIP Signaling port. This rule overrides any "deny-all" or "deny-ICMP" User ACL rule configured by the Administrator. This higher precedence "IP ACL rule" is created before the start of
traceroute for an endpoint, and is be removed as soon as the
traceroute is over. Thus, for the brief duration of
traceroute, the ICMP traffic to the Signaling port is allowed from any IP address, even if "deny-ICMP" or "deny-all" User ACL rules are configured in the system.
The SBC Core supports tracing routes for specific peer IP addresses. The
To allow the Internet Control Message Protocol (ICMP) packets from different routers when the
The SBC supports enabling or disabling the audit logs to start or stop the auditd service, which is used to write the audit logs. The SBC is enhanced to configure a remote server IP address, port, and protocol type to push the audit logs to the remote server. The following fields are added to the object When these fields are configured and the object Note For a High Availability (HA) pair, the
platformAuditLogs to support pushing the audit logs to a remote server.
platformAuditLogs is enabled, the
rsyslog.conf file is configured automatically to send the audit logs to the remote server. The
file sends the
/var/log/audit/audit.log to the remote server's
/var/log/messages file. The remote server's
/etc/rsyslog.conf file must match the configuration of the SBC to receive the audit logs. The SBC automatically adds an Access Control List (ACL) rule to send the audit logs through the application layer to the remote server.
platformAuditLogs is enabled.
platformAuditLogs is disabled.
file is updated both on the Active and the Standby SBCs to push the audit logs to the remote server.
The SBC supports enabling or disabling the audit logs to start or stop the auditd service, which is used to write the audit logs. The SBC is enhanced to configure a remote server IP address, port, and protocol type to push the audit logs to the remote server.
The following fields are added to the object
When these fields are configured and the object
For a High Availability (HA) pair, the