8.1. SIP Security Principles: Collect, Analyze and Police

Like any other Internet-based service VoIP servers can be target of fraud attempts, denial of service attacks and abnormal operational conditions such as registration storms after recovery of a failed router with a user population behind it. These have become common with prevalence of the SIP technology for telephony and need to be dealt with on a daily-basis. A key function of the SBC is to fend off such situations so that the infrastructure behind the SBC and service for the end-users remains unaffected.

Administering any service securely always consists of three steps: collect data, analyze it and police. Each of these steps is a necessity and always requires human judgement of an administrator. This can be challenging with the sheer amount of data to be handled and may resemble looking for the proverbial needle in the haystack. Every day a public SIP service for one thousand subscribers generates as much as 7 GB in 13 millions SIP packets! Obviously making an administrator look at every single SIP packet is not feasible and the ABC SBC frafos solution comes therefore with many administrative aids.

The first two steps, gathering data and analyzing it, can be pursused using various tools. frafos however strongly recommends use of its ABC Monitor (see Section ABC Monitor (Optional)) because it has a unique access to internals of the ABC SBC and can report on many specifics not seen outside of it. The data gathered by the ABC Monitor known as events come from inside the ABC SBC and can therefore reveal information not visible to anyone else: plain-text signaling and media which is encrypted to the outside (always the case with WebRTC), internal information such as reasons why a specific SIP request has been dropped, or correlation of dialogs that are obfuscated to the outside using Topology Hiding.

The following real-world example shows a typical attack on a SIP service. The Figure Screenshot of a monitored password-guessing attack shows the course of the attack and defense against it. The attack started on March 22, 2016 at 1AM local time from an IP address located in Guangzhou, China. It consisted of attempts to register as users with numbers beginning with “122”. The site was initially not taking any effort to fend the attack off, resulting in 1000 authentication attempts per hour. While the attacker didn’t succeed in registering a URI protected using well-chosen passwords in this case, endurance or a weak password could have crowned his undertaking with success. Therefore at about 10:30 local time, the administrator took an action and locked out the attacker’s IP address. It took exactly one hour until the perpetrator realized his tool was receiving no responses back and started sending from a different IP address. Now the SIP service admistrator found out that a static policy is not good enough and enabled a dynamic policy that locks an IP address if too many failed authentication attempts come from it. The effect came instantly: the attacks were locked at transport layer and began to appear only shortly in hourly interval: that’s the period after which the attacker changed his source IP address – few attempts were then observed in the ABC Monitor until the new source IP address was banned again.


Figure 1: Screenshot of a monitored password-guessing attack

This example is re-iterating the importance of the fundamental security principle: collect, analyze and police. If the site administrator didn’t have good data about what’s going on, he would be literally blind and the authentication attack could have remained unnoticed. All in all, two requests per second is not an excessive amount of traffic on a multi-thousand user-site, and the way the SIP protocol is designed almost every SIP request causes a 401/407 authentication challenge. Which leads to the second, analytical point. Usage data needs to be analyzed efficiently. The administrator needs to find out if there is anything going on at all, what are the specific patterns of an attack that can be used to fend it off, and who is the originator. The last step, fending the attack off, is the easiest once the nature of an attack is known.

These three facets of the security life-cycle are documented in the following sections. We will discuss them in the order a SIP packet encounters on its way. The first thing that happens to a freshly arrived SIP packet is it is processed by a ruleset that represent a site’s security policy. We describe the available rules and practices for using them in the Section Police: Devising Security Rules in the ABC SBC.

Analyzing the security-related events using the optional ABC Monitor is discussed in the Chapter Analyze: Finding Patterns in Events using the ABC Monitor.

8.2. Police: Devising Security Rules in the ABC SBC

There is nothing more dangerous than security. Sir Francis Walsingham, Queen Elizabeth’s Principal Secretary

The objective of the policing functionality is simple to state: Filter unwanted traffic as soon as possible before it causes harm. In order to achieve this objective, reasonable policies must be administered which permit legitimate and drop harmful traffic.

The delicate challenge is to differentiate between “friend and foe”. Resolving this dilemma often requires a learning period – the administrator or an automated system on his behalf need to find out the presence of illegitimate traffic and its originator. An administrator can do this by analyzing traffic. The advantage of this approach is that human assessment of the situation can capture finesses a computer fails to see. This argument is for example the reason why air traffic control has never been fully automated – computers are still not trusted a judgement about abnormal situation.

The disadvantage of relying on humans is, not surprisingly, the human factor too. Humans may fail to see an abnormality in sheer amount of traffic and keep alert 24 hours a day. That’s what computers are good at: they can look over gigabites of traffic relentlessly, find patterns they have been taught to look after, and raise alarms any time of day as soon as they appear.

Therefore we at frafos suggest that highest level of security of a SIP service is given when automated traffic filtering is combined with computer-aided human judgment.

In the following list we show typical attack types and also ABC SBC policies to deal with these.

  • Intrusion attacks are attempts to obtain unauthorized access to a system or to a SIP user’s account. They come by nature as an uninvited surprise at the most inconvenient time. The challenge is therefore to counter them as quickly as possible. In the Section Automatic IP Address Blocking we are showing how to automate prohibition of malicious traffic even before administrators do notice.
  • Harassing traffic may be easier to detect and yet incovenient to deal with. Unlike with real attacks, the harassing traffic is mostly an unintended side-effect of a broken implementation or configuration of some SIP devices. It doesn’t try to masquerade or surprise yet if coming in large quantities, it may have the same devastating effect as a malicious attack. The capability to filter out such “noise” helps to reduce security risk, off-load the infrastructure, and focus on the traffic that matters. We show how to block well-known sources of harassing traffic at both IP and SIP layer in the section Manual SIP Traffic Blocking.
  • Unpriviledged traffic is traffic that does not appear harmful yet it has not been explicitely authorized to use a SIP service. Such may not appear harmful on the first sight, yet it may be also an initial probing prelude to an actual intrusion attack. It appears therefore a wise idea to drop traffic which does not demonstrate appropriate credibility before it turns into a harm. This way users exhibiting proper behaviour are prioritized over users that don’t. The simplest and yet most powerful credibility test is that of successfully completed SIP registrations. See Section Blocking a User by his Registration Status for guidelines how to use it. Also note that the credibility-test is extended to lower-layer by a generalized technique known as grey-listing (Section Automatic Proactive Blocking: Greylisting).
  • Excessive traffic may have many root causes: Denial of Service (DoS), breach of service-level agreements, or SIP network misconfiguration. Regardless of the cause the results are always the same: quality of service (QoS) declines for legitimate uses. To prevent such QoS impairments, a site better choses to set limits on SIP and or RTP traffic and drops traffic exceeding the limits. We show how to shape traffic in Section Traffic Limiting and Shaping. Traffic shaping is also important to discover some sort of attacks like SIP password guessing: if the attacking SIP device tries to masquarade as a legitimate user, the high signaling rate it needs for guessing will give it away.
  • Excessively long calls are another irritating phenomena that needs to be dealt with in order to reduce a high-charge risk. Most often it is caused by SIP devices that do not terminate calls properly. Fraud attempts are also known that have been trying to gain maximum by running calls as long as possible. In Section Call Duration Control we explain how to keep a SIP service robust against infinite calls.
  • Improper content in SIP signaling or SDP media can bring insufficiently robust SIP devices to failure. This situation doesn’t happen so often because SIP devices typically do not have such processing capability like general purpose computers to be a real magnet for all kinds of viruses. Yet the situation changes as Android telephones come on the market and features offered by servers expand. Academics have already described SQL injection attacks [1] [2] : They crafted SIP messages which included SQL commands, and the SIP servers passed these to backend software. When the software is not sufficiently robust, opening a webpage to see a list of completed calls will also launch a potentially dangerous SQL query. If content of SIP and SDP is considered a risk, more aggressive mediation is needed. See Sections SIP Mediation and SDP Mediation for more information how to filter SIP/SDP content. Particularly header-field whitelisting may be instrumental for this purpose.

The ABC SBC offers several instruments for filtering undesired traffic. There are two types of: filters operating at IP/transport layer for the highest performance and filters operating at SIP layer when more sophisticated filtering criteria are needed. For example a well-known flooding attacker is best eliminated by filtering out all traffic from his IP address. On the other hand, if a single SIP user behind a SIP trunk IP misbehaves, blocking the whole trunk IP would be throwing the baby out with the bathwater. In such a case, the SIP-layer filtering would be a safer choice, albeit not that fast.

The IP-layer rules are managed from the administrative menu under “System ‣ Firewall“. The screen offers a search box where one can look for an IP addres to see if it is present on any of the lists, and then several firewall rule lists. The lists are ordered by precedence: the top lists are more manual, have higher precedence and override the bottom-placed lists. The top lists include Manual low-level rules, Exceptions to automatic blacklists, and Manual Firewall Blacklists and are described in Section Manual IP-layer Blocking. The bottom lists are generated in an automated way using built-in security assessment algorithms without administrator’s intervention, can be overriden by the manual lists in the top, and are described in the Sections Automatic IP Address Blocking and Automatic Proactive Blocking: Greylisting.


Figure 2: Firewall Rules Management

SIP layer filtering is then described in Section Manual SIP Traffic Blocking. If binary yes/no policies seem too harsh, placing quota on the traffic may be a better answer, which is described in Section Traffic Limiting and Shaping.

8.2.1. Manual IP-layer Blocking

In some situations, e.g. if DOS attacks are encountered, incoming IP traffic may better be blocked already on the operating system firewall (iptables) level so that CPU processing power and memory is saved as the SBC processes don’t need to handle the traffic.

The ABC SBC offers a graphical user interface to configure the firewall rules under “System ‣ Firewall“. There are several rules list, the top-positioned rules list take precedence over the bottom rules list and are processed in the exactly same order as shown in the GUI.

If incoming packets do not match any of these rules, default rules apply. Traffic to signaling and media interfaces will be accepted if in the declared destination port range, traffic to administrative port numbers will be permitted on XMI and IMI interfaces, all other traffic will be dropped.

The top-most rules list is “Manual low-level rules” and it is a “swiss army knife” for firewall administrators. While it is the first-in-order list, we recommend to use it as the last resort due to extra complexity. Simpler rules such as “Exceptions” and “Manual blacklists” bellow are easier to manage and audit. Nevertheless the low-level rules my be still useful in situations when administrators wish to limit administrative access to well-known IP addresses or ermit additional administrative protocols. These rules allow to specify IP flows using source and destination address and port numbers, and whether these flows should be accepted or dropped. That also means that attention must be paid to the order of these rules because it does affect the result. For example, the administrator can use the low-level rules block all traffic coming from the RFC1918 private IP address space as shown in Figure Manual low-level Firewall Rules. When a filtering criteria such as IP address or port number is left blank in the rule, any value in incoming IP packet matches.


Figure 3: Manual low-level Firewall Rules

The remaining firewall rules only refer to signaling (SIP and websocket) interfaces and are simple unordered lists of IP and subnet addresses.

“Exceptions to the automatic blacklist” are second in order and could also be called “Whitelists”. They take precedences over any of the blacklists bellow. This is important to be able to override too zealous behaviour of automated blacklists. This is often the case when traffic of multiple users is coming from behind a single IP address due to NATs or a peering topology. Then the automatic blacklists triggered by a single user would block all others behing their shared IP address. Similarly a SIP site administrator may want to exempt himself from being auto-blacklisted, because his signaling tests may get him blacklisted. Consequently, he would not be even able to open an SSH session to the ABC SBC.

For example a single misbehaving URI would otherwise block an IP address and all other URIs behind it. In such a case, it makes sense to exempt this address from automated blacklisting and address the problematic URI traffic at SIP layer. Example of such a “Whitelist” is shown in Figure Exceptions to the automatic blacklist.


Figure 4: Exceptions to the automatic blacklist

The third in order before automatic rules is “Manual Firewall Blacklist” that can disable traffic from an IP address or subnet even before it reaches any kind of SIP processing logic. This may make sense when a DoS attacker is detected whose traffic is better disabled as early as possible. Example of such is shown in Figure Manual Firewall Blacklist.


Figure 5: Manual Firewall Blacklist

The next firewall lists, automatic blacklist and greylist, are populated in an automatic way by ABC SBC, and can only be flushed by administrator. The are described in the subsequent chapters Automatic IP Address Blocking and Automatic Proactive Blocking: Greylisting.

8.2.2. Automatic IP Address Blocking

The ABC SBC implements an automated protection process for SIP-layer close-to-real-time detection and IP-layer elimination of offending SIP traffic. This combination provides application-aware assessment with lower-layer performance and helps to eliminate offending traffic without manual administrator intervention. This level of automation cuts the detection-reaction time to almost real-time reactiveness.

A picture tells more than thousand words: The Figure Number of Events with and without Automatic IP Address Blocking shows the profound effect of automated blocking. The event timeline begins under protection of automated blocking in a calm way with about fifty events a minute. When at 23:30 the administrator turns off the automatic protection, the offending traffic finds its way and builds up rapidly. One hour later, 2500 events are already reported every single minute, most of them failed authentication. This unfavorable status remains until the protection is re-enabled. Then, it takes less than five minutes until order is restored again.


Figure 6: Number of Events with and without Automatic IP Address Blocking

Intrusion attacks, by their very definition and purpose, come uninvited. Sometimes they may try to masquerade themselves in a way that the offending traffic looks innocent: Low-pace, using names of legitimate SIP device types. A human reaction may be too slow to identify such an attack. Therefore the automated process comes in: It acts before a human adminstrator could.

The ABC SBC protection process is based on the following empirical observations: Offending traffic comes in abnormal quantities, which are indicated by repetative failures, these failures are linked to an IP address, and the IP address can be blocked. In other words, when some of the security-related events (see Section Security Events) come repeatedly from the same source, it is as good as certain we are dealing with an attack and need to isolate that.

Linking repetitive failures with an offending source is a quite reliable assumption. Singular failures do occur, for example if a softphone user types in a wrong SIP password an authentication failure event is reported. Yet if the same event is repeated many times, the more likely explanation is we have encountered a password-cracking attack. Leaving such an attack unattended creates a ticket for troubles. At the pace of 2800 authentication attempts per minute (45 per second) shown in our example, an attacker could crack a trivial password taken from Oxford Advanced Learner’s Dictionary (185,000 entries) in less than 70 minutes!

Similarly, when a source continues to exceed traffic limits we are dealing with a Denial of Service attack, and when the ABC SBC is receiving repeatedly 403s from a downstream SIP service we know we are dealing with a scanning attack in which an attacker is trying to find a gap in a dial-out authorization policy.

In such a situation banning the originating source address at the OS layer is the safest way to keep the attack from the infrastructure. Care needs to be applied if in the network topology mutliple users exist behind a single IP address: then legitimate users could be banned as well as the actual offender. This could be for example the case with peering traffic from behind a SIP proxy, or multiple users behind a single NAT.

The immediate effect of automated IP Address Blocking can be seen in Figure Number of Events with and without Automatic IP Address Blocking: At the very moment when it is enabled, the storm of authentication attempts calms down. It continues to appear briefly when either the attacker changes his IP address or the maximum “banning time” expires – then the detection mechanism strikes in again and the attacks vanish.

This effect is achieved by ABC SBC monitoring various occurences that add to a “score” of a potential offender. To be banned, traffic of an offender must induce several serious events within a pre-configured period of time. Once the score is high enough to identify the originating IP address as “serial offender”, the address is put on a blocking list and stays there for a pre-configured time. The events that add to the score are all events documented in the Section Security Events: limit for exessive traffic, message-dropped for messages that the administrator chose to drop using the drop action, auth-failed for failed authentication attempts and log-reply for transactions which were declined by a downstream SIP entity. Also significant errors to pass SIP compliance sanity checks add to this score.

Once a source IP address is detected as a repeating offender, all of its traffic will be silently dropped. The list of all currently banned IP addresses can be found in the menu under “System ‣ Firewall ‣ Auto FW blacklist ‣ Full List “ together with the remaining time they are supposed to spend on the list.


Figure 7: SBC GUI Screenshot: Automated Firewall Blacklist

Automated blacklisting is by default turned off. To enable it perform the following steps:

  • Turn it on. Under “Config ‣ Global Config ‣ Firewall“ turn on “Blacklist IP addr for repeated signaling failures“. This will enable the automated blocking process that will process the “score” for IP addresses.
  • Fine-tune it if necessary.
    • The options “Signaling failures blacklist: IP address start score before any offense“ (recommended value: 2.8) and “Signaling failures blacklist: rate per second used to calculate a time-related bonus between offenses“ (recommended value: 0.0001) in the same global configuration section allow to specify a threshold. When exceeded, the offending IP address will be blacklisted. The first parameter specifies an initial “allowance” that helps to overcome initial problems like forgotten password. The other parameter sets an error rate which can be tolerated over time.
    • The option “Signaling failures blacklist: time in seconds to remove entries for which no event has occured from score calculation:“ states how long an IP address continues to be suspected after it produced its first security events. Recommended value is 7200.
    • The option “Time in seconds to blacklist IP addr for signaling failures:“ determines how long an offending IP address stays on a blacklist. Recommended value is 3600.
  • Define what occurences add to the blacklisting score:
    • To include authentication failures and SIP protocol sanity checks, enable the options Sanity and Auth under “Realms ‣ Call Agents ‣ Edit ‣ Firewall Blacklisting“. If this CA option is not set, the traffic coming from IP addresses within this CA will not be blacklisted.
    • Additionally scripting actions used for constraining undesired traffic may be set up to add to the blacklisting score. To enable the “drop” action to add to the score, check its “Blacklist by firewall if repeated” option as shown in the Figure The Drop Rule Options. To count originators of requests that were rejected by a downstream server, use the action Log message for replies, include message codes you are concerned about and turn on the option Log to firewall blacklist. The Figure Scoring Rejected Requests shows an example of such a rule intended to decline scanning attacks trying out calls to various telephone numbers. The guesses frequently fail and cause the replies with code 604. If this happens, the action log message for replies increases the blacklisting score.

Figure 8: The Drop Rule Options


Figure 9: Scoring Rejected Requests

Note again that blacklisting can impair legitimate users who share the same IP addres with an offending user. This is often the case with NATs or a trunk Call Agent represented by a single IP address and a single user that is misbehaving. In such a case, it may make sense to turn off auto-blacklisting for such a Call Agent, and deal with the misbehaving URI using SIP-layer filtering as shown in Section Manual SIP Traffic Blocking.

8.2.3. Automatic Proactive Blocking: Greylisting

Sometimes an automated blacklisting policy may be too reactive in that it begins to block traffic sources only when they have been already “caught” misbehaving. An alternative automated and sterner policy, greylisting, may be used instead to block suspicious traffic coming from an interface preemptively.

The basic idea is very simple: Permit signaling traffic from unknown sources for only a temporary “probation period”, accept it if some legitimity critera is established within this period and block (greylist) it otherwise. In this case, all packets coming from the IP address will be blocked at OS layer for maximum performance. This concept is stronger than blacklisting in that it doesn’t wait until a misbehaviour is spotted. An attacker trying to remain “under the radar” will not be tolerated any more. A single useless probing packet from his IP address to an ABC SBC singaling port will get him greylisted.

To enable grey-listing, you need to establish what makes legitimate traffic. An often used criteria is completion of authenticated SIP registration. To set up greylisting, proceed with the following steps:

  • Turn greylisting on for an interface. Go to System ‣ Interfaces ‣ Edit ‣ Greylist. At this moment signaling coming over this interface from an IP address will be dropped if the criteria does not establish its legitimacy within a strict time window.
  • Define the legitimacy criteria. This is achieved using the actions Log to grey list and Log message for replies. The former immeditaly accepts a request source IP address. The latter does so later only when an answer with required status code comes back and can do so for UAC, UAS or both.
  • Fine-tune greylisting global parameters if needed:
    • time delay in seconds to give IP a chance to prove validity,
    • time period in seconds when IP can be blacklisted if repeats and did not prove validity,
    • time in seconds to keep IP on blacklist,
    • time in seconds to keep IP on whitelist,
    • additional ports or port ranges (a:b) to check in addition to signaling ports, space separated.

Source IP addresses of cached registration bindings are implicitely accepted after receiving a successful response from the downstream registrar. This helps with a single administrative domain: an authenticated registration is quite a credible proof of sender’s legitimacy.

However in scenarios with peering domains and other scenarios where SIP devices do not register, legitimacy of the senders must be established using some explicit criteria. To asses such a non-registering SIP sender, administrator must choose SIP transactions that demonstrate the sender is not an offender. This requires knowledge of a site’s policy. For example, accepting an IP address based on an arbitrary 200-completed SIP transaction may be too relaxed, as any sender of a SIP OPTIONs “PING” packet that is “PONGed” would then qualify. Insisting on 200-completed INVITEs may be too harsh on the other hand, as a cancelled call attempt would result in graylisting the caller. Therefore the acceptance policy must be chosen with knowledge of what SIP transactions shall or shall not be accepted by the downstream SIP elements.

The qualifying SIP transactions are tagged using the “Log to grey list” and if dependent on the resulting transaction status the “Log Message for Replies” actions. When a transaction is processed using either action, and completes with a matching response code, then IP address of the SIP UAC, UAS or both will be accepted and will not be greylisted.

An example of such an A-rule is shown in Figure Greylisting Rule Example: Accept 200 REGISTERs and selected non-REGISTER codes. It accepts IP addresses from which REGISTERs come that complete with the 200 status code, and any other SIP requests that complete using some of the specified status codes. In all other cases, the IP address sending a packet to the ABC SBC will be blacklisted. That includes the cases when it is a non-SIP packet that doesn’t even make it to rule processing, a REGISTER which doesn’t result in a 200, and for example an INVITE which completes with the 604 code.


Figure 10: Greylisting Rule Example: Accept 200 REGISTERs and selected non-REGISTER codes

If we wanted to craft a more relaxed policy which does not inspect SIP answers coming back, we could use the action Log to Grey List instead (Figure Rule Example: Accepting an INVITE Sender’s IP Address). It accepts all IP addresses from which an INVITE comes. Its actual impact depends on where in the rules this action is placed. If it was in beginning of the rules, it would only block offenders sending non-SIP or non-INVITE packets to the signaling ports. Therefore it is typically placed after several rules that drop undesirable traffic, such as request from well-known scanners or unsolicited OPTIONs.


Figure 11: Rule Example: Accepting an INVITE Sender’s IP Address

We also have to care about outbound SIP requests. Answer packets coming back trigger the greylisting process and we need to have an acceptance policy as well. Typically it is quite simple under the assumptions that requests sent to outside express consensus to communicate with the outside IP address. Therefore installing a rule in C-rules to accept the destination address regardless of the response coming back will form a reasonable policy. Such a rule is shown in Figure Rule Example: Permit UAS’s IP Address for Any Replies. A destination appears on the greylist only if it sends no answer.


Figure 12: Rule Example: Permit UAS’s IP Address for Any Replies

Note that like with blacklisting, greylisting may have side-effects when there are multiple users behind a single IP address. A legitimate user who proves himself and promotes his IP address by the greylisting procedures makes traffic of other users behind the same IP also legitimate.

Blacklisting and greylisting may be used at the same time. In this case the side-effects of blacklisting will prevail as blacklisting goes first in the processing order. Then even if an IP address is accepted by the greylisting criteria, and a misbehaving user will cause the IP address to be blacklisted, all traffic from the IP address will be blocked.

It is also important to know that ABC SBC resets greylists upon every restart and starts re-learing them. This makes re-configuration and/or rapid failovers more robust against grey-listing innocent IP addresses. Otherwise a change of greylisting policies could fail to accept an IP address that has been already spotted under a previous policy. Similarly, a fail-over back and forth may also result in greylisting a legitimate IP address.

Checking the actual status of an IP address can be done on the administrative page “System ‣ Firewall ‣ Search IP“, from where one can also retrieve the full current blacklist and greylist.


Figure 13: Screenshot: Firewall Search IP Box Results

8.2.4. Manual SIP Traffic Blocking

The manual blocking is used to block well-known offending traffic using SIP-layer criteria. The SIP-layer blocking allows to establish SIP-layer filtering criteria, and it also allows to indicate to the upstream SIP client why a request is being denied using a SIP response code.

The reasons for using this type of blocking can be multifold: declining traffic from unsupported call agent types, refusing to process some unsupported applications like SIP for presence, or banning traffic from SIP users that have become unwelcome and cannot be delt with using IP-layer blacklisting because they share IP address with other legitimate users.

A call can be refused silenty or using a SIP reponse using either of the following methods:

  • Reply to request with reason and code. This action declines a SIP request using response code and phrase. Optionally a header field may be attached to the response. Replacement expressions can be used in the response phrase and header field. Multiple header fields can be introduced by putting \r\n between them. An event of type “call-attempt” is generated for declined INVITEs.
  • Drop request. This action drops a request silently and generates an event of type “message-dropped”. Events can be grouped by a key in which case the events repeat within short interval of time (ten seconds) if their keys differ. If there is no key, the event does not repeat until offending messages stop to arrive for ten seconds.

If either action is executed, rule processing stops immediately and no further rules are processed. Neither do the requests count towards limits (see Section Traffic Limiting and Shaping) if the limits are placed behind the reply/drop actions.

The remaining question is how to discrimante between trusted and untrusted traffic. The ABC SBC can use any of its rule conditions described in Section Condition Types. The most often used conditions include:

The following subsections documents the cases that are commonly used to filter out unwanted traffic based on different message elements. In the simple case, the tested elements are checked against fixed values like in the Figure The Drop Rule Options where the SIP requests are dropped if their Header Field User-Agent contains “scanner” or “sipcli”. If the list of values to check against is longer, devising many rules may become cumbersome, use of provisioned tables is recommended as shown in the Section Provisioned Table Example: URI Blacklist. Blocking by User-Agent, From and Other SIP Headers Fields

SIP request elements include many header fields upon which an administrator may make an accept/reject decision. For example, a SIP user may be found problematic and blocking his IP address is impossible because there are other legitimate SIP users behind the same IP address. In such a case it makes perfect sense to block all SIP requests with an offending address in the SIP From header field. Alternatively a whole domain can be blocked the same way. Conditions for this, From URI and From Domain, are available in ABC SBC rules, others are described in the Section Condition Types.

Not all header field names are available in the SBC rule conditions, and some may be even custom-made. Therefore there is also the possibility to refer to a header field by header name. That can be particularly useful when checking for some well known User Agent types that show their signature in the User-Agent SIP header field. Cases have been reported when this type of filtering has been used to block traffic from SIP devices with new untested firmware causing registration storms. Other common case is blocking well-known SIP scanners, one of such being known as “friendly-scanner”. Their packets look like this:

OPTIONS sip:100@ SIP/2.0.
Via: SIP/2.0/UDP;branch=z9hG4bK-3414626242;rport.
Content-Length: 0.
From: "sipvicious"<sip:100@>;tag=64343466366639623133633401333731383339333235.
Accept: application/sdp.
User-Agent: friendly-scanner.
To: "sipvicious"<sip:100@>.
Contact: sip:100@
Call-ID: 383887304209490351968881.
Max-Forwards: 70.

A rule to detect, drop and record such requests from inbound (A) rules is shown in Fig. Inbound rule for refusing calls from a certain user agent.


Figure 14: Inbound rule for refusing calls from a certain user agent

If the number of blocked elements become too long to have a separate rule for each of them, one can also utilize the provisioned tables as shown in the Section Provisioned Table Example: URI Blacklist. Blocking by IP Address

It is possible to block a single IP address or multiple IP addresses matching a text pattern with actions configured with Source IP condition in the inbound (A) rule see Fig. Inbound rule for refusing calls from a certain IP address.


Figure 15: Inbound rule for refusing calls from a certain IP address Blocking by IP Address Range

The simplest way to block a range of IP addresses is to create a Call Agent for such an IP address range, see Fig. Definition of a Banned Call Agent, and create an inbound (A) rule for this call agent without conditions that will refuse all messages from it see Fig. Rules for a Banned Call Agent,


Figure 16: Definition of a Banned Call Agent


Figure 17: Rules for a Banned Call Agent

Additionally this rule example uses the “Log Event” action to alert administrator of traffic violating his policy. (see Section Diagnostics Events for more details about using diagnostic events) Blocking a User by his Registration Status

Inbound (A) rules offer a possibility to enforce an administrative policy by blocking the request (usually an INVITE) if its initiator is or is not registered by using condition Register Cache. It also can be used as some form or caller prioritisation if used together with CAPS limit. The test against the register cache is made using one of the following keys:

  • From URI (AoR+Contact+IP/port)
  • From URI (AoR+IP/port)
  • Contact URI (Contact+IP/port)
  • To URI (AoR)
  • R-URI (Alias)

Such requests can be refused with Refuse call with reason and code action, see Fig. Inbound rule for refusing calls based on registration status.


Figure 18: Inbound rule for refusing calls based on registration status Blocking by Geographic Origin

The ABC SBC can also block or otherwise discriminate incoming requests based on the country code of the region from which they are coming. The region is determined using a Geo-IP database from request’s source IP address. The example here generates custom events when a request comes from France.


Figure 19: Inbound rule for Reporting on French Request Originators

8.2.5. Traffic Limiting and Shaping

Like any other Internet-based service VoIP servers can be the target of denial of service attacks. By generating a flood of SIP requests a malicious attacker can overload the VoIP infrastructure. Such overload conditions can negatively impair established calls and calls in progress and need to be controlled. Similarly, authorized users of a SIP service can access the service in a way that reaches abusive dimension and needs to be controlled as well. For example, a provider offering a flat-rate service to consumers may find that whole PBXs are connected to the SIP accounts. This would result in losses since the pricing calulation anticipated different usage calculation. Therefore traffic control is also needed in such a situation.

The ABC SBC offers several forms of controlling SIP and RTP traffic which are described in this Section. These are implemented as rules which can be placed in A or C rule-basis. If used in inbound A-rules, the limitations refer to traffic coming from a Call Agent or Realm. If used in outbound C-rules, the limitations refer to traffic sent to a Call Agent or Realm. In either case the limitations only affect calls that passed the limitation action. Reversely, calls that have not been processed using a limit action are not subject to such a limit. To make sure that all calls within a realm or call-agent are subject to a limit, the action must be placed in beginning of the rules without any condition.

More often, the call limits need to be related to a subset of traffic. For example only one parallel call may be permitted per IP address. The criteria can vary depending on use-case and therefore the limiting actions have an optional variable key parameter. The key specifies which traffic portion the limit applies to, and can use replacement expressions (see Section Using Replacements in Rules). All messages (and no other) that have the same key count torwards the limit. Two often used keys are source address and combination of source address with From URI. The former (denoted as “$si”) checks all traffic coming from any single IP address against the respective limit. The combination of source address with AoR (denoted as “$si$fu“) allows that requests with distinct From URIs count against their own limits even from behind a single IP address – particularly useful when the IP address belongs to a PBX which serves numerous SIP addresses.

When the  “Is global key”  option is kept unchecked, the indexing key is scoped to the entity the rule belongs to (Realm or Call Agent). This means that the real key used to index the corresponding measurement is a compound of the indexing key and the entity. If, however, the key is declared to be global (by checking the  “Is global key”  option), the index is solely determined by the key entered in the “Key attribute“ field. This means that if the same indexing key is used in another rule block (for example for another Realm or Call Agent), the limit will be applied jointly for calls on which this other rule block applies.

The traffic limiting actions also generate events when traffic does violate the limits – see Section Security Events. This is important for administrators to be able to notice such conditions and consider how to deal with such violations further: Whether to recognize these as illegitimate and continue blocking the orginators, or to lift the limits if they find the above-limit usage has a legitimate reason. Only one event is produced for a detected excess of traffic limit, regardless of its duration. However, if the excess calms down and emerges again after ten seconds, a new event will be generated.

To make sure that an administrator can be alarmed even before a limit hits and starts to drop traffic, some of the traffic limit actions have the “soft-limit” option that creates diagnostic alarms but does not drop any traffic. Also, in the case that the traffic violates the “hard” limit repeatedly, the option “Report abuse” allows to block the offending traffic source – see Section Automatic IP Address Blocking for additional information.

The following call limit actions are available for use in A- and C-rules:

  • Limit parallel calls - Set limit for number of parallel calls. New calls arriving in excess of this limit will be declined using the 403 SIP response. To make it easier to find the cause, the response includes a Warning header field with an additional hint: Warning: Caps limit reached. For example, to limit the number of parallel calls from the ABC SBC to a Realm or Call Agent, add a Limit parallel calls action to its outbound rules. Incomplete call attempt in progress whose context resides in memory also count temporarily towards the limit together with established call. That’s an important security aspects: it makes sure new calls in progress are declined and cannot establish calls later that would exceed the limit. To limit the number of parallel calls from a Realm to the FRAFOS ABC SBC, add a Limit parallel calls action to the Realm’s inbound rules. The action includes the following parameters:

    • Limit parallel calls – the actual number of parallel calls permitted.
    • Key Attribute and Is Global Key optionally define which partition of traffic counts towards the limit.
    • SIP response code and SIP response reason specify what type of reply is sent in response to a request that violated the limit. Optionally, header fields such as Warning may be added to the response using the SIP Header option. This option is intended to provide upstream client and troubleshooters with additional information explaining why a request is
    • Soft-limit value allows to specify the “soft” threshold which if exceeded will generate a diagnostic event.
    • Report abuse checbox makes occurence of a traffic limit violation count against automated IP address blocking score.
    • SIP response code and SIP response reason specify what type of reply is sent in response to a request that violated the limit. Optionally, header fields such as Warning may be added to the response using the SIP Header option. This option is intended to provide upstream client and troubleshooters with additional information explaining why a request is
  • Limit CAPS - Set limit for SIP request rate. If the request rate exceeds this limit, new call attempts will be declined using a 403 SIP response. Note that when a request is authenticated using SIP digest, it results in two transactions, both of which count towards the CAPS limit. New dialog-initiating (e.g. SUBSCRIBE) and out-of-dialog (e.g. unsolicited NOTIFY) requests also count against the CAPS limit and will be dropped if they exceed it. SIP requests belonging to a dialog that has previously passed the limit test will all be accepted. Retransmissions do not count towards the SIP limit. The action includes the following parameters:

    • Limit CAPS – the number of permitted SIP requests per unit of time. These two values define the permitted signaling rate.
    • Time Unit – lenght of time unit in second. Even if the number of permitted requests grows proportionally with lenght of time unit and yields the same signaling rate limit, longer time units are more permittive as they can accomodate more intense bursts.
    • Key Attribute and Is Global Key optionally define which partition of traffic counts towards the limit.
    • SIP response code and SIP response reason specify what type of reply is sent in response to a request that violated the limit. Optionally, header fields such as Warning may be added to the response using the SIP Header option. This option is intended to provide upstream client and troubleshooters with additional information explaining why a request is being dropped.
    • Soft-limit value allows to specify the “soft” threshold which if exceeded will generate a diagnostic event.
    • Report abuse checbox makes occurence of a traffic limit violation count against automated IP address blocking score.
  • Limit Bandwidth (kbps) - Set bandwidth admission limit for codecs. If current total sum of maximum bandwith as signaled in SDP exceeds this limit, the signaling request will be rejected using a 403. For example, the limit of 30 kbps will reject any incoming INVITE that, among others, offers G.711 codec (64 kbps) in its SDP using a SIP 403 response. This type of limit only serves as initial admission control and does not guard the actual RTP usage. A sender is not hindered to send more RTP traffic than advertised in SDP unless the Limit Bandwidth per Call action is applied.

    The action includes the following parameters:

    • Limit Bandwidth (kbps) – maximum permitted bandwidth

    • Key Attribute and Is Global Key optionally define which

      partition of traffic counts towards the limit.

    • SIP response code and SIP response reason specify what type of reply is sent in response to a request that violated the limit. Optionally, header fields such as Warning may be added to the response using the SIP Header option. This option is intended to provide upstream client and troubleshooters with additional information explaining why a request is being dropped.

    • Soft-limit value allows to specify the “soft” threshold which if exceeded will generate a diagnostic event.

    • Report abuse checkbox makes occurence of a traffic limit violation count against automated IP address blocking score.

  • Limit Bandwidth per Call (kbps) - Set limit for RTP traffic per call. This action observes all RTP streams, video and audio, of a call, and if the actual traffic rate exceeds the limit, the RTP packets will be dropped. RTCP traffic is not counted against the bandwidth limit and this bandwidth limit is only effective if RTP anchoring is enabled for the call. This action has the only parameter, the threshold value in kbps.

Note that limits are only applied to SIP requests that encounter the respective limit rule. That means that a newly introduced limit does not affect established calls. It also means that if call processing is stopped due to declining or dropping the call before the limit rule is evaluated, the declined call attempt doesn’t towards the limit. Example of such rules where calls are declined before counted against a CAPS limit is shown in Figure Order of Rules Matters: Dropped Calls Don’t Count Towards Limits.


Figure 20: Order of Rules Matters: Dropped Calls Don’t Count Towards Limits

The most delicate part when setting the limits is finding the appropriate threshold values. Definition of appropriate values depends on what type of SIP User Agents are being used and how. Specific aspects causing higher traffic rates need to be considered to make sure that legitimate traffic will not be discarded:

  • soft-clients often support SIP for presence (RFC3856). The amount of traffic, especially when such a client starts, can be high and grow with the length of the buddy list.
  • Registration throttling (Section Registrar off-load) is often used to keep NAT bindings alive. The limit rate needs to be adjusted to the throttling rate.
  • PBXs and Integrated Access Devices and most importantly trunking peers send traffic for many users from a single IP address. Traffic Limiting and Shaping by Example

In the following example we implement a policy to shape incoming traffic for a public SIP service for personal use. The example is intended to be rather liberal and sets the threshold relatively high for the anticipated use to make sure it doesn’t break some traffic-intensive use-cases.

We start policing VoIP calls in the first rule. To make sure that even a nervous caller attempting to reach a busy destination doesn’t exceed his limits, we permit 10 requests every 30 seconds for every source IP address (the “$i” in the key parameter). Note that the actual number of call attempts may be lower by one half, since SIP authentication attempts preceeding the actuall call attempts count towards the limit as well and double the number of requests.

The next rule throttles registrations. We know that several popular consumer Integrated Access Devices (IADs) offer several SIP accounts. We want to make sure that the devices don’t get locked out when they boot and send REGISTERs for all of their SIP accounts. We also need to account for the authenticating transactions. Therefore we set the limit to 10 requests every thirty seconds and key the limit by combination of IP address and From URI. That means that the limit can only be exceeded by requests coming from the same IP address and bearing the same From URI. In other words, even if many REGISTERs come from behind a single IP address the limit will only be hit if they use the same URI. If the URI is registered from an IP address at a rate beyond the limit, parallel registrations of the same URI from behind a different IP address will not count towards the same limit.

Further we impose a general limit on all SIP transaction types. Especially soft-phones are known to send a lot of “noise”: SIP PUBLISHes, SUBCRIBEs, NOTIFYs, OPTIONS and other request types. We permit 28 requests every three seconds from every single IP address.

Last but not least: we limit the number of parallel calls to 5 per IP address.


Figure 21: Limit on number of Call Attempts per Second Bandwidth limits by example

The ABC SBC can limit the bandwidth admited for a calls’ media streams. The action  Limit Bandwidth (kbps)  has as a parameter the bandwidth in kilobits per second to which the call should be limited, see Fig. Example of Shaping Rules. Attempts to set up calls exceeding this bandwidth will be rejected using a 403 response.


Figure 22: Example of Shaping Rules

8.2.6. Call Duration Control

By limiting the maximum duration of calls one can on the one hand prevent “bill shocks” when some customer fails to terminate a call in a proper manner. Additionally, attackers might try to deplete the resources of the SBC by generating calls with long durations causing a saturation of the call processing capacity of the SBC. Setting Call Length Limits

The Set call timer action sets the maximum duration of the call, in seconds. If a call exceeds this limit, the ABC SBC sends a BYE to both call participants and generates an event of the call-end type.


Figure 23: Set call length

If this action is executed several times, the call duration will be the lowest call timer set, regardless of the order in which the actions are executed. Controlling SIP Session Timers (SST)

SIP Session Timers (SST) is a mechanism defined in RFC 4028 that can be used to make sure that calls are ended after a a period of time even if one endpoint disappeared without properly terminating the call. This is especially important if calls are billed using data derived from the signalling messages, but also makes sure that unused resources are released properly. In order to achieve this, periodically a refresh of the SIP dialog is done by using a re-INVITE or an UPDATE. If the refresh request fails, e.g. if it times out, per the standard SIP mechanisms the dialog is torn down and related resources are released.

SIP Session Timers is a mechanism to negotiate which of the endpoints in the SIP dialog does this refresh. After the negotiation that happen with some specific headers (Session-Expires/x,Min-SE) in the INVITE or UPDATE and the responses to it, it is clear who has the refresher role.

The ABC SBC supports SIP Session Timers even if one or both endpoints do not have support for Session Timers. In order to minimise re-INVITES/UPDATEs sent from the middle into both call legs, and rather have the endpoints send the refresh messages, the ABC SBC tries to negotiate away the refresher role, so that the end points take on the refresher role.

There are separate actions for enabling SST on the caller and the callee leg

  • Enable SIP Session Timers (SST) - caller leg
  • Enable SIP Session Timers (SST) - callee leg

The SST mechanism also negotiates the time after which the refresh is done. The timer parameters - proposed Session Expiration and Minimum Expiration, in seconds - can be set individually for each leg. Setting RTP Inactivity Timer and Keepalive Timer

These two timers help to detect situations in which due to some network failure a phone call has already stopped. It requires media anchoring to be enabled.

It often occurs that a call party becomes suddenly unavailable and a call remains “hanging”. This may happen for example due to a software error in a softclient or a disconnected IP network. To make sure such a call doesn’t continue, an RTP inactivity timer may be configured. If configured and either party stops sending RTP, a call is discontinued by the ABC SBC after the preconfigured period of inactivity. Eventually an event of type “call-end” is reported with originator field set to “rtp-timer-terminated”.

The timer can be configured under “Config ‣ Global Config ‣ SEMS ‣ RTP timeout”. If set to zero, the timer is deactivated.

To make sure that a peering SIP device using a similar kind of timer doesn’t disconnect a call which just occurs to produce no media (voice inactivity detection, on-hold), the ABC SBC may also be configured to generate RTP keep-alive packets. If set to a non-zero value (in seconds), the ABC SBC sends keep-alive RTP packets periodically.

This timer can be configured under “Config ‣ Global Config ‣ SEMS ‣ RTP keep-alive frequency”.

Both timers can be also set on a call-by-call basis under parameters of media anchoring (see Section Media Anchoring (RTP Relay)).

8.3. Collect Events: Gathering Usage Data in the ABC Monitor

Knowledge is never too dear. Sir Francis Walsingham, Queen Elizabeth’s Principal Secretary

An administrator can only craft reasonable security policies if he knows what is actually going on. He must have access to detailed history of SIP user behaviour, security incidents and unusual activites. This is indeed the purpose of “events” as introduced in Section Events (optional). Events are detailed reports on user activity that encompass registration, call attempts, and security incidents.

Many individual events can identify need for administrator’s attention. For example if a packet is dropped because it is coming from a SIP scanning software, an administrator may want to act and ban the source IP address.

Some events in isolation may alone not indicate a threat and need to be monitored by their quantity and trend. For example, an isolated authentication failure can be caused by a password typo during SIP authentication process. However if many such occur in series, chances stand high it is some kind of password-guessing attack as described in Section Password Guessing Attacks. Being able to recognize such repetition allows the ABC SBC to act automatically and even ban offending traffic without the human administator’s intervention. (see Section Automatic IP Address Blocking).

Most of the events are always produced by the ABC SBC, and administrators don’t need any extra action to enable them. They just need to be able to understand and analyze them as shown in Section Analyze: Finding Patterns in Events using the ABC Monitor.

The rest of this Section is concerned with the cases when reporting events is optional and needs to be turned on explicitely to alert on possible departures from a SIP site’s policy.

8.3.1. Reporting Security Events

As security events failures are reported when a particular administrator-defined policy is being enforced. The only exception is an authentication failure which is always considered a security threat.

The events are reported only if corresponding actions are executed and proper parameters are set. Therefore it is the rule conditions that primarily determine when to trigger an event.

The following table summarizes how rules must be set up in order to generate proper events. All shaping actions report limit violations if event reporting is enabled. So does the drop action when executed on an incoming SIP request, and log-reply when a request is rejected downstream.

Particularly the log-reply action is important as in some cases the downstream SIP elements may know better than the ABC SBC that a request is illegitimate. This is for example the case in a scanning attack when an attacker attempts to probe all possible SIP addresses. The ABC SBC is unaware of individual users and is not in position to repel such an attack straight off. However the downstream server knows subscriber details and can reveal by proper SIP response codes that the requests are for invalid destinations. It may respond back with 604 for non-existing users or 403 for forbidden addresses. This way the ABC SBC can infer from the response codes received from downstream that the upstream request originator should be better blocked.

Event Type Required Action Required Parameter Additional Information
limit Limit parallel calls Report Abuse Traffic Limiting and Shaping
limit Limit CAPS Report Abuse Traffic Limiting and Shaping
limit Limit Bandwidth Report Abuse Traffic Limiting and Shaping
limit Limit Bandwidth per Call none Traffic Limiting and Shaping
message- dropped drop Blacklist by firewall if repeated Manual SIP Traffic Blocking
log- reply Log message for replies Log to Firewall blacklist  

8.3.2. Setting up Diagnostic Events

Diagnostic events are also of great importance to the process of continuous refinement of security policies and bridging the gap between liberal and strict policies. A too liberal policy may lead to exposure of a security gap. On the other hand a too strict policy that filters all unknown SIP elements is likely to break some SIP features. Diagnostic events allow to strike a compromise, in which a policy remains open and diagnostic events report on suspicious traffic patterns. An administrator can then inspect these in details and choose whether they are legitimate and can be preserved, or whether they shall be better banned.

An example of such policy is reporting on call from unregistered users (see Figure Rule Example: Report Calls of Unregistered Users). If an administrator feels uncertain whether such calls are legitimate or not, he may initially just observe them. To do so, he places log-action in an appropriate condition and then watches the reported events. These include detailed information about the calls in question and provide the administrator with insights needed for further refinement of his policies. He may for example find out that the call attempts are coming from a peering domain and are perfectly legitimate. Or he may find that they have no traceable originator and should be better blocked.

The following table lists actions that can be used to provide customized reports on observed activities. The shaping actions can include an additional lower limit to report on high traffic before the “hard limit” is hit and traffic begins to be declined. The action-log can report on any conditions identified in the ABC rules: unexpected URIs, traffic from unregistered users, and anything else that can be captured by conditions specified in Section Condition Types. The message-log event is used analogously, in addition to the event details it also collects the actual traffic that triggered the event.

Event Type Required Action Required Parameter Additional Information
limit Limit parallel calls Soft Limit Traffic Limiting and Shaping
limit Limit CAPS Soft Limit Traffic Limiting and Shaping
limit Limit Bandwidth Soft Limit Traffic Limiting and Shaping
limit Limit Bandwidth per Call none Traffic Limiting and Shaping
action- log Log Event none Diagnostics Events
log- reply
Log message for
Log as Event  
message- log
Log received
none Diagnostics Dashboard

8.4. Analyze: Finding Patterns in Events using the ABC Monitor

See and keep silent. Sir Francis Walsingham, Queen Elizabeth’s Principal Secretary

This section shows how the Monitor can be used when looking for security threats to a SIP service. Detecting presence of attacks and understanding their nature is a pre-requisite for devising proper policies that eliminate harmful and permit legitimate traffic.

Regular monitoring of a SIP service is proven to be the best way to keep operation smooth. Many administrators practice the simple and powerful habit to check their monitoring equipment as the very first thing in their working day. This section shows what to look for in the Monitor. Once a suspicious pattern is identified, the procedure is simple: keep filtering all regular events out until the events causing the pattern remain. Inspect their details and devise a proper policy.

In the following paragraphs we will walk you through the typical “stops” an administrator shall visit during his routing service check.

A good starting point is the “Overview dashboard”. Here a DoS attack can be discovered quickly as the the security-related events gain dominance rapidly. Even Distributed DoS attacks can be spotted there because increased aggregate number of security events will reveal their presence, regardless how well masquerated they are. This is shown in two 10-minutes examples in Figures Total Number of Events in a Usual Situation and Total Number of Events when a Peak in IP Address Occurs Greylisting.

Under normal operation, as shown in the upper part, the event types are balanced. There is a quite high number of greylisting events which is typical for a public SIP service exposed to scans from the public Internet. However, the number of these events still remains in the same order of magnitude as the other events. It is followed by the three registration events, also a typical situation for a public VoIP service in which telephones are turned off and on.

What should catch attention though is a situation in which an event type begins to dominate. This is the case in the lower diagram where greylisting events appear in unsual high quantities. That’s good time to visit the Security Dashboard and find out more specifics.


Figure 24: Total Number of Events in a Usual Situation


Figure 25: Total Number of Events when a Peak in IP Address Occurs Greylisting

The Security Dashboard is introduced in more details in the Section Security Dashboard. The dashboard aggregates events that have relevance to security of a SIP service. Presence of authentication events points at password-guessing attacks (Section Password Guessing Attacks), presence of log-reply events at scanning attacks (Section Scanning Attacks), and presence of dropped-message events at rejected attempts to violate SIP site’s security policies. So do Limit events unless they limit violation reaches an extend of a Denial of Service Attack (Section Denial-of-Service Attacks).

Not all SIP attacks have the ambition to ruin or gain control of a SIP service or a SIP user identity – some have the very simple motivation to find policy gaps that mistakenly permit phone calls. Such attempts are best spotted in the Toplist Dashboard as dicussed in the Section Dial-out Attempts.

The following subsections detail on how to identify typical threats. Note that real incidents as recorded by frafos are shown here that cannot be easily reproduced and may therefore include screenshots of previous ABC Monitor version with slightly different graphics.

8.4.1. Password Guessing Attacks

How would you feel if someone stole your password and was able to initate and receive your phone calls, and all of it at your expense?

Password guessing attacks are really irritating: they are aiming at acquiring a user’s password by guessing all thinkable variants of trivial passwords. The guesses are performed by machines. Once succesful, the attacker can impersonate his victim and make phone calls on his behalf. The good thing is these attacks relatively easily manifest themselves by an abnormally high number of failed authentication attempts. If an attacker tries to stay under the radar, the total number of failures may not be apparent. Even then, however, the failures become easily visible when tied up to the attacker’s IP address or geographic region. Such a situation is easily discovered in the Security Dashboard. A snapshot of the dashboard under attack is shown in the Figure Events Reported during anEvents Reported during an Authentication Attack. The toplist reveals that three of the ten most offending IP addresses come from the same subnet beginning with 200 and they are all clustered in South America.


Figure 26: Events Reported during anEvents Reported during an Authentication Attack

This intelligence is good enough to take counter-measures and lock the offenders by using some blocking techniques introduced in the Section Police: Devising Security Rules in the ABC SBC.

An investigative administrator may go further and study the attacker’s background. He may look at event details, see if these are attempts to register or make a phone call, what URIs are being used, or even return to the Home Dashboard, filter events by IP address and find out about all other activities of the offender. He may also filter the events from this offender out to see if this massive attack hasn’t overshadowed another less intense one.

8.4.2. Scanning Attacks

Would you be irritated if you found someone fiddeling with your house door’s lock? Then get some nerves with SIP services operating on the public Internet: This is happening every second and is called “scanning attacks”.

Scanning attacks are attempts to send SIP messages to various SIP addresses to find out if the server is connecting calls to them. Very often, attackers dial-out a telephone number many times with various prefixes in attempt to find a gap in dialing plan that will let them through. The destination number is often a premium number that generates revenue for its owner. Scanning attempts typically result in an increased number of failed authentications when the SIP service policy requires authentication, or some 403s (Forbidden)/480s(off-line)/604s(no such URI) when the service is not serving a particular destination. Alone this information may be useful for an attacker – finding out that a destination exists may encourage him to mount a password-guessing attack against it.

Therefore it makes sense to check “Log Reply” events in the Security Console and find senders who are trying to reach many non-existing addresses or whose request often fail for other reasons. Such are often indeed originators of scanning attacks. We clearly see in the Monitor (Figure Scanning Attacks Shown on Security Dashboard) that the in the observed period the log-reply events peak up shortly.


Figure 27: Scanning Attacks Shown on Security Dashboard

The relatively flat distribution across IP address leaves us with a question whether that was a coincidence or an orchestrated distributed attack. In such cases administrator’s insight is needed to judge the “Friend or Foe” dilemma. We discuss this further in the Section Distributed Attacks.

8.4.3. Denial-of-Service Attacks

Denial of service attacks (DoS) are simply excessive amounts of traffic targetted on a site with the sole purpose of impairing its service partially or completely. The ABC-SBC includes various counter-measures, probably the most effective one being the automated blocking described in Sections Automatic IP Address Blocking.

Presence of a DoS attack is best detected by the shaping actions that set traffic limits and report on their violations using limit events as documented in Section Traffic Limiting and Shaping. Adequate care is needed when devising the limits to match legitimate traffic patterns otherwise legitimate traffic could be shaped and reported on as abuse.

Once the limits are exceeded the offenders appear on the Security Dashboard. If the excessive traffic recurs and Auto-blocking is turned on, the offending IP addresses will be blocked.

An example of such a situation is shown in Figure Excessive Traffic Captured on a Security Dashboard. The limit event peaks come in quantities on timeline around 11:30 and in Hong Kong in the map. Further analysis, which is not shown in the Figure, reveals that a single User Agent Type is sending total of 5 requests per second using several distinct URIs. An administrator may then judge if his limits are set correctly and revealed an actual DoS attender, or if his limit criteria have been to strict.


Figure 28: Excessive Traffic Captured on a Security Dashboard

8.4.4. Distributed Attacks

Probably the closest non-computer analogy of a distributed attack is cross-fire when a target is exposed to an attack from many sides.

Distributed networking attacks are indeed a sophistication of other attack types that attempt to gather destructive force while remaing under radar screen. To obtain this explosive mix, the attacks are mounted from multiple sources. The most popularized distributed attack is the distributed denial of service attack (DDoS). However any other attack forms can be mounted in the distributed form and gain in invisibility and strike power.

The SBC can actually filter out substantial parts of a distributed attack on its own as shown in Section Automatic Proactive Blocking: Greylisting. The greylisting technique filters traffic which doesnt’ appear to do explicit harm yet it could have been probes prior to a real attack. It may be therefore worth to keep eye on the whitelisting and greylisting statistics. See the Figure Network Statistics Dashboard Capturing a Failover Situation in Section Network and Statistics Dashboard.

Still it may be useful to detect presence of a distributed attack. A way to examine validity of a situation is to compare the number of registrations (over 3 thousands in the example shown) and the number of greylisted IP addresses (around 70,000). The order of magnitude difference here shows there are many more IP addresses causing usless if not harmful traffic than those originating legitimate traffic.

Another place worth looking at is the Overview Dashboard and break-down of events by type, see Figure Total Number of Events when a Peak in IP Address Occurs Greylisting. While distributed attacks are more or less good in hiding their source, their presence can still be detected by their intensity, i.e. by number of certain event types that depart from values experienced under normal situation.

8.4.5. Dial-out Attempts

One of the very common attack forms is dial-out attempts. Technically it is the simplest possible attack and yet it can provide high gains to the attacker. It is simply trying to dial telephone numbers to see if the attacker can connect to them without authorization.

We have shown techniques that can discover such attacks in a generic way. If the attacker tries too hard and fast, his efforts will be exposed by the limit checks that serve the purpose of DoS detection (Section Denial-of-Service Attacks). If the attacker is not making good guesses about the service’s numbering plan, his attempts will be discovered using the response-checking technique used also for discovery of scanning attacks (Section Denial-of-Service Attacks). The attacker may be smarter though: he can seek for unprotected telephone numbers at low pace and using some educated guesses about dialing plans.

So if the attacker manages to remain “under radar” we still have to find out that someone is trying. The simplest way is to visit the “Top Lists Dashboard” – it shows a number of attempts and completed calls sorted by URI. Abnormal number of call attempts or even completed calls will appear here, even if the signaling rate remained moderate and the caller “hit” valid phone numbers. Therefore the daily-check routine for an administrator shall include visting the “toplist Dashboard” and inspecting events of the most active users.

The most active users appear in the “toplist dashboard” sorted in descending order. The example screenshot in Figure Example Toplist of Attempted and Completed Calls gives us a quite clear picture: a user whose name begins with “fmat” attempts many more times calls than anyone else in the observed period of time. It is also unusual that the same user does not appear in the top-list of completed calls.


Figure 29: Example Toplist of Attempted and Completed Calls

To verify if this is a legitimate user, the same method can be used as introduced in Section HOWTO Find a Needle in the Haystack: Iterative Event Filtering: iterative filtering. When you narrow down the events to those originated by a suspicious From URI, the other toplists will show values relating to the specific originator. If for example, the destination toplists shows the same destinations only with varying prefixes, we know this was an attempt to break through. Example of such call attempt deailts are shown in Figure Example: List of Attempted Destinations. Obviously someone is trying to use a SIPCLI tool to call a number 48957372266 with varying prefixes (011, +, 9011, etc). The attempts are slow to remain under radar screen: they attempt every five minutes. They always yield the SIP reponse code 403 (Forbidden).


Figure 30: Example: List of Attempted Destinations


[1]Geneiatakis, Dimitris, et al. “SIP message tampering: the SQL code injection attack.” Proceedings of 13th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2005), Split, Croatia. 2005.
[2]Abdelnur, Humberto, and Olivier Festor. “Advanced fuzzing in the VoIP space.” Journal in Computer Virology 6.1 (2010): 57-64.