We only need to be lucky once. You need to be lucky every time.
The IRA to Margaret Thatcher, after a failed assassination attempt.
If you really want to do something, you’ll find a way. If you don’t, you’ll find an excuse.
Jim Rohn
VoIP security can be regarded as two separate (but interconnected) challenges:
Securing a system against toll fraud (which is generally the goal of SIP-based intrusion attempts)
Securing a system against call interception (which relates to privacy, as well as improving toll fraud defences)
There are of course many other aspects to the security of your system, however most of those are general security concepts, not specific to VoIP.
In this chapter we will focus on an area of security that is too often overlooked, namely the generation and application of certificates and keys in order to secure communication between endpoints and your system. In SIP communications, encryption is optional (and, unfortunately, not used most of the time). In WebRTC, it is required.
This chapter focuses on generating keys and certificates, which we will use in upcoming chapters. It should by no means be considered the final word on securing your Asterisk system; there will be more covered in the Security chapter. We do hope, however, that it will provide you with a solid foundation on which to build a secure solution.
If you build any sort of server that is exposed to the internet, and wait for a few short hours after powering it up, you will notice that the system will have already attracted probes attempting to determine if it has any vulnerable SIP services. You will then notice, a short while later, an increasing amount of attacks on the server attempting to compromise account security. Congratulations, your server has automatically been added to lists of SIP servers shared by criminals for the purpose of fraud. If one of these intrusions succeeds, the compromised platform will likely become part of an organized crime network, with you paying the bill for untraceable calls to various expensive destinations.
We’re not playing around here; do not take your SIP security lightly or you are likely to find yourself the victim of a very expensive fraud attack.
The subscriber portion of the SIP credentials (the
'userinfo' part of the URI) is far too often set to
an extension number. This practice is fine for the purposes of
addressing calls, but is not at all recommended for the purposes of
authenticating an endpoint. The subscriber name of your endpoints should
have no meaning outside of your organization. A MAC address is perfect
for this. Without an actual address to probe, an attacker’s job just got
a lot more difficult.
You will see many SIP-type PBXs (including many based on Asterisk, unfortunately) that assign the extension number to the credentials of the phone. In this book, you will see that the extension number is not part of the phone credentials. There are several benefits to this, but from the perspective of security, the benefit is that if an attacker knows an extension, it does not provide any knowledge about how to authenticate a call through the system.
So, you might have a user with the SIP address
100@shifteight.org, that your Asterisk system will
associate with the device at
0000f3101010@yourpbx.com. When a call is directed to
'100', it will ring
'0000F3010101', but the caller never knows anything
about that endpoint.
You will see throughout this book that we will establish a relationship between an extension (which we believe is something that should be associated with a user or service) with a device identifier (which could be a SIP device, or a phone number), and that a simple table can be used to tie them together (and subsequently increase both security and flexibility).
By default, SIP messaging is passed in the clear, with no effective security. A man-in-the-middle attack is capable of obtaining all sorts of information about your calls. In order to minimize this, TLS is used.
We’ll talk more about how to configure devices to use TLS in the next chapter. All we need to do here is create the certificates.
There are three common ways to generate certificates. We’ll provide examples for two of them (self-signed and LetsEncrypt), but will leave the exercise of obtaining formally issued certificates up to the reader.
The primary advantage of a self-signed certificate is that you don’t have to validate it with any external entity. The disadvantage is that because of this, external entities will not trust it.
If you are securing SIP devices only for use within your controlled network environment, a self-signed certificate may be all you need. This is not considered the best approach, but in some cases it may be good enough, and it’s generally better than nothing.
In this world full of automated crime, there is much to learn about privacy and security, and the cryptography necessary to both, however this is a book about Asterisk, so what we are going to do is provide a template for generating the required components, and it’ll be up to you to research further.
The openssl toolkit provides a tool that’ll get the job done for us. We’ll run it as follows:
$ sudo su asterisk -
$ mkdir /home/asterisk/certs
$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \
-keyout /home/asterisk/certs/self-signed.key \
-out /home/asterisk/certs/self-signed.crt
You will be asked to provide some information, and then your key
and cert will be written to the
/home/asterisk/certs folder.
You can add the following to the command to bypass the questions (change the information as appropriate to your situation):
-subj “/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org”
The full command should then look something like this:
$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \ > -keyout /home/asterisk/certs/self-signed.key \ > -out /home/asterisk/certs/self-signed.crt \ > -subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"
This will generate a self-signed certificate and a private key,
and save them both to /home/asterisk/certs/. We can
use them later when we are configuring our SIP endpoints.
Exit the asterisk user account.
$ exit
$ who am i # You should be astmin again.
There is an alternative to using self-signed certificates: If you have a domain name assigned to your server that can be reached from the public internet, you can generate a validated certificate using LetsEncrypt. Read on.
If you are interested in secure communications across the public internet (which you are, trust us), then having domain certificates provided by a certificate authority (CA) is useful.
The LetsEncrypt project provides free Domain Validation (DV)
digital certificates. The free tool provided by the Let’s Encrypt
Foundation called 'certbot' allows you to automate
the obtaining and maintenance of trusted certificates.
At a minimum, your server will need a fully-qualified domain name (FQDN) that maps to an external IP address which arrives at the machine. Any firewall in between will need to pass traffic for that host name to the system you are obtaining the certificate for. If you cannot do this for whatever reason, the obtaining of a trusted certificate becomes more complex (and beyond the scope of this book).
Certbot can be installed with yum as follows:
$ sudo yum -y install certbot
Once installed, you simply need to run the following:
$ sudo certbot certonly
How would you like to authenticate with the ACME CA? ------------------------------------------------------------------------------- 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
If you’ve got a web server running, or are confident with option 2, that is OK, but these steps assume you don’t have a web server running, and thus will need/want to use the built-in temporary webserver that certbot will use to authenticate. This server is used to prove that you control the domain you’re requesting a certificate for.
Answer the next questions as appropriate, and then at this point you will insert the hostname that you assigned to the IP address of your server:
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): asteriskbook.shifteight.org
(replace asteriskbook.shifteight.org with the domain name you assigned).
Certbot will perform its magic, and if all went well you should get some sort of message similar to the following:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/asteriskbook.shifteight.org/privkey.pem Your cert will expire on 2018-07-23. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
You now have the certificates you’ll need for enabling various TLS services on your system. We’ll put them to use in the next chapter.
Not too difficult, eh?
If LetsEncrypt certificates do not provide the level of validation you require—for example you need Organization Validation (OV) or Extended Validation (EV)—you will need to obtain the services of a certificate authority that provides such things. Such matters are beyond the scope of what we’re going to cover in this book.
If you have worked through the examples for the Self-Signed and LetsEncrypt sections, you’ll have at least a basic understanding of some of the process of obtaining certificates from a certificate authority, as many of the steps will be similar.
We’ve secured our signalling, and that’s a good thing, however the payload itself (what’s being spoken, or the video being transmitted) is still being sent in the clear, and therefore sniff-able. To really ensure everyone’s privacy, we need to lock that down too.
Encrypting the Real Time Protocol will achieve the effect of securing our media streams.
There are two mechanisms commonly used to provide media encryption: SDES and DTLS-SRTP. SDES is a media encryption mechanism that trusts that the signalling is secure. In other words, if you are using TLS to secure your SIP signalling, then SDES is likely how your media encryption is being handled.
DTLS-SRTP, on the other hand, does not trust the signalling. It is important because the WebRTC standard requires that media be encrypted this way.
The certificates we’ve generated here should work in both scenarios. In upcoming chapters, when we are configuring SIP or WebRTC endpoints, we will cover in more detail how to use the certificates. For now, it’s enough that we’ve generated the certificates and have them available for use.
Make no mistake: Security makes everything more complicated. In the good old days, you could fire up a SIP connection with a half-dozen lines of config and call it a day. That doesn’t fly anymore, and while that type of configuration will still work (simply use UDP instead of TLS and all you need is a password), we decided that starting with this edition, all configuration examples will choose more secure options wherever possible. We’re not claiming to present the final word on VoIP security, but we are going to deliver examples that pay more than lip service to the concept.
Next up, we’ll discuss how to configure endpoints on your Asterisk system (using the keys and certificates we’ve just generated).