[necrossis]

I've been reading a lot of articles (from a search on google.news.com) about VoIP security issues.

Are there some measures we should take to secure our VoIP service?

What kind of threats are out there if you're using VoIP?

btw: I'm using SPA1001. But this would be for all form of VoIP out there.

thanks,

read this article:
http://www.computerweekly.com/articl...earch=&nPage=1

[rudholm]

Well, seeing as how that article is completely free of any information regarding actual VoIP security issues, it's difficult to comment.

The only "security" issue I can think of is surreptitious call monitoring. Any unencrypted network traffic is subject to eavesdropping, but it's not as easy as those selling "Security" would have you think. You must have access to at least one segment of the network over which the data travels. And this threat is relatively easily mitigated with end-to-end encryption (I understand the Sipura ATAs support encryption) or other tools probably more familiar to corporate IT departments; VPNs and encrypted tunnels.

Two Sipuras doing end-to-end encryption is a lot more secure than a traditional telephone call.

[mberlant]

To add to what rudholm said, in order to monitor a call you must have physical access to a part of the network that carries the entire call. In the world of SIP, which travels via UDP, each packet in a conversation could conceivably travel via a completely different route from end to end. In reality, the path will vary occasionally over the course of a call, with a cluster of packets taking one route and the next cluster of packets taking another.

This means that, in order to ensure capturing the conversation you must have physical access to the wire that connects one endpoint or the other's router with that endpoint's ISP's access router. Any farther into the network (until you reach the destination endpoint) will not offer access to the entire conversation.

[PhoneBoy]

A conventional telephone call is less secure than an 'unsecure' VoIP line, if only because tapping a telephone line is trivial if you can get anywhere near the demarc of the victim (or even just up the street, depending on the neighborhood and how the wiring is done). It basically requires a device that any telco installer has (forget what it's called exactly, but its a telephone handset attached to a pair of alligator clips), and they can be obtained relatively cheaply (less than $100, IIRC). Maybe I'll get one of those next time I'm at Frys.

Tapping a DSL or Cable line could probably be tapped in a similar manner (the demarc for that stuff is just as exposed), but the equipment necessary to tap a DSL or Cable connection is likely a bit more sophisticated (assuming it exists), therefore making such tapping a bit more unlikely.

[mberlant]

The official term for what you describe is a "lineman's handset".

To tap a DSL Line you would need two modems, a subscriber side one and a DSLAM side one, strapped together so that each modem listens to one side of the connection. If you can get this contraption to sync with the victim's connection it's pretty straightforward to run it through a network analyzer, capture the traffic, filter it for UDP traffic, filter it some more for packets with SIP headers, filter it some more for unique conversations, figure out which conversation you are interested in, and do all of this all over again to find the other half of the conversation.

Good luck.

[necrossis]

What about 'high jacking' of my VoIP service?

What I mean by this is:
Could someone gain access to the setup page of my Sipura and copy (steal) all of my BV account info in order to configure another ATA and make calls using my account?

[rudholm]

Well, you'd have to forward inbound external port 80 connections to your Sipura for anyone to be able to get to your Sipura's setup pages. And even if you did this, your BV account information is not visible (the password is obscured) on those pages. Even a fully unlocked Sipura presents the password as asterisks on the setup page.

You know, mberlant, now that I think of it, given the difficulty of capturing a conversation by collecting packets (as you've pointed out), a better and easier way of monitoring someone's calls would be to hijack their ATA and configure it to authenticate against my server. I would learn their SIP username/password at that time. I could then use those credentials to register with their service provider. I could pass calls through transparently. The advantage of this man-in-the-middle attack is that you could capture call administrative detail (number called/calling) as well as the actual call content. And once you have access to a PC on someone's LAN, finding and reconfiguring any unlocked ATA(s) on the LAN becomes almost trivial.

[meirgreen]

You don't have to hijack their ATA if you can fake their DNS client into giving the IP address for your server instead of the real one.

This would be harder for them to discover than changing settings on their ATA, which they might at some point inspect.

Meir
234045

[rudholm]

I guess you mean their DNS server, but yeah, that could work too as long as the ATA uses a hostname rather than an IP address as the SIP proxy. BroadVoice configures ATAs to use their own DNS servers. That DNS query isn't going to be easy to interfere with.

[meirgreen]

When the "man in the middle" sees the DNS request go out for proxy.broadvoice.com, it immediately spoofs a response as if it was coming from the BV DNS server IP. But instead of the IP for the *real* proxy, it gives the IP for it's own proxy. Then the fake proxy sits in the middle, and filters off all the conversations.

Guess it is easier to change the DNS entries in the ATA so you don't have to intercept any traffic. But this presumes you can break into the configuration.
This can be detected if he checks the DNS server IP addresses, and will be overwritten by BV when they send a new config file.