Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

8/6/2009
05:01 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

ISPs Team In Bot Cleanup

ISP group issues guidelines for how to clean up bot-infected consumers

It used to be that Internet service providers (ISPs) kept either a low profile or a hands-off approach to bot infections in their networks. But ISPs have gradually been getting more aggressive in the cleanup effort -- including a new best practices initiative by an ISP industry group.

The Messaging Anti-Abuse Working Group (MAAWG) recently published guidelines and best practices (PDF) for mitigating large-scale bot infections in residential networks, representing the group's first major foray into the bot battle. ISPs traditionally have been criticized for distancing themselves from the bot problem, but ISPs say times are changing.

"It used to be, we provide you a pipe and get the heck out of the way. But more and more, ISPs seem to be realizing they have a vested interest in making sure customers are protected in offering them services and online protections to do that," says Chris Roosenraad, co-vice chairman for MAAWG and a principal engineer for a major U.S. ISP. "ISPs interviewed a couple of years ago would've said, '[Bots] are a customer's problem, not ours.' Nowadays, they [know] they have the responsibility to protect their network, if nothing else."

ISPs have always had the challenge of balancing their users' privacy and network access with protecting the security of the network, which hasn't made it easy for them to take a bigger role. But bandwidth and brand reputation concerns -- along with the reality of botnet proliferation -- have forced ISPs into the spotlight.

"They've always been working on the problem, but didn't want to be high profile because it made it difficult for them to remediate the issues," says Adam O'Donnell, director of emerging technologies at Cloudmark.

O'Donnell says it has been tough for ISPs to find solutions for cleanup that scale to their networks. "A lot of products claiming to be botnet mitigation strategies either don't work or only work up to SMB scale," he says. "ISP scale has to be far more efficient."

Many ISPs offer free antivirus scanning and firewalling to their residential users, but, meanwhile, the bot count keeps growing: Bots account for about 90 percent of all spam, and bot malware now hits mobile devices and non-Windows platforms. Today's Twitter attack, which knocked the service offline temporarily and continued to cause service disruptions, is also a chilling reminder of how powerful botnets can be in waging distributed denial-of-services (DDoS).

But just how deep ISPs can drill down into their customers' bot-infected machines depends on where they are in the world, as well as their terms of service. "In Europe, customer privacy is a very high priority and is legally enshrined" in some aspects, Roosenraad says. That makes it tricky for ISPs to take a more proactive approach to getting their customers to clean their machines.

And even with their more public cleanup efforts, ISPs are still basically reacting to bot infections, not proactively halting them in their tracks. "There's not a lot we can do to prevent the infections," Roosenraad says. "That would get into customer privacy and could be incredibly invasive about what's done on [their] networks," he says.

Meanwhile, MAAWG's new guidelines for ISPs comprise three phases: detection, notification, and remediation. The best practices are a conglomeration of ISP members' methods and suggestions.

"This is the first time ISPs have stood up and said, 'This is what we think we should be doing about the problem,'" says Michael O'Reirdan, chairman of MAAWG and a distinguished engineer in national engineering and technical operations at a major U.S. ISP. "What you're seeing now is the first real, significant public focus on what ISPs can do or are doing here."

Identifying a bot in an ISP network is trickier politically than technically: The ISP has to maintain its users' privacy while not blocking or slowing legitimate traffic and not tipping off the botnet operators that they have found infected machines under their control, according to the MAAWG guidelines. They recommend a combination of network traffic inspection tools and input and feeds from other ISPs and customers. And DNS lookups can be tracked on the infected machine to look for blacklisted domains and IP addresses.

In some countries, ISPs can scan a customer's IP space for unpatched or vulnerable computers, the guidelines say.

ISPs should notify their customers with bot infections directly or using a "walled garden" or in-browser notification. A walled garden is a restricted area on the network where the infected machine can be placed while the user is alerted and his machine cleaned up. "They aren't allowed to surf beyond where the ISP wants them to," O'Reirdan says.

ISPs can also display an infection alert message in an iFrame or in part of the Web browser content to let the user know he or she is now a bot. The MAAWG guidelines say while this is an ideal way to alert a user whose machine is a bot, it's also "the most costly option."

Remediation, meanwhile, should be built around a "well-publicized" security portal where the bot-infected user can be sent to clean his machine. The portal would have educational information on what a bot is, as well as links to tools for cleanup.

ISPs say the education piece of the puzzle is crucial, especially since 80 percent of consumers are aware of bots, but only 20 percent believe they will get infected, according to a survey MAAWG released last month.

Cloudmark's O'Donnell says the next step for ISPs will be some form of HTTP filtering to prevent Web-borne bot infections. "But that's a technology that's not ready to scale for them yet," he says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message. Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Firms Improve Threat Detection but Face Increasingly Disruptive Attacks
Robert Lemos, Contributing Writer,  2/20/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9351
PUBLISHED: 2020-02-23
An issue was discovered in SmartClient 12.0. If an unauthenticated attacker makes a POST request to /tools/developerConsoleOperations.jsp or /isomorphic/IDACall with malformed XML data in the _transaction parameter, the server replies with a verbose error showing where the application resides (the a...
CVE-2020-9352
PUBLISHED: 2020-02-23
An issue was discovered in SmartClient 12.0. Unauthenticated exploitation of blind XXE can occur in the downloadWSDL feature by sending a POST request to /tools/developerConsoleOperations.jsp with a valid payload in the _transaction parameter.
CVE-2020-9353
PUBLISHED: 2020-02-23
An issue was discovered in SmartClient 12.0. The Remote Procedure Call (RPC) loadFile provided by the console functionality on the /tools/developerConsoleOperations.jsp (or /isomorphic/IDACall) URL is affected by unauthenticated Local File Inclusion via directory-traversal sequences in the elem XML ...
CVE-2020-9354
PUBLISHED: 2020-02-23
An issue was discovered in SmartClient 12.0. The Remote Procedure Call (RPC) saveFile provided by the console functionality on the /tools/developerConsoleOperations.jsp (or /isomorphic/IDACall) URL allows an unauthenticated attacker to overwrite files via vectors involving an XML comment and /.. pat...
CVE-2020-9355
PUBLISHED: 2020-02-23
danfruehauf NetworkManager-ssh before 1.2.11 allows privilege escalation because extra options are mishandled.