Secure sip


VoIP Security Issues

Asterisk FreePBX protection is not included with one button and should be systematically built at all levels, starting with the network layer (iptables, fail2ban, IPS) and ending with the correct configuration of the dial plan. Like any network application, VoIP-service is vulnerable for many kinds of attacks, but it has its own specificity. “Call tampering” attack (DDoS type) can be implemented by sending empty packets, for processing them the asterisk service will spend resources, this will lead to delays, and the conversation will become impossible.

To implement MITM, attacker does not have to be on the same network. Possible he will just change the DNS record or intercept the session (SIP registration hijacking). Since SIP uses UDP, this simplifies the attack. The attacker wedges into the process of connecting to the server, sending fake information about the client in the SIP REGISTER package, and is registered on behalf of the user. In the future, he passes all traffic through himself. Further processing also does not cause problems – many sniffers (like Cain & Abel) are able to extract audio and save to WAV or MP3 format.

Hacking VoIP is one of the most convenient ways to monetize. So, having found a mistake in the service (vulnerability or wrong configuration), an attacker can make calls to paid services, sell VoIP traffic or send spam. From our experience there are a lot of such incidents from different companies using Business PBX based on Asterisk. The new advanced sophisticated hack methods based on social engineering also can be exploited. So, due to weak sip security or improper configuration VoIP-service can cause serious financial losses.

Ensuring the safety of the Sip VoIP service

Traditional firewalls can not fully resist specific attacks, because they work at the transport level and do not know how to inspect each packet. Here we need specialized solutions related to the class NGFW (Next-Generation Firewall). Today they are represented by such vendors as Check Point, Fortinet, Certes Networks, SonicWall. Although, for example, freely distributed IPS Snort / Suricata already have a number of rules that allow you to recognize attacks on VoIP. As for the MITM attack, the protection against it has long been debugged. This is a test of the MAC address on the firewall. Encryption methods (VPN, TLS/SSL, SRTP (Secure Real Time Protocol)) and correct password policy allow you to protect yourself from authentication attacks (like brute force). To ensure server performance, recommended SRTP (RFC 3711), which allows you to encrypt (AES) media stream and provide defense of information. All conversations are encrypted, and the key pair is generated automatically for each session, which is very convenient, since it makes it easy to integrate this mechanism into existing products and does not require the PKI infrastructure.

TLS configuration in sip.conf file:


Now the connection is secure and you can not spy the registration data, although the conversatons themselves are not encrypted. The native protocol for Asterisk, like SIP, can be configured to support SRTP encryption (AES128). To do this, add only one line to the sip.conf configuration file: encryption=yes.

Attempts to find passwords for SIP accounts have long been common issue, especially since ready-made tools are freely available, and a simple script is written for the day. For example, a set of SIPVicious utilities allows you to obtain SIP lists in the specified IP range, extensions and passwords. Guest calls are disabled in sip.conf in one line: allowguest=no.

The server, in the case of a connection request error, sends one of the following messages:

  • 401 Unauthorized – unauthorized access (only registration servers);
  • 404 Not Found – user not found;
  • 404 Unknown user account – unknown login and password;
  • 407 Proxy Authentication Required – authorization is required for the proxy server.

You can complicate the task for attacker by forcing the server to issue the same error (401 Unauthorized) in all cases, for this you need to record: alwaysauthreject=yes.

Many specialized and manual scripts just test the connection on 5060 and, if it’s closed, ignore the node. So it recommended to run asterisk chan_sip on other port instead default 5061 and 5060 UDP. Other solution is whitelisting only specific IP addresses or ranges (for example sip providers IPs).