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.
Security relating to the first category, using password
authentication, was discussed in the section above. I now want to look
at the second category – Static SIP peers – which are defined in
sip.conf. You can list all the SIP peers (categories 1 and 2), at the
Asterisk Command Line Interface using the command
sip show peers. here is an example:
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: *97
Each 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
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. 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
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.
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.
8:30 AM
dao viet dung
Khách hàng có nhu cầu mua sản phẩm, dịch vụ từ du lịch, nhà hàng,
giải trí, học tập, đào tạo, thể thao, làm đẹp, chăm sóc sức khoẻ, y tế,
vận tải hay mua sắm tại các trung tâm thương mại dễ dàng tìm kiếm ưu đãi
của hàng ngàn doanh nghiệp tham gia mạng lưới Dealtoday.vn mọi lúc, mọi
nơi.
Việc kết nối với các đối tác và khách hàng hoàn toàn trên Internet,
thông tin và nội dung dịch vụ, sản phẩm được tạo ra một lần và có thể sử
dụng lâu dài nên tiết kiệm được chi phí sản xuất nội dung. So với các
mô hình B2C và B2B2C tập trung vào sản phẩm điện tử, gia dụng, thời
trang thì việc Dealtoday.vn tập trung vào dịch vụ sẽ đơn giản và tiết
kiệm chi phí hơn cho phần sản xuất nội dung như viết bài, chụp hình,
thiết kế.
