Feeds

Spam on IP telephony

To Spit or not to Spit

The essential guide to IT transformation

Spam filters can easily be trained to give better than 90 per cent effectiveness with zero false positives, and for those who still suffer from a lot of spam in their inboxes, they are either not updating their spam databases often enough, or they just do not see the value of getting 90 per cent fewer email messages.

There was also a bout of Spasms (spam over SMS) - less of a problem for businesses, where this does not seem to have been endemic, but pretty nasty for many children who find that they get messages asking for a response, and then find that up to £10 has been taken from their mobile account as a result.

Again, this sort of spam should be fairly easy to deal with, but is in the hands of the operators, rather than the users themselves.

How about Spim? Spam over instant messaging has not had a big hit yet, but significant instances of spurious instant messaging sessions are being seen where the user is asked to download a file, which unsurprisingly carries some nasty payload.

One more for the list - Spit. Spam over IP telephony is one which so far, thankfully, is pretty rare, and is low on many suppliers' radars. The problem is that it is completely different to the others.

Spam, Spasms and Spim are all asynchronous to one degree or another - an email can be easily taken out of a queue and held up for a few minutes while analysis is carried out, and no one is going to notice.

The same goes for Spasms. SMS messages turning up a couple of minutes late is no big deal, and for certain providers I could mention, getting them to turn up within the same working day seems to be beyond their powers as yet.

Even with Spim, a delay of a few seconds does not detract from the overall efficacy of the discussion session. And if most users are like my daughter, then there will be anywhere up to 20 sessions going on at the same time, so a delay is inevitable.

But Spit is different. If we decide to analyse all incoming calls we have a major problem. Sure, we can kill off any calls that come from a known bad set of IP addresses (a standard black listing approach as used by many anti-spam engines). And we can let through any call that comes through from a known, trusted IP address (again, white listing, as used by many Spam engines). So, we manage to kill off or let through probably 20 per cent of our calls, but what happens to the other 80 per cent?

As soon as we start to take an active interest in the call itself, we introduce a delay. Telephony of any sort is synchronous, and for those of us old enough to remember the joys of transatlantic telephony in the 1960s, that quarter-second delay in conversations made your head reel.

The problem for Spit engines will be that all the tricks that the spammers have learnt from email spam will be magnified here. It took spammers a while to realise that having a static IP address meant that the spam was cut off fairly rapidly by putting the IP address on a black list.

Now the majority of IP addresses used by spammers are either live only for 15 minutes or less and then dumped, or are completely spoofed randomly.

The farming of email addresses that used to be so simple through just looking at websites for the "@" sign moved through to common name brute force methods of john.smith@knowncompany.com - and we can expect brute force methods of IP sweeping to be used to identify IP telephony devices and target them in this way.

But to what end would anyone want to Spit, anyway? There is the slight chance that a virus could be written that could make the most out of the minimal intelligence built in to the phones. There is the use of mass cold calling, backed up either by cheap call centres or by recorded messages to sell holidays, time share or whatever.

However, the biggest one could well be the voice over IP denial of service attack-flooding a company's telephone service with essentially free calls from automated IP autodiallers running at thousands of calls a minute such that no incoming or outgoing calls are possible.

So, when you are looking at your new VoIP installation, you may need to have a set of policies in place. Which handsets will have completely open usage, with only those IP addresses that are known to be Spit sources blacklisted, which handsets will have a broader block of IP addresses blocked, and which ones will only have access in or out to telephone numbers and IP addresses that are in a white list?

This can minimise your risk, and should any of the open phones start to be attacked, that phone can rapidly have a new IP address allocated so that the Spit engines would have to find it again.

Talk to the supplier and find out what they can do to help. Do they run their own white and black lists that you can utilise to get up and running rapidly? Do they have denial of service protection, so that the system can throttle down the number of incoming calls from dubious environments and still let those from known environments through? Does the VoIP system integrate into existing management systems so that you can utilise existing tooling to identify patterns of irregular usage?

VoIP has so much going for it, but runs the risk of being ruined by a mixture of reality and perception. Many systems are implemented as unmanaged systems, resulting in poor voice quality.

There is a perception that VoIP is insecure, but no one seems worried that the past 100 years of telephony has meant that anyone with a couple of crocodile clips can listen in to conversations, and that corporate VoIP is relatively easily secured.

However, Spit to me is the biggest risk - if companies find that they are bombarded with useless calls that cost the perpetrator very little but cost the company a lot in time, in resources and in capability, we may yet see a backlash against VoIP.

However, I believe that suppliers will be able to come up with workable systems that will be able to deal with more than 90 per cent of Spit - but it is probably worth engaging in discussions with them now, rather than later.

Copyright © 2007, Quocirca

Next gen security for virtualised datacentres

More from The Register

next story
Rupert Murdoch says Google is worse than the NSA
Mr Burns vs. The Chocolate Factory, round three!
e-Borders fiasco: Brits stung for £224m after US IT giant sues UK govt
Defeat to Raytheon branded 'catastrophic result'
Germany 'accidentally' snooped on John Kerry and Hillary Clinton
Dragnet surveillance picks up EVERYTHING, USA, m'kay?
Snowden on NSA's MonsterMind TERROR: It may trigger cyberwar
Plus: Syria's internet going down? That was a US cock-up
Who needs hackers? 'Password1' opens a third of all biz doors
GPU-powered pen test yields more bad news about defences and passwords
Think crypto hides you from spooks on Facebook? THINK AGAIN
Traffic fingerprints reveal all, say boffins
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.