Contents

Introduction

Getting Started

DNS

Proxies

Gateways

User Agents

Directory Considerations

Security Considerations

Deployments

Glossary

Contacts

Related Links

Security Considerations

Securing VoIP touches on several concerns, some of which are only now beginning to be understood. They form a complex grid which we will discuss in three groups: types of attacks, basic ways of securing communications and device specific issues.

Perhaps the simplest form of application specific attack is just to register a client with someone else's identifier. The result of such a successful attack would be that the similarly registered phone would ring when someone calls the legitimate owner of the number. Any sort of rational authentication scheme will defeat this approach but it's sure to be tried, and in some cases it will undoubtedly succeed. All implementations should use at least basic authentication, even for trials.

Less obvious VoIP specific types of attacks are likely to be found, and these may be among the more dangerous. Caller-ID, for example, is often trusted on the PSTN to display the calling number accurately and, by extension, who is calling. With VoIP it does not take a high skill level to manipulate caller-ID. It can still be used to help determine whether to answer a call but should not be used to determine caller identity. There is no real "fix" as the action is not really a bug but, until users are made aware of this and similar issues, people may be vulnerable to con artists.

DoS (Denial of Service) attacks may be the most discussed. They occur when an attacker attempts to overwhelm the resources of a communication element such as a proxy with invalid requests, thereby preventing legitimate use. A generic DoS attack might be as simple as a high volume flood of ICMP requests. Such general IP attacks probably should be discovered and responded to by whatever information security mechanisms are already in place.

Application specific DoS attacks such as a high volume flood of INVITEs may need to be handled directly by the application element. Some proxies have logic in them that identifies a likely DoS attack and discard those packets. Whether such logic exists in a proxy is a reasonable question for a vendor.

As annoying as they may be, DoS attacks are known immediately by communicating parties and call content is neither overheard nor compromised. Subtler attacks may be more consequential. An MitM (Man in the Middle) attack takes place when a data stream (either signaling or media) is intercepted and re-transmitted. The intercepted signal may be stored, sent to a third party or altered before re-transmission to the originally intended recipient. If well done such an attack is almost impossible even to detect. This is in fact how lawful intercept of VoIP is expected to be accomplished. See the IETF's draft-baker-slem-architecture-00.txt

The only effective defense against an MitM attack is strong encryption for both the signaling and media streams. Before accepting the cost of end-to-end encryption though readers should weigh carefully the likelihood of interception and the consequences should that happen. Some communications may warrant expensive protection but not all will.

Moreover, encryption only guards against interception of the communication in transit. It does not safeguard either end terminal in a two-party conversation. Bruce Schneier's May 15, 2003 Crypto-Gram points out that in not a single instance of court ordered wiretaps in 2002 in the US did voice encryption prevent law enforcement from obtaining wanted information by other means. The report refers to the PSTN but there is no reason to believe it won't also be true of VoIP.

The most important other means is what Kevin Mitnick refers to as social engineering in "The Art of Deception." Social engineering isn't unique to VoIP but some of the tactics may be. For example, the machine on which a soft phone executes needs to be protected as carefully as the network over which the transmission is sent.

SIPS, a close cousin of SIP, is a good and low cost means of encryption soon to be widely deployed. It specifies TLS (transport layer security) over TCP and is not subject to bid down attacks. This means a SIPS call will fail rather than complete insecurely.

Along with cloning a registration perhaps the most likely temptation is to try and get free metered service through a SIP-PSTN gateway. Proxy software should provide a means of specifying class of service. Users not entitled to local or long distance should be prohibited at the proxy server by convenient user account configuration.

One possible tactic for free long distance is to bypass the local proxy and attempt to Asend traffic directly to the gateway. This can be prevented by appropriate ACL use discussed in the section on gateways.

The proxy, redirect and register servers all share the vulnerabilities common to any IP device and these servers must be globally accessible if calling service is to be geographically unlimited. Technically, they might be placed behind a firewall but the latency and jitter imposed is highly undesirable. Servers can, however, run host-based firewalls such as Iptables or Ipchains and such use is highly recommended. We further suggest that these servers implement a most restrictive policy and permit traffic only on ports demonstrated to be necessary.

Even if the servers are compromised some defense is possible. Basic authentication involves a secret shared between the end terminal and the database used by the proxy, redirect and register servers. The best practice is make sure this password is stored in encrypted form on the servers. It should similarly be stored in encrypted form on the end terminal. Even if an attacker gains root on the servers he still won't be able to clone a registration.

Tripwire is a utility which reports changes made to sensitive files. It can significantly minimize damage due to breakins and we recommend its use. Tripwire is included in many Linux distributions and can be obtained freely from the Internet.

Hard SIP phones may be the most vulnerable element and the most difficult to secure. Some are accessible via telnet for easy maintenance. This feature should be disabled if possible. At minimum it telnet should not be used where eavesdropping is possible and a different password should be used for each terminal to limit damage should the telnet session be intercepted. Other SIP phones appear not to handle high levels of multicast traffic gracefully. In addition, some SIP phones may be vulnerable to DoS attacks.