idnits 2.17.1 draft-oreirdan-mody-bot-remediation-02.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 11, 2009) is 5338 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 15, 2010 Comcast 6 September 11, 2009 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-02 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 15, 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 . . . . . . . . . . . . . . . 7 77 5. Detection, Notification and Remediation . . . . . . . . . . . 7 78 5.1. Detection of Bots . . . . . . . . . . . . . . . . . . . . 8 79 5.2. Notification to Internet Users . . . . . . . . . . . . . . 11 80 5.3. Remediation of Bot Infected Machines . . . . . . . . . . . 15 81 5.4. Guided Remediation Process . . . . . . . . . . . . . . . . 16 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 85 9. Informative references . . . . . . . . . . . . . . . . . . . . 18 86 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 19 87 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Key Terminology 98 This section defines the key terms used in this document. 100 2.1. Malicious Bots, or Bots 102 A malicious "bot" (derived from the word "robot", hereafter simply 103 referred to as a "bot") refers to a program that is surreptitiously 104 installed on a system in order to enable that system to automatically 105 (or semi-automatically) perform a task or set of tasks typically 106 under the command and control of a remote administrator, or "bot 107 master." Bots are also known as "zombies". It is important to note 108 that there are 'good', or benign bots. Such benign bots are often 109 found in such environments such as gaming and Internet Relay Chat 110 (IRC) [RFC1459], where a continual, interactive presence can be a 111 requirement for participating in the games, interacting with a 112 computing resource, or other purposes. 114 However, for the purposes of this document, all mention of bots 115 should assume that the bots involved are malicious in nature. Such 116 malicious bots shall generally be assumed to have been deployed 117 without the permission or conscious understanding of a particular 118 Internet user. Thus, without a user's knowledge, bots may transform 119 the user's computing device into a platform from which malicious 120 activities can be conducted. 122 2.2. Bot Networks, or Botnets 124 These are defined as concerted networks of bots capable of acting on 125 instructions generated remotely. The malicious activities are either 126 focused on the information on the local machine or acting to provide 127 services for remote machines. Bots are highly customizable so they 128 can be programmed to do many things. The major malicious activities 129 include: identity theft, spam, distributed denial of service (DDoS) 130 attacks, key-logging, fraudulent DNS (pharming), proxy services, fast 131 flux hosting and click fraud. 133 Infection vectors include un-patched operating systems, software 134 vulnerabilities, weak/non-existent passwords, malicious websites, un- 135 patched browsers, malware, vulnerable helper applications and social 136 engineering techniques to gain access to the user's computer. The 137 detection and destruction of bots is an ongoing issue and also a 138 constant battle between the internet security community, network 139 security engineers and bot developers. 141 Initially, bots used IRC to communicate but were easy to shutdown if 142 the command and control server was identified and deactivated. Newer 143 command and control methods have evolved, such that those currently 144 employed by bot masters make them much more resistant to 145 deactivation. With the introduction of P2P, HTTP and other resilient 146 communication protocols along with the widespread adoption of 147 encryption, bots are considerably more difficult to identify and 148 isolate from typical network usage. As a result increased reliance 149 is being placed on anonmaly detection and behavioral analysis, both 150 locally and remotely, to identify bots. 152 2.3. Computer 154 A computer, as used in the context of this document, is intended to 155 refer to a computing device that connects to the Internet. This 156 encompasses devices used directly by Internet users such as personal 157 computers, including laptops, desktops, and netbooks, as well as 158 mobile phones, smart phones, home gateway devices, and other end user 159 computing devices which are connected or can connect to the public 160 Internet and/or private IP networks. 162 Increasingly, other household systems and devices contain embedded 163 computers which are connected or can connect to the public Internet 164 and/or private IP networks. However, these devices may not be under 165 interactive control of the Internet user, such as may be the case 166 with various smart home and smart grid devices. 168 2.4. Malware 170 This is short for malicious software. In this case, malicious bots 171 are considered a subset of malware. Other forms of malware could 172 include viruses and other similar types of software. Internet users 173 can sometimes cause their computer to be infected with malware, which 174 may include a bot or cause a bot to install itself, via inadvertently 175 accessing a specific website, downloading a specific file, or other 176 activities. 178 Alternatively, Internet-connected computers may become infected with 179 malware through externally initiated malicious activities such as the 180 exploitation of vulnerabilities or the brute force guessing of access 181 credentials. 183 3. Introduction and Problem Statement 185 Computers used by Internet users, which in this case are customers of 186 an Internet Service Provider (ISP), can be infected with malware 187 which may contain and/or install one or more bots on a computer. 188 This can present a major problem for an ISP for a number of reasons 189 (not to mention of course the problems created for users). First, 190 these bots can be used to send spam, in some cases very large volumes 191 of spam. This spam can result in extra cost for the ISPs in terms of 192 wasted network, server, and/or personnel resources, among many other 193 potential costs or side effects. Such spam can also negatively 194 affect the reputation of the ISP, their customers, and the email 195 reputation of the IP address space used by the ISP (often referred to 196 simply as "IP reputation"). 198 In addition, these bots can act as platforms for directing, 199 participating in, or otherwise conducting attacks on critical 200 Internet infrastructure. Bots are frequently used as part of 201 concerted Distributed Denial of Service (DDoS) attacks for criminal, 202 political or other motivations. For example, bots have been used to 203 attack Internet resources and infrastructure ranging from web sites, 204 to email servers and DNS servers, as well as the critical Internet 205 infrastructure of entire countries. Motivations for such coordinated 206 DDoS attacks can range from criminal extortion attempts through to 207 online protesting and nationalistic fervor. 209 While any computing device can be infected with bots, the majority of 210 bot infections affect the personal computers used by Internet end 211 users. As a result of the role of ISPs in providing IP connectivity, 212 among many other services, to Internet users, these ISPs are in a 213 unique position to be able to attempt to detect and observe bot nets 214 operating in their networks. Furthermore, ISPs may also be in a 215 unique position to be able to communicate to Internet users which are 216 their customers, when customers computers may have been determined to 217 have been or possibly have been infected with one or more bots. 219 From an end user perspective, knowing that their computer has been 220 infected with one or more bots is very important information. Once 221 they know this, they can take steps to remove the bot, protect 222 themselves in the future, and resolve any problems which may stem 223 from the bot infection. Given that bots can drain the local 224 computing and network resources, enable theft of personal information 225 (including personal financial information), enable the computer to be 226 used from criminal activities (that may result in the Internet user 227 being legally culpable), destroy or leave the PC in an unrecoverable 228 state via 'kill switch' bot technologies, it is important to notify 229 the user that they may be infected with a bot. 231 As a result, the intent of this document is to provide a guide to 232 ISPs and other organizations for the remediation of these computers 233 infected with bots, so as to reduce the size of bot nets and minimize 234 the potential harm that bots can inflict upon Internet infrastructure 235 generally, as well as on individual Internet users. Efforts by ISPs 236 and other organizations could therefore, over time, reduce the pool 237 of computers infected with bots on the Internet, which in turn could 238 result in smaller bot nets with less capability for disruption. 240 4. Important Notice of Limitations 242 The techniques described in this document in no way guarantee the 243 remediation of all bots. Bot removal is potentially a task requiring 244 specialized knowledge, skills and tools, and may be beyond the 245 ability of average users. Attempts at bot removal may frequently be 246 unsuccessful, or only partially successful, and may leave a user's 247 system in an unstable and unsatisfactory state or even still 248 infected. Attempts at bot removal can also result in side effects 249 ranging from a loss of data or other files, all the way through 250 partial or complete loss of system usability. 252 In general, the only way a user can be sure they have removed some of 253 today's increasingly sophisticated malware is by "nuking-and-paving" 254 the system: reformatting the drive, reinstalling the operating system 255 and applications (including all patches) from scratch, and then 256 restoring user files from a clean backup. However the introduction 257 of BIOS based malware may mean that in some cases, this will not be 258 enough and may prove to be more than any end user can be reasonably 259 expected to resolve. 261 Devices with embedded operating systems, such as video gaming 262 consoles and smart home appliances, will most likely be beyond a 263 user's capability to remediate by themselves, and will typically 264 require the aid of vendor specific advice, updates and tools. Care 265 must be taken when imparting remediation advice to Internet users 266 given the increasingly wide array of computing devices that can be, 267 or could be, bot infected in the future. 269 5. Detection, Notification and Remediation 271 The potential mitigation of bots is accomplished through a process of 272 detection, notification to Internet users, and remediation of that 273 bot with a variety of tools. 275 5.1. Detection of Bots 277 An ISP must first identify that an Internet user, in this case a user 278 that is assumed to be their customer or otherwise connected to the 279 ISP's network, is determined to be infected, or likely to have been 280 infected with a bot. The ISP should attempt to detect the presence 281 of bots using methods, processes, and tools which maintain the 282 privacy of the personally identifiable information of their 283 customers. The ISP also should not block legitimate traffic in the 284 course of bot detection, and should instead employ detection methods, 285 tools, and processes which seek to be non-disruptive, as well as 286 being transparent to Internet users. 288 Detection methods, tools, and processes may include things such as 289 analysis of specific network and/or application traffic flows (such 290 as traffic to an email server), analysis of aggregate network and/or 291 application traffic data, data feeds received from other ISPs and 292 organizations (such as lists of the ISP's IP addresses which have 293 been reported to have sent spam), feedback from the ISP's customers 294 or other Internet users, as well as a wide variety of other 295 possibilities. It is likely that a combination of multiple bot 296 detection data points will prove to be an effective approach in order 297 to corroborate information of varying dependability or consistency, 298 as well as to avoid or minimize the possibility of false positive 299 identification of computers. Detection should also, where possible 300 and feasible, attempt to classify a bot in order to confirm that it 301 is malicious in nature, estimate the variety and severity of threats 302 it may pose (such as spam bot, key-logging bot, file distribution 303 bot, etc.), and to determine potential methods for eventual 304 remediation. However, given the dynamic nature of botnet management 305 and the criminal incentives to seek quick financial rewards, botnets 306 frequently update or change their core malicious capabilities. As a 307 consequence, botnets that are initially detected and classified by 308 the ISP need to be continuously monitored and tracked in order to 309 correctly identify the threat they pose at any particular point in 310 time. 312 Detection is also time-sensitive. If complex analysis is required 313 and multiple confirmations are needed to confirm a bot is indeed 314 present, then it is possible that the bot will do its damage (to 315 either the infected computer or a remotely targeted system) before it 316 can be stopped. This may mean that an ISP may need to balance the 317 desire or need to definitively classify and/or confirm a bot, which 318 may take an extended period of time, with the ability to predict the 319 strong likelihood of a bot in a very short period of time. This also 320 means that Internet users may benefit from the deployment of client- 321 based software protections or other software tools, which can enable 322 rapid performance of heuristically-based detection bot activity, such 323 as 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' personally identifiable information is 330 maintained. While bot detection methods, tools, and processes are 331 similar to spam and virus defenses deployed by the ISP for the 332 benefits of their customers (and may be directly related to those 333 defenses), attempts to detect bots should take into account the need 334 of an ISP to take care to ensure that such personally identifiable 335 information is properly protected. Finally, depending upon the 336 geographic region within which an ISP operates, certain methods 337 relating to bot detection may need to be included in relevant terms 338 of service documents or other documents which are available to the 339 customers of a particular ISP. 341 There are several bot detection methods, tools, and processes that an 342 ISP may choose to utilize, as noted in the list below. It is 343 important to note that the technical solutions available are 344 relatively immature, and are likely to change over time, and to 345 evolve rapidly in the coming years. While these items are described 346 in relation to ISPs, they may also be applicable to organizations 347 operating other networks, such as campus networks and enterprise 348 networks. 350 a. Where legally permissible or otherwise an industry accepted 351 practice in a particular market region, an ISP may in some manner 352 "scan" their IP space in order to detect un-patched or otherwise 353 vulnerable hosts. This may provide the ISP with the opportunity 354 to easily identify Internet users who appear to already be or are 355 at great risk of being infected with a bot. ISP's should note 356 that some types of port scanning may leave network services in a 357 hung state or render them unusable due to common frailties, and 358 that many modern firewall and host-based intrusion detection 359 implementations may alert the Internet user to the scan. As a 360 result the scan may be interpreted as a malicious attack against 361 the computer. Vulnerability scanning has a higher probability of 362 leaving accessible network services and applications in a damaged 363 state and will often result in a higher probability of detection 364 by the Internet user and subsequent interpretation as a targeted 365 attack. Depending upon the vulnerability being scanned, some 366 automated methods of vulnerability checking may result in data 367 being altered or created afresh on the Internet users computer 368 which be a problem in many legal environments. 370 b. An ISP may also communicate and share selected data, via feedback 371 loops or other mechanisms, with various third parties. Feedback 372 loops are consistently formatted feeds of real-time (or nearly 373 real-time) abuse reports offered by threat data clearinghouses, 374 security alert organizations, other ISPs, and other 375 organizations. The data may include, but is not limited to, 376 lists of the IP addresses computers which have or are likely to 377 have a bot running, domain names or fully qualified domain names 378 (FQDNs) known to host malware and/or be involved in the command 379 and control of botnets, IP addresses know to host malware and/or 380 be involved in the command and control of botnets, recently 381 tested or discovered techniques or detecting or remediating bot 382 infections, new threat vectors, and other relevant information. 383 Good examples of this include SNDS from Microsoft, XBL and PBL 384 from Spamhaus and DSHIELD AS tool from SANS 386 c. An ISP may use Netflow [RFC3954] or other similar passive network 387 monitoring to identify network anomalies that may be indicative 388 of botnet attacks or bot communications. For example, an ISP may 389 be able to identify compromised hosts by identifying traffic 390 destined to IP addresses associated with the command and control 391 of botnets. In addition, bots can be idenfied when a remote host 392 is under distribute attack because computers participating in the 393 attack will likely be infected by a bot. 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. 402 Alternative dynamic DNS based techniques may look for 403 associations of domain names with known bad actor lists and 404 networks with poor reputations, or heuristic techniques that rank 405 the domain name based upon previously identified botnet usage and 406 bot characteristics. 408 e. User complaints: Because bot infected hosts are frequently used 409 to send spam or participate in DDoS attacks, the ISP servicing 410 those hosts will normally receive complaints about the malicious 411 network traffic. Those complaints may be sent to RFC2142- 412 specified [RFC2142] role accounts, such as abuse@ or postmaster@ 413 or to abuse or security addresses specified by the site as part 414 of its WHOIS (or other) contact data. 416 f. ISPs may also discover likely bot infected hosts located at other 417 sites; when legally permissible or otherwise an industry accepted 418 practice in a particular market region, it may be worthwhile for 419 ISPs to share evidence relating to those compromised hosts with 420 the relevant remote ISP, with security researchers, and with 421 blocklist operators. 423 g. ISP's may operate or subscribe to services that provide 424 sinkholing or honeynet capabilities. This enable the ISP to 425 obtain realtime lists of bot infected computers as they attempt 426 to join the larger botnet or propagate. These technologies may 427 allow the ISP to enumerate bot infections within their customer 428 population. 430 5.2. Notification to Internet Users 432 Once an ISP has detected a bot, or the strong likelihood of a bot, 433 steps should be undertaken to inform the Internet user that they may 434 have a bot related problem. Depending upon a range of factors, from 435 the technical capabilities of the ISP, to the technical attributes of 436 their network, financial considerations, available server resources, 437 available organizational resources, the number of likely infected 438 computers detected at any given time, and the severity of any 439 possible threats, among many other things, an ISP will decide the 440 most appropriate method or methods for providing notification to one 441 or more of their customers or Internet users. Such notification 442 methods may include one or more of the following, as well as other 443 possible methods not described below. It is important to note that 444 none of these methods are guaranteed to be successful, as each has 445 its own set of limitations. In addition, in some cases, and ISP may 446 determine that a combination of two or more methods is most 447 appropriate. Finally, notification is also considered time 448 sensitive; if the user does not receive or view the notification or a 449 timely basis, then a particular bot could launch an attack, exploit 450 the user, or cause other harm. If possible, an ISP should establish 451 a preferred means of communication when the subscriber first signs up 452 for service. As a part of the notification process, ISPs should 453 maintain a record of the allocation of IP addresses to subscribers 454 for such a period as allows any bot detection technology to be 455 accurately able to link an infected IP address to a subscriber. This 456 record should only be maintained for a period which is consonant with 457 the protection of the privacy of the individual subscriber. 459 One important factor to bear in mind is that notification to end 460 users needs to be defended against spoofing by third parties. This 461 must be done to protect against the possibility of notifications 462 being spoofed and used by bots to deliver additional malware. 464 5.2.1. Email Notification 466 This is probably the most common form of notification used by ISPs. 467 One drawback of using email is that it is not guaranteed to be viewed 468 within a reasonable time frame, if at all. The user may be using a 469 different primary email address than that which they have provided to 470 the ISP. In addition, some ISPs do not provide an email account at 471 all, as part of a bundle of Internet services, and/or do not have a 472 need for or manner in which to request or retain the primary email 473 addresses of Internet users of their networks. Another possibility 474 is that the user, their email client, and/or their email servers 475 could determine or classify such a notification as spam, which could 476 delete the message or otherwise file it in an email folder that the 477 user may not check on a regular and/or timely basis. Bot masters 478 have also been known to impersonate the ISP or trusted sender and 479 send fradulant emails to the users. This technique of solical 480 engineering often leads to new bot infestations. Finally if the 481 user's email credentials are compromised, then a hacker and/or a bot 482 could simply login to the user's email account and delete the email 483 before it is read by the user. 485 5.2.2. Telephone Call Notification 487 A telephone call may be an effective means of communication in 488 particularly high-risk situations. However, telephone calls may not 489 be feasible due to the cost of making a large number of times, as 490 measured in either time, money, organizational resources, server 491 resources, or some other means. In addition, there is no guarantee 492 that the user will answer their phone. To the extent that the 493 telephone number called by the ISP can be answered by the infected 494 computing device, the bot on that computer may be able to disconnect, 495 divert, or otherwise interfere with an incoming call. Users may also 496 interpret such a telephone notification as a telemarketing call and 497 as such not welcome it, or not accept the call at all. Finally, even 498 if a representative of the ISP is able to connect with and speak with 499 a user, that user is very likely to lack the necessary technical 500 experience to understand or be able to effectively deal with the 501 threat. 503 5.2.3. Postal Mail Notification 505 This form of notification is probably the least popular means of 506 communication, due to both preparation time, delivery time and cost 507 however, it may be more effective than email even when delivering an 508 identical message. Optionally the notification of bot infection can 509 be printed on the bill when the subscriber is taking a billable 510 service. 512 5.2.4. Walled Garden Notification 514 Placing a user in a walled garden is another approach that ISPs may 515 take to notify users. A walled garden refers to an environment that 516 controls the information and services that a subscriber is allowed to 517 utilize and what network access permissions are granted. This is an 518 effective technique because it could be able to block all 519 communication between the bot and the command and control channel, 520 which may impair the ability of a bot to disrupt or block attempts to 521 notify the user. 523 While in many cases, the user is almost guaranteed to view the 524 notification message and take any appropriate remediation actions, 525 this approach poses can pose other challenges. For example, it is 526 not always the case that a user is actively using a computer that 527 uses a web browser or which has a web browser actively running on it. 528 In one case, a user could be playing a game online, via the use of a 529 dedicated, Internet-connected game console. In another case, the 530 user may not be using a computer with a web browser when they are 531 placed in the walled garden and may instead be in the course of a 532 telephone conversation, or may be expecting to receive a call, using 533 a Voice Over IP (VOIP) device of some type. As a result, the ISP may 534 feel the need to maintain a potentially lengthy white list of domains 535 which are not subject to the typical restrictions of a walled garden, 536 which could well prove to be an onerous task, from an operational 537 perspective. 539 The ISP has several options to determine when to let the user out of 540 the walled garden. One approach may be to let the user determine 541 when to exit. This option is suggested when the purpose of the 542 walled garden is to notify users and provide information on 543 remediation only, particularly since notification is not a guarantee 544 of successful remediation. It could also be the case that, for 545 whatever reason, the user makes the judgment that they cannot then 546 take the time to remediate their computer and that other online 547 activities which they would like to resume are more important. Exit 548 from the walled garden should involve require process to verify that 549 it is indeed the user who is requesting exit from the walled garden 550 and not the bot. 552 Once the user acknowledges the notification, then the user decides to 553 either remediate and then exit the walled garden, or exit the walled 554 garden without addressing the issue. Another approach may be to 555 enforce a stricter policy and require the user to clean the computer 556 prior to permitting the user to exit the walled garden, though this 557 may not be technically feasible depending upon the type of bot, 558 obfuscation techniques employed by a bot, and/or a range of other 559 factors. Thus, the ISP may also need to support tools to scan the 560 infected computer and determine whether it is still infected or rely 561 on user judgment that the bot has been disabled or removed. One 562 challenge with this approach is that if the user has multiple 563 computers sharing a single IP address, such as via a common home 564 gateway device which performs Network Address Translation (NAT), then 565 the ISP may need to determine from user feedback or other means that 566 all affected computers have been remediated, which may or may not be 567 technically feasible. 569 A list of well known addresses for both operating system vendors and 570 security vendors should be created. This can be referenced when 571 allowing access from the walled garden by end users in search of 572 operating system and application patches. 574 5.2.5. Instant Message Notification 576 Instant Message (IM): Instant messaging provides the ISP with a 577 simple means to communicate with the user. There are several 578 advantages to using IM which makes it an attractive option. If the 579 ISP provides IM service and the user subscribes to it then the user 580 can be notified easily. IM based notification can be cost effective 581 means to communicate with the use. This can be achieved by signing 582 up for IM service with the various popular IM providers and 583 programatically messaging, if permitted by the acceptable usage 584 policy, the notifications. However, IM based notification can also 585 be done manually by the ISP's support staff. Ideally, the ISP should 586 allow the user to register the IM identity and seek permission to be 587 contacted via this means. If the IM service provider supports 588 offline messaging the user can be notified regardless of their signed 589 in status. Essentially a message can be sent and when the user signs 590 in they would receive it. There are several drawbacks with this 591 communications method. There is a high probability that subscriber 592 may interpret the communication to be spam and as such ignore it. 593 Not every user uses IM and/or the user may not provide their IM 594 identity to the ISP so some alternative means have to be used. There 595 maybe a privacy concern when the communication between the ISP and 596 the end user is not secure and over a third party network and/or IM 597 service. As such the notification must be discreet and not provide 598 any personally identifiable information. 600 5.2.6. Short Message Service (SMS) Notification 602 Short Message Service (SMS): SMS allows the ISP send a brief 603 description of the problem to notify the user of the issue. The ISP 604 should allow users to register their mobile number for notifications 605 and also allow users to opt out if they do not wish to be notified. 606 The primary advantage of SMS is that users are used to receiving text 607 messages and are likely to read them. Users may not act on the 608 notification immediately if they are not in front of their computer 609 system. One disadvantage is that ISPs may have to follow up with an 610 alternate means of notification if not all of the necessary 611 information maybe conveyed in one message. This is becuase SMS 612 messages are limited to 140 characters. Another disadvantage with 613 SMS is the cost associated with it. The ISP has to either build its 614 own SMS gateway to interface with the various wireless service 615 providers or use a third party provider to notify users. It is 616 recommended that the ISP absorb the cost of notification and should 617 always state in the notification that the message is free of charge 618 to the user. Another small disadvantage is that it is possible to 619 notify the wrong user if the intended user changes their mobile 620 number but forgets to update it with the ISP. 622 5.2.7. Web Browser Notification 624 Near real-time notification to the user's web browser is another 625 technique that may be utilized for notifying the user, though how 626 such a system might operate is outside the scope of this document. 627 Such a notification could have a comparative advantage over a walled 628 garden notification, in that it does not restrict traffic to a 629 specified list of destinations in the same way that a walled garden 630 by definition would. However, as with a walled garden notification, 631 there is no guarantee that a user is at any given time making use of 632 a web browser, though such a system could certainly provide a 633 notification when such a browser is eventually used. Compared to a 634 walled garden, a web browser notification is probably preferred from 635 the perspective of Internet users, as it does not have the risk of 636 disrupting non-web sessions, such as online games, etc. (as noted in 637 Section 5.2.4). 639 5.3. Remediation of Bot Infected Machines 641 This section covers the different options available to remediate a 642 computer, which means to remove, disable, or otherwise render a bot 643 harmless. Prior to this step, an ISP has detected the bot, notified 644 the user that one of their computers is infected with a bot, and now 645 has to provide some means to clean the PC. The generally recommended 646 approach is to provide the necessary tools and education to the user 647 so that they may perform bot remediation themselves. 649 For example, this may include the creation of a special Security Web 650 Portal. This should be a well-publicized security portal to which a 651 user with a bot problem can be directed to for remediation. This 652 Security Web Portal should clearly explain why the user was notified 653 and may include an explanation of what bots are and the threats that 654 they pose. There should be a clear explanation of the steps that the 655 user should take in order to clean the computers and provide 656 information on how users can keep the computer free of future 657 infections. The Security Web Portal should have a guided process 658 that takes non technical users through the remediation process. 660 In terms of the text user to explain what bots are and the threat 661 they pose, something simple such as this may suffice: 663 "What is a bot? A bot is a piece of software, generally installed on 664 your machine without your knowledge, which either sends spam or tries 665 to steal your personal information. They can be very difficult to 666 spot, though you may have noticed that your computer is running much 667 more slowly than usual or you notice regular disk activity even when 668 you are not doing anything. Ignoring this problem is not really an 669 option since your personal information is currently at risk. Thus, 670 bots need to be removed to protect your data and your personal 671 information." 673 It is also important to note that it may not be immediately apparent 674 to the Internet user precisely which device has been or which 675 multiple devices have been infected with a particular bot. This is 676 because of the user's home-networking configurations and the growing 677 prevalence of IP enabled devices within a household that now connect 678 to the public Internet and/or Private IP networks. The consequence 679 of this for an ISP is that remediation advice may not ultimately be 680 actionable by the Internet user. For example, the Internet user may 681 be operating a computer, a notebook, a video console and multimedia 682 system on their personal network. All of these device may connect to 683 the Internet via a single gateway appliance. Any of these devices 684 can be infected with a bot through a number of vectors. yet the 685 remediation advice is likely to be quite different and may or may not 686 be directly serviceable by the Internet user. Diligence needs to be 687 taken by the ISP in understanding the specific nature of the device 688 that has been infected with a bot, and providing appropriate 689 remediation advice. 691 5.4. Guided Remediation Process 693 Minimally the Guided Remediation Process should include options 694 and/or recommendations on how a user should: 696 1. Backup personal Documents, for example: "Before you start, make 697 sure to back up all of your important data. (You should do this 698 on a regular basis anyway.) You can back up your files manually 699 or using a system back-up software utility, which may be part of 700 your Operating System (OS). You can back your files up to a USB 701 Thumb Drive (aka USB Key), a CD/DVD-ROM, an external hard drive, 702 or a network file server." 704 2. Download OS patches and Anti-Virus (A/V) software updates. For 705 example, links could be provided to Microsoft Windows updates at 706 http://update.microsoft.com/microsoftupdate/v6/ 707 default.aspx?ln=en-us as well as to Apple MacOS updates at 708 http://support.apple.com/kb/HT1338?viewlocale=en_US. 710 3. Explain how to configure the computer to automatically install 711 updates for the OS, A/V and other common Web Browsers such as 712 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 713 Opera, and Google Chrome. 715 4. The flow should also have the option for users to get 716 professional assistance if they are unable to remove the bots 717 themselves. If purchasing third party assistance, then the user 718 should be encouraged to pre-determine how much they are willing 719 to pay for that help. If the computer that is being remediated 720 is old and can easily be replaced with a new, faster, larger and 721 more reliable system for three or four hundred dollars, the it 722 makes no sense to spend five or six hundred dollars to fix the 723 old computer, for example. On the other hand, if the customer 724 has a brand new computer that cost several thousand dollars, it 725 might make perfect sense to spend the money in attempting to 726 remediate it. 728 5. To continue, regardless of whether the user or a knowledgeable 729 technical assistant is working on remediating the computer, their 730 first task should be to determine which of multiple potentially- 731 infected machines may be the one that needs attention (in the 732 common case of multiple computers in a home network). Sometimes, 733 as in cases where there is only a single directly-attached 734 computer, or the user has been noticing problems with one of 735 their computers, this can be easy. Other times, it may be more 736 difficult. If the user is behind a home gateway/router, then the 737 first task may be to ascertain which of the machines is infected. 738 In some cases the user may have to check all machines to identify 739 the infected one. 741 6. User surveys to solicit feedback on whether the notification and 742 remediation process is effective and what recommended changes 743 could be made in order to improve the ease, understandability, 744 and effectiveness the remediation process. 746 7. If the user is interested in reporting his or her computer's bot 747 infection to an applicable law enforcement authority, then the 748 computer effectively becomes a cyber "crime scene" and should not 749 be mitigated unless or until law enforcement has collected the 750 necessary evidence. For individuals in this situation, the ISP 751 should refer them to local, state, federal, or other relevant 752 computer crime offices. (Note: Some "minor" incidents, even if 753 highly traumatic to the user, may not be sufficiently serious for 754 law enforcement to commit some of their limited resources to an 755 investigation.) 757 6. Security Considerations 759 There are no security considerations to include at this time. 761 7. IANA Considerations 763 There are no IANA considerations in this document. 765 8. Acknowledgements 767 The authors wish to acknowledge the following individuals and 768 organisations for their review and feedback of this document: 770 Jonathan Curtis 772 Jeff Chan 774 Roland Dobbins 776 Eliot Gillum 778 Messaging Anti-Abuse Working Group (MAAWG) 780 Jose Nazario 782 Gunter Ollmann 784 Eric Ziegast 786 9. Informative references 788 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 789 RFC 1459, May 1993. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 795 FUNCTIONS", RFC 2142, May 1997. 797 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 798 9", RFC 3954, October 2004. 800 Appendix A. Document Change Log 802 [RFC Editor: This section is to be removed before publication] 804 -02 version: 806 o all updates from Jason - still some open issues but we're now at a 807 place where we can solicit more external feedback 809 -01 version: 811 o -01 version published 813 Appendix B. Open Issues 815 [RFC Editor: This section is to be removed before publication] 817 Could use some informational references in Section 3 819 Fix the odd list spacing in Section 5.1 821 Consider revision of the OS update links, to simplify them. 823 Add some point about notification to large networks may not be useful 824 -- such as coffee shops or hotels with WiFi networks. 826 Authors' Addresses 828 Jason Livingood 829 Comcast Cable Communications 830 One Comcast Center 831 1701 John F. Kennedy Boulevard 832 Philadelphia, PA 19103 833 US 835 Email: jason_livingood@cable.comcast.com 836 URI: http://www.comcast.com 837 Nirmal Mody 838 Comcast Cable Communications 839 One Comcast Center 840 1701 John F. Kennedy Boulevard 841 Philadelphia, PA 19103 842 US 844 Email: nirmal_mody@cable.comcast.com 845 URI: http://www.comcast.com 847 Mike O'Reirdan 848 Comcast Cable Communications 849 One Comcast Center 850 1701 John F. Kennedy Boulevard 851 Philadelphia, PA 19103 852 US 854 Email: michael_oreirdan@cable.comcast.com 855 URI: http://www.comcast.com