idnits 2.17.1 draft-oreirdan-mody-bot-remediation-00.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 (July 6, 2009) is 5408 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: January 7, 2010 Comcast 6 July 6, 2009 8 Recommendations for the Remediation of Bots in Large ISP Networks 9 draft-oreirdan-mody-bot-remediation-00 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 January 7, 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 large Internet Service 58 Providers (ISPs) can manage the effects of large numbers of bot 59 infected computers used by their subscribers via various remediation 60 techniques. At the time that this document was published, computers 61 infected by bots and the users of those computers comprise a 62 substantial number of users for large ISPs. Those Internet users are 63 exposed to risks such as loss of personal data, increased 64 susceptibility to online fraud and/or phishing, and becoming an 65 inadvertent participant in or component of an online crime, spam, 66 and/or phishing network. Mitigating the effects of and remediating 67 the installations of bots affecting large numbers of Internet users 68 will make it more difficult for bot nets to operate and could reduce 69 the level of online crime on the Internet in general and/or on a 70 particular ISP's network. 72 Table of Contents 74 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 2. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Introduction and Problem Statement . . . . . . . . . . . . . . 5 77 4. Important Notice of Limitations . . . . . . . . . . . . . . . 6 78 5. Detection, Notification and Remediation . . . . . . . . . . . 7 79 5.1. Detection of Bots . . . . . . . . . . . . . . . . . . . . 7 80 5.2. Notification to Internet Users . . . . . . . . . . . . . . 9 81 5.3. Remediation of Bot Infected Machines . . . . . . . . . . . 13 82 5.4. Guided Remediation Process . . . . . . . . . . . . . . . . 14 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 87 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 16 88 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Key Terminology 99 This section defines the key terms used in this document. 101 2.1. Bots 103 A "bot" (derived from the word "robot") refers to a program that is 104 surreptitiously installed on a system in order to enable that system 105 to automatically (or semi-automatically) perform a task or set of 106 tasks typically under the command and control of a remote 107 administrator, or "bot master." Bots are also known as "zombies." 108 It is important to note that there are 'good' bots. Such benign bots 109 are often found in such environments such as gaming and Internet 110 Relay Chat (IRC) [RFC1459], where a continual, interactive presence 111 can be a requirement for participating in the games, interacting with 112 a computing resource, or other purposes. However, for the purposes 113 of this document, all mention of bots should assume that the bots 114 involved are malicious in nature. Such malicious bots shall 115 generally be assumed to have been deployed without the permission or 116 conscious understanding of a particular Internet user. Thus, without 117 a user's knowledge, bots may transform the user's computing device 118 into a platform from which malicious activities are conducted. 120 2.2. Bot Networks, or Bot Nets 122 These are defined as concerted networks of bots capable of acting on 123 instructions generated remotely. The malicious activities are either 124 focused on the information on the local machine or acting to provide 125 services for remote machines. Bots are highly customizable so they 126 can be programmed to do many things. The major malicious activities 127 include: identity theft, spam, denial of service attacks, key- 128 logging, fraudulent DNS, proxy services, hosting and click fraud. 129 Infection vectors include un-patched operating systems, software 130 vulnerabilities, weak/non-existent passwords, malicious websites, un- 131 patched browsers, malware and social engineering techniques to gain 132 access to the user's computer. The detection and destruction of bots 133 is an ongoing issue and also a constant battle between anti-virus 134 developers and bot developers. Initially botnets utilized IRC to 135 communicate but were easy to shutdown if the command and control 136 server was identified and deactivated. However, with the 137 introduction of P2P, HTTP and other technologies including 138 encryption, bots are considerably more difficult to identify. As a 139 result increased reliance is being placed on behavioral analysis both 140 locally and remotely to identify bots. 142 2.3. Computer 144 A computer, as used in the context of this document, is intended to 145 encompass the various personal computing devices used by Internet 146 users. This may include devices ranging from so-called personal 147 computers, including laptops, desktops, and netbooks, as well as 148 mobile phones, smart phones, home gateway devices, and other end user 149 computing devices which are connected or can connect to the public 150 Internet and/or private IP networks. 152 2.4. Malware 154 This is short for "malicious software." In this case, malicious bots 155 are considered a subset of malware, which could also include viruses 156 and other similar types of software. Internet users can sometimes 157 cause their computer to be infected with malware, which may include a 158 bot or cause a bot to install itself, via inadvertently accessing a 159 specific website, downloading a specific file, or other activities. 161 3. Introduction and Problem Statement 163 Computers used by Internet users, which in this case are customers of 164 an Internet Service Provider (ISP), can be infected with malware 165 which may contain and/or install one or more bots on a computer. 166 This can present a major problem for an ISP for a number of reasons 167 (not to mention, of course, the problems created for users). First, 168 these bots can be used to send spam, in some cases very large volumes 169 of spam. This spam can result in extra cost for the ISPs in terms of 170 wasted network, server, and/or personnel resources, among many other 171 potential costs or side effects. Such spam can also negatively 172 affect the reputation of the ISP, their customers, and the email 173 reputation of the IP address space used by the ISP (often referred to 174 simply as "IP reputation"). 176 In addition, these bots can act as platform for directing, 177 participating in, or otherwise conducting attacks on critical 178 Internet infrastructure. Bots are frequently used as part of 179 concerted Distributed Denial of Service (DDoS) attacks for criminal, 180 political, anarchistic, or other motivations. For example, bots have 181 been used to attack Internet resources and infrastructure ranging 182 from web sites, to email servers and DNS servers, as well as the 183 critical Internet infrastructure of entire countries. 185 While any computing device, including computers used by Internet 186 users to the servers operated by ISPs and other organizations can be 187 infected with bots, the majority of bot infections affect the 188 computers used by Internet users. ISPs have a unique potential role 189 when it comes to detecting botnets because they provide IP 190 connectivity for the "good" and "bad" traffic coming from user 191 systems. Furthermore, ISPs may also be in a unique position to be 192 able to communicate to Internet users which are their customers, when 193 customers computers may have been determined to have been or possibly 194 have been infected with one or more bots. 196 From an end user perspective, knowing that their computer has been 197 infected with one or more bots of very important information. Once 198 they know this, they can take steps to remove the bot, protect 199 themselves in the future, and resolve any problems which may stem 200 from the bot infection. Given that bots can not only drain their 201 local computing and network resources, but also enable the theft of 202 personal information (including personal financial information), it 203 is important to help users identify when they may have been infected 204 with a bot. 206 As a result, the intent of this document is to provide a guide to 207 ISPs and other organizations for the remediation of these computers 208 infected with bots, so as to reduce the size of bot nets and minimize 209 the potential harm that bots can inflict upon Internet infrastructure 210 generally, as well as on individual Internet users. Efforts by ISPs 211 and other organizations could therefore, over time, reduce the pool 212 of computers infected with bots on the Internet, which in turn could 213 result in smaller bot nets with less capability for disruption. 215 4. Important Notice of Limitations 217 The techniques described in this document in no way guarantee the 218 remediation of all bots. Bot removal is potentially a task requiring 219 specialized knowledge, skills and tools, and may be beyond the 220 ability of average users. Attempts at bot removal may frequently be 221 unsuccessful, or only partially successful, and may leave a user's 222 system in an unstable and unsatisfactory state or even still 223 infected. Attempts at bot removal can also result in side effects 224 ranging from a loss of data or other files, all the way through 225 partial or complete loss of system usability. 227 In general, the only way a user can be sure they have removed some of 228 today's increasingly sophisticated malware is by "nuking-and-paving" 229 the system: reformatting the drive, reinstalling the operating system 230 and applications (including all patches) from scratch, and then 231 restoring user files from a clean backup. 233 5. Detection, Notification and Remediation 235 The potential mitigation of bots is accomplished through a process of 236 detection, notification to Internet users, and remediation of that 237 bot with a variety of tools. 239 5.1. Detection of Bots 241 An ISP must first identify that an Internet user, in this case a user 242 that is assumed to be their customer or otherwise connected to the 243 ISP's network, is determined to be infected, or likely to have been 244 infected with a bot. The ISP should attempt to detect the presence 245 of bots using methods, processes, and tools which maintain the 246 privacy of the personally identifiable information of their 247 customers. The ISP also should not block legitimate traffic in the 248 course of bot detection, and should instead employ detection methods, 249 tools, and processes which seek to be non-disruptive, as well as 250 transparent to both Internet users as well as the people who are 251 deploying and/or operating bot nets. 253 Detection methods, tools, and processes may include things such as 254 analysis of specific network and/or application traffic flows (such 255 as traffic to an email server), analysis of aggregate network and/or 256 application traffic data, data feeds received from other ISPs and 257 organizations (such as lists of the ISP's IP addresses which have 258 been reported to have sent spam), feedback from the ISP's customers 259 or other Internet users, as well as a wide variety of other 260 possibilities. It is likely that a combination of all of the 261 multiple bot detection data points will prove to be the most 262 effective approach, in order to corroborate information of varying 263 dependability or consistency, as well as to avoid or minimize the 264 possibility of false positive identification of computers. Detection 265 should also, where possible and feasible, attempt to classify a bot 266 in order to confirm that it is malicious in nature, estimate the 267 variety and severity of threats it may pose (such as spam bot, key 268 logging bot, file distribution bot, etc.), and to determine a 269 potential methods for eventual remediation. 271 Detection is also time-sensitive. If complex analysis is required 272 and multiple confirmations are needed to confirm a bot is indeed 273 present, then it is possible that the bot will do its damage before 274 it can be stopped. This may mean that an ISP may need to balance the 275 desire or need to definitively classify and/or confirm a bot, which 276 may take an extended period of time, with the ability to predict the 277 strong likelihood of a bot in a very short period of time. This also 278 means that Internet users may benefit from the deployment of client- 279 based software protections or other software tools, which can enable 280 rapid performance of heuristically-based detection bot activity, such 281 as the detection of a bot as it starts to communicate a bot net and 282 execute some type of command. Any bot detection systems should also 283 be capable of learning and adapting, either via manual intervention 284 or automatically, in order to cope with a rapidly evolving threat. 286 As noted above, detection methods, tools, and processes should ensure 287 that privacy of customers' personally identifiable information is 288 maintained. While bot detection methods, tools, and processes are 289 similar to spam and virus defenses deployed by the ISP for the 290 benefits of their customers (and may be directly related to those 291 defenses), attempts to detect bots should take into account the need 292 of an ISP to take care to ensure that such personally identifiable 293 information is properly protected. Finally, depending upon the 294 geographic region within which an ISP operates, certain methods 295 relating to bot detection may need to be included in relevant terms 296 of service documents or other documents which are available to the 297 customers of a particular ISP. 299 There are several bot detection methods, tools, and processes that an 300 ISP may choose to utilize, as noted in the list below. It is 301 important to note that the technical solutions available are 302 relatively immature, and are likely to change over time, and to 303 evolve rapidly in the coming years. While these items are described 304 in relation to ISPs, they may also be applicable to organizations 305 operating other networks, such as campus networks and enterprise 306 networks. 308 a. Where legally permissible or otherwise an industry accepted 309 practice in a particular market region, an ISP may in some manner 310 "scan" their IP space in order to detect un-patched or otherwise 311 vulnerable hosts. This may provide the ISP with the opportunity 312 to easily identify Internet users who appear to already be or are 313 at great risk of being infected with a bot. Such scanning should 314 be an unobtrusive and non-disruptive to users and user computers 315 as possible, using tools which such as NMAP 316 (http://www.nmap.org), Nessus (http://www.nessus.org), etc. 318 b. An ISP may also communicate and share selected data, via feedback 319 loops or other mechanisms, with various third parties. Feedback 320 loops are consistently formatted feeds of real-time (or nearly 321 real-time) abuse reports offered by threat data clearinghouses, 322 security alert organizations, ISPs, and other organizations. The 323 data may include, but is not limited to, lists of the IP 324 addresses computers which have or are likely to have a bot 325 running, domain names or fully qualified domain names (FQDNs) 326 known to host malware and/or be involved in the command and 327 control of bot nets, IP addresses know to host malware and/or be 328 involved in the command and control of bot nets, recently tested 329 or discovered techniques or detecting or remediating bot 330 infections, new threat vectors, and other relevant information. 332 c. An ISP may use Netflow [RFC3954] or other similar passive network 333 monitoring to identify bots. For example, an ISP may be able to 334 identify compromised hosts by identifying traffic destined to IP 335 addresses associated with the command and control of bot nets. 337 d. An ISP may use DNS-based techniques to perform detection. For 338 example, a given classified bot may be known to query a specific 339 list of domain names at specific times or on specific dates (in 340 the example of the so-called "Konficker" bot network), typically 341 by matching DNS queries to a well known list of domains 342 associated with malware. In many cases such lists are 343 distributed by or shared using third parties, such as threat data 344 clearinghouses. 346 e. User complaints: Because botted hosts are frequently used to send 347 spam, the ISP servicing those botted hosts will normally receive 348 complaints about that spam. Those complaints may be sent to 349 RFC2142-specified [RFC2142] role accounts, such as abuse@ or 350 postmaster@ or to abuse or security addresses specified by the 351 site as part of its WHOIS (or other) contact data. 353 f. ISPs may also discover likely botted hosts located at other 354 sites; when legally permissible or otherwise an industry accepted 355 practice in a particular market region, it may be worthwhile for 356 ISPs to share evidence relating to those compromised hosts with 357 the relevant remote ISP, with security researchers, and with 358 blocklist operators. 360 5.2. Notification to Internet Users 362 Once an ISP has detected a bot, or the strong likelihood of a bot, 363 steps should be undertaken to inform the Internet user that they may 364 have a bot-related problem. Depending upon a range of factors, from 365 the technical capabilities of the ISP, to the technical attributes of 366 their network, financial considerations, available server resources, 367 available organizational resources, the number of likely infected 368 computers detected at any given time, and the severity of any 369 possible threats, among many other things, an ISP will decide the 370 most appropriate method or methods for providing notification to one 371 or more of their customers or Internet users. Such notification 372 methods may include one or more of the following, as well as other 373 possible methods not described below. It is important to note that 374 none of these methods are guaranteed to be successful, as each has 375 its own set of limitations. In addition, in some cases, and ISP may 376 determine that a combination of two or more methods is most 377 appropriate. Finally, notification is also considered time 378 sensitive; if the user does not receive or view the notification or a 379 timely basis, then a particular bot could launch an attack, exploit 380 the user, or cause other harm. 382 5.2.1. Email Notification 384 This is probably the most common form of notification used by ISPs. 385 One drawback of using email is that it is not guaranteed to be viewed 386 within a reasonable time frame, if at all. The user may be using a 387 different primary email address than that which they have provided to 388 the ISP. In addition, some ISPs do not provide an email account at 389 all, as part of a bundle of Internet services, and/or do not have a 390 need for or manner in which to request or retain the primary email 391 addresses of Internet users of their networks. Another possibility 392 is that the user, their email client, and/or their email servers 393 could determine or classify such a notification as spam, which could 394 delete the message or otherwise file it in an email folder that the 395 user may not check on a regular and/or timely basis. Finally if the 396 user's email credentials are compromised, then a hacker and/or a bot 397 could simply login to the user's email account and delete the email 398 before it is read by the user. 400 5.2.2. Telephone Call Notification 402 A telephone call may be an effective means of communication in 403 particularly high-risk situations. However, telephone calls may not 404 be feasible due to the cost of making a large number of times, as 405 measured in either time, money, organizational resources, server 406 resources, or some other means. In addition, there is no guarantee 407 that the user will answer their phone. To the extent that the 408 telephone number called by the ISP can be answered by the infected 409 computing device, the bot on that computer may be able to disconnect, 410 divert, or otherwise interfere with an incoming call. Users may also 411 interpret such a telephone notification as a telemarketing call and 412 as such not welcome it, or not accept the call at all. Finally, even 413 if a representative of the ISP is able to connect with and speak with 414 a user, that user is very likely to lack the necessary technical 415 experience to understand or be able to effectively deal with the 416 threat. 418 5.2.3. Postal Mail Notification 420 This form of notification is probably the least popular means of 421 communication, due to both preparation time, delivery time and cost. 423 5.2.4. Walled Garden Notification 425 Placing a user in a so-called walled garden is another approach that 426 ISPs may take to notify users. This is an effective technique 427 because it could be able to block all communication between the bot 428 and the command and control channel, which may impair the ability of 429 a bot to disrupt or block attempts to notify the user. 431 While in many cases, the user is almost guaranteed to view the 432 notification message and take any appropriate remediation actions, 433 this approach poses can pose other challenges. For example, it is 434 not always the case that a user is actively using a computer that 435 uses a web browser or which has a web browser actively running on it. 436 In one case, a user could be playing a game online, via the use of a 437 dedicated, Internet-connected game console. In another case, the 438 user may not be using a computer with a web browser when they are 439 placed in the walled garden and may instead be in the course of a 440 telephone conversation, or may be expecting to receive a call, using 441 a Voice Over IP (VOIP) device of some type. As a result, the ISP may 442 feel the need to maintain a potentially lengthy white list of domains 443 which are not subject to the typical restrictions of a walled garden, 444 which could well prove to be an onerous task, from an operational 445 perspective. 447 The ISP has several options to determine when to let the user out of 448 the walled garden. One approach may be to let the user determine 449 when to exit. This option is suggested when the purpose of the 450 walled garden is to notify users and provide information on 451 remediation only, particularly since notification is not a guarantee 452 of successful remediation. It could also be the case that, for 453 whatever reason, the user makes the judgement that they cannot then 454 take the time to remediate their computer and that other online 455 activities which they would like to resume are more important. 457 Once the user acknowledges the notification, then the user decides to 458 either remediate and then exit the walled garden, or exit the walled 459 garden without addressing the issue. Another approach may be to 460 enforce a stricter policy and require the user to clean the computer 461 prior to permitting the user to exit the walled garden, though this 462 may not be technically feasible depending upon the type of bot, 463 obfuscation techniques employed by a bot, and/or a range of other 464 factors. Thus, the ISP may also need to support tools to scan the 465 infected computer and determine whether it is still infected or rely 466 on user judgement that the bot has been disabled or removed. One 467 challenge with this approach is that if the user has multiple 468 computers sharing a single IP address, such as via a common home 469 gateway device which performs Network Address Translation (NAT), then 470 the ISP may need to determine from user feedback or other means that 471 all affected computers have been remediated, which may or may not be 472 technically feasible. 474 5.2.5. Instant Message Notification 476 Instant Message (IM): Instant messaging provides the ISP with a 477 simple means to communicate with the user. There are several 478 advantages of using IM which makes it an attractive option. First, 479 if the ISP provides IM service and the user subscribes to it then the 480 user can be notified easily. Second, IM based notification can be 481 cost effective means to communicate with the use. This can be 482 achieved by signing up for IM service with the various popular IM 483 providers and programatically messaging, if permitted by the 484 acceptable usage policy, the notifications. However, it IM based 485 notification can also be done manually by the ISP's support staff. 486 Ideally, the ISP should allow the user to register the IM identity 487 and seek permission to be contacted via this mean. Third, if the IM 488 service provider supports offline messaging the user can be notified 489 regardless of their signed in status. Essentially a message can be 490 sent and when the user signs in they would receive it. There are 491 several drawbacks with this communications method. First, there is a 492 high probability that subscriber may interpret the communication to 493 be spam and as such ignore it. Second, not every user uses IM and/or 494 the user may not provide their IM identity to the ISP so some 495 alternative means have to be used. Third, there maybe a privacy 496 concern when the communication between the ISP and the end user is 497 not secure and over a third party network and/or IM service. As such 498 the notification must be discreet and not provide any personally 499 identifiable information. 501 5.2.6. Short Message Service (SMS) Notification 503 Short Message Service (SMS): SMS allows the ISP send a brief 504 description of the problem to notify the user of the issue. ISP 505 should allow users to register their mobile number for notifications 506 and also allow users to opt out if they do not wish to be notified. 507 The primary advantage of SMS is that users are used to receiving text 508 messages and are likely to read them. Although users may not act on 509 it immediately if they are not in front of their computer system. 510 One disadvantage is that ISPs may have to follow up with an alternate 511 means of communication if since a SMS message is restricted to 166 512 characters and not all of the necessary information maybe conveyed in 513 one message. Another disadvantage is the cost associated with SMS. 514 The ISP has to either build its own SMS gateway to interface with the 515 various wireless providers or use a third party provider to notify 516 users. It is recommended that the ISP absorb the cost of 517 notification and should always state in the notification that the 518 message is free of charge to the user. Another small disadvantage is 519 that it is possible to notify the wrong user if the intended user 520 changes their mobile number but forgets to update it with the ISP. 522 5.2.7. Web Browser Notification 524 Near real-time notification to the user's web browser is another 525 technique that may be utilized for notifying the user, though how 526 such a system might operate is outside the scope of this document. 527 Such a notification could have a comparative advantage over a walled 528 garden notification, in that it does not restrict traffic to a 529 specified list of destinations in the same way that a walled garden 530 by definition would. However, as with a walled garden notification, 531 there is no guarantee that a user is at any given time making use of 532 a web browser, though such a system could certainly provide a 533 notification when such a browser is eventually used. Compared to a 534 walled garden, a web browser notification is probably preferred from 535 the perspective of Internet users, as it does not have the risk of 536 disrupting non-web sessions, such as online games, etc. (as noted in 537 Section 5.2.4). 539 5.3. Remediation of Bot Infected Machines 541 This section covers the different options available to remediate a 542 computer, which means to remove, disable, or otherwise render a bot 543 harmless. Prior to this step, an ISP has detected the bot, notified 544 the user that one of their computers is infected with a bot, and now 545 has to provide some means to clean the PC. The generally recommended 546 approach is to provide the necessary tools and education to the user 547 so that they may perform bot remediation themselves. 549 For example, this may include the creation of a special Security Web 550 Portal. This should be a well-publicized security portal to which a 551 user with a bot problem can be directed to for remediation. This 552 Security Web Portal should clearly explain why the user was notified 553 and may include an explanation of what bots are and the threats that 554 they pose. There should be a clear explanation of the steps that the 555 user should take in order to clean the computers and provide 556 information on how users can keep the computer free of future 557 infections. The Security Web Portal should have a guided process 558 that takes non technical users through the remediation process. 560 In terms of the text user to explain what bots are and the threat 561 they pose, something simple such as this may suffice: 563 "What is a bot? A bot is a piece of software, generally installed on 564 your machine without your knowledge, which either sends spam or tries 565 to steal your personal information. They can be very difficult to 566 spot, though you may have noticed that your computer is running much 567 more slowly than usual or you notice regular disk activity even when 568 you are not doing anything. Ignoring this problem is not really an 569 option since your personal information is currently at risk. Thus, 570 bots need to be removed to protect your data and your personal 571 information." 573 5.4. Guided Remediation Process 575 Minimally the Guided Remediation Process should include options 576 and/or recommendations on how a user should: 578 1. If the user is interested in reporting his or her computer's bot 579 infection to an applicable law enforcement authority, then the 580 computer effectively becomes a cyber "crime scene" and should not 581 be mitigated unless or until law enforcement has collected the 582 necessary evidence. For individuals in this situation, the ISP 583 should refer them to local, state, federal, or other relevant 584 computer crime offices. (Note: Some "minor" incidents, even if 585 highly traumatic to the user, may not be sufficiently serious for 586 law enforcement to commit some of their limited resources to an 587 investigation.) 589 2. Regardless of whether the user or a knowledgeable technical 590 assistant is working on remediating the computer, their first 591 task should be to determine which of multiple potentially- 592 infected machines may be the one that needs attention (in the 593 common case of multiple computers in a home network). Sometimes, 594 as in cases where there is only a single directly-attached 595 computer, or the user has been noticing problems with one of 596 their computers, this can be easy. Other times, it may be more 597 difficult. If the user is behind a home gateway/router, then the 598 first task may be to ascertain which of the machines is infected. 599 In some cases the user may have to check all machines to identify 600 the infected one. Thus, it is possible that an individual 601 computer may have multiple bot infections and, in addition, 602 multiple computers on the home network may be infected. 604 3. Perform a FULL backup of the affected computers. 606 4. Download OS patches and Anti-Virus (A/V) software updates. For 607 example, for OS patches, links could be provided to Microsoft 608 Windows updates and Apple MacOS updates could be provided. 610 5. Run a scan using installed A/V software. 612 6. Explain how to configure the computer to automatically install 613 updates for the OS, A/V and other common Web Browsers such as 614 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 615 Opera, and Google Chrome. 617 7. The flow should also have the option for users to get 618 professional assistance if they are unable to remove the bots 619 themselves. If purchasing third party assistance, then the user 620 should be encouraged to pre-determine how much they are willing 621 to pay for that help. If the computer that is being remediated 622 is old and can easily be replaced with a new, faster, larger and 623 more reliable system for three or four hundred dollars, the it 624 makes no sense to spend five or six hundred dollars to fix the 625 old computer, for example. On the other hand, if the customer 626 has a brand new computer that cost several thousand dollars, it 627 might make perfect sense to spend the money in attempting to 628 remediate it. 630 8. User surveys to solicit feedback on whether the notification and 631 remediation process is effective and what recommended changes 632 could be made in order to improve the ease, understandability, 633 and effectiveness the remediation process. 635 There are many cases where a user may not be a residential user, in 636 which case some of these steps may not apply. For example, the user 637 may be part of a business, educational institution, non-profit 638 company, or other organization. In these cases, the user should 639 immediately seek out the support of their information technology 640 support team. 642 6. Security Considerations 644 Scanning systems for missing patches, while a good and necessary 645 task, may nonetheless result in systems being knocked offline. 647 Conveying a system to a third party for cleaning may result in 648 sensitive contents of that system (confidential email or images, 649 unauthorized access to remote systems via stored passwords, etc.) 650 being inadvertently disclosed to the third party. 652 Passive network monitoring, even of encrypted traffic, may result in 653 sensitive information leaking (e.g., merely knowing that a user is 654 connecting to a site about a particular subject may prompt one to 655 infer an interest in that particular subject). 657 7. IANA Considerations 659 There are no IANA considerations in this document. 661 8. Contributors 663 The authors wish to acknowledge the following individuals for their 664 textual contribution to and detailed reviews of this document: 666 Joe St. Sauver, University of Oregon and Internet2 (joe@uoregon.edu) 668 9. Normative References 670 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 671 RFC 1459, May 1993. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 677 FUNCTIONS", RFC 2142, May 1997. 679 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 680 9", RFC 3954, October 2004. 682 Appendix A. Document Change Log 684 [RFC Editor: This section is to be removed before publication] 686 -00 version: 688 o -00 version published 690 Appendix B. Open Issues 692 [RFC Editor: This section is to be removed before publication] 694 Could use some informational references in Section 3 696 Fix the odd list spacing in Section 5.1 698 Add some point about notification to large networks may not be useful 699 -- such as coffee shops or hotels with WiFi networks. 701 Consider combining 5.b and 5.f., and possibly re-wording some of the 702 other items. 704 Consider adding mention to the use of ccleaner in section 5.4 705 Significantly revise and expand section 5.4 707 Add discussion of root kits and other bits of malware that may 708 actively resist detection and removal (e.g., attempting to disinfect 709 a system while running an infected OS can be a rather futile 710 exercise; you have a much better chance of detecting malware if you 711 mount the infected disk on a third party system for review and 712 disinfection) 714 add discussion on restoring files from the backups if nuke and pave 715 is required. 717 add discussion of user education to help prevent repeat infections 719 consider adding discussion of the ISP's role in the remediation 720 process -- I think this is a key consideration. Liability issues, 721 cost issues and other factors should be laid out so that users 722 understand why the ISP doesn't just "do it for them." 724 Authors' Addresses 726 Jason Livingood 727 Comcast Cable Communications 728 One Comcast Center 729 1701 John F. Kennedy Boulevard 730 Philadelphia, PA 19103 731 US 733 Email: jason_livingood@cable.comcast.com 734 URI: http://www.comcast.com 736 Nirmal Mody 737 Comcast Cable Communications 738 One Comcast Center 739 1701 John F. Kennedy Boulevard 740 Philadelphia, PA 19103 741 US 743 Email: nirmal_mody@cable.comcast.com 744 URI: http://www.comcast.com 745 Mike O'Reirdan 746 Comcast Cable Communications 747 One Comcast Center 748 1701 John F. Kennedy Boulevard 749 Philadelphia, PA 19103 750 US 752 Email: michael_oreirdan@cable.comcast.com 753 URI: http://www.comcast.com