8.5. Practices for Devising Secure Rule-basis

While we have shown in previous sections how to police traffic, collect diagnostics information and analyze it there is still a remaining question: how to put all of this together in a consistent configuration using the ABC SBC rules. The way the rules are compiled can have significant impact on the logic of the service.

When devising the rule-base, the following important choices must be made:

  • Whether to use Media Control or not. Relaying media (Section Media Anchoring (RTP Relay)) provides the ABC SBC with more control and insight into calls at the price of performance and media latency. Also it is a necessity when NAT traversal (NAT Traversal) needs to be implemented, IP addresses of infrastructural elements behind an ABC SBC need to be hidden, transcoding (Section Transcoding) or RTP-to-SRTP conversion (Section RTP and SRTP Interworking) is needed. If used, which is nowaydas the default choice, the latency impact can be mitigated by greographic dispersion (see Section Introducing Geographic Dispersion for more information on what difference geographic distribution makes in a cloud environment).
  • Whether to use Topology Hiding or not. Topology Hiding obfuscates signaling so that it is hard for an external party to find IP addresses of the infrastructural elements behind the ABC SBC . We are describing the rules to be used for topology hiding in the Section Topology Hiding. Note that obfuscation of SIP traffic may make its analysis quite difficult. If used tracing of traffing using ABC Monitor is recommended.
  • How to organize policing rules. A reasonable practice is to start with rules that identify and instantly drop undesired signaling traffic before “heavier-processing” rules, such as media control or database queries begin. We show our recommendations in the Section Devising a secure rule-base.

8.5.1. Topology Hiding

Some service providers are worried about dislosing IP addresses of their infrastructure to third parties, attackers and competitors. Unfortunately the SIP protocol does such a disclosure in a grand style: SDP payload shows IP addresses from/which media is sent, Contact header-field shows the IP address of an end-point, and so does pre-RFC3261 CallID header-field. Via, Route and Record-Route header-field disclose the path of a SIP message exchange. Other standardized and / or proprietary header fields can also carry IP addresses.

Therefore service providers concerned about such disclosures prefer obfuscation of the respective SIP message elements. It needs to be pointed out though, that what makes life harder for attackers makes it similar hard or even harder for service operators. Correlating messages with each other for sake of troubleshooting is much harder when they are modified.

In the following subsections, we will review the default topology hiding behaviour and how to make it more transparent or more obfuscated.

8.5.1.1. Default Address Hiding

The default configuration of the ABC SBC tries to strike a good balance between the two extremes, full disclosure and full obfuscation. Already the back-to-back user-agent (B2BUA) design of the ABC SBC contributes significantly. The whole SIP path, as disclosed in Via, Route, and Record-Route header fields is split in two call-legs, each of them terminated by the ABC SBC. As result, each SIP dialog party sees the SBC as its peer in these Header fields. Additionally the ABC SBC by default rewrites dialog information (the triple CallID, From-tag, To-tag) so that IP address present in pre-RFC3261 implementations CallID is obfuscated.

If more signaling transparency is need than this default behaviour implements, transparent dialog ID can be enabled by an action as shown in the next Section. Also in some rare scenarios, the downstream elements in the SIP path may need to inspect the Via stack for the upstream leg. The ABC SBC reintroduces it when the following action is enabled:

Show Via

8.5.1.2. Transparent and Non-Transparent Dialog ID

The other concern is CallID – old-fashion SIP implementations pre-dating RFC3261 followed the RFC2543 specification and disclosed its address in CallID header-field. To make sure that the addresses do not get disclosed through this header-field when out-of-dialog or dialog-initiating requests are created by an elderly SIP User Agent, the ABC SBC can replace the CallID values with obfuscated values.

The choice whether to do is is administrator’s. By default the ABC SBC does change the CallId Header Field value.

We recommend that administators consider preserving the CallID for sake of troubleshooting. Leaving it unchanged makes correlation of incoming and outgoing SIP messages significantly easier. Enabling it is easy, what needs to be done is to place the following action in a Call Agent’s or Realm’s rules:

Enable transparent dialog IDs

Another advantage is that some non-standardized SIP extensions may want to take reference to a CallID value which becomes invalid once the ABC SBC changes it.

8.5.1.3. Hiding Addresses in Well-known SIP header-fields

When an operator is indeed concerned about disclosing internals of a Call Agent, the very step is to make sure that occurences of the Call Agent’s address in well-known header-fields are replaced with ABC SBC ‘s. Doing that is as simple as turning the Topology Hiding checkbox on under Call Agent’s attributes. Once enabled all the following header fields will be rewritten accordingly:

Note that if the Warning header field is obfuscated, it is denoted using an additional ;topoh paramater. This makes it clear that the address in the header-field is not genuine – otherwise a troubleshooter may be misled.

8.5.1.4. Hiding Contact Header in REGISTER

The Contact header is by default obfuscated by the SBC in all dialog-initiation transactions. Contact header field in REGISTER requests remains however untouched. If obfuscation is desirable, ABC SBC‘s register cache must be used that replaces the original Contacts with aliases.

The Section Registration Caching and Handling provides details about configuring registrar cache. This may be a reasonable option to be turned on alone for its “shock absorbing” and “NAT keep-alive” capabilities.

8.5.1.5. Hiding All Other Header Fields

Additional header-fields, standardized (Service Route RFC 3608) or proprietary, may appear and convey IP addresses. The ABC SBC only obfuscates the documented header-fields and doesn’t interfere with others. If other header-fields are present and disclosure of IP address is a concern, the administrator can remove them at the risk of affecting the purpose they are serving. He can either remove the specific header-fields or use header field whitelist, i.e. remove all but well-known header-fields. SIP manipulation is described in detail in the section SIP Mediation, of particular interest is the action set header whitelist.

8.5.1.6. Concealing Media

Similarly like with SIP, the ABC SBC can put itself in the middle of the path and present itself to each call as its peer while hiding the other party. If the ABC SBC doesn’t do it, IP address used for sending/receiving media will be seen in SDP and in the actual RTP packets.

To conceal the media sender/receiver, the following action must be enabled:

Enable RTP anchoring

The downside is that all media visits the ABC SBC, while increasing media latency and bandwidth imposed on the server. A detailed discussion can be found in the Section Media Handling .

8.5.2. Devising a secure rule-base

Developing a reasonable security policy may be a delicate task for a SIP service administrator. A too strict policy may too easily “throw the baby out with the bathwater” and impair legitimate traffic. The other extrem, a too liberal policy, may be too inviting for an attacker. Finding the right balance between serving users and protecting them from attackers requires understanding of the service goals and risks and drawing a balance between them.

The policy represented by the ABC rules also has performance implications associated with it. Some rules, such as database lookups, have higher latency and lower throughput than others.

We therefore suggest that policies are crafted in order of increasing complexity, starting with rules that instantly reply certain requests and continue to more complex rules. Basically, all undesirable SIP messages should be eliminated by rules in the initial rule-base part before processing for the accepted messages starts in the other part. The following subsections show examples of such rules in such order.

8.5.2.1. Shaping the Signaling Rate

It makese sense to begin processing with a check against SIP rate limits. Placing the check in the very beginning makes sure that all incoming SIP requests are checked against these limits including requests that are dropped by rules.

In Figure Rule Example: CAPS Shaping we are showing a simple rule example for sake of this Section. The rule checks all incoming SIP messages against a request rate and declines messages in excess of the limit.

_images/rule-shape-simple.png

Figure 1: Rule Example: CAPS Shaping

More sophisticated examples for shaping rules have been given in Figure Limit on number of Call Attempts per Second in Section Traffic Limiting and Shaping by Example.

8.5.2.2. Instant Responses

Many requests come that do not require any sophisiticated decision making: the right action is just to send a reply instantly. The reply can be positive or negative. Positive replies are typically sent in answer to some SIP User Agents’ SIP-layer NAT keep-alives. Negative answers are sent when requests request some unsupported service, do not comply to some local URI conventions, or come from a User Agent type known to misfunction.

The following rule examples show both cases: positive reply (Figure Rule Example: Confirming SIP Keep-alives) for keep-alive messages and negative replies to decline a request for unsupported Message Waiting Indication server (Figure Rule Example: Declining an MWI Request).

_images/keep-alive-rule.png

Figure 2: Rule Example: Confirming SIP Keep-alives

_images/rule-decline.png

Figure 3: Rule Example: Declining an MWI Request

8.5.2.3. Dropping

With SIP requests who appear a security threat, dropping them silently is a safer choice than declining them. The less information an attacker gets, the harder it is for him to find a security gap in a SIP service. If an IP address is sending clearly offending traffic, it may even make sense to ban it entirely.

A typical reason for deploying such a restrictive rule is elimination of SIP scanner traffic. SIP scanners are automated tools that probe Internet address space to see if there are some SIP services running. Such tools are even publicly available [1]. When such a tool finds a responsive SIP service, it continues looking for legitimate SIP addresses and it may even proceed to mounting a password-guessing attack. Such attacks are real: Once you start a SIP service on the public Internet, it takes no longer than few hours until the first scanning packets arrive. Note however that filtering such traffic is only eliminating naively crafted attacks that advertise themselves as such. More sophisticated attacks will certainly not do it and must be detected and repelled using other methods such as traffic shaping.

_images/rule-drop-and-firewall.png

Figure 4: Rule Example: Eliminating Traffic from SIP Scanners

The rule has an important option turned on: “Blacklist by firewall if repeated”. That means if the offending traffic appears repeatedly, the originator’s IP address will be blacklisted.

8.5.2.4. Database Checks

By now, we have eliminated most of the unwanted traffic: we have declined excessive traffic, gracefully handled SIP-layer keep-alives, declined politelly messages for unavailable services and dropped obvious security threats. The remaining traffic has been reduced to a level where we can deploy more expansive policy checks and dig in database. Often there are offending users identified by their URIs. A straight-forward way to eliminate their traffic is to provision a list of such users and block SIP traffic if it comes from such users. Figure Rule Example: Prohibited URIs shows a rule that looks up SIP requests From URI in such a table and if the URI is found, drops the request silently.

_images/rule-banned-uri.png

Figure 5: Rule Example: Prohibited URIs

8.5.2.5. More Limits

We may also want to constrain the number of parallel calls. We didn’t place such a limit in beginning of our rule-set. The reason is that too many call attempts are rejected in the inital part of rule-set and count towards the limit too. When we place the parallel call limit in the rule-base after all unwanted traffic is rejected, the call attempts we chose to decline won’t count towards the limit.

Figure Rule Example: Limit Parallel Calls shows rule for enforcement of maximum five parallel calls per single IP address. Also note that in this rule, no soft-limit warning is enabled and limit violations add to the security score computed by automated blocking (Section Automatic IP Address Blocking).

_images/rule_limit_pc.png

Figure 6: Rule Example: Limit Parallel Calls

8.5.2.6. Diagnostic Events

Often SIP messages do appear whose purpose is not entirely clear. Devising a policy that drops them may be premature – they may have some legitimate use which the administrator doesn’t understand. It is therefore a good practice to observe them before considering a policy adjustment. This moment of rule processing is perfectly right for this purpose: all traffic that shall be dropped is dropped already.

Example of such is shown in Figure Rule Example: Report Calls of Unregistered Users. This rule reports on all non-REGISTER requests for users who have not registered previously. This may be perfectly reasonable for a peering trunk and quite suspicious for a residential user. Gathering these diagnostic events puts an administrator in position to analyze the traffic and create well-targetted policies.

_images/rule-drop-unregistered.png

Figure 7: Rule Example: Report Calls of Unregistered Users

8.5.2.7. Processing Legitimate Traffic

At this stage of rule processing we have eliminated well-known offending traffic and reported on suspicious traffic. It is time to devise rules that process the traffic considered legitimate: mediation rules, media processing rules, topology hiding, etc. The most important fact for sake of this Section is placement of these rules: they are placed in the very end of a rule-base after all other checks have eliminated unwanted traffic.

Figure Rule Example: Processing Legitimate Traffic shows such rules: they implement registration caching and media anchoring to facilitate NAT traversal and off-load the infrastructure behind the ABC SBC . These two rules also contribute to topology hiding: use of media relay hides the actual RTP receivers and registration caching hides the registered contacts.

_images/rule-legit.png

Figure 8: Rule Example: Processing Legitimate Traffic

Footnotes

[1]SIP Vicious: https://github.com/sandrogauci/sipvicious