idnits 2.17.1 draft-oreirdan-mody-bot-remediation-09.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 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 (June 6, 2010) is 5073 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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: December 8, 2010 Comcast 6 June 6, 2010 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-09 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 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 December 8, 2010. 44 Copyright Notice 46 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 2. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Introduction and Problem Statement . . . . . . . . . . . . . . 6 76 4. Important Notice of Limitations and Scope . . . . . . . . . . 8 77 5. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Notification to Internet Users . . . . . . . . . . . . . . . . 12 79 7. Remediation of Hosts Infected with a Bot . . . . . . . . . . . 18 80 8. Guided Remediation Process . . . . . . . . . . . . . . . . . . 20 81 9. Professionally-Assisted Remediation Process . . . . . . . . . 21 82 10. Sharing of Data from the User to the ISP . . . . . . . . . . . 22 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 86 14. Informative references . . . . . . . . . . . . . . . . . . . . 24 87 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26 88 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 91 1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Key Terminology 99 This section defines the key terms used in this document. 101 2.1. Malicious Bots, or Bots 103 A malicious or potentially malicious "bot" (derived from the word 104 "robot", hereafter simply referred to as a "bot") refers to a program 105 that is installed on a system in order to enable that system to 106 automatically (or semi-automatically) perform a task or set of tasks 107 typically under the command and control of a remote administrator, or 108 "bot master". Bots are also known as "zombies". Such bots may have 109 been installed surreptitiously, without the user's full understanding 110 of what the bot will do once installed, unknowingly as part of 111 another software installation, under false pretenses, and/or in a 112 variety of other possible ways. 114 It is important to note that there are 'good', or benign bots. Such 115 benign bots are often found in such environments such as gaming and 116 Internet Relay Chat (IRC) [RFC1459], where a continual, interactive 117 presence can be a requirement for participating in the games, 118 interacting with a computing resource. Since such benign bots are 119 performing useful, lawful, and non-disruptive functions, there is no 120 reason for a provider to monitor for their presence and/or alert 121 users to their presence. 123 Thus, while there may be benign, or harmless bots, for the purposes 124 of this document all mention of bots shall assume that the bots 125 involved are malicious or potentially malicious in nature. Such 126 malicious bots shall generally be assumed to have been deployed 127 without the permission or conscious understanding of a particular 128 Internet user. Thus, without a user's knowledge, bots may transform 129 the user's computing device into a platform from which malicious 130 activities can be conducted. In addition, included explicitly in 131 this category are potentially malicious bots, which may initially 132 appear neutral but may simply be waiting for remote instructions to 133 transform and/or otherwise begin engaging in malicious behavior. In 134 general, installation of a malicious bot without user knowledge and 135 consent is considered in most regions to be unlawful, and the 136 activities of malicious bots typically involve unlawful or other 137 maliciously disruptive activities. 139 2.2. Bot Networks, or Botnets 141 These are defined as concerted networks of bots capable of acting on 142 instructions generated remotely. The malicious activities are either 143 focused on the information on the local machine or acting to provide 144 services for remote machines. Bots are highly customizable so they 145 can be programmed to do many things. The major malicious activities 146 include but are not limited to: identity theft, spam, spim (spam over 147 instant messaging), spit (spam over Internet telephony), email 148 address harvesting, distributed denial of service (DDoS) attacks, 149 key-logging, fraudulent DNS pharming (redirection), hosting proxy 150 services, fast flux hosting, hosting of illegal content, use in man- 151 in-the-middle attacks, and click fraud. 153 Infection vectors include un-patched operating systems, software 154 vulnerabilities (which include so-called zero-day vulnerabilities 155 where no patch yet exists), weak/non-existent passwords, malicious 156 websites, un-patched browsers, malware, vulnerable helper 157 applications and social engineering techniques to gain access to the 158 user's computer. The detection and destruction of bots is an ongoing 159 issue and also a constant battle between the internet security 160 community, network security engineers and bot developers. 162 Initially, some bots used IRC to communicate but were easy to 163 shutdown if the command and control server was identified and 164 deactivated. Newer command and control methods have evolved, such 165 that those currently employed by bot masters make them much more 166 resistant to deactivation. With the introduction of P2P, HTTP and 167 other resilient communication protocols along with the widespread 168 adoption of encryption, bots are considerably more difficult to 169 identify and isolate from typical network usage. As a result 170 increased reliance is being placed on anomaly detection and 171 behavioral analysis, both locally and remotely, to identify bots. 173 2.3. Host 175 An end user's host, or computer, as used in the context of this 176 document, is intended to refer to a computing device that connects to 177 the Internet. This encompasses devices used by Internet users such 178 as personal computers, including laptops, desktops, and netbooks, as 179 well as mobile phones, smart phones, home gateway devices, and other 180 end user computing devices which are connected or can connect to the 181 public Internet and/or private IP networks. 183 Increasingly, other household systems and devices contain embedded 184 hosts which are connected to or can connect to the public Internet 185 and/or private IP networks. However, these devices may not be under 186 interactive control of the Internet user, such as may be the case 187 with various smart home and smart grid devices. 189 2.4. Malware 191 This is short for malicious software. In this case, malicious bots 192 are considered a subset of malware. Other forms of malware could 193 include viruses and other similar types of software. Internet users 194 can sometimes cause their host to be infected with malware, which may 195 include a bot or cause a bot to install itself, via inadvertently 196 accessing a specific website, downloading a file, or other 197 activities. 199 In other cases, Internet-connected hosts may become infected with 200 malware through externally initiated malicious activities such as the 201 exploitation of vulnerabilities or the brute force guessing of access 202 credentials. 204 2.5. Fast Flux 206 DNS Fast Fluxing occurs when a domain is bound in DNS using A records 207 to multiple IP addresses, each of which has a very short Time To Live 208 (TTL) value associated with it. This means that the domain resolves 209 to varying IP addresses over a short period of time. 211 DNS Fast Flux is typically used in conjunction with proxies which 212 then route the web requests to the real host which serves the data 213 being sought. The proxies are normally run on compromised user 214 hosts. The effect of this is to make the detection of the real host 215 much more difficult and to ensure that the backend or hidden site 216 remains up for as long as possible. 218 3. Introduction and Problem Statement 220 Hosts used by Internet users, which in this case are customers of an 221 Internet Service Provider (ISP), can be infected with malware which 222 may contain and/or install one or more bots on a host. They can 223 present a major problem for an ISP for a number of reasons (not to 224 mention of course the problems created for users). First, these bots 225 can be used to send spam, in some cases very large volumes of spam 226 [Spamalytics: An Empirical Analysis of Spam Marketing Conversion]. 227 This spam can result in extra cost for the ISPs in terms of wasted 228 network, server, and/or personnel resources, among many other 229 potential costs and side effects. Such spam can also negatively 230 affect the reputation of the ISP, their customers, and the email 231 reputation of the IP address space used by the ISP (often referred to 232 simply as 'IP reputation'). 234 In addition, these bots can act as platforms for directing, 235 participating in, or otherwise conducting attacks on critical 236 Internet infrastructure [Emerging Cyber Threats Report for 2009: 237 Data, Mobility and Questions of Responsibility will Drive Cyber 238 Threats in 2009 and Beyond]. Bots are frequently used as part of 239 coordinated Distributed Denial of Service (DDoS) attacks for 240 criminal, political or other motivations [The Gh0st in the Shell: 241 Network Security in the Himalayas] [The snooping dragon: 242 social-malware surveillance of the Tibetan movement]. For example, 243 bots have been used to attack Internet resources and infrastructure 244 ranging from web sites, to email servers and DNS servers, as well as 245 the critical Internet infrastructure of entire countries [Battling 246 Botnets and Online Mobs: Estonia's Defense Efforts during the 247 Internet War] [Cyberspace as a Combat Zone: The Phenomenon of 248 Electronic Jihad]. Motivations for such coordinated DDoS attacks can 249 range from criminal extortion attempts through to online protesting 250 and nationalistic fervor [Case Study: How a Bookmaker and a Whiz Kid 251 Took On a DDOS-based Online Extortion Attack]. 253 While any computing device can be infected with bots, the majority of 254 bot infections affect the personal computers used by Internet end 255 users. As a result of the role of ISPs in providing IP connectivity, 256 among many other services, to Internet users, these ISPs are in a 257 unique position to be able to attempt to detect and observe bot nets 258 operating in their networks. Furthermore, ISPs may also be in a 259 unique position to be able to notify their customers of actual, 260 potential, or likely infection by bots or other infection. 262 From end users perspective, being notified that they may have an 263 infected computer on their network is important information. Once 264 they know this, they can take steps to remove the bots, resolve any 265 problems which may stem from the bot infection, and protect 266 themselves againts future threats. Given that bots can consume vast 267 amounts of local computing and network resources, enable theft of 268 personal information (including personal financial information), 269 enable the host to be used for criminal activities (that may result 270 in the Internet user being legally culpable), destroy or leave the 271 host in an unrecoverable state via 'kill switch' bot technologies, it 272 is important to notify the user that they may be infected with a bot. 274 As a result, the intent of this document is to provide guidance to 275 ISPs and other organizations for the remediation of hosts infected 276 with bots, so as to reduce the size of bot nets and minimize the 277 potential harm that bots can inflict upon Internet infrastructure 278 generally, as well as on individual Internet users. Efforts by ISPs 279 and other organizations can, over time, reduce the pool of hosts 280 infected with bots on the Internet, which in turn could result in 281 smaller bot nets with less capability for disruption. 283 The potential mitigation of bots is accomplished through a process of 284 detection, notification to Internet users, and remediation of bot 285 infections with a variety of tools, as described later in this 286 document. 288 4. Important Notice of Limitations and Scope 290 The techniques described in this document in no way guarantee the 291 remediation of all bots. Bot removal is potentially a task requiring 292 specialized knowledge, skills and tools, and may be beyond the 293 ability of average users. Attempts at bot removal may frequently be 294 unsuccessful, or only partially successful, leaving the user's system 295 in an unstable and unsatisfactory state or even in a state where it 296 is still infected. Attempts at bot removal can result in side 297 effects ranging from a loss of data to partial or complete loss of 298 system usability. 300 In general, the only way a user can be sure they have removed some of 301 today's increasingly sophisticated malware is by 'nuking-and-paving' 302 the system: reformatting the drive, reinstalling the operating system 303 and applications (including all patches) from scratch, and then 304 restoring user files from a known clean backup. However the 305 introduction of persistent memory based malware may mean that, in 306 some cases, this may not be enough and may prove to be more than any 307 end user can be reasonably expected to resolve [Persistent Memory 308 Infection]. Experienced users would have to re-flash or re-image 309 persistent memory sections or components of their hosts in order to 310 remove persistent memory based malware. However, in some cases, not 311 even 'nuking-and-paving' the system will solve the problem, which 312 calls for hard drive replacement and/or complete replacement of the 313 host. 315 Devices with embedded operating systems, such as video gaming 316 consoles and smart home appliances, will most likely be beyond a 317 user's capability to remediate by themselves, and could therefore 318 require the aid of vendor-specific advice, updates and tools. 319 However, in some cases, such devices will have a function or switch 320 to enable the user to reset that device to a factory default 321 configuration, which may in some cases enable the user to remediate 322 the infection. Care must be taken when imparting remediation advice 323 to Internet users given the increasingly wide array of computing 324 devices that can be, or could be, infected by bots in the future. 326 5. Detection of Bots 328 An ISP must first identify that an Internet user, in this case a user 329 that is assumed to be their customer or otherwise connected to the 330 ISP's network, is determined to be infected, or likely to have been 331 infected with a bot. The ISP must attempt to detect the presence of 332 bots using methods, processes, and tools which maintain the privacy 333 of the personally identifiable information (PII) of their customers. 334 The ISP must not block legitimate traffic in the course of bot 335 detection, and must instead employ detection methods, tools, and 336 processes which seek to be non-disruptive, and transparent to 337 Internet users and end-user applications. 339 Detection methods, tools, and processes may include analysis of 340 specific network and/or application traffic flows (such as traffic to 341 an email server), analysis of aggregate network and/or application 342 traffic data, data feeds received from other ISPs and organizations 343 (such as lists of the ISP's IP addresses which have been reported to 344 have sent spam), feedback from the ISP's customers or other Internet 345 users, as well as a wide variety of other possibilities. In 346 practice, it has proven effective to validate a bot infect through 347 the use of a combination of multiple bot detection data points. This 348 can help to corroborate information of varying dependability or 349 consistency, as well as to avoid or minimize the possibility of false 350 positive identification of hosts. Detection should also, where 351 possible and feasible, attempt to classify the specific bot infection 352 type in order to confirm that it is malicious in nature, estimate the 353 variety and severity of threats it may pose (such as spam bot, key- 354 logging bot, file distribution bot, etc.), and to determine potential 355 methods for eventual remediation. However, given the dynamic nature 356 of botnet management and the criminal incentives to seek quick 357 financial rewards, botnets frequently update or change their core 358 capabilities. As a consequence, botnets that are initially detected 359 and classified by the ISP as one particular type of bot need to be 360 continuously monitored and tracked in order to correctly identify the 361 threat the botnet poses at any particular point in time. 363 Detection is also time-sensitive. If complex analysis is required 364 and multiple confirmations are needed to verify a bot is indeed 365 present, then it is possible that the bot may cause some damage (to 366 either the infected host or a remotely targeted system) before it can 367 be stopped. This means that an ISP needs to balance the desire or 368 need to definitively classify and/or confirm the presence of a bot, 369 which may take an extended period of time, with the ability to 370 predict the likelihood of a bot in a very short period of time. Such 371 determinations have a relatively low false positive rate in order to 372 maintain the trust of users. This 'definitive-vs-likely' challenge 373 is difficult and, when in doubt, ISPs should err on the side of 374 caution by communicating that a bot infection has taken place. This 375 also means that Internet users may benefit from the installation of 376 client-based software on their host. This can enable rapid 377 performance of heuristically-based detection of bot activity, such as 378 the detection of a bot as it starts to communicate with other botnets 379 and execute commands. Any bot detection system should also be 380 capable of adapting, either via manual intervention or automatically, 381 in order to cope with a rapidly evolving threat. 383 As noted above, detection methods, tools, and processes should ensure 384 that privacy of customers' PII is maintained. While bot detection 385 methods, tools, and processes are similar to spam and virus defenses 386 deployed by the ISP for the benefit of their customers (and may be 387 directly related to those defenses), attempts to detect bots should 388 take into account the need of an ISP to take care to ensure any PII 389 collected or incidentally detected is properly protected. This is 390 important, as just as spam defenses may involve scanning the content 391 of email messages, which may contain PII, then so to may bot defenses 392 similarly come into incidental contact with PII. The definition of 393 PII varies from one jurisdiction to the next so proper care must be 394 taken to ensure that any actions taken comply with legislation and 395 good practice in the jurisdiction in which the PII is gathered. 396 Finally, depending upon the geographic region within which an ISP 397 operates, certain methods relating to bot detection may need to be 398 included in relevant terms of service documents or other documents 399 which are available to the customers of a particular ISP. 401 There are several bot detection methods, tools, and processes that an 402 ISP may choose to utilize, as noted in the list below. It is 403 important to note that the technical solutions available are 404 relatively immature, and are likely to change over time, evolving 405 rapidly in the coming years. While these items are described in 406 relation to ISPs, they may also be applicable to organizations 407 operating other networks, such as campus networks and enterprise 408 networks. 410 a. Where legally permissible or otherwise an industry accepted 411 practice in a particular market region, an ISP may in some manner 412 "scan" their IP space in order to detect un-patched or otherwise 413 vulnerable hosts, or to detect the signs of infection. This may 414 provide the ISP with the opportunity to easily identify Internet 415 users who appear to already be infected or are at great risk of 416 being infected with a bot. ISPs should note that some types of 417 port scanning may leave network services in a hung state or 418 render them unusable due to common frailties, and that many 419 modern firewall and host-based intrusion detection 420 implementations may alert the Internet user to the scan. As a 421 result the scan may be interpreted as a malicious attack against 422 the host. Vulnerability scanning has a higher probability of 423 leaving accessible network services and applications in a damaged 424 state and will often result in a higher probability of detection 425 by the Internet user and subsequent interpretation as a targeted 426 attack. Depending upon the vulnerability for which an ISP may be 427 scanning, some automated methods of vulnerability checking may 428 result in data being altered or created afresh on the Internet 429 user's host which can be a problem in many legal environments. 430 It should also be noted that due to the prevalence of Network 431 Address Translation devices, Port Address Translation devices, 432 and/or firewall devices in user networks, network-based 433 vulnerability scanning may be of limited value. Thus, while we 434 note that this is one technique which may be utilized, it is 435 unlikely to be particularly effective and it has problematic side 436 effects, which leads the authors to recommend against the use of 437 this particular method. 439 b. An ISP may also communicate and share selected data, via feedback 440 loops or other mechanisms, with various third parties. Feedback 441 loops are consistently formatted feeds of real-time (or nearly 442 real-time) abuse reports offered by threat data clearinghouses, 443 security alert organizations, other ISPs, and other 444 organizations. The data may include, but is not limited to, IP 445 addresses of hosts which have or are likely infected, IP 446 addresses, domain names or fully qualified domain names (FQDNs) 447 known to host malware and/or be involved in the command and 448 control of botnets, recently tested or discovered techniques for 449 detecting or remediating bot infections, new threat vectors, and 450 other relevant information. A few good examples of data sharing 451 include SNDS from Microsoft, XBL and PBL from Spamhaus, the 452 DSHIELD AS tool from the SANS Institute. 454 c. An ISP may use Netflow [RFC3954] or other similar passive network 455 monitoring to identify network anomalies that may be indicative 456 of botnet attacks or bot communications. For example, an ISP may 457 be able to identify compromised hosts by identifying traffic 458 destined to IP addresses associated with the command and control 459 of botnets, or destined to the combination of an IP address and 460 control port associated with a command and control network 461 (sometimes command and control traffic comes from a host which 462 has legitimate traffic). In addition, bots may be identified 463 when a remote host is under a DDoS attack, because hosts 464 participating in the attack will likely be infected by a bot, 465 frequently as observed at network borders (though ISPs should 466 beware of source IP address spoofing techniques to avoid or 467 confuse detection). 469 d. An ISP may use DNS-based techniques to perform detection. For 470 example, a given classified bot may be known to query a specific 471 list of domain names at specific times or on specific dates (in 472 the example of the so-called "Conficker" bot), often by matching 473 DNS queries to a well known list of domains associated with 474 malware. In many cases such lists are distributed by or shared 475 using third parties, such as threat data 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) can be placed in a Walled Garden and 506 used to analyze end user traffic to confirm malware type. This 507 will help with remediation of the infected device. 509 6. 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, from 514 the technical capabilities of the ISP, to the technical attributes of 515 their 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 following, as well as other possible 522 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 or a timely basis, 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 as 537 allows any commonly used bot detection technology to be able to 538 accurately link an infected IP address to a subscriber. This record 539 should only be maintained for a period of time which is necessary, in 540 order to maintain the protection of the privacy of an individual 541 subscriber. 543 One important factor to bear in mind is that notification to end 544 users needs to be resistant to potential spoofing. This must be done 545 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 6.1. Email Notification 552 This is a common form of notification used by ISPs. One drawback of 553 using email is that it is not guaranteed to be viewed within a 554 reasonable time frame, if at all. The user may be using a different 555 primary email address than that which they have provided to the ISP. 556 In addition, some ISPs do not provide an email account at all, as 557 part of a bundle of Internet services, and/or do not have a need for 558 or method in which to request or retain the primary email addresses 559 of Internet users of their networks. Another possibility is that the 560 user, their email client, and/or their email servers could determine 561 or classify such a notification as spam, which could delete the 562 message or otherwise file it in an email folder that the user may not 563 check on a regular and/or timely basis. Bot masters have also been 564 known to impersonate the ISP or trusted sender and send fraudulent 565 emails to the users. This technique of social engineering often 566 leads to new bot infestations. Finally if the user's email 567 credentials are compromised, then a hacker and/or a bot could simply 568 access the user's email account and delete the email before it is 569 read by the user. 571 6.2. Telephone Call Notification 573 A telephone call may be an effective means of communication in 574 particularly high-risk situations. However, telephone calls may not 575 be feasible due to the cost of making a large number of calls, as 576 measured in either time, money, organizational resources, server 577 resources, or some other means. In addition, there is no guarantee 578 that the user will answer their phone. To the extent that the 579 telephone number called by the ISP can be answered by the infected 580 computing device, the bot on that host may be able to disconnect, 581 divert, or otherwise interfere with an incoming call. Users may also 582 interpret such a telephone notification as a telemarketing call and 583 as such not welcome it, or not accept the call at all. Finally, even 584 if a representative of the ISP is able to connect with and speak to a 585 user, that user is very likely to lack the necessary technical 586 expertise to understand or be able to effectively deal with the 587 threat. 589 6.3. Postal Mail Notification 591 This form of notification is probably the least popular and effective 592 means of communication, due to both preparation time, delivery time, 593 the cost of printing and paper, and the cost of postage. 595 6.4. Walled Garden Notification 597 Placing a user in a walled garden is another approach that ISPs may 598 take to notify users. A walled garden refers to an environment that 599 controls the information and services that a subscriber is allowed to 600 utilize and what network access permissions are granted. A walled 601 garden implementation can range from strict to leaky. In a strict 602 walled garden environment access to most Internet resources are 603 typically limited by the ISP. In contrast a leaky walled garden 604 environment permits access to all Internet resources except those 605 deemed malicious or service and resources that can be used to notify 606 the users. 608 Walled gardens are effective because it is possible to notify the 609 user and simultaneously block all communication between the bot and 610 the command and control channel. While in many cases the user is 611 almost guaranteed to view the notification message and take any 612 appropriate remediation actions, this approach can pose other 613 challenges. For example, it is not always the case that a user is 614 actively using a host that uses a web browser or which has a web 615 browser actively running on it, or that uses another application 616 which uses ports which are redirected to the walled garden. In one 617 example, a user could be playing a game online, via the use of a 618 dedicated, Internet-connected game console. In another example, the 619 user may not be using a host with a web browser when they are placed 620 in the walled garden and may instead be in the course of a telephone 621 conversation, or may be expecting to receive a call, using a Voice 622 Over IP (VoIP) device of some type. As a result, the ISP may feel 623 the need to maintain a potentially lengthy white list of domains 624 which are not subject to the typical restrictions of a walled garden, 625 which could well prove to be an onerous task, from an operational 626 perspective. 628 For these reasons the implementation of a leaky walled garden makes 629 more sense but a leaky walled garden has different set of drawbacks. 630 The ISP has to assume that the user will eventually use a web browser 631 to acknowledge the notification other wise the user will remain in 632 the walled garden and not know it. If the intent of the leaky walled 633 garden is to solely notify the user about the bot infection then the 634 leaky walled garden is not ideal because notification is time 635 sensitive and the user may not receive the notification until the 636 user invokes a request for the targeted service and/or resource. 637 This means the bot can potentially do more damage. Additionally, the 638 ISP has to identify which services and/or resources to restrict for 639 the purposes of notification. This does not have to be resource 640 specific and can be time based and or policy based. For example show 641 notification for all HTTP requests every 10 minutes or show the 642 notification for one in five HTTP requests. 644 The ISP has several options to determine when to let the user out of 645 the walled garden. One approach may be to let the user determine 646 when to exit. This option is suggested when the primary purpose of 647 the walled garden is to notify users and provide information on 648 remediation only, particularly since notification is not a guarantee 649 of successful remediation. It could also be the case that, for 650 whatever reason, the user makes the judgment that they cannot then 651 take the time to remediate their host and that other online 652 activities which they would like to resume are more important. Exit 653 from the walled garden may also involve a process to verify that it 654 is indeed the user who is requesting exit from the walled garden and 655 not the bot. 657 Once the user acknowledges the notification, they may decide to 658 either remediate and exit the walled garden or to exit the walled 659 garden without remediating the issue. Another approach may be to 660 enforce a stricter policy and require the user to clean the host 661 prior to permitting the user to exit the walled garden, though this 662 may not be technically feasible depending upon the type of bot, 663 obfuscation techniques employed by a bot, and/or a range of other 664 factors. Thus, the ISP may also need to support tools to scan the 665 infected host (in the style of a virus scan, rather than a port scan) 666 and determine whether it is still infected or rely on user judgment 667 that the bot has been disabled or removed. One challenge with this 668 approach is that if the user has multiple hosts sharing a single IP 669 address, such as via a common home gateway device which performs 670 Network Address Translation (NAT). In such a case, the ISP may need 671 to determine from user feedback, or other means, that all affected 672 hosts have been remediated, which may or may not be technically 673 feasible. 675 Finally, when a walled garden is used, a list of well-known addresses 676 for both operating system vendors and security vendors should be 677 created and maintained in a white list which permits access to these 678 sites. This can be important for allowing access from the walled 679 garden by end users in search of operating system and application 680 patches. 682 6.5. Instant Message Notification 684 Instant messaging provides the ISP with a simple means to communicate 685 with the user. There are several advantages to using Instant 686 Messaging (IM) which makes it an attractive option. If the ISP 687 provides IM service and the user subscribes to it, then the user can 688 be notified easily. IM-based notification can be a cost effective 689 means to communicate with users automatically from an IM alert system 690 or via a manual process, by the ISP's support staff. Ideally, the 691 ISP should allow the user to register their IM identity in an ISP 692 account management system and grant permission to be contacted via 693 this means. If the IM service provider supports off-line messaging, 694 then the user can be notified regardless of whether they are 695 currently logged into the IM system. 697 There are several drawbacks with this communications method. There 698 is a high probability that subscriber may interpret the communication 699 to be spim, and as such ignore it. Also, not every user uses IM 700 and/or the user may not provide their IM identity to the ISP so some 701 alternative means have to be used. Even in those cases where a user 702 does have an IM address, they may not be signed onto that IM system 703 when the notification is attempted. There may be a privacy concern 704 on the part of users, when such an IM notification must be 705 transmitted over a third-party network and/or IM service. As such, 706 should this method be used, the notification should be discreet and 707 not include any PII in the notification itself. 709 6.6. Short Message Service (SMS) Notification 711 SMS allows the ISP send a brief description of the problem to notify 712 the user of the issue, typically to a mobile device such as a mobile 713 phone or smart phone. Ideally, the ISP should allow the user to 714 register their mobile number and/or SMS address in an ISP account 715 management system and grant permission to be contacted via this 716 means. The primary advantage of SMS is that users are familiar with 717 receiving text messages and are likely to read them. However, users 718 may not act on the notification immediately if they are not in front 719 of their host at the time of the SMS notification. 721 One disadvantage is that ISPs may have to follow up with an alternate 722 means of notification if not all of the necessary information maybe 723 conveyed in one message, given constraints on the number of 724 characters in an individual message (typically 140 characters). 725 Another disadvantage with SMS is the cost associated with it. The 726 ISP has to either build its own SMS gateway to interface with the 727 various wireless network service providers or use a third-party SMS 728 clearinghouse (relay) to notify users. In both cases an ISP may 729 incur fees related to SMS notifications, depending upon the method 730 used to send the notifications. An additional downside is that SMS 731 messages sent to a user may result in a charge to the user by their 732 wireless provider, depending upon the plan to which they subscribe. 733 Another minor disadvantage is that it is possible to notify the wrong 734 user if the intended user changes their mobile number but forgets to 735 update it with the ISP. 737 There are several other drawbacks with this communications method. 738 There is a high probability that subscriber may interpret the 739 communication to be spam, and as such ignore it. Also, not every 740 user uses SMS and/or the user may not provide their SMS address or 741 mobile number to the ISP. Even in those cases where a user does have 742 an SMS address or mobile number, their device may not be powered on 743 or otherwise available on a wireless network when the notification is 744 attempted. There maybe also be a privacy concern on the part of 745 users, when such an SMS notification must be transmitted over a 746 third-party network and/or SMS clearinghouse. As such, should this 747 method be used, the notification should be discreet and not include 748 any PII in the notification itself. 750 6.7. Web Browser Notification 752 Near real-time notification to the user's web browser is another 753 technique that may be utilized for notifying the user, though how 754 such a system might operate is outside the scope of this document. 755 Such a notification could have a comparative advantage over a walled 756 garden notification, in that it does not restrict traffic to a 757 specified list of destinations in the same way that a walled garden 758 by definition would. However, as with a walled garden notification, 759 there is no guarantee that a user is at any given time making use of 760 a web browser, though such a system could certainly provide a 761 notification when such a browser is eventually used. Compared to a 762 walled garden, a web browser notification is probably preferred from 763 the perspective of Internet users, as it does not have the risk of 764 disrupting non-web sessions, such as online games, VoIP calls, etc. 765 (as noted in Section 6.4). 767 6.8. Considerations for Notification to Public Network Locations 769 Delivering a notification to a location that provides a shared public 770 network, such as a train station, public square, coffee shop, or 771 similar location may be of low value since the users connecting to 772 such networks are typically highly transient and generally not know 773 to site or network administrators. For example, a system may detect 774 that a host on such a network has a bot, but by the time a 775 notification is generated that user has departed from the network and 776 moved elsewhere. 778 6.9. Considerations for Notification to Network Locations Using a 779 Shared IP Address 781 Delivering a notification to a location that Internet access routed 782 through one or more shared public IP addresses may be of low value 783 since it may be quite difficult to differentiate between users when 784 providing a notification. For example, on a business network of 500 785 users, all sharing one public IP address, it may be sub-optimal to 786 provide a notification to all 500 users if you only need one specific 787 user to be notified and take action. As a result, such networks may 788 find value in establishing a localized bot detection and notification 789 system, just as they are likely to also establish other localized 790 systems for security, file sharing, email, and so on. 792 However, should an ISP implement some form of notification to such 793 networks, it may be better to simply send notifications to a 794 designated network administrator at the site. In such a case the 795 local network administrator may like to receive additional 796 information in such a notification, such as a date and timestamp, the 797 source port of the infected system, and malicious sites and ports 798 that may have been visited. 800 7. Remediation of Hosts Infected with a Bot 802 This section covers the different options available to remediate a 803 host, which means to remove, disable, or otherwise render a bot 804 harmless. Prior to this step, an ISP has detected the bot, notified 805 the user that one of their hosts is infected with a bot, and now may 806 provide some recommended means to clean the host. The generally 807 recommended approach is to provide the necessary tools and education 808 to the user so that they may perform bot remediation themselves, 809 particularly given the risks and difficulties inherent in attempting 810 to remove a bot. 812 For example, this may include the creation of a special web site with 813 security-oriented content that is dedicated for this purpose. This 814 should be a well-publicized security web site to which a user with a 815 bot infection can be directed to for remediation. This security web 816 site should clearly explain why the user was notified and may include 817 an explanation of what bots are, and the threats that they pose. 818 There should be a clear explanation of the steps that the user should 819 take in order to attempt to clean their host and provide information 820 on how users can keep the host free of future infections. The 821 security web site should also have a guided process that takes non- 822 technical users through the remediation process, on an easily 823 understood, step-by-step basis. 825 In terms of the text used to explain what bots are and the threats 826 that they pose, something simple such as this may suffice: 828 "What is a bot? A bot is a piece of software, generally 829 installed on your machine without your knowledge, which either 830 sends spam or tries to steal your personal information. They 831 can be very difficult to spot, though you may have noticed that 832 your computer is running much more slowly than usual or you 833 notice regular disk activity even when you are not doing 834 anything. Ignoring this problem is risky to you and your 835 personal information. Thus, bots need to be removed to protect 836 your data and your personal information." 838 It is also important to note that it may not be immediately apparent 839 to the Internet user precisely which devices have been infected with 840 a particular bot. This may be due to the user's home network 841 configuration, which may encompass several hosts, where a home 842 gateway which performs Network Address Translation (NAT) to share a 843 single public IP address has been used. Therefore, any of these 844 devices can be infected with a bot. The consequence of this for an 845 ISP is that remediation advice may not ultimately be immediately 846 actionable by the Internet user, as that user may need to perform 847 additional investigation within their own home network. 849 An added complication is that the user may have a bot infection on a 850 device such as a video console, multimedia system, appliance, or 851 other end-user computing device which does not have a typical Windows 852 or Macintosh user interface. As a result, diligence needs to be 853 taken by the ISP where possible such that they can identify and 854 communicate the specific nature of the device that has been infected 855 with a bot, and further providing appropriate remediation advice. 857 There are a number of forums that exist online to provide security 858 related support to end users. These forums are staffed by volunteers 859 and often are focussed around the use of a common tool set to help 860 end users to remediate hosts infected with malware. It may be 861 advantageous to ISPs to foster a relationship with one or more 862 forums, perhaps by offering free hosting or other forms of 863 sponsorship. 865 8. Guided Remediation Process 867 Minimally the Guided Remediation Process should include options 868 and/or recommendations on how a user should: 870 1. Backup personal Documents, for example: "Before you start, make 871 sure to back up all of your important data. (You should do this 872 on a regular basis anyway.) You can back up your files manually 873 or using a system back-up software utility, which may be part of 874 your Operating System (OS). You can back your files up to a USB 875 Thumb Drive (aka USB Key), a writeable CD/DVD-ROM, an external 876 hard drive, or a network file server." 878 2. Download OS patches and Anti-Virus (A/V) software updates. For 879 example, links could be provided to Microsoft Windows updates at 880 http://update.microsoft.com/microsoftupdate/v6/ 881 default.aspx?ln=en-us as well as to Apple MacOS updates at 882 http://support.apple.com/kb/HT1338?viewlocale=en_US. 884 3. Explain how to configure the host to automatically install 885 updates for the OS, A/V and other common Web Browsers such as 886 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 887 Opera, and Google Chrome. 889 4. The flow should also have the option for users to get 890 professional assistance if they are unable to remove the bots 891 themselves. If purchasing professional assistance, then the user 892 should be encouraged to pre-determine how much they are willing 893 to pay for that help. If the host that is being remediated is 894 old and can easily be replaced with a new, faster, larger and 895 more reliable system for three or four hundred dollars, the it 896 makes no sense to spend five or six hundred dollars to fix the 897 old host, for example. On the other hand, if the customer has a 898 brand new host that cost several thousand dollars, it might make 899 perfect sense to spend the money in attempting to remediate it. 901 5. To continue, regardless of whether the user or a knowledgeable 902 technical assistant is working on remediating the host, their 903 first task should be to determine which of multiple potentially- 904 infected machines may be the one that needs attention (in the 905 common case of multiple hosts in a home network). Sometimes, as 906 in cases where there is only a single directly-attached host, or 907 the user has been noticing problems with one of their hosts, this 908 can be easy. Other times, it may be more difficult especially if 909 there are no clues as to which host is infected. If the user is 910 behind a home gateway/router, then the first task may be to 911 ascertain which of the machines is infected. In some cases the 912 user may have to check all machines to identify the infected one. 914 6. User surveys to solicit feedback on whether the notification and 915 remediation process is effective and what recommended changes 916 could be made in order to improve the ease, understandability, 917 and effectiveness the remediation process. 919 7. If the user is interested in reporting his or her host's bot 920 infection to an applicable law enforcement authority, then the 921 host effectively becomes a cyber "crime scene" and should not be 922 mitigated unless or until law enforcement has collected the 923 necessary evidence. For individuals in this situation, the ISP 924 should refer them to local, state, federal, or other relevant 925 computer crime offices. (Note: Some "minor" incidents, even if 926 highly traumatic to the user, may not be sufficiently serious for 927 law enforcement to commit some of their limited resources to an 928 investigation.) In addition, individual regions may have other, 929 specialized computer crime organizations to which these incidents 930 can be reported. For example, in the United States, that 931 organization is the Internet Crime Complaint Center, at 932 http://www.ic3.gov. 934 8. Users may also be interested in links to security expert forums, 935 where other users can assist them. 937 9. Professionally-Assisted Remediation Process 939 It should be acknowledged that, based on the current state of 940 remediation tools and the technical abilities of end users, that many 941 users may be unable to remediate on their own. As a result, it is 942 recommended that users have the option for professional assistance. 943 This may entail online or telephone assistance for remediation, as 944 well as working face to face with a professional who has training and 945 expertise in the removal of malware. 947 10. Sharing of Data from the User to the ISP 949 As an additional consideration, it may be useful to create a process 950 by which users could choose, at their option and with their express 951 consent, to share data regarding their bot infection with their ISP 952 and/or another authorized third party. Such third parties may 953 include governmental entities that aggregate threat data, such as the 954 Internet Crime Complaint Center referred to earlier in this document, 955 to academic institutions, and/or security researchers. While in many 956 cases the information shared with the user's ISP or designated third 957 parties will only be used for aggregated statistical analysis, it is 958 also possible that certain research needs may be best met with more 959 detailed data. Thus, any such data sharing from a user to the ISP or 960 authorized third party may contain some type of personally 961 identifiable information, either by design or inadvertently. As a 962 result, any such data sharing must be enabled on an opt-in based, 963 where users review and approve of the data being shared and the 964 parties with which it is to be shared, unless the ISP is already 965 required to share such data in order to comply with local laws and in 966 accordance with those laws and applicable regulations. 968 11. Security Considerations 970 This document describes in detail the numerous security risks and 971 concerns relating to bot nets. As such, it has been appropriate to 972 include specific information about security in each section above. 973 This document describes the security risks related to malicious bot 974 infections themselves, such as enabling identity theft, theft of 975 authentication credentials, and the use of a host to unwittingly 976 participate in a DDoS attack, among many other risks. This document 977 also describes at a high level the activities that ISPs should be 978 sensitive to, where the collection or communication of PII may be 979 possible. Finally, the document also describes security risks which 980 may relate to the particular methods of communicating a notification 981 to Internet users. Bot networks and bot infections pose extremely 982 serious security risks and any reader should review this document 983 carefully. 985 In addition, regarding notifications, as described in Section 6, care 986 should be taken to assure users that notifications have been provided 987 by a trustworthy site and/or party, so that the notification is more 988 difficult for phishers and/or malicious parties using social 989 engineering tactics to mimic, or that the user has some level of 990 trust that the notification is valid, and/or that the user has some 991 way to verify via some other mechanism or step that the notification 992 is valid. 994 As noted in Section 10, any sharing of data from the user to the ISP 995 and/or authorized third parties must be done on an opt-in basis. 996 Additionally the ISP and or authorized third parties must clearly 997 state what data will be shared and with whom the data will be shared 998 with. 1000 Lastly, as noted in some other sections, there my be legal 1001 requirements in particular legal jurisdictions concerning how long 1002 any subscriber-related or other data is retained, of which an ISP 1003 operating in such a jurisdiction must be aware and with which an ISP 1004 must comply. 1006 12. IANA Considerations 1008 There are no IANA considerations in this document. 1010 13. Acknowledgements 1012 The authors wish to acknowledge the following individuals for 1013 performing a detailed review of this document and/or providing 1014 comments and feedback with had helped to improve and evolve this 1015 document: 1017 Mark Baugher 1019 Richard Bennett 1021 James Butler 1023 Vint Cerf 1025 Alissa Cooper 1027 Jonathan Curtis 1029 Jeff Chan 1031 Roland Dobbins 1033 Dave Farber 1035 Eliot Gillum 1037 Joel Halpern 1039 Joel Jaeggli 1040 Scott Keoseyan 1042 The Messaging Anti-Abuse Working Group (MAAWG) 1044 Jose Nazario 1046 Gunter Ollmann 1048 David Reed 1050 Roger Safian 1052 Donald Smith 1054 Joe Stewart 1056 Forrest Swick 1058 Sean Turner 1060 Robb Topolski 1062 Eric Ziegast 1064 14. Informative references 1066 [Battling Botnets and Online Mobs: Estonia's Defense Efforts during 1067 the Internet War] 1068 Evron, G., "Battling Botnets and Online Mobs: Estonia's 1069 Defense Efforts during the Internet War", May 2005, . 1075 [Case Study: How a Bookmaker and a Whiz Kid Took On a DDOS-based 1076 Online Extortion Attack] 1077 Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid 1078 Took On a DDOS-based Online Extortion Attack", May 2005, < 1079 http://www.csoonline.com/article/220336/ 1080 How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online 1081 _Extortion_Attack>. 1083 [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad] 1084 Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon 1085 of Electronic Jihad", February 2007, . 1088 [Distributed Denial of Service Attacks: Explanation, Classification 1089 and Suggested Solutions] 1090 Saafan, A., "Distributed Denial of Service Attacks: 1091 Explanation, Classification and Suggested Solutions", 1092 March 2009, . 1096 [Emerging Cyber Threats Report for 2009: Data, Mobility and Questions 1097 of Responsibility will Drive Cyber Threats in 2009 and Beyond] 1098 Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., 1099 Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., 1100 Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber 1101 Threats Report for 2009: Data, Mobility and Questions of 1102 Responsibility will Drive Cyber Threats in 2009 and 1103 Beyond", October 2008, . 1106 [Persistent Memory Infection] 1107 Sacco, A. and A. Ortega, "Persistent BIOS Infection", 1108 March 2009, . 1111 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1112 RFC 1459, May 1993. 1114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", BCP 14, RFC 2119, March 1997. 1117 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1118 FUNCTIONS", RFC 2142, May 1997. 1120 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1121 9", RFC 3954, October 2004. 1123 [Spamalytics: An Empirical Analysis of Spam Marketing Conversion] 1124 Kanich, C., Kreibich, C., Levchenko, K., Enright, B., 1125 Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An 1126 Empirical Analysis of Spam Marketing Conversion", 1127 October 2008, . 1130 [The Gh0st in the Shell: Network Security in the Himalayas] 1131 Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st 1132 in the Shell: Network Security in the Himalayas", 1133 February 2010, . 1136 [The snooping dragon: social-malware surveillance of the Tibetan 1137 movement] 1138 Nagaraja, S. and R. Anderson, "The snooping dragon: 1139 social-malware surveillance of the Tibetan movement", 1140 March 2009, 1141 . 1143 Appendix A. Document Change Log 1145 [RFC Editor: This section is to be removed before publication] 1147 -09 version: 1149 o Corrected nits pointed out by Sean 1151 o Removed occurrences of double spacing 1153 o Grammar and spelling corrections in many sections 1155 o Added text for leaky walled garden 1157 -08 version: 1159 o Corrected a reference error in Section 10. 1161 o Added a new informative reference 1163 o Change to Section 5.a., to note additional port scanning 1164 limitations 1166 o Per Joel Jaeggli, change computer to host, to conform to IETF 1167 document norms 1169 o Several other changes suggested by Joel Jaeggli and Donald Smith 1170 on the OPSEC mailing list 1172 o Incorp. other feedback received privately 1174 o Because Jason is so very dedicated, he worked on this revision 1175 while on vacation ;-) 1177 -07 version: 1179 o Corrected various spelling and grammatical errors, pointed out by 1180 additional reviewers. Also added a section on information flowing 1181 from the user. Lastly, updated the reviewer list to include all 1182 those who either were kind enough to review for us or who provided 1183 interesting, insightful, and/or helpful feedback. 1185 -06 version: 1187 o Corrected an error in the version change log, and added some extra 1188 information on user remediation. Also added an informational 1189 reference to BIOS infection. 1191 -05 version: 1193 o Minor tweaks made by Jason - ready for wider review and next 1194 steps. Also cleared open issues. Lastly, added 2nd paragraph to 1195 security section and added sections on limitations relating to 1196 public and other shared network sites. Added a new section on 1197 professional remediation. 1199 -04 version: 1201 o Updated reference to BIOS based malware, added wording on PII and 1202 local jurisdictions, added suggestion that industry body produce 1203 bot stats, added suggestion that ISPs use volunteer forums 1205 -03 version: 1207 o all updates from Jason - now ready for wider external review 1209 -02 version: 1211 o all updates from Jason - still some open issues but we're now at a 1212 place where we can solicit more external feedback 1214 -01 version: 1216 o -01 version published 1218 Appendix B. Open Issues 1220 [RFC Editor: This section is to be removed before publication] 1222 per Donald, where SNDS is mentioned: That is a list of good examples 1223 but there are a lot of other good 3rd party infected client 1224 notification resources. Arbor via atlas, ShadowServer, Cymru, SIE, 1225 Support Intelligence and many others. It might be worth having a 1226 seperate section near the end that has a list of 3rd parties that are 1227 willing to share this kind of information with ISPs and provide 1228 contact info such as was done for conficker. http:// 1229 www.confickerworkinggroup.org/wiki/pmwiki.php/SP/ServiceProviders 1230 That list is NOT complete in any sense of the word. Providing 1231 contact information may help other ISPs get a more complete set of 1232 third party reports. I am a bit concerned that some of the 3rd party 1233 contact information could change later and be outdated but I believe 1234 most of them will use a role based email account or a link. 1236 per Sean, There is no RFC 2119 language in the document. Was this 1237 intentional? If it is then we could delete section 1. If it's not 1238 then you'll need to figure out which "must", "should", etc. need to 1239 be capitalized. 1241 per Donald, in notification method section, consider taking this text 1242 from the phone method and using as a new section with drawbacks/ 1243 challenges: Finally, even if a representative of the ISP is able to 1244 connect with and speak to a user, that user is very likely to lack 1245 the necessary technical expertise to understand or be able to 1246 effectively deal with the threat. 1248 per Donald, consider w/r/t the WG method: That is really the 1249 definition of a quarantine walled garden. Walled garden's don't have 1250 to quarantine the user (much) to notify the customer. They can be 1251 fairly leaky and still notify the customer of their infection. 1253 per Donald, consider text re users who continue to fail to mitigate: 1254 Another good approach is just to keep track of whom was put into the 1255 walled garden for which infection and if they keep showing up as 1256 infected via the trusted third party reports then you can assume they 1257 are unable/unwilling to remediate and take what ever additional 1258 actions you deem appropriate. 1260 per Donald, inclusion of PII is a good general stmt to consider for 1261 an opening section in the notification part of the doc: As such, 1262 should this method be used, the notification should be discreet and 1263 not include any PII in the notification itself. 1265 per Donald, do we want to consider adding a 'leaky' WG? 'Or design a 1266 leaky walled garden that allows most traffic without interference 1267 only redirecting the traffic needed to mitigate or notify.' 1269 Address suggestion from Donald Smith: The risks to users of infected 1270 systems and others are included/defined in many places within this 1271 document. It should probably be defined clearly in one place and 1272 referenced in all other places. 1274 per Roger - ponder acct termination 1276 A question has been raised about whether this should change from 1277 Informational to BCP. 1279 Guided remediation -- these urls while provided for the purpose of 1280 examples are unlikely to be stable on any kind of long timescale. 1281 fundamentally updating os software addresses vulnerability not 1282 remediation (windows malicious software removal tool notwithstanding) 1284 Guided remediation, bullets 4 - 7 -- It's unclear how these steps are 1285 even feasible to undertake for organizations nominally characterized 1286 as ISPs. there's a several thousand fold cost differential between 1287 automated help and remediation by sending a train professional to lay 1288 hands on one computer. 1290 Authors' Addresses 1292 Jason Livingood 1293 Comcast Cable Communications 1294 One Comcast Center 1295 1701 John F. Kennedy Boulevard 1296 Philadelphia, PA 19103 1297 US 1299 Email: jason_livingood@cable.comcast.com 1300 URI: http://www.comcast.com 1302 Nirmal Mody 1303 Comcast Cable Communications 1304 One Comcast Center 1305 1701 John F. Kennedy Boulevard 1306 Philadelphia, PA 19103 1307 US 1309 Email: nirmal_mody@cable.comcast.com 1310 URI: http://www.comcast.com 1312 Mike O'Reirdan 1313 Comcast Cable Communications 1314 One Comcast Center 1315 1701 John F. Kennedy Boulevard 1316 Philadelphia, PA 19103 1317 US 1319 Email: michael_oreirdan@cable.comcast.com 1320 URI: http://www.comcast.com