|
Mobile networks aren’t usually thought of as sources of spam, but a quick look at some of the resources that track spam reveals they actually are. This is counter intuitive at first glance because when most people think of mobile they think of smartphones, and those aren’t known to be sources of spam (at least not yet). What’s really going on is PCs connected to mobile networks with air cards, or tethered with a smartphone where it’s permissible, are the culprits. Bot infected PCs aren’t at all uncommon, and of course bots don’t especially care if they’re using a costly mobile data service to send their spam.
This problem is serious enough that some mobile networks regularly hit blocklists. These operators have a few issues. First off, their customers may discover their mail service doesn’t work reliably when organizations using the blocklist refuse all mail from the infected network. Second, and more important, spam is useless and the wireless spectrum and bandwidth it consumes has to be considered wasted. Mobile operators might be tempted to think the bandwidth isn’t really wasted, because their subscribers are paying for it as part of their data plan. But there is an obvious customer satisfaction issue with this argument—it’s always contentious when a subscriber exceeds the limit on their data plan and has to pay a significant premium for additional bandwidth. And it’s important to remember most end users are completely unaware their machine(s) are infected so they have no idea bandwidth they are paying for is even being used.
Mobile operators have rightfully prided themselves on the security of their networks. But the presence of infected PCs and other devices connected to mobile networks, and openness of current-generation smartphones introduce new exposures to spam and other exploits that pervade fixed broadband networks. There’s a great opportunity to change this dynamic and turn a negative into a positive. There are now simple ways to manage bots and the problems they create—sending spam, stealing personal information and more. The DNS can easily be employed to disrupt communication channels between infected PCs and the control systems bots rely on to send their instructions—effectively preventing spam from being sent. MX queries from infected hosts can also be blocked to prevent spam from being sent; or redirected to special mail gateways where the messages can be handled according to operator policies. These techniques don’t introduce any latency, overhead or new equipment in the network.
This solution is a win-win for network operators and their customers. Precious mobile resources aren’t wasted and customers aren’t unknowingly paying to send useless spam. Because the solution is based in the network end users don’t have to manage anything—another big plus given the increasing frustration end users have about administering their own security.
Recently the FCC and some of the largest US service providers agreed to a voluntary code of conduct to minimize cyber threats. Join Nominum’s webinar on May 10 as guest presenter, Peter Coroneos, the former CEO of the Internet Association of Australia will talk about his experience and best practices in implementing a similar code in Australia.
Sponsored byRadix
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byVerisign
Not all bots use DNS for their c&c;. And dealing with carrier grade NAT networks (like most cellular carriers’ 3G internet connectivity) isn’t as easy as this post makes it look.
I’d agree that sticking to IETF standards, in this case Message Submission, is often a win-win solution. Applications are not always compliant, but mobile apps tend to diverge more prominently than their PC counterparts. Why?