The relevance of SIP Domains
When a SIP request is sent to your Asterisk server, the main header should contain a Request URI (or R-URI) that looks somewhat like one of the following:
sip:
[email protected]
sip:
[email protected]
sip:
[email protected]
In each case, the destination is defined as a number then the @ symbol and finally the “SIP domain”. In the first two examples, the SIP domain is given as a host name and would have to be resolvable by public DNS servers to be useful. In the third example, the sip domain is given as an IP address – it would therefore need to match the IP address of your Asterisk server (or perhaps the external, or WAN, IP address of your NAT router if behind NAT).
Asterisk can be configured to be indifferent to SIP domains or you can specify a list of “allowed” domains that it will support.
A benefit of SIP domains
Activating support for SIP Domains in Asterisk can give you one more layer of security, but it will only be effective if you can:
Avoid having your PBX’s Internet IP address as one of the domains, and
Set the parameter allowexternaldomains = no
Doing both of the above will cause Asterisk to reject all SIP requests where the R-URI is using the external IP address of the PBX rather than a legitimate SIP domain – one that you have configured and approved. Since most hacking attempts are based on IP address only, this could be a useful extra layer of protection for your server.
A potential pitfall with SIP domains
Every silver lining has a cloud and so it is with SIP domains. All the advice offered in part 2 about checking which dial plan will be used for inbound calls can be rendered invalid if you have defined a sip domain with the additional optional parameter, context, appended on the end. For example:
sip.conf
[general]
domain=mysipdomain.com,mycontext
Any request sent to your Asterisk server where the R-URI is using the above sip domain, will use the dial plan configured for the context called mycontext. I would recommend avoiding using the additional parameter when defining a sip domain in Asterisk because it could act like a hidden back-door that is easy to overlook.
Automated-Attendants, DISA and other risks
The vulnerabilites discussed so far have mostly involved quite technical weaknesses, especially related to malicious SIP requests arriving over the Internet. However, it is also possible to leave the door open for mis-use through the menus and options that are offered to ordinary callers. Features that are very convenient for legitimate users can provide a route in for hackers, especially if weak passwords have been used. You would be ill advised to assume that a “hidden” menu option known only to employees will never be found by a potential hacker – there are only 12 keys on a telephone key pad so it doesn’t take much effort to try all twelve at various points in the caller menus.
Areas to watch include Automated-Attendants, voicemail access, follow-me and call forwarding options, DISA or any similar trunk-to-trunk callout feature.
Protecting against Denial of Service attacks
Asterisk is good at many things, but handling a lot of simultaneous requests is not one of them. It would be relatively easy to overwhelm most Asterisk servers by bombarding them with a lot of SIP requests in a short space of time. Restricting access at the firewall is the best solution because it stops the requests before they reach Asterisk, but it is not always an option. Correct use of security parameters within Asterisk such as “allowexternaldomains” and “allowguest” can help deflect unauthorised requests before they demand too much processing, but once again it may not always be possible to use them. So how might it be possible to protect your Asterisk servers against Denial of Service attacks if the aforementioned options are not available or are not adequate?
OpenSIPS as an intelligent firewall
One possibility would be to use an OpenSIPS server as a barrier between the Internet and Asterisk. OpenSIPS is able to handle much greater demands in terms of requests per minute and is also able to inspect SIP requests in great detail to determine if they are valid or malicious. In this scenario, the OpenSIPS server would be accessible from any address on the Internet, but the Asterisk server would only accept connections from the OpenSIPS server. This configuration also has the advantage of being scalable – if one Asterisk server is not enough, you can add more behind a single OpenSIPS server which will load balance requests across all the Asterisk servers.
Fail2ban
Another option to consider is the use of Fail2ban or a similar add-on product. Fail2ban is an open-source product that will dynamically modify the rules in an iptables (or similar) firewall based on the number and frequency of unauthorised access attempts made from a given remote address. It works by constantly monitoring the Asterisk log file – or other log file – to identify brute force attacks. Parameters can be configured to adjust settings such as how long to block the remote address, how many failures before it should be blocked, etc. It comes with standard rule sets and templates that will work with a number of commonly used applications, but you can also configure your own rule sets to cope with unsupported applications.
Link: Click here to visit the Fail2ban web site.
Stopping a “friendly-scanner” DoS attack
One form of attack that has been widely reported (and which may even be made more likely if you use settings such as “alwaysauthreject=yes”) is an intense and endless stream of REGISTER requests sent from one source address on the Internet and using the “friendly-scanner” user agent name.
Summing up
The level of risk has certainly intensified in the last year or possibly even the last few months and there is little doubt that the unwary will get caught and will end up paying for someone else’s phone calls to weird and unlikely destinations like North Korea or Ethiopia. Once an unsecured PBX has been found, it is likely to be hit with hundreds of expensive calls and very large bills can be run up in a matter of hours. This is not a problem to be taken lightly – it could even sink a small business.
You cannot seriously expect protection or redress from the authorities or the Telcos – you would be extremely lucky to get more than passing sympathy from either. Protecting your PBX is therefore up to you, your PBX maintainer and IT support team. If all Asterisk PBX’s were locked down and properly protected then the hackers would soon lose interest and look for other ways to make money, so make it as difficult for them as you can. Make sure all your passwords are very strong, that you have set “alwaysauthreject” to yes and check all the other points raised in these articles.
