asterisk users - Oct 2010 - fraud advice (Also advice on using ipbanning)

When we designed our systems on asterisk we designed it to me multi-tenant. 
Se we use customer prefixes on all extensions. This allows us to have 
multiple customers using the same extension pools. It also reduces the hack 
foot print as hackers must know the prefix for a customer to try and brute 
force things. All passwords use 8+ characters with alfa/numeric and special 
characters. 

As I see it Asterisk does very good keeping out the hackers if you use a 
solid design in your peer and dialplans. At the least put an alpha 
character post or pre other wise you are just asking for it.  Use your head 
you can be smarter then they are.

We are looking into ipban as well. If any one has an example of ipban I 
would love to see how best to implement it.  In a 4 year period we have not 
had a breach but we do get about 10 to 15 hack attempts a week. We have 
blocking scripts that block ip's at the primary firewall but I would like 
to trigger the ipban at each switch level. Could I also use the ipban 
method to trigger the audo updates to our primary firewalls? Any advice is 
appreciated. 

 Bryant

----------------------------------------
 From: "Steve Totaro" <stotaro at totarotechnologies.com>
Sent: Friday, October 15, 2010 11:22 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users at lists.digium.com>
Subject: Re: [asterisk-users] fraud advice

On Fri, Oct 15, 2010 at 10:29 AM, Steve Edwards
<asterisk.org at sedwards.com> wrote:
> On Thu, 14 Oct 2010, bruce bruce wrote:
>
>> But it also sickens me at how badly Asterisk is made to not cope with
>> situations like this and worse than that is FreePBX.
>
> Kind of like blaming the gun manufacturer instead of the criminal with
> their finger on the trigger?
>
> Is there some gaping hole in Asterisk security or are you just asleep at
> the wheel?
>
> --
> Thanks in advance,
> 
-------------------------------------------------------------------------
> Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 
PST
> Newline                                              Fax: 
+1-760-731-3000
>
This is nothing new. Trunk to trunk transfers and other exploits
could be used on old school phone systems to do the same thing.

I would start with getting the current balance, if over $10k call the
FBI, call them anyways, it couldn't hurt. You want the Feds to check
things out before local police if possible.

Gather as much info as possible, along with police and FBI case
numbers and then call the carrier and see what can be done.

A friend of mine took what was supposed to be my one month rotation to
Iraq. I had too much going on to be in Iraq for a month and a half
and had taken the last rotation so it wasn't even my turn.

The phone bill came for his cell (company provided on Asia Cell) for
$4k in just a couple weeks. It turns out that he was not using the
cell and one of the cleaning people stole his SIM.

After contacting Asia Cell a few times about the matter, they credited
the whole amount back. So you never know.

As for security, I assume you need to allow these extensions to
register from outside the LAN? If not, then only allow them to
register via a LAN IP, I would do it with iptables, only allow the
provider IP through.

I am curious what your user:pass was? something like 1000:1000, I see
many systems setup like this and am surprised they haven't been hit
yet.

In the future, you could use a scheme that makes it much more secure
and also pretty easy to maintain.

The username could be the MAC and the pass could be the serial number
or asset tags if you use them.

I know there must be dozens of people reading this that have had the
same issue but are embarrassed to speak up.

(BTW Sierra Leone is in West Africa, not the Middle East.)

Thanks,
Steve T

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20101016/5693fee8/attachment.htm

----- Original Message -----


When we designed our systems on asterisk we designed it to me multi-tenant. Se
we use customer prefixes on all extensions. This allows us to have multiple
customers using the same extension pools. It also reduces the hack foot print as
hackers must know the prefix for a customer to try and brute force things. All
passwords use 8+ characters with alfa/numeric and special characters.

As I see it Asterisk does very good keeping out the hackers if you use a solid
design in your peer and dialplans. At the least put an alpha character post or
pre other wise you are just asking for it. Use your head you can be smarter then
they are.

We are looking into ipban as well. If any one has an example of ipban I would
love to see how best to implement it. In a 4 year period we have not had a
breach but we do get about 10 to 15 hack attempts a week. We have blocking
scripts that block ip's at the primary firewall but I would like to trigger
the ipban at each switch level. Could I also use the ipban method to trigger the
audo updates to our primary firewalls? Any advice is appreciated.


Bryant 



You could also use OSSEC http://www.ossec.net and a custom decoder and rule: 

<decoder name="local-asterisk-denied"> 
<prematch>NOTICE[\d+] \S+: Registration from </prematch> 
<regex offset="after_prematch">^\S+ failed for
'(\d+.\d+.\d+.\d+)'</regex>
<order>srcip</order> 
</decoder> 

<rule id="110005" level="5"> 
<decoded_as>local-asterisk-denied</decoded_as> 
<description>Asterisk Potentially Under Attack</description> 
</rule> 

<rule id="110006" level="10" frequency="5"
timeframe="10">
<if_matched_sid>110005</if_matched_sid> 
<same_source_ip /> 
<description>Asterisk Under Brute Force Attack</description> 
</rule> 
-- 
Thanks, Phil 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20101017/37d9352f/attachment.htm