We see lots of things like this on a more and more frequesnt basis now. I wouldn't be surprised if people are starting to post scripts on warez sites for this now.
One thing we have done to ensure issue like this get stomped is by providing our clients on prem ipsec routers and only have private ip access to the sip registration servers. I encourage other providers to try this with there own networks, it adds not only a major security layer to prevent against hacking but also ensures the traffic travelling across the Internet between the client and your servers is encrypted eliminating a whole stack of other forms of attacks and information gathering which could lead to account compromising. Phil -----Original Message----- From: Stephan Monette [mailto:[EMAIL PROTECTED] Sent: Tue 11/11/2008 6:52 PM To: [email protected] Subject: Re: [on-asterisk] SIP hack attempts Hey everyone, We're also seeing geniuses out there scanning extensions with the extension's number as the password. They also try the same extension number in a reverse order. So make sure you use a minimum of 8 digits for your password and mix the numbers! One more thing you can check with your provider is to limit the number of concurrent calls on your DIDs/account. So if you get hacked, there won't be too many calls made from your account and it will not cost you a lot of $$$ for being negligent. But you still have to put up with the poor customers who received the automated voice call from your DID and giving you a hard time for calling at 2:00AM in the morning! Cheers. Stephan Monette Unlimitel Inc. Tel.: 613-688-6212. x221 TF : 1-877-464-6638, x221 FAX : 613-482-1077 Chuck Mariotti wrote: > Simon, I ran into and was a victim of such an attack back in mid-august. I > emailed unlimitel and this is the recommendations that Stephen had: > > > Dear Customer, > We're seeing a lot more hacking activities lately and here's a short list to > do on your server to help keep it secure: > 1- Change all your default passwords on the server (root, admin, maint). > Never use easy to remember passwords like 1234,... > 2- Never use passwords like 1234 for your any extensions on your server. > There's a lot of hackers out there just scanning your Asterisk server to > detect extensions (200 to 299 mostly) with easy passwords like 1234. > 3- Block access to your server and just leave the RTP, SIP and IAX2 opened. > Just leave the SSH and WEB access opened to your static IP from the office. > You can do this by using the iptables from Linux on your Asterisk server. > 4- Monitor your network and if you see some activities scanning your server, > keep note of the source IP address and block it completely from your server. > Hope this few tips can help you keep your server more secure and avoid big > telephone bills. > Stephan Monette > Unlimitel Inc. > > > -----Original Message----- > From: Simon P. Ditner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2008 6:00 PM > To: [email protected] > Subject: Re: [on-asterisk] SIP hack attempts > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
