idnits 2.17.1 draft-oreirdan-mody-bot-remediation-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (January 9, 2012) is 4492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5070 (Obsoleted by RFC 7970) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: July 12, 2012 Comcast 6 January 9, 2012 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-20 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. Such computers can also 19 become an inadvertent participant in or component of an online crime 20 network, spam network, and/or phishing network, as well as be used as 21 a part of a distributed denial of service attack. Mitigating the 22 effects of and remediating the installations of malicious bots will 23 make it more difficult for botnets to operate and could reduce the 24 level of online crime on the Internet in general and/or on a 25 particular Internet Service Provider's network. 27 Status of this Memo 29 This Internet-Draft is submitted 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 12, 2012. 44 Copyright Notice 46 Copyright (c) 2012 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 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction and Problem Statement . . . . . . . . . . . . . . 5 63 3. Important Notice of Limitations and Scope . . . . . . . . . . 7 64 4. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Notification to Internet Users . . . . . . . . . . . . . . . . 12 66 6. Remediation of Hosts Infected with a Bot . . . . . . . . . . . 18 67 6.1. Guided Remediation Process . . . . . . . . . . . . . . . . 20 68 6.2. Professionally-Assisted Remediation Process . . . . . . . 22 69 7. Failure or Refusal to Remediate . . . . . . . . . . . . . . . 22 70 8. Sharing of Data from the User to the ISP . . . . . . . . . . . 22 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 72 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 23 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 75 13. Informative references . . . . . . . . . . . . . . . . . . . . 25 76 Appendix A. Examples of Third Party Malware Lists . . . . . . . . 27 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 27 78 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 81 1. Key Terminology 83 This section defines the key terms used in this document. 85 1.1. Malicious Bots, or Bots 87 A malicious or potentially malicious "bot" (derived from the word 88 "robot", hereafter simply referred to as a "bot") refers to a program 89 that is installed on a system in order to enable that system to 90 automatically (or semi-automatically) perform a task or set of tasks 91 typically under the command and control of a remote administrator, or 92 "bot master". Bots are also known as "zombies". Such bots may have 93 been installed surreptitiously, without the user's full understanding 94 of what the bot will do once installed, unknowingly as part of 95 another software installation, under false pretenses, and/or in a 96 variety of other possible ways. 98 It is important to note that there are 'good' bots. Such 'good' bots 99 are often found in such environments such as gaming and Internet 100 Relay Chat (IRC) [RFC1459], where a continual, interactive presence 101 can be a requirement for participating in the games, interacting with 102 a computing resource. Since such 'good' bots are performing useful, 103 lawful, and non-disruptive functions, there is no reason for a 104 provider to monitor for their presence and/or alert users to their 105 presence. 107 Thus, while there may be good, or harmless bots, for the purposes of 108 this document all mention of bots shall assume that the bots involved 109 are malicious or potentially malicious in nature. Such malicious 110 bots shall generally be assumed to have been deployed without the 111 permission or conscious understanding of a particular Internet user. 112 Thus, without a user's knowledge, bots may transform the user's 113 computing device into a platform from which malicious activities can 114 be conducted. In addition, included explicitly in this category are 115 potentially malicious bots, which may initially appear neutral but 116 may simply be waiting for remote instructions to transform and/or 117 otherwise begin engaging in malicious behavior. In general, 118 installation of a malicious bot without user knowledge and consent is 119 considered in most regions to be unlawful, and the activities of 120 malicious bots typically involve unlawful or other maliciously 121 disruptive activities. 123 1.2. Bot Networks, or Botnets 125 These are defined as concerted networks of bots capable of acting on 126 instructions generated remotely. The malicious activities are either 127 focused on the information on the local machine or acting to provide 128 services for remote machines. Bots are highly customizable so they 129 can be programmed to do many things. The major malicious activities 130 include but are not limited to: identity theft, spam, spim (spam over 131 instant messaging), spit (spam over Internet telephony), email 132 address harvesting, distributed denial of service (DDoS) attacks, 133 key-logging, fraudulent DNS pharming (redirection), hosting proxy 134 services, fast flux (see Section 1.5) hosting, hosting of illegal 135 content, use in man-in-the-middle attacks, and click fraud. 137 Infection vectors (infection pathways) include un-patched operating 138 systems, software vulnerabilities (which include so-called zero-day 139 vulnerabilities where no patch yet exists), weak/non-existent 140 passwords, malicious websites, un-patched browsers, malware, 141 vulnerable helper applications, inherently insecure protocols, 142 protocols implemented without security features switched on and 143 social engineering techniques to gain access to the user's computer. 144 The detection and destruction of bots is an ongoing issue and also a 145 constant battle between the Internet security community and network 146 security engineers on the one hand and bot developers on the other. 148 Initially, some bots used IRC to communicate but were easy to 149 shutdown if the command and control server was identified and 150 deactivated. Newer command and control methods have evolved, such 151 that those currently employed by bot masters make them much more 152 resistant to deactivation. With the introduction of P2P 153 architectures and associated protocols as well as the use of HTTP and 154 other resilient communication protocols along with the widespread 155 adoption of encryption, bots are considerably more difficult to 156 identify and isolate from typical network usage. As a result 157 increased reliance is being placed on anomaly detection and 158 behavioral analysis, both locally and remotely, to identify bots. 160 1.3. Host 162 An end user's host, or computer, as used in the context of this 163 document, is intended to refer to a computing device that connects to 164 the Internet. This encompasses devices used by Internet users such 165 as personal computers, including laptops, desktops, and netbooks, as 166 well as mobile phones, smart phones, home gateway devices, and other 167 end user computing devices that are connected or can connect to the 168 public Internet and/or private IP networks. 170 Increasingly, other household systems and devices contain embedded 171 hosts which are connected to or can connect to the public Internet 172 and/or private IP networks. However, these devices may not be under 173 interactive control of the Internet user, such as may be the case 174 with various smart home and smart grid devices. 176 1.4. Malware 178 This is short for malicious software. In this case, malicious bots 179 are considered a subset of malware. Other forms of malware could 180 include viruses and other similar types of software. Internet users 181 can sometimes cause their hosts to be infected with malware, which 182 may include a bot or cause a bot to install itself, via inadvertently 183 accessing a specific website, downloading a file, or other 184 activities. 186 In other cases, Internet-connected hosts may become infected with 187 malware through externally initiated malicious activities such as the 188 exploitation of vulnerabilities or the brute force guessing of access 189 credentials. 191 1.5. Fast Flux 193 Domain Name System (DNS) Fast Fluxing occurs when a domain is bound 194 in DNS using A records to multiple IP addresses, each of which has a 195 very short Time To Live (TTL) value associated with it. This means 196 that the domain resolves to varying IP addresses over a short period 197 of time. 199 DNS Fast Flux is typically used in conjunction with proxies that are 200 normally run on compromised user hosts. These proxies route the web 201 requests to the real host which serves the data being sought.The 202 effect of this is to make the detection of the real host much more 203 difficult and to ensure that the backend or hidden site remains up 204 for as long as possible. 206 2. Introduction and Problem Statement 208 Hosts used by Internet users, which in this case are customers of an 209 Internet Service Provider (ISP), can be infected with malware that 210 may contain and/or install one or more bots on a host. They can 211 present a major problem for an ISP for a number of reasons (not to 212 mention of course the problems created for users). First, these bots 213 can be used to send spam, in some cases very large volumes of spam 214 [Spamalytics]. This spam can result in extra cost for the ISPs in 215 terms of wasted network, server, and/or personnel resources, among 216 many other potential costs and side effects. Such spam can also 217 negatively affect the reputation of the ISP, their customers, and the 218 email reputation of the IP address space used by the ISP (often 219 referred to simply as 'IP reputation') A further potential 220 complication is that IP space compromised by bad reputation may 221 continue to carry this bad reputation even when used for entirely 222 innocent purposes following re-assignment of that IP space.. 224 In addition, these bots can act as platforms for directing, 225 participating in, or otherwise conducting attacks on critical 226 Internet infrastructure [Threat-Report]. Bots are frequently used as 227 part of coordinated Distributed Denial of Service (DDoS) attacks for 228 criminal, political or other motivations [Gh0st] [Dragon] [DDoS]. 229 For example, bots have been used to attack Internet resources and 230 infrastructure ranging from web sites to email servers and DNS 231 servers, as well as the critical Internet infrastructure of entire 232 countries [Estonia] [Combat-Zone]. Motivations for such coordinated 233 DDoS attacks can range from criminal extortion attempts through to 234 online protesting and nationalistic fervor [Whiz-Kid]. DDoS attacks 235 may also be motivated by simple personal vendettas or simply persons 236 seeking a cheap thrill at the expense of others. 238 There is good evidence to suggest that bots are being used in the 239 corporate environment for purposes of corporate espionage including 240 the exfiltration of corporate financial data and intellectual 241 property. This also extends to the possibility of bots being used 242 for state sponsored purposes such as espionage. 244 While any computing device can be infected with bots, the majority of 245 bot infections affect the personal computers used by Internet end 246 users. As a result of the role of ISPs in providing IP connectivity, 247 among many other services, to Internet users, these ISPs are in a 248 unique position to be able to attempt to detect and observe botnets 249 operating in their networks. Furthermore, ISPs may also be in a 250 unique position to be able to notify their customers of actual, 251 potential, or likely infection by bots or other infection. 253 From end users' perspectives, being notified that they may have an 254 infected computer on their network is important information. Once 255 they know this, they can take steps to remove the bots, resolve any 256 problems which may stem from the bot infection, and protect 257 themselves against future threats. Given that bots can consume vast 258 amounts of local computing and network resources, enable theft of 259 personal information (including personal financial information), 260 enable the host to be used for criminal activities (that may result 261 in the Internet user being legally culpable), destroy or leave the 262 host in an unrecoverable state via 'kill switch' bot technologies, it 263 is important to notify the user that they may be infected with a bot. 265 As a result, the intent of this document is to provide guidance to 266 ISPs and other organizations for the remediation of hosts infected 267 with bots, so as to reduce the size of botnets and minimize the 268 potential harm that bots can inflict upon Internet infrastructure 269 generally, as well as on individual Internet users. Efforts by ISPs 270 and other organizations can, over time, reduce the pool of hosts 271 infected with bots on the Internet, which in turn could result in 272 smaller botnets with less capability for disruption. 274 The potential mitigation of bots is accomplished through a process of 275 detection, notification to Internet users, and remediation of bot 276 infections with a variety of tools, as described later in this 277 document. 279 3. Important Notice of Limitations and Scope 281 The techniques described in this document in no way guarantee the 282 remediation of all bots. Bot removal is potentially a task requiring 283 specialized knowledge, skills and tools, and may be beyond the 284 ability of average users. Attempts at bot removal may frequently be 285 unsuccessful, or only partially successful, leaving the user's system 286 in an unstable and unsatisfactory state or even in a state where it 287 is still infected. Attempts at bot removal can result in side 288 effects ranging from a loss of data to partial or complete loss of 289 system usability. 291 In general, the only way a user can be sure they have removed some of 292 today's increasingly sophisticated malware is by 'nuking-and-paving' 293 the system: reformatting the drive, reinstalling the operating system 294 and applications (including all patches) from scratch, and then 295 restoring user files from a known clean backup. However the 296 introduction of persistent memory based malware may mean that, in 297 some cases, this may not be enough and may prove to be more than any 298 end user can be reasonably expected to resolve [BIOS]. Experienced 299 users would have to re-flash or re-image persistent memory sections 300 or components of their hosts in order to remove persistent memory 301 based malware. However, in some cases, not even 'nuking-and-paving' 302 the system will solve the problem, which calls for hard drive 303 replacement and/or complete replacement of the host. 305 Devices with embedded operating systems, such as video gaming 306 consoles and smart home appliances, will most likely be beyond a 307 user's capability to remediate by themselves, and could therefore 308 require the aid of vendor-specific advice, updates and tools. 309 However, in some cases, such devices will have a function or switch 310 to enable the user to reset that device to a factory default 311 configuration, which may in some cases enable the user to remediate 312 the infection. Care should be taken when imparting remediation 313 advice to Internet users given the increasingly wide array of 314 computing devices that can be, or could be, infected by bots in the 315 future. 317 This document is not intended to address the issues relating to the 318 prevention of bots on an end user device. This is out of scope for 319 this document. 321 4. Detection of Bots 323 An ISP must first identify that an Internet user, in this case a user 324 that is assumed to be their customer or otherwise connected to the 325 ISP's network, is infected, or likely to have been infected with a 326 bot. The ISP should attempt to detect the presence of bots using 327 methods, processes and tools that maintain the privacy of the 328 personally identifiable information (PII) of their customers. The 329 ISP should not block legitimate traffic in the course of bot 330 detection, and should instead employ detection methods, tools, and 331 processes that seek to be non-disruptive and transparent to Internet 332 users and end-user applications. 334 Detection methods, tools and processes may include analysis of 335 specific network and/or application traffic flows (such as traffic to 336 an email server), analysis of aggregate network and/or application 337 traffic data, data feeds received from other ISPs and organizations 338 (such as lists of the ISP's IP addresses which have been reported to 339 have sent spam), feedback from the ISP's customers or other Internet 340 users, as well as a wide variety of other possibilities. In 341 practice, it has proven effective to confirm a bot infection through 342 the use of a combination of multiple bot detection data points. This 343 can help to corroborate information of varying dependability or 344 consistency, as well as to avoid or minimize the possibility of false 345 positive identification of hosts. Detection should also, where 346 possible and feasible, attempt to classify the specific bot infection 347 type in order to confirm that it is malicious in nature, estimate the 348 variety and severity of threats it may pose (such as spam bot, key- 349 logging bot, file distribution bot, etc.), and to determine potential 350 methods for eventual remediation. However, given the dynamic nature 351 of botnet management and the criminal incentives to seek quick 352 financial rewards, botnets frequently update or change their core 353 capabilities. As a consequence, botnets that are initially detected 354 and classified by the ISP as made up of one particular type of bot 355 need to be continuously monitored and tracked in order to identify 356 correctly the threat the botnet poses at any particular point in 357 time. 359 Detection is also time-sensitive. If complex analysis is required 360 and multiple confirmations are needed to verify a bot is indeed 361 present, then it is possible that the bot may cause some damage (to 362 either the infected host or a remotely targeted system) before it can 363 be stopped. This means that an ISP needs to balance the desire or 364 need to definitively classify and/or confirm the presence of a bot, 365 which may take an extended period of time, with the ability to 366 predict the likelihood of a bot in a very short period of time. Such 367 determinations must have a relatively low false positive rate in 368 order to maintain the trust of users. This 'definitive-vs-likely' 369 challenge is difficult and, when in doubt, ISPs should err on the 370 side of caution by communicating that a bot infection has taken 371 place. This also means that Internet users may benefit from the 372 installation of client-based security software on their host. This 373 can enable rapid heuristically-based detection of bot activity, such 374 as the detection of a bot as it starts to communicate with other 375 botnets and execute commands. Any bot detection system should also 376 be capable of adapting, either via manual intervention or 377 automatically, in order to cope with a rapidly evolving threat. 379 As noted above, detection methods, tools, and processes should ensure 380 that privacy of customers' personally identifiable information (PII) 381 is maintained. This protection afforded to PII should also extend to 382 third parties processing data on behalf of ISPs. While bot detection 383 methods, tools, and processes are similar to spam and virus defenses 384 deployed by the ISP for the benefit of their customers (and may be 385 directly related to those defenses), attempts to detect bots should 386 take into account the need of an ISP to take care to ensure any PII 387 collected or incidentally detected is properly protected. This is 388 important, as just as spam defenses may involve scanning the content 389 of email messages, which may contain PII, then so too may bot 390 defenses similarly come into incidental contact with PII. The 391 definition of PII varies from one jurisdiction to the next so proper 392 care should be taken to ensure that any actions taken comply with 393 legislation and good practice in the jurisdiction in which the PII is 394 gathered. Finally, depending upon the geographic region within which 395 an ISP operates, certain methods relating to bot detection may need 396 to be included in relevant terms of service documents or other 397 documents which are available to the customers of a particular ISP. 399 There are several bot detection methods, tools, and processes that an 400 ISP may choose to utilize, as noted in the list below. It is 401 important to note that the technical solutions available are 402 relatively immature, and are likely to change over time, evolving 403 rapidly in the coming years. While these items are described in 404 relation to ISPs, they may also be applicable to organizations 405 operating other networks, such as campus networks and enterprise 406 networks. 408 a. Where it is not legally proscribed and an accepted industry 409 practice in a particular market region, an ISP may in some manner 410 "scan" its IP space in order to detect un-patched or otherwise 411 vulnerable hosts, or to detect the signs of infection. This may 412 provide the ISP with the opportunity to easily identify Internet 413 users who appear to already be infected or are at great risk of 414 being infected with a bot. ISPs should note that some types of 415 port scanning may leave network services in a hung state or 416 render them unusable due to common frailties, and that many 417 modern firewall and host-based intrusion detection 418 implementations may alert the Internet user to the scan. As a 419 result the scan may be interpreted as a malicious attack against 420 the host. Vulnerability scanning has a higher probability of 421 leaving accessible network services and applications in a damaged 422 state and will often result in a higher probability of detection 423 by the Internet user and subsequent interpretation as a targeted 424 attack. Depending upon the vulnerability for which an ISP may be 425 scanning, some automated methods of vulnerability checking may 426 result in data being altered or created afresh on the Internet 427 user's host which can be a problem in many legal environments. 428 It should also be noted that due to the prevalence of Network 429 Address Translation devices, Port Address Translation devices, 430 and/or firewall devices in user networks, network-based 431 vulnerability scanning may be of limited value. Thus, while we 432 note that this is one technique that may be utilized, it is 433 unlikely to be particularly effective and it has problematic side 434 effects, which leads the authors to recommend against the use of 435 this particular method. 437 b. An ISP may also communicate and share selected data, via feedback 438 loops or other mechanisms, with various third parties. Feedback 439 loops are consistently formatted feeds of real-time (or nearly 440 real-time) abuse reports offered by threat data clearinghouses, 441 security alert organizations, other ISPs, and other 442 organizations. The formats for feedback loops include those 443 defined in both ARF [RFC5965] and IODEF [RFC5070]. The data may 444 include, but is not limited to, IP addresses of hosts that appear 445 to be either definitely or probably infected, IP addresses, 446 domain names or fully qualified domain names (FQDNs) known to 447 host malware and/or be involved in the command and control of 448 botnets, recently tested or discovered techniques for detecting 449 or remediating bot infections, new threat vectors, and other 450 relevant information. A few good examples of data sharing are 451 noted in Appendix A. 453 c. An ISP may use Netflow [RFC3954] or other similar passive network 454 monitoring to identify network anomalies that may be indicative 455 of botnet attacks or bot communications. For example, an ISP may 456 be able to identify compromised hosts by identifying traffic 457 destined to IP addresses associated with the command and control 458 of botnets, or destined to the combination of an IP address and 459 control port associated with a command and control network 460 (sometimes command and control traffic comes from a host which 461 has legitimate traffic). In addition, bots may be identified 462 when a remote host is under a DDoS attack, because hosts 463 participating in the attack will likely be infected by a bot, 464 frequently as observed at network borders (though ISPs should 465 beware of source IP address spoofing techniques to avoid or 466 confuse detection). 468 d. An ISP may use DNS-based techniques to perform detection. For 469 example, a given classified bot may be known to query a specific 470 list of domain names at specific times or on specific dates (in 471 the example of the so-called "Conficker" bot (see [Conficker]), 472 often by matching DNS queries to a well known list of domains 473 associated with malware. In many cases such lists are 474 distributed by or shared using third parties, such as threat data 475 clearinghouses. 477 e. User complaints: Because hosts infected by bots are frequently 478 used to send spam or participate in DDoS attacks, the ISP 479 servicing those hosts will normally receive complaints about the 480 malicious network traffic. Those complaints may be sent to 481 RFC2142-specified [RFC2142] role accounts, such as abuse@, or to 482 other relevant addresses such as to abuse or security addresses 483 specified by the site as part of its WHOIS (or other) contact 484 data. 486 f. ISPs may also discover likely bot infected hosts located on other 487 networks. Thus, when legally permissible in a particular market 488 region, it may be worthwhile for ISPs to share information 489 relating to those compromised hosts with the relevant remote 490 network operator, with security researchers, and with blocklist 491 operators. 493 g. ISPs may operate or subscribe to services that provide 494 'sinkholing' or 'honeynet' capabilities. This may enable the ISP 495 to obtain near-real-time lists of bot infected hosts as they 496 attempt to join a larger botnet or propagate to other hosts on a 497 network. 499 h. ISP industry associations should examine the possibility of 500 collating statistics from ISP members in order to provide good 501 statistics about bot infections based on real ISP data. 503 i. An Intrusion Detection System (IDS) can be a useful tool to 504 actually help identify the malware. An IDS tool such as SNORT 505 (open source IDS platform; see [Snort]) can be placed in a Walled 506 Garden and used to analyze end user traffic to confirm malware 507 type. This will help with remediation of the infected device. 509 5. Notification to Internet Users 511 Once an ISP has detected a bot, or the strong likelihood of a bot, 512 steps should be undertaken to inform the Internet user that they may 513 have a bot-related problem. Depending upon a range of factors 514 including technical capabilities of the ISP, technical attributes of 515 its network, financial considerations, available server resources, 516 available organizational resources, the number of likely infected 517 hosts detected at any given time and the severity of any possible 518 threats, among other things, an ISP should decide the most 519 appropriate method or methods for providing notification to one or 520 more of their customers or Internet users. Such notification methods 521 may include one or more of the methods described in the following 522 subsections, as well as other possible methods not described below. 524 It is important to note that none of these methods are guaranteed to 525 be one-hundred percent successful, and that each has its own set of 526 limitations. In addition, in some cases, an ISP may determine that a 527 combination of two or more methods is most appropriate and effective, 528 and reduces the chance that malware may block a notification. As 529 such, the authors recommend the use of multiple notification methods. 530 Finally, notification is also considered time sensitive; if the user 531 does not receive or view the notification in a timely fashion, then a 532 particular bot could launch an attack, exploit the user, or cause 533 other harm. If possible, an ISP should establish a preferred means 534 of communication when the subscriber first signs up for service. As 535 a part of the notification process, ISPs should maintain a record of 536 the allocation of IP addresses to subscribers for such a period long 537 enough to allow any commonly used bot detection technology to be able 538 to accurately link an infected IP address to a subscriber. This 539 record should only be maintained for a period of time which is 540 necessary to support bot detection,but no longer, in order to protect 541 the privacy of the individual subscriber. 543 One important factor to bear in mind is that notification to end 544 users needs to be resistant to potential spoofing. This should be 545 done to protect, as reasonably as possible, against the potential of 546 legitimate notifications being spoofed and/or used by parties with 547 intent to perform additional malicious attacks against victims of 548 malware, or even to deliver additional malware. 550 It should be possible for the end user to indicate the preferred 551 means of notification on an opt-in basis for that notification 552 method. It is recommended that the end user should not be allowed to 553 opt out of notification entirely. 555 When users are notified, an ISP should endeavor to give as much 556 information to the end user regarding which bot detection methods 557 employed at the ISP consonant with not providing information to those 558 creating or deploying the bots so that they would be able to avoid 559 detection. 561 5.1. Email Notification 563 This is a common form of notification used by ISPs. One drawback of 564 using email is that it is not guaranteed to be viewed within a 565 reasonable time frame, if at all. The user may be using a different 566 primary email address than that which they have provided to the ISP. 567 In addition, some ISPs do not provide an email account at all, as 568 part of a bundle of Internet services, and/or do not have a need for 569 or method by which to request or retain the primary email addresses 570 of Internet users of their networks. Another possibility is that the 571 user, their email client, and/or their email servers could determine 572 or classify such a notification as spam, which could delete the 573 message or otherwise file it in an email folder that the user may not 574 check on a regular and/or timely basis. Bot masters have also been 575 known to impersonate the ISP or trusted sender and send fraudulent 576 emails to the users. This technique of social engineering often 577 leads to new bot infestations. Finally if the user's email 578 credentials are compromised, then a hacker and/or a bot could simply 579 access the user's email account and delete the email before it is 580 read by the user. 582 5.2. Telephone Call Notification 584 A telephone call may be an effective means of communication in 585 particularly high-risk situations. However, telephone calls may not 586 be feasible due to the cost of making a large number of calls, as 587 measured in either time, money, organizational resources, server 588 resources, or some other means. In addition, there is no guarantee 589 that the user will answer their phone. To the extent that the 590 telephone number called by the ISP can be answered by the infected 591 computing device, the bot on that host may be able to disconnect, 592 divert, or otherwise interfere with an incoming call. Users may also 593 interpret such a telephone notification as a telemarketing call and 594 as such not welcome it, or not accept the call at all. Finally, even 595 if a representative of the ISP is able to connect with and speak to a 596 user, that user is very likely to lack the necessary technical 597 expertise to understand or be able to effectively deal with the 598 threat. 600 5.3. Postal Mail Notification 602 This form of notification is probably the least popular and effective 603 means of communication, due to both preparation time, delivery time, 604 the cost of printing and paper, and the cost of postage. 606 5.4. Walled Garden Notification 608 Placing a user in a walled garden is another approach that ISPs may 609 take to notify users. A walled garden refers to an environment that 610 controls the information and services that a subscriber is allowed to 611 utilize and what network access permissions are granted. A walled 612 garden implementation can range from strict to leaky. In a strict 613 walled garden environment, access to most Internet resources is 614 typically limited by the ISP. In contrast, a leaky walled garden 615 environment permits access to all Internet resources, except those 616 deemed malicious, and ensures access to those that can be used to 617 notify users of infections. 619 Walled gardens are effective because it is possible to notify the 620 user and simultaneously block all communication between the bot and 621 the command and control channel. While in many cases the user is 622 almost guaranteed to view the notification message and take any 623 appropriate remediation actions, this approach can pose other 624 challenges. For example, it is not always the case that a user is 625 actively using a host that uses a web browser or that has a web 626 browser actively running on it, or that uses another application 627 which uses ports which are redirected to the walled garden. In one 628 example, a user could be playing a game online, via the use of a 629 dedicated, Internet-connected game console. In another example, the 630 user may not be using a host with a web browser when they are placed 631 in the walled garden and may instead be in the course of a telephone 632 conversation, or may be expecting to receive a call, using a Voice 633 Over IP (VoIP) device of some type. As a result, the ISP may feel 634 the need to maintain a potentially lengthy white list of domains that 635 are not subject to the typical restrictions of a walled garden, which 636 could well prove to be an onerous task from an operational 637 perspective. 639 For these reasons the implementation of a leaky walled garden makes 640 more sense, but a leaky walled garden has a different set of 641 drawbacks. The ISP has to assume that the user will eventually use a 642 web browser to acknowledge the notification, otherwise the user will 643 remain in the walled garden and not know it. If the intent of the 644 leaky walled garden is solely to notify the user about the bot 645 infection, then the leaky walled garden is not ideal because 646 notification is time sensitive and the user may not receive the 647 notification until the user invokes a request for the targeted 648 service and/or resource. This means the bot can potentially do more 649 damage. Additionally, the ISP has to identify which services and/or 650 resources to restrict for the purposes of notification. This does 651 not have to be resource specific and can be time based and/or policy 652 based. An example of how notification could be made on a timed basis 653 could involve notification for all HTTP requests every 10 minutes, or 654 show the notification for one in five HTTP requests. 656 The ISP has several options to determine when to let the user out of 657 the walled garden. One approach may be to let the user determine 658 when to exit. This option is suggested when the primary purpose of 659 the walled garden is to notify users and provide information on 660 remediation only, particularly since notification is not a guarantee 661 of successful remediation. It could also be the case that, for 662 whatever reason, the user makes the judgment that they cannot then 663 take the time to remediate their host and that other online 664 activities which they would like to resume are more important. Exit 665 from the walled garden may also involve a process to verify that it 666 is indeed the user who is requesting exit from the walled garden and 667 not the bot. 669 Once the user acknowledges the notification, they may decide to 670 either remediate and exit the walled garden or to exit the walled 671 garden without remediating the issue. Another approach may be to 672 enforce a stricter policy and require the user to clean the host 673 prior to permitting the user to exit the walled garden, though this 674 may not be technically feasible depending upon the type of bot, 675 obfuscation techniques employed by a bot, and/or a range of other 676 factors. Thus, the ISP may also need to support tools to scan the 677 infected host (in the style of a virus scan, rather than a port scan) 678 and determine whether it is still infected or rely on user judgment 679 that the bot has been disabled or removed. One challenge with this 680 approach is that the user might have multiple hosts sharing a single 681 IP address, such as via a common home gateway device which performs 682 Network Address Translation (NAT). In such a case, the ISP may need 683 to determine from user feedback, or other means, that all affected 684 hosts have been remediated, which may or may not be technically 685 feasible. 687 Finally, when a walled garden is used, a list of well-known addresses 688 for both operating system vendors and security vendors should be 689 created and maintained in a white list which permits access to these 690 sites. This can be important for allowing access from the walled 691 garden by end users in search of operating system and application 692 patches. It is recommended that walled gardens be seriously 693 considered as a method of notification as they are easy to implement 694 and proven to be effective as a means of getting end user attention. 696 5.5. Instant Message Notification 698 Instant messaging provides the ISP with a simple means to communicate 699 with the user. There are several advantages to using Instant 700 Messaging (IM) that make it an attractive option. If the ISP 701 provides IM service and the user subscribes to it, then the user can 702 be notified easily. IM-based notification can be a cost effective 703 means to communicate with users automatically from an IM alert system 704 or by a manual process, involving the ISP's support staff. Ideally, 705 the ISP should allow the user to register their IM identity in an ISP 706 account management system and grant permission to be contacted via 707 this means. If the IM service provider supports off-line messaging, 708 then the user can be notified regardless of whether they are 709 currently logged into the IM system. 711 There are several drawbacks with this communications method. There 712 is a high probability that subscriber may interpret the communication 713 to be spim, and as such ignore it. Also, not every user uses IM 714 and/or the user may not provide their IM identity to the ISP so some 715 alternative means have to be used. Even in those cases where a user 716 does have an IM address, they may not be signed onto that IM system 717 when the notification is attempted. There may be a privacy concern 718 on the part of users, when such an IM notification must be 719 transmitted over a third-party network and/or IM service. As such, 720 should this method be used, the notification should be discreet and 721 not include any PII in the notification itself. 723 5.6. Short Message Service (SMS) Notification 725 SMS allows the ISP to send a brief description of the problem to 726 notify the user of the issue, typically to a mobile device such as a 727 mobile phone or smart phone. Ideally, the ISP should allow the user 728 to register their mobile number and/or SMS address in an ISP account 729 management system and grant permission to be contacted via this 730 means. The primary advantage of SMS is that users are familiar with 731 receiving text messages and are likely to read them. However, users 732 may not act on the notification immediately if they are not in front 733 of their host at the time of the SMS notification. 735 One disadvantage is that ISPs may have to follow up with an alternate 736 means of notification if not all of the necessary information may be 737 conveyed in one message, given constraints on the number of 738 characters in an individual message (typically 140 characters). 739 Another disadvantage with SMS is the cost associated with it. The 740 ISP has to either build its own SMS gateway to interface with the 741 various wireless network service providers or use a third-party SMS 742 clearinghouse (relay) to notify users. In both cases an ISP may 743 incur fees related to SMS notifications, depending upon the method 744 used to send the notifications. An additional downside is that SMS 745 messages sent to a user may result in a charge to the user by their 746 wireless provider, depending upon the plan to which they subscribe 747 and the country in which the user resides. Another minor 748 disadvantage is that it is possible to notify the wrong user if the 749 intended user changes their mobile number but forgets to update it 750 with the ISP. 752 There are several other drawbacks with this communications method. 753 There is a high probability that subscriber may interpret the 754 communication to be spam, and as such ignore it. Also, not every 755 user uses SMS and/or the user may not provide their SMS address or 756 mobile number to the ISP. Even in those cases where a user does have 757 an SMS address or mobile number, their device may not be powered on 758 or otherwise available on a wireless network when the notification is 759 attempted. There maybe also be a privacy concern on the part of 760 users, when such an SMS notification must be transmitted over a 761 third-party network and/or SMS clearinghouse. As such, should this 762 method be used, the notification should be discreet and not include 763 any PII in the notification itself. 765 5.7. Web Browser Notification 767 Near real-time notification to the user's web browser is another 768 technique that may be utilized for notifying the user [RFC6108], 769 though how such a system might operate is outside the scope of this 770 document. Such a notification could have a comparative advantage 771 over a walled garden notification, in that it does not restrict 772 traffic to a specified list of destinations in the same way that a 773 walled garden by definition would. However, as with a walled garden 774 notification, there is no guarantee that a user is at any given time 775 making use of a web browser, though such a system could certainly 776 provide a notification when such a browser is eventually used. 777 Compared to a walled garden, a web browser notification is probably 778 preferred from the perspective of Internet users, as it does not have 779 the risk of disrupting non-web sessions, such as online games, VoIP 780 calls, etc. (as noted in Section 5.4). 782 There are alternative methods of web browser notification offered 783 commercially by a number of vendors. Many of the techniques used are 784 proprietary and it is not within the scope of this document to 785 describe how they are implemented. These techniques have been 786 successfully implemented at several ISPs. 788 It should be noted that web notification is only intended to notify 789 devices running a web browser. 791 5.8. Considerations for Notification to Public Network Locations 793 Delivering a notification to a location that provides a shared public 794 network, such as a train station, public square, coffee shop, or 795 similar location may be of low value since the users connecting to 796 such networks are typically highly transient and generally not known 797 to site or network administrators. For example, a system may detect 798 that a host on such a network has a bot, but by the time a 799 notification is generated that user has departed from the network and 800 moved elsewhere. 802 5.9. Considerations for Notification to Network Locations Using a 803 Shared IP Address 805 Delivering a notification to a location that accesses the Internet 806 routed through one or more shared public IP addresses may be of low 807 value since it may be quite difficult to differentiate between users 808 when providing a notification. For example, on a business network of 809 500 users, all sharing one public IP address, it may be sub-optimal 810 to provide a notification to all 500 users if you only need one 811 specific user to be notified and take action. As a result, such 812 networks may find value in establishing a localized bot detection and 813 notification system, just as they are likely to also establish other 814 localized systems for security, file sharing, email, and so on. 816 However, should an ISP implement some form of notification to such 817 networks, it may be better to simply send notifications to a 818 designated network administrator at the site. In such a case the 819 local network administrator may like to receive additional 820 information in such a notification, such as a date and timestamp, the 821 source port of the infected system, and malicious sites and ports 822 that may have been visited. 824 5.10. Notification and End User Expertise 826 The ultimate effectiveness of any of the aforementioned forms of 827 notification is heavily dependent upon both the expertise of the end 828 user and the wording of any such notification. For example, while a 829 user may receive and acknowledge a notification, that user may lack 830 the necessary technical expertise to understand or be able to deal 831 effectively with the threat. As a result, it is important that such 832 notifications use clear and easily understood language, so that the 833 majority of users (who are non-technical) may understand the 834 notification. In addition, a notification should provide easily 835 understood guidance on how to remediate a threat as described in 836 Section 6, potentially with one path for technical users to take and 837 another for non-technical users. 839 6. Remediation of Hosts Infected with a Bot 841 This section covers the different options available to remediate a 842 host, which means to remove, disable, or otherwise render a bot 843 harmless. Prior to this step, an ISP has detected the bot, notified 844 the user that one of their hosts is infected with a bot, and now may 845 provide some recommended means to clean the host. The generally 846 recommended approach is to provide the necessary tools and education 847 to the user so that they may perform bot remediation themselves, 848 particularly given the risks and difficulties inherent in attempting 849 to remove a bot. 851 For example, this may include the creation of a special web site with 852 security-oriented content that is dedicated for this purpose. This 853 should be a well-publicized security web site to which a user with a 854 bot infection can be directed to for remediation. This security web 855 site should clearly explain why the user was notified and may include 856 an explanation of what bots are, and the threats that they pose. 857 There should be a clear explanation of the steps that the user should 858 take in order to attempt to clean their host and provide information 859 on how users can keep the host free of future infections. The 860 security web site should also have a guided process that takes non- 861 technical users through the remediation process, on an easily 862 understood, step-by-step basis. 864 In terms of the text used to explain what bots are and the threats 865 that they pose, something simple such as this may suffice: 867 "What is a bot? A bot is a piece of software, generally 868 installed on your machine without your knowledge, which either 869 sends spam or tries to steal your personal information. They 870 can be very difficult to spot, though you may have noticed that 871 your computer is running much more slowly than usual or you 872 notice regular disk activity even when you are not doing 873 anything. Ignoring this problem is risky to you and your 874 personal information. Thus, bots need to be removed to protect 875 your data and your personal information." 877 Many bots are designed to work in a very stealthy manner and as such 878 there may be a need to make sure that the Internet user understands 879 the magnitude of the threat faced despite the stealthy nature of the 880 bot. 882 It is also important to note that it may not be immediately apparent 883 to the Internet user precisely which devices have been infected with 884 a particular bot. This may be due to the user's home network 885 configuration, which may encompass several hosts, where a home 886 gateway which performs Network Address Translation (NAT) to share a 887 single public IP address has been used. Therefore, any of these 888 devices can be infected with a bot. The consequence of this for an 889 ISP is that remediation advice may not ultimately be immediately 890 actionable by the Internet user, as that user may need to perform 891 additional investigation within their own home network. 893 An added complication is that the user may have a bot infection on a 894 device such as a video console, multimedia system, appliance, or 895 other end-user computing device which does not have a typical desktop 896 computing interface. As a result, diligence needs to be taken by the 897 ISP where possible such that it can identify and communicate the 898 specific nature of the device that has been infected with a bot, and 899 further providing appropriate remediation advice. If the ISP cannot 900 pin down the device or identify its type, then it should make it 901 clear to the user that any initial advice given is generic and 902 further advice can be given (or is available) once the type of 903 infected device is known. 905 There are a number of forums that exist online to provide security 906 related support to end users. These forums are staffed by volunteers 907 and often are focussed around the use of a common tool set to help 908 end users to remediate hosts infected with malware. It may be 909 advantageous to ISPs to foster a relationship with one or more 910 forums, perhaps by offering free hosting or other forms of 911 sponsorship. 913 It is also important to keep in mind that not all users will be 914 technically adept as noted in Section 5.10. As a result, it may be 915 more effective to provide a range of suggestion options for 916 remediation. This may include for example a very detailed "do it 917 yourself" approach for experts, a simpler guided process for the 918 average user, and even assisted remediation as described in 919 Section 6.2. 921 6.1. Guided Remediation Process 923 Minimally, the Guided Remediation Process should include the 924 following goals, with options and/or recommendations for achieving 925 them: 927 1. Backup personal files. For example: "Before you start, make sure 928 to backup all of your important data. (You should do this on a 929 regular basis anyway.) You can backup your files manually or 930 using a system backup software utility, which may be part of your 931 Operating System (OS). You can backup your files to a USB Thumb 932 Drive (aka USB Key), a writeable CD/DVD-ROM, an external hard 933 drive, a network file server, or an Internet-based backup 934 service." It may be advisable to suggest that the user backup is 935 performed onto separate backup media or devices if they suspect 936 bot infection. 938 2. Download OS patches and Anti-Virus (A/V) software updates. For 939 example, links could be provided to Microsoft Windows updates as 940 well as to Apple MacOS updates, or to other major operating 941 systems which are relevant to users and their devices. 943 3. Configure the host to automatically install updates for the OS, 944 A/V and other common Web Browsers such as Microsoft Internet 945 Explorer, Mozilla Firefox, Apple Safari, Opera, and Google 946 Chrome. 948 4. Get professional assistance if they are unable to remove the bots 949 themselves. If purchasing professional assistance, then the user 950 should be encouraged to pre-determine how much they are willing 951 to pay for that help. If the host that is being remediated is 952 old and can easily be replaced with a new, faster, larger and 953 more reliable system for a certain cost, the it makes no sense to 954 spend more than that cost to fix the old host, for example. On 955 the other hand, if the customer has a brand new host, it might 956 make perfect sense to spend the money to attempt to remediate it. 958 5. To continue, regardless of whether the user or a knowledgeable 959 technical assistant is working on remediating the host, their 960 first task should be to determine which of multiple potentially- 961 infected machines may be the one that needs attention (in the 962 common case of multiple hosts in a home network). Sometimes, as 963 in cases where there is only a single directly-attached host, or 964 the user has been noticing problems with one of their hosts, this 965 can be easy. Other times, it may be more difficult especially if 966 there are no clues as to which host is infected. If the user is 967 behind a home gateway/router, then the first task may be to 968 ascertain which of the machines is infected. In some cases the 969 user may have to check all machines to identify the infected one. 971 6. ISPS may also look at offering a CD/DVD with remediation 972 processes and software in the event that a host is so badly 973 infected as to be unable to communicate over the Internet. 975 7. User surveys to solicit feedback on whether the notification and 976 remediation process is effective and what recommended changes 977 could be made in order to improve the ease, understandability, 978 and effectiveness the remediation process. 980 8. If the user is interested in reporting his or her host's bot 981 infection to an applicable law enforcement authority, then the 982 host effectively becomes a cyber "crime scene" and the infection 983 should not be mitigated unless or until law enforcement has 984 collected the necessary evidence. For individuals in this 985 situation, the ISP may wish to provide links to local, state, 986 federal, or other relevant computer crime offices. (Note: Some 987 "minor" incidents, even if highly traumatic to the user, may not 988 be sufficiently serious for law enforcement to commit some of 989 their limited resources to an investigation.) In addition, 990 individual regions may have other, specialized computer crime 991 organizations to which these incidents can be reported. For 992 example, in the United States, that organization is the Internet 993 Crime Complaint Center, at http://www.ic3.gov. 995 9. Users may also be interested in links to security expert forums, 996 where other users can assist them. 998 6.2. Professionally-Assisted Remediation Process 1000 It should be acknowledged that, based on the current state of 1001 remediation tools and the technical abilities of end users, that many 1002 users may be unable to remediate on their own. As a result, it is 1003 recommended that users have the option for professional assistance. 1004 This may entail online or telephone assistance for remediation, as 1005 well as working face to face with a professional who has training and 1006 expertise in the removal of malware. It should be made clear at the 1007 time of offering this service that this service is intended for those 1008 that do not have the skills or confidence to attempt remediation and 1009 is not intended as an up-sell by the ISP. 1011 7. Failure or Refusal to Remediate 1013 ISP systems should track the bot infection history of hosts in order 1014 to detect when users consistently fail to remediate or refuse to take 1015 any steps to remediate. In such cases, ISPs may need to consider 1016 taking additional steps to protect their network, other users and 1017 hosts on that network, and other networks. Such steps may include a 1018 progression of actions up to and including account termination. 1019 Refusal to remediate can be viewed as a business issue and as such no 1020 technical recommendation is possible. 1022 8. Sharing of Data from the User to the ISP 1024 As an additional consideration, it may be useful to create a process 1025 by which users could choose, at their option and with their express 1026 consent, to share data regarding their bot infections with their ISP 1027 and/or another authorized third party. Such third parties may 1028 include governmental entities that aggregate threat data, such as the 1029 Internet Crime Complaint Center referred to earlier in this document, 1030 to academic institutions, and/or security researchers. While in many 1031 cases the information shared with the user's ISP or designated third 1032 parties will only be used for aggregated statistical analysis, it is 1033 also possible that certain research needs may be best met with more 1034 detailed data. Thus, any such data sharing from a user to the ISP or 1035 authorized third party may contain some type of personally 1036 identifiable information, either by design or inadvertently. As a 1037 result, any such data sharing should be enabled on an opt-in basis, 1038 where users review and approve of the data being shared and the 1039 parties with which it is to be shared, unless the ISP is already 1040 required to share such data in order to comply with local laws and in 1041 accordance with those laws and applicable regulations. 1043 9. Security Considerations 1045 This document describes in detail the numerous security risks and 1046 concerns relating to botnets. As such, it has been appropriate to 1047 include specific information about security in each section above. 1048 This document describes the security risks related to malicious bot 1049 infections themselves, such as enabling identity theft, theft of 1050 authentication credentials, and the use of a host to unwittingly 1051 participate in a DDoS attack, among many other risks. Finally, the 1052 document also describes security risks which may relate to the 1053 particular methods of communicating a notification to Internet users. 1054 Bot networks and bot infections pose extremely serious security risks 1055 and any reader should review this document carefully. 1057 In addition, regarding notifications, as described in Section 5, care 1058 should be taken to assure users that notifications have been provided 1059 by a trustworthy site and/or party, so that the notification is more 1060 difficult for phishers and/or malicious parties using social 1061 engineering tactics to mimic, or that the user has some level of 1062 trust that the notification is valid, and/or that the user has some 1063 way to verify via some other mechanism or step that the notification 1064 is valid. 1066 10. Privacy Considerations 1068 This document describes at a high level the activities to which ISPs 1069 should be sensitive, where the collection or communication of PII may 1070 be possible. In addition, when performing notifications to end users 1071 Section 5, those notifications should not include PII. 1073 As noted in Section 8, any sharing of data from the user to the ISP 1074 and/or authorized third parties should be done on an opt-in basis. 1075 Additionally the ISP and or authorized third parties should clearly 1076 state what data will be shared and with whom the data will be shared. 1078 Lastly, as noted in some other sections, there my be legal 1079 requirements in particular legal jurisdictions concerning how long 1080 any subscriber-related or other data is retained, of which an ISP 1081 operating in such a jurisdiction should be aware and with which an 1082 ISP should comply. 1084 11. IANA Considerations 1086 There are no IANA considerations in this document. 1088 12. Acknowledgements 1090 The authors wish to acknowledge the following individuals and groups 1091 for performing a detailed review of this document and/or providing 1092 comments and feedback that helped to improve and evolve this 1093 document: 1095 Mark Baugher 1097 Richard Bennett 1099 James Butler 1101 Vint Cerf 1103 Alissa Cooper 1105 Jonathan Curtis 1107 Jeff Chan 1109 Roland Dobbins 1111 Dave Farber 1113 Stephen Farrell 1115 Eliot Gillum 1117 Joel Halpern 1119 Joel Jaeggli 1121 Scott Keoseyan 1123 Murray S. Kucherawy 1125 The Messaging Anti-Abuse Working Group (MAAWG) 1126 Jose Nazario 1128 Gunter Ollmann 1130 David Reed 1132 Roger Safian 1134 Donald Smith 1136 Joe Stewart 1138 Forrest Swick 1140 Sean Turner 1142 Robb Topolski 1144 Maxim Weinstein 1146 Eric Ziegast 1148 13. Informative references 1150 [BIOS] Sacco, A. and A. Ortega, "Persistent BIOS Infection", 1151 March 2009, . 1154 [Combat-Zone] 1155 Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon 1156 of Electronic Jihad", February 2007, . 1159 [Conficker] 1160 Porras, P., Saidi, H., and V. Yegneswaran, "An Analysis of 1161 Conficker's Logic and Rendezvous Points", March 2009, 1162 . 1164 [DDoS] Saafan, A., "Distributed Denial of Service Attacks: 1165 Explanation, Classification and Suggested Solutions", 1166 March 2009, . 1168 [Dragon] Nagaraja, S. and R. Anderson, "The snooping dragon: 1169 social-malware surveillance of the Tibetan movement", 1170 March 2009, 1171 . 1173 [Estonia] Evron, G., "Battling Botnets and Online Mobs: Estonia's 1174 Defense Efforts during the Internet War", May 2005, . 1180 [Gh0st] Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st 1181 in the Shell: Network Security in the Himalayas", 1182 February 2010, . 1185 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1186 RFC 1459, May 1993. 1188 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1189 FUNCTIONS", RFC 2142, May 1997. 1191 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1192 9", RFC 3954, October 2004. 1194 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1195 Object Description Exchange Format", RFC 5070, 1196 December 2007. 1198 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1199 Extensible Format for Email Feedback Reports", RFC 5965, 1200 August 2010. 1202 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 1203 Van Lieu, "Comcast's Web Notification System Design", 1204 RFC 6108, February 2011. 1206 [Snort] Roesch, M., "Snort Home Page", March 2009, 1207 . 1209 [Spamalytics] 1210 Kanich, C., Kreibich, C., Levchenko, K., Enright, B., 1211 Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An 1212 Empirical Analysis of Spam Marketing Conversion", 1213 October 2008, . 1216 [Threat-Report] 1217 Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., 1218 Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., 1219 Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber 1220 Threats Report for 2009: Data, Mobility and Questions of 1221 Responsibility will Drive Cyber Threats in 2009 and 1222 Beyond", October 2008, . 1225 [Whiz-Kid] 1226 Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid 1227 Took On a DDOS-based Online Extortion Attack", May 2005, < 1228 http://www.csoonline.com/article/220336/ 1229 How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online 1230 _Extortion_Attack>. 1232 Appendix A. Examples of Third Party Malware Lists 1234 As noted in Section 4, there are many potential third parties which 1235 may be willing to share lists of infected hosts. This list is for 1236 example purposes only, is not intended to be either exclusive or 1237 exhaustive, and is subject to change over time. 1239 o Arbor - Atlas, see http://atlas.arbor.net/ 1241 o Internet Systems Consortium - Secure Information Exchange (SIE), 1242 see https://sie.isc.org/ 1244 o Microsoft - Smart Network Data Services (SNDS), see 1245 https://postmaster.live.com/snds/ 1247 o SANS Institute / Internet Storm Center - DShield Distributed 1248 Intrusion Detection System, see http://www.dshield.org/about.html 1250 o ShadowServer Foundation, see http://www.shadowserver.org/ 1252 o Spamhaus - Policy Block List (PBL), see 1253 http://www.spamhaus.org/pbl/ 1255 o Spamhaus - Exploits Block List (XBL), see 1256 http://www.spamhaus.org/xbl/ 1258 o Team Cymru - Community Services, see http://www.team-cymru.org/ 1260 Appendix B. Document Change Log 1262 [RFC Editor: This section is to be removed before publication] 1264 -20 version: 1266 o Addressed comments raised at IESG ommitted in -19 1268 o minor nits corrections 1270 -19 version: 1272 o Addressed comments raised at IESG 1274 o minor nits corrections 1276 -18 version: 1278 o minor nits corrections 1280 -17 version: 1282 o various copy editing 1284 o briefly discuss IP reputation issues 1286 o briefly discuss corporate espionage threat 1288 o add references for ARF and IODEF, Snort, and Conficker 1290 -16 version: 1292 o Section 6.1.6 Substituted unable for able 1294 -15 version: 1296 o Issue of quiet bots addressed 1298 o Section 5.4 substitute "may be" for maybe 1300 o Section 5.4 Added reference to country of residence 1302 o Section 5.8 Corrected spelling error 1304 o Section 5.10 Correctedspelling error 1306 o Section 6 Corrected spelling errors 1308 -14 version: 1310 o Minor errors rectified, spelling errors addressed 1312 o ALL open issues are now closed! 1313 -13 version: 1315 o All changes below per Sean Farrell except where indicated 1317 o Section 1.2 Added reference to fast flux definition 1319 o Section 1.2 Included reference to insecure protocols 1321 o Section 4 Cleared ambiguity 1323 o Section 4 Substituted "must have" 1325 o Section 4 Substituted "to" for "too" 1327 o Section 4 Addressed PII issue for 3rd parties 1329 o Section 4 Addressed issue around blocking of traffic during bot 1330 detection process 1332 o Section 5 Per Max Weinstein Included a number of comments and 1333 addressed issues of detection transparency 1335 o Section 5 Addressed issue by recommending that users should be 1336 allowed to opt in to their desired method of notification 1338 o Section 5.4 Addressed issue around timing of notification 1340 o Section 5.4 Addressed Walled Garden issue by recommending that 1341 Walled Gardens are to be used as a notification method 1343 o Section 5.7 Noted that there are alternative methods to that 1344 outlined in RFC6108 1346 o Section 5.7 Noted that web notification is only intended for 1347 devices running a web browser 1349 o Section 5.9 Fixed typo 1351 o Section 6.1 Noted that ISPs should be clear when offering paid 1352 remediation services that these are aimed at those without skills 1353 to remediate or lacking confidence to do so 1355 o Section 7 Noted that refusal to remediate is a business issue and 1356 not subject to technical recommendation. 1358 o ALL open issues are now closed! 1360 -12 version: 1362 o Shortened reference names (non-RFC references) 1364 o Closed Open Issue #1 and #4, as leaky walled gardens are covered 1365 in Section 5.4 1367 o Closed Open Issue #2 and #6, by adding a section on users that 1368 fail to mitigate, including account termination 1370 o Closed Open Issue #3, by adding a Privacy Considerations section 1371 to address PII 1373 o Closed Open Issue #5, with no action taken 1375 o Closed Open Issue #7, by leaving as Informational (the IETF can 1376 assess this later) 1378 o Closed Open Issue #8, by generalizing the guided remediation 1379 section via the removal of specific links, etc. 1381 o Closed Open Issue #9, by reviewing and updating remediation steps 1383 o Changed some 'must' statements to 'should' statements (even though 1384 there is not RFC 2119 language in the document) 1386 o ALL open issues are now closed! 1388 -11 version: 1390 o Added reference to RFC 6108 1392 o Per Sean Turner, removed RFC 2119 reference and section 1394 o Per Donald Smith, externalized the reference to 3rd party data 1395 sources, now Appendix A 1397 o Per Donald Smith, moved basic notification challenges into a new 1398 section at the end of the Notifications section. 1400 -10 version: 1402 o Minor refresh to keep doc from expiring. Several large updates 1403 planned in a Dec/Jan revision 1405 -09 version: 1407 o Corrected nits pointed out by Sean 1408 o Removed occurrences of double spacing 1410 o Grammar and spelling corrections in many sections 1412 o Added text for leaky walled garden 1414 -08 version: 1416 o Corrected a reference error in Section 10. 1418 o Added a new informative reference 1420 o Change to Section 5.a., to note additional port scanning 1421 limitations 1423 o Per Joel Jaeggli, change computer to host, to conform to IETF 1424 document norms 1426 o Several other changes suggested by Joel Jaeggli and Donald Smith 1427 on the OPSEC mailing list 1429 o Incorp. other feedback received privately 1431 o Because Jason is so very dedicated, he worked on this revision 1432 while on vacation ;-) 1434 -07 version: 1436 o Corrected various spelling and grammatical errors, pointed out by 1437 additional reviewers. Also added a section on information flowing 1438 from the user. Lastly, updated the reviewer list to include all 1439 those who either were kind enough to review for us or who provided 1440 interesting, insightful, and/or helpful feedback. 1442 -06 version: 1444 o Corrected an error in the version change log, and added some extra 1445 information on user remediation. Also added an informational 1446 reference to BIOS infection. 1448 -05 version: 1450 o Minor tweaks made by Jason - ready for wider review and next 1451 steps. Also cleared open issues. Lastly, added 2nd paragraph to 1452 security section and added sections on limitations relating to 1453 public and other shared network sites. Added a new section on 1454 professional remediation. 1456 -04 version: 1458 o Updated reference to BIOS based malware, added wording on PII and 1459 local jurisdictions, added suggestion that industry body produce 1460 bot stats, added suggestion that ISPs use volunteer forums 1462 -03 version: 1464 o all updates from Jason - now ready for wider external review 1466 -02 version: 1468 o all updates from Jason - still some open issues but we're now at a 1469 place where we can solicit more external feedback 1471 -01 version: 1473 o -01 version published 1475 Appendix C. Open Issues 1477 No open issues. 1479 Authors' Addresses 1481 Jason Livingood 1482 Comcast Cable Communications 1483 One Comcast Center 1484 1701 John F. Kennedy Boulevard 1485 Philadelphia, PA 19103 1486 US 1488 Email: jason_livingood@cable.comcast.com 1489 URI: http://www.comcast.com 1491 Nirmal Mody 1492 Comcast Cable Communications 1493 One Comcast Center 1494 1701 John F. Kennedy Boulevard 1495 Philadelphia, PA 19103 1496 US 1498 Email: nirmal_mody@cable.comcast.com 1499 URI: http://www.comcast.com 1500 Mike O'Reirdan 1501 Comcast Cable Communications 1502 One Comcast Center 1503 1701 John F. Kennedy Boulevard 1504 Philadelphia, PA 19103 1505 US 1507 Email: michael_oreirdan@cable.comcast.com 1508 URI: http://www.comcast.com