Internet Engineering Task Force (IETF)                      J. Livingood
Request for Comments: 6561                                       N. Mody
Category: Informational                                     M. O'Reirdan
ISSN: 2070-1721                                                  Comcast
                                                              March 2012
        

Recommendations for the Remediation of Bots in ISP Networks

ISPネットワークでのボットの修復に関する推奨事項

Abstract

概要

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components 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.

このドキュメントには、インターネットサービスプロバイダーがさまざまな修復技術を使用して、サブスクライバーが使用するコンピューターに悪意のあるボットが侵入した場合の影響を管理する方法に関する推奨事項が含まれています。感染したコンピュータを使用しているインターネットユーザーは、個人データの損失やオンライン詐欺の影響を受けやすいなどのリスクにさらされています。このようなコンピュータは、オンライン犯罪ネットワーク、スパムネットワーク、フィッシングネットワークの不注意な参加者やコンポーネントになり、分散型サービス拒否攻撃の一部として使用される可能性もあります。悪意のあるボットの影響を軽減し、インストールを修正すると、ボットネットの運用がより困難になり、インターネット全般や特定のインターネットサービスプロバイダーのネットワークでのオンライン犯罪のレベルが低下する可能性があります。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6561.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6561で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Key Terminology ............................................3
           1.1.1. Malicious Bots, or Bots .............................3
           1.1.2. Bot Networks, or Botnets ............................4
           1.1.3. Host ................................................5
           1.1.4. Malware .............................................5
           1.1.5. Fast Flux ...........................................5
   2. Problem Statement ...............................................6
   3. Important Notice of Limitations and Scope .......................7
   4. Detection of Bots ...............................................8
   5. Notification to Internet Users .................................12
      5.1. Email Notification ........................................13
      5.2. Telephone Call Notification ...............................13
      5.3. Postal Mail Notification ..................................14
      5.4. Walled Garden Notification ................................14
      5.5. Instant Message Notification ..............................16
      5.6. Short Message Service (SMS) Notification ..................16
      5.7. Web Browser Notification ..................................17
      5.8. Considerations for Notification to Public Network
           Locations .................................................18
      5.9. Considerations for Notification to Network
           Locations Using a Shared IP Address .......................18
      5.10. Notification and End User Expertise ......................19
   6. Remediation of Hosts Infected with a Bot .......................19
      6.1. Guided Remediation Process ................................21
      6.2. Professionally Assisted Remediation Process ...............22
   7. Failure or Refusal to Remediate ................................23
   8. Sharing of Data from the User to the ISP .......................23
   9. Security Considerations ........................................23
   10. Privacy Considerations ........................................24
   11. Acknowledgements ..............................................24
   12. Informative References ........................................26
   Appendix A.  Examples of Third-Party Malware Lists ................28
        

1. Introduction

1. はじめに

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components 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.

このドキュメントには、インターネットサービスプロバイダーがさまざまな修復技術を使用して、サブスクライバーが使用するコンピューターに悪意のあるボットが侵入した場合の影響を管理する方法に関する推奨事項が含まれています。感染したコンピュータを使用しているインターネットユーザーは、個人データの損失やオンライン詐欺の影響を受けやすいなどのリスクにさらされています。このようなコンピュータは、オンライン犯罪ネットワーク、スパムネットワーク、フィッシングネットワークの不注意な参加者やコンポーネントになり、分散型サービス拒否攻撃の一部として使用される可能性もあります。悪意のあるボットの影響を軽減し、インストールを修正すると、ボットネットの運用がより困難になり、インターネット全般や特定のインターネットサービスプロバイダーのネットワークでのオンライン犯罪のレベルが低下する可能性があります。

1.1. Key Terminology

1.1. 主な用語

This section defines the key terms used in this document.

このセクションでは、このドキュメントで使用される主要な用語を定義します。

1.1.1. Malicious Bots, or Bots

1.1.1. 悪意のあるボット、またはボット

A malicious or potentially malicious bot (derived from the word "robot", hereafter simply referred to as a "bot") refers to a program that is 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". Such bots may have been installed surreptitiously, without the user's full understanding of what the bot will do once installed, unknowingly as part of another software installation, under false pretenses, and/or in a variety of other possible ways.

悪意のある、または潜在的に悪意のあるボット（「ロボット」という単語に由来し、以下、単に「ボット」と呼びます）は、システムに自動（または半自動）で実行できるようにするためにシステムにインストールされるプログラムを指します通常、リモート管理者、つまり「ボットマスター」のコマンドと制御下にあるタスクまたはタスクのセット。ボットは「ゾンビ」としても知られています。そのようなボットは、一度インストールされたボットが何をするのかをユーザーが完全に理解せずに、知らないうちに別のソフトウェアのインストールの一部として、偽装したり、さまざまな方法で不正にインストールされている可能性があります。

It is important to note that there are "good" bots. Such good bots are often found interacting with a computing resource in environments such as gaming and Internet Relay Chat (IRC) [RFC1459], where a continual, interactive presence can be a requirement for participating in the games. Since such good bots are performing useful, lawful, and non-disruptive functions, there is no reason for a provider to monitor for their presence and/or alert users to their presence.

「良い」ボットがあることに注意することが重要です。このような優れたボットは、ゲームやインターネットリレーチャット（IRC）[RFC1459]などの環境でコンピューティングリソースと対話することがよくあります。この場合、ゲームに参加するには、継続的でインタラクティブな存在が必要です。このような優れたボットは有用で合法で無停止の機能を実行しているため、プロバイダーがプレゼンスを監視したり、ユーザーにプレゼンスを警告したりする理由はありません。

While there may be good, or harmless bots, for the purposes of this document, all mention of bots shall assume that the bots involved are malicious or potentially 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. In addition, included explicitly in this category are potentially malicious bots, which may initially appear neutral but may simply be waiting for remote instructions to transform and/or otherwise begin engaging in malicious behavior. In general, installation of a malicious bot without user knowledge and consent is considered in most regions to be unlawful, and the activities of malicious bots typically involve unlawful or other maliciously disruptive activities.

このドキュメントの目的上、優れた、または無害なボットが存在する可能性がありますが、ボットに関するすべての言及は、関与するボットが本来悪意のある、または潜在的に悪質であると想定します。そのような悪意のあるボットは、一般に、特定のインターネットユーザーの許可または意識的な理解なしに展開されたと想定されます。したがって、ユーザーの知らないうちに、ボットはユーザーのコンピューティングデバイスを、悪意のあるアクティビティを実行できるプラットフォームに変換する可能性があります。さらに、このカテゴリには明示的に潜在的に悪意のあるボットが含まれます。これは最初は中立のように見えるかもしれませんが、リモート命令が変換するか、悪意のある動作を開始するのを待っているだけです。一般に、ユーザーの知識と同意なしに悪意のあるボットをインストールすることは、ほとんどの地域で違法であると見なされ、悪意のあるボットの活動には、通常、違法またはその他の悪意のある破壊的な活動が含まれます。

1.1.2. Bot Networks, or Botnets

1.1.2. ボットネットワーク、またはボットネット

A "bot network", or "botnet", is defined as a concerted network 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 but are not limited to identity theft, spam, spim (spam over Instant Messaging (IM)), spit (spam over Internet telephony), email address harvesting, distributed denial-of-service (DDoS) attacks, key-logging, fraudulent DNS pharming (redirection), hosting proxy services, fast flux (see Section 1.1.5) hosting, hosting of illegal content, use in man-in-the-middle attacks, and click fraud.

「ボットネットワーク」または「ボットネット」は、リモートで生成された命令を操作できるボットの協調ネットワークとして定義されます。悪意のある活動は、ローカルマシンの情報に焦点を当てているか、リモートマシンにサービスを提供するために行動しています。ボットは高度にカスタマイズ可能であるため、多くのことを実行するようにプログラムできます。主な悪意のあるアクティビティには、IDの盗難、スパム、スピム（インスタントメッセージング（IM）を介したスパム）、唾（インターネットテレフォニーを介したスパム）、電子メールアドレスの収集、分散型サービス拒否（DDoS）攻撃、キーが含まれますが、これらに限定されませんロギング、DNSファーミング（リダイレクト）、ホスティングプロキシサービス、高速フラックス（セクション1.1.5を参照）ホスティング、違法コンテンツのホスティング、中間者攻撃での使用、およびクリック詐欺。

Infection vectors (infection pathways) include un-patched operating systems, software vulnerabilities (which include so-called zero-day vulnerabilities where no patch yet exists), weak/non-existent passwords, malicious web sites, un-patched browsers, malware, vulnerable helper applications, inherently insecure protocols, protocols implemented without security features switched on, 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 and network security engineers on the one hand and bot developers on the other.

感染経路（感染経路）には、パッチが適用されていないオペレーティングシステム、ソフトウェアの脆弱性（パッチがまだ存在しない、いわゆるゼロデイ脆弱性が含まれます）、脆弱な/存在しないパスワード、悪意のあるWebサイト、パッチが適用されていないブラウザ、マルウェア、脆弱なヘルパーアプリケーション、本質的​​に安全でないプロトコル、セキュリティ機能をオンにせずに実装されたプロトコル、およびユーザーのコンピューターにアクセスするためのソーシャルエンジニアリング技術。ボットの検出と破壊は進行中の問題であり、一方ではインターネットセキュリティコミュニティとネットワークセキュリティエンジニア、他方ではボット開発者の間の絶え間ない戦いです。

Initially, some bots used IRC to communicate but were easy to shut down 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 peer-to-peer (P2P) architectures and associated protocols, the use of HTTP and other resilient communication protocols, and 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 anomaly detection and behavioral analysis, both locally and remotely, to identify bots.

当初、一部のボットは通信にIRCを使用していましたが、コマンドアンドコントロールサーバーが識別され、非アクティブ化されていれば簡単にシャットダウンできました。新しいコマンドと制御方法が進化し、現在ボットマスターが採用している方法では、非アクティブ化に対する耐性が大幅に向上しています。ピアツーピア（P2P）アーキテクチャと関連プロトコルの導入、HTTPやその他の復元力のある通信プロトコルの使用、および暗号化の広範囲な採用により、ボットは通常のネットワーク使用から識別して分離することがかなり困難になっています。その結果、ボットを特定するために、ローカルとリモートの両方で、異常検出と行動分析への依存が高まっています。

1.1.3. Host

1.1.3. ホスト

As used in the context of this document, the host or computer of an end user is intended to refer to a computing device that connects to the Internet. This encompasses devices used by Internet users such as personal computers (including laptops, desktops, and netbooks), mobile phones, smart phones, home gateway devices, and other end user computing devices that are connected or can connect to the public Internet and/or private IP networks.

このドキュメントのコンテキストで使用されているように、エンドユーザーのホストまたはコンピューターは、インターネットに接続するコンピューティングデバイスを指すことを目的としています。これには、インターネットユーザーが使用するデバイス（ラップトップ、デスクトップ、ネットブックなど）、携帯電話、スマートフォン、ホームゲートウェイデバイス、および公共のインターネットに接続されているか接続できるその他のエンドユーザーコンピューティングデバイスが含まれます。プライベートIPネットワーク。

Increasingly, other household systems and devices contain embedded hosts that are connected to 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.

他の家庭用システムやデバイスには、パブリックインターネットやプライベートIPネットワークに接続されている、または接続できる組み込みホストがますます含まれています。しかしながら、これらのデバイスは、様々なスマートホームおよびスマートグリッドデバイスの場合のように、インターネットユーザーのインタラクティブな制御下にない場合があります。

1.1.4. Malware

1.1.4. マルウェア

Malware 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 hosts to be infected with malware, which may include a bot or cause a bot to install itself, via inadvertently accessing a specific web site, downloading a file, or other activities.

マルウェアは「悪意のあるソフトウェア」の略です。この場合、悪意のあるボットはマルウェアのサブセットと見なされます。マルウェアの他の形式には、ウイルスや他の同様の種類のソフトウェアが含まれる可能性があります。インターネットユーザーは、特定のWebサイトに誤ってアクセスしたり、ファイルをダウンロードしたり、その他のアクティビティを実行したりして、ボットを含むマルウェアにホストを感染させたり、ボットに自分自身をインストールさせたりすることがあります。

In other cases, Internet-connected hosts may become infected with malware through externally initiated malicious activities such as the exploitation of vulnerabilities or the brute force guessing of access credentials.

他の場合では、インターネットに接続されたホストは、脆弱性の悪用やアクセス資格情報のブルートフォース推測など、外部から開始された悪意のあるアクティビティを通じてマルウェアに感染する可能性があります。

1.1.5. Fast Flux

1.1.5. 高速フラックス

Domain Name System (DNS) fast fluxing occurs when a domain is bound in DNS using A records to multiple IP addresses, each of which has a very short Time-to-Live (TTL) value associated with it. This means that the domain resolves to varying IP addresses over a short period of time.

ドメインネームシステム（DNS）の高速フラクシングは、ドメインがDNSでAレコードを使用して複数のIPアドレスにバインドされている場合に発生します。各IPアドレスには、非常に短い存続時間（TTL）値が関連付けられています。つまり、ドメインは短期間にさまざまなIPアドレスに解決されます。

DNS fast flux is typically used in conjunction with proxies that are normally run on compromised user hosts. These proxies route the web requests to the real host, which serves the data being sought. The effect of this is to make the detection of the real host much more difficult and to ensure that the backend or hidden site remains up for as long as possible.

DNS高速フラックスは、通常、侵害されたユーザーホストで通常実行されるプロキシと組み合わせて使用​​されます。これらのプロキシは、Webリクエストを実際のホストにルーティングします。ホストは、求められているデータを提供します。これにより、実際のホストの検出がさらに困難になり、バックエンドまたは非表示サイトが可能な限り長く維持されるようになります。

2. Problem Statement

2. 問題文

Hosts used by Internet users, which in this case are customers of an Internet Service Provider (ISP), can be infected with malware that may contain and/or install one or more bots on a host. They 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 [Spamalytics]. 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 and 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"). A further potential complication is that IP space compromised by bad reputation may continue to carry this bad reputation even when used for entirely innocent purposes following reassignment of that IP space.

インターネットユーザー（この場合はインターネットサービスプロバイダー（ISP）の顧客）が使用するホストは、ホストに1つ以上のボットを含んだりインストールしたりするマルウェアに感染する可能性があります。 ISPにいくつかの理由で大きな問題を引き起こす可能性があります（もちろん、ユーザーのために作成された問題は言うまでもありません）。まず、これらのボットはスパムを送信するために使用でき、場合によっては大量のスパムを送信できます[Spamalytics]。このスパムは、多くの潜在的なコストと副作用の中でも、ネットワーク、サーバー、および/または人的リソースの浪費という点で、ISPに追加コストをもたらす可能性があります。このようなスパムは、ISPとその顧客の評判、およびISPが使用するIPアドレス空間の電子メールの評判（多くの場合、単に「IPレピュテーション」と呼ばれる）に悪影響を及ぼす可能性があります。さらに複雑になる可能性があるのは、悪い評判によって危険にさらされたIPスペースが、そのIPスペースの再割り当て後に完全に無害な目的で使用された場合でも、この悪い評判を持ち続ける可能性があることです。

In addition, these bots can act as platforms for directing, participating in, or otherwise conducting attacks on critical Internet infrastructure [Threat-Report]. Bots are frequently used as part of coordinated DDoS attacks for criminal, political, or other motivations [Gh0st][Dragon][DDoS]. 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 [Estonia][Combat-Zone]. Motivations for such coordinated DDoS attacks can range from criminal extortion attempts through to online protesting and nationalistic fervor [Whiz-Kid]. DDoS attacks may also be motivated by simple personal vendettas or by persons simply seeking a cheap thrill at the expense of others.

さらに、これらのボットは、重要なインターネットインフラストラクチャへの攻撃を指示、参加、または実行するためのプラットフォームとして機能する可能性があります[Threat-Report]。ボットは、犯罪、政治、その他の動機付けのための協調型DDoS攻撃の一部として頻繁に使用されます[Gh0st] [Dragon] [DDoS]。たとえば、ボットはWebサイトから電子メールサーバーやDNSサーバーまでのインターネットリソースやインフラストラクチャ、および国全体の重要なインターネットインフラストラクチャ[エストニア] [戦闘ゾーン]を攻撃するために使用されています。このように調整されたDDoS攻撃の動機は、犯罪の恐喝の試みから、オンラインでの抗議活動や民族主義的な熱意までさまざまです[Whiz-Kid]。 DDoS攻撃は、単純な個人的な復讐者によって、または単に他人を犠牲にして安価なスリルを求めている人によって動機付けられることもあります。

There is good evidence to suggest that bots are being used in the corporate environment for purposes of corporate espionage including the exfiltration of corporate financial data and intellectual property. This also extends to the possibility of bots being used for state-sponsored purposes such as espionage.

ボットが企業の財務データや知的財産の流出を含む企業スパイの目的で企業環境で使用されていることを示唆する良い証拠があります。これはまた、スパイなどの国家支援目的でボットが使用される可能性にまで及びます。

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 botnets operating in their networks. Furthermore, ISPs may also be in a unique position to be able to notify their customers of actual, potential, or likely infection by bots or other infection.

あらゆるコンピューティングデバイスがボットに感染する可能性がありますが、ボット感染の大部分は、インターネットエンドユーザーが使用するパソコンに影響を与えます。他の多くのサービスの中で、インターネットユーザーへのIP接続の提供におけるISPの役割の結果として、これらのISPは、ネットワークで動作しているボットネットを検出および監視することができる独特の立場にあります。さらに、ISPは、ボットやその他の感染による実際の感染、潜在的な感染、または起こりそうな感染を顧客に通知できる独自の立場にある場合もあります。

From the perspective of end users, being notified that they may have an infected computer on their network is important information. Once they know this, they can take steps to remove the bots, resolve any problems that may stem from the bot infection, and protect themselves against future threats. It is important to notify users that they may be infected with a bot because bots can consume vast amounts of local computing and network resources, enable theft of personal information (including personal financial information), enable the host to be used for criminal activities (that may result in the Internet user being legally culpable), and destroy or leave the host in an unrecoverable state via "kill switch" bot technologies.

エンドユーザーの観点からすると、ネットワーク上に感染したコンピュータがある可能性があることを通知されることは重要な情報です。これがわかったら、ボットを削除し、ボットの感染に起因する可能性のある問題を解決し、将来の脅威から身を守るための手順を実行できます。ボットはローカルコンピューティングおよびネットワークリソースを大量に消費し、個人情報（個人の財務情報を含む）の盗用を可能にし、ホストが犯罪活動に使用される可能性があるため、ボットに感染している可能性があることをユーザーに通知することが重要ですインターネットユーザーが法的に過失の可能性がある）場合があり、「キルスイッチ」ボットテクノロジーによってホストを破壊するか、回復不可能な状態のままにします。

As a result, the intent of this document is to provide guidance to ISPs and other organizations for the remediation of hosts infected with bots, so as to reduce the size of botnets and minimize the potential harm that bots can inflict upon Internet infrastructure in general as well as on individual Internet users. Efforts by ISPs and other organizations can, over time, reduce the pool of hosts infected with bots on the Internet, which in turn could result in smaller botnets with less capability for disruption.

結果として、このドキュメントの目的は、ボットに感染したホストを修復するためのISPおよびその他の組織にガイダンスを提供し、ボットネットのサイズを縮小して、ボットが一般的にインターネットインフラストラクチャに与える潜在的な害を最小限に抑えることです。個人のインターネットユーザーにも。 ISPや他の組織による取り組みにより、時間の経過とともに、インターネット上のボットに感染したホストのプールが減少し、その結果、ボットネットが小さくなり、混乱の可能性が少なくなる可能性があります。

The potential mitigation of bots is accomplished through a process of detection, notification to Internet users, and remediation of bot infections with a variety of tools, as described later in this document.

このドキュメントで後述するように、ボットの潜在的な緩和策は、検出、インターネットユーザーへの通知、およびさまざまなツールを使用したボット感染の修復のプロセスを通じて達成されます。

3. Important Notice of Limitations and Scope

3. 制限と範囲に関する重要なお知らせ

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; it may be beyond the ability of average users. Attempts at bot removal may frequently be unsuccessful, or only partially successful, leaving the user's system in an unstable and unsatisfactory state or even in a state where it is still infected. Attempts at bot removal can result in side effects ranging from a loss of data to partial or complete loss of system usability.

このドキュメントで説明されている手法は、すべてのボットの修復を保証するものではありません。ボットの削除は、専門的な知識、スキル、およびツールを必要とする可能性のあるタスクです。それは平均的なユーザーの能力を超えているかもしれません。ボットの削除の試みは、多くの場合、失敗するか、部分的にのみ成功し、ユーザーのシステムを不安定で不十分な状態、またはまだ感染している状態にしてしまう可能性があります。ボットを削除しようとすると、データが失われたり、システムのユーザビリティが部分的または完全に失われたりするなど、副作用が発生する可能性があります。

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 known clean backup. However, the introduction of persistent memory-based malware may mean that, in some cases, this may not be enough and may prove to be more than any end user can be reasonably expected to resolve [BIOS]. Experienced users would have to re-flash or re-image persistent memory sections or components of their hosts in order to remove persistent memory- based malware. However, in some cases, not even nuking-and-paving the system will solve the problem, which calls for hard drive replacement and/or complete replacement of the host.

一般に、ユーザーが今日のますます高度化するマルウェアの一部を確実に削除できる唯一の方法は、システムに「やり直し」を行うことです。ドライブを再フォーマットし、オペレーティングシステムとアプリケーション（すべてのパッチを含む）を最初から再インストールします。次に、既知のクリーンバックアップからユーザーファイルを復元します。ただし、永続的なメモリベースのマルウェアの導入は、場合によっては、これでは不十分であり、エンドユーザーが[BIOS]の解決を期待できるよりも優れていることを証明する場合があります。経験豊富なユーザーは、永続的なメモリベースのマルウェアを削除するために、ホストの永続的なメモリセクションまたはコンポーネントを再フラッシュまたは再イメージ化する必要があります。ただし、場合によっては、システムを無差別に起動しても問題が解決されず、ハードドライブの交換やホストの完全な交換が必要になります。

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 could therefore require the aid of vendor-specific advice, updates, and tools. However, in some cases, such devices will have a function or switch to enable the user to reset that device to a factory default configuration, which may sometimes enable the user to remediate the infection. Care should be taken when imparting remediation advice to Internet users given the increasingly wide array of computing devices that can be, or could be, infected by bots in the future.

ビデオゲームコンソールやスマート家電などのオペレーティングシステムが組み込まれたデバイスは、ユーザーが自分で修復する能力を超えている可能性が高いため、ベンダー固有のアドバイス、アップデート、およびツールの支援が必要になる可能性があります。ただし、場合によっては、そのようなデバイスには機能またはスイッチがあり、ユーザーがそのデバイスを工場出荷時のデフォルト構成にリセットできるようにすることで、ユーザーが感染を修復できる場合があります。将来ボットに感染する可能性がある、または感染する可能性のあるコンピューティングデバイスの種類がますます増えることを考慮して、インターネットユーザーに修復アドバイスを与える際には注意が必要です。

This document is not intended to address the issues relating to the prevention of bots on an end user device. This is out of the scope of this document.

このドキュメントは、エンドユーザーデバイスでのボットの防止に関する問題に対処することを目的としたものではありません。これは、このドキュメントの範囲外です。

4. Detection of Bots

4. ボットの検出

An ISP must first identify that an Internet user is infected or likely to have been infected with a bot (a user is assumed to be their customer or otherwise connected to the ISP's network). The ISP should attempt to detect the presence of bots using methods, processes, and tools that maintain the privacy of the personally identifiable information (PII) of their customers. The ISP should not block legitimate traffic in the course of bot detection and should instead employ detection methods, tools, and processes that seek to be non-disruptive and transparent to Internet users and end user applications.

ISPはまず、インターネットユーザーがボットに感染しているか、ボットに感染している可能性があることを特定する必要があります（ユーザーは顧客であるか、ISPのネットワークに接続していると見なされます）。 ISPは、顧客の個人識別情報（PII）のプライバシーを維持する方法、プロセス、およびツールを使用して、ボットの存在を検出しようとする必要があります。 ISPはボット検出の過程で正当なトラフィックをブロックするべきではなく、代わりにインターネットユーザーおよびエンドユーザーアプリケーションに対して無停止で透過的な検出方法、ツール、およびプロセスを採用する必要があります。

Detection methods, tools, and processes may include 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 that 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. In practice, it has proven effective to confirm a bot infection through the use of a combination of multiple bot detection data points. This can help to corroborate information of varying dependability or consistency, as well as to avoid or minimize the possibility of false positive identification of hosts. Detection should also, where possible and feasible, attempt to classify the specific bot infection type 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 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 capabilities. As a consequence, botnets that are initially detected and classified by the ISP as made up of one particular type of bot need to be continuously monitored and tracked in order to correctly identify the threat the botnet poses at any particular point in time.

検出方法、ツール、およびプロセスには、特定のネットワークやアプリケーションのトラフィックフロー（電子メールサーバーへのトラフィックなど）の分析、ネットワークやアプリケーションの総トラフィックデータの分析、他のISPや組織から受信したデータフィード（など）が含まれる場合があります。スパムを送信したと報告されているISPのIPアドレスのリストとして）、ISPの顧客または他のインターネットユーザーからのフィードバック、およびその他のさまざまな可能性。実際には、複数のボット検出データポイントの組み合わせを使用してボット感染を確認することが効果的であることが証明されています。これは、さまざまな信頼性または一貫性の情報を裏付けるのに役立ち、ホストの誤検出の可能性を回避または最小限に抑えることができます。検出は、可能かつ実現可能な場合、特定のボット感染タイプを分類して、それが悪意のある性質であることを確認し、脅威となる可能性のある脅威の種類と重大度（スパムボット、キーロギングボット、ファイルなど）を推定する必要もあります。配布ボットなど）、そして最終的な修復の潜在的な方法を決定します。ただし、ボットネット管理の動的な性質と迅速な金銭的報酬を求める犯罪的インセンティブを考えると、ボットネットは頻繁にコア機能を更新または変更します。その結果、特定のタイプのボットで構成されているとISPによって最初に検出および分類されたボットネットは、ボットネットが特定の時点でもたらす脅威を正しく識別するために、継続的に監視および追跡する必要があります。

Detection is also time sensitive. If complex analysis is required and multiple confirmations are needed to verify a bot is indeed present, then it is possible that the bot may cause some damage (to either the infected host or a remotely targeted system) before it can be stopped. This means that an ISP needs to balance the desire or need to definitively classify and/or confirm the presence of a bot, which may take an extended period of time, with the ability to predict the likelihood of a bot in a very short period of time. Such determinations must have a relatively low false positive rate in order to maintain the trust of users. This "definitive-versus-likely" challenge is difficult and, when in doubt, ISPs should err on the side of caution by communicating that a bot infection has taken place. This also means that Internet users may benefit from the installation of client-based security software on their host. This can enable rapid heuristically based detection of bot activity, such as the detection of a bot as it starts to communicate with other botnets and execute commands. Any bot detection system should also be capable of adapting, either via manual intervention or automatically, in order to cope with a rapidly evolving threat.

検出も時間に敏感です。複雑な分析が必要であり、ボットが実際に存在することを確認するために複数の確認が必要な場合、ボットを停止する前に、ボットが（感染したホストまたはリモートターゲットシステムのいずれかに）損傷を与える可能性があります。つまり、ISPは、ボットの存在を明確に分類および/または確認する必要があるため、長期間かかる場合があり、非常に短い期間のボットの可能性を予測する機能と、バランスをとる必要があります。時間。このような決定は、ユーザーの信頼を維持するために、比較的低い偽陽性率でなければなりません。この「決定的対潜在的」な課題は困難であり、疑わしい場合は、ISPはボット感染が発生したことを伝えることにより、注意を怠る必要があります。これは、インターネットユーザーがクライアントベースのセキュリティソフトウェアをホストにインストールすることで恩恵を受ける可能性があることも意味します。これにより、他のボットネットとの通信やコマンドの実行を開始するボットの検出など、ボットアクティビティのヒューリスティックに基づく迅速な検出が可能になります。ボット検出システムは、急速に進化する脅威に対処するために、手動操作または自動のいずれかで適応できる必要もあります。

As noted above, detection methods, tools, and processes should ensure that privacy of customers' personally identifiable information (PII) is maintained. This protection afforded to PII should also extend to third parties processing data on behalf of ISPs. While bot detection methods, tools, and processes are similar to spam and virus defenses deployed by the ISP for the benefit 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 any PII collected or incidentally detected is properly protected. This is important because just as spam defenses may involve scanning the content of email messages, which may contain PII, then so too may bot defenses similarly come into incidental contact with PII. The definition of PII varies from one jurisdiction to the next so proper care should be taken to ensure that any actions taken comply with legislation and good practice in the jurisdiction in which the PII is gathered. 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 that are available to the customers of a particular ISP.

上記のように、検出方法、ツール、およびプロセスは、顧客の個人識別情報（PII）のプライバシーが確実に維持されるようにする必要があります。 PIIに提供されるこの保護は、ISPに代わってデータを処理するサードパーティにも及ぶはずです。ボットの検出方法、ツール、およびプロセスは、顧客の利益のためにISPによって展開されたスパムおよびウイルス防御に似ています（これらの防御に直接関連している可能性があります）、ボットを検出する試みは、ISPの必要性を考慮する必要があります収集された、または偶発的に検出されたPIIが適切に保護されるように注意する。スパム防御がPIIを含む可能性のある電子メールメッセージのコンテンツをスキャンするのと同様に、ボット防御も同様にPIIと偶発的に接触する可能性があるため、これは重要です。 PIIの定義は管轄区域ごとに異なるため、PIIが収集された管轄区域の法律および適切な慣行に準拠するように、適切な注意を払う必要があります。最後に、ISPが動作する地理的地域によっては、ボット検出に関連する特定の方法を、特定のISPの顧客が利用できる関連サービス規約文書またはその他の文書に含める必要がある場合があります。

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, evolving 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.

以下のリストに記載されているように、ISPが利用することを選択できるボット検出方法、ツール、およびプロセスがいくつかあります。利用可能な技術的ソリューションは比較的未成熟であり、今後数年間で急速に進化し、時間とともに変化する可能性が高いことに注意することが重要です。これらの項目はISPに関連して説明されていますが、キャンパスネットワークやエンタープライズネットワークなど、他のネットワークを運用している組織にも適用できます。

a. Where it is not legally proscribed and an accepted industry practice in a particular market region, an ISP may in some manner "scan" its IP space in order to detect un-patched or otherwise vulnerable hosts or to detect the signs of infection. This may provide the ISP with the opportunity to easily identify Internet users who appear already to be infected or are at great risk of being infected with a bot. ISPs 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 host. 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 for which an ISP may be scanning, some automated methods of vulnerability checking may result in data being altered or created afresh on the Internet user's host, which can be a problem in many legal environments. It should also be noted that due to the prevalence of Network Address Translation devices, Port Address Translation devices, and/or firewall devices in user networks, network-based vulnerability scanning may be of limited value. Thus, while we note that this is one technique that may be utilized, it is unlikely to be particularly effective and has problematic side effects, which leads the authors to recommend against the use of this particular method.

a. 特定の市場地域で法的に禁止され、認められている業界慣行ではない場合、ISPは、パッチが適用されていない、または脆弱なホストを検出したり、感染の兆候を検出したりするために、何らかの方法でIPスペースを「スキャン」します。これにより、ISPは、すでに感染しているように見える、またはボットに感染するリスクが非常に高いインターネットユーザーを簡単に特定する機会を得ることができます。 ISPは、一部の種類のポートスキャンでは、ネットワークサービスがハングしたままになるか、一般的な脆弱性のために使用できなくなる可能性があること、および多くの最新のファイアウォールおよびホストベースの侵入検出実装がインターネットユーザーにスキャンを警告する場合があることに注意する必要があります。その結果、スキャンはホストに対する悪意のある攻撃として解釈される可能性があります。脆弱性スキャンは、アクセス可能なネットワークサービスとアプリケーションを損傷した状態のままにする可能性が高く、インターネットユーザーによる検出とその後の標的型攻撃としての解釈の可能性が高くなります。 ISPがスキャンする可能性のある脆弱性に応じて、脆弱性チェックの一部の自動化された方法により、インターネットユーザーのホストでデータが変更または新たに作成され、多くの法的環境で問題となる場合があります。また、ネットワークアドレス変換デバイス、ポートアドレス変換デバイス、および/またはユーザーネットワークのファイアウォールデバイスの普及により、ネットワークベースの脆弱性スキャンの価値が制限される可能性があることにも注意してください。したがって、これは利用できる1つの手法であることに注意しますが、特に効果的である可能性は低く、問題のある副作用があるため、著者はこの特定の方法の使用を推奨しないようにしています。

b. 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 formats for feedback loops include those defined in both the Abuse Reporting Format (ARF) [RFC5965] and the Incident Object Description Exchange Format (IODEF) [RFC5070]. The data may include, but is not limited to, IP addresses of hosts that appear to be either definitely or probably infected, IP addresses, domain names or fully qualified domain names (FQDNs) known to host malware and/or be involved in the command and control of botnets, recently tested or discovered techniques for detecting or remediating bot infections, new threat vectors, and other relevant information. A few good examples of data sharing are noted in Appendix A.

b。 ISPは、フィードバックループまたはその他のメカニズムを介して、さまざまなサードパーティと通信し、選択したデータを共有することもできます。フィードバックループは、脅威データクリアリングハウス、セキュリティ警告組織、他のISP、および他の組織によって提供される、リアルタイム（またはほぼリアルタイム）の悪用レポートの一貫した形式のフィードです。フィードバックループの形式には、Abuse Reporting Format（ARF）[RFC5965]とIncident Object Description Exchange Format（IODEF）[RFC5070]の両方で定義されている形式が含まれます。データには、明確にまたはおそらく感染していると思われるホストのIPアドレス、マルウェアをホストしている、またはコマンドに関与していることが知られているIPアドレス、ドメイン名、または完全修飾ドメイン名（FQDN）が含まれますが、これらに限定されません。ボットネットの制御、ボット感染、新しい脅威ベクトル、およびその他の関連情報を検出または修復するために最近テストまたは発見された手法。付録Aに、データ共有の良い例をいくつか示します。

c. An ISP may use Netflow [RFC3954] 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 or destined to the combination of an IP address and control port associated with a command and control network (sometimes command and control traffic comes from a host that has legitimate traffic). In addition, bots may be identified when a remote host is under a DDoS attack, because hosts participating in the attack will likely be infected by a bot. This can often be observed at network borders although ISPs should beware of source IP address spoofing techniques that may be employed to avoid or confuse detection.

c. ISPは、Netflow [RFC3954]または他の同様のパッシブネットワークモニタリングを使用して、ボットネット攻撃またはボット通信を示す可能性のあるネットワーク異常を識別します。たとえば、ISPは、ボットネットのコマンドと制御に関連付けられたIPアドレス宛の、またはコマンドと制御ネットワークに関連付けられたIPアドレスと制御ポートの組み合わせ（場合によってはコマンドとコントロール）宛のトラフィックを特定することで、侵害されたホストを特定できる場合があります。制御トラフィックは、正当なトラフィックを持つホストから送信されます）。さらに、攻撃に参加しているホストはボットに感染している可能性が高いため、リモートホストがDDoS攻撃を受けているときにボットが特定される可能性があります。 ISPは、検出を回避または混乱させるために使用される可能性のあるソースIPアドレスのスプーフィング技術に注意する必要がありますが、これはネットワーク境界でよく見られます。

d. 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 (see [Conficker]), 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.

d. ISPは、DNSベースの技術を使用して検出を実行する場合があります。たとえば、特定の分類されたボットは、特定の時間または特定の日付にドメイン名の特定のリストにクエリを実行することがわかっている場合があります（いわゆる「Conficker」ボット（[Conficker]を参照）の例では）。多くの場合、このようなリストは脅威データクリアリングハウスなどのサードパーティによって配布または共有されています。

e. Because hosts infected by bots 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 role accounts specified in RFC 2142 [RFC2142], such as abuse@, or to other relevant addresses such as to abuse or security addresses specified by the site as part of its WHOIS (or other) contact data.

e. ボットに感染したホストは、スパムの送信やDDoS攻撃への参加に頻繁に使用されるため、これらのホストにサービスを提供するISPは通常、悪意のあるネットワークトラフィックについて苦情を受け取ります。これらの苦情は、RFC 2142 [RFC2142]で指定されているロールアカウント（abuse @など）に送信される場合と、WHOIS（またはその他の）連絡先データの一部としてサイトで指定された虐待アドレスやセキュリティアドレスなどの他の関連アドレスに送信される場合があります。

f. ISPs may also discover likely bot-infected hosts located on other networks. Thus, when legally permissible in a particular market region, it may be worthwhile for ISPs to share information relating to those compromised hosts with the relevant remote network operator, security researchers, and blocklist operators.

f. ISPは、他のネットワーク上にあるボットに感染している可能性のあるホストを発見することもあります。したがって、特定の市場地域で法的に許可されている場合、ISPがこれらの侵害されたホストに関する情報を関連するリモートネットワークオペレーター、セキュリティリサーチャー、およびブロックリストオペレーターと共有することは価値があります。

g. ISPs may operate or subscribe to services that provide "sinkholing" or "honeynet" capabilities. This may enable the ISP to obtain near-real-time lists of bot-infected hosts as they attempt to join a larger botnet or propagate to other hosts on a network.

g. ISPは、「シンクホール」または「ハニーネット」機能を提供するサービスを運用またはサブスクライブする場合があります。これにより、ISPは、ボットに感染したホストが大規模なボットネットに参加したり、ネットワーク上の他のホストに伝播したりする際に、ほぼリアルタイムのリストを取得できます。

h. ISP industry associations should examine the possibility of collating statistics from ISP members in order to provide good statistics about bot infections based on real ISP data.

h. ISP業界団体は、実際のISPデータに基づいてボット感染に関する適切な統計を提供するために、ISPメンバーからの統計を照合する可能性を検討する必要があります。

i. An Intrusion Detection System (IDS) can be a useful tool to actually help identify the malware. An IDS tool such as Snort (open source IDS platform; see [Snort]) can be placed in a walled garden and used to analyze end user traffic to confirm malware type. This will help with remediation of the infected device.

i. 侵入検知システム（IDS）は、実際にマルウェアを特定するのに役立つ便利なツールです。 Snort（オープンソースIDSプラットフォーム。[Snort]を参照）などのIDSツールを壁に囲まれた庭に置き、エンドユーザーのトラフィックを分析してマルウェアの種類を確認するために使用できます。これは、感染したデバイスの修復に役立ちます。

5. Notification to Internet Users

5. インターネットユーザーへの通知

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. An ISP should decide the most appropriate method or methods for providing notification to one or more of their customers or Internet users, depending upon a range of factors including the technical capabilities of the ISP, the technical attributes of its network, financial considerations, available server resources, available organizational resources, the number of likely infected hosts detected at any given time, and the severity of any possible threats. Such notification methods may include one or more of the methods described in the following subsections, as well as other possible methods not described below.

ISPがボットを検出した場合、またはボットの可能性が高い場合は、インターネットユーザーにボット関連の問題がある可能性があることを通知するための手順を実行する必要があります。 ISPは、ISPの技術的能力、ネットワークの技術的属性、財務上の考慮事項、利用可能なサーバーなど、さまざまな要因に応じて、1人以上の顧客またはインターネットユーザーに通知を提供するための最も適切な方法を決定する必要がありますリソース、利用可能な組織リソース、ある時点で検出された感染の可能性があるホストの数、および可能性のある脅威の重大度。そのような通知方法には、以下のサブセクションで説明する1つ以上の方法と、以下で説明しない他の可能な方法が含まれます。

It is important to note that none of these methods are guaranteed to be one hundred percent successful and that each has its own set of limitations. In addition, in some cases, an ISP may determine that a combination of two or more methods is most appropriate and effective and reduces the chance that malware may block a notification. As such, the authors recommend the use of multiple notification methods. Finally, notification is also considered time sensitive; if the user does not receive or view the notification in a timely fashion, 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 a period long enough to allow any commonly used bot detection technology to be able to accurately link an infected IP address to a subscriber. This record should only be maintained for a period of time that is necessary to support bot detection, but no longer, in order to protect the privacy of the individual subscriber.

これらの方法が100％成功することは保証されておらず、それぞれに独自の制限セットがあることに注意することが重要です。さらに、場合によっては、ISPは2つ以上の方法の組み合わせが最も適切で効果的であると判断し、マルウェアが通知をブロックする可能性を減らします。そのため、著者は複数の通知方法の使用を推奨しています。最後に、通知も時間に敏感であると見なされます。ユーザーがタイムリーに通知を受信または表示しない場合、特定のボットが攻撃を開始したり、ユーザーを悪用したり、その他の害を及ぼす可能性があります。可能であれば、加入者が最初にサービスにサインアップするときに、ISPは適切な通信手段を確立する必要があります。通知プロセスの一部として、ISPは、一般的に使用されているボット検出テクノロジーが感染したIPアドレスをサブスクライバーに正確にリンクできるように十分長い期間、サブスクライバーへのIPアドレスの割り当ての記録を維持する必要があります。このレコードは、ボットの検出をサポートするために必要な期間だけ保持されるべきですが、個々のサブスクライバーのプライバシーを保護するためには保持されません。

One important factor to bear in mind is that notification to end users needs to be resistant to potential spoofing. This should be done to protect, as reasonably as possible, against the potential of legitimate notifications being spoofed and/or used by parties with intent to perform additional malicious attacks against victims of malware or even to deliver additional malware.

心に留めておくべき重要な要素の1つは、エンドユーザーへの通知は、なりすましの可能性に耐える必要があることです。これは、正当な通知がなりすまし、および/またはマルウェアの被害者に対して追加の悪意のある攻撃を実行したり、追加のマルウェアを配信したりする意図で使用される可能性から、可能な限り合理的に保護するために行う必要があります。

It should be possible for the end user to indicate the preferred means of notification on an opt-in basis for that notification method. It is recommended that the end user should not be allowed to opt out of notification entirely.

エンドユーザーは、その通知方法のオプトインベースで通知の優先手段を示すことができるはずです。エンドユーザーが通知を完全にオプトアウトできないようにすることをお勧めします。

When users are notified, an ISP should endeavor to give as much information as possible to the end user regarding which bot detection methods are employed at the ISP, consonant with not providing information to those creating or deploying the bots so that they would be able to avoid detection.

ユーザーに通知されたとき、ISPは、ボットを作成またはデプロイしている人に情報を提供しないように、ISPで使用されているボット検出方法に関して、エンドユーザーにできるだけ多くの情報を提供するよう努めるべきです。検出を避けます。

5.1. Email Notification

5.1. 電子メール通知

This is a 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 the one they 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 method by 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 fraudulent emails to the users. This technique of social 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 access the user's email account and delete the email before it is read by the user.

これは、ISPが使用する一般的な通知形式です。電子メールを使用することの1つの欠点は、妥当な時間枠内に表示されることが保証されていないことです。ユーザーは、ISPに提供したものとは異なるプライマリ電子メールアドレスを使用している可能性があります。さらに、一部のISPは、インターネットサービスのバンドルの一部として電子メールアカウントをまったく提供していないか、ネットワークのインターネットユーザーのプライマリ電子メールアドレスを要求または保持するための方法や方法を必要としません。別の可能性としては、ユーザー、メールクライアント、メールサーバーがそのような通知をスパムとして判断または分類する可能性があり、メッセージを削除したり、ユーザーが定期的に確認できないメールフォルダーにそれをファイルしたりする可能性があります。 /またはタイムリーに。ボットマスターは、ISPまたは信頼できる送信者になりすまし、ユーザーに詐欺メールを送信することも知られています。このソーシャルエンジニアリングの手法は、新しいボットの蔓延につながることがよくあります。最後に、ユーザーのメール認証情報が侵害された場合、ハッカーやボットはユーザーのメールアカウントにアクセスし、ユーザーが読み取る前にメールを削除する可能性があります。

5.2. Telephone Call Notification

5.2. 電話通知

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 calls, 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 host 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 therefore 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 to a user, that user is very likely to lack the necessary technical expertise to understand or be able to effectively deal with the threat.

電話は、特にリスクの高い状況での効果的なコミュニケーション手段となります。ただし、時間、お金、組織のリソース、サーバーのリソース、またはその他の手段で測定される通話の数が多いため、通話は実行できない場合があります。また、ユーザーが電話に出るという保証はありません。 ISPから呼び出された電話番号に感染したコンピューティングデバイスが応答できる範囲で、そのホストのボットは、切断したり、転送したり、着信呼び出しを妨害したりする可能性があります。ユーザーは、そのような電話通知をテレマーケティングコールと解釈して、それを歓迎しないか、まったくコールを受け入れない場合もあります。最後に、ISPの代表者がユーザーに接続して話しかけることができたとしても、そのユーザーは脅威を理解したり効果的に対処したりするために必要な技術的専門知識を欠いている可能性が非常に高いです。

5.3. Postal Mail Notification

5.3. 郵便通知

This form of notification is probably the least popular and effective means of communication, due to preparation time, delivery time, the cost of printing and paper, and the cost of postage.

この形式の通知は、準備時間、納期、印刷と紙のコスト、および送料のコストのため、おそらく最も一般的で効果的なコミュニケーション手段ではありません。

5.4. Walled Garden Notification

5.4. ウォールドガーデン通知

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. A walled garden implementation can range from strict to leaky. In a strict walled garden environment, access to most Internet resources is typically limited by the ISP. In contrast, a leaky walled garden environment permits access to all Internet resources, except those deemed malicious, and ensures access to those that can be used to notify users of infections.

ウォールドガーデンにユーザーを配置することは、ISPがユーザーに通知するために使用できる別のアプローチです。 「ウォールドガーデン」とは、加入者が利用を許可されている情報とサービス、および付与されているネットワークアクセス許可を制御する環境を指します。ウォールドガーデンの実装は、厳密なものから漏れやすいものまでさまざまです。厳格な壁に囲まれた庭の環境では、ほとんどのインターネットリソースへのアクセスは通常ISPによって制限されています。対照的に、壁に漏れのある庭の環境では、悪意があると見なされたものを除くすべてのインターネットリソースへのアクセスが許可され、ユーザーに感染を通知するために使用できるリソースへのアクセスが保証されます。

Walled gardens are effective because it is possible to notify the user and simultaneously block all communication between the bot and the command and control channel. While in many cases the user is almost guaranteed to view the notification message and take any appropriate remediation actions, this approach can pose other challenges. For example, it is not always the case that a user is actively utilizing a host that implements a web browser, has a web browser actively running on it, or operates another application that uses ports that are redirected to the walled garden. In one example, a user could be playing a game online, via the use of a dedicated, Internet-connected game console. In another example, the user may not be using a host 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 that are not subject to the typical restrictions of a walled garden, which could well prove to be an onerous task from an operational perspective.

ウォールドガーデンは、ユーザーに通知し、同時にボットとコマンドアンドコントロールチャネル間のすべての通信をブロックできるため、効果的です。多くの場合、ユーザーは通知メッセージを表示して適切な修正アクションを実行することがほぼ保証されていますが、このアプローチは他の課題を引き起こす可能性があります。たとえば、ユーザーがWebブラウザーを実装するホストをアクティブに利用している、Webブラウザーをアクティブに実行している、壁に囲まれた庭にリダイレクトされるポートを使用する別のアプリケーションを操作しているとは限りません。一例では、ユーザは、インターネットに接続された専用のゲームコンソールを使用して、オンラインでゲームをプレイすることができる。別の例では、ユーザーは壁に囲まれた庭に置かれているときにWebブラウザーを備えたホストを使用していない可能性があり、代わりに電話で会話中か、Voice over IP（VoIP ）あるタイプのデバイス。その結果、ISPは、ウォールドガーデンの一般的な制限の影響を受けない、潜在的に長いドメインのホワイトリストを維持する必要性を感じる可能性があります。これは、運用の観点から見ると面倒な作業であることがよくわかります。

For these reasons, the implementation of a leaky walled garden makes more sense, but a leaky walled garden has a different set of drawbacks. The ISP has to assume that the user will eventually use a web browser to acknowledge the notification; otherwise, the user will remain in the walled garden and not know it. If the intent of the leaky walled garden is solely to notify the user about the bot infection, then the leaky walled garden is not ideal because notification is time sensitive, and the user may not receive the notification until the user invokes a request for the targeted service and/or resource. This means the bot can potentially do more damage. Additionally, the ISP has to identify which services and/or resources to restrict for the purposes of notification. This does not have to be resource specific and can be time based and/or policy based. An example of how notification could be made on a timed basis could involve notification for all HTTP requests every 10 minutes, or show the notification for one in five HTTP requests.

これらの理由から、壁に漏れのある庭の実装はより理にかなっていますが、壁に漏れのある庭にはさまざまな欠点があります。 ISPは、ユーザーが最終的にWebブラウザを使用して通知を確認すると想定する必要があります。さもなければ、ユーザーは壁に囲まれた庭に留まり、それを知らないでしょう。壁に囲まれた庭の意図がボットの感染についてユーザーに通知することだけである場合、壁に囲まれた庭は理想的ではありません。通知は時間に敏感であり、ユーザーがターゲットへのリクエストを呼び出すまでユーザーは通知を受信しない可能性があります。サービスおよび/またはリソース。つまり、ボットは潜在的にさらに多くのダメージを与える可能性があります。さらに、ISPは通知の目的で制限するサービスやリソースを特定する必要があります。これは、リソース固有である必要はなく、時間ベースおよび/またはポリシーベースにすることができます。通知を時間ベースで行う方法の例には、10分ごとのすべてのHTTPリクエストの通知が含まれる場合や、HTTPリクエストの5分の1の通知が表示される場合があります。

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 primary 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 host and that other online activities that they would like to resume are more important. Exit from the walled garden may also involve a process to verify that it is indeed the user who is requesting exit from the walled garden and not the bot.

ISPには、ユーザーを壁に囲まれた庭からいつ退去させるかを決定するいくつかのオプションがあります。 1つのアプローチは、ユーザーがいつ終了するかを決定できるようにすることです。このオプションは、ウォールドガーデンの主な目的がユーザーに通知し、修復に関する情報のみを提供することである場合に推奨されます。特に、通知は修復の成功を保証するものではありません。また、何らかの理由で、ユーザーが時間をかけてホストを修正できないと判断し、再開したい他のオンライン活動の方が重要であると判断する場合もあります。ウォールドガーデンからの退出には、ボットではなくウォールドガーデンからの退出を要求しているのが実際にユーザーであることを確認するプロセスが含まれる場合もあります。

Once the user acknowledges the notification, they may decide either to remediate and exit the walled garden or to exit the walled garden without remediating the issue. Another approach may be to enforce a stricter policy and require the user to clean the host 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 host (in the style of a virus scan, rather than a port scan) 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 the user might have multiple hosts sharing a single IP address, such as via a common home gateway device that performs Network Address Translation (NAT). In such a case, the ISP may need to determine from user feedback, or other means, that all affected hosts have been remediated, which may or may not be technically feasible.

ユーザーは通知を確認すると、壁に囲まれた庭園を修復して終了するか、問題を解決せずに壁に囲まれた庭園を終了するかを決定できます。別のアプローチとしては、より厳しいポリシーを適用し、壁に囲まれた庭から出ることを許可する前にホストをクリーンアップするようユーザーに要求することができますが、ボットのタイプ、ボットが使用する難読化技術、および/または他の要因の範囲。したがって、ISPは、感染したホストをスキャンし（ポートスキャンではなくウイルススキャンのスタイルで）、まだ感染しているかどうか、またはボットが無効化または削除されているというユーザーの判断に依存するツールをサポートする必要がある場合もあります。 。このアプローチの1つの課題は、ネットワークアドレス変換（NAT）を実行する共通のホームゲートウェイデバイスを介するなどして、ユーザーが複数のホストで単一のIPアドレスを共有している可能性があることです。このような場合、ISPは、ユーザーのフィードバックまたはその他の手段から、影響を受けるすべてのホストが修復されたことを判断する必要がある場合があります。これは、技術的に可能である場合とそうでない場合があります。

Finally, when a walled garden is used, a list of well-known addresses for both operating system vendors and security vendors should be created and maintained in a white list that permits access to these sites. This can be important for allowing access from the walled garden by end users in search of operating system and application patches. It is recommended that walled gardens be seriously considered as a method of notification as they are easy to implement and proven to be effective as a means of getting end user attention.

最後に、ウォールドガーデンを使用する場合は、オペレーティングシステムベンダーとセキュリティベンダーの両方の既知のアドレスのリストを作成し、これらのサイトへのアクセスを許可するホワイトリストで維持する必要があります。これは、オペレーティングシステムとアプリケーションのパッチを求めてエンドユーザーが壁に囲まれた庭からアクセスできるようにするために重要です。ウォールドガーデンは実装が簡単で、エンドユーザーの注意を引く手段として効果的であることが証明されているため、通知方法として真剣に検討することをお勧めします。

5.5. Instant Message Notification

5.5. インスタントメッセージ通知

IM provides the ISP with a simple means to communicate with the user. There are several advantages to using IM that make 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 a cost-effective means to communicate with users automatically from an IM alert system or by a manual process, involving the ISP's support staff. Ideally, the ISP should allow the user to register their IM identity in an ISP account management system and grant permission to be contacted via this means. If the IM service provider supports off-line messaging, then the user can be notified regardless of whether they are currently logged into the IM system.

IMは、ISPにユーザーと通信する簡単な手段を提供します。 IMを使用することにはいくつかの利点があり、魅力的なオプションになります。 ISPがIMサービスを提供し、ユーザーがそれに加入している場合、ユーザーは簡単に通知を受けることができます。 IMベースの通知は、IMアラートシステムから自動的に、またはISPのサポートスタッフが関与する手動プロセスによって、ユーザーと通信するための費用効果の高い手段となります。理想的には、ISPは、ユーザーが自分のIM IDをISPアカウント管理システムに登録し、この手段を介して連絡を受ける許可を与えることを許可する必要があります。 IMサービスプロバイダーがオフラインメッセージングをサポートしている場合、ユーザーが現在IMシステムにログインしているかどうかに関係なく、ユーザーに通知できます。

There are several drawbacks with this communications method. There is a high probability that a subscriber may interpret the communication to be spim and thus ignore it. Also, 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. Even in those cases where a user does have an IM address, they may not be signed onto that IM system when the notification is attempted. There may be a privacy concern on the part of users when such an IM notification must be transmitted over a third-party network and/or IM service. As such, should this method be used, the notification should be discreet and not include any PII in the notification itself.

この通信方法にはいくつかの欠点があります。加入者が通信をスピムであると解釈して、それを無視する可能性が高いです。また、すべてのユーザーがIMを使用するわけではなく、ユーザーがIM IDをISPに提供しない場合があるため、いくつかの代替手段を使用する必要があります。ユーザーがIMアドレスを持っている場合でも、通知が試行されたときに、そのIMシステムにサインオンされない場合があります。このようなIM通知をサードパーティのネットワークやIMサービス経由で送信する必要がある場合、ユーザーのプライバシーに関する懸念があるかもしれません。そのため、このメソッドを使用する場合、通知は目立たないようにし、通知自体にPIIを含めないでください。

5.6. Short Message Service (SMS) Notification

5.6. ショートメッセージサービス（SMS）通知

SMS allows the ISP to send a brief description of the problem to notify the user of the issue, typically to a mobile device such as a mobile phone or smart phone. Ideally, the ISP should allow the user to register their mobile number and/or SMS address in an ISP account management system and grant permission to be contacted via this means. The primary advantage of SMS is that users are familiar with receiving text messages and are likely to read them. However, users may not act on the notification immediately if they are not in front of their host at the time of the SMS notification.

SMSを使用すると、ISPは問題の簡単な説明を送信して、通常は携帯電話やスマートフォンなどのモバイルデバイスに問題をユーザーに通知できます。理想的には、ISPは、ユーザーが携帯電話番号やSMSアドレスをISPアカウント管理システムに登録し、この方法で連絡を取る許可を与えることを許可する必要があります。 SMSの主な利点は、ユーザーがテキストメッセージの受信に慣れており、テキストメッセージを読む可能性が高いことです。ただし、SMS通知時にユーザーがホストの前にいなかった場合、ユーザーは通知にすぐに対応できません。

One disadvantage is that ISPs may have to follow up with an alternate means of notification if not all of the necessary information may be conveyed in one message, given constraints on the number of characters in an individual message (typically 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 network service providers or use a third-party SMS clearinghouse (relay) to notify users. In both cases, an ISP may incur fees related to SMS notifications, depending upon the method used to send the notifications. An additional downside is that SMS messages sent to a user may result in a charge to the user by their wireless provider, depending upon the plan to which they subscribe and the country in which the user resides. Another minor 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.

1つの欠点は、個々のメッセージの文字数（通常は140文字）に制限がある場合、必要な情報のすべてが1つのメッセージで伝えられない場合、ISPは別の通知方法を使用する必要があることです。 SMSのもう1つの欠点は、それに関連するコストです。 ISPは、独自のSMSゲートウェイを構築して、さまざまなワイヤレスネットワークサービスプロバイダーとやり取りするか、サードパーティのSMSクリアリングハウス（リレー）を使用してユーザーに通知する必要があります。どちらの場合も、ISPは、通知の送信方法に応じて、SMS通知に関連する料金を負担する場合があります。もう1つの欠点は、ユーザーに送信されたSMSメッセージは、ユーザーが加入しているプラ​​ンとユーザーが居住する国によっては、ワイヤレスプロバイダーからユーザーに料金が発生する可能性があることです。もう1つのマイナーな欠点は、意図したユーザーが携帯電話番号を変更しても、ISPで更新するのを忘れた場合に、間違ったユーザーに通知する可能性があることです。

There are several other drawbacks with this communications method. There is a high probability that subscriber may interpret the communication to be spam and thus ignore it. Also, not every user uses SMS, and/or the user may not provide their SMS address or mobile number to the ISP. Even in those cases where a user does have an SMS address or mobile number, their device may not be powered on or otherwise available on a wireless network when the notification is attempted. There may also be a privacy concern on the part of users when such an SMS notification must be transmitted over a third-party network and/or SMS clearinghouse. As such, should this method be used, the notification should be discreet and not include any PII in the notification itself.

この通信方法には、他にもいくつかの欠点があります。加入者が通信をスパムであると解釈して、それを無視する可能性が高いです。また、すべてのユーザーがSMSを使用しているわけではなく、ユーザーがSMSアドレスや携帯電話番号をISPに提供していない場合もあります。ユーザーがSMSアドレスまたは携帯電話番号を持っている場合でも、通知が試行されたときに、デバイスの電源がオンになっていないか、ワイヤレスネットワークでデバイスを使用できない場合があります。このようなSMS通知をサードパーティのネットワークやSMSクリアリングハウスを介して送信する必要がある場合、ユーザーのプライバシーに関する懸念が生じることもあります。そのため、このメソッドを使用する場合、通知は目立たないようにし、通知自体にPIIを含めないでください。

5.7. Web Browser Notification

5.7. Webブラウザ通知

Near-real-time notification to the user's web browser is another technique that may be utilized for notifying the user [RFC6108], 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 would, by definition. However, as with a walled garden notification, there is no guarantee that a user is making use of a web browser at any given time, 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, VoIP calls, etc. (as noted in Section 5.4).

ユーザーのWebブラウザーへのほぼリアルタイムの通知は、ユーザーへの通知に使用できるもう1つの手法です[RFC6108]。このようなシステムの動作方法は、このドキュメントの範囲外です。そのような通知は、ウォールドガーデンの通知と比べて、ウォールドガーデンの定義と同じ方法でトラフィックを特定の宛先リストに制限しないという点で、比較優位性があります。ただし、ウォールドウォール通知と同様に、ユーザーがいつでもWebブラウザーを使用しているとは限りませんが、そのようなシステムは、ブラウザーが最終的に使用されたときに確実に通知を提供できます。壁に囲まれた庭と比較して、オンラインゲームやVoIP通話などの非Webセッションを中断するリスクがないため、インターネットユーザーの観点からはおそらくWebブラウザー通知が好まれます（セクション5.4に記載）。 ）。

There are alternative methods of web browser notification offered commercially by a number of vendors. Many of the techniques used are proprietary, and it is not within the scope of this document to describe how they are implemented. These techniques have been successfully implemented at several ISPs.

多くのベンダーによって商業的に提供されているWebブラウザー通知の代替方法があります。使用されるテクニックの多くは独自仕様であり、それらがどのように実装されるかを説明することはこのドキュメントの範囲内ではありません。これらの手法は、いくつかのISPで正常に実装されています。

It should be noted that web notification is only intended to notify devices running a web browser.

Web通知は、Webブラウザーを実行しているデバイスに通知することのみを目的としていることに注意してください。

5.8. Considerations for Notification to Public Network Locations

5.8. パブリックネットワークロケーションへの通知に関する考慮事項

Delivering a notification to a location that provides a shared public network, such as a train station, public square, coffee shop, or similar location may be of low value since the users connecting to such networks are typically highly transient and generally not known to site or network administrators. For example, a system may detect that a host on such a network has a bot, but by the time a notification is generated, that user has departed from the network and moved elsewhere.

鉄道駅、公共広場、コーヒーショップ、または同様の場所などの共有パブリックネットワークを提供する場所に通知を配信することは、そのようなネットワークに接続するユーザーは通常非常に一時的であり、一般にサイトに知られていないため、価値が低い場合があります。またはネットワーク管理者。たとえば、そのようなネットワーク上のホストにボットがあることをシステムが検出したとしても、通知が生成されるまでに、そのユーザーはネットワークを離れて別の場所に移動したことになります。

5.9. Considerations for Notification to Network Locations Using a Shared IP Address

5.9. 共有IPアドレスを使用したネットワークロケーションへの通知に関する考慮事項

Delivering a notification to a location that accesses the Internet routed through one or more shared public IP addresses may be of low value since it may be quite difficult to differentiate between users when providing a notification. For example, on a business network of 500 users, all sharing one public IP address, it may be sub-optimal to provide a notification to all 500 users if you only need one specific user to be notified and take action. As a result, such networks may find value in establishing a localized bot detection and notification system, just as they are likely to also establish other localized systems for security, file sharing, email, and so on.

1つ以上の共有パブリックIPアドレスを介してルーティングされたインターネットにアクセスする場所に通知を配信することは、通知を提供するときにユーザーを区別するのが非常に難しいため、価値が低い場合があります。たとえば、1つのパブリックIPアドレスをすべて共有する500ユーザーのビジネスネットワークでは、特定の1人のユーザーのみに通知してアクションを実行する必要がある場合、500ユーザーすべてに通知を提供するのは最適ではない場合があります。その結果、セキュリティ、ファイル共有、電子メールなどの他のローカライズされたシステムを確立する可能性が高いのと同じように、そのようなネットワークは、ローカライズされたボット検出および通知システムを確立することに価値を見出します。

However, should an ISP implement some form of notification to such networks, it may be better to simply send notifications to a designated network administrator at the site. In such a case, the local network administrator may like to receive additional information in such a notification, such as a date and timestamp, the source port of the infected system, and malicious sites and ports that may have been visited.

ただし、ISPがこのようなネットワークへの通知を何らかの形で実装する場合は、サイトの指定されたネットワーク管理者に通知を送信する方がよい場合があります。そのような場合、ローカルネットワーク管理者は、日付とタイムスタンプ、感染したシステムの送信元ポート、アクセスされた可能性のある悪意のあるサイトとポートなどの追加情報を通知で受け取りたいと思うかもしれません。

5.10. Notification and End User Expertise

5.10. 通知とエンドユーザーの専門知識

The ultimate effectiveness of any of the aforementioned forms of notification is heavily dependent upon both the expertise of the end user and the wording of any such notification. For example, while a user may receive and acknowledge a notification, that user may lack the necessary technical expertise to understand or be able to deal effectively with the threat. As a result, it is important that such notifications use clear and easily understood language, so that the majority of users (who are non-technical) may understand the notification. In addition, a notification should provide easily understood guidance on how to remediate a threat as described in Section 6, potentially with one path for technical users to take and another for non-technical users.

前述の通知形式の最終的な効果は、エンドユーザーの専門知識とそのような通知の文言の両方に大きく依存します。たとえば、ユーザーが通知を受信して​​確認する一方で、脅威を理解したり、脅威に効果的に対処したりするために必要な技術的専門知識が不足している場合があります。結果として、大部分のユーザー（技術者ではない）が通知を理解できるように、そのような通知は明確で理解しやすい言語を使用することが重要です。さらに、通知には、セクション6で説明されている脅威の修復方法に関する簡単に理解できるガイダンスが含まれている必要があります。テクニカルユーザーが使用するパスと非テクニカルユーザーが使用するパスが含まれている可能性があります。

6. Remediation of Hosts Infected with a Bot

6. ボットに感染したホストの修復

This section covers the different options available to remediate a host, 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 hosts is infected with a bot, and now may provide some recommended means to clean the host. The generally recommended approach is to provide the necessary tools and education to the user so that they may perform bot remediation themselves, particularly given the risks and difficulties inherent in attempting to remove a bot.

このセクションでは、ホストの修正に使用できるさまざまなオプションについて説明します。これは、ボットを削除、無効化、またはその他の方法で無害にすることを意味します。この手順の前に、ISPはボットを検出し、ホストの1つがボットに感染していることをユーザーに通知し、ホストをクリーンアップするための推奨される手段を提供する場合があります。一般的に推奨されるアプローチは、ユーザーに必要なツールと教育を提供することです。これにより、特にボットの削除を試みる際に固有のリスクと困難を考慮して、ユーザーがボット修復を自分で実行できるようになります。

For example, this may include the creation of a special web site with security-oriented content that is dedicated for this purpose. This should be a well-publicized security web site to which a user with a bot infection can be directed to for remediation. This security web site 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 attempt to clean their host and information on how users can keep the host free of future infections. The security web site should also have a guided process that takes non-technical users through the remediation process, on an easily understood, step-by-step basis.

たとえば、この目的に特化したセキュリティ指向のコンテンツを含む特別なWebサイトの作成が含まれる場合があります。これは、ボットに感染したユーザーを修正のために誘導できる、広く知られたセキュリティWebサイトである必要があります。このセキュリティWebサイトは、ユーザーに通知された理由を明確に説明する必要があり、ボットとは何か、ボットがもたらす脅威の説明を含めることができます。ホストをクリーンアップするためにユーザーが実行する必要がある手順の明確な説明と、ユーザーがホストを将来の感染から解放する方法に関する情報が必要です。セキュリティWebサイトには、技術者以外のユーザーが簡単に理解できる段階的な修正プロセスを案内するガイド付きプロセスも必要です。

In terms of the text used to explain what bots are and the threats that they pose, something simple such as this may suffice:

ボットとは何か、およびボットがもたらす脅威を説明するために使用されるテキストに関しては、次のような単純なもので十分です。

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 may notice regular disk activity even when you are not doing anything. Ignoring this problem is risky to you and your personal information. Thus, bots need to be removed to protect your data and your personal information.

ボットとは何ですか？ボットはソフトウェアであり、通常は知らないうちにマシンにインストールされ、スパムを送信したり、個人情報を盗んだりします。コンピュータの実行速度が通常よりも遅いことに気づいたり、何もしていなくても定期的なディスクアクティビティに気づいたりすることがありますが、それらを見つけるのは非常に困難です。この問題を無視することは、あなたとあなたの個人情報にとって危険です。したがって、データと個人情報を保護するためにボットを削除する必要があります。

Many bots are designed to work in a very stealthy manner, and as such, there may be a need to make sure that the Internet user understands the magnitude of the threat faced despite the stealthy nature of the bot.

多くのボットは非常にステルスな方法で動作するように設計されているため、ボットのステルス的な性質にもかかわらず、インターネットユーザーが直面する脅威の大きさを確実に理解する必要がある場合があります。

It is also important to note that it may not be immediately apparent to the Internet user precisely which devices have been infected with a particular bot. This may be due to the user's home network configuration, which may encompass several hosts, where a home gateway that performs Network Address Translation (NAT) to share a single public IP address has been used. Therefore, any of these devices can be infected with a bot. The consequence of this for an ISP is that remediation advice may not ultimately be immediately actionable by the Internet user, as that user may need to perform additional investigation within their own home network.

また、特定のボットに感染したデバイスが正確にインターネットユーザーにすぐにはわからない場合があることに注意することも重要です。これは、ネットワークアドレス変換（NAT）を実行して単一のパブリックIPアドレスを共有するホームゲートウェイが使用されている複数のホストを含​​むユーザーのホームネットワーク構成が原因である可能性があります。したがって、これらのデバイスはいずれもボットに感染する可能性があります。 ISPの場合、この結果、インターネットユーザーは自分のホームネットワーク内で追加の調査を行う必要がある場合があるため、最終的に修復のアドバイスをすぐに実行できない場合があります。

An added complication is that the user may have a bot infection on a device such as a video console, multimedia system, appliance, or other end user computing device that does not have a typical desktop computing interface. As a result, diligence needs to be taken by the ISP where possible such that it can identify and communicate the specific nature of the device that has been infected with a bot and provide further appropriate remediation advice. If the ISP cannot pin down the device or identify its type, then it should make it clear to the user that any initial advice given is generic and further advice can be given (or is available) once the type of infected device is known.

さらに複雑なのは、ユーザーがビデオコンソール、マルチメディアシステム、アプライアンス、または一般的なデスクトップコンピューティングインターフェイスを持たない他のエンドユーザーコンピューティングデバイスなどのデバイスでボットに感染する可能性があることです。その結果、ISPがボットに感染したデバイスの特定の性質を識別および伝達し、さらに適切な修正アドバイスを提供できるように、可能な限りISPが注意を払う必要があります。 ISPがデバイスを特定できないか、デバイスのタイプを識別できない場合は、初期のアドバイスは一般的なものであり、感染したデバイスのタイプが判明すると、さらにアドバイスを提供できる（または利用できる）ことをユーザーに明確に伝える必要があります。

There are a number of forums that exist online to provide security-related support to end users. These forums are staffed by volunteers and often are focused around the use of a common tool set to help end users to remediate hosts infected with malware. It may be advantageous to ISPs to foster a relationship with one or more forums, perhaps by offering free hosting or other forms of sponsorship.

エンドユーザーにセキュリティ関連のサポートを提供するために、オンライン上に存在するフォーラムがいくつかあります。これらのフォーラムにはボランティアが配置されており、多くの場合、エンドユーザーがマルウェアに感染したホストを修復するのに役立つ一般的なツールセットの使用に重点が置かれています。 ISPが1つ以上のフォーラムとの関係を促進することは、おそらく無料のホスティングまたは他の形のスポンサーシップを提供することによって、有利になるかもしれません。

It is also important to keep in mind that not all users will be technically adept, as noted in Section 5.10. As a result, it may be more effective to provide a range of suggestion options for remediation. This may include, for example, a very detailed "do it yourself" approach for experts, a simpler guided process for the average user, and even assisted remediation as described in Section 6.2.

セクション5.10に記載されているように、すべてのユーザーが技術的に熟練しているわけではないことも覚えておくことが重要です。その結果、修復のためのさまざまな提案オプションを提供することがより効果的である可能性があります。これには、たとえば、専門家のための非常に詳細な「自分で行う」アプローチ、平均的なユーザーのためのより簡単なガイド付きプロセス、さらにはセクション6.2で説明されている修正支援が含まれる場合があります。

6.1. Guided Remediation Process

6.1. ガイド付きの修正プロセス

Minimally, the Guided Remediation Process should include the following goals, with options and/or recommendations for achieving them:

ガイド付き是正プロセスには、最低限、次の目標と、それらを達成するためのオプションや推奨事項を含める必要があります。

1. Back up personal files. For example:

1. 個人ファイルをバックアップします。例えば：

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 backup software utility, which may be part of your Operating System (OS). You can back up your files to a USB Thumb Drive (aka USB Key), a writable CD/DVD-ROM, an external hard drive, a network file server, or an Internet-based backup service.

開始する前に、重要なデータをすべてバックアップしてください。 （とにかく定期的にこれを行う必要があります。）ファイルは、手動で、またはオペレーティングシステム（OS）の一部であるシステムバックアップソフトウェアユーティリティを使用してバックアップできます。 USBサムドライブ（別名USBキー）、書き込み可能なCD / DVD-ROM、外付けハードドライブ、ネットワークファイルサーバー、またはインターネットベースのバックアップサービスにファイルをバックアップできます。

It may be advisable to suggest that the user backup is performed onto separate backup media or devices if they suspect bot infection.

ボットの感染が疑われる場合は、ユーザーバックアップを個別のバックアップメディアまたはデバイスに実行することをお勧めします。

2. Download OS patches and Anti-Virus (A/V) software updates. For example, links could be provided to Microsoft Windows updates, Apple Mac OS updates, or other major operating systems that are relevant to users and their devices.

2. OSパッチとアンチウイルス（A / V）ソフトウェアアップデートをダウンロードします。たとえば、Microsoft Windowsアップデート、Apple Mac OSアップデート、またはユーザーとそのデバイスに関連するその他の主要なオペレーティングシステムへのリンクを提供できます。

3. Configure the host 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.

3. OS、A / V、およびその他の一般的なWebブラウザー（Microsoft Internet Explorer、Mozilla Firefox、Apple Safari、Opera、Google Chromeなど）のアップデートを自動的にインストールするようにホストを構成します。

4. Get professional assistance if they are unable to remove the bots themselves. If purchasing professional assistance, then the user should be encouraged to predetermine how much they are willing to pay for that help. For example, if the host that is being remediated is old and can easily be replaced with a new, faster, larger, and more reliable system for a certain cost, then it makes no sense to spend more than that cost to fix the old host. On the other hand, if the customer has a brand-new host, it might make perfect sense to spend the money to attempt to remediate it.

4. ボットを自分で削除できない場合は、専門家の支援を受けてください。専門家の支援を購入する場合、ユーザーは、その支援に対して支払う金額を事前に決定するように奨励されるべきです。たとえば、修正中のホストが古く、一定のコストでより速く、より大きく、より信頼性の高い新しいシステムに簡単に交換できる場合、そのコストを超えて古いホストを修正しても意味がありません。 。一方、顧客が新しいホストを持っている場合、そのホストを修正するためにお金を使うことは完全に理にかなっています。

5. To continue, regardless of whether the user or a knowledgeable technical assistant is working on remediating the host, the 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 hosts in a home network). Sometimes, as in cases where there is only a single directly attached host, or the user has been noticing problems with one of their hosts, this can be easy. Other times, it may be more difficult, especially if there are no clues as to which host is infected. 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.

5.続行するには、ユーザーまたは知識の豊富なテクニカルアシスタントがホストの修正に取り組んでいるかどうかに関係なく、最初のタスクは、感染の可能性がある複数のマシンのうち、注意が必要なマシンを特定することです（複数のホストの一般的な場合）。ホームネットワークで）。場合によっては、直接接続されているホストが1つしかない場合や、ユーザーがいずれかのホストの問題に気付いている場合のように、これは簡単です。場合によっては、特にどのホストが感染しているかの手掛かりがない場合は、さらに困難になることがあります。ユーザーがホームゲートウェイ/ルーターの背後にいる場合、最初のタスクは、感染しているマシンを確認することです。場合によっては、ユーザーはすべてのマシンをチェックして感染したマシンを特定する必要があります。

6. ISPs may also look at offering a CD/DVD with remediation processes and software in the event that a host is so badly infected as to be unable to communicate over the Internet.

6. ISPは、ホストがインターネットに通信できないほどひどく感染している場合に備えて、修復プロセスとソフトウェアをCD / DVDに提供することも検討します。

7. 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.

7. 通知および修正プロセスが効果的であるかどうか、および修正プロセスの容易さ、理解可能性、および有効性を向上させるために推奨される変更を行うことができるかについてのフィードバックを求めるユーザー調査。

8. If the user is interested in reporting the host's bot infection to an applicable law enforcement authority, then the host effectively becomes a cyber "crime scene", and the infection should not be mitigated unless or until law enforcement has collected the necessary evidence. For individuals in this situation, the ISP may wish to provide links 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.) In addition, individual regions may have other, specialized computer crime organizations to which these incidents can be reported. For example, in the United States, that organization is the Internet Crime Complaint Center, at http://www.ic3.gov.

8. ユーザーがホストのボット感染を該当する法執行機関に報告することに関心がある場合、ホストは事実上サイバー「犯罪現場」になり、法執行機関が必要な証拠を収集しない限り、またはそのまでは感染を緩和すべきではありません。このような状況にある個人のために、ISPは地方、州、連邦、またはその他の関連するコンピュータ犯罪事務所へのリンクを提供することを望む場合があります。 （注：一部の「マイナー」インシデントは、ユーザーに大きな外傷を与えたとしても、法執行機関が限られたリソースの一部を調査に投入するのに十分深刻ではない場合があります。）さらに、個々の地域には、他の専門のコンピューター犯罪組織がある場合があります。これらの事件を報告することができます。たとえば、米国では、その組織はhttp://www.ic3.govにあるInternet Crime Complaint Centerです。

9. Users may also be interested in links to security expert forums, where other users can assist them.

9. ユーザーは、他のユーザーがそれらを支援できるセキュリティ専門家フォーラムへのリンクに興味があるかもしれません。

6.2. Professionally Assisted Remediation Process

6.2. 専門家による修正プロセス

It should be acknowledged that, based on the current state of remediation tools and the technical abilities of end users, that many users may be unable to remediate on their own. As a result, it is recommended that users have the option for professional assistance. This may entail online or telephone assistance for remediation, as well as working face to face with a professional who has training and expertise in the removal of malware. It should be made clear at the time of offering this service that this service is intended for those that do not have the skills or confidence to attempt remediation and is not intended as an up-sell by the ISP.

現在の修復ツールの状態とエンドユーザーの技術的能力に基づいて、多くのユーザーが自分で修復できない場合があることを認識しておく必要があります。そのため、ユーザーには専門家による支援のオプションを用意することをお勧めします。これには、修正のためのオンラインまたは電話によるサポート、およびマルウェアの削除に関するトレーニングと専門知識を備えた専門家との面談が必要になる場合があります。このサービスを提供する時点で、このサービスは修復を試みるスキルや自信がない人を対象としており、ISPによるアップセルを目的としていないことを明確にしておく必要があります。

7. Failure or Refusal to Remediate

7. 失敗または是正の拒否

ISP systems should track the bot infection history of hosts in order to detect when users consistently fail to remediate or refuse to take any steps to remediate. In such cases, ISPs may need to consider taking additional steps to protect their network, other users and hosts on that network, and other networks. Such steps may include a progression of actions up to and including account termination. Refusal to remediate can be viewed as a business issue, and as such, no technical recommendation is possible.

ISPシステムは、ホストのボット感染履歴を追跡して、ユーザーが常に修復に失敗したり、修復のための手順を実行することを拒否したりする場合を検出する必要があります。このような場合、ISPは、ネットワーク、そのネットワーク上の他のユーザーとホスト、および他のネットワークを保護するための追加の手順を検討する必要がある場合があります。このような手順には、アカウントの終了までの一連のアクションが含まれる場合があります。修正の拒否はビジネス上の問題と見なすことができるため、技術的な推奨はできません。

8. Sharing of Data from the User to the ISP

8. ユーザーからISPへのデータの共有

As an additional consideration, it may be useful to create a process by which users could choose, at their option and with their express consent, to share data regarding their bot infections with their ISP and/or another authorized third party. Such third parties may include governmental entities that aggregate threat data, such as the Internet Crime Complaint Center referred to earlier in this document, academic institutions, and/or security researchers. While in many cases the information shared with the user's ISP or designated third parties will only be used for aggregated statistical analysis, it is also possible that certain research needs may be best met with more detailed data. Thus, any such data sharing from a user to the ISP or authorized third party may contain some type of personally identifiable information, either by design or inadvertently. As a result, any such data sharing should be enabled on an opt-in basis, where users review and approve of the data being shared and the parties with which it is to be shared, unless the ISP is already required to share such data in order to comply with local laws and applicable regulations.

追加の考慮事項として、ユーザーが自由に、明確な同意を得て、ボット感染に関するデータをISPや他の許可されたサードパーティと共有することを選択できるプロセスを作成すると役立つ場合があります。このような第三者には、このドキュメントで前述したインターネット犯罪苦情センターなどの脅威データを集約する政府機関、学術機関、セキュリティ研究者が含まれる場合があります。多くの場合、ユーザーのISPまたは指定された第三者と共有される情報は、集計された統計分析にのみ使用されますが、特定の調査ニーズがより詳細なデータで最もよく満たされる可能性もあります。したがって、ユーザーからISPまたは許可された第三者へのそのようなデータ共有には、設計上または不注意で、何らかのタイプの個人識別情報が含まれる場合があります。その結果、そのようなデータ共有はオプトインベースで有効にする必要があります。そこでは、ISPがそのようなデータをすでに共有するように要求されていない限り、ユーザーは共有されるデータとそれが共有される当事者をレビューおよび承認します。現地の法律および適用される規制を遵守するため。

9. Security Considerations

9. セキュリティに関する考慮事項

This document describes in detail the numerous security risks and concerns relating to botnets. As such, it has been appropriate to include specific information about security in each section above. This document describes the security risks related to malicious bot infections themselves, such as enabling identity theft, theft of authentication credentials, and the use of a host to unwittingly participate in a DDoS attack, among many other risks. Finally, the document also describes security risks that may relate to the particular methods of communicating a notification to Internet users. Bot networks and bot infections pose extremely serious security risks, so readers should review this document carefully.

このドキュメントでは、ボットネットに関連する多数のセキュリティリスクと懸念事項について詳しく説明します。そのため、上記の各セクションにセキュリティに関する特定の情報を含めることが適切でした。このドキュメントでは、悪意のあるボット感染自体に関連するセキュリティリスクについて説明します。たとえば、IDの盗難、認証資格情報の盗難、ホストの使用によるDDoS攻撃への無意識の参加など、さまざまなリスクがあります。最後に、このドキュメントでは、インターネットユーザーに通知を伝達する特定の方法に関連するセキュリティリスクについても説明しています。ボットネットワークとボット感染は非常に深刻なセキュリティリスクをもたらすため、読者はこのドキュメントを注意深く確認する必要があります。

In addition, regarding notifications as described in Section 5, care should be taken to assure users that notifications have been provided by a trustworthy site and/or party, so that the notification is more difficult for phishers and/or malicious parties using social engineering tactics to mimic. Otherwise, care should be taken to ensure that the user has some level of trust that the notification is valid and/or that the user has some way to verify via some other mechanism or step that the notification is valid.

さらに、セクション5に記載されている通知については、信頼できるサイトやパーティーによって通知が提供されていることをユーザーに保証するように注意する必要があります。これにより、ソーシャルエンジニアリングの手法を使用するフィッシャーや悪意のあるパーティーによる通知はより困難になります。模倣します。それ以外の場合は、通知が有効であること、または通知が有効であることをユーザーが他のメカニズムまたは手順で確認するための何らかの方法があることを、ユーザーがある程度信頼できるように注意する必要があります。

10. Privacy Considerations

10. プライバシーに関する考慮事項

This document describes at a high level the activities to which ISPs should be sensitive, i.e., where the collection or communication of PII may be possible. In addition, when performing notifications to end users (see Section 5), those notifications should not include PII.

このドキュメントでは、ISPが敏感である必要があるアクティビティ、つまりPIIの収集または通信が可能な場所について概説します。さらに、エンドユーザーへの通知を実行する場合（セクション5を参照）、それらの通知にはPIIを含めないでください。

As noted in Section 8, any sharing of data from the user to the ISP and/or authorized third parties should be done on an opt-in basis. Additionally the ISP and or authorized third parties should clearly state what data will be shared and with whom the data will be shared.

セクション8で述べたように、ユーザーからISPおよび/または承認された第三者へのデータの共有は、オプトインベースで行う必要があります。さらに、ISPおよび/または承認された第三者は、どのデータが共有され、誰とデータが共有されるかを明確に述べる必要があります。

Lastly, as noted in other sections, there may be legal requirements in particular legal jurisdictions concerning how long any subscriber-related or other data is retained. An ISP operating in such a jurisdiction should be aware of these requirements and should comply with them.

最後に、他のセクションで述べたように、加入者関連のデータやその他のデータが保持される期間に関して、特定の法的管轄区域で法的要件が存在する場合があります。そのような管轄区域で運用しているISPは、これらの要件を認識し、それらに準拠する必要があります。

11. Acknowledgements

11. 謝辞

The authors wish to acknowledge the following individuals and groups for performing a detailed review of this document and/or providing comments and feedback that helped to improve and evolve this document:

著者は、このドキュメントの詳細なレビューを実行したり、このドキュメントの改善と発展に役立つコメントやフィードバックを提供したりした、次の個人やグループに感謝します。

Mark Baugher

マーク・バウアー

Richard Bennett

リチャード・ベネット

James Butler

ジェームズバトラー

Vint Cerf

来た鹿

Alissa Cooper

アリッサクーパー

Jonathan Curtis

ジョナサン・カーティス

Jeff Chan Roland Dobbins

ジェフチャンローランドドビンズ

Dave Farber

デイブ・ファーバー

Stephen Farrell

スティーブン・ファレル

Eliot Gillum

エリオット・ギラム

Joel Halpern

ジョエル・ハルパーン

Joel Jaeggli

ジョエル・ジャグリ

Scott Keoseyan

スコット・ケオセヤン

Murray S. Kucherawy

マレー・S・カーリー

The Messaging Anti-Abuse Working Group (MAAWG)

メッセージング乱用防止ワーキンググループ（MAAWG）

Jose Nazario

ホセ・ナザリオ

Gunter Ollmann

ガンター・オルマン

David Reed

デビッドリード

Roger Safian

ロジャー・サフィアン|

Donald Smith

ドナルド・スミス

Joe Stewart

ジョー・スチュワート

Forrest Swick

フォレスト・スウィック

Sean Turner

ショーンターナー

Robb Topolski

ロブ・トポルスキ

Maxim Weinstein

マキシムワインスタイン

Eric Ziegast

エリック・ジーガスト

12. Informative References

12. 参考引用

[BIOS] Sacco, A. and A. Ortega, "Persistent BIOS Infection", March 2009, <http://www.coresecurity.com/files/ attachments/Persistent_BIOS_Infection_CanSecWest09.pdf>.

[BIOS] Sacco、A。およびA. Ortega、「Persistent BIOS Infection」、2009年3月、<http://www.coresecurity.com/files/ attachments / Persistent_BIOS_Infection_CanSecWest09.pdf>。

[Combat-Zone] Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad", February 2007, <http:// www.memrijttm.org/content/en/report.htm?report=1822>.

[Combat-Zone] Alshech、E。、「Combat Zone as a Combat Zone：The Phenomenon of Electronic Jihad」、2007年2月、<http：// www.memrijttm.org/content/en/report.htm?report=1822> 。

[Conficker] Porras, P., Saidi, H., and V. Yegneswaran, "An Analysis of Conficker's Logic and Rendezvous Points", March 2009, <http://mtc.sri.com/Conficker/>.

[Conficker] Porras、P.、Saidi、H.、V。Yegneswaran、「An Analysis of Conficker's Logic and Rendezvous Points」、2009年3月、<http://mtc.sri.com/Conficker/>。

[DDoS] Saafan, A., "Distributed Denial of Service Attacks: Explanation, Classification and Suggested Solutions", March 2009, <www.exploit-db.com/download_pdf/14738/>.

[DDoS] Saafan、A.、「分散型サービス拒否攻撃：説明、分類、および推奨される解決策」、2009年3月、<www.exploit-db.com/download_pdf/14738/>。

[Dragon] Nagaraja, S. and R. Anderson, "The snooping dragon: social-malware surveillance of the Tibetan movement", March 2009, <http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-746.pdf>.

[ドラゴン]ナガラジャ、S.、R。アンダーソン、「スヌーピングドラゴン：チベット運動のソーシャルマルウェア監視」、2009年3月、<http://www.cl.cam.ac.uk/techreports/UCAM-CL -TR-746.pdf>。

[Estonia] Evron, G., "Battling Botnets and Online Mobs: Estonia's Defense Efforts during the Internet War", 2008, <http:// journal.georgetown.edu/wp-content/uploads/9.1-Evron.pdf>.

[エストニア]エブロン、G。、「ボットネットとオンラインモブとの闘い：インターネット戦争中のエストニアの防御努力」、2008年、<http://journal.georgetown.edu/wp-content/uploads/9.1-Evron.pdf>

[Gh0st] Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st in the Shell: Network Security in the Himalayas", February 2010, <http://www.infowar-monitor.net/wp-content/ uploads/2010/02/cs294-28-paper.pdf>.

[Gh0st] Vallentin、M.、Whiteaker、J。、およびY. Ben-David、「The Gh0st in the Shell：Network Security in the Himalayas」、2010年2月、<http://www.infowar-monitor.net/ wp-content / uploads / 2010/02 / cs294-28-paper.pdf>。

[RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.

[RFC1459] Oikarinen、J。およびD. Reed、「インターネットリレーチャットプロトコル」、RFC 1459、1993年5月。

[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.

[RFC2142] Crocker、D。、「Common Services、Roles and Functionsのメールボックス名」、RFC 2142、1997年5月。

[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.

[RFC3954] Claise、B。、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。

[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.

[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「The Incident Object Description Exchange Format」、RFC 5070、2007年12月。

[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.

[RFC5965] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能なフォーマット」、RFC 5965、2010年8月。

[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, February 2011.

[RFC6108] Chung、C.、Kasyanov、A.、Livingood、J.、Mody、N。、およびB. Van Lieu、「ComcastのWeb通知システムの設計」、RFC 6108、2011年2月。

[Snort] Roesch, M., "Snort Home Page", March 2009, <http://www.snort.org/>.

[Snort] Roesch、M。、「Snortホームページ」、2009年3月、<http://www.snort.org/>。

[Spamalytics] Kanich, C., Kreibich, C., Levchenko, K., Enright, B., Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An Empirical Analysis of Spam Marketing Conversion", October 2008, <http://www.icir.org/christian/publications/ 2008-ccs-spamalytics.pdf>.

[Spamalytics] Kanich、C.、Kreibich、C.、Levchenko、K.、Enright、B.、Voelker、G.、Paxson、V。、およびS. Savage、「Spamalytics：An Spamical Analysis of Spam Marketing Conversion」、 2008年10月、<http://www.icir.org/christian/publications/ 2008-ccs-spamalytics.pdf>。

[Threat-Report] Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber Threats Report for 2009: Data, Mobility and Questions of Responsibility will Drive Cyber Threats in 2009 and Beyond", October 2008, <http://smartech.gatech.edu/ bitstream/1853/26301/1/CyberThreatsReport2009.pdf>.

[脅威レポート] Ahamad、M.、Amster、D.、Barret、M.、Cross、T.、Heron、G.、Jackson、D.、King、J.、Lee、W.、Naraine、R。、 Ollman、G.、Ramsey、J.、Schmidt、H.、and P. Traynor、 "Emerging Cyber​​ Threats Report for 2009：Data、Mobility and Questions of Responsibility Driven Cyber​​ Threats in 2009 and Beyond"、2008年10月、<http ：//smartech.gatech.edu/ bitstream / 1853/26301/1 / Cyber​​ThreatsReport2009.pdf>。

[Whiz-Kid] Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid Took On a DDOS-based Online Extortion Attack", May 2005, <http://www.csoonline.com/article/220336/ How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online _Extortion_Attack>.

[Whiz-Kid] Berinato、S。、「Case Study：How a Bookmaker and Whiz Kid Took on a DDOS-based Online Extortion Attack」、2005年5月、<http://www.csoonline.com/article/220336/ How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online _Extortion_Attack>。

Appendix A. Examples of Third-Party Malware Lists

付録A.サードパーティのマルウェアリストの例

As noted in Section 4, there are many potential third parties that may be willing to share lists of infected hosts. This list is for example purposes only, is not intended to be either exclusive or exhaustive, and is subject to change over time.

セクション4で述べたように、感染したホストのリストを共有することをいとわない可能性のある多くの潜在的なサードパーティがあります。このリストは例示のみを目的としており、排他的または網羅的であることを意図したものではなく、時間とともに変更される可能性があります。

o Arbor - Atlas, see http://atlas.arbor.net/

o アーバー-アトラス、http：//atlas.arbor.net/を参照

o Internet Systems Consortium - Secure Information Exchange (SIE), see https://sie.isc.org/

o Internet Systems Consortium-Secure Information Exchange（SIE）、https：//sie.isc.org/を参照

o Microsoft - Smart Network Data Services (SNDS), see https://postmaster.live.com/snds/

o Microsoft-スマートネットワークデータサービス（SNDS）、https：//postmaster.live.com/snds/を参照

o SANS Institute / Internet Storm Center - DShield Distributed Intrusion Detection System, see http://www.dshield.org/about.html

o SANS Institute / Internet Storm Center-DShield Distributed Intrusion Detection System、http：//www.dshield.org/about.htmlを参照してください

o ShadowServer Foundation, see http://www.shadowserver.org/

o ShadowServer Foundation、http：//www.shadowserver.org/を参照

o Spamhaus - Policy Block List (PBL), see http://www.spamhaus.org/pbl/

o Spamhaus-ポリシーブロックリスト（PBL）、http：//www.spamhaus.org/pbl/を参照

o Spamhaus - Exploits Block List (XBL), see http://www.spamhaus.org/xbl/

o Spamhaus-エクスプロイトブロックリスト（XBL）、http：//www.spamhaus.org/xbl/を参照

   o  Team Cymru - Community Services, see http://www.team-cymru.org/
Authors' Addresses
        

Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA

Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 USA

   EMail: jason_livingood@cable.comcast.com
   URI:   http://www.comcast.com
        

Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA

Nirmal Mody Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 USA

   EMail: nirmal_mody@cable.comcast.com
   URI:   http://www.comcast.com
        

Mike O'Reirdan Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA

Mike O'Reirdan Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 USA

   EMail: michael_oreirdan@cable.comcast.com
   URI:   http://www.comcast.com