Hi,

This is a big problem, i have given some information which help you to understand.

1. 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 PBXs 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 most concerning is that each new attempt
seems to come from a different IP address - if the would-be hackers are using a botnet it suggests
that they are really serious about their undertaking and expect to make money out of it.

2.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. This is often described as "toll fraud. In many 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 - to the end user it just looks like any other VoIP or calling card
service, but with lower prices.

Another possibility for an attack on your systems would be DoS (Denial of Service). Asterisk servers
are not 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 registration or invite requests at it to bring it to its
knees.

Toll fraud is clearly the main issue today. However, the time may come when unwanted spam calls are
as big a problem as toll fraud. When that happens, it will present administrators with a whole new set
of problems.

3.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.

4.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 99999. 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.

.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. Im 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.

6.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 callers 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.

7.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!

which many ricks, there are some way to secure your server.

1. 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.

2.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.

3.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 /var/log/asterisk/messages. 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).

4.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.

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.

5.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 didnt match.

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 - "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 JK (23 ms
smartvox/221221 114.32.159.2 5060 JK (27 ms
sipgate/7654567 217.10.79.23 5060 JK (33 ms
sipbroker 64.34.162.221 5060 Unmonitored
myopensips-in 192.168.0.116 5060 Unmonitored
2001 (Unspecified D A 0 UNKNJWN
2002 (Unspecified D A 0 UNKNJWN
2003/2003 192.168.0.53 D A 5060 JK (31 ms
2004/2004 192.168.0.31 D 5070 JK (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 senders 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 oblige you to 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). Voiptalk is one example of this.

efault 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
MJH Interpret: default
MJH 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:

fpbxwarpCLI dialplan show from-sip-external

Context 'from-sip-external' created by 'pbx_config' ,
'h' = 1. NoJp(Hangup pbx_config,
'i' = 1. NoJp(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. NoJp(Timeout pbx_config,
'_.' = 1. NoJp(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.

hope this help you to secure you server. If did, please thanks.