[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 6561

Internet Engineering Task Force                             J. Livingood
Internet-Draft                                                   N. Mody
Intended status: Informational                              M. O'Reirdan
Expires: January 7, 2010                                         Comcast
                                                            July 6, 2009


   Recommendations for the Remediation of Bots in Large ISP Networks
                 draft-oreirdan-mody-bot-remediation-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Livingood, et al.        Expires January 7, 2010                [Page 1]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document contains recommendations on how large Internet Service
   Providers (ISPs) can manage the effects of large numbers of bot
   infected computers used by their subscribers via various remediation
   techniques.  At the time that this document was published, computers
   infected by bots and the users of those computers comprise a
   substantial number of users for large ISPs.  Those Internet users are
   exposed to risks such as loss of personal data, increased
   susceptibility to online fraud and/or phishing, and becoming an
   inadvertent participant in or component of an online crime, spam,
   and/or phishing network.  Mitigating the effects of and remediating
   the installations of bots affecting large numbers of Internet users
   will make it more difficult for bot nets to operate and could reduce
   the level of online crime on the Internet in general and/or on a
   particular ISP's network.





























Livingood, et al.        Expires January 7, 2010                [Page 2]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   2.  Key Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Introduction and Problem Statement . . . . . . . . . . . . . .  5
   4.  Important Notice of Limitations  . . . . . . . . . . . . . . .  6
   5.  Detection, Notification and Remediation  . . . . . . . . . . .  7
     5.1.  Detection of Bots  . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Notification to Internet Users . . . . . . . . . . . . . .  9
     5.3.  Remediation of Bot Infected Machines . . . . . . . . . . . 13
     5.4.  Guided Remediation Process . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 16
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

































Livingood, et al.        Expires January 7, 2010                [Page 3]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Key Terminology

   This section defines the key terms used in this document.

2.1.  Bots

   A "bot" (derived from the word "robot") refers to a program that is
   surreptitiously installed on a system in order to enable that system
   to automatically (or semi-automatically) perform a task or set of
   tasks typically under the command and control of a remote
   administrator, or "bot master."  Bots are also known as "zombies."
   It is important to note that there are 'good' bots.  Such benign bots
   are often found in such environments such as gaming and Internet
   Relay Chat (IRC) [RFC1459], where a continual, interactive presence
   can be a requirement for participating in the games, interacting with
   a computing resource, or other purposes.  However, for the purposes
   of this document, all mention of bots should assume that the bots
   involved are malicious in nature.  Such malicious bots shall
   generally be assumed to have been deployed without the permission or
   conscious understanding of a particular Internet user.  Thus, without
   a user's knowledge, bots may transform the user's computing device
   into a platform from which malicious activities are conducted.

2.2.  Bot Networks, or Bot Nets

   These are defined as concerted networks of bots capable of acting on
   instructions generated remotely.  The malicious activities are either
   focused on the information on the local machine or acting to provide
   services for remote machines.  Bots are highly customizable so they
   can be programmed to do many things.  The major malicious activities
   include: identity theft, spam, denial of service attacks, key-
   logging, fraudulent DNS, proxy services, hosting and click fraud.
   Infection vectors include un-patched operating systems, software
   vulnerabilities, weak/non-existent passwords, malicious websites, un-
   patched browsers, malware and social engineering techniques to gain
   access to the user's computer.  The detection and destruction of bots
   is an ongoing issue and also a constant battle between anti-virus
   developers and bot developers.  Initially botnets utilized IRC to
   communicate but were easy to shutdown if the command and control
   server was identified and deactivated.  However, with the
   introduction of P2P, HTTP and other technologies including



Livingood, et al.        Expires January 7, 2010                [Page 4]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   encryption, bots are considerably more difficult to identify.  As a
   result increased reliance is being placed on behavioral analysis both
   locally and remotely to identify bots.

2.3.  Computer

   A computer, as used in the context of this document, is intended to
   encompass the various personal computing devices used by Internet
   users.  This may include devices ranging from so-called personal
   computers, including laptops, desktops, and netbooks, as well as
   mobile phones, smart phones, home gateway devices, and other end user
   computing devices which are connected or can connect to the public
   Internet and/or private IP networks.

2.4.  Malware

   This is short for "malicious software."  In this case, malicious bots
   are considered a subset of malware, which could also include viruses
   and other similar types of software.  Internet users can sometimes
   cause their computer to be infected with malware, which may include a
   bot or cause a bot to install itself, via inadvertently accessing a
   specific website, downloading a specific file, or other activities.


3.  Introduction and Problem Statement

   Computers used by Internet users, which in this case are customers of
   an Internet Service Provider (ISP), can be infected with malware
   which may contain and/or install one or more bots on a computer.
   This can present a major problem for an ISP for a number of reasons
   (not to mention, of course, the problems created for users).  First,
   these bots can be used to send spam, in some cases very large volumes
   of spam.  This spam can result in extra cost for the ISPs in terms of
   wasted network, server, and/or personnel resources, among many other
   potential costs or side effects.  Such spam can also negatively
   affect the reputation of the ISP, their customers, and the email
   reputation of the IP address space used by the ISP (often referred to
   simply as "IP reputation").

   In addition, these bots can act as platform for directing,
   participating in, or otherwise conducting attacks on critical
   Internet infrastructure.  Bots are frequently used as part of
   concerted Distributed Denial of Service (DDoS) attacks for criminal,
   political, anarchistic, or other motivations.  For example, bots have
   been used to attack Internet resources and infrastructure ranging
   from web sites, to email servers and DNS servers, as well as the
   critical Internet infrastructure of entire countries.




Livingood, et al.        Expires January 7, 2010                [Page 5]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   While any computing device, including computers used by Internet
   users to the servers operated by ISPs and other organizations can be
   infected with bots, the majority of bot infections affect the
   computers used by Internet users.  ISPs have a unique potential role
   when it comes to detecting botnets because they provide IP
   connectivity for the "good" and "bad" traffic coming from user
   systems.  Furthermore, ISPs may also be in a unique position to be
   able to communicate to Internet users which are their customers, when
   customers computers may have been determined to have been or possibly
   have been infected with one or more bots.

   From an end user perspective, knowing that their computer has been
   infected with one or more bots of very important information.  Once
   they know this, they can take steps to remove the bot, protect
   themselves in the future, and resolve any problems which may stem
   from the bot infection.  Given that bots can not only drain their
   local computing and network resources, but also enable the theft of
   personal information (including personal financial information), it
   is important to help users identify when they may have been infected
   with a bot.

   As a result, the intent of this document is to provide a guide to
   ISPs and other organizations for the remediation of these computers
   infected with bots, so as to reduce the size of bot nets and minimize
   the potential harm that bots can inflict upon Internet infrastructure
   generally, as well as on individual Internet users.  Efforts by ISPs
   and other organizations could therefore, over time, reduce the pool
   of computers infected with bots on the Internet, which in turn could
   result in smaller bot nets with less capability for disruption.


4.  Important Notice of Limitations

   The techniques described in this document in no way guarantee the
   remediation of all bots.  Bot removal is potentially a task requiring
   specialized knowledge, skills and tools, and may be beyond the
   ability of average users.  Attempts at bot removal may frequently be
   unsuccessful, or only partially successful, and may leave a user's
   system in an unstable and unsatisfactory state or even still
   infected.  Attempts at bot removal can also result in side effects
   ranging from a loss of data or other files, all the way through
   partial or complete loss of system usability.

   In general, the only way a user can be sure they have removed some of
   today's increasingly sophisticated malware is by "nuking-and-paving"
   the system: reformatting the drive, reinstalling the operating system
   and applications (including all patches) from scratch, and then
   restoring user files from a clean backup.



Livingood, et al.        Expires January 7, 2010                [Page 6]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


5.  Detection, Notification and Remediation

   The potential mitigation of bots is accomplished through a process of
   detection, notification to Internet users, and remediation of that
   bot with a variety of tools.

5.1.  Detection of Bots

   An ISP must first identify that an Internet user, in this case a user
   that is assumed to be their customer or otherwise connected to the
   ISP's network, is determined to be infected, or likely to have been
   infected with a bot.  The ISP should attempt to detect the presence
   of bots using methods, processes, and tools which maintain the
   privacy of the personally identifiable information of their
   customers.  The ISP also should not block legitimate traffic in the
   course of bot detection, and should instead employ detection methods,
   tools, and processes which seek to be non-disruptive, as well as
   transparent to both Internet users as well as the people who are
   deploying and/or operating bot nets.

   Detection methods, tools, and processes may include things such as
   analysis of specific network and/or application traffic flows (such
   as traffic to an email server), analysis of aggregate network and/or
   application traffic data, data feeds received from other ISPs and
   organizations (such as lists of the ISP's IP addresses which have
   been reported to have sent spam), feedback from the ISP's customers
   or other Internet users, as well as a wide variety of other
   possibilities.  It is likely that a combination of all of the
   multiple bot detection data points will prove to be the most
   effective approach, in order to corroborate information of varying
   dependability or consistency, as well as to avoid or minimize the
   possibility of false positive identification of computers.  Detection
   should also, where possible and feasible, attempt to classify a bot
   in order to confirm that it is malicious in nature, estimate the
   variety and severity of threats it may pose (such as spam bot, key
   logging bot, file distribution bot, etc.), and to determine a
   potential methods for eventual remediation.

   Detection is also time-sensitive.  If complex analysis is required
   and multiple confirmations are needed to confirm a bot is indeed
   present, then it is possible that the bot will do its damage before
   it can be stopped.  This may mean that an ISP may need to balance the
   desire or need to definitively classify and/or confirm a bot, which
   may take an extended period of time, with the ability to predict the
   strong likelihood of a bot in a very short period of time.  This also
   means that Internet users may benefit from the deployment of client-
   based software protections or other software tools, which can enable
   rapid performance of heuristically-based detection bot activity, such



Livingood, et al.        Expires January 7, 2010                [Page 7]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   as the detection of a bot as it starts to communicate a bot net and
   execute some type of command.  Any bot detection systems should also
   be capable of learning and adapting, either via manual intervention
   or automatically, in order to cope with a rapidly evolving threat.

   As noted above, detection methods, tools, and processes should ensure
   that privacy of customers' personally identifiable information is
   maintained.  While bot detection methods, tools, and processes are
   similar to spam and virus defenses deployed by the ISP for the
   benefits of their customers (and may be directly related to those
   defenses), attempts to detect bots should take into account the need
   of an ISP to take care to ensure that such personally identifiable
   information is properly protected.  Finally, depending upon the
   geographic region within which an ISP operates, certain methods
   relating to bot detection may need to be included in relevant terms
   of service documents or other documents which are available to the
   customers of a particular ISP.

   There are several bot detection methods, tools, and processes that an
   ISP may choose to utilize, as noted in the list below.  It is
   important to note that the technical solutions available are
   relatively immature, and are likely to change over time, and to
   evolve rapidly in the coming years.  While these items are described
   in relation to ISPs, they may also be applicable to organizations
   operating other networks, such as campus networks and enterprise
   networks.

   a.  Where legally permissible or otherwise an industry accepted
       practice in a particular market region, an ISP may in some manner
       "scan" their IP space in order to detect un-patched or otherwise
       vulnerable hosts.  This may provide the ISP with the opportunity
       to easily identify Internet users who appear to already be or are
       at great risk of being infected with a bot.  Such scanning should
       be an unobtrusive and non-disruptive to users and user computers
       as possible, using tools which such as NMAP
       (http://www.nmap.org), Nessus (http://www.nessus.org), etc.

   b.  An ISP may also communicate and share selected data, via feedback
       loops or other mechanisms, with various third parties.  Feedback
       loops are consistently formatted feeds of real-time (or nearly
       real-time) abuse reports offered by threat data clearinghouses,
       security alert organizations, ISPs, and other organizations.  The
       data may include, but is not limited to, lists of the IP
       addresses computers which have or are likely to have a bot
       running, domain names or fully qualified domain names (FQDNs)
       known to host malware and/or be involved in the command and
       control of bot nets, IP addresses know to host malware and/or be
       involved in the command and control of bot nets, recently tested



Livingood, et al.        Expires January 7, 2010                [Page 8]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


       or discovered techniques or detecting or remediating bot
       infections, new threat vectors, and other relevant information.

   c.  An ISP may use Netflow [RFC3954] or other similar passive network
       monitoring to identify bots.  For example, an ISP may be able to
       identify compromised hosts by identifying traffic destined to IP
       addresses associated with the command and control of bot nets.

   d.  An ISP may use DNS-based techniques to perform detection.  For
       example, a given classified bot may be known to query a specific
       list of domain names at specific times or on specific dates (in
       the example of the so-called "Konficker" bot network), typically
       by matching DNS queries to a well known list of domains
       associated with malware.  In many cases such lists are
       distributed by or shared using third parties, such as threat data
       clearinghouses.

   e.  User complaints: Because botted hosts are frequently used to send
       spam, the ISP servicing those botted hosts will normally receive
       complaints about that spam.  Those complaints may be sent to
       RFC2142-specified [RFC2142] role accounts, such as abuse@ or
       postmaster@ or to abuse or security addresses specified by the
       site as part of its WHOIS (or other) contact data.

   f.  ISPs may also discover likely botted hosts located at other
       sites; when legally permissible or otherwise an industry accepted
       practice in a particular market region, it may be worthwhile for
       ISPs to share evidence relating to those compromised hosts with
       the relevant remote ISP, with security researchers, and with
       blocklist operators.

5.2.  Notification to Internet Users

   Once an ISP has detected a bot, or the strong likelihood of a bot,
   steps should be undertaken to inform the Internet user that they may
   have a bot-related problem.  Depending upon a range of factors, from
   the technical capabilities of the ISP, to the technical attributes of
   their network, financial considerations, available server resources,
   available organizational resources, the number of likely infected
   computers detected at any given time, and the severity of any
   possible threats, among many other things, an ISP will decide the
   most appropriate method or methods for providing notification to one
   or more of their customers or Internet users.  Such notification
   methods may include one or more of the following, as well as other
   possible methods not described below.  It is important to note that
   none of these methods are guaranteed to be successful, as each has
   its own set of limitations.  In addition, in some cases, and ISP may
   determine that a combination of two or more methods is most



Livingood, et al.        Expires January 7, 2010                [Page 9]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   appropriate.  Finally, notification is also considered time
   sensitive; if the user does not receive or view the notification or a
   timely basis, then a particular bot could launch an attack, exploit
   the user, or cause other harm.

5.2.1.  Email Notification

   This is probably the most common form of notification used by ISPs.
   One drawback of using email is that it is not guaranteed to be viewed
   within a reasonable time frame, if at all.  The user may be using a
   different primary email address than that which they have provided to
   the ISP.  In addition, some ISPs do not provide an email account at
   all, as part of a bundle of Internet services, and/or do not have a
   need for or manner in which to request or retain the primary email
   addresses of Internet users of their networks.  Another possibility
   is that the user, their email client, and/or their email servers
   could determine or classify such a notification as spam, which could
   delete the message or otherwise file it in an email folder that the
   user may not check on a regular and/or timely basis.  Finally if the
   user's email credentials are compromised, then a hacker and/or a bot
   could simply login to the user's email account and delete the email
   before it is read by the user.

5.2.2.  Telephone Call Notification

   A telephone call may be an effective means of communication in
   particularly high-risk situations.  However, telephone calls may not
   be feasible due to the cost of making a large number of times, as
   measured in either time, money, organizational resources, server
   resources, or some other means.  In addition, there is no guarantee
   that the user will answer their phone.  To the extent that the
   telephone number called by the ISP can be answered by the infected
   computing device, the bot on that computer may be able to disconnect,
   divert, or otherwise interfere with an incoming call.  Users may also
   interpret such a telephone notification as a telemarketing call and
   as such not welcome it, or not accept the call at all.  Finally, even
   if a representative of the ISP is able to connect with and speak with
   a user, that user is very likely to lack the necessary technical
   experience to understand or be able to effectively deal with the
   threat.

5.2.3.  Postal Mail Notification

   This form of notification is probably the least popular means of
   communication, due to both preparation time, delivery time and cost.






Livingood, et al.        Expires January 7, 2010               [Page 10]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


5.2.4.  Walled Garden Notification

   Placing a user in a so-called walled garden is another approach that
   ISPs may take to notify users.  This is an effective technique
   because it could be able to block all communication between the bot
   and the command and control channel, which may impair the ability of
   a bot to disrupt or block attempts to notify the user.

   While in many cases, the user is almost guaranteed to view the
   notification message and take any appropriate remediation actions,
   this approach poses can pose other challenges.  For example, it is
   not always the case that a user is actively using a computer that
   uses a web browser or which has a web browser actively running on it.
   In one case, a user could be playing a game online, via the use of a
   dedicated, Internet-connected game console.  In another case, the
   user may not be using a computer with a web browser when they are
   placed in the walled garden and may instead be in the course of a
   telephone conversation, or may be expecting to receive a call, using
   a Voice Over IP (VOIP) device of some type.  As a result, the ISP may
   feel the need to maintain a potentially lengthy white list of domains
   which are not subject to the typical restrictions of a walled garden,
   which could well prove to be an onerous task, from an operational
   perspective.

   The ISP has several options to determine when to let the user out of
   the walled garden.  One approach may be to let the user determine
   when to exit.  This option is suggested when the purpose of the
   walled garden is to notify users and provide information on
   remediation only, particularly since notification is not a guarantee
   of successful remediation.  It could also be the case that, for
   whatever reason, the user makes the judgement that they cannot then
   take the time to remediate their computer and that other online
   activities which they would like to resume are more important.

   Once the user acknowledges the notification, then the user decides to
   either remediate and then exit the walled garden, or exit the walled
   garden without addressing the issue.  Another approach may be to
   enforce a stricter policy and require the user to clean the computer
   prior to permitting the user to exit the walled garden, though this
   may not be technically feasible depending upon the type of bot,
   obfuscation techniques employed by a bot, and/or a range of other
   factors.  Thus, the ISP may also need to support tools to scan the
   infected computer and determine whether it is still infected or rely
   on user judgement that the bot has been disabled or removed.  One
   challenge with this approach is that if the user has multiple
   computers sharing a single IP address, such as via a common home
   gateway device which performs Network Address Translation (NAT), then
   the ISP may need to determine from user feedback or other means that



Livingood, et al.        Expires January 7, 2010               [Page 11]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   all affected computers have been remediated, which may or may not be
   technically feasible.

5.2.5.  Instant Message Notification

   Instant Message (IM): Instant messaging provides the ISP with a
   simple means to communicate with the user.  There are several
   advantages of using IM which makes it an attractive option.  First,
   if the ISP provides IM service and the user subscribes to it then the
   user can be notified easily.  Second, IM based notification can be
   cost effective means to communicate with the use.  This can be
   achieved by signing up for IM service with the various popular IM
   providers and programatically messaging, if permitted by the
   acceptable usage policy, the notifications.  However, it IM based
   notification can also be done manually by the ISP's support staff.
   Ideally, the ISP should allow the user to register the IM identity
   and seek permission to be contacted via this mean.  Third, if the IM
   service provider supports offline messaging the user can be notified
   regardless of their signed in status.  Essentially a message can be
   sent and when the user signs in they would receive it.  There are
   several drawbacks with this communications method.  First, there is a
   high probability that subscriber may interpret the communication to
   be spam and as such ignore it.  Second, not every user uses IM and/or
   the user may not provide their IM identity to the ISP so some
   alternative means have to be used.  Third, there maybe a privacy
   concern when the communication between the ISP and the end user is
   not secure and over a third party network and/or IM service.  As such
   the notification must be discreet and not provide any personally
   identifiable information.

5.2.6.  Short Message Service (SMS) Notification

   Short Message Service (SMS): SMS allows the ISP send a brief
   description of the problem to notify the user of the issue.  ISP
   should allow users to register their mobile number for notifications
   and also allow users to opt out if they do not wish to be notified.
   The primary advantage of SMS is that users are used to receiving text
   messages and are likely to read them.  Although users may not act on
   it immediately if they are not in front of their computer system.
   One disadvantage is that ISPs may have to follow up with an alternate
   means of communication if since a SMS message is restricted to 166
   characters and not all of the necessary information maybe conveyed in
   one message.  Another disadvantage is the cost associated with SMS.
   The ISP has to either build its own SMS gateway to interface with the
   various wireless providers or use a third party provider to notify
   users.  It is recommended that the ISP absorb the cost of
   notification and should always state in the notification that the
   message is free of charge to the user.  Another small disadvantage is



Livingood, et al.        Expires January 7, 2010               [Page 12]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   that it is possible to notify the wrong user if the intended user
   changes their mobile number but forgets to update it with the ISP.

5.2.7.  Web Browser Notification

   Near real-time notification to the user's web browser is another
   technique that may be utilized for notifying the user, though how
   such a system might operate is outside the scope of this document.
   Such a notification could have a comparative advantage over a walled
   garden notification, in that it does not restrict traffic to a
   specified list of destinations in the same way that a walled garden
   by definition would.  However, as with a walled garden notification,
   there is no guarantee that a user is at any given time making use of
   a web browser, though such a system could certainly provide a
   notification when such a browser is eventually used.  Compared to a
   walled garden, a web browser notification is probably preferred from
   the perspective of Internet users, as it does not have the risk of
   disrupting non-web sessions, such as online games, etc. (as noted in
   Section 5.2.4).

5.3.  Remediation of Bot Infected Machines

   This section covers the different options available to remediate a
   computer, which means to remove, disable, or otherwise render a bot
   harmless.  Prior to this step, an ISP has detected the bot, notified
   the user that one of their computers is infected with a bot, and now
   has to provide some means to clean the PC.  The generally recommended
   approach is to provide the necessary tools and education to the user
   so that they may perform bot remediation themselves.

   For example, this may include the creation of a special Security Web
   Portal.  This should be a well-publicized security portal to which a
   user with a bot problem can be directed to for remediation.  This
   Security Web Portal should clearly explain why the user was notified
   and may include an explanation of what bots are and the threats that
   they pose.  There should be a clear explanation of the steps that the
   user should take in order to clean the computers and provide
   information on how users can keep the computer free of future
   infections.  The Security Web Portal should have a guided process
   that takes non technical users through the remediation process.

   In terms of the text user to explain what bots are and the threat
   they pose, something simple such as this may suffice:

   "What is a bot?  A bot is a piece of software, generally installed on
   your machine without your knowledge, which either sends spam or tries
   to steal your personal information.  They can be very difficult to
   spot, though you may have noticed that your computer is running much



Livingood, et al.        Expires January 7, 2010               [Page 13]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   more slowly than usual or you notice regular disk activity even when
   you are not doing anything.  Ignoring this problem is not really an
   option since your personal information is currently at risk.  Thus,
   bots need to be removed to protect your data and your personal
   information."

5.4.  Guided Remediation Process

   Minimally the Guided Remediation Process should include options
   and/or recommendations on how a user should:

   1.  If the user is interested in reporting his or her computer's bot
       infection to an applicable law enforcement authority, then the
       computer effectively becomes a cyber "crime scene" and should not
       be mitigated unless or until law enforcement has collected the
       necessary evidence.  For individuals in this situation, the ISP
       should refer them to local, state, federal, or other relevant
       computer crime offices.  (Note: Some "minor" incidents, even if
       highly traumatic to the user, may not be sufficiently serious for
       law enforcement to commit some of their limited resources to an
       investigation.)

   2.  Regardless of whether the user or a knowledgeable technical
       assistant is working on remediating the computer, their first
       task should be to determine which of multiple potentially-
       infected machines may be the one that needs attention (in the
       common case of multiple computers in a home network).  Sometimes,
       as in cases where there is only a single directly-attached
       computer, or the user has been noticing problems with one of
       their computers, this can be easy.  Other times, it may be more
       difficult.  If the user is behind a home gateway/router, then the
       first task may be to ascertain which of the machines is infected.
       In some cases the user may have to check all machines to identify
       the infected one.  Thus, it is possible that an individual
       computer may have multiple bot infections and, in addition,
       multiple computers on the home network may be infected.

   3.  Perform a FULL backup of the affected computers.

   4.  Download OS patches and Anti-Virus (A/V) software updates.  For
       example, for OS patches, links could be provided to Microsoft
       Windows updates and Apple MacOS updates could be provided.

   5.  Run a scan using installed A/V software.

   6.  Explain how to configure the computer to automatically install
       updates for the OS, A/V and other common Web Browsers such as
       Microsoft Internet Explorer, Mozilla Firefox, Apple Safari,



Livingood, et al.        Expires January 7, 2010               [Page 14]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


       Opera, and Google Chrome.

   7.  The flow should also have the option for users to get
       professional assistance if they are unable to remove the bots
       themselves.  If purchasing third party assistance, then the user
       should be encouraged to pre-determine how much they are willing
       to pay for that help.  If the computer that is being remediated
       is old and can easily be replaced with a new, faster, larger and
       more reliable system for three or four hundred dollars, the it
       makes no sense to spend five or six hundred dollars to fix the
       old computer, for example.  On the other hand, if the customer
       has a brand new computer that cost several thousand dollars, it
       might make perfect sense to spend the money in attempting to
       remediate it.

   8.  User surveys to solicit feedback on whether the notification and
       remediation process is effective and what recommended changes
       could be made in order to improve the ease, understandability,
       and effectiveness the remediation process.

   There are many cases where a user may not be a residential user, in
   which case some of these steps may not apply.  For example, the user
   may be part of a business, educational institution, non-profit
   company, or other organization.  In these cases, the user should
   immediately seek out the support of their information technology
   support team.


6.  Security Considerations

   Scanning systems for missing patches, while a good and necessary
   task, may nonetheless result in systems being knocked offline.

   Conveying a system to a third party for cleaning may result in
   sensitive contents of that system (confidential email or images,
   unauthorized access to remote systems via stored passwords, etc.)
   being inadvertently disclosed to the third party.

   Passive network monitoring, even of encrypted traffic, may result in
   sensitive information leaking (e.g., merely knowing that a user is
   connecting to a site about a particular subject may prompt one to
   infer an interest in that particular subject).


7.  IANA Considerations

   There are no IANA considerations in this document.




Livingood, et al.        Expires January 7, 2010               [Page 15]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


8.  Contributors

   The authors wish to acknowledge the following individuals for their
   textual contribution to and detailed reviews of this document:

   Joe St. Sauver, University of Oregon and Internet2 (joe@uoregon.edu)


9.  Normative References

   [RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
              RFC 1459, May 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", RFC 3954, October 2004.


Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -00 version:

   o  -00 version published


Appendix B.  Open Issues

   [RFC Editor: This section is to be removed before publication]

   Could use some informational references in Section 3

   Fix the odd list spacing in Section 5.1

   Add some point about notification to large networks may not be useful
   -- such as coffee shops or hotels with WiFi networks.

   Consider combining 5.b and 5.f., and possibly re-wording some of the
   other items.

   Consider adding mention to the use of ccleaner in section 5.4




Livingood, et al.        Expires January 7, 2010               [Page 16]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   Significantly revise and expand section 5.4

   Add discussion of root kits and other bits of malware that may
   actively resist detection and removal (e.g., attempting to disinfect
   a system while running an infected OS can be a rather futile
   exercise; you have a much better chance of detecting malware if you
   mount the infected disk on a third party system for review and
   disinfection)

   add discussion on restoring files from the backups if nuke and pave
   is required.

   add discussion of user education to help prevent repeat infections

   consider adding discussion of the ISP's role in the remediation
   process -- I think this is a key consideration.  Liability issues,
   cost issues and other factors should be laid out so that users
   understand why the ISP doesn't just "do it for them."


Authors' Addresses

   Jason Livingood
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: jason_livingood@cable.comcast.com
   URI:   http://www.comcast.com


   Nirmal Mody
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: nirmal_mody@cable.comcast.com
   URI:   http://www.comcast.com









Livingood, et al.        Expires January 7, 2010               [Page 17]

Internet-Draft  Remediation of Bots in Large ISP Networks      July 2009


   Mike O'Reirdan
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: michael_oreirdan@cable.comcast.com
   URI:   http://www.comcast.com










































Livingood, et al.        Expires January 7, 2010               [Page 18]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/