Amazing points brought up by everyone. I remember that a simple search for word trixbox with dyndns domains would definitely bring up a few boxes that were not secured. The fan part was that even the secured ones still had the default passw0rd for FOP if not the maint default password. So, anyone could use FOP to call different extensions at midnight if it was a home pbx or drive everyone nuts during the day by drag and drop of extensions. I guess a good firewall with good practices with passwords would prevent security issues. But even then there are situations when you have no control. I have a client who refuses to use VPN and has a public static IP forwarded to his box. For some reason he likes to get to his network without a VPN connection due to some other application that he is running on a separate server. He also has employees that connect SIP over the net again without VPN. There are more than 100 attempts on the box every day. They all originate from different IPs. Most of them from China. E-mailing the Admins on the other side would definitely not get any attention. All I can do is warn the client continuously and keep a good password on the root. I don't think the mouse trap works for him at all. Most of the attempts come from possessed machines that can even be from North America. They can be using dynamic IPs. So, I can't block every single IP I see there. 1- Its time consuming. 2- I could be blocking access to legit stuff if I block a dynamic IP. Guess what happens if the system compromised? I have the experience. Your system will join the group of the possessed machines and will try to lunch a DDoS on some of the major websites, e.g. CNN.com, Adobe.com, Amazon.com and that is when Rogers suspends your internet for some time and makes you listen to a lengthy Service Term Agreement. In AsterLAMP systems security should be turned ON all way unless a user wants to turn it off manually. I believe security should be a big part of FreePBX too because the novice users are more vulnerable. Until now, every FreePBX install warns of default SQL and Asterisk Manager passwords and there is no easy one click way of changing these passwords without breaking other stuff. -Bruce
> Date: Tue, 11 Nov 2008 19:52:13 -0500 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: [on-asterisk] SIP hack attempts > > Hi, > > Would anyone be interested to see a demonstration on how to build a > mouse trap in your Asterisk server at the next TAUG meeting? > > I'm willing to drive to Toronto and put a presentation together on the > subject. > > Cheers. > > Stephan Monette > Unlimitel Inc. > > Tel.: 613-688-6212. x221 > TF : 1-877-464-6638, x221 > FAX : 613-482-1077 > > > > Stephan Monette wrote: >> Hey everyone, >> >> Another trend we see in this hacking activity: >> >> The hackers seems to be collecting SIP accounts hacked for a few weeks >> from one server and then from a different IP address/Asterisk server >> they start using the hacked accounts earlier to make their fraudulent >> calls. There could be weeks between the time they discover your weak >> SIP account and the time they start using it. >> >> Did you know that if someone gets hurt and that same person can prove >> the calls are being made by your phone system, the administrator of >> your phone system can be sued for being negligent to properly secure >> their systems and are personally responsible for any damages cause by >> this action! >> >> Very scary! >> >> Another easy way to reduce your system from being hacked is to design >> a mouse trap: create an extension 200 with password 1234. Then you >> program a separate context for extension 200 with no possibilities to >> make any calls. Most hackers stop sniffing for passwords after >> successfully guessing the first account. Then design a small tool to >> gather IP addresses that uses extension 200 and block all access from >> those IP addresses. >> >> Cheers. >> >> Stephan Monette >> Unlimitel Inc. >> >> Tel.: 613-688-6212. x221 >> TF : 1-877-464-6638, x221 >> FAX : 613-482-1077 >> >> >> Chuck Mariotti wrote: >>> I also made some recommendations to Unlimitel, but maybe this should >>> be shared with providers as to what would have allowed me to catch >>> this issue: >>> >>> I know this is likely a lot of work, but... it would be nice to have >>> the daily totals in the body of the email and subject. I rarely open >>> my email attachment to see the minutes used for a day, but if there >>> was a dollar amount or # of minutes in the subject, it would make it >>> easier to scan with the eyeball. I would have missed our recent hack >>> completely if I didn't get returned calls complaining... which made >>> me check my CDR in Asterisk, which made me look the next day in your >>> report. It also happened on a Friday night (I'm sure on purpose) so I >>> wouldn't have even attempted to look until Monday. >>> >>> I know that's a lot more horsepower needed than just attaching a text >>> file. But I know it would be helpful to me. >>> >>> As well, could be useful to set an alert on DID for minutes used in a >>> day... I think that's asking too much though. >>> >>> Regards, >>> >>> Chuck >>> >>> -----Original Message----- >>> From: Chuck Mariotti [mailto:[EMAIL PROTECTED] Sent: Tuesday, >>> November 11, 2008 6:40 PM >>> To: Simon P. Ditner; [email protected] >>> Subject: RE: [on-asterisk] SIP hack attempts >>> >>> 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"' failed for 'EE.FF.GG.HH' - No matching peer >>> found >>> ... >>> [Nov 5 20:20:21] NOTICE[19408] chan_sip.c: Registration from >>> '"1000"' 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] >>> >>> >>> >>> >>> >> >> >> >> --------------------------------------------------------------------- >> 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]
