Mitigating SIP Attacks

Overview

SIP scanning and attack tools employed by fraudsters may target specific IP address ranges directly, but most tend to be random scans of a whole range of IP addresses. The scanning and attack methodology seen most frequently includes:

OPTIONS - Discover whether a SIP process is open and listening by asking for supported SIP options
INVITE - Check for an open service that will forward calls without authorization or challenge for registration by sending an initial call request
INVITE or REGISTER – Send calls and/or user authentication requests; Based on the error received it may be possible to enumerate user extensions, or in other words determine what accounts are available for password cracking.
REGISTER - Guess weak or default passwords; The attacker sends tens, hundreds, or even thousands of passwords per discovered extension until a password is found.
Start making calls. The attacker then registers a soft client and makes call attempts. The initial call attempt may not work if a dial prefix is needed, so attackers try all of those until they get an outside line

Most of the scanning tools such as SIPVicious, SIPScan, smap, and Sipsak are open source and freely available. Other tools are used exclusively by specific segments of criminals. As of the end of 2012, 99% of the attacks on customer systems and public SIP honeypots that we tracked were committed using an open source tool with easily identifiable characteristics.

This appendix provides configuration recommendations and references for more detailed information used to mitigate attacks by SIP scanning and attack tools. Several methods will be discussed since not all solutions may be acceptable in all customer environments.

Deployment Archetypes

Oracle classifies SIP deployments in three different major archetypes:

Peering: Calls are sent from a SIP proxy to the SD. The proxy may host SIP user agents or analog devices if a gateway function is provided. Peering is deployed either over a private network such as MPLS from service provider to customer, or over-the-top (OTT) via the Internet.

Customers using SIP peering or “trunking” deployments can usually implement a combination of trusted Session Agents (SA) and Access Control Lists (ACLs) to limit what remote IP addresses are able to communicate with the SD. In a peering network there is an implicit level of trust since the remote IP address is known and provisioned. When the trunk is delivered over a private network we are not usually concerned with SIP scanning prevention since there is no direct Internet access. In deployments where peering does happen over an untrusted network, such as OTT, the ACL entry drops incoming requests from unknown sources.

It then falls to the operator to determine if their particular architecture might see SIP scans from behind a trusted IP address. With multiple layers of NAT in IPv4 networks, it is always possible that messages are transiting through a firewall or gateway rather than just an individual SIP proxy.

Access: Calls are sent directly from a SIP endpoint to the SBC. A SIP registration may be required to authenticate and authorize the services available to the endpoint.

Access deployments will benefit the most from SIP scanner mitigation. This deployment model relies on the ability for users to roam, so ACLs based on known IP addresses cannot be used. Access to the network needs to be controlled via other means, usually through the use of a SIP registration.

Hybrid: Many networks have a mix of peering and access. In these cases, calls from remote subscribers may be sent to a trusted peer such as a service provider.

Strategies for Mitigating Against SIP Scanners

Mitigation against SIP scanners can be provided through several complementary strategies.

Access Control: Ensure proper configuration to block unauthorized end-points. Proper configuration of access control settings such as realm trust levels, access control lists (ACL), and SIP port allow-anonymous settings can limit traffic to known session agents and/or registered endpoints.
Threat Identification: Identify and drop messages from SIP scanners and avoid responding to the sender whenever possible - fraudulent messages can be dropped based on patterns found in the SIP messaging.
Enforcement: Limit attacks that cannot be identified as a scan from a known tool. Enforcement of message thresholds (DoS configuration) can demote or blocklist endpoints that do not become trusted or abuse their existing trust potentially limiting the damage of a scan.

There are several types of access control that apply to deployments over untrusted networks.

Denial of Service Prevention: The section regarding DoS in this appendix covesr proper configuration of access control parameters. Guidelines are provided for configuring trust levels, ACLs, allow-anonymous settings, and message thresholds.

Signaling Authentication and Encryption: SIP can be encrypted using the Transport Layer Security (TLS) protocol. If the connection is established using mutual certificate authentication, then a resulting benefit is effective access control. During the TLS connection establishment, the endpoint verifies the SBC certificate, and the SBC verifies the endpoint certificate was issued by a trusted Certificate Authority (CA). That mutual authentication provides assurance that the device is legitimate, and not an attack tool. When combined with the use of online certificate status protocol (OCSP), it is possible for administrators to refuse network access to devices that are lost or have left the organization. If TLS with mutual authentication is used, then the effects of all SIP scanning tools are mitigated.

Not all endpoints support installation of third party certificates or TLS encryption, and it may be difficult for an organization to issue and manage individual client certificates. TLS (and optionally SRTP) may also require additional hardware for encryption acceleration.

Endpoint Allowlisting: If an organization manages the endpoints in use it can fingerprint them the same way we fingerprint attack tools. Endpoints will advertise a SIP User-Agent value or may have proprietary SIP headers that provide identifying values. Messages from endpoints that do not have these characteristics can be rejected using a Header Manipulation Rule. Section 3 of this Tech Note describes the Header Manipulation Rules required to perform User-Agent allowlisting.

Threat Identification Alternative 1: sipShield SPL plug-in

The Session Plug-in Language (SPL) is an Oracle API library that exposes core functions to an embedded LUA processor via call-backs. A plug-in is an additional piece of software written using SPL that runs on the SBC to implement a custom feature. It is supported via Oracle Consulting Services.

sipShield enables the SBC to drop SIP messages containing the identifying characteristics of known malicious tools with absolutely no response to the attacker. The sipShield plug-in examines multiple characteristics of each message, and is superior to our second option, “Header Manipulation Rules for Scanner Mitigation” described below. It is recommended that sipShield should be used wherever possible.

Since sipShield requires a specific SPL API version, it is not available for all software releases. Only recent releases of software support sipShield at this time. To determine if sipShield is supported issue the “show spl” command in the ACLI. If the SPL version found is 2.0.1 or greater then sipShield is supported. If the command is not found then SPL is not included in the software release.

ACMEPACKET# show sp
SPL Version: C2.0.1

Threat Identification Alternative 2: Header Manipulation Rules for Scanner Mitigation

If sipShield is not appropriate for your environment, the second alternative is to use SIP header manipulation rules (HMR) to drop messages received from known, fraudulent User-Agent(s). The HMR rule processes each inbound message, and if a match is found, it marks the message as invalid or “Rogue”. Subsequent responses back to the attacker are dropped. Unfortunately the SD’s B2BUA will usually respond with an initial response (“100 Trying” or a 4xx error) prior to evaluation with the HMR (the specific response depends on realm settings). This gives the attacker the knowledge that there is a SIP process running (even though the INVITE response is dropped). As they continue their attack, INVITE and REGISTER messages will be dropped without reaching the core, and they will eventually be demoted or blocklisted depending on your DoS settings.

Header Manipulation Rules for Scanner Mitigation are covered below.

Enforcement: Implement DoS Prevention

Some scanning tools will not match a known pattern because they are either new, or a skilled attacker has changed SIP fields to make them less detectable. DoS/DDoS prevention settings can protect against attacks that cannot be identified by their SIP messaging. Endpoint actions can be limited by requiring them to register first, and by enforcing defined message thresholds. The administrator can determine what happens when the thresholds are exceeded – either a ‘demotion’ to a queue with less bandwidth, or blocklisting for a configurable period.

Basic DDoS configuration settings are outlined in the other appendices. However, for the best DDoS protection, the configuration should be customized based on the customer environment and the traffic levels they actually receive.

DoS settings that help mitigate SIP scanning risks are also depicted below.

SIP Header Manipulation Rule Logic

One way to drop all packets sent from an endpoint running an SIP scanner is to use a combination of SIP Manipulation Rules in conjunction with a dummy Session Agent. In this case, a dummy session agent is defined that is not an externally routable target.

As a message enters the SBC it is passed by the SIP interface to the incoming HMR. The HMR applies a regular expression against the message to determine if it is a scanning tool. If there is a match, the HMR can take action to mark it as invalid by inserting an additional route header and forwarding it to a “dummy” session agent. Provisioning the dummy session agent with the state disabled will cause the call to be refused. Custom mapping this to a unique error response can in turn be used in conjunction with a sip-interface option configurable to drop specific error responses.

Below is a flow diagram of how a SIP REGISTER message with a User-Agent header of “friendly-scanner” will be dropped.

HMR creates a dummy address in the Route header.

Some customers have asked about using the “reject” action in HMRs to send a “677 Rogue” response rather than routing to a dummy session agent. However, the “reject” action is evaluated immediately, and therefore is not affected by the sip-interface dropResponse parameter so the attacker will receive many more responses than you intend.

Header Manipulation Rules Configuration

An inbound SIP Manipulation Rule needs to be created to modify any messages that contain a User-Agent header that is known (or suspected) to be fraudulent. The manipulation rule will add a Route header that directs the message to a “dummy” Session Agent.

Two rule examples are given. The first one identifies fraudulent User-Agent values, and the second allowlists only the desired User-Agent values and denies all others.

Note:

The list of User-Agents in the match-value shown in the example should be entered without spaces between the pipe symbols. There is an extra space for formatting.
Release S-CX7.2.0 and greater allows you to log attack messages to the /ramdrv/logs/matched.log file if you wish. Simply change the store action in the isScanner rule to log.
If you already have inbound sip-manipulations the header rules identified in the examples below can be added to them.

WARNING:

If you have valid users of Counterpath Eyebeam in your environment then you should delete the final “|eyeBeam” string from the match-value below.

Identifying fraudulent User-Agent values

In this HMR, the first header-rule uses a logical OR and performs a regular expression match on multiple known User-Agent values. If any of these partial matches is found then the value is stored. The second rule checks to see if the first rule stored a value, and inserts the Route header if it did.

sip-manipulation
        name                 AddRoutHdr
        description
        split-headers
        join-headers
        header-rule
                name                 isScanner
                header-name          User-Agent
                action               store
                comparison-type      pattern-rule
                msg-type             any
                methods
                match-value          friendly|sundayddr|SIPScan|
                                     smap|sipsak|sipcli|sipv|
                                     VaxIPUserAgent|eyeBeam
                new-value
        header-rule
                name                 addNullRoute
                header-name          Route
                action               add
                comparison-type      boolean
                msg-type             request
                methods
                match-value          $isScanner.$0
                new-value            "<sip:10.12.13.14;lr>"

Allowlisting known User-Agents

A similar HMR is used here. The first header rule is replaced with one that uses a logical OR with multiple values, but its regular expression match is for valid User-Agents. If a valid User-Agent match is found, it is stored. The expressions used can match a part of the User-Agent string, and can be as specific (or unspecific) as required. The final rule has been modified to insert the invalid route if a valid User-Agent was NOT found.

Note:

If endpoint firmware is updated and the User-Agent string changes then the allowlist rule may start failing and endpoints will be denied. Make sure to perform lab testing prior to any endpoint software updates.

sip-manipulation
        name                 AddRoutHdr
        description
        split-headers
        join-headers
        header-rule
                name                 allowlist
                header-name          User-Agent
                action               store
                comparison-type      pattern-rule
                msg-type             out-of-dialog
                methods
                match-value          (Bria Professional release 2.4.3
                                     stamp 50906|UCCAPI|Avaya SIP R2.2
                                     Endpoint Brcm)
                new-value
        header-rule
                name                 addNullRoute
                header-name          Route
                action               add
                comparison-type      boolean
                msg-type             request
                methods
                match-value          !($allowlist.$0)
                new-value            "<sip:10.12.13.14;lr>

Realm: The access realm-config must also be modified to assign the SIP manipulation rule defined above as the inbound manipulation. Add the addRouteHdr manipulation for both fraudulent and allowlisting scenarios.

realm-config
        identifier               access
        description              Serving all access endpoints
        .
        .
        .
        in-translationid
        out-translationid
        in-manipulationid        addRouteHeader

Session Agent: A dummy Session Agent needs to be created with the state disabled. This is important so that the Session Agent will reply with a 503 response to any request. The 503 response will then be mapped to a new response code that can be easily dropped. A SIP Response Mapping is created to map any 503 from this Session Agent to a 677 SIP response code. We use an error code that is not valid according to RFCs so it can easily be distinguished from other traffic. Any 677 responses can then be dropped at the SIP Interface level without dropping any valid 503 responses from other endpoints. The SIP Response Mapping must be assigned in the Session Agent as shown below.

session-agent
        hostname               10.12.13.14
        ip-address
        port                   5060
        state                  disabled
        app-protocol           SIP
        transport-method       UDP
        realm-id               *
        .
        .
        .
        local-response-map     503Rogue

SIP Response Mapping: A SIP Response Mapping must be configured to map 503 responses from this Session Agent to a dummy response code (677). The response-map ACLI level can be found in configuration mode under session-router > sip-response-map.

response-map
        name              503Rogue
        entries           503 -> 677 (Rogue)

SIP Interface: All SIP interfaces that receive messages from SIP scanners require the option “dropResponse=677” to drop the 677 responses received from the dummy Session Agent.

sip-interface
        state              enabled
        realm-id           access
        .
        .
        .
        options            dropResponse=677

Scanner Mitigation using DDoS Settings

The DDoS settings recommended in the appendices will protect the SBC, but more strict trust levels and thresholds need to be defined to deny endpoints that are attempting to scan the system. To accomplish this, the access-control-trust-level on the access realm-config must be configured to low, which will cause endpoints to be blocklisted when they exceed thresholds. The untrusted-signal-threshold parameter defines the threshold of SIP messages received within the global tolerance-window (set under media-manager) before an untrusted user will be demoted to denied. The untrusted-signal-threshold should be set to a value that is just greater than the number of messages required by an untrusted endpoint to become trusted through SIP registration. The untrusted-signal-threshold value should be confirmed by collecting and analyzing a packet capture from the targeted network deployment. In many cases a registration will be two or three messages, but endpoint behavior and requirements vary. When this threshold is exceeded, the endpoint will be placed on the denied list for the amount of time defined in the deny-period. This period should be determined based on your individual needs. Setting the deny period to a long duration may cause problems for endpoints that simply entered an incorrect password or had a connection issue with some packet loss.

The following parameters should also be customized to your needs based on expected call flows.

realm-config
        identifier                      access
        description                     Serving all access endpoints
        .
        .
        .
        access-control-trust-level      low
        invalid-signal-threshold        1
        maximum-signal-threshold        4000
        untrusted-signal-threshold      5
        nat-trust-threshold             0
        deny-period                     120

Configure the media-manager settings per the recommendations in the DDoS prevention appendix that is applicable for your architecture. The max-untrusted-signaling parameter will limit the amount of untrusted traffic the SBC will process.

If any media-manager settings are changed you MUST save, activate, and reboot the SBC so they will take effect.

Peering Environments

As noted earlier, this appendix does not focus on scanning attacks in SIP Peering environments. In these environments it is recommended to create static ACLs with a trust level appropriate for the peer. It is recommended when peering over a trusted network, such as an MPLS connection delivered from a service provider, that a “high” trust level should be used. If your trust in the peer is not assured, it may be appropriate to set trust level to “medium” or “low” so they will be limited or blocklisted for abuse. Keep in mind that signaling thresholds will then need to be set on the realm.

The realm-config, access-control-trust-level should match the trust-level of the ACL so that all traffic from any endpoint that does not have an ACL will be denied. Always make sure that the realm-id, source-address, destination-address, and application-protocol are specified.

realm-config
        identifier                      peer
        description                     
        addr-prefix                     172.16.101.6
        .
        .
        .
        access-control-trust-level      high

access-control
        realm-id                        peer
        description                     
        source-address                  172.16.101.6
        destination-address             197.168.11.100
        application-protocol            SIP
        transport-protocol              ALL
        acces                           permit
        average-rate-limit              0
        trust-level                     high