One thing that a lot of VOIP providers do which I have always though was crazy from a security standpoint is to use the DID as the username for SIP authentication. That gives away (more than) half the required information for a successful attack.
The SIP authentication username and passwords should not be anything that an attacker would easily be able to discover. Some providers compound the problem by letting the users choose their own passwords which many users will happily set to "password". Unfortunately, no matter how secure your username/passwords are they can still be compromised if the machine is hacked. Softphones running on insecure computers can have their SIP credentials compromised by a virus. A lot of people use their softphones while travelling and in a significant number of cases would be using open and unsecured Wifi access points making the sniffing of passwords trivial. This problem may increase as more and more people put VOIP softphones on mobile devices such as the iPhone or gPhone. -- John Lange www.johnlange.ca On Tue, 2008-11-11 at 17:59 -0500, Simon P. Ditner wrote: > Not a single reply? > > It's very easy to disregard this message, but I think this is something > VERY IMPORTANT that we should be talking about much more -- especially > for those deploying systems for remote workers over a public network. > There is a huge opportunity for toll fraud, voip spam, and such as this > market segment continues to grow. > > Lability becomes an issue too -- who's responsible when someone is > defrauded via your phone system? The phone companies have a record of you > calling so-and-so; can you prove you didn't? > > These are the sort of scans I've been spotting hitting some of my systems > the past week, trying to brute force. You'll see incremental scans like: > > [Nov 5 19:58:30] NOTICE[19408] chan_sip.c: Registration from '"0"<sip:[EMAIL > PROTECTED]>' failed for 'EE.FF.GG.HH' - No matching peer found > ... > [Nov 5 20:20:21] NOTICE[19408] chan_sip.c: Registration from > '"1000"<sip:[EMAIL PROTECTED]>' failed for 'EE.FF.GG.HH' - Wrong password > ... > > We were discussing this around the office, particularly how sipvicious > (http://sipvicious.org) works, and it was noted that you can find active > SIP accounts easily, and then start a brute force against a known active > account. > > I poked my head into #asterisk-dev, and asked if there were a feature in > the works to automatically disable accounts after a number of bad auth > attempts. It's been discussed, but so far no code. > > There are however some easy things you can do that are common across > running any service on the internet. > > Inside of asterisk, you can cut down on your exposure by only allowing > particular SIP accounts to be registered from remotely by putting > deny-based ACL's on the other accounts, listing your local subnets as > permissable: > > sip.conf > [somepeer] > type=peer > deny=0.0.0.0/0.0.0.0 > permit=192.168.0.0/255.255.255.0 > > You can also create automatic blacklisting of IP addresses that attempt > too many SIP authentications per interval, such as this SSH example: > > http://www.mattiasholm.com/node/6 > > Thoughts? What are other people doing to protect their exposure? > > re, > spd > > On Mon, 10 Nov 2008, Andre Courchesne - Consultant wrote: > > > Hi, > > > > Just to let you know that I see a proliferation is SIP hack attempts. > > Twice > > today I happened to be logged in servers where I saw SIP discovery from IP > > 212.12.148.109 and on the other server that same IP had actually gained > > controlled of a SIP account (which was created with a weak secret by the > > administrator). > > > > The call pattern indicated that calls were made by a dialer of some sort > > and the SIP packets were originating from an Asterisk server. > > > > So be carefull about your server that you have to let unprotected on an > > internet segment. > > > > Andre > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
