I found this little nugget on Broadvoice's howto page for Asterisk ...
; This extended Dial Plan will enable International Dialing on The
Unlimited World PLUS Plan
; This dial plan enables World Plus countries
; there are no built in ways to prevent calls to cell phone users
(except in germany where Cell phone prefix's are
; carried by 1 and has been accounted for)
exten=_01130.,1,dial(SIP/${ext...@sip.broadvoice.com,30)
exten=_01131.,1,dial(SIP/${ext...@sip.broadvoice.com,30)
exten=_01132.,1,dial(SIP/${ext...@sip.broadvoice.com,30)
exten=_01133.,1,dial(SIP/${ext...@sip.broadvoice.com,30)
exten=_01134.,1,dial(SIP/${ext...@sip.broadvoice.com,30)
And so on for the free calling countries they have. I was able to modify
the UK (44) dial string to account for cellphones, premium rate and
"local" rate calls too as all cellphones in the UK start 07xxx, free,
"local" and "national" rate centers start 08xxx and premium rate are of
course 09xxx.
Lets see how this works!
Mark
On 09/18/2010 10:17 PM, Chris Abnett wrote:
> We ran into an issue with some of our customers that are not running
> astlinux or asterisk at all.. but are using VOIP trunks.. (into adtran
> 924).. they got in and hacked the SIP provider info to make the calls
> out... spoofed IP and MAC address info to gain access to the network.....
>
> The PBX systems at these sites never even showed a record of a call being
> made or received.. however the provider obviously showed the calls... and
> the calls were in fact made to Somalia as well...
>
> What we did was obviously secure the network, but also had the provider
> block all international calls except for country codes specified.. most
> providers will do this for you... so if there is no need to call middle
> east, have the provider block those calls...
>
> Typically what we have found is that these calls are linked to an automated
> system whereby callers are sold prepaid cell phones and dial a local number
> then make the call out to the middle east or wherever.. once the calls are
> blocked their system yanks them out and you are typically clear.. but if
> they feel your system is still exploitable they will go after it for a
> while....
>
> Another way that legacy systems are hacked is to bring a call in with no
> DNIS digits and often it will default to a context in which an
> autofallthrough takes precedence and basically allows the attacker free
> reign on your asterisk.... so I always make sure that my contexts have a
> hangup at the end of each thread... so that if a call somehow falls through
> the cracks it will reach a hangup before it is allowed to fall through to a
> context that allows full access.. you can also use the autofallthrough
> directive to block these types of things too....
>
> -Christopher
>
> -----Original Message-----
> From: Lonnie Abelbeck [mailto:li...@lonnie.abelbeck.com]
> Sent: Saturday, September 18, 2010 9:54 PM
> To: AstLinux Users Mailing List
> Subject: Re: [Astlinux-users] Call Theft again - questions
>
> Mark,
>
> Sorry to hear about the call theft.
>
> First I'd change all your passwords, including your provider, with something
> like the output of:
>
> $ openssl rand -base64 21
>
> If you are running the latest AstLinux (0.7.2) there is a firewall plugin
> "adaptive-ban" that has been demonstrated to deter brute force attacks
> similar to fail2ban. (See Network tab -> Firewall Plugins: )
>
> Obviously not allowing the world UDP 5060 access, if you can, would also
> help.
>
> Lonnie
>
>
>
> On Sep 18, 2010, at 7:55 PM, Mark Phillips wrote:
>
>> Hi All,
>>
>> Well, for the second time in about a month I've been the victim of call
>> theft to the tune of almost $1000. It would seem that someone is able to
>> acquire an extension on my AstLinux box and use it to call Somalia for a
>> few minutes at a time over and over again until I catch it.
>>
>> Luckily this time my provider was on the lookout and trapped the theft
>> after about $250 of calls were made.
>>
>> To get to the point, Broadvoice's call log show that I made a good many
>> calls to a particular number in Somalia but my log does not. Indeed, my
>> log as viewed via the AstLinux Management web interface shows that the
>> last call made by one of my users was at around 1030am today. The last
>> call to Somalia was at 5:48 tonight.
>>
>> I have a number of questions all related to SIP security but my biggest
>> question is "why don't the calls show up in my log?" My provider can
>> show logs demonstrating that the Somalia calls came from my IP address
>> and I did spot the odd one or 2 towards the end originating from an
>> extension within my number plan.
>>
>> So back to my SIP questions, I use a combination of hard and softphones
>> around the house and a softphone on my new Android phone. I occasionally
>> use a softphone on my laptop remotely via L2TP VPN.
>>
>> Each entry in my sip.conf file has this in it;
>>
>> deny=0.0.0.0/0.0.0.0
>> permit=192.168.201.0/255.255.255.0
>> permit=192.168.202.0/255.255.255.0
>>
>> but yet still the hacker/thief was able to get in.
>>
>> When I spotted the theft I noted that the thief was using exten 2201 (my
>> android softphone), the UA as reported by "sip show peer 2201" was
>> "MySIP" (an app I was never able to get working correctly) but yet my
>> Android wasn't running the MySIP softphone at the time.
>>
>> Could it be that the MySIP app was in fact some sort of Android Trojan?
>> How well do if at all do the deny/permit parameters in sip.conf work?
>> How well does the SIP module in AstLinux stand up to brute force attacks
>> (I'm assuming the thief tried that as well)?
>>
>> I'm now so worried about another one of these occurrences that I'm
>> having to disable SIP access on my monoWall which in turn will impact my
>> ability to work.
>>
>> Ideas??
>>
>> Thanks
>>
>> Mark
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Astlinux-users mailing list
>> Astlinux-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>>
>>
>
>
> ----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
