One document matched: draft-oreirdan-mody-bot-remediation-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC1459 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1459.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2142 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2142.xml">
<!ENTITY RFC3667 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3667.xml">
<!ENTITY RFC3954 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3954.xml">
]>
<!-- ADD BACK ONCE I-D POSTED rfc include="reference.I-D.draft-livingood-web-notification-00 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc category="info" docName="draft-oreirdan-mody-bot-remediation-02" ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: pre5378Trust200902, full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev="Remediation of Bots in ISP Networks">Recommendations for the Remediation of Bots in ISP Networks</title>
<author fullname="Jason Livingood" initials="J." surname="Livingood">
<organization abbrev="Comcast">Comcast Cable
Communications</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author fullname="Nirmal Mody" initials="N." surname="Mody">
<organization abbrev="Comcast">Comcast Cable
Communications</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>nirmal_mody@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author fullname="Mike O'Reirdan" initials="M." surname="O'Reirdan">
<organization abbrev="Comcast">Comcast Cable
Communications</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>michael_oreirdan@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day="11" month="September" year="2009" />
<!-- META-DATA DECLARATIONS -->
<area></area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>Internet Engineering Task Force</workgroup>
<!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<keyword>ISP</keyword>
<keyword>Internet Service Provider</keyword>
<keyword>Bot</keyword>
<keyword>Botnet</keyword>
<keyword>Remediation</keyword>
<keyword>malware</keyword>
<keyword>notification</keyword>
<abstract>
<t>This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. Internet users with infected computers are exposed to risks such as loss of personal data, as well as increased susceptibility to online fraud and/or phishing. Such computers can also become an inadvertent participant in or component of an online crime network, spam network, and/or phishing network, as well as be used as a part of a distributed denial of service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network.</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor="ReqLang" title="Requirements Language" toc="include">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="terms" title="Key Terminology" toc="include">
<t>This section defines the key terms used in this document.</t>
<section title="Malicious Bots, or Bots" toc="exclude">
<t>A malicious "bot" (derived from the word "robot", hereafter simply referred to as a "bot") refers to a program that is surreptitiously installed on a system in order to enable that system to automatically (or semi-automatically) perform a task or set of
tasks typically under the command and control of a remote administrator, or "bot master." Bots are also known as "zombies". It is important to note that there are 'good', or benign bots. Such benign bots are often found in such environments such as gaming and Internet Relay Chat (IRC) <xref target="RFC1459"></xref>, where a continual, interactive presence can be a requirement for participating in the games, interacting with a computing resource, or other purposes.</t>
<t>However, for the purposes of this document, all mention of bots should assume that the bots involved are malicious in nature. Such malicious bots shall generally be assumed to have been deployed without the permission or conscious understanding of a particular Internet user. Thus, without a user's knowledge, bots may transform the user's computing device into a platform from which malicious activities can be conducted.</t>
</section>
<section title="Bot Networks, or Botnets" toc="exclude">
<t>These are defined as concerted networks of bots capable of acting
on instructions generated remotely. The malicious activities are
either focused on the information on the local machine or acting to
provide services for remote machines. Bots are highly customizable so
they can be programmed to do many things. The major malicious
activities include: identity theft, spam, distributed denial of service (DDoS) attacks,
key-logging, fraudulent DNS (pharming), proxy services, fast flux
hosting and click fraud. </t>
<t>Infection vectors include un-patched
operating systems, software vulnerabilities, weak/non-existent
passwords, malicious websites, un-patched browsers, malware,
vulnerable helper applications and social engineering techniques to
gain access to the user's computer. The detection and destruction of
bots is an ongoing issue and also a constant battle between the
internet security community, network security engineers and bot
developers.</t>
<t>Initially, bots used IRC to communicate but were easy to
shutdown if the command and control server was identified and
deactivated. Newer command and control methods have evolved, such that those currently employed by
bot masters make them much more resistant to deactivation. With the
introduction of P2P, HTTP and other resilient communication protocols
along with the widespread adoption of encryption, bots are considerably
more difficult to identify and isolate from typical network usage. As
a result increased reliance is being placed on anonmaly detection and
behavioral analysis, both locally and remotely, to identify bots.</t>
</section>
<section title="Computer" toc="exclude">
<t>A computer, as used in the context of this document, is intended to
refer to a computing device that connects to the Internet. This
encompasses devices used directly by Internet users such as personal
computers, including laptops, desktops, and netbooks, as well as
mobile phones, smart phones, home gateway devices, and other end user
computing devices which are connected or can connect to the public
Internet and/or private IP networks.</t>
<t>Increasingly, other household systems and devices contain embedded
computers which are connected or can connect to the public Internet
and/or private IP networks. However, these devices may not be under
interactive control of the Internet user, such as may be the case with various smart home and smart grid devices.</t>
</section>
<section title="Malware" toc="exclude">
<t>This is short for malicious software. In this case, malicious
bots are considered a subset of malware. Other forms of malware could include
viruses and other similar types of software. Internet users can
sometimes cause their computer to be infected with malware, which may
include a bot or cause a bot to install itself, via inadvertently
accessing a specific website, downloading a specific file, or other
activities.</t>
<t>Alternatively, Internet-connected computers may become infected with
malware through externally initiated malicious activities such as the
exploitation of vulnerabilities or the brute force guessing of access
credentials.</t>
</section>
</section>
<section anchor="intro" title="Introduction and Problem Statement" toc="include">
<t>Computers used by Internet users, which in this case are customers of
an Internet Service Provider (ISP), can be infected with malware which
may contain and/or install one or more bots on a computer. This can
present a major problem for an ISP for a number of reasons (not to
mention of course the problems created for users). First, these bots can
be used to send spam, in some cases very large volumes of spam. This
spam can result in extra cost for the ISPs in terms of wasted network,
server, and/or personnel resources, among many other potential costs or
side effects. Such spam can also negatively affect the reputation of the
ISP, their customers, and the email reputation of the IP address space
used by the ISP (often referred to simply as "IP reputation").</t>
<t>In addition, these bots can act as platforms for directing,
participating in, or otherwise conducting attacks on critical Internet
infrastructure. Bots are frequently used as part of concerted
Distributed Denial of Service (DDoS) attacks for criminal, political or
other motivations. For example, bots have been used to attack Internet
resources and infrastructure ranging from web sites, to email servers
and DNS servers, as well as the critical Internet infrastructure of
entire countries. Motivations for such coordinated DDoS attacks can range
from criminal extortion attempts through to online protesting and
nationalistic fervor.</t>
<t>While any computing device can be infected with bots, the
majority of bot infections affect the personal computers used by
Internet end users. As a result of the role of ISPs in providing IP
connectivity, among many other services, to Internet users, these ISPs
are in a unique position to be able to attempt to detect and observe bot
nets operating in their networks. Furthermore, ISPs may also be in a
unique position to be able to communicate to Internet users which are
their customers, when customers computers may have been determined to
have been or possibly have been infected with one or more bots.</t>
<t>From an end user perspective, knowing that their computer has
been infected with one or more bots is very important information. Once
they know this, they can take steps to remove the bot, protect
themselves in the future, and resolve any problems which may stem from
the bot infection. Given that bots can drain the local computing and
network resources, enable theft of personal information (including
personal financial information), enable the computer to be used from
criminal activities (that may result in the Internet user being legally
culpable), destroy or leave the PC in an unrecoverable state via 'kill
switch' bot technologies, it is important to notify the user that they
may be infected with a bot.</t>
<t>As a result, the intent of this document is to provide a guide to
ISPs and other organizations for the remediation of these computers
infected with bots, so as to reduce the size of bot nets and minimize
the potential harm that bots can inflict upon Internet infrastructure
generally, as well as on individual Internet users. Efforts by ISPs and
other organizations could therefore, over time, reduce the pool of
computers infected with bots on the Internet, which in turn could result
in smaller bot nets with less capability for disruption.</t>
</section>
<section anchor="limitations" title="Important Notice of Limitations" toc="include">
<t>The techniques described in this document in no way guarantee the
remediation of all bots. Bot removal is potentially a task requiring
specialized knowledge, skills and tools, and may be beyond the ability
of average users. Attempts at bot removal may frequently be
unsuccessful, or only partially successful, and may leave a user's
system in an unstable and unsatisfactory state or even still infected.
Attempts at bot removal can also result in side effects ranging from a
loss of data or other files, all the way through partial or complete
loss of system usability.</t>
<t>In general, the only way a user can be sure they have removed some of
today's increasingly sophisticated malware is by "nuking-and-paving" the
system: reformatting the drive, reinstalling the operating system and
applications (including all patches) from scratch, and then restoring
user files from a clean backup. However the introduction of BIOS based
malware may mean that in some cases, this will not be enough and may
prove to be more than any end user can be reasonably expected to
resolve.</t>
<t>Devices with embedded operating systems, such as video gaming
consoles and smart home appliances, will most likely be beyond a user's
capability to remediate by themselves, and will typically require the
aid of vendor specific advice, updates and tools. Care must be taken
when imparting remediation advice to Internet users given the
increasingly wide array of computing devices that can be, or could be,
bot infected in the future.</t>
</section>
<section anchor="DetectNotifyRemediate" title="Detection, Notification and Remediation" toc="include">
<t>The potential mitigation of bots is accomplished through a process of
detection, notification to Internet users, and remediation of that bot
with a variety of tools.</t>
<section anchor="Detection" title="Detection of Bots" toc="include">
<t>An ISP must first identify that an Internet user, in this case a
user that is assumed to be their customer or otherwise connected to
the ISP's network, is determined to be infected, or likely to have
been infected with a bot. The ISP should attempt to detect the
presence of bots using methods, processes, and tools which maintain
the privacy of the personally identifiable information of their
customers. The ISP also should not block legitimate traffic in the
course of bot detection, and should instead employ detection methods,
tools, and processes which seek to be non-disruptive, as well as being
transparent to Internet users.</t>
<t>Detection methods, tools, and processes may include things such as
analysis of specific network and/or application traffic flows (such as
traffic to an email server), analysis of aggregate network and/or
application traffic data, data feeds received from other ISPs and
organizations (such as lists of the ISP's IP addresses which have been
reported to have sent spam), feedback from the ISP's customers or
other Internet users, as well as a wide variety of other
possibilities. It is likely that a combination of multiple
bot detection data points will prove to be an effective
approach in order to corroborate information of varying dependability
or consistency, as well as to avoid or minimize the possibility of
false positive identification of computers. Detection should also,
where possible and feasible, attempt to classify a bot in order to
confirm that it is malicious in nature, estimate the variety and
severity of threats it may pose (such as spam bot, key-logging bot,
file distribution bot, etc.), and to determine potential methods for
eventual remediation. However, given the dynamic nature of botnet
management and the criminal incentives to seek quick financial rewards,
botnets frequently update or change their core malicious capabilities. As
a consequence, botnets that are initially detected and classified by the
ISP need to be continuously monitored and tracked in order to correctly
identify the threat they pose at any particular point in time.</t>
<t>Detection is also time-sensitive. If complex analysis is required
and multiple confirmations are needed to confirm a bot is indeed
present, then it is possible that the bot will do its damage (to either
the infected computer or a remotely targeted system) before it
can be stopped. This may mean that an ISP may need to balance the
desire or need to definitively classify and/or confirm a bot, which
may take an extended period of time, with the ability to predict the
strong likelihood of a bot in a very short period of time. This also
means that Internet users may benefit from the deployment of
client-based software protections or other software tools, which can
enable rapid performance of heuristically-based detection bot
activity, such as the detection of a bot as it starts to communicate a
bot net and execute some type of command. Any bot detection systems
should also be capable of learning and adapting, either via manual
intervention or automatically, in order to cope with a rapidly
evolving threat.</t>
<t>As noted above, detection methods, tools, and processes should
ensure that privacy of customers' personally identifiable information
is maintained. While bot detection methods, tools, and processes are
similar to spam and virus defenses deployed by the ISP for the
benefits of their customers (and may be directly related to those
defenses), attempts to detect bots should take into account the need
of an ISP to take care to ensure that such personally identifiable
information is properly protected. Finally, depending upon the
geographic region within which an ISP operates, certain methods
relating to bot detection may need to be included in relevant terms of
service documents or other documents which are available to the
customers of a particular ISP.</t>
<t>There are several bot detection methods, tools, and processes that
an ISP may choose to utilize, as noted in the list below. It is
important to note that the technical solutions available are
relatively immature, and are likely to change over time, and to evolve
rapidly in the coming years. While these items are described in
relation to ISPs, they may also be applicable to organizations
operating other networks, such as campus networks and enterprise
networks.</t>
<t><list style="letters"> <t>Where legally permissible or otherwise an industry accepted practice in a particular market region, an ISP may in some manner "scan" their IP space in order to detect un-patched or otherwise vulnerable hosts. This may provide the ISP with the opportunity to easily identify Internet users who appear to already be or are at great risk of being infected with a bot. ISP's should note that some types of port scanning may leave network services in a hung state or render them unusable due to common frailties, and that many modern firewall and host-based intrusion detection implementations may alert the Internet user to the scan. As a result the scan may be interpreted as a malicious attack against the computer. Vulnerability scanning has a higher probability of leaving accessible network services and applications in a damaged state and will often result in a higher probability of detection by the Internet user and subsequent interpretation as a targeted attack. Depending upon the vulnerability being scanned, some automated methods of vulnerability checking may result in data being altered or created afresh on the Internet users computer which be a problem in many legal environments.</t>
<t>An ISP may also communicate and share selected data, via feedback loops or other mechanisms, with various third parties. Feedback loops are consistently formatted feeds of real-time (or nearly real-time) abuse reports offered by threat data clearinghouses, security alert organizations, other ISPs, and other organizations. The data may include, but is not limited to, lists of the IP addresses computers which have or are likely to have a bot running, domain names or fully qualified domain names (FQDNs) known to host malware and/or be involved in the command and control of botnets, IP addresses know to host malware and/or be involved in the command and control of botnets, recently tested or discovered techniques or detecting or remediating bot infections, new threat vectors, and other relevant information. Good examples of this include SNDS from Microsoft, XBL and PBL from Spamhaus and DSHIELD AS tool from SANS</t>
<t>An ISP may use Netflow <xref target="RFC3954"></xref> or other similar passive network monitoring to identify network anomalies that may be indicative of botnet attacks or bot communications. For example, an ISP may be able to identify compromised hosts by identifying traffic destined to IP addresses associated with the command and control of botnets. In addition, bots can be idenfied when a remote host is under distribute attack because computers participating in the attack will likely be infected by a bot.</t>
<t>An ISP may use DNS-based techniques to perform detection. For example, a given classified bot may be known to query a specific list of domain names at specific times or on specific dates (in the example of the so-called "Conficker" bot), often by matching DNS queries to a well known list of domains associated with malware. In many cases such lists are distributed by or shared using third parties, such as threat data clearinghouses. Alternative dynamic DNS based techniques may look for associations of domain names with known bad actor lists and networks with poor reputations, or heuristic techniques that rank the domain name based upon previously identified botnet usage and bot characteristics.</t>
<t>User complaints: Because bot infected hosts are frequently used to send spam or participate in DDoS attacks, the ISP servicing those hosts will normally receive complaints about the malicious network traffic. Those complaints may be sent to RFC2142-specified <xref target="RFC2142"></xref> role accounts, such as abuse@ or postmaster@ or to abuse or security addresses specified by the site as part of its WHOIS (or other) contact data.</t>
<t>ISPs may also discover likely bot infected hosts located at other sites; when legally permissible or otherwise an industry accepted practice in a particular market region, it may be worthwhile for ISPs to share evidence relating to those compromised hosts with the relevant remote ISP, with security researchers, and with blocklist operators.</t>
<t>ISP's may operate or subscribe to services that provide sinkholing
or honeynet capabilities. This enable the ISP to obtain realtime
lists of bot infected computers as they attempt to join the larger
botnet or propagate. These technologies may allow the ISP to
enumerate bot infections within their customer population.</t>
</list></t>
</section>
<section anchor="Notification" title="Notification to Internet Users" toc="include">
<t>Once an ISP has detected a bot, or the strong likelihood of a bot,
steps should be undertaken to inform the Internet user that they may
have a bot related problem. Depending upon a range of factors, from
the technical capabilities of the ISP, to the technical attributes of
their network, financial considerations, available server resources,
available organizational resources, the number of likely infected
computers detected at any given time, and the severity of any possible
threats, among many other things, an ISP will decide the most
appropriate method or methods for providing notification to one or
more of their customers or Internet users. Such notification methods
may include one or more of the following, as well as other possible
methods not described below. It is important to note that none of
these methods are guaranteed to be successful, as each has its own set
of limitations. In addition, in some cases, and ISP may determine that
a combination of two or more methods is most appropriate. Finally,
notification is also considered time sensitive; if the user does not
receive or view the notification or a timely basis, then a particular
bot could launch an attack, exploit the user, or cause other harm. If
possible, an ISP should establish a preferred means of communication
when the subscriber first signs up for service. As a part of the
notification process, ISPs should maintain a record of the allocation
of IP addresses to subscribers for such a period as allows any bot
detection technology to be accurately able to link an infected IP
address to a subscriber. This record should only be maintained for a
period which is consonant with the protection of the privacy of the
individual subscriber.</t>
<t>One important factor to bear in mind is that notification to
end users needs to be defended against spoofing by third parties.
This must be done to protect against the possibility of notifications
being spoofed and used by bots to deliver additional malware.</t>
<section anchor="Email Notification" title="Email Notification" toc="exclude">
<t>This is probably the most common form of notification used by
ISPs. One drawback of using email is that it is not guaranteed to be
viewed within a reasonable time frame, if at all. The user may be
using a different primary email address than that which they have
provided to the ISP. In addition, some ISPs do not provide an email
account at all, as part of a bundle of Internet services, and/or do
not have a need for or manner in which to request or retain the
primary email addresses of Internet users of their networks. Another
possibility is that the user, their email client, and/or their email
servers could determine or classify such a notification as spam,
which could delete the message or otherwise file it in an email
folder that the user may not check on a regular and/or timely basis.
Bot masters have also been known to impersonate the ISP or trusted
sender and send fradulant emails to the users. This technique of
solical engineering often leads to new bot infestations. Finally if the
user's email credentials are compromised, then a hacker and/or a bot
could simply login to the user's email account and delete the email
before it is read by the user.
</t>
</section>
<section anchor="Telephone Call Notification" title="Telephone Call Notification" toc="exclude">
<t>A telephone call may be an effective means of communication in
particularly high-risk situations. However, telephone calls may not
be feasible due to the cost of making a large number of times, as
measured in either time, money, organizational resources, server
resources, or some other means. In addition, there is no guarantee
that the user will answer their phone. To the extent that the
telephone number called by the ISP can be answered by the infected
computing device, the bot on that computer may be able to
disconnect, divert, or otherwise interfere with an incoming call.
Users may also interpret such a telephone notification as a
telemarketing call and as such not welcome it, or not accept the
call at all. Finally, even if a representative of the ISP is able to
connect with and speak with a user, that user is very likely to lack
the necessary technical experience to understand or be able to
effectively deal with the threat.</t>
</section>
<section anchor="Postal Mail Notification" title="Postal Mail Notification" toc="exclude">
<t>This form of notification is probably the least popular means of
communication, due to both preparation time, delivery time and cost
however, it may be more effective than email even when delivering an
identical message. Optionally the notification of bot infection can
be printed on the bill when the subscriber is taking a billable
service.</t>
</section>
<section anchor="Walled Garden Notification" title="Walled Garden Notification" toc="exclude">
<t>Placing a user in a walled garden is another approach that ISPs
may take to notify users. A walled garden refers to an environment
that controls the information and services that a subscriber is
allowed to utilize and what network access permissions are granted.
This is an effective technique because it could be able to block all
communication between the bot and the command and control channel,
which may impair the ability of a bot to disrupt or block attempts
to notify the user.</t>
<t>While in many cases, the user is almost guaranteed to view the
notification message and take any appropriate remediation actions,
this approach poses can pose other challenges. For example, it is
not always the case that a user is actively using a computer that
uses a web browser or which has a web browser actively running on
it. In one case, a user could be playing a game online, via the use
of a dedicated, Internet-connected game console. In another case,
the user may not be using a computer with a web browser when they
are placed in the walled garden and may instead be in the course of
a telephone conversation, or may be expecting to receive a call,
using a Voice Over IP (VOIP) device of some type. As a result, the
ISP may feel the need to maintain a potentially lengthy white list
of domains which are not subject to the typical restrictions of a
walled garden, which could well prove to be an onerous task, from an
operational perspective.</t>
<t>The ISP has several options to determine when to let the user out
of the walled garden. One approach may be to let the user determine
when to exit. This option is suggested when the purpose of the
walled garden is to notify users and provide information on
remediation only, particularly since notification is not a guarantee
of successful remediation. It could also be the case that, for
whatever reason, the user makes the judgment that they cannot then
take the time to remediate their computer and that other online
activities which they would like to resume are more important.
Exit from the walled garden should involve require process to verify
that it is indeed the user who is requesting exit from the walled
garden and not the bot.</t>
<t>Once the user acknowledges the notification, then the user
decides to either remediate and then exit the walled garden, or exit
the walled garden without addressing the issue. Another approach may
be to enforce a stricter policy and require the user to clean the
computer prior to permitting the user to exit the walled garden,
though this may not be technically feasible depending upon the type
of bot, obfuscation techniques employed by a bot, and/or a range of
other factors. Thus, the ISP may also need to support tools to scan
the infected computer and determine whether it is still infected or
rely on user judgment that the bot has been disabled or removed.
One challenge with this approach is that if the user has multiple
computers sharing a single IP address, such as via a common home
gateway device which performs Network Address Translation (NAT),
then the ISP may need to determine from user feedback or other means
that all affected computers have been remediated, which may or may
not be technically feasible.</t>
<t>A list of well known addresses for both operating system vendors
and security vendors should be created. This can be referenced when
allowing access from the walled garden by end users in search of
operating system and application patches.</t>
</section>
<section anchor="Instant Message Notification" title="Instant Message Notification" toc="exclude">
<t>Instant Message (IM): Instant messaging provides the ISP
with a simple means to communicate with the user. There are
several advantages to using IM which makes it an attractive
option. If the ISP provides IM service and the user
subscribes to it then the user can be notified easily.
IM based notification can be cost effective means to
communicate with the use. This can be achieved by signing up
for IM service with the various popular IM providers and
programatically messaging, if permitted by the acceptable
usage policy, the notifications. However, IM based
notification can also be done manually by the ISP's support
staff. Ideally, the ISP should allow the user to register the
IM identity and seek permission to be contacted via this
means. If the IM service provider supports offline
messaging the user can be notified regardless of their signed
in status. Essentially a message can be sent and when the user
signs in they would receive it. There are several drawbacks
with this communications method. There is a high
probability that subscriber may interpret the communication to
be spam and as such ignore it. Not every user uses IM
and/or the user may not provide their IM identity to the ISP
so some alternative means have to be used. There maybe
a privacy concern when the communication between the ISP and
the end user is not secure and over a third party network
and/or IM service. As such the notification must be discreet
and not provide any personally identifiable information.</t>
</section>
<section anchor="Short Message Service (SMS) Notification" title="Short Message Service (SMS) Notification" toc="exclude">
<t>Short Message Service (SMS): SMS allows the ISP send a
brief description of the problem to notify the user of the
issue. The ISP should allow users to register their mobile number
for notifications and also allow users to opt out if they do
not wish to be notified. The primary advantage of SMS is that
users are used to receiving text messages and are likely to
read them. Users may not act on the notification
immediately if they are not in front of their computer system.
One disadvantage is that ISPs may have to follow up with an
alternate means of notification if not all of the necessary
information maybe conveyed in one message. This is becuase
SMS messages are limited to 140 characters. Another
disadvantage with SMS is the cost associated with it. The ISP
has to either build its own SMS gateway to interface with the
various wireless service providers or use a third party
provider to notify users. It is recommended that the ISP
absorb the cost of notification and should always state in the
notification that the message is free of charge to the user.
Another small disadvantage is that it is possible to notify
the wrong user if the intended user changes their mobile
number but forgets to update it with the ISP.</t>
</section>
<section anchor="Web Browser Notification" title="Web Browser Notification" toc="exclude">
<t>Near real-time notification to the user's web browser is
another technique that may be utilized for notifying the user,
though how such a system might operate is outside the scope of
this document. Such a notification could have a comparative
advantage over a walled garden notification, in that it does not
restrict traffic to a specified list of destinations in the same
way that a walled garden by definition would. However, as with a
walled garden notification, there is no guarantee that a user is
at any given time making use of a web browser, though such a
system could certainly provide a notification when such a
browser is eventually used. Compared to a walled garden, a web
browser notification is probably preferred from the perspective
of Internet users, as it does not have the risk of disrupting
non-web sessions, such as online games, etc. (as noted in <xref
target="Walled Garden Notification"></xref>).</t>
</section>
</section>
<section anchor="Remediation" title="Remediation of Bot Infected Machines" toc="include">
<t>This section covers the different options available to remediate a
computer, which means to remove, disable, or otherwise render a bot
harmless. Prior to this step, an ISP has detected the bot, notified
the user that one of their computers is infected with a bot, and now
has to provide some means to clean the PC. The generally recommended
approach is to provide the necessary tools and education to the user
so that they may perform bot remediation themselves.</t>
<t>For example, this may include the creation of a special Security
Web Portal. This should be a well-publicized security portal to which
a user with a bot problem can be directed to for remediation. This
Security Web Portal should clearly explain why the user was notified
and may include an explanation of what bots are and the threats that
they pose. There should be a clear explanation of the steps that the
user should take in order to clean the computers and provide
information on how users can keep the computer free of future
infections. The Security Web Portal should have a guided process that
takes non technical users through the remediation process.</t>
<t>In terms of the text user to explain what bots are and the threat
they pose, something simple such as this may suffice:</t>
<t>"What is a bot? A bot is a piece of software, generally installed
on your machine without your knowledge, which either sends spam or
tries to steal your personal information. They can be very difficult
to spot, though you may have noticed that your computer is running
much more slowly than usual or you notice regular disk activity even
when you are not doing anything. Ignoring this problem is not really
an option since your personal information is currently at risk. Thus,
bots need to be removed to protect your data and your personal
information."</t>
<t>It is also important to note that it may not be immediately
apparent to the Internet user precisely which device has been or
which multiple devices have been infected with a particular bot.
This is because of the user's home-networking configurations and
the growing prevalence of IP enabled devices within a household
that now connect to the public Internet and/or Private IP
networks. The consequence of this for an ISP is that
remediation advice may not ultimately be actionable by the
Internet user. For example, the Internet user may be operating a
computer, a notebook, a video console and multimedia system on
their personal network. All of these device may connect to the
Internet via a single gateway appliance. Any of these devices
can be infected with a bot through a number of vectors. yet the
remediation advice is likely to be quite different and may or
may not be directly serviceable by the Internet user. Diligence
needs to be taken by the ISP in understanding the specific
nature of the device that has been infected with a bot, and
providing appropriate remediation advice.</t>
</section>
<section title="Guided Remediation Process" toc="include">
<t>Minimally the Guided Remediation Process should include options
and/or recommendations on how a user should: <list style="numbers"> <t>Backup personal Documents, for example: "Before you start, make sure to back up all of your important data. (You should do this on a regular basis anyway.) You can back up your files manually or using a system back-up software utility, which may be part of your Operating System (OS). You can back your files up to a USB Thumb Drive (aka USB Key), a CD/DVD-ROM, an external hard drive, or a network file server."</t>
<t>Download OS patches and Anti-Virus (A/V) software updates. For example, links could be provided to Microsoft Windows updates at http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en-us as well as to Apple MacOS updates at http://support.apple.com/kb/HT1338?viewlocale=en_US.</t>
<t>Explain how to configure the computer to automatically install updates for the OS, A/V and other common Web Browsers such as Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Opera, and Google Chrome.</t>
<t>The flow should also have the option for users to get professional assistance if they are unable to remove the bots themselves. If purchasing third party assistance, then the user should be encouraged to pre-determine how much they are willing to pay for that help. If the computer that is being remediated is old and can easily be replaced with a new, faster, larger and more reliable system for three or four hundred dollars, the it makes no sense to spend five or six hundred dollars to fix the old computer, for example. On the other hand, if the customer has a brand new computer that cost several thousand dollars, it might make perfect sense to spend the money in attempting to remediate it.</t>
<t>To continue, regardless of whether the user or a knowledgeable technical assistant is working on remediating the computer, their first task should be to determine which of multiple potentially-infected machines may be the one that needs attention (in the common case of multiple computers in a home network). Sometimes, as in cases where there is only a single directly-attached computer, or the user has been noticing problems with one of their computers, this can be easy. Other times, it may be more difficult. If the user is behind a home gateway/router, then the first task may be to ascertain which of the machines is infected. In some cases the user may have to check all machines to identify the infected one.</t>
<t>User surveys to solicit feedback on whether the notification and remediation process is effective and what recommended changes could be made in order to improve the ease, understandability, and effectiveness the remediation process.</t>
<t>If the user is interested in reporting his or her computer's bot infection to an applicable law enforcement authority, then the computer effectively becomes a cyber "crime scene" and should not be mitigated unless or until law enforcement has collected the necessary evidence. For individuals in this situation, the ISP should refer them to local, state, federal, or other relevant computer crime offices. (Note: Some "minor" incidents, even if highly traumatic to the user, may not be sufficiently serious for law enforcement to commit some of their limited resources to an investigation.)</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>There are no security considerations to include at this time.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations in this document.</t>
</section>
<section title="Acknowledgements">
<t>The authors wish to acknowledge the following individuals and organisations
for their review and feedback of this document:</t>
<t>Jonathan Curtis</t>
<t>Jeff Chan</t>
<t>Roland Dobbins</t>
<t>Eliot Gillum</t>
<t>Messaging Anti-Abuse Working Group (MAAWG)</t>
<t>Jose Nazario</t>
<t>Gunter Ollmann</t>
<t>Eric Ziegast</t>
<!-- <t>Your name here in lights!</t> -->
</section>
<!-- appendix -->
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title="Informative references">
&RFC1459;
&RFC2119;
&RFC2142;
&RFC3954;
</references>
<section title="Document Change Log">
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>-02 version: <list style="symbols">
<t>all updates from Jason - still some open issues but we're now at a place where we can solicit more external feedback</t>
</list></t>
<t>-01 version: <list style="symbols">
<t>-01 version published</t>
</list></t>
</section>
<!-- ADD BACK ONCE THIS DRAFT IS PUBLISHED
<references title='Informative References'>
rfc include="reference.I-D.draft-livingood-web-notification-00.xml
</references>
-->
<section title="Open Issues">
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>Could use some informational references in Section 3</t>
<t>Fix the odd list spacing in Section 5.1</t>
<t>Consider revision of the OS update links, to simplify them.</t>
<t>Add some point about notification to large networks may not be useful
-- such as coffee shops or hotels with WiFi networks.</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->
| PAFTECH AB 2003-2026 | 2026-04-24 17:24:29 |