Denial of Service Protection
This section explains the Denial of Service (DoS) protection for the Oracle® Enterprise Session Border Controller. The Oracle® Enterprise Session Border Controller DoS protection functionality protects softswitches and gateways with overload protection, dynamic and static access control, and trusted device classification and separation at Layers 3-5. The Oracle® Enterprise Session Border Controller itself is protected from signaling and media overload, but more importantly the feature allows legitimate, trusted devices to continue receiving service even during an attack. DoS protection prevents the Oracle® Enterprise Session Border Controller host processor from being overwhelmed by a targeted DoS attack from the following:
- IP packets from an untrusted source as defined by provisioned or dynamic ACLs
- IP packets for unsupported or disabled protocols
- Nonconforming/malformed (garbage) packets to signaling ports
- Volume-based attack (flood) of valid or invalid call requests, signaling messages, and so on.
- Overload of valid or invalid call requests from legitimate, trusted sources
The following diagram illustrates DoS protection applied to the softswitch and to the Oracle® Enterprise Session Border Controller.
Levels of DoS Protection
The multi-level Oracle® Enterprise Session Border Controller DoS protection consists of the following strategies:
- Fast path filtering/access control: access control for signaling packets destined for the Oracle® Enterprise Session Border Controller host processor as well as media (RTP) packets. The Oracle® Enterprise Session Border Controller performs media filtering by using the existing dynamic pinhole firewall capabilities. Fast path filtering packets destined for the host processor require the configuration and management of a trusted list and a deny list for each Oracle® Enterprise Session Border Controller realm (although the actual devices can be dynamically trusted or denied by the Oracle® Enterprise Session Border Controller based on configuration). You do not have to provision every endpoint/device on the Oracle® Enterprise Session Border Controller, but instead retain the default values.
- Host path protection: includes flow classification, host path policing and unique signaling flow policing. Fast path filtering alone cannot protect the
Oracle® Enterprise Session Border Controller host processor from being overwhelmed by a malicious attack from a trusted source. The host path and individual signaling flows must be policed to ensure that a volume-based attack will not overwhelm the
Oracle® Enterprise Session Border Controller’s normal call processing; and subsequently not overwhelm systems beyond it.
The Oracle® Enterprise Session Border Controller must classify each source based on its ability to pass certain criteria that is signaling- and application-dependent. At first each source is considered untrusted with the possibility of being promoted to fully trusted. The Oracle® Enterprise Session Border Controller maintains two host paths, one for each class of traffic (trusted and untrusted), with different policing characteristics to ensure that fully trusted traffic always gets precedence.
- Host-based malicious source detection and isolation – dynamic deny list. Malicious sources can be automatically detected in real-time and denied in the fast path to block them from reaching the host processor.
About the Process
DoS attacks are handled in the Oracle® Enterprise Session Border Controller’s host path. The Oracle® Enterprise Session Border Controller uses NAT table entries to filter out undesirable IP addresses; creating a deny list. After a packet from an endpoint is accepted through NAT filtering, policing is implemented in the Traffic Manager subsystem based on the sender’s IP address. NAT table entries distinguish signaling packets coming in from different sources for policing purposes. The maximum number of policed calls that the Oracle® Enterprise Session Border Controller can support is 16K (on 32K CAM / IDT CAM).
The Traffic Manager has two pipes, trusted and untrusted, for the signaling path. Each signaling packet destined for the host CPU traverses one of these two pipes.
Trusted Path
Packets from trusted devices travel through the trusted pipe in their own individual queues. In the Trusted path, each trusted device flow has its own individual queue (or pipe). The Oracle® Enterprise Session Border Controller can dynamically add device flows to the trusted list by promoting them from the Untrusted path based on behavior; or they can be statically provisioned.
Trusted traffic is put into its own queue and defined as a device flow based on the following:
- source IP address
- source UDP/TCP port number
- destination IP address
- destination UDP/TCP port (SIP interface to which it is sending)
- realm it belongs to, which inherits the Ethernet interface and VLAN it came in on
For example, SIP packets coming from 10.1.2.3 with UDP port 1234 to the Oracle® Enterprise Session Border Controller SIP interface address 11.9.8.7 port 5060, on VLAN 3 of Ethernet interface 0:1, are in a separate Trusted queue and policed independently from SIP packets coming from 10.1.2.3 with UDP port 3456 to the same Oracle® Enterprise Session Border Controller address, port and interface.
Data in this flow is policed according to the configured parameters for the specific device flow, if statically provisioned. Alternatively, the realm to which endpoints belong have a default policing value that every device flow will use. The defaults configured in the realm mean each device flow gets its own queue using the policing values. As shown in the previous example, if both device flows are from the same realm and the realm is configured to have an average rate limit of 10K bytes per second (10KBps), each device flow will have its own 10KBps queue. They are not aggregated into a 10KBps queue.
The individual flow queues and policing lets the Oracle® Enterprise Session Border Controller provide each trusted device its own share of the signaling, separate the device’s traffic from other trusted and untrusted traffic, and police its traffic so that it can’t attack or overload the Oracle® Enterprise Session Border Controller (therefore it is trusted, but not completely).
Untrusted Path
Packets (fragmented and unfragmented) that are not part of the trusted or denied list travel through the untrusted pipe. In the untrusted path, traffic from each user/device goes into one of 2048 queues with other untrusted traffic. Packets from a single device flow always use the same queue of the 2048 untrusted queues, and 1/2048th of the untrusted population also uses that same queue. To prevent one untrusted endpoint from using all the pipe’s bandwidth, the 2048 flows defined within the path are scheduled in a fair-access method. As soon as the Oracle® Enterprise Session Border Controller decides the device flow is legitimate, it will promote it to its own trusted queue.
All 2048 untrusted queues have dynamic sizing ability, which allows one untrusted queue to grow in size, as long as other untrusted queues are not being used proportionally as much. This dynamic queue sizing allows one queue to use more than average when it is available. For example, in the case where one device flow represents a PBX or some other larger volume device. If the overall amount of untrusted packets grows too large, the queue sizes rebalance, so that a flood attack or DoS attack does not create excessive delay for other untrusted devices.
In the usual attack situations, the signaling processor detects the attack and dynamically demotes the device to denied in the hardware by adding it to the deny ACL list. Even if the Oracle® Enterprise Session Border Controller does not detect an attack, the untrusted path gets serviced by the signaling processor in a fair access mechanism. An attack by an untrusted device will only impact 1/1000th of the overall population of untrusted devices, in the worst case. Even then there’s a probability of users in the same 1/1000th percentile getting in and getting promoted to trusted.
IP Fragment Packet Flow
All fragment packets are sent through their own 1024 untrusted flows in the Traffic Manager. The first ten bits (LSB) of the source address are used to determine which fragment-flow the packet belongs to. These 1024 fragment flows share untrusted bandwidth with already existing untrusted-flows. In total, there are 2049 untrusted flows: 1024-non-fragment flows, 1024 fragment flows, and 1 control flow.
Fragmented ICMP packets are qualified as ICMP packets rather than fragment packets. Fragment and non-fragmented ICMP packets follow the trusted-ICMP-flow in the Traffic Manager, with a bandwidth limit of 8Kbs.
Fragment Packet Loss Prevention
You can set the maximum amount of bandwidth (in the max-untrusted-signaling parameter) you want to use for untrusted packets. However, because untrusted and fragment packets share the same amount of bandwidth for policing, any flood of untrusted packets can cause the Oracle® Enterprise Session Border Controller to drop fragment packets.
To prevent fragment packet loss on the Acme Packet 3820 and Acme Packet 4500, you can set the fragment-msg-bandwidth. When you set any value other than 0 (which disables it), the Oracle® Enterprise Session Border Controller:
- Provides for a separate policing queue for fragment packets (separate from that used for untrusted packets)
- Uses this new queue to prevent fragment packet loss when there is a flood from untrusted endpoints.
When you set up a queue for fragment packets, untrusted packets likewise have their own queue—meaning also that the max-untrusted-signaling and min-untrusted-signaling values are applied to the untrusted queue.
Static and Dynamic ACL Entry Limits
The Oracle® Enterprise Session Border Controller can simultaneously police a maximum of 250,000 trusted device flows, while at the same time denying an additional 32,000 attackers. If list space becomes full and additional device flows need to be added, the oldest entries in the list are removed and the new device flows are added.
Dynamic Deny for HNT
Dynamic deny for HNT has been implemented on the Oracle® Enterprise Session Border Controller for cases when callers are behind a NAT or firewall. Without this feature, if one caller behind a NAT or firewall were denied, the Oracle® Enterprise Session Border Controller would also deny all other users behind the same NAT or firewall. This would be true even for endpoints behind the firewall that had not crossed threshold limits you set for their realm; all endpoints behind the firewall would go out of service. In the following diagram, both Phone A and Phone B would be denied because their IP addresses would be translated by the firewall to the same IPv4 address (192.168.16.2).
However, dynamic deny for HNT allows the Oracle® Enterprise Session Border Controller to determine, based on the UDP/TCP port, which endpoints should be denied and which should be allowed. The Oracle® Enterprise Session Border Controller can determine that even though multiple endpoints originating behind a firewall appear with the same IPv4 address, those addresses use different ports and are unique.
As shown in the diagram below, the ports from Phone A and Phone B remain unchanged. This way, if Phone A violates the thresholds you have configured, the Oracle® Enterprise Session Border Controller can block traffic from Phone A while still accepting traffic from Phone B.
Host and Media Path Protection Process
The Oracle® Enterprise Session Border Controller Network Processors (NPs) check the deny and permit lists for received packets, and classify them as trusted, untrusted or denied (discard). Only packets to signaling ports and dynamically signaled media ports are permitted. All other packets sent to Oracle® Enterprise Session Border Controller ports are filtered. Only packets from trusted and untrusted (unknown) sources are permitted; any packet from a denied source is dropped by the NP hardware. The Traffic Manager manages bandwidth policing for trusted and untrusted traffic, as described earlier. Malicious traffic is detected in the host processor and the offending device is dynamically added to denied list, which enables early discard by the NP. Devices become trusted based on behavior detected by the Signaling Processor, and dynamically added to the trusted list. This process enables the proper classification by the NP hardware. All other traffic is untrusted (unknown).
E-SBC Access Control
You an create static trusted/untrusted/deny lists with source IP addresses or IP address prefixes, UDP/TDP port number or ranges, and based on the appropriate signaling protocols. Furthermore, the Oracle® Enterprise Session Border Controller can dynamically promote and demote device flows based on the behavior, and thus dynamically creates trusted, untrusted, and denied list entries.
Access Control for Hosts
ACLs are supported for all VoIP signaling protocols on the Oracle® Enterprise Session Border Controller: SIP and H.323. The Oracle® Enterprise Session Border Controller loads ACLs so they are applied when signaling ports are loaded. The following rules apply to static NAT entries based on your configuration:
- If there are no ACLs applied to a realm that have the same configured trust level as that realm, the Oracle® Enterprise Session Border Controller adds a default NAT entry using the realm parameters.
- If you configure a realm with none as its trust level and you have configured ACLs, the Oracle® Enterprise Session Border Controller only applies the ACLs.
- If you set a trust level for the ACL that is lower than the one you set for the realm, the Oracle® Enterprise Session Border Controller will not add a separate NAT entry for the ACL.
ACLs provide access control based on destination addresses when you configure destination addresses as a way to filter traffic. You can set up a list of access control exceptions based on the source or the destination of the traffic.
For dynamic ACLs based on the promotion and demotion of endpoints, the rules of the matching ACL are applied.
Media Access Control
The media access control consists of media path protection and pinholes through the firewall. Only RTP and RTCP packets from ports dynamically negotiated through signaling (SIP and H.323) are allowed, which reduces the chance of RTP hijacking. Media access depends on both the destination and source RTP/RTCP UDP port numbers being correct, for both sides of the call.
Host Path Traffic Management
The host path traffic management consists of the dual host paths discussed earlier:
- Trusted path is for traffic classified by the system as trusted. You can initially define trusted traffic by ACLs, as well as by dynamically promoting it through successful SIP registration, or a successful call establishment. You can configure specific policing parameters per ACL, as well as define default policing values for dynamically-classified flows. Traffic for each trusted device flow is limited from exceeding the configured values in hardware. Even an attack from a trusted, or spoofed trusted, device cannot impact the system.
- Untrusted path is the default for all unknown traffic that has not been statically provisioned otherwise. For example, traffic from unregistered endpoints. Pre-configured bandwidth policing for all hosts in the untrusted path occurs on a per-queue and aggregate basis.
Traffic Promotion
Traffic is promoted from untrusted to trusted list when the following occurs:
- successful SIP registration for SIP endpoints
- successful session establishment for SIP calls
Malicious Source Blocking
Malicious source blocking consists of monitoring the following metrics for each source:
- SIP transaction rate (messages per second)
- SIP call rate (call attempts per second)
- Nonconformance/invalid signaling packet rate
Device flows that exceed the configured invalid signaling threshold, or the configured valid signaling threshold, within the configured time period are demoted, either from trusted to untrusted, or from untrusted to denied classification.
Blocking Actions
Blocking actions include the following:
- Dynamic deny entry added, which can be viewed through the ACLI.
- SNMP trap generated, identifying the malicious source
Dynamically added deny entries expire and are promoted back to untrusted after a configured default deny period time. You can also manually clear a dynamically added entry from the denied list using the ACLI.
Protecting Against Session Agent Overloads
You can prevent session agent overloads with registrations by specifying the registrations per second that can be sent to a session agent.
ARP Flood Protection Enhancements
Enhancements have been made to the way the Oracle® Enterprise Session Border Controller provides ARP flood protection. In releases prior to Release C5.0, there is one queue for both ARP requests and responses, which the Oracle® Enterprise Session Border Controller polices at a non-configurable limit (eight kilobytes per second). This method of ARP protection can cause problems during an ARP flood, however. For instance, gateway heartbeats the Oracle® Enterprise Session Border Controller uses to verify (via ARP) reachability for default and secondary gateways could be throttled; the Oracle® Enterprise Session Border Controller would then deem the router or the path to it unreachable, decrement the system’s health score accordingly. Another example is when local routers send ARP requests for the Oracle® Enterprise Session Border Controller’s address are throttled in the queue; the Oracle® Enterprise Session Border Controller never receives the request and so never responds, risking service outage.
The solution implemented to resolve this issue is to divide the ARP queue in two, resulting in one ARP queue for requests and a second for responses. This way, the gateway heartbeat is protected because ARP responses can no longer be flooded from beyond the local subnet. In addition, the Oracle® Enterprise Session Border Controllers in HA nodes generate gateway heartbeats using their shared virtual MAC address for the virtual interface.
In addition, this solution implements a configurable ARP queue policing rate so that you are not committed to the eight kilobytes per second used as the default in prior releases. The previous default is not sufficient for some subnets, and higher settings resolve the issue with local routers sending ARP request to the Oracle® Enterprise Session Border Controller that never reach it or receive a response.
As a security measure, in order to mitigate the effect of the ARP table reaching its capacity, configuring the media-manager option, active-arp, is advised. Enabling this option causes all ARP entries to get refreshed every 20 minutes.
Dynamic Demotion for NAT Devices
In addition to the various ways the Oracle® Enterprise Session Border Controller already allows you to promote and demote devices to protect itself and other network elements from DoS attacks, it can now block off an entire NAT device. The Oracle® Enterprise Session Border Controller can detect when a configurable number of devices behind a NAT have been blocked off, and then shut off the entire NAT’s access.
This dynamic demotion of NAT devices can be enabled for an access control (ACL) configuration or for a realm configuration. When you enable the feature, the Oracle® Enterprise Session Border Controller tracks the number of endpoints behind a single NAT that have been labeled untrusted. It shuts off the NAT’s access when the number reaches the limit you set.
The demoted NAT device then remains on the untrusted list for the length of the time you set in the deny-period.
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® Enterprise Session Border Controller. The Oracle® Enterprise 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® Enterprise 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.