idnits 2.17.1 draft-oreirdan-mody-bot-remediation-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (February 12, 2010) is 5187 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: August 16, 2010 Comcast 6 February 12, 2010 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-07 11 Abstract 13 This document contains recommendations on how Internet Service 14 Providers can manage the effects of computers used by their 15 subscribers, which have been infected with malicious bots, via 16 various remediation techniques. Internet users with infected 17 computers are exposed to risks such as loss of personal data, as well 18 as increased susceptibility to online fraud and/or phishing. Such 19 computers can also become an inadvertent participant in or component 20 of an online crime network, spam network, and/or phishing network, as 21 well as be used as a part of a distributed denial of service attack. 22 Mitigating the effects of and remediating the installations of 23 malicious bots will make it more difficult for botnets to operate and 24 could reduce the level of online crime on the Internet in general 25 and/or on a particular Internet Service Provider's network. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on August 16, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 80 2. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Introduction and Problem Statement . . . . . . . . . . . . . . 6 82 4. Important Notice of Limitations and Scope . . . . . . . . . . 7 83 5. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 8 84 6. Notification to Internet Users . . . . . . . . . . . . . . . . 12 85 7. Remediation of Computers Infected with a Bot . . . . . . . . . 17 86 8. Guided Remediation Process . . . . . . . . . . . . . . . . . . 18 87 9. Professionally-Assisted Remediation Process . . . . . . . . . 20 88 10. Sharing of Data from the User to the ISP . . . . . . . . . . . 20 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 92 14. Informative references . . . . . . . . . . . . . . . . . . . . 22 93 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 24 94 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Key Terminology 105 This section defines the key terms used in this document. 107 2.1. Malicious Bots, or Bots 109 A malicious "bot" (derived from the word "robot", hereafter simply 110 referred to as a "bot") refers to a program that is surreptitiously 111 installed on a system in order to enable that system to automatically 112 (or semi-automatically) perform a task or set of tasks typically 113 under the command and control of a remote administrator, or "bot 114 master." Bots are also known as "zombies". 116 It is important to note that there are 'good', or benign bots. Such 117 benign bots are often found in such environments such as gaming and 118 Internet Relay Chat (IRC) [RFC1459], where a continual, interactive 119 presence can be a requirement for participating in the games, 120 interacting with a computing resource, or other purposes. Since such 121 benign bots are performing useful, lawful, and non-disruptive 122 functions, there is no reason for a provider to monitor for their 123 presence and/or alert users to their presence. 125 Thus, while there may be benign bots, for the purposes of this 126 document all mention of bots shall assume that the bots involved are 127 malicious in nature. Such malicious bots shall generally be assumed 128 to have been deployed without the permission or conscious 129 understanding of a particular Internet user. Thus, without a user's 130 knowledge, bots may transform the user's computing device into a 131 platform from which malicious activities can be conducted. In 132 general, installation of a malicious bot without user knowledge and 133 consent is considered in most regions to be unlawful, and the 134 activities of malicious bots typically involve unlawful or other 135 maliciously disruptive activities. 137 2.2. Bot Networks, or Botnets 139 These are defined as concerted networks of bots capable of acting on 140 instructions generated remotely. The malicious activities are either 141 focused on the information on the local machine or acting to provide 142 services for remote machines. Bots are highly customizable so they 143 can be programmed to do many things. The major malicious activities 144 include: identity theft, spam, distributed denial of service (DDoS) 145 attacks, key-logging, fraudulent DNS (pharming), proxy services, fast 146 flux hosting and click fraud. 148 Infection vectors include un-patched operating systems, software 149 vulnerabilities, weak/non-existent passwords, malicious websites, un- 150 patched browsers, malware, vulnerable helper applications and social 151 engineering techniques to gain access to the user's computer. The 152 detection and destruction of bots is an ongoing issue and also a 153 constant battle between the internet security community, network 154 security engineers and bot developers. 156 Initially, bots used IRC to communicate but were easy to shutdown if 157 the command and control server was identified and deactivated. Newer 158 command and control methods have evolved, such that those currently 159 employed by bot masters make them much more resistant to 160 deactivation. With the introduction of P2P, HTTP and other resilient 161 communication protocols along with the widespread adoption of 162 encryption, bots are considerably more difficult to identify and 163 isolate from typical network usage. As a result increased reliance 164 is being placed on anomaly detection and behavioral analysis, both 165 locally and remotely, to identify bots. 167 2.3. Computer 169 A computer, as used in the context of this document, is intended to 170 refer to a computing device that connects to the Internet. This 171 encompasses devices used by Internet users such as personal 172 computers, including laptops, desktops, and netbooks, as well as 173 mobile phones, smart phones, home gateway devices, and other end user 174 computing devices which are connected or can connect to the public 175 Internet and/or private IP networks. 177 Increasingly, other household systems and devices contain embedded 178 computers which are connected to or can connect to the public 179 Internet and/or private IP networks. However, these devices may not 180 be under interactive control of the Internet user, such as may be the 181 case with various smart home and smart grid devices. 183 2.4. Malware 185 This is short for malicious software. In this case, malicious bots 186 are considered a subset of malware. Other forms of malware could 187 include viruses and other similar types of software. Internet users 188 can sometimes cause their computer to be infected with malware, which 189 may include a bot or cause a bot to install itself, via inadvertently 190 accessing a specific website, downloading a specific file, or other 191 activities. 193 Alternatively, Internet-connected computers may become infected with 194 malware through externally initiated malicious activities such as the 195 exploitation of vulnerabilities or the brute force guessing of access 196 credentials. 198 2.5. Fast Flux 200 DNS Fast Fluxing occurs when a domain is bound in DNS using A records 201 to multiple IP addresses, each of which has a very short Time To Live 202 (TTL) value associated with it. This means that the domain resolves 203 to varying IP addresses over a short period of time. 205 DNS Fast Flux is typically used in conjunction with proxies which 206 then route the web requests to the real host which serves the data 207 being sought. The proxies are normally hosted on compromised user 208 computers. The effect of this is to make the detection of the real 209 host for a piece of content much more difficult and to ensure that 210 the site remains up for as long as possible. 212 3. Introduction and Problem Statement 214 Computers used by Internet users, which in this case are customers of 215 an Internet Service Provider (ISP), can be infected with malware 216 which may contain and/or install one or more bots on a computer. 217 This can present a major problem for an ISP for a number of reasons 218 (not to mention of course the problems created for users). First, 219 these bots can be used to send spam, in some cases very large volumes 220 of spam [Spamalytics: An Empirical Analysis of Spam Marketing 221 Conversion]. This spam can result in extra cost for the ISPs in 222 terms of wasted network, server, and/or personnel resources, among 223 many other potential costs and side effects. Such spam can also 224 negatively affect the reputation of the ISP, their customers, and the 225 email reputation of the IP address space used by the ISP (often 226 referred to simply as 'IP reputation'). 228 In addition, these bots can act as platforms for directing, 229 participating in, or otherwise conducting attacks on critical 230 Internet infrastructure [Emerging Cyber Threats Report for 2009: 231 Data, Mobility and Questions of Responsibility will Drive Cyber 232 Threats in 2009 and Beyond]. Bots are frequently used as part of 233 concerted Distributed Denial of Service (DDoS) attacks for criminal, 234 political or other motivations [The Gh0st in the Shell: Network 235 Security in the Himalayas] [The snooping dragon: social-malware 236 surveillance of the Tibetan movement]. For example, bots have been 237 used to attack Internet resources and infrastructure ranging from web 238 sites, to email servers and DNS servers, as well as the critical 239 Internet infrastructure of entire countries [Battling Botnets and 240 Online Mobs: Estonia's Defense Efforts during the Internet War] 241 [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad]. 242 Motivations for such coordinated DDoS attacks can range from criminal 243 extortion attempts through to online protesting and nationalistic 244 fervor [Case Study: How a Bookmaker and a Whiz Kid Took On a 245 DDOS-based Online Extortion Attack]. 247 While any computing device can be infected with bots, the majority of 248 bot infections affect the personal computers used by Internet end 249 users. As a result of the role of ISPs in providing IP connectivity, 250 among many other services, to Internet users, these ISPs are in a 251 unique position to be able to attempt to detect and observe bot nets 252 operating in their networks. Furthermore, ISPs may also be in a 253 unique position to be able to communicate to Internet users which are 254 their customers, when customers' computers may have been determined 255 to have been or possibly have been infected with one or more bots. 257 From an end user perspective, knowing that their computer has been 258 infected with one or more bots is very important information. Once 259 they know this, they can take steps to remove the bot, protect 260 themselves in the future, and resolve any problems which may stem 261 from the bot infection. Given that bots can drain local computing 262 and network resources, enable theft of personal information 263 (including personal financial information), enable the computer to be 264 used from criminal activities (that may result in the Internet user 265 being legally culpable), destroy or leave the PC in an unrecoverable 266 state via 'kill switch' bot technologies, it is important to notify 267 the user that they may be infected with a bot. 269 As a result, the intent of this document is to provide a guide to 270 ISPs and other organizations for the remediation of these computers 271 infected with bots, so as to reduce the size of bot nets and minimize 272 the potential harm that bots can inflict upon Internet infrastructure 273 generally, as well as on individual Internet users. Efforts by ISPs 274 and other organizations could therefore, over time, reduce the pool 275 of computers infected with bots on the Internet, which in turn could 276 result in smaller bot nets with less capability for disruption. 278 The potential mitigation of bots is accomplished through a process of 279 detection, notification to Internet users, and remediation of that 280 bot with a variety of tools, as described later in this document. 282 4. Important Notice of Limitations and Scope 284 The techniques described in this document in no way guarantee the 285 remediation of all bots. Bot removal is potentially a task requiring 286 specialized knowledge, skills and tools, and may be beyond the 287 ability of average users. Attempts at bot removal may frequently be 288 unsuccessful, or only partially successful, and may leave a user's 289 system in an unstable and unsatisfactory state or even in a state 290 where it is still infected. Attempts at bot removal can also result 291 in side effects ranging from a loss of data or other files, all the 292 way through partial or complete loss of system usability. 294 In general, the only way a user can be sure they have removed some of 295 today's increasingly sophisticated malware is by 'nuking-and-paving' 296 the system: reformatting the drive, reinstalling the operating system 297 and applications (including all patches) from scratch, and then 298 restoring user files from a clean backup. However the introduction 299 of BIOS-based malware may mean that, in some cases, this will not be 300 enough and may prove to be more than any end user can be reasonably 301 expected to resolve [Persistent BIOS Infection]. Experienced users 302 would have to re-flash BIOS in their machines in order to remove 303 BIOS-based malware. However, in some cases, not even 'nuking-and- 304 paving' the system will solve the problem, which calls for hard drive 305 and/or complete computer replacement. 307 Devices with embedded operating systems, such as video gaming 308 consoles and smart home appliances, will most likely be beyond a 309 user's capability to remediate by themselves, and will typically 310 require the aid of vendor-specific advice, updates and tools. Care 311 must be taken when imparting remediation advice to Internet users 312 given the increasingly wide array of computing devices that can be, 313 or could be, infected by bots in the future. 315 5. Detection of Bots 317 An ISP must first identify that an Internet user, in this case a user 318 that is assumed to be their customer or otherwise connected to the 319 ISP's network, is determined to be infected, or likely to have been 320 infected with a bot. The ISP must attempt to detect the presence of 321 bots using methods, processes, and tools which maintain the privacy 322 of the personally identifiable information (PII) of their customers. 323 The ISP also must not block legitimate traffic in the course of bot 324 detection, and must instead employ detection methods, tools, and 325 processes which seek to be non-disruptive, as well as being 326 transparent to Internet users and end-user applications. 328 Detection methods, tools, and processes may include things such as 329 analysis of specific network and/or application traffic flows (such 330 as traffic to an email server), analysis of aggregate network and/or 331 application traffic data, data feeds received from other ISPs and 332 organizations (such as lists of the ISP's IP addresses which have 333 been reported to have sent spam), feedback from the ISP's customers 334 or other Internet users, as well as a wide variety of other 335 possibilities. It is likely that a combination of multiple bot 336 detection data points will prove to be an effective approach in order 337 to corroborate information of varying dependability or consistency, 338 as well as to avoid or minimize the possibility of false positive 339 identification of computers. Detection should also, where possible 340 and feasible, attempt to classify a bot in order to confirm that it 341 is malicious in nature, estimate the variety and severity of threats 342 it may pose (such as spam bot, key-logging bot, file distribution 343 bot, etc.), and to determine potential methods for eventual 344 remediation. However, given the dynamic nature of botnet management 345 and the criminal incentives to seek quick financial rewards, botnets 346 frequently update or change their core malicious capabilities. As a 347 consequence, botnets that are initially detected and classified by 348 the ISP as one particular type of bot need to be continuously 349 monitored and tracked in order to correctly identify the threat they 350 pose at any particular point in time. 352 Detection is also time-sensitive. If complex analysis is required 353 and multiple confirmations are needed to confirm a bot is indeed 354 present, then it is possible that the bot may cause some damage (to 355 either the infected computer or a remotely targeted system) before it 356 can be stopped. This may mean that an ISP may need to balance the 357 desire or need to definitively classify and/or confirm a bot, which 358 may take an extended period of time, with the ability to predict the 359 strong likelihood of a bot in a very short period of time. This 360 'definitive-vs-likely' challenge is difficult and, when in doubt, 361 ISPs should probably err on the side of caution by communicating when 362 a likely bot infection has taken place. This also means that 363 Internet users may benefit from the deployment of client-based 364 software protections or other software tools, which can enable rapid 365 performance of heuristically-based detection bot activity, such as 366 the detection of a bot as it starts to communicate a bot net and 367 execute some type of command. Any bot detection systems should also 368 be capable of learning and adapting, either via manual intervention 369 or automatically, in order to cope with a rapidly evolving threat. 371 As noted above, detection methods, tools, and processes should ensure 372 that privacy of customers' PII is maintained. While bot detection 373 methods, tools, and processes are similar to spam and virus defenses 374 deployed by the ISP for the benefit of their customers (and may be 375 directly related to those defenses), attempts to detect bots should 376 take into account the need of an ISP to take care to ensure any PII 377 collected or incidentally detected is properly protected. The 378 definition of PII varies from one jurisdiction to the next so proper 379 care must be taken to ensure that any actions taken comply with 380 legislation and good practice in the jurisdiction in which the PII is 381 gathered. Finally, depending upon the geographic region within which 382 an ISP operates, certain methods relating to bot detection may need 383 to be included in relevant terms of service documents or other 384 documents which are available to the customers of a particular ISP. 386 There are several bot detection methods, tools, and processes that an 387 ISP may choose to utilize, as noted in the list below. It is 388 important to note that the technical solutions available are 389 relatively immature, and are likely to change over time, evolving 390 rapidly in the coming years. While these items are described in 391 relation to ISPs, they may also be applicable to organizations 392 operating other networks, such as campus networks and enterprise 393 networks. 395 a. Where legally permissible or otherwise an industry accepted 396 practice in a particular market region, an ISP may in some manner 397 "scan" their IP space in order to detect un-patched or otherwise 398 vulnerable hosts. This may provide the ISP with the opportunity 399 to easily identify Internet users who appear to already be or are 400 at great risk of being infected with a bot. ISP's should note 401 that some types of port scanning may leave network services in a 402 hung state or render them unusable due to common frailties, and 403 that many modern firewall and host-based intrusion detection 404 implementations may alert the Internet user to the scan. As a 405 result the scan may be interpreted as a malicious attack against 406 the computer. Vulnerability scanning has a higher probability of 407 leaving accessible network services and applications in a damaged 408 state and will often result in a higher probability of detection 409 by the Internet user and subsequent interpretation as a targeted 410 attack. Depending upon the vulnerability being scanned, some 411 automated methods of vulnerability checking may result in data 412 being altered or created afresh on the Internet users computer 413 which be a problem in many legal environments. 415 b. An ISP may also communicate and share selected data, via feedback 416 loops or other mechanisms, with various third parties. Feedback 417 loops are consistently formatted feeds of real-time (or nearly 418 real-time) abuse reports offered by threat data clearinghouses, 419 security alert organizations, other ISPs, and other 420 organizations. The data may include, but is not limited to, 421 lists of the IP addresses computers which have or are likely to 422 have a bot running, domain names or fully qualified domain names 423 (FQDNs) known to host malware and/or be involved in the command 424 and control of botnets, IP addresses know to host malware and/or 425 be involved in the command and control of botnets, recently 426 tested or discovered techniques or detecting or remediating bot 427 infections, new threat vectors, and other relevant information. 428 Good examples of this include SNDS from Microsoft, XBL and PBL 429 from Spamhaus and the DSHIELD AS tool from the SANS Institute. 431 c. An ISP may use Netflow [RFC3954] or other similar passive network 432 monitoring to identify network anomalies that may be indicative 433 of botnet attacks or bot communications. For example, an ISP may 434 be able to identify compromised hosts by identifying traffic 435 destined to IP addresses associated with the command and control 436 of botnets. In addition, bots can be identified when a remote 437 host is under a DDoS attack because computers participating in 438 the attack will likely be infected by a bot, frequently as 439 observed at network borders. 441 d. An ISP may use DNS-based techniques to perform detection. For 442 example, a given classified bot may be known to query a specific 443 list of domain names at specific times or on specific dates (in 444 the example of the so-called "Conficker" bot), often by matching 445 DNS queries to a well known list of domains associated with 446 malware. In many cases such lists are distributed by or shared 447 using third parties, such as threat data clearinghouses. 449 e. User complaints: Because hosts infected by bots are frequently 450 used to send spam or participate in DDoS attacks, the ISP 451 servicing those hosts will normally receive complaints about the 452 malicious network traffic. Those complaints may be sent to 453 RFC2142-specified [RFC2142] role accounts, such as abuse@ or 454 postmaster@ or to abuse or security addresses specified by the 455 site as part of its WHOIS (or other) contact data. 457 f. ISPs may also discover likely bot infected hosts located at other 458 sites; when legally permissible or otherwise an industry accepted 459 practice in a particular market region, it may be worthwhile for 460 ISPs to share evidence relating to those compromised hosts with 461 the relevant remote ISP, with security researchers, and with 462 blocklist operators. 464 g. ISPs may operate or subscribe to services that provide 465 'sinkholing' or 'honeynet' capabilities. This may enable the ISP 466 to obtain near-real-time lists of bot infected computers as they 467 attempt to join a larger botnet or propagate to other hosts on a 468 network. 470 h. ISP industry associations should examine the possibility of 471 collating statistics from ISP members in order to provide good 472 statistics about bot infections based on real ISP data. 474 i. An Intrusion Detection System(IDS) can be a useful tool to 475 actually identify to help identify the malware. An IDS tool such 476 as SNORT (open source IDS platform) can be placed in a Walled 477 Garden and used to analyze end user traffic to confirm malware 478 type. This will help with remediation of the infected device. 480 6. Notification to Internet Users 482 Once an ISP has detected a bot, or the strong likelihood of a bot, 483 steps should be undertaken to inform the Internet user that they may 484 have a bot-related problem. Depending upon a range of factors, from 485 the technical capabilities of the ISP, to the technical attributes of 486 their network, financial considerations, available server resources, 487 available organizational resources, the number of likely infected 488 computers detected at any given time, and the severity of any 489 possible threats, among many other things, an ISP should decide the 490 most appropriate method or methods for providing notification to one 491 or more of their customers or Internet users. Such notification 492 methods may include one or more of the following, as well as other 493 possible methods not described below 495 It is important to note that none of these methods are guaranteed to 496 be successful, and that each has its own set of limitations. In 497 addition, in some cases, an ISP may determine that a combination of 498 two or more methods is most appropriate. Finally, notification is 499 also considered time sensitive; if the user does not receive or view 500 the notification or a timely basis, then a particular bot could 501 launch an attack, exploit the user, or cause other harm. If 502 possible, an ISP should establish a preferred means of communication 503 when the subscriber first signs up for service. As a part of the 504 notification process, ISPs should maintain a record of the allocation 505 of IP addresses to subscribers for such a period as allows any bot 506 detection technology to be accurately able to link an infected IP 507 address to a subscriber. This record should only be maintained for a 508 period of time which is necessary, in order to maintain the 509 protection of the privacy of an individual subscriber. 511 One important factor to bear in mind is that notification to end 512 users needs to be defended against spoofing by third parties. This 513 must be done to protect against the possibility of notifications 514 being spoofed and used by bots to deliver additional malware. 516 6.1. Email Notification 518 This is probably the most common form of notification used by ISPs. 519 One drawback of using email is that it is not guaranteed to be viewed 520 within a reasonable time frame, if at all. The user may be using a 521 different primary email address than that which they have provided to 522 the ISP. In addition, some ISPs do not provide an email account at 523 all, as part of a bundle of Internet services, and/or do not have a 524 need for or method in which to request or retain the primary email 525 addresses of Internet users of their networks. Another possibility 526 is that the user, their email client, and/or their email servers 527 could determine or classify such a notification as spam, which could 528 delete the message or otherwise file it in an email folder that the 529 user may not check on a regular and/or timely basis. Bot masters 530 have also been known to impersonate the ISP or trusted sender and 531 send fradulent emails to the users. This technique of social 532 engineering, generally referred to as 'phishing', often leads to new 533 bot infestations. Finally if the user's email credentials are 534 compromised, then a hacker and/or a bot could simply login to the 535 user's email account and delete the email before it is read by the 536 user. 538 6.2. Telephone Call Notification 540 A telephone call may be an effective means of communication in 541 particularly high-risk situations. However, telephone calls may not 542 be feasible due to the cost of making a large number of calls, as 543 measured in either time, money, organizational resources, server 544 resources, or some other means. In addition, there is no guarantee 545 that the user will answer their phone. To the extent that the 546 telephone number called by the ISP can be answered by the infected 547 computing device, the bot on that computer may be able to disconnect, 548 divert, or otherwise interfere with an incoming call. Users may also 549 interpret such a telephone notification as a telemarketing call and 550 as such not welcome it, or not accept the call at all. Finally, even 551 if a representative of the ISP is able to connect with and speak to a 552 user, that user is very likely to lack the necessary technical 553 expertise to understand or be able to effectively deal with the 554 threat. 556 6.3. Postal Mail Notification 558 This form of notification is probably the least popular and effective 559 means of communication, due to both preparation time, delivery time, 560 the cost of printing and paper, and the cost of postage. 562 6.4. Walled Garden Notification 564 Placing a user in a walled garden is another approach that ISPs may 565 take to notify users. A walled garden refers to an environment that 566 controls the information and services that a subscriber is allowed to 567 utilize and what network access permissions are granted. This is an 568 effective technique because it could be able to block all 569 communication between the bot and the command and control channel, 570 which may impair the ability of a bot to disrupt or block attempts to 571 notify the user. 573 While in many cases the user is almost guaranteed to view the 574 notification message and take any appropriate remediation actions, 575 this approach poses can pose other challenges. For example, it is 576 not always the case that a user is actively using a computer that 577 uses a web browser or which has a web browser actively running on it. 578 In one example, a user could be playing a game online, via the use of 579 a dedicated, Internet-connected game console. In another example, 580 the user may not be using a computer with a web browser when they are 581 placed in the walled garden and may instead be in the course of a 582 telephone conversation, or may be expecting to receive a call, using 583 a Voice Over IP (VoIP) device of some type. As a result, the ISP may 584 feel the need to maintain a potentially lengthy white list of domains 585 which are not subject to the typical restrictions of a walled garden, 586 which could well prove to be an onerous task, from an operational 587 perspective. 589 The ISP has several options to determine when to let the user out of 590 the walled garden. One approach may be to let the user determine 591 when to exit. This option is suggested when the purpose of the 592 walled garden is to notify users and provide information on 593 remediation only, particularly since notification is not a guarantee 594 of successful remediation. It could also be the case that, for 595 whatever reason, the user makes the judgment that they cannot then 596 take the time to remediate their computer and that other online 597 activities which they would like to resume are more important. Exit 598 from the walled garden may also involve a process to verify that it 599 is indeed the user who is requesting exit from the walled garden and 600 not the bot. 602 Once the user acknowledges the notification, then the user decides to 603 either remediate and then exit the walled garden, or exit the walled 604 garden without addressing the issue. Another approach may be to 605 enforce a stricter policy and require the user to clean the computer 606 prior to permitting the user to exit the walled garden, though this 607 may not be technically feasible depending upon the type of bot, 608 obfuscation techniques employed by a bot, and/or a range of other 609 factors. Thus, the ISP may also need to support tools to scan the 610 infected computer and determine whether it is still infected or rely 611 on user judgment that the bot has been disabled or removed. One 612 challenge with this approach is that if the user has multiple 613 computers sharing a single IP address, such as via a common home 614 gateway device which performs Network Address Translation (NAT). In 615 such a case, the ISP may need to determine from user feedback, or 616 other means, that all affected computers have been remediated, which 617 may or may not be technically feasible. 619 Finally, when a walled garden is used, a list of well-known addresses 620 for both operating system vendors and security vendors should be 621 created and maintained in a white list which permits access to these 622 sites. This can be important for allowing access from the walled 623 garden by end users in search of operating system and application 624 patches. 626 6.5. Instant Message Notification 628 Instant messaging provides the ISP with a simple means to communicate 629 with the user. There are several advantages to using IM which makes 630 it an attractive option. If the ISP provides IM service and the user 631 subscribes to it, then the user can be notified easily. IM-based 632 notification can be a cost effective means to communicate with users 633 automatically from an IM alert system or via a manual process, by the 634 ISP's support staff. Ideally, the ISP should allow the user to 635 register their IM identity in an ISP account management system and 636 grant permission to be contacted via this means. If the IM service 637 provider supports off-line messaging, then the user can be notified 638 regardless of whether they are currently logged into the IM system. 640 There are several drawbacks with this communications method. There 641 is a high probability that subscriber may interpret the communication 642 to be spam, and as such ignore it. Also, not every user uses IM 643 and/or the user may not provide their IM identity to the ISP so some 644 alternative means have to be used. Even in those cases where a user 645 does have an IM address, they may not be signed onto that IM system 646 when the notification is attempted. There maybe also be a privacy 647 concern on the part of users, when such an IM notification must be 648 transmitted over a third-party network and/or IM service. As such, 649 should this method be used, the notification should be discreet and 650 not include any PII in the notification itself. 652 6.6. Short Message Service (SMS) Notification 654 SMS allows the ISP send a brief description of the problem to notify 655 the user of the issue, typically to a mobile device such as a mobile 656 phone or smart phone. Ideally, the ISP should allow the user to 657 register their mobile number and/or SMS address in an ISP account 658 management system and grant permission to be contacted via this 659 means. The primary advantage of SMS is that users are familiar with 660 receiving text messages and are likely to read them. However, users 661 may not act on the notification immediately if they are not in front 662 of their computer system at the time of the SMS notification. 664 One disadvantage is that ISPs may have to follow up with an alternate 665 means of notification if not all of the necessary information maybe 666 conveyed in one message, given constraints on the number of 667 characters in an individual message (typically 140 characters). 668 Another disadvantage with SMS is the cost associated with it. The 669 ISP has to either build its own SMS gateway to interface with the 670 various wireless network service providers or use a third-party SMS 671 clearinghouse (relay) to notify users. In both cases, an ISP will 672 typically pay on a per-message basis to send SMS notifications. An 673 additional downside is that SMS messages sent to a user may result in 674 a charge to the user by their wireless provider, depending upon the 675 plat to which they subscribe. Another minor disadvantage is that it 676 is possible to notify the wrong user if the intended user changes 677 their mobile number but forgets to update it with the ISP. 679 There are several other drawbacks with this communications method. 680 There is a high probability that subscriber may interpret the 681 communication to be spam, and as such ignore it. Also, not every 682 user uses SMS and/or the user may not provide their SMS address or 683 mobile number to the ISP. Even in those cases where a user does have 684 an SMS address or mobile number, their device may not be powered on 685 or otherwise available on a wireless network when the notification is 686 attempted. There maybe also be a privacy concern on the part of 687 users, when such an SMS notification must be transmitted over a 688 third-party network and/or SMS clearinghouse. As such, should this 689 method be used, the notification should be discreet and not include 690 any PII in the notification itself. 692 6.7. Web Browser Notification 694 Near real-time notification to the user's web browser is another 695 technique that may be utilized for notifying the user, though how 696 such a system might operate is outside the scope of this document. 697 Such a notification could have a comparative advantage over a walled 698 garden notification, in that it does not restrict traffic to a 699 specified list of destinations in the same way that a walled garden 700 by definition would. However, as with a walled garden notification, 701 there is no guarantee that a user is at any given time making use of 702 a web browser, though such a system could certainly provide a 703 notification when such a browser is eventually used. Compared to a 704 walled garden, a web browser notification is probably preferred from 705 the perspective of Internet users, as it does not have the risk of 706 disrupting non-web sessions, such as online games, VoIP calls, etc. 707 (as noted in Section 6.4). 709 6.8. Considerations for Notification to Public Network Locations 711 Delivering a notification to a location that provides a shared public 712 network, such as a train station, public square, coffee shop, or 713 similar location may be of low value since the users connecting to 714 such networks are typically highly transient and generally not know 715 to site or network administrators. For example, a system may detect 716 that a computer on such a network has a bot, but by the time a 717 notification is generated that user has departed from the network and 718 moved elsewhere. 720 6.9. Considerations for Notification to Network Locations Using a 721 Shared IP Address 723 Delivering a notification to a location that Internet access routed 724 through one or more shared public IP addresses may be of low value 725 since it may be quite difficult to differentiate between users when 726 providing a notification. For example, on a business network of 500 727 users, all sharing one public IP address, it may be sub-optimal to 728 provide a notification to all 500 users if you only need one specific 729 user to be notified and take action. As a result, such networks may 730 find value in establishing a localized bot detection and notification 731 system, just as they are likely to also establish other localized 732 systems for security, file sharing, email, and so on. 734 7. Remediation of Computers Infected with a Bot 736 This section covers the different options available to remediate a 737 computer, which means to remove, disable, or otherwise render a bot 738 harmless. Prior to this step, an ISP has detected the bot, notified 739 the user that one of their computers is infected with a bot, and now 740 may provide some recommended means to clean the computer. The 741 generally recommended approach is to provide the necessary tools and 742 education to the user so that they may perform bot remediation 743 themselves, particularly given the risks and difficulties inherent in 744 attempting to remove a bot. 746 For example, this may include the creation of a special web site with 747 security-oriented content that is dedicated for this purpose. This 748 should be a well-publicized security web site to which a user with a 749 bot infection can be directed to for remediation. This security web 750 site should clearly explain why the user was notified and may include 751 an explanation of what bots are, and the threats that they pose. 752 There should be a clear explanation of the steps that the user should 753 take in order to attempt to clean their computer and provide 754 information on how users can keep the computer free of future 755 infections. The security web site should also have a guided process 756 that takes non-technical users through the remediation process, on an 757 easily understood, step-by-step basis. 759 In terms of the text used to explain what bots are and the threats 760 that they pose, something simple such as this may suffice: 762 "What is a bot? A bot is a piece of software, generally 763 installed on your machine without your knowledge, which either 764 sends spam or tries to steal your personal information. They 765 can be very difficult to spot, though you may have noticed that 766 your computer is running much more slowly than usual or you 767 notice regular disk activity even when you are not doing 768 anything. Ignoring this problem is not really an option since 769 your personal information is currently at risk. Thus, bots 770 need to be removed to protect your data and your personal 771 information." 773 It is also important to note that it may not be immediately apparent 774 to the Internet user precisely which devices have been infected with 775 a particular bot. This may be due to the user's home network 776 configuration, which may encompass several computers, where a home 777 gateway which performs Network Address Translation (NAT) to share a 778 single public IP address has been used. Therefore, any of these 779 devices can be infected with a bot. The consequence of this for an 780 ISP is that remediation advice may not ultimately be immediately 781 actionable by the Internet user, as that user may need to perform 782 additional investigation within their own home network. 784 An added complication is that the user may have a bot infection on a 785 device such as a video console, multimedia system, appliance, or 786 other end-user computing device which does not have a typical Windows 787 or Macintosh user interface. As a result, diligence needs to be 788 taken by the ISP where possible such that they can identify and 789 communicate the specific nature of the device that has been infected 790 with a bot, and further providing appropriate remediation advice. 792 There are a number of forums that exist online to provide security 793 related support to end users. These forums are staffed by volunteers 794 and often are focussed around the use of a common tool set to help 795 end users to remediate computers infected with malware. It may be 796 advantageous to ISPs to foster a relationship with one or more 797 forums, perhaps by offering free hosting or other forms of 798 sponsorship. 800 8. Guided Remediation Process 802 Minimally the Guided Remediation Process should include options 803 and/or recommendations on how a user should: 805 1. Backup personal Documents, for example: "Before you start, make 806 sure to back up all of your important data. (You should do this 807 on a regular basis anyway.) You can back up your files manually 808 or using a system back-up software utility, which may be part of 809 your Operating System (OS). You can back your files up to a USB 810 Thumb Drive (aka USB Key), a writeable CD/DVD-ROM, an external 811 hard drive, or a network file server." 813 2. Download OS patches and Anti-Virus (A/V) software updates. For 814 example, links could be provided to Microsoft Windows updates at 815 http://update.microsoft.com/microsoftupdate/v6/ 816 default.aspx?ln=en-us as well as to Apple MacOS updates at 817 http://support.apple.com/kb/HT1338?viewlocale=en_US. 819 3. Explain how to configure the computer to automatically install 820 updates for the OS, A/V and other common Web Browsers such as 821 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 822 Opera, and Google Chrome. 824 4. The flow should also have the option for users to get 825 professional assistance if they are unable to remove the bots 826 themselves. If purchasing third party assistance, then the user 827 should be encouraged to pre-determine how much they are willing 828 to pay for that help. If the computer that is being remediated 829 is old and can easily be replaced with a new, faster, larger and 830 more reliable system for three or four hundred dollars, the it 831 makes no sense to spend five or six hundred dollars to fix the 832 old computer, for example. On the other hand, if the customer 833 has a brand new computer that cost several thousand dollars, it 834 might make perfect sense to spend the money in attempting to 835 remediate it. 837 5. To continue, regardless of whether the user or a knowledgeable 838 technical assistant is working on remediating the computer, their 839 first task should be to determine which of multiple potentially- 840 infected machines may be the one that needs attention (in the 841 common case of multiple computers in a home network). Sometimes, 842 as in cases where there is only a single directly-attached 843 computer, or the user has been noticing problems with one of 844 their computers, this can be easy. Other times, it may be more 845 difficult. If the user is behind a home gateway/router, then the 846 first task may be to ascertain which of the machines is infected. 847 In some cases the user may have to check all machines to identify 848 the infected one. 850 6. User surveys to solicit feedback on whether the notification and 851 remediation process is effective and what recommended changes 852 could be made in order to improve the ease, understandability, 853 and effectiveness the remediation process. 855 7. If the user is interested in reporting his or her computer's bot 856 infection to an applicable law enforcement authority, then the 857 computer effectively becomes a cyber "crime scene" and should not 858 be mitigated unless or until law enforcement has collected the 859 necessary evidence. For individuals in this situation, the ISP 860 should refer them to local, state, federal, or other relevant 861 computer crime offices. (Note: Some "minor" incidents, even if 862 highly traumatic to the user, may not be sufficiently serious for 863 law enforcement to commit some of their limited resources to an 864 investigation.) In addition, individual regions may have other, 865 specialized computer crime organizations to which these incidents 866 can be reported. For example, in the United States, that 867 organization is the Internet Crime Complaint Center, at 868 http://www.ic3.gov. 870 8. Users may also be interested in links to security expert forums, 871 where other users can assist them. 873 9. Professionally-Assisted Remediation Process 875 It should be acknowledged that, based on the current state of 876 remediation tools and the technical abilities of end users, that many 877 users may be unable to remediate on their own. As a result, it is 878 recommended that users have the option to avail themselves of 879 professional assistance. This may entail online or telephone 880 assistance for remediation, as well as working face to face with a 881 professional who has training and expertise in the removal of 882 malware. 884 10. Sharing of Data from the User to the ISP 886 As an additional consideration, it may be useful to create a process 887 by which users could choose, at their option and with their express 888 consent, to share data regarding their bot infection with their ISP 889 and/or another authorized third party. Such third parties may 890 include governmental entities that aggregate threat data, such as the 891 Internet Crime Complaint Center referred to earlier in this document, 892 to academic institutions, and/or security researchers. While in many 893 cases the information shared with the user's ISP or designated third 894 parties will only be used for aggregated statistical analysis, it is 895 also possible that certain research needs may be best met with more 896 detailed data. Thus, any such data sharing from a user to the ISP or 897 authorized third party may contain some type of personally 898 identifiable information, either by design or inadvertently. As a 899 result, any such data sharing must be enabled on an opt-in based, 900 where users review and approve of the data being shared and the 901 parties with which it is to be shared. 903 11. Security Considerations 905 This document describes in detail the numerous security risks and 906 concerns relating to bot nets. As such, it has been appropriate to 907 include specific information about security in each section above. 908 This document describes the security risks related to malicious bot 909 infections themselves, such as enabling identity theft, theft of 910 authentication credentials, and the use of a computer to unwittingly 911 participate in a DDoS attack, among many other risks. This document 912 also describes at a high level the activities that ISPs should be 913 sensitive to, where the collection or communication of PII may be 914 possible. Finally, the document also describes security risks which 915 may relate to the particular methods of communicating a notification 916 to Internet users. Bot networks and bot infections pose extremely 917 serious security risks and any reader should review this document 918 carefully. 920 In addition, regarding notifications, as described in the Section 6, 921 care should be taken to assure users that notifications have been 922 provided by a trustworthy site and/or party, so that the notification 923 is more difficult for phishers to mimic, or that the user has some 924 level of trust that the notification is valid, and/or that the user 925 has some way to verify via some other mechanism or step that the 926 notification is valid. 928 Lastly, as noted in Section 10, any sharing of data from the User to 929 the ISP and/or authorized third parties must be done on an opt-in 930 basis and with a clear by the user of the data to be shared and with 931 whom it is to be shared. 933 12. IANA Considerations 935 There are no IANA considerations in this document. 937 13. Acknowledgements 939 The authors wish to acknowledge the following individuals for 940 performing a detailed review of this document and/or providing 941 comments and feedback with had helped to improve and evolve this 942 document: 944 Mark Baugher 946 Richard Bennett 948 James Butler 950 Vint Cerf 951 Alissa Cooper 953 Jonathan Curtis 955 Jeff Chan 957 Roland Dobbins 959 Dave Farber 961 Eliot Gillum 963 Joel Halpern 965 Scott Keoseyan 967 The Messaging Anti-Abuse Working Group (MAAWG) 969 Jose Nazario 971 Gunter Ollmann 973 David Reed 975 Joe Stewart 977 Forrest Swick 979 Robb Topolski 981 Eric Ziegast 983 14. Informative references 985 [Battling Botnets and Online Mobs: Estonia's Defense Efforts during 986 the Internet War] 987 Evron, G., "Battling Botnets and Online Mobs: Estonia's 988 Defense Efforts during the Internet War", May 2005, . 994 [Case Study: How a Bookmaker and a Whiz Kid Took On a DDOS-based 995 Online Extortion Attack] 996 Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid 997 Took On a DDOS-based Online Extortion Attack", May 2005, < 998 http://www.csoonline.com/article/220336/ 999 How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online 1000 _Extortion_Attack>. 1002 [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad] 1003 Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon 1004 of Electronic Jihad", February 2007, . 1007 [Emerging Cyber Threats Report for 2009: Data, Mobility and Questions 1008 of Responsibility will Drive Cyber Threats in 2009 and Beyond] 1009 Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., 1010 Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., 1011 Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber 1012 Threats Report for 2009: Data, Mobility and Questions of 1013 Responsibility will Drive Cyber Threats in 2009 and 1014 Beyond", October 2008, . 1017 [Persistent BIOS Infection] 1018 Sacco, A. and A. Ortega, "Persistent BIOS Infection", 1019 March 2009, . 1022 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1023 RFC 1459, May 1993. 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1029 FUNCTIONS", RFC 2142, May 1997. 1031 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1032 9", RFC 3954, October 2004. 1034 [Spamalytics: An Empirical Analysis of Spam Marketing Conversion] 1035 Kanich, C., Kreibich, C., Levchenko, K., Enright, B., 1036 Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An 1037 Empirical Analysis of Spam Marketing Conversion", 1038 October 2008, . 1041 [The Gh0st in the Shell: Network Security in the Himalayas] 1042 Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st 1043 in the Shell: Network Security in the Himalayas", 1044 February 2010, . 1047 [The snooping dragon: social-malware surveillance of the Tibetan 1048 movement] 1049 Nagaraja, S. and R. Anderson, "The snooping dragon: 1050 social-malware surveillance of the Tibetan movement", 1051 March 2009, 1052 . 1054 Appendix A. Document Change Log 1056 [RFC Editor: This section is to be removed before publication] 1058 -07 version: 1060 o Corrected various spelling and grammatical errors, pointed out by 1061 additional reviewers. Also added a section on information flowing 1062 from the user. Lastly, updated the reviewer list to include all 1063 those who either were kind enough to review for us or who provided 1064 interesting, insightful, and/or helpful feedback. 1066 -06 version: 1068 o Corrected an error in the version change log, and added some extra 1069 information on user remediation. Also added an informational 1070 reference to BIOS infection. 1072 -05 version: 1074 o Minor tweaks made by Jason - ready for wider review and next 1075 steps. Also cleared open issues. Lastly, added 2nd paragraph to 1076 security section and added sections on limitations relating to 1077 public and other shared network sites. Added a new section on 1078 professional remediation. 1080 -04 version: 1082 o Updated reference to BIOS based malware, added wording on PII and 1083 local jurisdictions, added suggestion that industry body produce 1084 bot stats, added suggestion that ISPs use volunteer forums 1086 -03 version: 1088 o all updates from Jason - now ready for wider external review 1090 -02 version: 1092 o all updates from Jason - still some open issues but we're now at a 1093 place where we can solicit more external feedback 1095 -01 version: 1097 o -01 version published 1099 Appendix B. Open Issues 1101 [RFC Editor: This section is to be removed before publication] 1103 A question has been raised about whether this should change from 1104 Informational to BCP. 1106 Authors' Addresses 1108 Jason Livingood 1109 Comcast Cable Communications 1110 One Comcast Center 1111 1701 John F. Kennedy Boulevard 1112 Philadelphia, PA 19103 1113 US 1115 Email: jason_livingood@cable.comcast.com 1116 URI: http://www.comcast.com 1118 Nirmal Mody 1119 Comcast Cable Communications 1120 One Comcast Center 1121 1701 John F. Kennedy Boulevard 1122 Philadelphia, PA 19103 1123 US 1125 Email: nirmal_mody@cable.comcast.com 1126 URI: http://www.comcast.com 1128 Mike O'Reirdan 1129 Comcast Cable Communications 1130 One Comcast Center 1131 1701 John F. Kennedy Boulevard 1132 Philadelphia, PA 19103 1133 US 1135 Email: michael_oreirdan@cable.comcast.com 1136 URI: http://www.comcast.com