| TOC |
|
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 March 19, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. Internet users with infected computers are exposed to risks such as loss of personal data, as well as increased susceptibility to online fraud and/or phishing. Such computers can also become an inadvertent participant in or component of an online crime network, spam network, and/or phishing network, as well as be used as a part of a distributed denial of service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network.
1.
Requirements Language
2.
Key Terminology
3.
Introduction and Problem Statement
4.
Important Notice of Limitations and Scope
5.
Detection of Bots
6.
Notification to Internet Users
7.
Remediation of Compters Infected with a Bot
8.
Guided Remediation Process
9.
Security Considerations
10.
IANA Considerations
11.
Acknowledgements
12.
Informative references
Appendix A.
Document Change Log
Appendix B.
Open Issues
§
Authors' Addresses
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
This section defines the key terms used in this document.
| TOC |
A malicious "bot" (derived from the word "robot", hereafter simply referred to as a "bot") 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', or benign bots. Such benign bots are often found in such environments such as gaming and Internet Relay Chat (IRC) [RFC1459] (Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” May 1993.), 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 can be conducted.
| TOC |
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, distributed denial of service (DDoS) attacks, key-logging, fraudulent DNS (pharming), proxy services, fast flux hosting and click fraud.
Infection vectors include un-patched operating systems, software vulnerabilities, weak/non-existent passwords, malicious websites, un-patched browsers, malware, vulnerable helper applications 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 the internet security community, network security engineers and bot developers.
Initially, bots used IRC to communicate but were easy to shutdown if the command and control server was identified and deactivated. Newer command and control methods have evolved, such that those currently employed by bot masters make them much more resistant to deactivation. With the introduction of P2P, HTTP and other resilient communication protocols along with the widespread adoption of encryption, bots are considerably more difficult to identify and isolate from typical network usage. As a result increased reliance is being placed on anonmaly detection and behavioral analysis, both locally and remotely, to identify bots.
| TOC |
A computer, as used in the context of this document, is intended to refer to a computing device that connects to the Internet. This encompasses devices used by Internet users such as 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.
Increasingly, other household systems and devices contain embedded computers which are connected to or can connect to the public Internet and/or private IP networks. However, these devices may not be under interactive control of the Internet user, such as may be the case with various smart home and smart grid devices.
| TOC |
This is short for malicious software. In this case, malicious bots are considered a subset of malware. Other forms of malware could 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.
Alternatively, Internet-connected computers may become infected with malware through externally initiated malicious activities such as the exploitation of vulnerabilities or the brute force guessing of access credentials.
| TOC |
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 and 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 platforms 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 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. Motivations for such coordinated DDoS attacks can range from criminal extortion attempts through to online protesting and nationalistic fervor.
While any computing device can be infected with bots, the majority of bot infections affect the personal computers used by Internet end users. As a result of the role of ISPs in providing IP connectivity, among many other services, to Internet users, these ISPs are in a unique position to be able to attempt to detect and observe bot nets operating in their networks. 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 is 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 drain local computing and network resources, enable theft of personal information (including personal financial information), enable the computer to be used from criminal activities (that may result in the Internet user being legally culpable), destroy or leave the PC in an unrecoverable state via 'kill switch' bot technologies, it is important to notify the user that they may be 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.
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, as described later in this document.
| TOC |
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 in a state where it is 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. However the introduction of BIOS-based malware may mean that, in some cases, this will not be enough and may prove to be more than any end user can be reasonably expected to resolve.
Devices with embedded operating systems, such as video gaming consoles and smart home appliances, will most likely be beyond a user's capability to remediate by themselves, and will typically require the aid of vendor-specific advice, updates and tools. Care must be taken when imparting remediation advice to Internet users given the increasingly wide array of computing devices that can be, or could be, infected by bots in the future.
| TOC |
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 (PII) 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 being transparent to Internet users and end-user applications.
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 multiple bot detection data points will prove to be an 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 potential methods for eventual remediation. However, given the dynamic nature of botnet management and the criminal incentives to seek quick financial rewards, botnets frequently update or change their core malicious capabilities. As a consequence, botnets that are initially detected and classified by the ISP as one particular type of bot need to be continuously monitored and tracked in order to correctly identify the threat they pose at any particular point in time.
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 may cause some damage (to either the infected computer or a remotely targeted system) 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 'definitive-vs-likely' challenge is difficult and, when in doubt, ISPs should probably err on the side of caution by communicating when a likely bot infection has taken place. 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 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' PII is maintained. While bot detection methods, tools, and processes are similar to spam and virus defenses deployed by the ISP for the benefit 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 any PII collected or incidentally detected 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, evolving 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. ISP's should note that some types of port scanning may leave network services in a hung state or render them unusable due to common frailties, and that many modern firewall and host-based intrusion detection implementations may alert the Internet user to the scan. As a result the scan may be interpreted as a malicious attack against the computer. Vulnerability scanning has a higher probability of leaving accessible network services and applications in a damaged state and will often result in a higher probability of detection by the Internet user and subsequent interpretation as a targeted attack. Depending upon the vulnerability being scanned, some automated methods of vulnerability checking may result in data being altered or created afresh on the Internet users computer which be a problem in many legal environments.
- 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, other 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 botnets, IP addresses know to host malware and/or be involved in the command and control of botnets, recently tested or discovered techniques or detecting or remediating bot infections, new threat vectors, and other relevant information. Good examples of this include SNDS from Microsoft, XBL and PBL from Spamhaus and the DSHIELD AS tool from the SANS Institue.
- c.
- An ISP may use Netflow [RFC3954] (Claise, B., “Cisco Systems NetFlow Services Export Version 9,” October 2004.) or other similar passive network monitoring to identify network anomalies that may be indicative of botnet attacks or bot communications. 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 botnets. In addition, bots can be idenfied when a remote host is under a DDoS attack because computers participating in the attack will likely be infected by a bot, frequently as observed at network borders.
- 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 "Conficker" bot), often 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 hosts infected by bots are frequently used to send spam or participate in DDoS attacks, the ISP servicing those hosts will normally receive complaints about the malicious network traffic. Those complaints may be sent to RFC2142-specified [RFC2142] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.) 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 bot infected 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.
- g.
- ISPs may operate or subscribe to services that provide 'sinkholing' or 'honeynet' capabilities. This may enable the ISP to obtain near-real-time lists of bot infected computers as they attempt to join a larger botnet or propagate to other hosts on a network.
| TOC |
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 should 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, and that each has its own set of limitations. In addition, in some cases, an ISP may determine that a combination of two or more methods is most 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. If possible, an ISP should establish a preferred means of communication when the subscriber first signs up for service. As a part of the notification process, ISPs should maintain a record of the allocation of IP addresses to subscribers for such a period as allows any bot detection technology to be accurately able to link an infected IP address to a subscriber. This record should only be maintained for a period of time which is necessary, in order to maintain the protection of the privacy of an individual subscriber.
One important factor to bear in mind is that notification to end users needs to be defended against spoofing by third parties. This must be done to protect against the possibility of notifications being spoofed and used by bots to deliver additional malware.
| TOC |
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 method 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. Bot masters have also been known to impersonate the ISP or trusted sender and send fradulant emails to the users. This technique of solical engineering, generally referred to as 'phishing', often leads to new bot infestations. 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.
| TOC |
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 calls, 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 to a user, that user is very likely to lack the necessary technical expertise to understand or be able to effectively deal with the threat.
| TOC |
This form of notification is probably the least popular and effective means of communication, due to both preparation time, delivery time, the cost of printing and paper, and the cost of postage.
| TOC |
Placing a user in a walled garden is another approach that ISPs may take to notify users. A walled garden refers to an environment that controls the information and services that a subscriber is allowed to utilize and what network access permissions are granted. 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 example, a user could be playing a game online, via the use of a dedicated, Internet-connected game console. In another example, 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 judgment 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. Exit from the walled garden may also involve a process to verify that it is indeed the user who is requesting exit from the walled garden and not the bot.
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 judgment 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). In such a case, the ISP may need to determine from user feedback, or other means, that all affected computers have been remediated, which may or may not be technically feasible.
Finally, when a walled garden is used, a list of well-known addresses for both operating system vendors and security vendors should be created and maintained in a white list which permits access to these sites. This can be important for allowing access from the walled garden by end users in search of operating system and application patches.
| TOC |
Instant messaging provides the ISP with a simple means to communicate with the user. There are several advantages to using IM which makes it an attractive option. If the ISP provides IM service and the user subscribes to it, then the user can be notified easily. IM-based notification can be a cost effective means to communicate with users automatically from an IM alert system or via a manual process, by the ISP's support staff. Ideally, the ISP should allow the user to register their IM identity in an ISP account management system and grant permission to be contacted via this means. If the IM service provider supports off-line messaging, then the user can be notified regardless of whether they are currently logged into the IM system.
There are several drawbacks with this communications method. There is a high probability that subscriber may interpret the communication to be spam, and as such ignore it. Also, 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. Even in those cases where a user does have an IM address, they may not be signed onto that IM system when the notification is attempted. There maybe also be a privacy concern on the part of users, when such an IM notification must be transmitted over a third-party network and/or IM service. As such, should this method be used, the notification should be discreet and not include any PII in the notification itself.
| TOC |
SMS allows the ISP send a brief description of the problem to notify the user of the issue, typically to a mobile device such as a mobile phone or smart phone. Ideally, the ISP should allow the user to register their mobile number and/or SMS address in an ISP account management system and grant permission to be contacted via this means. The primary advantage of SMS is that users are familiar with receiving text messages and are likely to read them. However, users may not act on the notification immediately if they are not in front of their computer system at the time of the SMS notification.
One disadvantage is that ISPs may have to follow up with an alternate means of notification if not all of the necessary information maybe conveyed in one message, given constraints on the number of characters in an individual message (typically 140 characters). Another disadvantage with SMS is the cost associated with it. The ISP has to either build its own SMS gateway to interface with the various wireless network service providers or use a third-party SMS clearinghouse (relay) to notify users. In both cases, an ISP will typically pay on a per-message basis to send SMS notifications. An additional downside is that SMS messages sent to a user may result in a charge to the user by their wireless provider, depending upon the plat to which they subscribe. Another minor disadvantage is 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.
There are several other drawbacks with this communications method. There is a high probability that subscriber may interpret the communication to be spam, and as such ignore it. Also, not every user uses SMS and/or the user may not provide their SMS address or mobile number to the ISP. Even in those cases where a user does have an SMS address or mobile number, their device may not be powered on or otherwise available on a wireless network when the notification is attempted. There maybe also be a privacy concern on the part of users, when such an SMS notification must be transmitted over a third-party network and/or SMS clearinghouse. As such, should this method be used, the notification should be discreet and not include any PII in the notification itself.
| TOC |
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, VoIP calls, etc. (as noted in Section 6.4 (Walled Garden Notification)).
| TOC |
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 may provide some recommended means to clean the computer. The generally recommended approach is to provide the necessary tools and education to the user so that they may perform bot remediation themselves, particularly given the risks and difficulties inherent in attempting to remove a bot.
For example, this may include the creation of a special web site with security-oriented content that is dedicated for this purpose. This should be a well-publicized security web site to which a user with a bot infection can be directed to for remediation. This security web site 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 attempt to clean their computer and provide information on how users can keep the computer free of future infections. The security web site should also have a guided process that takes non-technical users through the remediation process, on an easily understood, step-by-step basis.
In terms of the text used to explain what bots are and the threats that 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 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."
It is also important to note that it may not be immediately apparent to the Internet user precisely which devices have been infected with a particular bot. This may be due to the user's home network configuration, which may encompass several computers, where a home gateway which performs Network Address Translation (NAT) to share a single public IP address has been used. Therefore, any of these devices can be infected with a bot. The consequence of this for an ISP is that remediation advice may not ultimately be immediately actionable by the Internet user, as that user may need to perform additional investigation within their own home network.
An added complication is that the user may have a bot infection on a device such as a video console, multimedia system, appliance, or other end-user computing device which does not have a typical Windows or Macintosh user interface. As a result, diligence needs to be taken by the ISP where possible such that they can identify and communicate the specific nature of the device that has been infected with a bot, and further providing appropriate remediation advice.
| TOC |
Minimally the Guided Remediation Process should include options and/or recommendations on how a user should:
| TOC |
This document describes in detail the numerous security risks and concerns relating to bot nets. As such, it has been appropriate to include specific information about security in each section above. This document describes the security risks related to malicious bot infections themselves, such as enabling identity theft, theft of authentication credentials, and the use of a computer to unwittingly participate in a DDoS attack, among many other risks. This document also describes at a high level the activities that ISPs should be sensitive to, where the collection or communication of PII may be possible. Finally, the document also describes security risks which may relate to the particular methods of communicating a notification to Internet users. Bot networks and bot infections pose extremely serious security risks and any reader should review this document carefully.
| TOC |
There are no IANA considerations in this document.
| TOC |
The authors wish to acknowledge the following individuals and organisations for their review and feedback of this document:
Jonathan Curtis
Jeff Chan
Roland Dobbins
Eliot Gillum
The Messaging Anti-Abuse Working Group (MAAWG)
Jose Nazario
Gunter Ollmann
Eric Ziegast
| TOC |
| [RFC1459] | Oikarinen, J. and D. Reed, “Internet Relay Chat Protocol,” RFC 1459, May 1993 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2142] | Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” RFC 2142, May 1997 (TXT, HTML, XML). |
| [RFC3954] | Claise, B., “Cisco Systems NetFlow Services Export Version 9,” RFC 3954, October 2004 (TXT). |
| TOC |
[RFC Editor: This section is to be removed before publication]
-02 version:
-02 version:
-01 version:
| TOC |
[RFC Editor: This section is to be removed before publication]
Could use some informational references in Section 3
Consider revision of the OS update links, to simplify them.
Add some point about notification to large networks may not be useful -- such as coffee shops or hotels with WiFi networks.
| TOC |
| 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 |
| 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 |