Risk
9/27/2011
08:54 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Should ISPs Monitor Users' PCs To Stop Botnets?

Homeland Security's proposed code of conduct for notifying users when their PCs are infected by malware raises privacy concerns.

The Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) are proposing that service providers notify their customers whenever they detect a botnet infection on the user's PC, and then coordinate the subsequent removal of that malware.

But what's the best way to detect botnets and coordinate notifications? To answer that question, DHS and NIST last week released a voluntary notification proposal for comment--until November 4, 2011--in the Federal Register. In particular, they're seeking "information on the requirements of, and possible approaches to creating, a voluntary industry code of conduct to address the detection, notification, and mitigation of botnets." The agencies also want suggestions for "potential models for detection, notification, prevention, and mitigation of botnets' illicit use of computer equipment."

Busting botnets is a priority for the government because of "the potential economic impact of botnets and the problems they cause to computer systems, businesses, and consumers," said DHS and NIST. Notably, these networks of zombie computers are often rented out to be used as spam relays, in phishing attacks, and to launch massive, distributed denial-of-service attacks.

Furthermore, the incidence of botnets being used to commit crimes continues to increase. More coordinated botnet notifications, however, might help reduce the overall number of botnet infections, making zombie PCs more scarce. That, in turn, could make botnet-driven attacks more costly for criminals, as well as difficult to execute.

[Are your Web-connected photocopiers, scanners, and VoIP servers compromising your enterprise security? Learn more at Corporate Espionage's New Friend: Embedded Web Servers.]

The cornerstone of any such notification program would likely be for service providers--not least because they already have both contact details and a working relationship with so many PC users--to detect infections via network traffic and notify affected customers. That approach has been used since December 2010 in Australia, and recently introduced in Germany and Japan.

Businesses and government agencies in the United States also have some experience with informing botnet-infected PC owners about their malware issues. In October 2010, Comcast implemented botnet notifications as part of its Constant Guard service, run by computer security firm Damballa. According to Comcast, it may email a "service notice" to Comcast email addresses when it suspects that a user's PC is infected by malware. The email then directs users to the Constant Guard website for instructions on how to eliminate the malware.

After the FBI took down the Coreflood botnet earlier this year, any PC infected with the malware redirected to a replacement government command-and-control server, which remotely disabled the botnet. Authorities then alerted the user's service provider, requesting that it warn the user that their PC was infected with the Coreflood malware, and offer advice for eradicating the infection.

But the practice of detecting botnet infections on people's PCs raises privacy questions. "If we agree to having our packets inspected as they traverse the Internet, will the temptation to use this information to track your activities, or sell your surfing habits to marketers, be too great for ISPs to resist?" said Chester Wisniewski, a senior security advisor at Sophos Canada, in a blog post.

But he said the proposal offers great promise, as well as pragmatism in a world that too often obsesses over high-profile but incredibly rare attacks, such as Stuxnet. "The vast majority of attacks are using our own computing resources to compromise our infrastructure," he said.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web