If you are going to expose a security vulnerability like this, I'd recommend only allowing access to a trunk that has a finite ld value. For instance, a prepaid like VOIP.ms, so that when they have exceeded the $100 of long distance on the account in 15 minutes, calls don't go through any longer.
To open these calls up to your main ld trunks seems like a very bad idea. BTW, I had a customer who's 3mb bonded T1 was saturated at the full 3 mb by sipvicious attack. Although Kyle didn't say this exactly, I believe he is eluding to the fact that looking for vulnerabilities in SIP products will only continue to rise, and make them more vulnerable. This feature could be one of those vulnerabilities if policies are not put into place to limit their exposure. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kyle Haefner Sent: Wednesday, September 29, 2010 12:10 PM To: Tony Graziano Cc: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Anyone in a position to test authorization code on 4.3 install? I really think that open SIP uris to the Internet are going to be a short lived thing. I think that in future if you want to call someone outside of your domain you'll need to present either a personal certificate from a trusted third party, or a certificate signed to your domain and your domain is signed by a TTP, before your call is allowed to be processed on the far end. Sure, someone will always be able to DOS (and firewall limiting will help here) you from a bot-net, but at least a robo-call from Nigeria won't wake you up at 2Am in the morning! Kyle Tony, a bit more complicated than this but scarily not by much :) #!/bin/bash while [1] do sipsak -I [email protected] sleep 60 done On Wed, Sep 29, 2010 at 12:45 PM, Tony Graziano <[email protected]> wrote: > I pointed that out specifically for you Kyle. While I agree with you, my "spidey senses" tingle at the thought of revealing what someone has dialed in "human speak:...". Having been one to speak to customers toll fraud back in my carrier telecom days... > > In my tests, I placed a DID number on the alias for AC (Authorization Code) feature. Something a little in between like "Enter Code" and "Thank you, please wait" might be acceptable. I just think about toll-fraud... > > Which reminds me to yank that DID off of that system. So the default is *...@sipdomain, which also means it can be used as a sip uri. So that makes me suggesting to people that the default is too well known and to change it if they see a lot of traffic to that uri from the internet and it is not warranted, because now a simple pin being broken with a script can open yourself up for toll fraud... I'm not picking, just pointing out the obvious. > > I know people wanted this feature, but shouldn't there should be a way to protect it? An alarm that sends an email if there are numerous improper attempts in a short time period. Once it is installed, there is no way to disable the service, only to uninstall the package. It's not selectable as a role, and maybe it shouldn't be a role, but maybe you should be able to disable it whether it is installed or not. > > So if you use it, consider changing the default code from *81 to something a little less obvious. Sometimes a little obscurity is OK. > > All this "spidey sense" stuff has made me want to go stare at my "Red Hulk" comic book for a while... > > > On Wed, Sep 29, 2010 at 2:22 PM, Kyle Haefner <[email protected]<mailto:[email protected]>> wrote: > See what I mean, beeps aren't always that obvious? :) > > On Wed, Sep 29, 2010 at 12:01 PM, Tony Graziano > <[email protected]<mailto:[email protected]>> wrote: >> Nevermind. It was a PICNIC issue. I forgot to use the daned access code! That's what those two beeps mean... >> >> (I smacked the back of my head for that one). >> >> On Wed, Sep 29, 2010 at 1:55 PM, Douglas Hubler <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto :[email protected]>>> wrote: >> On Wed, Sep 29, 2010 at 1:50 PM, Tony Graziano >> <[email protected]<mailto:[email protected]><mailto:tg [email protected]<mailto:[email protected]>>> wrote: >>> I find dialing media services is an issue (VM or AA). >>> >>> Dialinf internal users and pstn numbers seem fine. I get two beeps dialing >>> media services. >>> >>> Should that work? >> >> Should, can you post back the offending log entries. >> _______________________________________________ >> sipx-users mailing list >> [email protected]<mailto:[email protected]><mailto :[email protected]<mailto:[email protected]>> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: [email protected]<mailto:[email protected] ><mailto:[email protected]<mailto:[email protected] tment.net>> >> Fax: 434.984.8431 >> >> Email: [email protected]<mailto:[email protected]><mailto:tgr [email protected]<mailto:[email protected]>> >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: [email protected]<mailto:[email protected]>< mailto:[email protected]<mailto:[email protected] t.net>> >> Fax: 434.984.8427 >> >> Helpdesk Contract Customers: >> http://www.myitdepartment.net/gethelp/ >> >> Why do mathematicians always confuse Halloween and Christmas? >> Because 31 Oct = 25 Dec. >> >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected]<mailto:[email protected] > > Fax: 434.984.8431 > > Email: [email protected]<mailto:[email protected]> > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected]<mailto:[email protected]> > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
