Asterisk is the telephony engine used in one of our most popular products, A2Billing. However, the nature of A2Billing is that it does normally have to be exposed to the internet.
Whenever we do installations of A2Billing, we see attacks via SIP occurring within a few minutes of installation, probing for access.
On a properly configured system, with security in mind, these attacks are nothing more than a minor annoyance, but a concerted attack, or more than one hacker attacking the VoIP system at the same time can result in high network, processor, and memory loads, which can affect your customers as well as call quality, so there are a number of facets to protecting your Asterisk server.
Dial-in Attacks
This is where a hacker launches calls at your system, in the hope of discovering a way of accessing Asterisk so that secondary calls can be made. This has been a popular fraud for years, preceding even VoIP.
Many PBX system have a DISA (Direct Inwards System Access) entry, whereby someone knowing the DISA number could then dial a code and get an outside line. Often, the code was not changed from the default, resulting in massive telephone bills for the PBX owner. Do note that voicemail systems also come configured with DISA.
Even large calling card companies were not immune, in the early days, calling card numbers were not random, or they were only six digits, given a computer and the ability to dial at high speed, it did not take long to make toll-free calls. By default, A2Billing’s calling card numbers are 10 digits long and randomly generated.
For the switch admin, the annoyances are spurious CDR, logs, and stress on the system, assuming no route has been left to get access to make outbound calls.
Defences are to only allow inbound calls from trusted sources, and only to DID you own, hanging up any calls immediately, rather than playing “this number is not in service”
SIP Scanning
This takes the form of trying to register an extension to your system, and using brute force to identify the username and password.
With it’s default settings, when a SIP peer tries to register, Asterisk will either reply with “That extension does not exist” or “That extension does exist but you have not got the right password”
This answer will then tell the hacker to start testing passwords, and thousands can be tried every minute, so unless you have a password made up of many random numbers and letters, it’s only a matter of time before the password is cracked.
There are a number of defences against this attack:
- alwaysauthreject = yes; when the password is wrong, this says sends the reply “that extension does not exist” even if it does exist, the idea being that the hacker moves on to the next extension, then finally leaves your server for the next one.
- Domain = your FQDN; this means that Asterisk will only allow registration if the domain is correct, registration is not allowed via IP address. The domain can be looked up remotely, so it is only a road hump, but does help protect against automated scanners. Replace your FQDN with your fully qualified domain name.
- Complex secrets and passwords; Do note that some endpoints do not accept characters other than a-Z and 0-9.
- Deny and Permit; Limiting the IP addresses that can connect to the PBX. e.g. if all your extensions are internal to the office network, and no one has to connect remotely, then you can Deny everything (deny = 0.0.0.0/0.0.0.0) and permit only your internal IP range, (permit = 192.168.1.0/255.255.255.0) or a single IP, 192.168.1.200/255.255.255.255
- IP-Tables; we will cover this in more detail later.
- IDS; Intrusion detection system such as OSSEC and Fail2Ban.
IDS Systems
Common IDS systems include OSSEC and Fail2Ban. These systems monitor log files looking for suspicious behaviour, such as a number of wrongly entered passwords in a short period of time.
There are drawbacks with this system in that a determined attack will produce so many logs that the IDS will use all the processor, memory and IO parsing the logs, allowing the hacker thousands of attempts before the IDS finally blocks the attack with iptables.
The default rules also allow a number of attempts, so attacks can be timed not to trigger the IDS or as soon as the IP is blocked, the hacker can resume the attempt from another IP address.
Having said this, they do have a valuable place in security, but some iptables to block the more obvious attacks to take the load of the IDS is a good start.
SIP Specific IP-Tables
There are a number of rules that can be included in your iptables to stop attacks in their tracks before the measures mentioned above come into play.
Block Common Attacks
Most attacks are from freely and widely available software, and include the name of the software in the SIP message, as many amateur hackers do not bother to change this. Recognising and blocking the most popular names will cut down the number of attacks.
Examples of the names popular SIP hacking tools present include:
- friendly-scanner
- VaxSIPUserAgent
- sundayddr
- sipsak
- sipvicious
- iWar
- sip-scan
- sipcli
These can all be blocked with an iptables rule such as:
iptables -I INPUT -j DROP -p udp –dport 5060 -m string –string “insert above name here” –algo bm
Rate Limiting
You can use iptables to limit the rate at which SIP messages can be sent from a single device, this gives less time for the attacker to do brute force attacks, and stops the load being deferred to your IDS system. Rules as follows could form a good basis.
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –set
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –rcheck –seconds 3600 –hitcount 100 -j DROP
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –rcheck –seconds 600 –hitcount 20 -j DROP
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –rcheck –seconds 300 –hitcount 10 -j DROP
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –rcheck –seconds 180 –hitcount 5 -j DROP
iptables -A INPUT -p udp –dport 5060 -i eth0 -m state –state NEW -m recent –rcheck –seconds 60 –hitcount 3 -j DROP
This will drop registration attacks if they come in too fast, so normal phones should be fine as they do not produce too many registration attempts.
Geographical IP-Tables
There is no point allowing people from other countries around the world to attempt to register to your Asterisk system if there is no good reason for an endpoint to register from anywhere.
There are a number of websites that will give you the ranges of IP addresses for different areas around the world which can be incorporated into your iptables.
A disadvantage is that these iptables can take a long time to apply for the first time, but even though there may be thousands of entries, once setup, they operate with no noticeable lag as generally you would only have the iptable rule triggered on “NEW” connections, not on “RELATED” or “ESTABLISHED” connections.
This rule can be taken further if SIP peers are connecting from home, it should be possible to set up iptables to only allow connections from their ISP’s IP range.
Clearly this does not block everyone, but does dramatically reduce the number of people who can attack your server, leaving the IDS free as the second level of defence for those hackers who, by coincidence, are on the IP address range you have allowed.
Conclusion
There are other areas of attack, for instance, as yet undiscovered vulnerabilities in the various components of your system, but there is little that can be done about these, other than ensure that all software is up to date, and watching the security advisories. The steps mentioned above will reduce your attack surface area.
Also bear in mind that if you have clients registered to your system, they may be insecure, and if hacked, could pass traffic through your system. The only defence against this is to mitigate the damage, usually by setting a concurrent call limit and blocking all destinations that your customers would not use in their normal course of business.