10:45 AM
dao viet dung
A growing problem
Like a slice of Victoria sponge cake on a summers day attracts wasps, so new technologies seem to attract the attention of cyber-criminals. The more widely used the technology, the greater the interest. It was inevitable, and widely predicted, that VoIP would become a favorite target for hackers as its popularity and uptake increased – it has the accessibility of an email server combined with the potential for fraud of an online bank account. Irresistible!And so it has come to be. The level of sophistication and the number of attacks against VoIP servers and PBX’s has gradually escalated over the years and then really taken off in the last 12 months. Automated port scanning and security probing can be seen many times a day, even on IP addresses that are not part of any published SIP service. What is more, each new attempt seems to come from a different IP address! This makes it harder to just block them at the firewall and indicates that the would-be hackers are using a botnet. Another possibility is that the source address is being deliberately spoofed. This would make it difficult to detect the true source address which is masked by the “noise” of many randomly generated addresses. Whatever the mechanism, it suggests that the hackers are really serious about their undertaking and expect to make a lot of money out of it.
What are the hackers hoping to do?
In most cases they want to find a weakness that will allow them to make long distance, international or other chargeable calls for free. The numbers that get called are often in African countries, but I have also seen North Korea and others. One service provider told me that China is a popular destination. This is often described as “toll fraud”. In some cases, the fraudster is reselling the hijacked call time from your server to unsuspecting end users who think they have signed up to a legitimate call service (or who don’t care if it is legal as long as it is cheap). Alternatively, the numbers being called are on a premium rate service – this allows the fraudster to collect part of the call charges directly to their own bank account.Another possibility for an attack on your systems would be DoS (Denial of Service). Asterisk servers are not that good at handling floods of SIP requests, so once someone has identified your server it would be relatively easy for them to fire hundreds of requests at it with the intention of bringing it to its knees. Deliberate DoS attacks are not common compared to toll fraud. However, brute force password guessing can have the same impact as a DoS attack – see “password guessing gone crazy” below.
Toll fraud is clearly the main issue today. However, the time may come when unwanted spam calls (enjoying the delightful acronym of SPIT) are as big a problem as toll fraud. When that happens, it will present administrators with a whole new set of problems.
What do the attacks look like?
SIP port scanning – locating target servers
Port 5060 is the standard SIP port and the first step for the would-be hacker is to send a SIP request to this port to see what response comes back. If you can use a non-standard port or block all access at the firewall except from addresses known to be trusted, then it will elevate your protection to a completely new level. However, for most VoIP applications this is simply not possible.Probing requests may come in the form of a SIP INVITE, REGISTER or OPTIONS request. I have recently seen a big increase in OPTIONS requests that come from a wide range of Internet IP addresses, but they contain certain elements that identify a common ancestry. First, all the requests have the User-Agent field set to either “sundayddr” or “friendly-scanner”. Second, they often identify their origin as ”sip:100@1.1.1.1″, “sip:100@192.168.1.9″ or similar. It may not be possible to block or even detect these if you are using an Asterisk server, but in OpenSIPS, I recommend that you drop the packet rather than send any response.
Password guessing
Once a SIP server has been identified, vulnerabilities can be searched for. I have seen Asterisk logs that clearly show an initial scan where an attempt is made to register on every extension number from 10 to 9999. The response coming back tells the attacker if that extension exists (bad password) or does not exist (not found). Then, armed with a list of your extensions, the second phase of the scan will keep trying hundreds of passwords on a known extension.Password guessing gone crazy
Under some circumstances (possibly when Asterisk is more tightly locked down than usual) the password guessing attack seems to get stuck in an endless loop. It sends REGISTER requests for various randomly named accounts in a relentless and unceasing stream at a rate in excess of 80 per second. I have written an article dedicated just to this one problem and its solution. Click here to be linked to the relevant article.Open relay
If the SIP server has been configured by an inexperienced person who perhaps did not appreciate the risks, then the worst case scenario would be that your Asterisk server will accept INVITE requests from any Internet address without any password being required and connect the caller to destinations on the PSTN. I’m glad to say that Asterisk, Trixbox or FreePBX will not generally do this “out-of-the-box”, but it would be easy to tweak the dial plan such that it could. For many years, I have seen evidence in the logs of SIP requests to numbers on the PSTN, often with various prefixes, in the hope that they will hit the jackpot.Weaknesses in the server
This form of exploitation is more likely with OpenSIPS than with Asterisk because the rules and routing logic in OpenSIPS are almost completely under the control of the installer and system administrator rather than the authors of the product. With a protocol as complex as SIP, there is plenty of scope for missing some detail or assuming a function behaves one way when it actually behaves in some subtly different manner. One of my clients was caught out by a weakness in the handling of deliberately malformed From headers. A function that should return true if the SIP domain is local would return false when the caller’s number was missing. This meant the calls were not being challenged for a password yet would then be handled as if coming from an authenticated user. Such mistakes can be very costly.The human factor
Remember that not all IT fraud takes the form of a unknown third party hacking into your systems from the Internet. A disgruntled or dishonest employee finding they have access to account passwords or the ability to add a hidden access route, may be tempted to exploit their position of trust. As a VoIP service provider, you may find you are approached by clients who talk of temptingly large and growing volumes of traffic that they want to put through your service. They might be very believable and indistinguishable from a legitimate client, but it may not always be what it appears. Your billing systems need to be able to stop traffic from a client whose credit limit has been reached. And always get advance payment for your minutes!Protecting your Asterisk server
In part 1, we examined the techniques that are used to probe for vulnerabilities in a SIP server and reviewed the types of exploitation a would-be hacker hopes to use. In this second part, I look at the ways you can protect your Asterisk or other SIP server and guard against weaknesses that could potentially cost your organisation a lot of money.Basic Internet Security
The first line of defence is your firewall. You must block all unnecessary access from the Internet which generally means everything except port 5060 and the range of ports used for RTP. You will probably also need a rule to permit remote access – typically port 22 for SSH – but if at all possible set all remote access rules so they only allow connections from known source addresses. If you do allow remote access from the Internet of any sort (including through a web browser) then make sure you set a strong password. Never leave the original system default password on any system exposed to the Internet.As mentioned in part 1, you can greatly improve security by changing to a non-standard port for the incoming SIP or by blocking access to port 5060 from all sources except those you already know and trust. This might be possible in a business that wants to connect a number of branch offices together using VoIP. However, it is far less convenient if you want to allow home based workers to connect to the office PBX using IP phones. For some applications it may be possible to connect through a VPN tunnel, but beware of possible performance issues if the speech (RTP) is going through VPN.
Check logs regularly
Even if you have a smart billing or call logging system, it is sensible to check the application log files quite often. The main log file for Asterisk is either /var/log/asterisk/messages or /var/log/asterisk/full. It is here that you might see hundreds of failed register attempts from the Internet. This may provide essential information in your fight against hackers because it shows you the scale of the problem, the accounts they are trying to crack, the type of attack and, sometimes, the IP addresses that the attack is coming from (the worst offenders can then be blocked at the firewall).SIP User Accounts
Call requests arriving at your Asterisk server will generally need to be validated with a user id and password. There are exceptions to this rule, most notably when the request comes from a pre-defined peer whose definition in sip.conf includes a setting such as ”insecure=invite”.Use strong passwords
To protect your Asterisk server from brute force password guessing attacks, always make sure all your SIP user accounts have a strong password – at least 6 chars with a mix of upper and lower case letters plus numeric digits and at least one non-standard character such as $, !, #, *, etc. However, note that a few special characters will not work – avoid & or %. The importance of using strong passwords cannot be over-emphasised. It is essential even when you are setting up the accounts for internal extension phones because, unless you are very careful, the same credentials will work for calls from the Internet. To check the list of user accounts and passwords in Asterisk, it sometimes works to run the command “sip show users” at the CLI.Other cautions when adding SIP User Accounts
Never include the parameter “insecure=invite” or “insecure=very” when defining a dynamic SIP user account. If you do, it will disable password checking for that account. Where possible, restrict the range of IP addresses from which the user is allowed to connect using the “deny” and “permit” parameters. This is a good idea where all possible source IP addresses are known in advance such as from a local LAN in an office. If possible, avoid setting the type to “friend”. Instead use “type=peer” and “host=dynamic” (see below).Configuration tip:
In the [general] section of sip.conf,
set “alwaysauthreject=yes”. This makes it much harder for a hacker to
scan your server and identify what extension numbers are being used
because it tells Asterisk that when the supplied credentials are wrong
on an INVITE or REGISTER request, it should always return the same error
no matter whether it was the user id or the password that didn’t match.
However, it may also cause the so-called “friendly-scanner” to go into
an endless cycle of manic password guessing – if you suspect this is
happening to you, then you need to read my article here.
Outbound Routes
If you are using FreePBX (or a package based on it), then you should look carefully at the configuration for “Outbound Routes”. It makes sense to add a route specifically for International calls and, if possible, to restrict the countries that can be called. You can do this by adding a number of “Dial Patterns” that match the countries you want to allow and do not match any others. Make sure no other Outbound Route has a Dial Pattern that allows International calls.A variation on the above would be to set a “Route Password” on the route that handles International calls or to have two Outbound Routes for International calls – one having no password but restricted to certain acceptable countries and another that has a password and is used for all other International destinations. Note that Outbound Routes are checked in sequence so you must put those with a dial pattern matching specific countries first, then put one with a Dial Pattern that works as a catch-all for any other International destination.
On its own, controls on the Outbound Routes may not be sufficient to fully protect your system, but it is a big help and acts as a second line of defence behind the user accounts.
SIP Peers
When Asterisk receives a SIP INVITE request, the sender will broadly fall into one of three categories:- Those from a dynamic IP address which have to authenticate with user id and password
- Those from a “trusted” pre-defined IP address (authentication by password is optional)
- The rest.
Name/username Host Dyn Nat ACL Port Status voiptalk/801234543 77.240.48.94 5060 OK (23 ms) smartvox/221221 114.32.159.2 5060 OK (27 ms) sipgate/7654567 217.10.79.23 5060 OK (33 ms) sipbroker 64.34.162.221 5060 Unmonitored myopensips-in 192.168.0.116 5060 Unmonitored 2001 (Unspecified) D A 0 UNKNOWN 2002 (Unspecified) D A 0 UNKNOWN 2003/2003 192.168.0.53 D A 5060 OK (31 ms) 2004/2004 192.168.0.31 D 5070 OK (6 ms) 9 sip peers [Monitored: 5 online, 2 offline Unmonitored: 2 online, 0 offline]The IP address of each static peer is defined using “host=<ip_address>” in the relevant section of sip.conf and you can specify that a peer does not need to authenticate (i.e. that you trust it soley on the basis of knowing the sender’s IP address) by adding the line “insecure=invite” to the peer definition. SIP Peers can be used very effectively to protect Asterisk against unauthorised call handling as long as you set the parameter “allowguest=no” in the general section of sip.conf. On FreePBX/Trixbox, this parameter is found on the General Settings page, near the end, and is called “Allow Anonymous Inbound SIP Calls?: no”. When set like this, Asterisk will only accept SIP requests from the pre-defined peer addresses or from peers that authenticate using a valid username and password. Unfortunately, some VoIP service providers may require that you set this parameter to Yes because it suits them to send calls to your PBX from several different addresses (for reasons of load balancing and/or resilience). I am aware that Voiptalk send calls from more than one server, but others do it too.
Always use “type=peer” and never “type=friend”
When adding static SIP peers (or so-called “SIP Trunks” in FreePBX/Trixbox) set the type to “peer” and never set it to “friend”. This advice may run counter to the majority of documentation, sample files and examples shown on the voip-info.org site and on Asterisk forums, but you’ll have to take my word for it – using “type=friend” is a big mistake! It will make your Asterisk server much more vulnerable because “type=friend” actually causes two objects to be created – a SIP peer and a SIP user. This gives the potential hacker two entrance doors into your PBX, one of which has comparatively weak security. The problem is that a “user” is allowed to connect from any remote IP address, not just the address specified in the host parameter. Even if you want to allow connections from any address, it is much better to use “host=dynamic” than to use “type=friend”.By far the worst mistake that you could make when defining a static SIP peer would be to have both “type=friend” and “insecure=invite”. In this situation, a hacker could initiate calls from any remote IP address without needing to authenticate with a password. They would only need to guess one piece of data – the user name.
Default Contexts
If your Asterisk server cannot be locked down as described above, perhaps because it needs to accept legitimate requests from IP addresses that cannot be predicted in advance, then it is essential that you examine your configuration and make sure you understand how dial plan contexts are selected for each type of inbound call, especially those in category 3 above. A specific context can, and generally should, be defined for each peer in the sip.conf file using “context=<context_name>” in the peer definition in sip.conf. By doing that you can then be confident that INVITE requests from all other sources (category 3) will use the default context. FreePBX generally expects you to set the context to “from-trunk” when defining a new SIP trunk. To check which context is assigned to any given peer, run the command “sip show peer <name>” at the CLI using the name shown by the “sip show peers” command.This all sounds straightforward, but in fact there is potential for a huge amount of confusion here! First, you must understand that Asterisk comes with a special pre-defined “default” context. Out of the box, Asterisk will generally use the context called “default” to route any category 3 calls. However, you can reset which context should be used for category 3 SIP calls by inserting a line “context=<my_default_context>” in the [general] section of sip.conf. FreePBX or Trixbox will almost certainly have done this for you using a context with a name like ”from-sip-external”. To see which context will be used for calls from unknown sources, run the command “sip show settings” at the CLI. The final section of the output from this command shows you various default settings, including the default context. Here is a sample from a FreePBX unit:
Default Settings: ----------------- Context: from-sip-external Nat: RFC3581 DTMF: rfc2833 Qualify: 0 Use ClientCode: No Progress inband: Never Language: (Defaults to English) MOH Interpret: default MOH Suggest: Voice Mail Extension: *97Each context contains steps that define the dial plan for calls handled by that context. One context may insert the code from a number of other contexts using the “include” directive. To see the dialplan details of any given context, run the command “dialplan show <context_name>” at the CLI. For example:
fpbxwarp*CLI> dialplan show from-sip-external
[ Context 'from-sip-external' created by 'pbx_config' ]
'h' => 1. NoOp(Hangup) [pbx_config]
'i' => 1. NoOp(Invalid) [pbx_config]
's' => 1. GotoIf($["${ALLOW_SIP_ANON}"="yes"]?from-trunk|${DID}|1) [pbx_config]
2. Set(TIMEOUT(absolute)=15) [pbx_config]
3. Answer() [pbx_config]
4. Wait(2) [pbx_config]
5. Playback(ss-noservice) [pbx_config]
6. Playtones(congestion) [pbx_config]
7. Congestion(5) [pbx_config]
't' => 1. NoOp(Timeout) [pbx_config]
'_.' => 1. NoOp(Received incoming SIP connection from unknown peer to ${EXTEN}) [pbx_config]
2. Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})}) [pbx_config]
3. Goto(s|1) [pbx_config]
-= 5 extensions (13 priorities) in 1 context. =-The above example, from FreePBX, is rather over-complicated to explain here, but it does illustrate how you can use the “dialplan show” command to see if calls from unknown sources will be handled safely.
Getting more advanced
In part 2, we looked at several ways in which an Asterisk system administrator can help to make their system more secure, with special emphasis on avoidance of toll fraud. In this, the third and final article in the series, I will pick up on a topic that was left unfinished at the end of part 2 – sip domains. I also want to look at a couple of other topics that were barely touched on in the first two articles, but which are profoundly important for security – the dial plan and Denial of Service attacks.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:012345678@mysipservice.com
- sip:012345678@sip.mydomain.com
- sip:012345678@114.32.159.60
Asterisk can be configured to be indifferent to SIP domains or you can specify a list of “allowed” domains that it will support. How this is achieved is explained in detail in another article on this site:
Configuring and using SIP domains in Asterisk
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
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.
SIP firewall
There are few products available that can honestly be described as purpose-built SIP firewalls. However, there is at least one device now available designed exclusively to be used as a SIP firewall installed in front of your IP-PBX. It is the Pika µFirewall or µWarp. You can read the Smartvox review of this device here.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. If you are, or suspect you may be, on the receiving end of such an attack, then please read the article located here.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.
I hope this has been useful and would welcome feedback from interested readers, either using the voting buttons or by leaving a comment.
