Spam on IP telephony

To Spit or not to Spit

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 [e-mail] - 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