Posts Tagged “VOIP”

iPhone only: Fring, a VoIP and chat app for the iPhone, got a nice update this week that lets users make video and voice calls over a 3G connection. Best of all, it’s still free.

We’ve mentioned Fring before because it’s a great way to turn your iPod touch into an iPhone, but until now the only way you could make calls with it was via Skype. The new update bypasses the need for Skype and lets you call or video chat with your contacts right from Fring using your iPhone’s 3G connection (and, of course, Wi-Fi when you’re near a hotspot).

If you already have Fring on your iPhone, you don't need to download anything else. The app will auto-update the next time you open it. If you get an error message on your first attempt at a voice or video call, click on More -> Go Offline and open Fring a second time.

Even if you don’t have access to a 3G connection (we’re looking at you, unlockers), Fring is a great app to have around anyway. It keeps you connected to all the friend and buddy lists you have spread out all over the place on AIM, Google Talk, MSN, and so on.


Tags: google, VOIP

Possibly Related posts

Comments Comments Off

rsullivan25: back at it – hope to get service to our new VOIP server today

Tags: VOIP

Possibly Related posts

Comments Comments Off

In case any of you were wondering why there has been a fairly notable upswing in the attacks happening on SIP endpoints, the answer is “script kiddies.”  In the last few months, a number of new tools have made it easy for knuckle-draggers to attack and defraud SIP endpoints, Asterisk-based systems included.  There are easily-available tools that scan networks looking for SIP hosts, and then scan hosts looking for valid extensions, and then scan valid extensions looking for passwords.  You can take steps, NOW, to eliminate many of these problems.  I think the community is interested in coming up with an integrated Asterisk-based solution that is much wider in scope for dynamic protection (community-shared blacklists is the current thinking) but that doesn’t mean you should wait for some new tool to defend your systems.  You can IMMEDIATELY take fairly common-sense measures to protect your Asterisk server from the bulk of the scans and attacks that are on the increase. The methods and tools for protection already exists – just apply them, and you’ll be able to sleep more soundly at night.

 

Seven Easy Steps to Better SIP Security on Asterisk:

 

1) Don’t accept SIP authentication requests from all IP addresses.  Use the “permit=” and “deny=” lines in sip.conf to only allow a reasonable subset of IP addresess to reach each listed extension/user in your sip.conf file.  Even if you accept inbound calls from “anywhere” (via [default]) don’t let those users reach authenticated elements!

 

2) Set “alwaysauthreject=yes” in your sip.conf file.  This option has been around for a while (since 1.2?) but the default is “no”, which allows extension information leakage.  Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks.

 

3) Use STRONG passwords for SIP entities.  This is probably the most important step you can take.  Don’t just concatenate two words together and suffix it with “1″ – if you’ve seen how sophisticated the tools are that guess passwords, you’d understand that trivial obfuscation like that is a minor hinderance to a modern CPU.  Use symbols, numbers, and a mix of upper and lowercase letters at least 12 digits long.

 

4) Block your AMI manager ports.  Use “permit=” and “deny=” lines in manager.conf to reduce inbound connections to known hosts only.  Use strong passwords here, again at least 12 characters with a complex mix of symbols, numbers, and letters.

 

5) Allow only one or two calls at a time per SIP entity, where possible.  At the worst, limiting your exposure to toll fraud is a wise thing to do.  This also limits your exposure when legitimate password holders on your system lose control of their passphrase – writing it on the bottom of the SIP phone, for instance, which I’ve seen.

 

6) Make your SIP usernames different than your extensions.  While it is convenient to have extension “1234″ map to SIP entry “1234″ which is also SIP user “1234″, this is an easy target for attackers to guess SIP authentication names.  Use the MAC address of the device, or some sort of combination of a common phrase + extension MD5 hash (example: from a shell prompt, try “md5 -s ThePassword5000″)

 

7) Ensure your [default] context is secure.  Don’t allow unauthenticated callers to reach any contexts that allow toll calls.  Permit only a limited number of active calls through your default context (use the “GROUP” function as a counter.)  Prohibit unauthenticated calls entirely (if you don’t want them) by setting “allowguest=no” in the [general] part of sip.conf.

 

These 7 basics will protect most people, but there are certainly other steps you can take that are more complex and reactive.  Here is a fail2ban recipe which might allow you to ban endpoints based on volume of requests.  There is discussion on the asterisk-user and asterisk-dev mailing lists of incorporating this type of functionality into Asterisk – let’s hear your ideas!

 

If you’d like to see an example of the tools that you’re up against, see this demo video of an automated attack tool that does scan, guess, and crack methods via a click-and-drool interface.
  
In summary: basic security measures will protect you against the vast majority of SIP-based brute-force attacks.  Most of the SIP attackers are fools with tools – they are opportunists who see an easy way to defraud people who have not considered the costs of insecure methods.  Asterisk has some methods to prevent the most obvious attacks from succeeding at the network level, but the most effective method of protection are the administrative issues of password robustness and username obscurity. 

 

JT
Tags: VOIP

Possibly Related posts

Comments Comments Off

electric-meter

My promised restructuring of Microsoft will conclude tomorrow but today I want to cover a news announcement from Google that I think is very important, yet that importance seems to have been missed by the mainstream and technical press alike.  My subject is the Google PowerMeter, which is far more strategic than Google is letting-on.

Not that the official PowerMeter story isn’t a good one.  Google has invented these devices that will be distributed to users to measure the electricity consumption of their homes or apartments in real time, encouraging residents to conserve power, which is good for everyone.  I’d love to have one of these gizmos, which in most cases won’t only report to the residents but also to the electric utility.  And eventually that utility may be able to directly control electric heating and cooling systems through the PowerMeters, turning them up or down as needed to reduce total demand during high-use periods, perhaps in exchange for lower electric rates for the consumer.

This power consumption shaping would be very similar to programs already in place with many industrial users, the idea being that if maximum consumption can be kept down below a certain level then the utility won’t have to fire-up expensive gas turbine generators that are often used for peak additional power.  And in extreme cases utilities might be able to forego entire power plants, saving in the case of nuclear plans, up to $3 billion in construction costs.  It’s a heck of a deal.

So this is Google doing its bit for the environment in exchange for which they learn even more about our behavior, right?

Wrong.  It’s much more than that.

Google’s PowerMeter is a Trojan horse – a way to become a de facto Internet Service Provider for potentially millions of homes.

Several years ago Google made a $100 million investment in a suburban Washington, DC company called Current Technologies, which is America’s leading provider of both smart electric metering services (that’s what the Google PowerMeter is supposed to be) AND power line Internet service based in part on the HomePlug networking standard.

Current’s business model was simple.  They’d give participating utilities a way to both measure and control local power consumption pretty much as described above.  Oh and, by the way, the meter connection could also be used to provide Internet service, potentially to 100 percent of a neighborhood since pretty much everyone buys electric power.  Throw Internet on the power bill, then maybe digital cable service, too.  Eventually the power companies would take on the cable and telephone companies to fight for broadband hegemony.

Only it isn’t really happening that way.  Current is doing deals with utilities, but most of those utilities AREN’T going so far as to offer broadband Internet.  They are just reading meters, thank you, which isn’t bad unless your profit is supposed to come from the Internet and cable competitor side.  So Current Technologies is struggling somewhat and Google’s investment in that company hasn’t grown as much as either company would like.

Enter the Google PowerMeter, which is both an intelligent power meter AND an Internet gateway, just like the original vision at Current Technologies.

Electric utilities are enthusiastically installing backbone capability to serve these smart meters.  And contrary to popular belief, the network on the power company’s side of that medium-voltage transformer on your telephone pole is usually optical fiber, NOT Broadband over Power Lines (BPL) which amateur radio operators hate so much.  The fact is that BPL has real distance limitations and it is just easier to string fiber alongside the medium and high-voltage lines.

So the utilities partner with Google to install these boxes, ideally in every home.  They install enough fiber for gigabit service to the medium voltage transformer with HomePlug or WiFi into the home.  And the whole thing interfaces to Google at the power company’s data center where Google will install proxy servers and routers and connect to the Internet backbone.

Eventually Google — not the electric utility — throws the switch on consumer Internet access, IP TV, and VoIP phones, which the electric companies could have done – should have done – on their own but generally couldn’t be bothered to.

Ideally Google lights the whole town with Internet with the utility happily picking-up most of the infrastructure costs yet with Google becoming the ISP.

Now THAT’s a heck of a deal.

Prove to me I’m wrong.

Tags: google, internet, VOIP

Possibly Related posts

Comments Comments Off

Installing The Asterisk PBX And The Asterisk Web-Based Provisioning GUI On Linux

Tags: linux, VOIP

Possibly Related posts

Comments Comments Off