Asterisk: Practicing Safe SIP

As part of the installation at EMF, I need an Asterisk server to act as a gateway between the PAX and the rest of the EMF phone network to help me route calls to the right places...

Closeup of a telephone keypad, highlighting the asterisk key

Why Asterisk?

Asterisk is a bit of a "VoIP multitool" - it does pretty much everything! As well as being a SIP/RTP server, it can handle transcoding, and has rich support for developing complex applications. However, our use case is mostly routing and number manipulation.

The Strowger Exchange works on a 2-digit numbering scheme, and the EMF network is a mixture of numbers between 4 and 8 digits long.

If we end up supporting C*Net then our dialplan requirements become a bit more intricate again, and Asterisk is the easiest way for me to make that happen.

What are the risks?

I quite often hear people saying "Asterisk is a security hazard" and "just say no" - but I think that's a bit defeatist!

The problem isn't really that asterisk is particularly risky, it's that SIP is a "high value" target for attackers on the internet, and Asterisk is one of the most popular SIP servers on the planet. The threat surface looks something like this:

  • If an attacker can get SIP credentials for your PBX, they can connect to it to place calls.
  • If your PBX allows calls to the outside world, the attacker can route calls through it.
  • If they can route calls, they can use it for placing phishing calls, calling international or premium rate numbers - that you end up paying for!

For these reasons, brute force attacks against SIP usernames/passwords are extremely popular and there are readily available tools (eg sipvicious) that will scan/enumerate/brute-force for you.

We should do all we can to keep these tools out!

Mitigation

There are a few simple things we can do. We can make ourselves a tougher target, and we can block the high-volume-low-skill attacks. This won't keep out a determined/skillfull hacker, but it will significantly cut down all the noisy low-effort attacks.

Limiting our exposure

If you don't need your Asterisk to be listening on a public IP - firewall it off! For EMF, my asterisk will be behind it's own NAT router, and won't be generally listening for connections, except from specific IP addresses.

That's not always possible though, but there are some other steps we can take to keep the bad actors out...

Reducing the noise

If we can identify the tools used by the scanners, or the IP addresses of known-bad-actors, we know they're not legitimate traffic so we can just block them!

There are a couple of tools that can help us here:

  • APIBAN - This is a free tool that provides a block list of IP addresses known to be bad
  • User-Agent Filtering - Uses iptables string-matching to identify and block traffic from known scanning tools

Making ourselves a tougher target

These scanners work in two phases. First they try to enumerate usernames, and then once they've found one they try to guess the password.

We can make both these stages harder for an attacker, but using complex usernames and passwords.

The scanners all seem to go after numeric usernames, which isn't surprising, it's quite common to use a phone or extension number as the SIP username (indeed some VoIP phones can only accept numeric usernames) - by including other characters in our usernames, it makes them harder to find. Setting a complex password makes the second stage (guessing the password) much harder.

Accidental security by obscurity

Security by obscurity isn't really security, but SIP still works if you run it on a non-standard port. I've had to change the SIP port I'm using, because my home lab network already has an asterisk listening on port 5060, and that conflicts with my port forwarding.

It's not something I recommend as a security measure, but any scanner blindly spewing traffic at port 5060 won't find a sever that's running on a different port...

Some SIP settings that help too

I'm using the older chan_sip module in Asterisk right now. Not for any goot reason really, mostly inertia. I've got a couple of Asterisk servers which have quite complex sip configurations, and I just haven't got around to migrating them to pjsip yet (I just haven't found the time!) - the Asterisk server I'm using for EMF is much less complicated, but I'm being lazy and "using what I know"

After EMF I'll probably use my EMF Asterisk server as a platform for learning pjsip, but for now - this advice is for the older chan_sip settings in sip.conf

[general]
context=block-caller  ; If a peer doesn't have a context set, this is the context they end up in
allowguest=no         ; Don't allow unauthenticated SIP peers
alwaysauthreject=yes  ; Respond the same way for bad usernames as for bad passwords
allowoverlap=no       ; Disable overlap dialing support
call-limit=1          ; Restrict how many calls a peer can make simultaneously

A note about codecs

The obvious codecs to support are u-law/a-law, but I've seen test calls arriving with other codecs so I'm using this config:

disallow=all
allow=ulaw
allow=alaw
allow=g722
allow=opus

Hopefully that's enough, but I won't really know until people start trying to use it on-site!

Defensive dialplan habits

It's also good practice to follow some sensible dialplan habits. There's a really good guide in the asterisk documentation, but most people have never read it! https://github.com/asterisk/asterisk/blob/master/README-SERIOUSLY.bestpractices.md

The first point on that page is about filtering input that came from the outside world, but there's one situation that it misses. The EXEC and SYSTEM dialplan commands spawn an executable shell environment, it's especially important you're careful about what you pass to them.

You wouldn't want the caller-id/shell-exec equivalent of Little Bobby Tables to come calling!

Useful Tools

Debugging SIP can be a bit of a pain

It's tempting to use a packet capture tool (eg tcpdump, wireshark or tcpshark) but sngrep is a SIP specific packet capture tool, with a really nice text mode interface. It makes inspecting a SIP conversation really easy!

Conclusion

A barely configured Asterisk box can be a bit of a security nightmare, but by taking some simple steps we can make it much better behaved!