VoIP hacking all around! READ THIS AND APPLY

A number of South African big business VoIP servers have been hacked recently and run up gigantic bills so I decided to share what we do to ensure VoIP does not get a reputation as insecure.

Most of the companies that were hacked used ON SITE PBX which means you are not safe even if you have no WAN side exposure on your box. None of our systems have been hacked yet so I suggest you follow our lead. If anybody has any further suggestions please add them in the comments below. The steps I'm about to mention will only apply to companies running Linux based Asterisk boxes.

1) Install and ensure Fail2Ban is working. Fail2Ban locks unauthorised users out of SSH, GUI and Webmin after 3 unsuccessful attempts by placing them in a jail. The only way to regain access is to remove them from a jail. FreePBX systems (other than PIAF) DO NOT include this by default. This is your first line of defence. http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

2) Do not use common or easy to guess passwords for ANYTHING. Use a mixture of upper and lower case and symbols e.g. Wh0@r3you?_6581 . Every extra digit increases the complexity exponentially. Use a password generator like LastPass if you are not creative

3) Only open ports that you must have open. Close any unused ports e.g POP3, IAX2 etc if you are not using them. It is pointless to change your SSH port because an NMAP scan will pick it up anyway.You can try and change SIP port to something other than 5060 though as this is a commonly targeted port.

4) Disable root login on SSH. Let users authenticate with their normal user login and pass and the SU that will require a root level password. This doubles the security on SSH.

5) Use a separate outbound route for all international calls that has a dial plan that matches 00. then pin protect it. Give the client CEO the pin and let him decide who has access to it.

6) Limit the maximum length of any phone call by adding this to your Asterisk Dial setting: TtL(14400000) , This will limit all calls to 4 hours. The problem is that most providers such as ECN only bill you once the call is terminated. This means if your system is hacked you can easily get a R100,000 bill even though you only have R10,000 credit. This is the common method used to places like Sierra Leone and the Ukraine where premium rated numbers are dialled that cost R30 per minute....

7) Use a prepaid rather than postpaid system. If they do get past all of these settings they can only take you for what you have loaded e.g R1000 or whatever.

8) Use an intermediary gateway such as a session border controller (if your providers has this) and only allow RTP over UDP from this specific IP. This way even if they hack your system and have full access they cannot make calls.

9) Install pinsets for international calls.

Lastly:
10) Ensure your firewall is perfectly secured by having at least the following in your IPTABLES. (save the content below as a .sh file on your Linux box and make it executable by using chmod 755 filename.sh. Then run the file. Do NOT run the commands individually (especially the first one) as you will lose access to your system unless you are sitting at the server itself directly)

Start shell script:

#!/bin/sh
#
# A shell script used to setup rules for iptables.
# Wipe the tables clean
iptables -F


# INPUT SIDE
# Accept all loopback input (localhost)
iptables -A INPUT -i lo -p all -j ACCEPT

# Set default policies for INPUT, FORWARD and OUTPUT chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Reject spoofed packets
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -s 208.51.62.130 DROP
iptables -A INPUT -s 142.4.204.0/24 DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP

# Stop smurf attacks
iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp -m limit --limit 1/second -j DROP

# Drop all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

# Drop excessive RST packets to avoid smurf attacks
iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT

# Attempt to block portscans
# Anyone who tried to portscan us is locked out for an entire day.
iptables -A INPUT -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP

# Once the day has passed, remove them from the portscan list
iptables -A INPUT -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove

# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

# Allow the following ports through from outside

# SIP on UDP port 5060. Other SIP servers may need TCP port 5060 as well
iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 5060 -j ACCEPT

# IAX2- the IAX protocol
iptables -A INPUT -p udp -m udp --dport 4569 -j ACCEPT

# IAX - most have switched to IAX v2, or ought to
iptables -A INPUT -p udp -m udp --dport 5036 -j DROP

# RTP - the media stream
# (related to the port range in /etc/asterisk/rtp.conf)
iptables -A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT

# Allow the three way handshake
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# smtp
iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

# http
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

# https
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

# ssh & sftp
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# Deny pings through
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP

#Block access for account scanners like 'User-Agent: friendly-scanner' NOTICE: The rules must inserted into the chain at the front to make them work properly. (If you want to merge the rules #into you ruleset make sure they are chained before iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT )

iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -m recent --set --name VOIP --rsource
iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "REGISTER sip:" --algo bm -m recent --update --seconds 60 --hitcount 16 --rttl --name VOIP --rsource -j DROP
iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "INVITE sip:" --algo bm -m recent --set --name VOIPINV --rsource
iptables -I INPUT -p udp -m udp --dport 5060 -m string --string "INVITE sip:" --algo bm -m recent --update --seconds 60 --hitcount 16 --rttl --name VOIPINV --rsource -j DROP
iptables -I INPUT -p udp -m hashlimit --hashlimit 8/sec --hashlimit-mode srcip,dstport --hashlimit-name tunnel_limit -m udp --dport 5060 -j ACCEPT
iptables -I INPUT -p udp -m udp --dport 5060 -j DROP

# Allow established routes to remain open from the outside
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Kill all other input
iptables -A INPUT -j REJECT

# Output side
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow the following ports through from outside
# smtp
iptables -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT

# DNS requests
iptables -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

# DHCP/Bootstrap Protocol Server
iptables -A OUTPUT -p udp -m udp --dport 67 -j ACCEPT

# http
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

# https
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

# ssh & sftp
iptables -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

# Allout pings out
iptables -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Kill all other output
iptables -A OUTPUT -j REJECT


# FORWARD SIDE
iptables -A FORWARD -j REJECT

#Script end

These are the only things that I can think of for now but if you have stuff to add please do so! We need to assist one another to protect our environments.

Very helpful thanks!

Would Elastix be affected?

Yes Elastix is quite insecure as the development base is not very active. If you have trouble applying any of these steps PM me and I will gladly assist.

Superspeed said:

Yes Elastix is quite insecure as the development base is not very active. If you have trouble applying any of these steps PM me and I will gladly assist.

Click to expand...

sigh, can't even visit government websites these days without getting malware. R140 million virus hosts

Great Post! Thanks

Most of the companies that were hacked used ON SITE PBX which means you are not safe even if you have no WAN side exposure on your box.

Click to expand...

I don't understand how boxes that are not exposed to the internet are vulnerable? My experience with hacked boxes has always involved poor or no firewalling attached to the internet.

Something else to add to your defence list is to set complex sip passwords for your extensions and to also set the permit/deny IP range to only match your LAN subnet.

Hi

Also Do not set up or use DISA.

Worth reading if you use a Fotigate and a SIP server on the internet: http://mybroadband.co.za/vb/showthr...bound-connections-on-outbound-only-SIP-policy

Excellent post and tips will help a lot of people thanks OP!

What about 2fa options for log in?

The easiest iptables and the most secure is as follows providing you don't access your onsite PBX remotely with soft phones which you shouldn't do anyway unless you use a secure VPN. If you have a remote pbx or a softphone that has a static ip address then the below rule can also be used with all the static IP's you wish to allow in.

Port 5060 deny rule
iptables -t filter -I FORWARD -d (IP OF PBX) -p udp --dport 5060 -j DROP

port 5060 allow (only from your service provider sip server)
iptables -t filter -I FORWARD -s (IP OF PROVIDERS SIP SERVER) -d (IP OF PBX) -p udp --dport 5060 -j ACCEPT

This works like a bomb and unless your own provider is trying to hack you you are safe. PS the DROP rule must be before the ACCEPT rule.

michaelmcse said:

The easiest iptables and the most secure is as follows providing you don't access your onsite PBX remotely with soft phones which you shouldn't do anyway unless you use a secure VPN. If you have a remote pbx or a softphone that has a static ip address then the below rule can also be used with all the static IP's you wish to allow in.

Port 5060 deny rule
iptables -t filter -I FORWARD -d (IP OF PBX) -p udp --dport 5060 -j DROP

port 5060 allow (only from your service provider sip server)
iptables -t filter -I FORWARD -s (IP OF PROVIDERS SIP SERVER) -d (IP OF PBX) -p udp --dport 5060 -j ACCEPT

This works like a bomb and unless your own provider is trying to hack you you are safe. PS the DROP rule must be before the ACCEPT rule.

Click to expand...

I believe your rule is flawed:

1. your service SP does not register to you, you register to them - same principal as being behind router, for you to receive and make calls you do not have to open any ports unless you want remote access.
2. IP's can be spoofed, so a clever hacker would spoof IP of SP, and because you are not blocking number of attempts over time period he can try all his saved un and pwd as well as guest and anonymous without being blocked.

by dropping packets to 5060 you are basically telling the would be hacker that there is a server onsite, any hacker will also test for vulnerabilities on port 80 and 22 too.

best practice is to not expose to www, but if you have to like in a hosted environment disable guest and anonymous, change ports out of known range and install firewall that silently drops packets, or you can just run a deny all rule and allow known ranges or ip's

it is guaranteed that your server when exposed to the internet will get tested within an hour of going live

Of course the easiest way would to NOT use VoIP ! :crylaugh:

And expose yourself to other methods of fraud! :twisted:

Yes you send the request out but if the IP responding is blocked then it cannot communicate with the system. Tried and tested. I still have failtoban and the new asterisk firewall enabled which locks out after 3 failed attempts. Let's say somebody spoofed the IP which A is hard to do and B good luck to them finding the providers sip server IP but regardless the packet may be accepted in but the response would via DNS go to the providers server since it will be the one listed at said IP and so the connection would be incomplete.

Subscribed , very interesting thread

At OP

How secure are consumer VOIP services ?
I recently signed up for Vox Vobi.
I use a mobile app on my smartphone.

Can I be hacked and then someone run up the voip usage on my account?

If you are using Asterisk with FreePBX and default settings, then chances are you have transfers enabled and also the option that allows the calling party to transfer calls (T).

There is a method of fraud doing the rounds where the thief will dial in and once someone answers the call they will initiate a transfer, this will disconnect the call and allow them to dial any number (providing your dial-plan allows it). The destination will be a premium rated number in a remote country. The person who answered the call often thinks nothing of it, till the bill arrives at the end of the month.

Suggested fixes: Disable international dialing, or at the very least enable pin codes and limited destination countries. Disable the T option in Dialing options in the FreePBX GUI. Train your reception and other staff to report strange telephony behaviour.

You can read more here: https://community.freepbx.org/t/hacker-makes-international-calls-through-my-freepbx-ivr/34334

you are making a issue out of nothing, if you read the post completely you will see that this function has been available since pre 2.5 and has already been addressed by the developers where this is disabled by default, messing with the features codes is going to break internal transfers. https://issues.freepbx.org/browse/FREEPBX-12058

The fix to remove it as default is only a year old and there are still enough people running older versions. It's also possible (haven't checked yet) that if you're upgrading the new defaults won't get applied, only fresh installs.

Also just because something has been around for a long time doesn't always mean it gets exploited immediately. The original default with T enabled is actively being exploited at the moment, so it's worth informing people.