idnits 2.17.1 draft-oreirdan-mody-bot-remediation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2009) is 5334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Livingood 3 Internet-Draft N. Mody 4 Intended status: Informational M. O'Reirdan 5 Expires: March 19, 2010 Comcast 6 September 15, 2009 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-03 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 19, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document contains recommendations on how Internet Service 58 Providers can manage the effects of computers used by their 59 subscribers, which have been infected with malicious bots, via 60 various remediation techniques. Internet users with infected 61 computers are exposed to risks such as loss of personal data, as well 62 as increased susceptibility to online fraud and/or phishing. Such 63 computers can also become an inadvertent participant in or component 64 of an online crime network, spam network, and/or phishing network, as 65 well as be used as a part of a distributed denial of service attack. 66 Mitigating the effects of and remediating the installations of 67 malicious bots will make it more difficult for botnets to operate and 68 could reduce the level of online crime on the Internet in general 69 and/or on a particular Internet Service Provider's network. 71 Table of Contents 73 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 2. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Introduction and Problem Statement . . . . . . . . . . . . . . 6 76 4. Important Notice of Limitations and Scope . . . . . . . . . . 7 77 5. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 7 78 6. Notification to Internet Users . . . . . . . . . . . . . . . . 11 79 7. Remediation of Compters Infected with a Bot . . . . . . . . . 15 80 8. Guided Remediation Process . . . . . . . . . . . . . . . . . . 17 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 84 12. Informative references . . . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 19 86 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Key Terminology 97 This section defines the key terms used in this document. 99 2.1. Malicious Bots, or Bots 101 A malicious "bot" (derived from the word "robot", hereafter simply 102 referred to as a "bot") refers to a program that is surreptitiously 103 installed on a system in order to enable that system to automatically 104 (or semi-automatically) perform a task or set of tasks typically 105 under the command and control of a remote administrator, or "bot 106 master." Bots are also known as "zombies". It is important to note 107 that there are 'good', or benign bots. Such benign bots are often 108 found in such environments such as gaming and Internet Relay Chat 109 (IRC) [RFC1459], where a continual, interactive presence can be a 110 requirement for participating in the games, interacting with a 111 computing resource, or other purposes. 113 However, for the purposes of this document, all mention of bots 114 should assume that the bots involved are malicious in nature. Such 115 malicious bots shall generally be assumed to have been deployed 116 without the permission or conscious understanding of a particular 117 Internet user. Thus, without a user's knowledge, bots may transform 118 the user's computing device into a platform from which malicious 119 activities can be conducted. 121 2.2. Bot Networks, or Botnets 123 These are defined as concerted networks of bots capable of acting on 124 instructions generated remotely. The malicious activities are either 125 focused on the information on the local machine or acting to provide 126 services for remote machines. Bots are highly customizable so they 127 can be programmed to do many things. The major malicious activities 128 include: identity theft, spam, distributed denial of service (DDoS) 129 attacks, key-logging, fraudulent DNS (pharming), proxy services, fast 130 flux hosting and click fraud. 132 Infection vectors include un-patched operating systems, software 133 vulnerabilities, weak/non-existent passwords, malicious websites, un- 134 patched browsers, malware, vulnerable helper applications and social 135 engineering techniques to gain access to the user's computer. The 136 detection and destruction of bots is an ongoing issue and also a 137 constant battle between the internet security community, network 138 security engineers and bot developers. 140 Initially, bots used IRC to communicate but were easy to shutdown if 141 the command and control server was identified and deactivated. Newer 142 command and control methods have evolved, such that those currently 143 employed by bot masters make them much more resistant to 144 deactivation. With the introduction of P2P, HTTP and other resilient 145 communication protocols along with the widespread adoption of 146 encryption, bots are considerably more difficult to identify and 147 isolate from typical network usage. As a result increased reliance 148 is being placed on anonmaly detection and behavioral analysis, both 149 locally and remotely, to identify bots. 151 2.3. Computer 153 A computer, as used in the context of this document, is intended to 154 refer to a computing device that connects to the Internet. This 155 encompasses devices used by Internet users such as personal 156 computers, including laptops, desktops, and netbooks, as well as 157 mobile phones, smart phones, home gateway devices, and other end user 158 computing devices which are connected or can connect to the public 159 Internet and/or private IP networks. 161 Increasingly, other household systems and devices contain embedded 162 computers which are connected to or can connect to the public 163 Internet and/or private IP networks. However, these devices may not 164 be under interactive control of the Internet user, such as may be the 165 case with various smart home and smart grid devices. 167 2.4. Malware 169 This is short for malicious software. In this case, malicious bots 170 are considered a subset of malware. Other forms of malware could 171 include viruses and other similar types of software. Internet users 172 can sometimes cause their computer to be infected with malware, which 173 may include a bot or cause a bot to install itself, via inadvertently 174 accessing a specific website, downloading a specific file, or other 175 activities. 177 Alternatively, Internet-connected computers may become infected with 178 malware through externally initiated malicious activities such as the 179 exploitation of vulnerabilities or the brute force guessing of access 180 credentials. 182 3. Introduction and Problem Statement 184 Computers used by Internet users, which in this case are customers of 185 an Internet Service Provider (ISP), can be infected with malware 186 which may contain and/or install one or more bots on a computer. 187 This can present a major problem for an ISP for a number of reasons 188 (not to mention of course the problems created for users). First, 189 these bots can be used to send spam, in some cases very large volumes 190 of spam. This spam can result in extra cost for the ISPs in terms of 191 wasted network, server, and/or personnel resources, among many other 192 potential costs and side effects. Such spam can also negatively 193 affect the reputation of the ISP, their customers, and the email 194 reputation of the IP address space used by the ISP (often referred to 195 simply as 'IP reputation'). 197 In addition, these bots can act as platforms for directing, 198 participating in, or otherwise conducting attacks on critical 199 Internet infrastructure. Bots are frequently used as part of 200 concerted Distributed Denial of Service (DDoS) attacks for criminal, 201 political or other motivations. For example, bots have been used to 202 attack Internet resources and infrastructure ranging from web sites, 203 to email servers and DNS servers, as well as the critical Internet 204 infrastructure of entire countries. Motivations for such coordinated 205 DDoS attacks can range from criminal extortion attempts through to 206 online protesting and nationalistic fervor. 208 While any computing device can be infected with bots, the majority of 209 bot infections affect the personal computers used by Internet end 210 users. As a result of the role of ISPs in providing IP connectivity, 211 among many other services, to Internet users, these ISPs are in a 212 unique position to be able to attempt to detect and observe bot nets 213 operating in their networks. Furthermore, ISPs may also be in a 214 unique position to be able to communicate to Internet users which are 215 their customers, when customers' computers may have been determined 216 to have been or possibly have been infected with one or more bots. 218 From an end user perspective, knowing that their computer has been 219 infected with one or more bots is very important information. Once 220 they know this, they can take steps to remove the bot, protect 221 themselves in the future, and resolve any problems which may stem 222 from the bot infection. Given that bots can drain local computing 223 and network resources, enable theft of personal information 224 (including personal financial information), enable the computer to be 225 used from criminal activities (that may result in the Internet user 226 being legally culpable), destroy or leave the PC in an unrecoverable 227 state via 'kill switch' bot technologies, it is important to notify 228 the user that they may be infected with a bot. 230 As a result, the intent of this document is to provide a guide to 231 ISPs and other organizations for the remediation of these computers 232 infected with bots, so as to reduce the size of bot nets and minimize 233 the potential harm that bots can inflict upon Internet infrastructure 234 generally, as well as on individual Internet users. Efforts by ISPs 235 and other organizations could therefore, over time, reduce the pool 236 of computers infected with bots on the Internet, which in turn could 237 result in smaller bot nets with less capability for disruption. 239 The potential mitigation of bots is accomplished through a process of 240 detection, notification to Internet users, and remediation of that 241 bot with a variety of tools, as described later in this document. 243 4. Important Notice of Limitations and Scope 245 The techniques described in this document in no way guarantee the 246 remediation of all bots. Bot removal is potentially a task requiring 247 specialized knowledge, skills and tools, and may be beyond the 248 ability of average users. Attempts at bot removal may frequently be 249 unsuccessful, or only partially successful, and may leave a user's 250 system in an unstable and unsatisfactory state or even in a state 251 where it is still infected. Attempts at bot removal can also result 252 in side effects ranging from a loss of data or other files, all the 253 way through partial or complete loss of system usability. 255 In general, the only way a user can be sure they have removed some of 256 today's increasingly sophisticated malware is by 'nuking-and-paving' 257 the system: reformatting the drive, reinstalling the operating system 258 and applications (including all patches) from scratch, and then 259 restoring user files from a clean backup. However the introduction 260 of BIOS-based malware may mean that, in some cases, this will not be 261 enough and may prove to be more than any end user can be reasonably 262 expected to resolve. 264 Devices with embedded operating systems, such as video gaming 265 consoles and smart home appliances, will most likely be beyond a 266 user's capability to remediate by themselves, and will typically 267 require the aid of vendor-specific advice, updates and tools. Care 268 must be taken when imparting remediation advice to Internet users 269 given the increasingly wide array of computing devices that can be, 270 or could be, infected by bots in the future. 272 5. Detection of Bots 274 An ISP must first identify that an Internet user, in this case a user 275 that is assumed to be their customer or otherwise connected to the 276 ISP's network, is determined to be infected, or likely to have been 277 infected with a bot. The ISP should attempt to detect the presence 278 of bots using methods, processes, and tools which maintain the 279 privacy of the personally identifiable information (PII) of their 280 customers. The ISP also should not block legitimate traffic in the 281 course of bot detection, and should instead employ detection methods, 282 tools, and processes which seek to be non-disruptive, as well as 283 being transparent to Internet users and end-user applications. 285 Detection methods, tools, and processes may include things such as 286 analysis of specific network and/or application traffic flows (such 287 as traffic to an email server), analysis of aggregate network and/or 288 application traffic data, data feeds received from other ISPs and 289 organizations (such as lists of the ISP's IP addresses which have 290 been reported to have sent spam), feedback from the ISP's customers 291 or other Internet users, as well as a wide variety of other 292 possibilities. It is likely that a combination of multiple bot 293 detection data points will prove to be an effective approach in order 294 to corroborate information of varying dependability or consistency, 295 as well as to avoid or minimize the possibility of false positive 296 identification of computers. Detection should also, where possible 297 and feasible, attempt to classify a bot in order to confirm that it 298 is malicious in nature, estimate the variety and severity of threats 299 it may pose (such as spam bot, key-logging bot, file distribution 300 bot, etc.), and to determine potential methods for eventual 301 remediation. However, given the dynamic nature of botnet management 302 and the criminal incentives to seek quick financial rewards, botnets 303 frequently update or change their core malicious capabilities. As a 304 consequence, botnets that are initially detected and classified by 305 the ISP as one particular type of bot need to be continuously 306 monitored and tracked in order to correctly identify the threat they 307 pose at any particular point in time. 309 Detection is also time-sensitive. If complex analysis is required 310 and multiple confirmations are needed to confirm a bot is indeed 311 present, then it is possible that the bot may cause some damage (to 312 either the infected computer or a remotely targeted system) before it 313 can be stopped. This may mean that an ISP may need to balance the 314 desire or need to definitively classify and/or confirm a bot, which 315 may take an extended period of time, with the ability to predict the 316 strong likelihood of a bot in a very short period of time. This 317 'definitive-vs-likely' challenge is difficult and, when in doubt, 318 ISPs should probably err on the side of caution by communicating when 319 a likely bot infection has taken place. This also means that 320 Internet users may benefit from the deployment of client-based 321 software protections or other software tools, which can enable rapid 322 performance of heuristically-based detection bot activity, such as 323 the detection of a bot as it starts to communicate a bot net and 324 execute some type of command. Any bot detection systems should also 325 be capable of learning and adapting, either via manual intervention 326 or automatically, in order to cope with a rapidly evolving threat. 328 As noted above, detection methods, tools, and processes should ensure 329 that privacy of customers' PII is maintained. While bot detection 330 methods, tools, and processes are similar to spam and virus defenses 331 deployed by the ISP for the benefit of their customers (and may be 332 directly related to those defenses), attempts to detect bots should 333 take into account the need of an ISP to take care to ensure any PII 334 collected or incidentally detected is properly protected. Finally, 335 depending upon the geographic region within which an ISP operates, 336 certain methods relating to bot detection may need to be included in 337 relevant terms of service documents or other documents which are 338 available to the customers of a particular ISP. 340 There are several bot detection methods, tools, and processes that an 341 ISP may choose to utilize, as noted in the list below. It is 342 important to note that the technical solutions available are 343 relatively immature, and are likely to change over time, evolving 344 rapidly in the coming years. While these items are described in 345 relation to ISPs, they may also be applicable to organizations 346 operating other networks, such as campus networks and enterprise 347 networks. 349 a. Where legally permissible or otherwise an industry accepted 350 practice in a particular market region, an ISP may in some manner 351 "scan" their IP space in order to detect un-patched or otherwise 352 vulnerable hosts. This may provide the ISP with the opportunity 353 to easily identify Internet users who appear to already be or are 354 at great risk of being infected with a bot. ISP's should note 355 that some types of port scanning may leave network services in a 356 hung state or render them unusable due to common frailties, and 357 that many modern firewall and host-based intrusion detection 358 implementations may alert the Internet user to the scan. As a 359 result the scan may be interpreted as a malicious attack against 360 the computer. Vulnerability scanning has a higher probability of 361 leaving accessible network services and applications in a damaged 362 state and will often result in a higher probability of detection 363 by the Internet user and subsequent interpretation as a targeted 364 attack. Depending upon the vulnerability being scanned, some 365 automated methods of vulnerability checking may result in data 366 being altered or created afresh on the Internet users computer 367 which be a problem in many legal environments. 369 b. An ISP may also communicate and share selected data, via feedback 370 loops or other mechanisms, with various third parties. Feedback 371 loops are consistently formatted feeds of real-time (or nearly 372 real-time) abuse reports offered by threat data clearinghouses, 373 security alert organizations, other ISPs, and other 374 organizations. The data may include, but is not limited to, 375 lists of the IP addresses computers which have or are likely to 376 have a bot running, domain names or fully qualified domain names 377 (FQDNs) known to host malware and/or be involved in the command 378 and control of botnets, IP addresses know to host malware and/or 379 be involved in the command and control of botnets, recently 380 tested or discovered techniques or detecting or remediating bot 381 infections, new threat vectors, and other relevant information. 382 Good examples of this include SNDS from Microsoft, XBL and PBL 383 from Spamhaus and the DSHIELD AS tool from the SANS Institue. 385 c. An ISP may use Netflow [RFC3954] or other similar passive network 386 monitoring to identify network anomalies that may be indicative 387 of botnet attacks or bot communications. For example, an ISP may 388 be able to identify compromised hosts by identifying traffic 389 destined to IP addresses associated with the command and control 390 of botnets. In addition, bots can be idenfied when a remote host 391 is under a DDoS attack because computers participating in the 392 attack will likely be infected by a bot, frequently as observed 393 at network borders. 395 d. An ISP may use DNS-based techniques to perform detection. For 396 example, a given classified bot may be known to query a specific 397 list of domain names at specific times or on specific dates (in 398 the example of the so-called "Conficker" bot), often by matching 399 DNS queries to a well known list of domains associated with 400 malware. In many cases such lists are distributed by or shared 401 using third parties, such as threat data clearinghouses. 403 e. User complaints: Because hosts infected by bots are frequently 404 used to send spam or participate in DDoS attacks, the ISP 405 servicing those hosts will normally receive complaints about the 406 malicious network traffic. Those complaints may be sent to 407 RFC2142-specified [RFC2142] role accounts, such as abuse@ or 408 postmaster@ or to abuse or security addresses specified by the 409 site as part of its WHOIS (or other) contact data. 411 f. ISPs may also discover likely bot infected hosts located at other 412 sites; when legally permissible or otherwise an industry accepted 413 practice in a particular market region, it may be worthwhile for 414 ISPs to share evidence relating to those compromised hosts with 415 the relevant remote ISP, with security researchers, and with 416 blocklist operators. 418 g. ISPs may operate or subscribe to services that provide 419 'sinkholing' or 'honeynet' capabilities. This may enable the ISP 420 to obtain near-real-time lists of bot infected computers as they 421 attempt to join a larger botnet or propagate to other hosts on a 422 network. 424 6. Notification to Internet Users 426 Once an ISP has detected a bot, or the strong likelihood of a bot, 427 steps should be undertaken to inform the Internet user that they may 428 have a bot-related problem. Depending upon a range of factors, from 429 the technical capabilities of the ISP, to the technical attributes of 430 their network, financial considerations, available server resources, 431 available organizational resources, the number of likely infected 432 computers detected at any given time, and the severity of any 433 possible threats, among many other things, an ISP should decide the 434 most appropriate method or methods for providing notification to one 435 or more of their customers or Internet users. Such notification 436 methods may include one or more of the following, as well as other 437 possible methods not described below 439 It is important to note that none of these methods are guaranteed to 440 be successful, and that each has its own set of limitations. In 441 addition, in some cases, an ISP may determine that a combination of 442 two or more methods is most appropriate. Finally, notification is 443 also considered time sensitive; if the user does not receive or view 444 the notification or a timely basis, then a particular bot could 445 launch an attack, exploit the user, or cause other harm. If 446 possible, an ISP should establish a preferred means of communication 447 when the subscriber first signs up for service. As a part of the 448 notification process, ISPs should maintain a record of the allocation 449 of IP addresses to subscribers for such a period as allows any bot 450 detection technology to be accurately able to link an infected IP 451 address to a subscriber. This record should only be maintained for a 452 period of time which is necessary, in order to maintain the 453 protection of the privacy of an individual subscriber. 455 One important factor to bear in mind is that notification to end 456 users needs to be defended against spoofing by third parties. This 457 must be done to protect against the possibility of notifications 458 being spoofed and used by bots to deliver additional malware. 460 6.1. Email Notification 462 This is probably the most common form of notification used by ISPs. 463 One drawback of using email is that it is not guaranteed to be viewed 464 within a reasonable time frame, if at all. The user may be using a 465 different primary email address than that which they have provided to 466 the ISP. In addition, some ISPs do not provide an email account at 467 all, as part of a bundle of Internet services, and/or do not have a 468 need for or method in which to request or retain the primary email 469 addresses of Internet users of their networks. Another possibility 470 is that the user, their email client, and/or their email servers 471 could determine or classify such a notification as spam, which could 472 delete the message or otherwise file it in an email folder that the 473 user may not check on a regular and/or timely basis. Bot masters 474 have also been known to impersonate the ISP or trusted sender and 475 send fradulant emails to the users. This technique of solical 476 engineering, generally referred to as 'phishing', often leads to new 477 bot infestations. Finally if the user's email credentials are 478 compromised, then a hacker and/or a bot could simply login to the 479 user's email account and delete the email before it is read by the 480 user. 482 6.2. Telephone Call Notification 484 A telephone call may be an effective means of communication in 485 particularly high-risk situations. However, telephone calls may not 486 be feasible due to the cost of making a large number of calls, as 487 measured in either time, money, organizational resources, server 488 resources, or some other means. In addition, there is no guarantee 489 that the user will answer their phone. To the extent that the 490 telephone number called by the ISP can be answered by the infected 491 computing device, the bot on that computer may be able to disconnect, 492 divert, or otherwise interfere with an incoming call. Users may also 493 interpret such a telephone notification as a telemarketing call and 494 as such not welcome it, or not accept the call at all. Finally, even 495 if a representative of the ISP is able to connect with and speak to a 496 user, that user is very likely to lack the necessary technical 497 expertise to understand or be able to effectively deal with the 498 threat. 500 6.3. Postal Mail Notification 502 This form of notification is probably the least popular and effective 503 means of communication, due to both preparation time, delivery time, 504 the cost of printing and paper, and the cost of postage. 506 6.4. Walled Garden Notification 508 Placing a user in a walled garden is another approach that ISPs may 509 take to notify users. A walled garden refers to an environment that 510 controls the information and services that a subscriber is allowed to 511 utilize and what network access permissions are granted. This is an 512 effective technique because it could be able to block all 513 communication between the bot and the command and control channel, 514 which may impair the ability of a bot to disrupt or block attempts to 515 notify the user. 517 While in many cases the user is almost guaranteed to view the 518 notification message and take any appropriate remediation actions, 519 this approach poses can pose other challenges. For example, it is 520 not always the case that a user is actively using a computer that 521 uses a web browser or which has a web browser actively running on it. 522 In one example, a user could be playing a game online, via the use of 523 a dedicated, Internet-connected game console. In another example, 524 the user may not be using a computer with a web browser when they are 525 placed in the walled garden and may instead be in the course of a 526 telephone conversation, or may be expecting to receive a call, using 527 a Voice Over IP (VoIP) device of some type. As a result, the ISP may 528 feel the need to maintain a potentially lengthy white list of domains 529 which are not subject to the typical restrictions of a walled garden, 530 which could well prove to be an onerous task, from an operational 531 perspective. 533 The ISP has several options to determine when to let the user out of 534 the walled garden. One approach may be to let the user determine 535 when to exit. This option is suggested when the purpose of the 536 walled garden is to notify users and provide information on 537 remediation only, particularly since notification is not a guarantee 538 of successful remediation. It could also be the case that, for 539 whatever reason, the user makes the judgment that they cannot then 540 take the time to remediate their computer and that other online 541 activities which they would like to resume are more important. Exit 542 from the walled garden may also involve a process to verify that it 543 is indeed the user who is requesting exit from the walled garden and 544 not the bot. 546 Once the user acknowledges the notification, then the user decides to 547 either remediate and then exit the walled garden, or exit the walled 548 garden without addressing the issue. Another approach may be to 549 enforce a stricter policy and require the user to clean the computer 550 prior to permitting the user to exit the walled garden, though this 551 may not be technically feasible depending upon the type of bot, 552 obfuscation techniques employed by a bot, and/or a range of other 553 factors. Thus, the ISP may also need to support tools to scan the 554 infected computer and determine whether it is still infected or rely 555 on user judgment that the bot has been disabled or removed. One 556 challenge with this approach is that if the user has multiple 557 computers sharing a single IP address, such as via a common home 558 gateway device which performs Network Address Translation (NAT). In 559 such a case, the ISP may need to determine from user feedback, or 560 other means, that all affected computers have been remediated, which 561 may or may not be technically feasible. 563 Finally, when a walled garden is used, a list of well-known addresses 564 for both operating system vendors and security vendors should be 565 created and maintained in a white list which permits access to these 566 sites. This can be important for allowing access from the walled 567 garden by end users in search of operating system and application 568 patches. 570 6.5. Instant Message Notification 572 Instant messaging provides the ISP with a simple means to communicate 573 with the user. There are several advantages to using IM which makes 574 it an attractive option. If the ISP provides IM service and the user 575 subscribes to it, then the user can be notified easily. IM-based 576 notification can be a cost effective means to communicate with users 577 automatically from an IM alert system or via a manual process, by the 578 ISP's support staff. Ideally, the ISP should allow the user to 579 register their IM identity in an ISP account management system and 580 grant permission to be contacted via this means. If the IM service 581 provider supports off-line messaging, then the user can be notified 582 regardless of whether they are currently logged into the IM system. 584 There are several drawbacks with this communications method. There 585 is a high probability that subscriber may interpret the communication 586 to be spam, and as such ignore it. Also, not every user uses IM 587 and/or the user may not provide their IM identity to the ISP so some 588 alternative means have to be used. Even in those cases where a user 589 does have an IM address, they may not be signed onto that IM system 590 when the notification is attempted. There maybe also be a privacy 591 concern on the part of users, when such an IM notification must be 592 transmitted over a third-party network and/or IM service. As such, 593 should this method be used, the notification should be discreet and 594 not include any PII in the notification itself. 596 6.6. Short Message Service (SMS) Notification 598 SMS allows the ISP send a brief description of the problem to notify 599 the user of the issue, typically to a mobile device such as a mobile 600 phone or smart phone. Ideally, the ISP should allow the user to 601 register their mobile number and/or SMS address in an ISP account 602 management system and grant permission to be contacted via this 603 means. The primary advantage of SMS is that users are familiar with 604 receiving text messages and are likely to read them. However, users 605 may not act on the notification immediately if they are not in front 606 of their computer system at the time of the SMS notification. 608 One disadvantage is that ISPs may have to follow up with an alternate 609 means of notification if not all of the necessary information maybe 610 conveyed in one message, given constraints on the number of 611 characters in an individual message (typically 140 characters). 612 Another disadvantage with SMS is the cost associated with it. The 613 ISP has to either build its own SMS gateway to interface with the 614 various wireless network service providers or use a third-party SMS 615 clearinghouse (relay) to notify users. In both cases, an ISP will 616 typically pay on a per-message basis to send SMS notifications. An 617 additional downside is that SMS messages sent to a user may result in 618 a charge to the user by their wireless provider, depending upon the 619 plat to which they subscribe. Another minor disadvantage is that it 620 is possible to notify the wrong user if the intended user changes 621 their mobile number but forgets to update it with the ISP. 623 There are several other drawbacks with this communications method. 624 There is a high probability that subscriber may interpret the 625 communication to be spam, and as such ignore it. Also, not every 626 user uses SMS and/or the user may not provide their SMS address or 627 mobile number to the ISP. Even in those cases where a user does have 628 an SMS address or mobile number, their device may not be powered on 629 or otherwise available on a wireless network when the notification is 630 attempted. There maybe also be a privacy concern on the part of 631 users, when such an SMS notification must be transmitted over a 632 third-party network and/or SMS clearinghouse. As such, should this 633 method be used, the notification should be discreet and not include 634 any PII in the notification itself. 636 6.7. Web Browser Notification 638 Near real-time notification to the user's web browser is another 639 technique that may be utilized for notifying the user, though how 640 such a system might operate is outside the scope of this document. 641 Such a notification could have a comparative advantage over a walled 642 garden notification, in that it does not restrict traffic to a 643 specified list of destinations in the same way that a walled garden 644 by definition would. However, as with a walled garden notification, 645 there is no guarantee that a user is at any given time making use of 646 a web browser, though such a system could certainly provide a 647 notification when such a browser is eventually used. Compared to a 648 walled garden, a web browser notification is probably preferred from 649 the perspective of Internet users, as it does not have the risk of 650 disrupting non-web sessions, such as online games, VoIP calls, etc. 651 (as noted in Section 6.4). 653 7. Remediation of Compters Infected with a Bot 655 This section covers the different options available to remediate a 656 computer, which means to remove, disable, or otherwise render a bot 657 harmless. Prior to this step, an ISP has detected the bot, notified 658 the user that one of their computers is infected with a bot, and now 659 may provide some recommended means to clean the computer. The 660 generally recommended approach is to provide the necessary tools and 661 education to the user so that they may perform bot remediation 662 themselves, particularly given the risks and difficulties inherent in 663 attempting to remove a bot. 665 For example, this may include the creation of a special web site with 666 security-oriented content that is dedicated for this purpose. This 667 should be a well-publicized security web site to which a user with a 668 bot infection can be directed to for remediation. This security web 669 site should clearly explain why the user was notified and may include 670 an explanation of what bots are, and the threats that they pose. 671 There should be a clear explanation of the steps that the user should 672 take in order to attempt to clean their computer and provide 673 information on how users can keep the computer free of future 674 infections. The security web site should also have a guided process 675 that takes non-technical users through the remediation process, on an 676 easily understood, step-by-step basis. 678 In terms of the text used to explain what bots are and the threats 679 that they pose, something simple such as this may suffice: 681 "What is a bot? A bot is a piece of software, generally 682 installed on your machine without your knowledge, which either 683 sends spam or tries to steal your personal information. They 684 can be very difficult to spot, though you may have noticed that 685 your computer is running much more slowly than usual or you 686 notice regular disk activity even when you are not doing 687 anything. Ignoring this problem is not really an option since 688 your personal information is currently at risk. Thus, bots 689 need to be removed to protect your data and your personal 690 information." 692 It is also important to note that it may not be immediately apparent 693 to the Internet user precisely which devices have been infected with 694 a particular bot. This may be due to the user's home network 695 configuration, which may encompass several computers, where a home 696 gateway which performs Network Address Translation (NAT) to share a 697 single public IP address has been used. Therefore, any of these 698 devices can be infected with a bot. The consequence of this for an 699 ISP is that remediation advice may not ultimately be immediately 700 actionable by the Internet user, as that user may need to perform 701 additional investigation within their own home network. 703 An added complication is that the user may have a bot infection on a 704 device such as a video console, multimedia system, appliance, or 705 other end-user computing device which does not have a typical Windows 706 or Macintosh user interface. As a result, diligence needs to be 707 taken by the ISP where possible such that they can identify and 708 communicate the specific nature of the device that has been infected 709 with a bot, and further providing appropriate remediation advice. 711 8. Guided Remediation Process 713 Minimally the Guided Remediation Process should include options 714 and/or recommendations on how a user should: 716 1. Backup personal Documents, for example: "Before you start, make 717 sure to back up all of your important data. (You should do this 718 on a regular basis anyway.) You can back up your files manually 719 or using a system back-up software utility, which may be part of 720 your Operating System (OS). You can back your files up to a USB 721 Thumb Drive (aka USB Key), a CD/DVD-ROM, an external hard drive, 722 or a network file server." 724 2. Download OS patches and Anti-Virus (A/V) software updates. For 725 example, links could be provided to Microsoft Windows updates at 726 http://update.microsoft.com/microsoftupdate/v6/ 727 default.aspx?ln=en-us as well as to Apple MacOS updates at 728 http://support.apple.com/kb/HT1338?viewlocale=en_US. 730 3. Explain how to configure the computer to automatically install 731 updates for the OS, A/V and other common Web Browsers such as 732 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 733 Opera, and Google Chrome. 735 4. The flow should also have the option for users to get 736 professional assistance if they are unable to remove the bots 737 themselves. If purchasing third party assistance, then the user 738 should be encouraged to pre-determine how much they are willing 739 to pay for that help. If the computer that is being remediated 740 is old and can easily be replaced with a new, faster, larger and 741 more reliable system for three or four hundred dollars, the it 742 makes no sense to spend five or six hundred dollars to fix the 743 old computer, for example. On the other hand, if the customer 744 has a brand new computer that cost several thousand dollars, it 745 might make perfect sense to spend the money in attempting to 746 remediate it. 748 5. To continue, regardless of whether the user or a knowledgeable 749 technical assistant is working on remediating the computer, their 750 first task should be to determine which of multiple potentially- 751 infected machines may be the one that needs attention (in the 752 common case of multiple computers in a home network). Sometimes, 753 as in cases where there is only a single directly-attached 754 computer, or the user has been noticing problems with one of 755 their computers, this can be easy. Other times, it may be more 756 difficult. If the user is behind a home gateway/router, then the 757 first task may be to ascertain which of the machines is infected. 758 In some cases the user may have to check all machines to identify 759 the infected one. 761 6. User surveys to solicit feedback on whether the notification and 762 remediation process is effective and what recommended changes 763 could be made in order to improve the ease, understandability, 764 and effectiveness the remediation process. 766 7. If the user is interested in reporting his or her computer's bot 767 infection to an applicable law enforcement authority, then the 768 computer effectively becomes a cyber "crime scene" and should not 769 be mitigated unless or until law enforcement has collected the 770 necessary evidence. For individuals in this situation, the ISP 771 should refer them to local, state, federal, or other relevant 772 computer crime offices. (Note: Some "minor" incidents, even if 773 highly traumatic to the user, may not be sufficiently serious for 774 law enforcement to commit some of their limited resources to an 775 investigation.) 777 9. Security Considerations 779 This document describes in detail the numerous security risks and 780 concerns relating to bot nets. As such, it has been appropriate to 781 include specific information about security in each section above. 782 This document describes the security risks related to malicious bot 783 infections themselves, such as enabling identity theft, theft of 784 authentication credentials, and the use of a computer to unwittingly 785 participate in a DDoS attack, among many other risks. This document 786 also describes at a high level the activities that ISPs should be 787 sensitive to, where the collection or communication of PII may be 788 possible. Finally, the document also describes security risks which 789 may relate to the particular methods of communicating a notification 790 to Internet users. Bot networks and bot infections pose extremely 791 serious security risks and any reader should review this document 792 carefully. 794 10. IANA Considerations 796 There are no IANA considerations in this document. 798 11. Acknowledgements 800 The authors wish to acknowledge the following individuals and 801 organisations for their review and feedback of this document: 803 Jonathan Curtis 805 Jeff Chan 807 Roland Dobbins 809 Eliot Gillum 811 The Messaging Anti-Abuse Working Group (MAAWG) 813 Jose Nazario 815 Gunter Ollmann 817 Eric Ziegast 819 12. Informative references 821 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 822 RFC 1459, May 1993. 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 828 FUNCTIONS", RFC 2142, May 1997. 830 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 831 9", RFC 3954, October 2004. 833 Appendix A. Document Change Log 835 [RFC Editor: This section is to be removed before publication] 837 -02 version: 839 o all updates from Jason - now ready for wider external review 841 -02 version: 843 o all updates from Jason - still some open issues but we're now at a 844 place where we can solicit more external feedback 846 -01 version: 848 o -01 version published 850 Appendix B. Open Issues 852 [RFC Editor: This section is to be removed before publication] 854 Could use some informational references in Section 3 856 Consider revision of the OS update links, to simplify them. 858 Add some point about notification to large networks may not be useful 859 -- such as coffee shops or hotels with WiFi networks. 861 Authors' Addresses 863 Jason Livingood 864 Comcast Cable Communications 865 One Comcast Center 866 1701 John F. Kennedy Boulevard 867 Philadelphia, PA 19103 868 US 870 Email: jason_livingood@cable.comcast.com 871 URI: http://www.comcast.com 873 Nirmal Mody 874 Comcast Cable Communications 875 One Comcast Center 876 1701 John F. Kennedy Boulevard 877 Philadelphia, PA 19103 878 US 880 Email: nirmal_mody@cable.comcast.com 881 URI: http://www.comcast.com 882 Mike O'Reirdan 883 Comcast Cable Communications 884 One Comcast Center 885 1701 John F. Kennedy Boulevard 886 Philadelphia, PA 19103 887 US 889 Email: michael_oreirdan@cable.comcast.com 890 URI: http://www.comcast.com