IP ACL Policing - Packet Filtering

Traffic Filtering and Policing

The

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 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

. It is not concerned with SIP message leaving the . ACLs protect the  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

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

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 

decides if a packet is a media packet, signaling packet, or a management packet.

Dynamic Blacklisting

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.

Enhanced Dynamic Blacklisting

The 

 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  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.

• When an endpoint triggers a rule with a blacklist action, all packets from that endpoint are dropped for the effective period. When the timer expires, the entry is removed.
• When an endpoint triggers a rule with a 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.

This 

 enhanced profile supports handling offending events in a flexible way apart from triggers such as  the two consecutive 401s for REGISTER messages, badSipMessage, and endpoint CAC rejection.

For more information, refer to:

• Enhanced DBL Profile - CLI
• Request Address Context - CLI
• Show Table Address Context
• Configuring Enhanced Dynamic Blacklist Profile
• sonusSbxDBLEnhActionSetNotification - MINOR
• sonusSbxDBLEnhActionClearNotification - MINOR
  

Policing Steps Summary

 A summary of the high level

steps to filter and police policy for media, signaling, and control traffic packets is described below.

1. Initially, wire-rate policers are applied as soon as the

   Unable to show "metadata-from": No such page "_space_variables"
   receives a packet at NIF (see Figure 1 for the flow).
   Note

   The term "wire-rate policer" represents the steps performed before registered/registering peer policing/aggregate policing.

   SBC Packet Policing Flow

   
2. After wire-rate policers have completed, the packet is sent to one of the following application policers (system automatically distributes packet based on the registration status):
   1. Registered Peer Policing—Packet comes from registered peer. The policer parameter is taken from Registered Endpoint CAC Profile associated to SIP Trunk Group.
   2. Registering Peer Policing—Packet comes from peer now registering. The micro-flow policer policy is applied. The parameters associated with this are not configurable.
   3. Unknown Peer Policing—Packet comes from non-registered peer, and goes to operator configured ACL flow policer, and then to system configured ACL low policer
      
      
3. After individual policing completes, all SIP and H323 packets go to an aggregate policer which is applied on a per-zone basis. Within this policer, the packet is prioritized (from highest to lowest) as follows.
   1. Registered access peers
   2. "Whitelisted" – matches an operator-configured ACL rule
   3. Registering access peers
   4. "Dark gray" – matches a defaulted signaling port ACL rule

 

Policing for Multiple Signaling Ports on Same IP Address

When an operator configures multiple SIP signaling ports on the same IP address in the same address context,

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.

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 20.20.20.20:5080 (Peer A) and 30.30.30.30: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.

• UDP packets coming from the peer 20.20.20.20:5080/UDP to UDP port 5060 match "Peering UDP A' rule.
• TCP packets from the peer 20.20.20.20:*/TCP to TCP port 5060 match "Peering TCP Ingress A" rule, which is for peer-initiated inbound TCP connection to the
  Unable to show "metadata-from": No such page "_space_variables"
  's SIP signaling port.
• TCP packets from the peer 20.20.20.20:5080/TCP match "Peering TCP Egress A" rule, which is for outbound-initiated TCP connection with ephemeral port numbers on the
  Unable to show "metadata-from": No such page "_space_variables"
  .
• UDP packets coming from the peer 30.30.30.30:5090/UDP to UDP port 5070 will match "Peering UDP B" rule.

 

Automatically Log a Traceroute Request for IP Signaling Outage

The 

 supports tracing routes for specific peer IP addresses. 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).

The 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:

• If the ARS blacklists a server, SIP Signaling Gateway (SIPSG)  sends a traceroute request to log the route for the blacklisted server.
• When the Gateway-Gateway (GW-GW) TCP connection is lost and cannot be restored, the Gateway Signaling Gateway (GWSG) sends traceroute request to log the route for the peer GW server.
• When the establishment of a GW-GW connection fails.
• When a peer IP address is blacklisted by the PathCheck process via the ARS mechanism.

To allow the Internet Control Message Protocol (ICMP) packets from different routers when the traceroute starts, an Access Control List (ACL) entry is configured. As soon as the traceroute output is available, this ACL entry is removed.

 

For configuration details, refer to Zone - Traceroute Sig Port - CLI.

Pushing Audit Records to Remote Server Using rsyslog.conf File

The

supports enabling or disabling the audit logs to start or stop the auditd service, which is used to write the audit logs. The 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 platformAuditLogs to support pushing the audit logs to a remote server.

• a remote host IP address
• a port number
• a protocol type

When these fields are configured and the object platformAuditLogs is enabled, the /etc/rsyslog.conf file is configured automatically to send the audit logs to the remote server. The /etc/rsyslog.conf 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

to receive the audit logs. The

Unable to show "metadata-from": No such page "_space_variables"

automatically adds an Access Control List (ACL) rule to send the audit logs through the application layer to the remote server.

For more information, refer to:

• Event Log - CLI

• Show Table OAM

• OAM - Event Log - Platform Audit Logs
• Pushing Audit Records to Remote Server Using rsyslog.conf File