Mitigating SIP Attacks
The goal of this appendix is to provide configuration recommendations to be implemented on the Session Border Controller (SBC) to reduce the negative effects of SIP scanning tools.
The configuration techniques described will reduce the impact of attacks by known tools. The intent is to drop all packets received from these tools without responding wherever possible. This is not possible in all cases. DDoS configuration adjustments will be recommended to reduce the impact of attacks on SBC resources and allow uninterrupted service to legitimate, trusted users.
Overview
- 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 blacklist 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 Whitelisting: 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 whitelisting.
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 blacklisted 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 blacklisting 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.
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 whitelists 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
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>"
Whitelisting 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 whitelist 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 whitelist
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 !($whitelist.$0)
new-value "<sip:10.12.13.14;lr>
realm-config
identifier access
description Serving all access endpoints
.
.
.
in-translationid
out-translationid
in-manipulationid addRouteHeader
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
response-map
name 503Rogue
entries 503 -> 677 (Rogue)
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 blacklisted 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.
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 blacklisted for abuse. Keep in mind that signaling thresholds will then need to be set on the realm.
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
