SIP Proxy Attacks

The SIP proxy (or call processor) is a key resource in a SIP-based system. The SIP proxy is responsible for processing all requests between SIP endpoints, including SIP phones, media gateways, and other resources. If the service for the SIP proxy is affected, the entire voice network can be disrupted. Many of the attacks discussed here would prevent all or most of your users from making or receiving calls.

Attack Target SIP Proxies with UDP Floods Using the udpfl ood Tool

Popularity:

8

Simplicity:

9

Impact:

9

Risk Rating:

9

As mentioned previously, SIP proxies use either UDP or TCP for signaling. While SIP requires support for TCP, UDP is still more commonly used than TCP. This means that UDP-based floods are possible against most SIP proxies. To demonstrate these attacks, we modified the udpflood engine software developed by Robin Keir, available at http://www.packetstorm.org. We made several modifications, including the ability to specify layer 2 QoS values, which are discussed in more depth in Chapter 4. The udpflood tool used to target SIP proxies generates "large" 1400 byte packets. The usage information for this tool is as follows :

 udpflood: ./udpflood EthernetInterface SourceName DestinationName SourcePort DestinationPort NumPackets Usage Example: ./udpflood eth0 5000 hacker_box asterisk_proxy 1000000 Mandatory parameters: EthernetInterface - the Ethernet interface to write to. SourceName  host name or IPV4 address of attacking system. DestinationName  host name or IPV4 address of the target system. SourcePort - IP port of the attacking system. DestinationPort  IP port of the target system. This is generally set to 5060 for SIP floods or the port used for RTP on a SIP phone. NumPackets  The total number of packets to send to the target system. 

The udpflood tool builds a UDP packet containing 1380 bytes of payload. The first 10 bytes are ASCII "0123456789," with the remaining bytes set to 0. The udpflood tool does not spoof the source MAC address, because MAC addresses are not a security factor for SIP. Spoofing the MAC address is not necessary to trick any of the SIP proxies or phones into processing the flood packets. More sophisticated tools are described later in this and other sections.

We used the udpflood tool to send 1,000,000 packets to both the Asterisk and SER SIP proxies. Each command took approximately 2 minutes (1 minute 55 seconds) to execute, meaning approximately 8333 packets were put on the wire per second, each of which was 1414 bytes long (this is the Ethernet frame size ), for a total of approximately 12,000,000 bytes. Running Wireshark on the attacking system showed all packets captured. This packet rate is right at 100Mb per second, the theoretical limit for 100Mb Ethernet. Running Wireshark on the target SIP proxies showed that approximately 25 percent to 30 percent of these packets were received. The following commands were used to generate the packet floods:

 ./udpflood eth0 hacker_box asterisk_proxy 9 5060 1000000 

and

 ./udpflood eth0 hacker_box ser_proxy 9 5060 1000000 

We ran the Asterisk SIP proxy in debug mode to verify that it did receive the packets (to ensure that they were not discarded at a lower level). Debug was disabled during attack testing. During the attack, the Asterisk SIP proxy CPU was elevated, but still processed calls. Manual calls, at a rate of one per ten seconds, were completed approximately 90 percent of the time. One in ten calls was not completed. Active calls were not affected at all (this is to be expected because the media flows from SIP phone to phone). The Asterisk SIP proxy recovered from the attack. After the attack ceased, all attempted calls were completed, and we didn't observe any lingering artifacts from the attack.

We ran the SER SIP proxy in debug mode to verify that it did receive the packets. Again, debug was disabled during attack testing. During the attack, the SER SIP proxy CPU was only slightly elevated, but it was not able to process calls reliably. Manual calls, at a rate of one per ten seconds, were never completed. Occasionally, a call between an Avaya and Cisco phone would ring, but the connection couldn't be established, indicating the loss of packets needed to complete the connection. Active calls weren't affected at all, but when the calls were disconnected, no more calls could be made. The SER SIP proxy recovered from the attack. After the attack ceased, all attempted calls were completed, and we didn't observe any lingering artifacts from the attack.

We also used the udpflood tool to target other ports on the Asterisk and SER SIP proxies. Floods directed at other well-known ports, such as 7 (echo), 9 (discard), and so on, had no effect on the SIP proxies. All calls were completed normally.

Attack Target SIP Proxies with INVITE Floods Using the inviteflood Tool

Popularity:

7

Simplicity:

8

Impact:

10

Risk Rating:

8

In SIP, the INVITE request is used to initiate a call. The INVITE request is key because it "kicks off" processing within the SIP proxy or phone. If a SIP proxy or phone can be tricked into accepting a flood of INVITE requests, a partial or full disruption of service can occur. As discussed in the previous section, most SIP networks use UDP, which simplifies an attacker's job in flooding a SIP proxy or phone.

A number of attack scenarios exist for INVITE floods, targeted at both SIP proxies and phones. To demonstrate these attacks, we used a Linux-based inviteflood tool, which, as its name implies, floods a target with INVITE requests. The usage information for this tool is as follows:

 inviteflood: ./inviteflood EthernetInterface TargetUser TargetDomain DestinationIP NumPackets a Alias I SourceIP S SourcePort d DestinationPort -l linestring h -v Usage Example: ./inviteflood eth0 5000 asterisk_proxy asterisk_proxy 1000 Mandatory parameters: EthernetInterface - the Ethernet interface to write to. TargetUser - "" or john.doe or 5000 or "1+210-555-1212". If this parameter is left blank or references a non-existent UA, the SIP proxy will return an error and not attempt to forward the request. TargetDomainIP  IPV4 address used to construct the "To:" line in the INVITE. If a SIP proxy is targeted and this value is not the same as the SIP proxy, then the SIP proxy will attempt to forward the request to the SIP proxy at this address. If the address is unknown or cannot be resolved, the SIP proxy will retry several times before eventually timing out. DestinationIP  IPV4 address of the target system. NumPackets  The total number of packets to send to the target system. Optional Parameters: -a  Alias  Used to set the "From:" alias. -i  SourceIP  Used to set the source IP address. The default is the IP address of the Ethernet interface. -S  SourcePort  Used to set the source port. The range is 0-65535. The default is the well-known discard port, 9. -d DestinationPort  Used to set the destination port. The range is 0-65535. The default is the well-known SIP port, 5060. -l linestring  A string used by the Snom SIP phone. It must be specified for attacks sent directly to a Snom IP phone. -h  Help  Prints this usage information. -v  Verbose  Enables verbose output. 

A sample SIP INVITE request generated by the inviteflood tool is shown next . The inviteflood tool builds an INVITE request, where the CSeq header field value is incremented in each subsequent message and the new value is also used to replace the last ten characters of the following header field values:

  • The Via branch tag

  • The From tag

  • The Call-ID

A change in these values influences the target to interpret each INVITE request as an independent call dialog initiation event, as opposed to a redundant request. For speed reasons, updates to the ID/tags are performed "in-place" (that is, the SIP/SDP request content is not synthesized each time). The size of the resulting layer 2 packet varies depending on the command-line inputs, but is, in general, approximately 1140 bytes (Ethernet II):

 Session Initiation Protocol     Request-Line: INVITE sip:3000@10.1.101.1 SIP/2.0         Method: INVITE         Resent Packet: False     Message Header         Via: SIP/2.0/UDP 10.1.101.99:9;          branch=81000cc6-b738-443e-b583-b70000000001         Max-Forwards: 70         Content-Length: 460         To: 3000 <sip:3000@10.1.101.1:5060>         From: <sip:10.1.101.99:9>;tag=81001bf1-b738-443e-ae96-860000000001         Call-ID: 810026c1-b738-443e-b58d-230000000001         CSeq: 0000000001 INVITE         Supported: timer         Allow: NOTIFY         Allow: REFER         Allow: OPTIONS         Allow: INVITE         Allow: ACK         Allow: CANCEL         Allow: BYE         Content-Type: application/sdp      Contact: <sip:10.1.101.99:9>      Supported: replaces      User-Agent: Elite 1.0 Brcm Callctrl/1.5.1.0 MxSF/v.3.2.6.26  Message body      Session Description Protocol          Session Description Protocol Version (v): 0          Owner/Creator, Session Id (o):           MxSIP 0 639859198 IN IP4 10.1.101.99          Session Name (s): SIP Call          Connection Information (c): IN IP4 10.1.101.99          Time Description, active time (t): 0 0          Media Description, name and address (m): audio 16388 RTP/AVP           0 18 101 102 107 104 105 106 4 8 103 

The inviteflood tool is "transmit only." It is incapable of responding to authentication challenges or call dialog handshaking. The flood of signaling messages is actually worsened by not responding to call dialog handshaking from the targeted SIP proxy or SIP phones, because they retransmit messages. By targeting the SIP proxy, SIP phone, or both, the inviteflood tool can be used to generate a number of different disruption of service conditions.

For most of the attacks, the inviteflood tool was used to send 1,000,000 packets to a target. Each command took approximately 1.5 minutes (1 minute 30 seconds) to execute, meaning approximately 11,111 packets were put on the wire per second, each of which was 1140 bytes long (this is the Ethernet frame size), for a total of approximately 12,000,000 bytes. Running Wireshark on the attacking system showed all packets captured. This packet rate is right at 100Mb per second, the theoretical limit for 100Mb Ethernet. Running Ethereal on the target SIP proxies showed that approximately 25 percent to 30 percent of these packets were received. The commands used for these attacks used this basic form:

 ./inviteflood eth0 target_extension target_domain target_ip 1000000 

For each attack, we recorded the following information:

  • Make/receive calls?   Indicates whether the SIP proxy was able to process new calls.

  • Responses   Lists the types of responses received from the SIP proxy.

  • SIP proxy errors   For one attack, debugging was enabled for each SIP proxy. Any significant errors are reported here.

For all tests, the SIP proxies appeared to fully recover, so this is not documented in the tables that follow.

Note 

Figure 12-4 shows an interesting artifact of these attacks. It shows one of the SIP phones with over 12,000 missed calls. This gives you a sense of the volume of calls you can generate with the inviteflood tool.

image from book
Figure 12-4: SIP phone with over 12,000 missed calls

Target a SIP Proxy with a Nonexistent SIP Phone

This attack floods a SIP proxy with requests containing a nonexistent SIP phone. While a nave attack, unsophisticated attackers might use it if they don't know the address of a SIP phone. Figure 12-5 illustrates this attack.

image from book
Figure 12-5: Targeting a SIP proxy with a nonexistent SIP phone

The command invocations for these attacks are

 ./inviteflood eth0 666 10.1.101.1 10.1.101.1 1000000 

and

 ./inviteflood eth0 666 10.1.101.2 10.1.101.2 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

Yes, but some calls fail.

404 Not Found

None

SER SIP proxy

Yes, but some calls fail.

404 Not Found

None

Both SIP proxies respond with 404 Not Found responses. Because the SIP proxies are also acting as SIP registrars, they know that the target "666" doesn't exist and, therefore, return the 404 response. While both SIP proxies are busy generating these responses, they are still able to process the majority of call requests. A few calls, however, are not processed.

Target a SIP Proxy with an Invalid IP Domain Address

This attack floods the SIP proxies with requests that are intended to be forwarded to another domain. The other domain is, however, an invalid IP address. This is another nave attack, but one which is quite effective. Figure 12-6 illustrates this attack.

image from book
Figure 12-6: Targeting a SIP proxy with an invalid IP domain address

The command invocations for these attacks are

 ./inviteflood eth0 5000 10.1.101.66 10.1.101.1 1000000 

and

 ./inviteflood eth0 5000 10.1.101.66 10.1.101.2 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

Yes, but some calls fail. Call connections also fail.

404 Not Found

None

SER SIP proxy

No, but a few calls go through.

100 Trying 500 Terribly Sorry Server Error 408 Request Timeout

Server out of memory

The Asterisk SIP proxy is more resilient to this attack, because it appears to recognize that there is no valid SIP proxy at the invalid IP address and quickly returns a 404 Not Found response, as it did in the previous attack. The SER SIP proxy, however, attempts to contact the SIP proxy at the invalid IP address. This causes it to allocate internal resources, attempting to establish calls that are never completed. Eventually, it runs out of memory trying to establish and track all the attempted calls.

Target a SIP Proxy with an Invalid Domain Name

This attack floods the SIP proxies with requests intended to be forwarded to another domain that is nonexistent. This is another nave attack, but one which is quite effective. Figure 12-7 illustrates this attack.

image from book
Figure 12-7: Targeting a SIP proxy with an invalid domain name

The command invocations for these attacks are as follows:

 ./inviteflood eth0 5000 bogus.com 10.1.101.1 1000000 

and

 ./inviteflood eth0 5000 bogus.com 10.1.101.2 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

Yes, but some calls fail. Call connections also fail.

404 Not Found

None

SER SIP proxy

No, but a few calls go through.

478 Unresolvable Destination (multiple responses per INVITE request)

Server out of memory

The Asterisk SIP proxy is more resilient to this attack because it appears to recognize that there is no valid SIP proxy at the invalid domain and quickly returns a 404 Not Found response, as it did for the previous two attacks. The SER SIP proxy, however, attempts to contact the SIP proxy at the invalid domain. This causes it to allocate internal resources, attempting to establish calls that are never completed. Eventually, it runs out of memory trying to establish and track all the attempted calls.

The SER SIP proxy is unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxy recovers and is able to process calls normally.

Target a SIP Proxy with an Invalid SIP Phone in Another Domain

This attack floods the SIP proxies with requests for an invalid SIP phone in the other proxy's domain. This attack attempts to load up multiple proxies with one attack. Figure 12-8 illustrates this attack.

image from book
Figure 12-8: Targeting a SIP proxy with an invalid SIP phone in another domain

The command invocations for these attacks are as follows:

 ./inviteflood eth0 666 10.1.101.2 10.1.101.1 1000000 

and

 ./inviteflood eth0 666 10.1.101.1 10.1.101.2 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

No, only a few calls go through.

100 Trying 404 Not Found 408 Request Timeout

Too many open files

SER SIP proxy

No, only a few calls go through.

100 Trying 404 Not Found 408 Request Timeout 500 Terribly Sorry Server Error

Server out of memory

This attack significantly disrupts both SIP proxies. The requests are received by the first proxy, which returns a 100 Trying response. The request is passed to the second proxy, which then returns a 404 Not Found, which is, in turn , returned to the attacker. The first proxy also returns 408 Request Timeout responses because it receives no response to many of its requests. The Asterisk and SER SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to establish and track all the attempted calls.

The SER and Asterisk SIP proxies are unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxies recover and are able to process calls normally.

Target a SIP Proxy with a Valid SIP Phone in Another Domain

This attack floods the SIP proxies with requests for a valid SIP phone in the other proxy's domain, attempting to load up multiple proxies with one attack. It has the side effect of affecting the target SIP phone. Figure 12-9 illustrates this attack.

image from book
Figure 12-9: Targeting a SIP proxy with a valid SIP phone in another domain

The command invocations for these attacks are

 ./inviteflood eth0 6000 10.1.101.2 10.1.101.1 1000000 

and

 ./inviteflood eth0 3000 10.1.101.1 10.1.101.2 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

No

100 Trying 180 Ringing 408 Request Timeout

Too many open files

SER SIP proxy

No

100 Trying 180 Ringing 408 Request Timeout 500 Terribly Sorry Server Error

Server out of memory

This attack significantly disrupts both SIP proxies. The requests are received by the first proxy, which returns a 100 Trying response. The request is passed to the second proxy, which returns yet another 100 Trying response. The requests are passed to the SIP phone, which rings but is unusable. The Asterisk and SER SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to establish and track all the calls.

The SER and Asterisk SIP proxies are unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxies recover and are able to process calls normally.

Different SIP phones behave differently under this attack: the results are documented in the section on "SIP Phone Attacks," later in the chapter. Generally, if the call is answered and hung up, the SIP phone starts ringing again.

Target a SIP Proxy for a Valid SIP Phone

This attack floods a SIP proxy with requests for a valid SIP phone within its domain, attempting to load up the SIP proxy. This attack has the side effect of affecting the SIP phone. Figure 12-10 illustrates this attack.

image from book
Figure 12-10: Targeting a SIP proxy for a valid SIP phone

The command invocations for these attacks are as follows:

 ./inviteflood eth0 6000 10.1.101.2 10.1.101.2 1000000 

and

 ./inviteflood eth0 3000 10.1.101.1 10.1.101.1 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

No

100 Trying 180 Ringing 408 Request Timeout

Too many open files

SER SIP proxy

No

100 Trying 180 Ringing 408 Request Timeout 500 Terribly Sorry Server Error

Server out of memory

This attack significantly disrupts the target SIP proxy. The SIP proxy receives the request, returns a 100 Trying response, and forwards it to the SIP phone. A 180 Ringing response is also returned. If the call is answered, a 200 OK response might also be sent. The SIP phone generally rings and rings and is completely unusable. The Asterisk and SER SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to establish and track all the calls.

The SER and Asterisk SIP proxies are unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxies recover and are able to process calls normally.

Attack Target a SIP Proxy When Authentication Is Enabled

Popularity:

6

Simplicity:

8

Impact:

10

Risk Rating:

8

This attack attempts to flood a SIP proxy when authentication is enabled for INVITE requests. Authentication won't normally be enabled for INVITE requests, but it is possible. With authentication enabled, when the SIP proxy receives an INVITE request, it responds with a 407 Proxy Authentication response. The inviteflood tool doesn't respond to these requests. The INVITE requests generated are for a valid extension in the targeted SIP proxy's domain. Figure 12-11 illustrates this attack.

image from book
Figure 12-11: Targeting a SIP proxy when authentication is enabled

The command invocations for these attacks are as follows:

 ./inviteflood eth0 6000 10.1.101.2 10.1.101.2 1000000 

and

 ./inviteflood eth0 3000 10.1.101.1 10.1.101.1 1000000 

The following table summarizes the results of this attack:

 

Make/Receive Calls?

Response Codes

SIP Proxy Errors

Asterisk SIP proxy

No

407 Proxy Authentication Required 408 Request Timeout

Too many open files

SER SIP proxy

No

407 Proxy Authentication Required 408 Request Timeout 500 Terribly Sorry Server Error

Server out of memory

This attack significantly disrupts the target SIP proxy. The SIP proxy receives the requests and returns a 407 Proxy Authentication Required response. The SIP phone isn't affected because the INVITE request is not proxied to the SIP phone. The Asterisk and SER SIP proxies allocate internal resources to track the INVITE requests for which authorization is required. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to track and request authentication for all the calls.

Attack Other SIP Proxy Disruption Attacks Using the invitefl ood Tool

Popularity:

7

Simplicity:

9

Impact:

6

Risk Rating:

7

In addition to the " aggressive " attacks described in the previous sections, a number of more subtle attacks exist that are possibly less likely to be detected . For example, you could generate "bursts" of INVITE requests at defined or random intervals. You could send a five-second burst of packets every ten minutes or hour . This attack would still be disruptive, but it might be harder to detect. An example command invocation for this type of attack is

 ./inviteflood eth0 6000 10.1.101.2 10.1.101.2 50000 

Attack Target SIP Proxies with INVITE Floods Using SiVuS

Popularity:

7

Simplicity:

8

Impact:

4

Risk Rating:

6

The SIP Vulnerability Scanner (SiVuS), available from http://www.vopsecurity.org, can be used not only for scanning, but also for generating various SIP packet floods. SiVuS runs in Windows and provides a handy GUI that allows a SIP request to be defined and then sent to a target. The Utilities pane within SIP has a GUI that allows you to specify key SIP request headers for INVITE, REGISTER, and other values. You can also specify the number of requests sent. By building a request and generating, for example, 1,000,000 requests, you can repeat many of the attacks described in the earlier section "Target SIP Proxies with INVITE Floods Using the inviteflood Tool."

Figures 12-12 and 12-13 illustrate examples in which 1,000,000 INVITE requests for a nonexisting user and an existing user are sent.

image from book
Figure 12-12: Using SiVuS to target a SIP proxy with an invalid SIP phone
image from book
Figure 12-13: Using SiVuS to target a SIP proxy with a valid SIP phone

Both of these attacks create load on the target SIP proxy. Neither , however, seriously degrades the performance of the SIP proxy. SiVuS generates requests at less than 1/10 the rate of the inviteflood tool and does not vary the Call-ID and other values that need to change in order to trick the SIP proxy into treating the requests as separate calls.

Attack TCP SYN Flood Attacks

Popularity:

9

Simplicity:

8

Impact:

9

Risk Rating:

9

You can also generate TCP SYN flood attacks against SIP proxies. Because TCP isn't commonly used yet (and isn't supported by both the SIP proxies), we did not perform actual tests. We did test TCP SYN flood attacks against an Avaya Communication Manager system in Chapter 8, however. Refer to that chapter for the results.

Impact and Probability of Occurrence

These attacks partially or fully disrupt operation of your SIP proxy, meaning that someor perhaps allof your users will not be able to make or receive phone calls reliably. This could affect your customer interaction lines, customer support lines, executive lines, and so forth. As you can see, these attacks can have a serious impact on your business especially true considering that dropping even a few calls is unacceptable in most enterprises .

At the current time, the vast majority of enterprise VoIP systems are not connected to a public VoIP network via SIP trunks. Therefore, for these attacks to take place, the attacker needs access to your internal network. An attacker can gain access as a result of a user downloading a worm or virus with the ability to perform a UDP or INVITE flood or by gaining access to the internal network through another means.

The INVITE flood attack is also possible from a public network if you use SIP trunks for access to your voice service provider.

Countermeasures

You can employ several countermeasures to address these attacks against your SIP proxies. These are described next.

Countermeasurs Use TCP and TLS for SIP Connections

RFC 3261compliant SIP proxies (and SIP phones) must support both UDP and TCP. When TCP is used, SIP endpoints generally establish persistent connections with each other. For example, two SIP proxies will establish a persistent connection between themselves . Likewise, SIP phones will establish persistent connections to the SIP proxy. Because of features inherent in TCP, such as the use of sequence numbers , it is more difficult for an attacker to trick a target into accepting packet floods. A target will still consume resources processing the flood packets, but it will be able to discard them at a lower protocol layer. This, for example, would prevent a SIP proxy from ever "seeing" an INVITE flood.

For TCP to be an effective countermeasure against floods, it must be used for all SIP phones communicating with the SIP proxy. If some SIP phones use TCP, but others don't, then the security model breaks down. For example, if an enterprise uses a SIP proxy that supports TCP for some SIP phones, but not for others, then an attacker can spoof packets for the SIP phones that do not use TCP and flood the SIP proxy. Taking this example to an extreme, if the SIP proxy communicates to 10,000 SIP phones and a single one uses UDP, then if the attacker determines that endpoint, he can easily flood the SIP proxy. The fact that the SIP proxy uses TCP for "some" of the SIP phones is irrelevant.

Caution 

Attacks against TCP are still possible, however, as discussed in Chapter 6.

When TCP is used, you can also employ Transport Layer Security (TLS) (http://www.rfc.net/rfc2246.html). TLS uses encryption to provide privacy and strong authentication. TLS prevents attackers from eavesdropping on signaling. TLS also provides strong authentication, which makes it very difficult (if not impossible ) for an attacker to trick a SIP proxy into accepting packet floods. As with TCP, this means that spoofed packets will be discarded at the TLS layer and the SIP proxy will not "see" an INVITE flood. Because it uses encryption for authentication, TLS is superior to TCP alone, thereby making it even more difficult to spoof packets.

TLS is used to secure single connections between SIP proxies and/or SIP proxies and SIP phones. TLS is not an end-to-end protocol. For a call to be secure, you must employ TLS for all connections between SIP endpoints participating in the call. TLS also, of course, requires that you trust the SIP proxies that interact with the call.

TLS shares a disadvantage with TCP, in that if some SIP phones use TLS, but others don't, then the security model breaks down. For example, if an enterprise uses a SIP proxy that supports TLS for some SIP phones, but for not others, then an attacker can spoof packets for the SIP phones that don't use TLS and flood the SIP proxy. The fact that the SIP proxy uses TLS for "some" of the SIP phones is irrelevant.

Unfortunately, the Asterisk SIP proxy does not support TCP, and neither the Asterisk nor the SER SIP proxies currently support TLS. The Openser project, which is a separate branch of the SER SIP proxy, does support TLS, but it is debatable whether this or the primary SER SIP proxy offers better overall functionality. There is, however, an "experimental" tree in CVS for the SER SIP proxy and references to TLS in the code, so it appears that this function will be supported in the future.

Many of the major VoIP vendors offer support for SIP, although it is not their primary offering. Many of these implementations support the use of TCP. Some support the use of TLS. You can probably expect these "enterprise-class" SIP offerings to be more secure. However, this security can break down if you mix in components from other vendors that don't support security features.

Countermeasurs Use VLANs to Separate Voice and Data

Most enterprise-class SIP systems use VLANs to separate voice and data. While VLANs are designed primarily to assist with performance, they also provide a layer of separation and security. With VLANs and properly configured LAN switches, you can block a DoS attack from a compromised PC. MAC filtering and 802.1x port authentication are additional countermeasures. The use of softphones on PCs can defeat the use of VLANs as a security measure. When a softphone is used, packets, presumably from the softphone, must be accepted by the SIP proxy, which opens up the possibility that a rogue application can mimic the softphone and generate flood attacks. One solution to this problem is to use TLS for strong authentication to the softphone.

 Companion Web Site   It is also possible to get flood packets onto the voice VLAN if a rogue PC is added to the LAN switch port configured for the voice VLAN. Keep an eye on the http://www.hackingvoip.com website. We plan to add VLAN support to many of our tools, including the inviteflood tool.

Countermeasurs Use DoS Mitigation in LAN Switches

Many LAN switches offer DoS detection and mitigation. You can use this feature to detect various types of floods and prevent the packets from reaching the target.

Countermeasurs Enable Authentication

RFC 3261compliant SIP proxies must support digest-based authentication. This authentication can be enabled for different types of requests, such as INVITE, REGISTER, OPTIONS, BYE, and so on. For example, when authentication is enabled, if a SIP phone sends a REGISTER request, the SIP proxy responds with a 401 Unauthorized response. For INVITE requests, the SIP proxy responds with a 407 Proxy Authentication Requiredresponse. The SIP proxy provides a realm and nonce, which the SIP phone uses to calculate a digest from the username and password, which is sent along with a new request.

We highly recommend authentication for REGISTER requests, and thus this should be a best practice. You can also enable authentication for INVITE requests. Note that authentication for INVITE requests received from an external network is not practical because the SIP proxy will not have username and password information for external users.

Remember from the section "Target a SIP Proxy When Authentication Is Enabled" that use of authentication can create an additional DoS vulnerability. An attacker can send INVITE requests and never respond, causing resources to be allocated in the SIP proxy, which will remain until they timeout. The attacker could also listen for the 401 and/or 407 responses and reply multiple times, also potentially creating a DoS condition.

Countermeasurs Change Well-Known Ports

The SIP proxies allow the default SIP port of 5060 to be changed. While this is a "security through obscurity" technique, it does provide some limited protection.

Countermeasurs Use SIP Firewalls

A SIP firewall can be deployed to inspect all signaling sent to the SIP proxy. The SIP firewall can detect various forms of attacks, including UDP and INVITE floods, and mitigate them. A SIP firewall is essential when connecting to a public network. SIP firewalls are available from several vendors, including SecureLogix (http://www.securelogix.com), Sipera (http://www.sipera.com), Borderware (http://www.borderware.com), and Ingate (http://www.ingate.com). Some traditional firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS) also provide support for SIP.



Hacking Exposed VoIP. Voice Over IP Security Secrets & Solutions
Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
ISBN: 0072263644
EAN: 2147483647
Year: 2004
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net