[要約] 要約：RFC 4778は、インターネットサービスプロバイダ（ISP）環境における運用セキュリティの現在の実践についてのガイドラインです。 目的：このRFCの目的は、ISPが適切なセキュリティ対策を実施し、ネットワークおよびサービスの安全性を確保するためのベストプラクティスを提供することです。
Network Working Group M. Kaeo
Request for Comments: 4778 Double Shot Security, Inc.
Category: Informational January 2007
Current Operational Security Practices in Internet Service Provider Environments
インターネットサービスプロバイダー環境での現在の運用セキュリティプラクティス
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.
このドキュメントは、レイヤー2とレイヤー3インフラストラクチャデバイスを保護するために、今日の大規模なISP運用ネットワークで使用されている現在のプラクティスの調査です。ここにリストされている情報は、インターネットサービスプロバイダー環境で安全なインフラストラクチャの定義と実装に直接責任がある人々から収集された情報の結果です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Attack Sources . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Operational Security Impact from Threats . . . . . . . . . 5
1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7
2. Protected Operational Functions . . . . . . . . . . . . . . . 8
2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 8
2.2. Device Management - In-Band and Out-of-Band (OOB) . . . . 10
2.3. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Routing Control Plane . . . . . . . . . . . . . . . . . . 18
2.5. Software Upgrades and Configuration
Integrity/Validation . . . . . . . . . . . . . . . . . . . 22
2.6. Logging Considerations . . . . . . . . . . . . . . . . . . 26
2.7. Filtering Considerations . . . . . . . . . . . . . . . . . 29
2.8. Denial-of-Service Tracking/Tracing . . . . . . . . . . . . 30
3. Security Considerations . . . . . . . . . . . . . . . . . . . 32
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. Normative References . . . . . . . . . . . . . . . . . . . 33
5.2. Informational References . . . . . . . . . . . . . . . . . 33
Appendix A. Protocol Specific Attacks . . . . . . . . . . . . . . 34
A.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 34
A.2. IPv4 Protocol-Based Attacks . . . . . . . . . . . . . . . 34
A.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 36
Security practices are well understood by the network operators who have, for many years, gone through the growing pains of securing their network infrastructures. However, there does not exist a written document that enumerates these security practices. Network attacks are continually increasing and although it is not necessarily the role of an ISP to act as the Internet police, each ISP has to ensure that certain security practices are followed to ensure that their network is operationally available for their customers. This document is the result of a survey conducted to find out what current security practices are being deployed to secure network infrastructures.
セキュリティ慣行は、長年にわたってネットワークインフラストラクチャを確保するという苦痛を経験してきたネットワークオペレーターによってよく理解されています。ただし、これらのセキュリティ慣行を列挙する書面による文書は存在しません。ネットワーク攻撃は継続的に増加しており、インターネット警察として機能するISPの役割ではありませんが、各ISPは特定のセキュリティプラクティスに従って、ネットワークが顧客が運用できるようにすることを確認する必要があります。このドキュメントは、ネットワークインフラストラクチャを保護するために現在のセキュリティプラクティスが展開されているものを見つけるために実施された調査の結果です。
The scope for this survey is restricted to security practices that mitigate exposure to risks with the potential to adversely impact network availability and reliability. Securing the actual data traffic is outside the scope of the conducted survey. This document focuses solely on documenting currently deployed security mechanisms for layer 2 and layer 3 network infrastructure devices. Although primarily focused on IPv4, many of the same practices can (and should) apply to IPv6 networks. Both IPv4 and IPv6 network infrastructures are taken into account in this survey.
この調査の範囲は、ネットワークの可用性と信頼性に悪影響を与える可能性のあるリスクへの暴露を軽減するセキュリティ慣行に限定されています。実際のデータトラフィックを確保することは、実施された調査の範囲外です。このドキュメントは、レイヤー2およびレイヤー3ネットワークインフラストラクチャデバイスの現在展開されているセキュリティメカニズムの文書化のみに焦点を当てています。主にIPv4に焦点を合わせていましたが、同じプラクティスの多くがIPv6ネットワークに適用できる（またそうすべきです）。この調査では、IPv4ネットワークインフラストラクチャとIPv6ネットワークインフラストラクチャの両方が考慮されています。
A threat is a potential for a security violation, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm [RFC2828]. Every operational network is subject to a multitude of threat actions, or attacks, i.e., an assault on system security that derives from an intelligent act that is a deliberate attempt to evade security services, and violate the security policy of a system [RFC2828]. Many of the threats to a network infrastructure occur from an instantiation (or combination) of the following:
脅威は、セキュリティ違反の可能性であり、セキュリティを侵害して害を引き起こす可能性のある状況、能力、行動、またはイベントがある場合に存在します[RFC2828]。すべての運用ネットワークは、多数の脅威アクションまたは攻撃、つまり、セキュリティサービスを回避し、システムのセキュリティポリシーに違反する意図的な試みであるインテリジェントな行為に由来するシステムセキュリティに対する攻撃の対象となります[RFC2828]。ネットワークインフラストラクチャに対する脅威の多くは、次のインスタンス（または組み合わせ）から発生します。
Reconnaissance: An attack whereby information is gathered to ascertain the network topology or specific device information, which can be further used to exploit known vulnerabilities
偵察：ネットワークトポロジまたは特定のデバイス情報を確認するために情報が収集される攻撃。既知の脆弱性を活用するためにさらに使用できる攻撃
Man-In-The-Middle: An attack where a malicious user impersonates either the sender or recipient of a communication stream while inserting, modifying, or dropping certain traffic. This type of attack also covers phishing and session hijacks.
中間者：悪意のあるユーザーが、特定のトラフィックを挿入、変更、またはドロップしながら、通信ストリームの送信者または受信者のいずれかになりすましている攻撃。このタイプの攻撃は、フィッシングとセッションのハイジャックもカバーしています。
Protocol Vulnerability Exploitation: An attack that takes advantage of known protocol vulnerabilities due to design or implementation flaws to cause inappropriate behavior.
プロトコルの脆弱性の搾取：設計または実装の欠陥による既知のプロトコルの脆弱性を利用して、不適切な動作を引き起こす攻撃。
Message Insertion: This can be a valid message (it could be a reply attack, which is a scenario where a message is captured and resent at a later time). A message can also be inserted with any of the fields in the message being spoofed, such as IP addresses, port numbers, header fields, or even packet content. Flooding is also part of this threat instantiation.
メッセージ挿入：これは有効なメッセージになる可能性があります（これは、返信攻撃である可能性があります。これは、メッセージがキャプチャされ、後でresするシナリオです）。IPアドレス、ポート番号、ヘッダーフィールド、パケットコンテンツなど、スプーフィングされているメッセージ内のフィールドのいずれかを挿入することもできます。洪水は、この脅威のインスタンスの一部でもあります。
Message Diversion/Deletion: An attack where legitimate messages are removed before they can reach the desired recipient, or are re-directed to a network segment that is normally not part of the data path.
メッセージの転換/削除：正当なメッセージが希望の受信者に到達する前に削除される攻撃、または通常データパスの一部ではないネットワークセグメントに再指向されます。
Message Modification: This is a subset of a message insertion attack where a previous message has been captured and modified before being retransmitted. The message can be captured using a man-in-the-middle attack or message diversion.
メッセージの変更：これは、再送信される前に以前のメッセージがキャプチャおよび変更されたメッセージ挿入攻撃のサブセットです。メッセージは、中間の攻撃またはメッセージの転換を使用してキャプチャできます。
Note that sometimes denial-of-service attacks are listed as separate categories. A denial-of-service is a consequence of an attack and can be the result of too much traffic (i.e., flooding), exploiting protocol exploitation, or inserting/deleting/diverting/modifying messages.
サービス拒否攻撃は、個別のカテゴリとしてリストされる場合があることに注意してください。サービス拒否は攻撃の結果であり、トラフィックが多すぎる（つまり、洪水）、プロトコルの搾取の悪用、またはメッセージの挿入/削除/転用/変動の結果である可能性があります。
These attacks can be sourced in a variety of ways:
これらの攻撃はさまざまな方法で調達できます。
Active vs Passive Attacks
アクティブな対パッシブ攻撃
An active attack involves writing data to the network. It is common practice in active attacks to disguise one's address and conceal the identity of the traffic sender. A passive attack involves only reading information off the network. This is possible if the attacker has control of a host in the communications path between two victim machines, or has compromised the routing infrastructure to specifically arrange that traffic pass through a compromised machine. There are also situations where mirrored traffic (often used for debugging, performance monitoring, or accounting purposes) is diverted to a compromised machine, which would not necessarily subvert any existing topology, and could be harder to detect. In general, the goal of a passive attack is to obtain information that the sender and receiver would prefer to remain private [RFC3552].
アクティブな攻撃には、ネットワークにデータを書き込むことが含まれます。積極的な攻撃における一般的な慣行は、自分の住所を隠し、トラフィック送信者の身元を隠すことです。パッシブ攻撃には、ネットワークから情報を読み取るだけです。これは、攻撃者が2つの被害者マシン間の通信パスでホストを制御するか、ルーティングインフラストラクチャを侵害して、トラフィックが侵害されたマシンを通過することを具体的に配置した場合に可能です。また、ミラー化されたトラフィック（デバッグ、パフォーマンス監視、または会計目的でよく使用されることが多い）が侵害されたマシンに転用される状況もあります。一般に、パッシブ攻撃の目標は、送信者と受信者がプライベートを維持することを好む情報を取得することです[RFC3552]。
On-path vs Off-path Attacks
オンパス対オフパス攻撃
In order for a datagram to be transmitted from one host to another, it generally must traverse some set of intermediate links and routers. Such routers are naturally able to read, modify, or remove any datagram transmitted along that path. This makes it much easier to mount a wide variety of attacks if you are on-path. Off-path hosts can transmit arbitrary datagrams that appear to come from any host but cannot necessarily receive datagrams intended for other hosts. Thus, if an attack depends on being able to receive data, off-path hosts must first subvert the topology in order to place themselves on-path. This is by no means impossible, but is not necessarily trivial [RFC3552]. A more subtle attack is one where the traffic-mirroring capability of a device is hijacked and the traffic is diverted to a compromised host since the network topology may not need to be subverted.
あるホストから別のホストにデータグラムを送信するには、一般に、中間リンクとルーターのセットを横断する必要があります。このようなルーターは、そのパスに沿って送信されたデータグラムを読み取り、変更、または削除することができます。これにより、パス中の場合、多種多様な攻撃を簡単に取り付けることができます。Off-Pathホストは、どのホストからも届くように見える任意のデータグラムを送信できますが、必ずしも他のホスト向けのデータグラムを受信することはできません。したがって、攻撃がデータを受信できることに依存している場合、オフパスホストは最初に自分自身をパスに配置するためにトポロジを破壊する必要があります。これは決して不可能ではありませんが、必ずしも些細な[RFC3552]ではありません。より微妙な攻撃とは、ネットワークトポロジーを破壊する必要がないため、デバイスのトラフィックマイラーリング機能がハイジャックされ、トラフィックが侵害されたホストに転用される攻撃です。
Insider vs Outsider Attacks
インサイダー対アウトサイダー攻撃
An "insider attack" is initiated from inside a given security perimeter by an entity that is authorized to access system resources, but uses them in a way not approved by those who granted the authorization. An "outside attack" is initiated from outside the perimeter by an unauthorized or illegitimate user of the system.
「インサイダー攻撃」は、システムリソースへのアクセスが許可されているが、許可を認められた人々によって承認されていない方法でそれらを使用するエンティティによって、特定のセキュリティ境界内から開始されます。「外部攻撃」は、システムの不正または非合法ユーザーによって境界外から開始されます。
Deliberate Attacks vs Unintentional Events
意図的な攻撃と意図しないイベント
A deliberate attack is where a miscreant intentionally performs an assault on system security. However, there are also instances where unintentional events cause the same harm, yet are performed without malicious intent. Configuration errors and software bugs can be as devastating to network availability as any deliberate attack on the network infrastructure.
意図的な攻撃は、悪党がシステムセキュリティに対する攻撃を意図的に実行する場合です。ただし、意図しないイベントが同じ害を引き起こす場合もありますが、悪意のある意図なしに実行される場合もあります。構成エラーとソフトウェアバグは、ネットワークインフラストラクチャに対する意図的な攻撃と同じくらいネットワークの可用性に壊滅的なものになる可能性があります。
The attack source can be a combination of any of the above, all of which need to be considered when trying to ascertain the impact any attack can have on the availability and reliability of the network. It is nearly impossible to stop insider attacks or unintentional events. However, if appropriate monitoring mechanisms are in place, these attacks can also be detected and mitigated as with any other attack source. The amount of effort it takes to identify and trace an attack is, of course, dependent on the resourcefulness of the attacker. Any of the specific attacks discussed further in this document will elaborate on malicious behavior, which are sourced by an "outsider" and are deliberate attacks. Some further elaboration will be given to the feasibility of passive vs active and on-path vs off-path attacks to show the motivation behind deploying certain security features.
攻撃ソースは、上記のいずれかの組み合わせである可能性があります。これらはすべて、ネットワークの可用性と信頼性に攻撃が与える影響を確認しようとするときに考慮する必要があります。インサイダー攻撃や意図しないイベントを停止することはほぼ不可能です。ただし、適切な監視メカニズムが整っていれば、これらの攻撃を他の攻撃ソースと同様に検出および緩和することもできます。もちろん、攻撃を特定して追跡するために必要な努力の量は、攻撃者の機知に依存します。このドキュメントでさらに議論されている特定の攻撃は、悪意のある行動について詳しく説明します。これは、「部外者」によって供給され、意図的な攻撃です。特定のセキュリティ機能の展開の背後にある動機を示すために、パッシブ対アクティブおよびパスオンパスオフパス攻撃の実現可能性についてさらに詳しく説明します。
The main concern for any of the potential attack scenarios is the impact and harm it can cause to the network infrastructure. The threat consequences are the security violations that results from a threat action, i.e., an attack. These are typically classified as follows:
潜在的な攻撃シナリオのいずれかの主な関心事は、ネットワークインフラストラクチャに引き起こす可能性のある影響と害です。脅威の結果は、脅威行動、つまり攻撃に起因するセキュリティ違反です。これらは通常、次のように分類されます。
(Unauthorized) Disclosure
（不正）開示
A circumstance or event whereby an entity gains access to data for which the entity is not authorized.
エンティティが承認されていないデータへのアクセスを獲得する状況またはイベント。
Deception
欺くこと
A circumstance or event that may result in an authorized entity receiving false data and believing it to be true.
誤ったデータを受け取り、それが真実であると信じている認定エンティティをもたらす可能性のある状況またはイベント。
Disruption
混乱
A circumstance or event that interrupts or prevents the correct operation of system services and functions. A broad variety of attacks, collectively called denial of service attacks, threaten the availability of systems and bandwidth to legitimate users. Many such attacks are designed to consume machine resources, making it difficult or impossible to serve legitimate users. Other attacks cause the target machine to crash, completely denying service to users.
システムサービスと機能の正しい操作を中断または防止する状況またはイベント。集合的にサービス攻撃と呼ばれる幅広い攻撃は、システムの可用性と正当なユーザーへの帯域幅を脅かしています。そのような攻撃の多くは、機械リソースを消費するように設計されており、合法的なユーザーにサービスを提供することが困難または不可能です。他の攻撃により、ターゲットマシンがクラッシュし、ユーザーへのサービスを完全に拒否します。
Usurpation
奪取
A circumstance or event that results in control of system services or functions by an unauthorized entity. Most network infrastructure systems are only intended to be completely accessible to certain authorized individuals. Should an unauthorized person gain access to critical layer 2/layer 3 infrastructure devices or services, they could cause great harm to the reliability and availability of the network.
不正なエンティティによるシステムサービスまたは機能の制御をもたらす状況またはイベント。ほとんどのネットワークインフラストラクチャシステムは、特定の許可された個人が完全にアクセスできるようになることのみを目的としています。許可されていない人がクリティカルレイヤー2/レイヤー3インフラストラクチャデバイスまたはサービスにアクセスした場合、ネットワークの信頼性と可用性に大きな害を及ぼす可能性があります。
A complete description of threat actions that can cause these threat consequences can be found in [RFC2828]. Typically, a number of different network attacks are used in combination to cause one or more of the above-mentioned threat consequences. An example would be a malicious user who has the capability to eavesdrop on traffic. First, he may listen in on traffic for a while, doing reconnaissance work and ascertaining which IP addresses belong to specific devices, such as routers. Were this miscreant to obtain information, such as a router password sent in cleartext, he can then proceed to compromise the actual router. From there, the miscreant can launch various active attacks, such as sending bogus routing updates to redirect traffic or capture additional traffic to compromise other network devices. While this document enumerates which countermeasures ISPs are deploying today, a useful generic analysis of actual backbone infrastructure attacks and the appropriate countermeasures can be found in [RTGWG].
これらの脅威の結果を引き起こす可能性のある脅威行動の完全な説明は、[RFC2828]に記載されています。通常、多くの異なるネットワーク攻撃が組み合わせて使用され、上記の脅威の結果の1つ以上を引き起こします。例としては、トラフィックを盗聴する機能がある悪意のあるユーザーです。第一に、彼はしばらくの間トラフィックに耳を傾け、偵察作業を行い、どのIPアドレスがルーターなどの特定のデバイスに属しているかを確認することができます。ClearTextで送信されたルーターパスワードなどの情報を取得するこの悪党が、実際のルーターを侵害することができます。そこから、悪党は、偽のルーティングアップデートを送信してトラフィックをリダイレクトしたり、他のネットワークデバイスを妥協して追加のトラフィックをキャプチャするなど、さまざまなアクティブな攻撃を開始できます。このドキュメントは、どの対策ISPが展開しているかを列挙していますが、実際のバックボーンインフラストラクチャ攻撃の有用な一般的な分析と適切な対策は[rtgwg]にあります。
This document is a survey of current operational practices that mitigate the risk of being susceptible to any threat actions. As such, the main focus is on the currently deployed security practices used to detect and/or mitigate attacks. The top-level categories in this document are based on operational functions for ISPs and generally relate to what is to be protected. This is followed by a description of which attacks are possible and the security practices currently deployed. This will provide the necessary security services to help mitigate these attacks. These security services are classified as follows:
このドキュメントは、脅威行動の影響を受けやすいリスクを軽減する現在の運用慣行の調査です。そのため、主な焦点は、攻撃の検出および/または緩和に使用されている現在展開されているセキュリティプラクティスにあります。このドキュメントのトップレベルのカテゴリは、ISPの運用機能に基づいており、一般に保護されるものに関連しています。これに続いて、どの攻撃が可能であり、セキュリティ慣行が現在展開されている説明が続きます。これにより、これらの攻撃を軽減するために必要なセキュリティサービスが提供されます。これらのセキュリティサービスは次のように分類されます。
o User Authentication
o ユーザ認証
o User Authorization
o ユーザー承認
o Data Origin Authentication
o データ起源認証
o Access Control
o アクセス制御
o Data Integrity
o データの整合性
o Data Confidentiality
o データの機密性
o Auditing/Logging
o 監査/ロギング
o DoS Mitigation
o DOS緩和
In many instances, a specific protocol currently deployed will offer a combination of these services. For example, Authentication, Authorization, and Accounting (AAA) can offer user authentication, user authorization, and audit/logging services, while the Secure SHell (SSH) Protocol can provide data origin authentication, data integrity, and data confidentiality. The services offered are more important than the actual protocol used. Note that access control will refer basically to logical access control, i.e., filtering. Each section ends with an additional considerations section that explains why specific protocols may or may not be used, and also gives some information regarding capabilities, which are not possible today due to bugs or lack of usability.
多くの場合、現在展開されている特定のプロトコルは、これらのサービスの組み合わせを提供します。たとえば、認証、承認、および会計（AAA）は、ユーザー認証、ユーザー承認、監査/ロギングサービスを提供し、Secure Shell（SSH）プロトコルはデータ起源認証、データの整合性、およびデータの機密性を提供できます。提供されるサービスは、実際のプロトコルよりも重要です。アクセス制御は、基本的に論理アクセス制御、つまりフィルタリングを指すことに注意してください。各セクションは、特定のプロトコルが使用される場合と使用されない理由を説明する追加の考慮事項セクションで終了し、バグや使いやすさの欠如のために今日不可能な機能に関する情報も提供します。
Device physical access pertains to protecting the physical location and access of the layer 2 or layer 3 network infrastructure device. Physical security is a large field of study/practice in and of itself, arguably the largest, oldest, and most well-understood area of security. Although it is important to have contingency plans for natural disasters, such as earthquakes and floods, which can cause damage to networking devices, this is out of the scope of this document. Here, we concern ourselves with protecting access to the physical location and how a device can be further protected from unauthorized access if the physical location has been compromised, i.e., protecting the console access. This is aimed largely at stopping an intruder with physical access from gaining operational control of the device(s). Note that nothing will stop an attacker with physical access from effecting a denial-of-service attack, which can be easily accomplished by powering off the device or just unplugging some cables.
デバイスの物理的アクセスは、レイヤー2またはレイヤー3ネットワークインフラストラクチャデバイスの物理的位置とアクセスの保護に関係しています。物理的なセキュリティは、それ自体が研究/実践の大きな分野であり、おそらく最大の、最も古く、最もよく理解されているセキュリティ領域です。ネットワークデバイスに損傷を与える可能性のある地震や洪水など、自然災害の緊急時対応計画を立てることが重要ですが、これはこの文書の範囲外です。ここでは、物理的な場所へのアクセスを保護することと、物理的な場所が損なわれている場合、つまりコンソールアクセスを保護する場合、デバイスを不正アクセスからさらに保護する方法に関心があります。これは、主に、デバイスの運用制御を獲得するための物理的なアクセスを伴う侵入者を停止することを目的としています。物理的なアクセスで攻撃者がサービス拒否攻撃に影響を与えるのを止めるものは何もないことに注意してください。これは、デバイスの電源を切ったり、いくつかのケーブルを抜いたりするだけで簡単に実現できます。
If any intruder gets physical access to a layer 2 or layer 3 device, the entire network infrastructure can be under the control of the intruder. At a minimum, the intruder can take the compromised device out of service, causing network disruption, the extent of which depends on the network topology. A worse scenario is where the intruder uses this device to crack the console password, gaining complete control of the device (perhaps without anyone detecting such a compromise, or to attach another network device onto a port and siphon off data with which the intruder can ascertain the network topology) and the entire network.
侵入者がレイヤー2またはレイヤー3デバイスへの物理的なアクセスを取得した場合、ネットワークインフラストラクチャ全体が侵入者の制御下にある可能性があります。少なくとも、侵入者は侵害されたデバイスをサービスから外し、ネットワークの破壊を引き起こす可能性があります。さらに悪いシナリオは、侵入者がこのデバイスを使用してコンソールパスワードをクラックし、デバイスの完全な制御を獲得することです（おそらく、そのような妥協を検出する人はいません。ネットワークトポロジ）とネットワーク全体。
The threat of gaining physical access can be realized in a variety of ways, even if critical devices are under high security. Cases still occur where attackers have impersonated maintenance workers to gain physical access to critical devices that have caused major outages and privacy compromises. Insider attacks from authorized personnel also pose a real threat and must be adequately recognized and addressed.
物理的なアクセスを獲得するという脅威は、重要なデバイスが高いセキュリティの下にある場合でも、さまざまな方法で実現できます。攻撃者がメンテナンスワーカーになりすまして、主要な停止やプライバシーの妥協を引き起こした重要なデバイスへの物理的アクセスを得るために、依然として発生しています。認定担当者からのインサイダー攻撃も実際の脅威をもたらし、適切に認識され、対処する必要があります。
For physical device security, equipment is kept in highly restrictive environments. Only authorized users with card-key badges have access to any of the physical locations that contain critical network infrastructure devices. These card-key systems keep track of who accessed which location and at what time. Most cardkey systems have a fail-back "master key" in case the card system is down. This "master key" usually has limited access and its use is also carefully logged (which should only happen if the card-key system is NOT online/functional).
物理的なデバイスのセキュリティのために、機器は非常に制限的な環境に保管されています。カードキーバッジを持つ認定ユーザーのみが、重要なネットワークインフラストラクチャデバイスを含む物理的な場所にアクセスできます。これらのカードキーシステムは、誰がどの場所にアクセスしたか、何時にアクセスしたかを追跡しています。ほとんどのCardKeyシステムには、カードシステムがダウンしている場合に備えて、フェールバック「マスターキー」があります。この「マスターキー」には通常、アクセスが制限されており、その使用も慎重に記録されています（カードキーシステムがオンライン/機能でない場合にのみ発生するはずです）。
All console access is always password protected and the login time is set to time out after a specified amount of inactivity - typically between 3-10 minutes. The type of privileges that you obtain from a console login varies between separate vendor devices. In some cases you get initial basic access and need to perform a second authentication step to get more privileged access (i.e., enable or root). In other vendors, you get the more privileged access when you log into the console as root, without requiring a second authentication step.
すべてのコンソールアクセスは常にパスワードで保護されており、ログイン時間は、指定された量の不活動（通常は3〜10分の間にタイムアウトに設定されます。コンソールログインから取得する特権の種類は、別のベンダーデバイス間で異なります。場合によっては、初期の基本アクセスを取得し、より特権的なアクセス（つまり、有効またはルート）を取得するために2番目の認証ステップを実行する必要があります。他のベンダーでは、2番目の認証ステップを必要とせずに、コンソールにルートとしてログインすると、より特権的なアクセスを取得します。
How ISPs manage these logins vary greatly, although many of the larger ISPs employ some sort of AAA mechanism to help automate privilege-level authorization and utilize the automation to bypass the need for a second authentication step. Also, many ISPs define separate classes of users to have different privileges while logged onto the console. Typically, all console access is provided via an out-of-band (OOB) management infrastructure, which is discussed in Section 2.2 of this document.
ISPがこれらのログインを管理する方法は大きく異なりますが、より大きなISPの多くは、特権レベルの承認を自動化し、自動化を利用して2番目の認証ステップの必要性をバイパスするために何らかのAAAメカニズムを採用しています。また、多くのISPは、コンソールにログインしながら異なる特権を持つように、ユーザーの個別のクラスを定義します。通常、すべてのコンソールアクセスは、このドキュメントのセクション2.2で説明する帯域外（OOB）管理インフラストラクチャを介して提供されます。
The following security services are offered through the use of the practices described in the previous section:
以下のセキュリティサービスは、前のセクションで説明したプラクティスを使用して提供されます。
o User Authentication - All individuals who have access to the physical facility are authenticated. Console access is authenticated.
o ユーザー認証 - 物理施設にアクセスできるすべての個人が認証されます。コンソールアクセスは認証されています。
o User Authorization - An authenticated individual has implicit authorization to perform commands on the device. In some cases, multiple authentication is required to differentiate between basic and more privileged access.
o ユーザー認証 - 認証された個人は、デバイス上でコマンドを実行するための暗黙の承認を持っています。場合によっては、基本的なアクセスとより特権的なアクセスを区別するために、複数の認証が必要です。
o Data Origin Authentication - Not applicable.
o データ起源認証 - 該当なし。
o Access Control - Not applicable.
o アクセス制御 - 該当なし。
o Data Integrity - Not applicable.
o データの整合性 - 該当しません。
o Data Confidentiality - Not applicable.
o データの機密性 - 該当なし。
o Auditing/Logging - All access to the physical locations of the infrastructure equipment is logged via electronic card-key systems. All console access is logged (refer to Section 2.2 of this document for more details).
o 監査/ロギング - インフラストラクチャ機器の物理的な場所へのすべてのアクセスは、電子カードキーシステムを介して記録されます。すべてのコンソールアクセスが記録されます（詳細については、このドキュメントのセクション2.2を参照してください）。
o DoS Mitigation - Not applicable.
o DOS緩和 - 該当なし。
Physical security is relevant to operational security practices as described in this document, mostly from a console-access perspective. Most ISPs provide console access via an OOB management infrastructure, which is discussed in Section 2.2 of this document.
物理的セキュリティは、このドキュメントで説明されているように、主にコンソールアクセスの観点からの運用セキュリティ慣行に関連しています。ほとんどのISPは、このドキュメントのセクション2.2で説明されているOOB管理インフラストラクチャを介してコンソールアクセスを提供します。
The physical and logical authentication and logging systems should be run independently of each other and should reside in different physical locations. These systems need to be secured to ensure that they themselves will not be compromised, which could give the intruder valuable authentication and logging information.
物理的および論理的認証とロギングシステムは、互いに独立して実行され、異なる物理的な場所に存在する必要があります。これらのシステムは、侵入者に貴重な認証と記録情報を提供する可能性があることを確認するために、保護する必要があります。
Social engineering plays a big role in many physical access compromises. Most ISPs have set up training classes and awareness programs to educate company personnel to deny physical access to people who are not properly authenticated or authorized to have physical access to critical infrastructure devices.
ソーシャルエンジニアリングは、多くの物理的アクセスの妥協に大きな役割を果たします。ほとんどのISPは、重要なインフラストラクチャデバイスへの物理的アクセスを適切に認証または許可されていない人々への物理的なアクセスを拒否するために、企業の職員を教育するためのトレーニングクラスと意識向上プログラムを設定しています。
In-band management is generally considered to be device access, where the control traffic takes the same data path as the data that traverses the network. Out-of-band management is generally considered to be device access, where the control traffic takes a separate path as the data that traverses the network. In many environments, device management for layer 2 and layer 3 infrastructure devices is deployed as part of an out-of-band management infrastructure, although there are some instances where it is deployed in-band as well. Note that while many of the security concerns and practices are the same for OOB management and in-band management, most ISPs prefer an OOB management system, since access to the devices that make up this management network are more vigilantly protected and considered to be less susceptible to malicious activity.
帯域内管理は一般にデバイスアクセスと見なされます。この場合、制御トラフィックはネットワークを横断するデータと同じデータパスを取得します。一般に、バンド外の管理はデバイスアクセスであると見なされます。この場合、コントロールトラフィックはネットワークを横断するデータとして個別のパスを取得します。多くの環境では、レイヤー2およびレイヤー3インフラストラクチャデバイスのデバイス管理は、バンド外の管理インフラストラクチャの一部として展開されていますが、バンド内に展開される場合もあります。この管理ネットワークを構成するデバイスへのアクセスはより慎重に保護され、より少ないと考えられているため、セキュリティの懸念と実践の多くはOOB管理と帯域管理で同じですが、ほとんどのISPはOOB管理システムを好むことに注意してください。悪意のある活動の影響を受けやすい。
Console access is always architected via an OOB network. Presently, the mechanisms used for either in-band management or OOB are via virtual terminal access (i.e., Telnet or SSH), Simple Network Management Protocol (SNMP), or HTTP. In all large ISPs that were interviewed, HTTP management was never used and was explicitly disabled. Note that file transfer protocols (TFTP, FTP, and SCP) will be covered in Section 2.5 of this document.
コンソールアクセスは、OOBネットワークを介して常にアーキテクチャ化されます。現在、バンド内管理またはOOBのいずれかに使用されるメカニズムは、仮想端子アクセス（つまり、TelnetまたはSSH）、単純なネットワーク管理プロトコル（SNMP）、またはHTTPを介して行われます。インタビューされたすべての大規模なISPで、HTTP管理は決して使用されず、明示的に無効にされました。ファイル転送プロトコル（TFTP、FTP、およびSCP）は、このドキュメントのセクション2.5で説明されることに注意してください。
For device management, passive attacks are possible if someone has the capability to intercept data between the management device and the managed device. The threat is possible if a single infrastructure device is somehow compromised and can act as a network sniffer, or if it is possible to insert a new device that acts as a network sniffer.
デバイス管理の場合、管理デバイスと管理されたデバイスの間でデータを傍受する機能がある場合、パッシブ攻撃が可能です。単一のインフラストラクチャデバイスが何らかの形で侵害され、ネットワークスニファーとして機能する可能性がある場合、またはネットワークスニファーとして機能する新しいデバイスを挿入できる場合、脅威が可能です。
Active attacks are possible for both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack, where either a device has to already be compromised or a device can be inserted into the path. For off-path active attacks, where a topology subversion is required to reroute traffic and essentially bring the attacker on-path, the attack is generally limited to message insertion or modification.
オンパスとオフパスの両方のシナリオでは、アクティブな攻撃が可能です。パスでアクティブな攻撃の場合、状況はパッシブ攻撃の場合と同じです。この攻撃では、デバイスを既に妥協する必要があるか、デバイスをパスに挿入できます。トポロジーの転覆がトラフィックを再ルーティングし、本質的に攻撃者をパスでもたらすために必要なオフパスアクティブ攻撃の場合、攻撃は一般にメッセージの挿入または変更に限定されます。
Confidentiality violations can occur when a miscreant intercepts any management data that has been sent in cleartext or with weak encryption. This includes interception of usernames and passwords with which an intruder can obtain unauthorized access to network devices. It can also include other information, such as logging or configuration information, if an administrator is remotely viewing local logfiles or configuration information.
機密性違反は、悪党がClearTextまたは弱い暗号化で送信された管理データを傍受する場合に発生する可能性があります。これには、侵入者がネットワークデバイスへの不正アクセスを取得できるユーザー名とパスワードの傍受が含まれます。また、管理者がローカルログファイルまたは構成情報をリモートで表示している場合、ロギングや構成情報など、他の情報を含めることもできます。
If username/password information was encrypted but the cryptographic mechanism used made it easy to capture data and break the encryption key, the device management traffic could be compromised. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user.
ユーザー名/パスワード情報が暗号化されたが、使用された暗号化メカニズムにより、データをキャプチャして暗号化キーを壊すことができた場合、デバイス管理トラフィックが侵害される可能性があります。トラフィックは、ネットワーク上で盗聴するか、悪意のあるユーザーにトラフィックを迂回させることができることによってキャプチャする必要があります。
For a replay attack to be successful, the management traffic would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient.
リプレイ攻撃を成功させるには、管理トラフィックを最初にオンパスでキャプチャするか、攻撃者に転用して、後で意図した受信者に再生される必要があります。
Data can be manipulated by someone in control of intermediary hosts. Forging data is also possible with IP spoofing, where a remote host sends out packets that appear to come from another, trusted host.
データは、中間ホストを制御する人によって操作できます。IPスプーフィングでも鍛造データが可能です。これは、リモートホストが別の信頼できるホストから来るように見えるパケットを送信する可能性があります。
A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent from a management system to the networking infrastructure device and traffic that is sent from the network infrastructure device to the management system.
中間の攻撃は、データストリーム自体ではなく、通信ピアのアイデンティティを攻撃します。攻撃者は、管理システムからネットワーキングインフラストラクチャデバイスに送信されるトラフィックと、ネットワークインフラストラクチャデバイスから管理システムに送信されるトラフィックを傍受します。
OOB management is done via a terminal server at each location. SSH access is used to get to the terminal server from where sessions to the devices are initiated. Dial-in access is deployed as a backup if the network is not available. However, it is common to use dial-back, encrypting modems, and/or one-time-password (OTP) modems to avoid the security weaknesses of plain dial-in access.
OOB管理は、各場所のターミナルサーバーを介して行われます。SSHアクセスは、デバイスへのセッションが開始されるターミナルサーバーに到達するために使用されます。ネットワークが使用できない場合、ダイヤルインアクセスはバックアップとして展開されます。ただし、プレーンダイヤルインアクセスのセキュリティの弱点を回避するために、ダイヤルバック、暗号化モデム、および/または1回限りのパスワード（OTP）モデムを使用することが一般的です。
All in-band management and OOB management access to layer 2 and layer 3 devices is authenticated. The user authentication and authorization is typically controlled by an AAA server (i.e., Remote Authentication Dial-in User Service (RADIUS) and/or Terminal Access Controller Access-Control System (TACACS+)). Credentials used to determine the identity of the user vary from static username/password to one-time username/password schemes such as Secure-ID. Static username/passwords are expired after a specified period of time, usually 30 days. Every authenticated entity via AAA is an individual user for greater granularity of control. Note that often the AAA server used for OOB management authentication is a separate physical device from the AAA server used for in-band management user authentication. In some deployments, the AAA servers used for device management authentication/authorization/accounting are on separate networks to provide a demarcation for any other authentication functions.
レイヤー2およびレイヤー3デバイスへのすべてのバンド管理とOOB管理アクセスが認証されています。ユーザー認証と承認は、通常、AAAサーバー（つまり、リモート認証ダイヤルインユーザーサービス（RADIUS）および/またはターミナルアクセスコントローラーアクセス制御システム（TACACS））によって制御されます。ユーザーのIDを決定するために使用される資格情報は、静的ユーザー名/パスワードからSecure-IDなどの1回限りのユーザー名/パスワードスキームまでさまざまです。静的ユーザー名/パスワードは、指定された期間、通常は30日後に期限切れになります。AAAを介したすべての認証されたエンティティは、制御の粒度を高めるための個々のユーザーです。多くの場合、OOB管理認証に使用されるAAAサーバーは、インバンド管理ユーザー認証に使用されるAAAサーバーとは別の物理デバイスであることに注意してください。一部の展開では、デバイス管理認証/認証/会計に使用されるAAAサーバーは、他の認証関数の境界を提供するために別々のネットワーク上にあります。
For backup purposes, there is often a single local database entry for authentication that is known to a very limited set of key personnel. It is usually the highest privilege-level username/password combination, which in most cases is the same across all devices. This local device password is routinely regenerated once every 2-3 months, and is also regenerated immediately after an employee who had access to that password leaves the company or is no longer authorized to have knowledge of that password.
バックアップのために、非常に限られた主要人員に知られている認証用のローカルデータベースエントリが1つあります。通常、これは最高の特権レベルのユーザー名/パスワードの組み合わせであり、ほとんどの場合、すべてのデバイスで同じです。このローカルデバイスのパスワードは、2〜3か月に1回定期的に再生され、そのパスワードにアクセスした従業員が会社を去るか、そのパスワードの知識を持つことを許可されなくなった直後に再生されます。
Each individual user in the AAA database is configured with specific authorization capability. Specific commands are either individually denied or permitted, depending on the capability of the device to be accessed. Multiple privilege levels are deployed. Most individuals are authorized with basic authorization to perform a minimal set of commands, while a subset of individuals are authorized to perform more privileged commands. Securing the AAA server is imperative and access to the AAA server itself is strictly controlled. When an individual leaves the company, his/her AAA account is immediately deleted and the TACACS/RADIUS shared secret is reset for all devices.
AAAデータベースの各ユーザーは、特定の承認機能を備えて構成されています。特定のコマンドは、アクセスするデバイスの機能に応じて、個別に拒否または許可されます。複数の特権レベルが展開されます。ほとんどの個人は、最小限のコマンドセットを実行するための基本的な許可を認められていますが、個人のサブセットはより特権的なコマンドを実行することを許可されています。AAAサーバーのセキュリティは必須であり、AAAサーバー自体へのアクセスは厳密に制御されます。個人が会社を離れると、彼/彼女のAAAアカウントはすぐに削除され、TACACS/RADIUS共有シークレットはすべてのデバイスにリセットされます。
Some management functions are performed using command line interface (CLI) scripting. In these scenarios, a dedicated user is used for the identity in scripts that perform CLI scripting. Once authenticated, these scripts control which commands are legitimate, depending on authorization rights of the authenticated individual.
一部の管理関数は、コマンドラインインターフェイス（CLI）スクリプトを使用して実行されます。これらのシナリオでは、CLIスクリプトを実行するスクリプトのIDに専用のユーザーが使用されます。認証されると、認証された個人の承認権に応じて、これらのスクリプト制御コマンドは正当なものです。
SSH is always used for virtual terminal access to provide for an encrypted communication channel. There are exceptions due to equipment limitations which are described in the additional considerations section.
SSHは、暗号化された通信チャネルを提供するために、仮想端子アクセスに常に使用されます。追加の考慮事項セクションで説明されている機器の制限のために例外があります。
If SNMP is used for management, it is for read queries only and restricted to specific hosts. If possible, the view is also restricted to only send the information that the management station needs, rather than expose the entire configuration file with the read-only SNMP community. The community strings are carefully chosen to be difficult to crack and there are procedures in place to change these community strings between 30-90 days. If systems support two SNMP community strings, the old string is replaced by first configuring a second, newer community string and then migrating over from the currently used string to the newer one. Most large ISPs have multiple SNMP systems accessing their routers so it takes more then one maintenance period to get all the strings fixed in all the right systems. SNMP RW is not used and is disabled by configuration.
SNMPが管理に使用される場合、それは読み取りクエリのみであり、特定のホストに制限されています。可能であれば、ビューは、構成ファイル全体を読み取り専用SNMPコミュニティで公開するのではなく、管理ステーションが必要とする情報のみを送信するように制限されています。コミュニティの文字列は、割れが難しいように慎重に選択されており、30〜90日間の間にこれらのコミュニティ文字列を変更する手順があります。システムが2つのSNMPコミュニティ文字列をサポートする場合、古い文字列は、最初に2番目の新しいコミュニティ文字列を構成し、現在使用されている文字列から新しい文字列に移行することに置き換えられます。ほとんどの大型ISPには、ルーターにアクセスする複数のSNMPシステムがあるため、すべての適切なシステムですべての文字列を固定するのに1つ以上のメンテナンス期間がかかります。SNMP RWは使用されておらず、構成によって無効になっています。
Access control is strictly enforced for infrastructure devices by using stringent filtering rules. A limited set of IP addresses are allowed to initiate connections to the infrastructure devices and are specific to the services to which they are to limited (i.e., SSH and SNMP).
アクセス制御は、厳しいフィルタリングルールを使用することにより、インフラストラクチャデバイスに厳密に施行されます。限られた一連のIPアドレスは、インフラストラクチャデバイスへの接続を開始することができ、それらが制限されるサービス（つまり、SSHおよびSNMP）に固有のものです。
All device management access is audited and any violations trigger alarms that initiate automated email, pager, and/or telephone notifications. AAA servers keep track of the authenticated entity as well as all the commands that were carried out on a specific device. Additionally, the device itself logs any access control violations (i.e., if an SSH request comes in from an IP address that is not explicitly permitted, that event is logged so that the offending IP address can be tracked down and investigations made as to why it was trying to access a particular infrastructure device)
すべてのデバイス管理アクセスは監査され、違反は自動化された電子メール、ポケットベル、および/または電話通知を開始するアラームをトリガーします。AAAサーバーは、特定のデバイスで実行されたすべてのコマンドと同様に、認証されたエンティティとすべてのコマンドを追跡します。さらに、デバイス自体はアクセス制御違反をログに記録します（つまり、明示的に許可されていないIPアドレスからSSH要求が送信された場合、そのイベントがログに記録され、問題のあるIPアドレスを追跡し、その理由について調査することができます特定のインフラストラクチャデバイスにアクセスしようとしていました）
The security services offered for device OOB management are nearly identical to those of device in-band management. Due to the critical nature of controlling and limiting device access, many ISPs feel that physically separating the management traffic from the normal customer data traffic will provide an added level of risk mitigation and limit the potential attack vectors. The following security services are offered through the use of the practices described in the previous section:
デバイスOOB管理に提供されるセキュリティサービスは、デバイス内の管理の管理者とほぼ同じです。デバイスアクセスを制御および制限することの重要な性質により、多くのISPは、管理トラフィックを通常の顧客データトラフィックから物理的に分離すると、リスク軽減レベルが追加され、潜在的な攻撃ベクターが制限されると感じています。以下のセキュリティサービスは、前のセクションで説明したプラクティスを使用して提供されます。
o User Authentication - All individuals are authenticated via AAA services.
o ユーザー認証 - すべての個人は、AAAサービスを介して認証されます。
o User Authorization - All individuals are authorized via AAA services to perform specific operations once successfully authenticated.
o ユーザー承認 - すべての個人は、AAAサービスを介して認証された特定の操作を実行することを許可されています。
o Data Origin Authentication - Management traffic is strictly filtered to allow only specific IP addresses to have access to the infrastructure devices. This does not alleviate risk the from spoofed traffic, although when combined with edge filtering using BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in Section 2.5), then the risk of spoofing is mitigated, barring a compromised internal system. Also, using SSH for device access ensures that no one can spoof the traffic during the SSH session.
o データ起源認証 - 管理トラフィックは厳密にフィルタリングされ、特定のIPアドレスのみがインフラストラクチャデバイスにアクセスできるようにします。これは、BCP38 [RFC2827]およびBCP84 [RFC3704]ガイドライン（セクション2.5で説明）を使用してエッジフィルタリングと組み合わせると、スプーフィングされたトラフィックからのリスクを軽減しません。また、SSHを使用してデバイスアクセスを使用すると、SSHセッション中に誰もトラフィックを押し付けることができません。
o Access Control - Management traffic is filtered to allow only specific IP addresses to have access to the infrastructure devices.
o アクセス制御 - 管理トラフィックはフィルタリングされ、特定のIPアドレスのみがインフラストラクチャデバイスにアクセスできるようにします。
o Data Integrity - Using SSH provides data integrity and ensures that no one has altered the management data in transit.
o データの整合性 - SSHを使用すると、データの整合性が提供され、輸送中の管理データを変更していないことが保証されます。
o Data Confidentiality - Using SSH provides data confidentiality.
o データの機密性 - SSHを使用すると、データの機密性が提供されます。
o Auditing/Logging - Using AAA provides an audit trail for who accessed which device and which operations were performed.
o 監査/ロギング - AAAを使用すると、どのデバイスにアクセスし、どの操作が実行されたかが監査証跡を提供します。
o DoS Mitigation - Using packet filters to allow only specific IP addresses to have access to the infrastructure devices. This limits but does not prevent spoofed DoS attacks directed at an infrastructure device. However, the risk is lowered by using a separate physical network for management purposes.
o DOS緩和 - パケットフィルターを使用して、特定のIPアドレスのみがインフラストラクチャデバイスにアクセスできるようにします。これにより、インフラストラクチャデバイスに向けられたスプーフィングされたDOS攻撃を防ぐことはできません。ただし、管理目的で別の物理ネットワークを使用することにより、リスクが低下します。
Password selection for any device management protocol used is critical to ensure that the passwords are hard to guess or break using a brute-force attack.
使用されているデバイス管理プロトコルのパスワード選択は、ブルートフォース攻撃を使用してパスワードを推測または壊すのが難しいことを確認するために重要です。
IP security (IPsec) is considered too difficult to deploy, and the common protocol to provide for confidential management access is SSH. There are exceptions for using SSH due to equipment limitations since SSH may not be supported on legacy equipment. In some cases, changing the host name of a device requires an SSH rekey event since the key is based on some combination of host name, Message Authentication Code (MAC) address, and time. Also, in the case where the SSH key is stored on a route processor card, a re-keying of SSH would be required whenever the route processor card needs to be swapped. Some providers feel that this operational impact exceeds the security necessary and instead use Telnet from trusted inside hosts (called 'jumphosts' or 'bastion hosts') to manage those devices. An individual would first SSH to the jumphost and then Telnet from the jumphost to the actual infrastructure device, fully understanding that any passwords will be sent in the clear between the jumphost and the device to which it is connecting. All authentication and authorization is still carried out using AAA servers.
IPセキュリティ（IPSEC）は展開が難しすぎると考えられており、機密管理アクセスを提供するための一般的なプロトコルはSSHです。SSHはレガシー機器ではサポートされていない可能性があるため、機器の制限のためにSSHを使用することには例外があります。場合によっては、キーはホスト名、メッセージ認証コード（MAC）アドレス、および時間の組み合わせに基づいているため、デバイスのホスト名を変更するにはSSH Rekeイベントが必要です。また、SSHキーがルートプロセッサカードに保存されている場合、ルートプロセッサカードを交換する必要がある場合はいつでもSSHの再キーを必要とします。一部のプロバイダーは、この運用上の影響が必要なセキュリティを超えていると感じており、代わりにこれらのデバイスを管理するために、信頼できる内部ホスト（「Jumphosts」または「Bastion Hosts」と呼ばれる）からTelnetを使用します。個人は最初にジャンフォストにSSHを使用し、次にジャンフォストから実際のインフラストラクチャデバイスにターネットし、パスワードがジャンフォストと接続しているデバイスの間にクリアで送信されることを完全に理解します。すべての認証と承認は、AAAサーバーを使用して引き続き実行されます。
In instances where Telnet access is used, the logs on the AAA servers are more verbose and more attention is paid to them to detect any abnormal behavior. The jumphosts themselves are carefully controlled machines and usually have limited access. Note that Telnet is NEVER allowed to an infrastructure device except from specific jumphosts; i.e., packet filters are used at the console server and/or infrastructure device to ensure that Telnet is only allowed from specific IP addresses.
Telnetアクセスが使用される場合、AAAサーバーのログはより冗長であり、異常な動作を検出するためにより注意が払われます。ジャンフォスト自体は慎重に制御されたマシンであり、通常はアクセスが制限されています。特定のジャンフォストを除き、Telnetはインフラストラクチャデバイスに許可されないことに注意してください。つまり、パケットフィルターはコンソールサーバーおよび/またはインフラストラクチャデバイスで使用され、Telnetが特定のIPアドレスからのみ許可されるようにします。
With thousands of devices to manage, some ISPs have created automated mechanisms to authenticate to devices. As an example, Kerberos has been used to automate the authentication process for devices that have support for Kerberos. An individual would first log in to a Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. This 'ticket' is generally set to have a lifespan of 10 hours and is used to automatically authenticate the individual to the infrastructure devices.
何千ものデバイスを管理するために、一部のISPは、デバイスに認証するための自動化されたメカニズムを作成しました。例として、KerberosはKerberosをサポートするデバイスの認証プロセスを自動化するために使用されています。個人は、最初にSSHを使用してKerberized Unixサーバーにログインし、Kerberosの「チケット」を生成します。この「チケット」は通常、10時間の寿命があるように設定されており、個人をインフラストラクチャデバイスに自動的に認証するために使用されます。
In instances where SNMP is used, some legacy devices only support SNMPv1, which then requires the provider to mandate its use across all infrastructure devices for operational simplicity. SNMPv2 is primarily deployed since it is easier to set up than v3.
SNMPが使用される場合、一部のレガシーデバイスはSNMPV1のみをサポートします。これにより、プロバイダーは、運用上のシンプルさのためにすべてのインフラストラクチャデバイスでの使用を義務付ける必要があります。SNMPV2は、V3よりもセットアップが簡単であるため、主に展開されます。
This section refers to how traffic is handled that traverses the network infrastructure device. The primary goal of ISPs is to forward customer traffic. However, due to the large amount of malicious traffic that can cause DoS attacks and render the network unavailable, specific measures are sometimes deployed to ensure the availability to forward legitimate customer traffic.
このセクションでは、ネットワークインフラストラクチャデバイスを通過するトラフィックの処理方法について説明します。ISPの主な目標は、顧客のトラフィックを転送することです。ただし、DOS攻撃を引き起こし、ネットワークを利用できないようにする可能性のある大量の悪意のあるトラフィックにより、正当な顧客トラフィックを転送するための可用性を確保するために、特定の手段が展開されることがあります。
Any data traffic can potentially be attack traffic and the challenge is to detect and potentially stop forwarding any of the malicious traffic. The deliberately sourced attack traffic can consist of packets with spoofed source and/or destination addresses or any other malformed packet that mangle any portion of a header field to cause protocol-related security issues (such as resetting connections, causing unwelcome ICMP redirects, creating unwelcome IP options, or packet fragmentations).
データトラフィックは潜在的にトラフィックを攻撃する可能性があり、課題は悪意のあるトラフィックの転送を検出し、停止することです。意図的に調達した攻撃トラフィックは、スプーフィングされたソースおよび/または宛先アドレス、またはヘッダーフィールドの任意の部分をマングル化してプロトコル関連のセキュリティ問題（接続のリセット、歓迎されないICMPリダイレクトなど、歓迎されない歓迎されません。IPオプション、またはパケット断片化）。
Filtering and rate limiting are the primary mechanism to provide risk mitigation of malicious traffic rendering the ISP services unavailable. However, filtering and rate limiting of data path traffic is deployed in a variety of ways, depending on how automated the process is and what the capabilities and performance limitations of the existing deployed hardware are.
フィルタリングとレートの制限は、ISPサービスを利用できない悪意のあるトラフィックのリスク軽減を提供する主要なメカニズムです。ただし、データパストラフィックのフィルタリングとレートの制限は、プロセスの自動化と既存の展開ハードウェアの機能とパフォーマンスの制限が何であるかに応じて、さまざまな方法で展開されます。
The ISPs that do not have performance issues with their equipment follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress filtering. BCP38 recommends filtering ingress packets with obviously spoofed and/or 'reserved' source addresses to limit the effects of denial-of-service attacks, while BCP84 extends the recommendation for multi-homed environments. Filters are also used to help alleviate issues between service providers. Without any filtering, an inter-exchange peer could steal transit just by using static routes, and essentially redirect data traffic. Therefore, some ISPs have implemented ingress/egress filters that block unexpected source and destination addresses not defined in the above-mentioned documents. Null routes and black-hole triggered routing [RFC3882] are used to deter any detected malicious traffic streams. These two techniques are described in more detail in Section 2.8 below.
機器にパフォーマンスの問題を抱えていないISPは、BCP38 [RFC2827]およびBCP84 [RFC3704]ガイドラインのイングレスフィルタリングのガイドラインに従います。BCP38では、明らかにスプーフィングおよび/または「予約された」ソースアドレスを備えたイングレスパケットのフィルタリングを推奨して、サービス拒否攻撃の影響を制限しますが、BCP84はマルチホーム環境の推奨を拡張します。フィルターは、サービスプロバイダー間の問題を軽減するためにも使用されます。フィルタリングがなければ、交換間のピアは静的ルートを使用してトランジットを盗み、基本的にデータトラフィックをリダイレクトできます。したがって、一部のISPは、上記のドキュメントで定義されていない予期しないソースおよび宛先アドレスをブロックするIngress/Egressフィルターを実装しています。ヌルルートとブラックホールトリガールーティング[RFC3882]は、検出された悪意のある交通ストリームを阻止するために使用されます。これらの2つの手法については、以下のセクション2.8で詳しく説明します。
Most ISPs consider layer 4 filtering useful, but it is only implemented if performance limitations allow for it. Since it poses a large administrative overhead and ISPs are very much opposed to acting as the Internet firewall, Layer 4 filtering is typically implemented as a last option. Netflow is used for tracking traffic flows, but there is some concern whether sampling is good enough to detect malicious behavior.
ほとんどのISPは、レイヤー4フィルタリングが有用であると考えていますが、パフォーマンスの制限が許可されている場合にのみ実装されます。大規模な管理オーバーヘッドをもたらし、ISPはインターネットファイアウォールとして機能することに非常に反対しているため、レイヤー4フィルタリングは通常、最後のオプションとして実装されます。Netflowはトラフィックフローの追跡に使用されますが、サンプリングが悪意のある動作を検出するのに十分であるかどうかは懸念があります。
Unicast Reverse Path Forwarding (RPF) is not consistently implemented. Some ISPs are in the process of doing so, while other ISPs think that the perceived benefit of knowing that spoofed traffic comes from legitimate addresses are not worth the operational complexity. Some providers have a policy of implementing uRPF at link speeds of Digital Signal 3 (DS3) and below, which was due to the fact that all hardware in the network supported uRPF for DS3 speeds and below. At higher-speed links, the uRPF support was inconsistent and it was easier for operational people to implement a consistent solution.
ユニキャストリバースパス転送（RPF）は一貫して実装されていません。一部のISPはそうするプロセスにありますが、他のISPは、スプーフィングされたトラフィックが正当な住所から来ていることを知ることの利点は運用上の複雑さの価値がないと考えています。一部のプロバイダーには、デジタル信号3（DS3）以下のリンク速度でURPFを実装するポリシーがあります。これは、ネットワーク内のすべてのハードウェアがDS3速度以下でURPFをサポートしているためです。高速リンクでは、URPFのサポートは一貫性がなく、運用上の人々が一貫したソリューションを実装するのが簡単でした。
o User Authentication - Not applicable.
o ユーザー認証 - 該当なし。
o User Authorization - Not applicable.
o ユーザー承認 - 該当なし。
o Data Origin Authentication - When IP address filtering per BCP38, BCP84, and uRPF are deployed at network edges it can ensure that any spoofed traffic comes from at least a legitimate IP address and can be tracked.
o データ起源認証 - BCP38、BCP84、およびURPFごとのIPアドレスフィルタリングがネットワークエッジに展開されると、スプーフィングされたトラフィックが少なくとも正当なIPアドレスから来て追跡できるようにします。
o Access Control - IP address filtering and layer 4 filtering is used to deny forbidden protocols and limit traffic destined for infrastructure device itself. Filters are also used to block unexpected source/destination addresses.
o アクセス制御 - IPアドレスフィルタリングとレイヤー4フィルタリングは、禁止されたプロトコルを拒否し、インフラストラクチャデバイス自体に向けたトラフィックを制限するために使用されます。フィルターは、予期しないソース/宛先アドレスをブロックするためにも使用されます。
o Data Integrity - Not applicable.
o データの整合性 - 該当しません。
o Data Confidentiality - Not applicable.
o データの機密性 - 該当なし。
o Auditing/Logging - Filtering exceptions are logged for potential attack traffic.
o 監査/ロギング - フィルタリングの例外は、潜在的な攻撃トラフィックのために記録されます。
o DoS Mitigation - Black-hole triggered filtering and rate-limiting are used to limit the risk of DoS attacks.
o DOS緩和 - ブラックホールトリガーされたフィルタリングとレート制限は、DOS攻撃のリスクを制限するために使用されます。
For layer 2 devices, MAC address filtering and authentication is not used in large-scale deployments. This is due to the problems it can cause when troubleshooting networking issues. Port security becomes unmanageable at a large scale where thousands of switches are deployed.
レイヤー2デバイスの場合、Macアドレスフィルタリングと認証は大規模な展開では使用されません。これは、ネットワーキングの問題のトラブルシューティング時に引き起こす可能性のある問題が原因です。ポートセキュリティは、数千のスイッチが展開される大規模に管理できなくなります。
Rate limiting is used by some ISPs, although other ISPs believe it is not really useful, since attackers are not well-behaved and it doesn't provide any operational benefit over the complexity. Some ISPs feel that rate limiting can also make an attacker's job easier by requiring the attacker to send less traffic to starve legitimate traffic that is part of a rate limiting scheme. Rate limiting may be improved by developing flow-based rate-limiting capabilities with filtering hooks. This would improve the performance as well as the granularity over current capabilities.
レートの制限は一部のISPで使用されますが、他のISPは、攻撃者が行方不明にならず、複雑さに対して運用上の利点を提供しないため、実際には有用ではないと考えています。一部のISPは、レートの制限が、攻撃者がレート制限スキームの一部である正当なトラフィックを飢えさせるためにより少ないトラフィックを送ることを要求することにより、攻撃者の仕事を容易にすることができると感じています。フィルタリングフックを使用して、フローベースのレート制限機能を開発することにより、レートの制限が改善される場合があります。これにより、パフォーマンスと現在の機能に対する粒度が向上します。
Lack of consistency regarding the ability to filter, especially with respect to performance issues, cause some ISPs not to implement BCP38 and BCP84 guidelines for ingress filtering. One such example is at edge boxes, where up to 1000 T1s connecting into a router with an OC-12 (Optical Carrier) uplink. Some deployed devices experience a large performance impact with filtering, which is unacceptable for passing customer traffic through, though ingress filtering (uRPF) might be applicable at the devices that are connecting these aggregation routers. Where performance is not an issue, the ISPs make a tradeoff between management versus risk.
特にパフォーマンスの問題に関してフィルタリングする能力に関する一貫性の欠如により、一部のISPは、イングレスフィルタリングのためにBCP38およびBCP84ガイドラインを実装しないようにします。そのような例の1つは、OC-12（光学キャリア）アップリンクを備えたルーターに最大1000のT1が接続するエッジボックスです。一部の展開されたデバイスは、フィルタリングに大きなパフォーマンスの影響を与えます。これは顧客のトラフィックを通過するのに受け入れられませんが、イングレスフィルタリング（URPF）は、これらの集約ルーターを接続しているデバイスに適用できる場合があります。パフォーマンスが問題ではない場合、ISPは経営陣とリスクの間のトレードオフを行います。
The routing control plane deals with all the traffic that is part of establishing and maintaining routing protocol information.
ルーティングコントロールプレーンは、ルーティングプロトコル情報の確立と維持の一部であるすべてのトラフィックを扱います。
Attacks on the routing control plane can be from both passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the communicating routing peers. This can be accomplished if a single routing peer is somehow compromised and can act as a network sniffer, or if it is possible to insert a new device that acts as a network sniffer.
ルーティング制御プレーンへの攻撃は、受動的またはアクティブなソースの両方からのものです。誰かが通信ルーティングピア間でデータを傍受する機能を持っている場合、受動的な攻撃が可能です。これは、単一のルーティングピアが何らかの形で侵害され、ネットワークスニファーとして機能する可能性がある場合、またはネットワークスニファーとして機能する新しいデバイスを挿入できる場合に実現できます。
Active attacks are possible for both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack, where either a device has to already be compromised or a device can be inserted into the path. This may lead to an attacker impersonating a legitimate routing peer and exchanging routing information. Unintentional active attacks are more common due to configuration errors, which cause legitimate routing peers to feed invalid routing information to other neighboring peers.
オンパスとオフパスの両方のシナリオでは、アクティブな攻撃が可能です。パスでアクティブな攻撃の場合、状況はパッシブ攻撃の場合と同じです。この攻撃では、デバイスを既に妥協する必要があるか、デバイスをパスに挿入できます。これにより、攻撃者が正当なルーティングピアになりすまし、ルーティング情報を交換することにつながる可能性があります。意図しないアクティブな攻撃は、構成エラーのためにより一般的です。これにより、合法的なルーティングピアが他の近隣のピアに無効なルーティング情報を提供します。
For off-path active attacks, the attacks are generally limited to message insertion or modification, which can divert traffic to illegitimate destinations, causing traffic to never reach its intended destination.
オフパスのアクティブな攻撃の場合、攻撃は一般にメッセージの挿入または変更に限定され、トラフィックを非giatiarな目的地に迂回させる可能性があり、トラフィックが目的の目的地に到達することはありません。
Confidentiality violations can occur when a miscreant intercepts any of the routing update traffic. This is becoming more of a concern because many ISPs are classifying addressing schemes and network topologies as private and proprietary information. It is also a concern because the routing protocol packets contain information that may show ways in which routing sessions could be spoofed or hijacked. This in turn could lead into a man-in-the-middle attack, where the miscreants can insert themselves into the traffic path or divert the traffic path and violate the confidentiality of user data.
機密性の違反は、悪党がルーティングアップデートトラフィックのいずれかを傍受したときに発生する可能性があります。多くのISPは、プライベートおよび独自の情報として、多くのISPがアドレス指定スキームとネットワークトポロジを分類しているため、より懸念されています。また、ルーティングプロトコルパケットには、ルーティングセッションをスプーフィングまたはハイジャックする方法を示す可能性のある情報が含まれているため、懸念事項です。これは、中間の攻撃につながる可能性があります。そこでは、悪党がトラフィックパスに自分自身を挿入したり、トラフィックパスを転用したり、ユーザーデータの機密性に違反したりできます。
If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user. Note that by using cryptographically protected routing information, the latter would require the cryptographic key to already be compromised anyway, so this attack is only feasible if a device was able to eavesdrop and capture the cryptographically protected routing information.
データの整合性と機密性を提供するために暗号化メカニズムが使用された場合、オフラインの暗号攻撃がデータを損なう可能性があります。トラフィックは、ネットワーク上で盗聴するか、悪意のあるユーザーにトラフィックを迂回させることができることによってキャプチャする必要があります。暗号化されたルーティング情報を使用することにより、後者は暗号化キーを既に妥協する必要があるため、この攻撃は、デバイスが暗号化された保護されたルーティング情報を盗用してキャプチャできた場合にのみ実現可能であることに注意してください。
For a replay attack to be successful, the routing control plane traffic would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient. Additionally, since many of these protocols include replay protection mechanisms, these would also need to be subverted, if applicable.
リプレイ攻撃を成功させるには、ルーティングコントロールプレーンのトラフィックを最初にパスでキャプチャするか、攻撃者に転用して、後で意図した受信者に再生される必要があります。さらに、これらのプロトコルの多くにはリプレイ保護メカニズムが含まれているため、該当する場合は、これらを破壊する必要があります。
Routing control plane traffic can be manipulated by someone in control of intermediate hosts. In addition, traffic can be injected by forging IP addresses, where a remote router sends out packets that appear to come from another, trusted router. If enough traffic is injected to be processed by limited memory routers, it can cause a DoS attack.
ルーティングコントロールプレーントラフィックは、中間ホストを制御する人によって操作できます。さらに、IPアドレスを偽造することでトラフィックを注入できます。この場合、リモートルーターは、信頼できるルーターから来るように見えるパケットを送信します。限られたメモリルーターによって処理されるのに十分なトラフィックが注入された場合、DOS攻撃を引き起こす可能性があります。
A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent from one routing peer to the other and communicates on behalf of one of the peers. This can lead to a diversion of the user traffic to either an unauthorized receiving party or cause legitimate traffic to never reach its intended destination.
Securing the routing control plane takes many features, which are generally deployed as a system. Message Digest 5 (MD5) authentication is used by some ISPs to validate the sending peer and to ensure that the data in transit has not been altered. Some ISPs only deploy MD5 authentication at the customers' request. Additional sanity checks to ensure with reasonable certainty that the received routing update was originated by a valid routing peer include route filters and the Generalized TTL Security Mechanism (GTSM) feature [RFC3682] (sometimes also referred to as the TTL-Hack). The GTSM feature is used for protocols such as the Border Gateway Protocol (BGP), and makes use of a packet's Time To Live (TTL) field (IPv4) or Hop Limit (IPv6) to protect communicating peers. If GTSM is used, it is typically deployed only in limited scenarios between internal BGP peers due to lack of consistent support between vendor products and operating system versions.
ルーティング制御プレーンを固定するには、一般的にシステムとして展開される多くの機能が必要です。メッセージダイジェスト5（MD5）認証は、一部のISPによって使用され、送信ピアを検証し、輸送中のデータが変更されていないことを確認します。一部のISPは、顧客のリクエストでMD5認証のみを展開します。受信したルーティングアップデートが有効なルーティングピアインクルードルートフィルターと一般化されたTTLセキュリティメカニズム（GTSM）機能[RFC3682]（TTLハックとも呼ばれる）によって妥当な確実性を確保するための追加の正気チェック。GTSM機能は、Border Gateway Protocol（BGP）などのプロトコルに使用され、パケットの時間（TTL）フィールド（IPv4）またはホップ制限（IPv6）を使用して、通信ピアを保護します。GTSMを使用すると、ベンダー製品とオペレーティングシステムバージョン間の一貫したサポートがないため、内部BGPピア間の限られたシナリオでのみ展開されます。
Packet filters are used to limit which systems can appear as a valid peer, while route filters are used to limit which routes are believed to be from a valid peer. In the case of BGP routing, a variety of policies are deployed to limit the propagation of invalid routing information. These include: incoming and outgoing prefix filters for BGP customers, incoming and outgoing prefix filters for peers and upstream neighbors, incoming AS-PATH filter for BGP customers, outgoing AS-PATH filter towards peers and upstream neighbors, route dampening and rejecting selected attributes and communities. Consistency between these policies varies greatly and there is a definite distinction whether the other end is an end-site vs an internal peer vs another big ISP or customer. Mostly ISPs do prefix-filter their end-site customers, but due to the operational constraints of maintaining large prefix filter lists, many ISPs are starting to depend on BGP AS-PATH filters to/from their peers and upstream neighbors.
パケットフィルターは、有効なピアとして表示できるシステムを制限するために使用され、ルートフィルターは有効なピアからのルートが信じられていると考えられるルートを制限するために使用されます。BGPルーティングの場合、無効なルーティング情報の伝播を制限するために、さまざまなポリシーが展開されます。これらには、BGP顧客向けの着信および発信プレフィックスフィルター、ピアおよび上流の隣人向けの着信および発信プレフィックスフィルター、BGP顧客向けの着信AS-PATHフィルター、ピアおよびアップストリーム隣人への発信AS-PATHフィルター、選択された属性をダンプして拒否するルートコミュニティ。これらのポリシー間の一貫性は大きく異なり、もう一方の端がエンドサイト対内部ピア対別の大きなISPまたは顧客であるかどうかは明確な区別があります。ほとんどのISPは、最終部位の顧客をプレフィックスフィルターしますが、大きなプレフィックスフィルターリストを維持するという運用上の制約により、多くのISPは、ピアやアップストリームの隣人にbgpとして依存し始めています。
In cases where prefix lists are not used, operators often define a maximum prefix limit per peer to prevent misconfiguration (e.g., unintentional de-aggregation or neighbor routing policy mis-configuration) or overload attacks. ISPs need to coordinate with each other what the expected prefix exchange is, and increase this number by some sane amount. It is important for ISPs to pad the max-prefix number enough to allow for valid swings in routing announcements, preventing an unintentional shut down of the BGP session. Individual implementation amongst ISPs are unique, and depending on equipment supplier(s), different implementation options are available. Most equipment vendors offer implementation options ranging from just logging excessive prefixes being received, to automatically shutting down the session. If the option of reestablishing a session after some pre-configured idle timeout has been reached is available, it should be understood that automatically reestablishing the session may potentially introduce instability continuously into the overall routing table if a policy mis-configuration on the adjacent neighbor is causing the condition. If a serious mis-configuration on a peering neighbor has occurred, then automatically shutting down the session and leaving it shut down until being manually cleared, is sometimes best and allows for operator intervention to correct as needed.
プレフィックスリストが使用されていない場合、オペレーターは多くの場合、ピアごとの最大プレフィックス制限を定義して、誤った構成（例：意図しない凝集または隣接ルーティングポリシーの誤った構成など）または過負荷攻撃を防ぎます。ISPは、予想されるプレフィックス交換が何であるかを互いに調整し、この数をいくらか正気な量で増やす必要があります。ISPがルーティングアナウンスで有効なスイングを可能にし、BGPセッションの意図しないシャットダウンを防ぐのに十分なほど最大値の数字を埋めることが重要です。ISP間の個別の実装はユニークであり、機器サプライヤーに応じて、さまざまな実装オプションが利用可能です。ほとんどの機器ベンダーは、受信中の過剰なプレフィックスを記録することから、セッションを自動的にシャットダウンすることまで、実装オプションを提供しています。事前に構成されたアイドルタイムアウトに到達した後にセッションを再確立するオプションが利用可能である場合、セッションを自動的に再確立すると、隣接する近隣のポリシーの誤りがある場合、全体的なルーティングテーブルに不安定性を継続的に導入する可能性があることを理解する必要があります。状態を引き起こします。ピアーリング隣人の深刻な誤った構成が発生した場合、セッションを自動的にシャットダウンして手動でクリアされるまでシャットダウンしたままにしておくことが最善であり、必要に応じてオペレーターの介入が修正されます。
Some large ISPs require that routes be registered in an Internet Routing Registry (IRR), which can then be part of the Routing Assets Database (RADb) - a public registry of routing information for networks in the Internet that can be used to generate filter lists. Some ISPs, especially in Europe, require registered routes before agreeing to become an eBGP peer with someone.
いくつかの大規模なISPは、ルートをインターネットルーティングレジストリ（IRR）に登録することを要求します。これは、ルーティングアセットデータベース（RADB）の一部になります - フィルターリストを生成するために使用できるインターネットのネットワークのルーティング情報のパブリックレジストリで。特にヨーロッパの一部のISPは、誰かとEBGPのピアになることに同意する前に、登録ルートを必要とします。
Many ISPs also do not propagate interface IP addresses to further reduce attack vectors on routers and connected customers.
また、多くのISPは、ルーターと接続された顧客の攻撃ベクトルをさらに削減するために、インターフェイスIPアドレスを伝播しません。
o User Authentication - Not applicable.
o ユーザー認証 - 該当なし。
o User Authorization - Not applicable.
o ユーザー承認 - 該当なし。
o Data Origin Authentication - By using MD5 authentication and/or the TTL-hack, a routing peer can be reasonably certain that traffic originated from a valid peer.
o Data Origin Authentication -MD5認証および/またはTTLハックを使用することにより、ルーティングピアは、トラフィックが有効なピアから発生したことを合理的に確信できます。
o Access Control - Route filters, AS-PATH filters, and prefix limits are used to control access to specific parts of the network.
o アクセス制御 - ルートフィルター、As -Pathフィルター、およびプレフィックス制限は、ネットワークの特定の部分へのアクセスを制御するために使用されます。
o Data Integrity - By using MD5 authentication, a peer can be reasonably certain that the data has not been modified in transit, but there is no mechanism to prove the validity of the routing information itself.
o データの整合性 - MD5認証を使用することにより、ピアはデータが輸送中に変更されていないことを合理的に確信できますが、ルーティング情報自体の妥当性を証明するメカニズムはありません。
o Data Confidentiality - Not implemented.
o データの機密性 - 実装されていません。
o Auditing / Logging - Filter exceptions are logged.
o 監査 /ロギング - フィルターの例外が記録されます。
o DoS Mitigation - Many DoS attacks are mitigated using a combination of techniques including: MD5 authentication, the GTSM feature, filtering routing advertisements to bogons, and filtering routing advertisements to one's own network.
o DOS緩和 - 多くのDOS攻撃は、MD5認証、GTSM機能、ボゴンへのルーティング広告のフィルタリング、自分のネットワークへのルーティング広告のフィルタリングなどの手法の組み合わせを使用して緩和されます。
So far the primary concern to secure the routing control plane has been to validate the sending peer and to ensure that the data in transit has not been altered. Although MD5 routing protocol extensions have been implemented, which can provide both services, they are not consistently deployed amongst ISPs. Two major deployment concerns have been implementation issues, where both software bugs and the lack of graceful re-keying options have caused significant network down times. Also, some ISPs express concern that deploying MD5 authentication will itself be a worse DoS attack victim and prefer to use a combination of other risk mitigation mechanisms such as GTSM (for BGP) and route filters. An issue with GTSM is that it is not supported on all devices across different vendors' products.
これまでのところ、ルーティング制御プレーンを保護するための主な関心事は、送信ピアを検証し、輸送中のデータが変更されていないことを確認することでした。MD5ルーティングプロトコル拡張は実装されていますが、両方のサービスを提供できますが、ISPの間に一貫して展開されていません。2つの主要な展開の懸念が実装の問題であり、ソフトウェアのバグと優雅な再キーイングオプションの欠如の両方が、重要なネットワークのダウンタイムを引き起こしました。また、一部のISPは、MD5認証を展開すること自体がDOS攻撃の犠牲者であり、GTSM（BGP用）やルートフィルターなどの他のリスク緩和メカニズムの組み合わせを使用することを好むことを表明しています。GTSMの問題は、さまざまなベンダーの製品のすべてのデバイスでサポートされていないことです。
IPsec is not deployed since the operational management aspects of ensuring interoperability and reliable configurations is too complex and time consuming to be operationally viable. There is also limited concern to the confidentiality of the routing information. The integrity and validity of the updates are of much greater concern.
IPSECは、相互運用性と信頼性の高い構成を確保するための運用管理の側面が複雑で時間がかかり、運用可能になるには時間がかかるため、展開されません。また、ルーティング情報の機密性にも懸念が限られています。更新の完全性と妥当性は、はるかに懸念されています。
There is concern for manual or automated actions, which introduce new routes and can affect the entire routing domain.
新しいルートを導入し、ルーティングドメイン全体に影響を与える可能性のある手動または自動化されたアクションには懸念があります。
Software upgrades and configuration changes are usually performed as part of either in-band or OOB management functions. However, there are additional considerations to be taken into account, which are enumerated in this section.
ソフトウェアのアップグレードと構成の変更は、通常、インバンドまたはOOB管理機能のいずれかの一部として実行されます。ただし、このセクションで列挙されている追加の考慮事項が考慮されています。
Attacks performed on system software and configurations can be both from passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the network infrastructure device and the system which is downloading or uploading the software or configuration information. This can be accomplished if a single infrastructure device is somehow compromised and can act as a network sniffer, or if it is possible to insert a new device that acts as a network sniffer.
システムソフトウェアと構成で実行される攻撃は、パッシブソースまたはアクティブなソースの両方からのものです。誰かがネットワークインフラストラクチャデバイスとソフトウェアまたは構成情報をダウンロードまたはアップロードしているシステムとの間にデータを傍受する機能がある場合、パッシブ攻撃が可能です。これは、単一のインフラストラクチャデバイスが何らかの形で侵害され、ネットワークスニファーとして機能する可能性がある場合、またはネットワークスニファーとして機能する新しいデバイスを挿入できる場合に実現できます。
Active attacks are possible for both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack, where either a device has to already be compromised or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modification where the attacker may wish to load illegal software or configuration files to an infrastructure device.
オンパスとオフパスの両方のシナリオでは、アクティブな攻撃が可能です。パスでアクティブな攻撃の場合、状況はパッシブ攻撃の場合と同じです。この攻撃では、デバイスを既に妥協する必要があるか、デバイスをパスに挿入できます。オフパスアクティブ攻撃の場合、攻撃は一般にメッセージ挿入または変更に限定されます。攻撃者は、違法なソフトウェアまたは構成ファイルをインフラストラクチャデバイスにロードすることを希望する場合があります。
Note that similar issues are relevant when software updates are downloaded from a vendor site to an ISPs network management system that is responsible for software updates and/or configuration information.
ソフトウェアの更新がソフトウェアの更新や構成情報を担当するISPSネットワーク管理システムにダウンロードされると、ソフトウェアの更新がダウンロードされた場合、同様の問題が関連することに注意してください。
Confidentiality violations can occur when a miscreant intercepts any of the software image or configuration information. The software image may give an indication of exploits which the device is vulnerable to while the configuration information can inadvertently lead attackers to identify critical infrastructure IP addresses and passwords.
機密性違反は、悪党がソフトウェアの画像または構成情報を傍受するときに発生する可能性があります。ソフトウェアイメージは、設定情報が攻撃者を不注意にリードして重要なインフラストラクチャのIPアドレスとパスワードを識別することができる一方で、デバイスが脆弱なエクスプロイトの兆候を示す場合があります。
If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the communication path or by being able to divert traffic to a malicious user.
データの整合性と機密性を提供するために暗号化メカニズムが使用された場合、オフラインの暗号攻撃がデータを損なう可能性があります。トラフィックは、通信パスを盗聴するか、悪意のあるユーザーにトラフィックを迂回させることができることによってキャプチャする必要があります。
For a replay attack to be successful, the software image or configuration file would need to first be captured either on-path or diverted to an attacker to later be replayed to the intended recipient. Additionally, since many protocols do have replay protection capabilities, these would have to be subverted as well in applicable situations.
リプレイ攻撃を成功させるには、ソフトウェアイメージまたは構成ファイルを最初にオンパスでキャプチャするか、攻撃者に転用して、後で意図した受信者に再生される必要があります。さらに、多くのプロトコルにはリプレイ保護機能があるため、適用される状況でもこれらを破壊する必要があります。
Software images and configuration files can be manipulated by someone in control of intermediate hosts. By forging an IP address and impersonating a valid host which can download software images or configuration files, invalid files can be downloaded to an infrastructure device. This can also be the case from trusted vendors who may unbeknownst to them have compromised trusted hosts. An invalid software image or configuration file can cause a device to hang and become inoperable. Spoofed configuration files can be hard to detect, especially when the only added command is to allow a miscreant access to that device by entering a filter allowing a specific host access and configuring a local username/password database entry for authentication to that device.
ソフトウェアイメージと構成ファイルは、中間ホストを制御する人によって操作できます。IPアドレスを偽造し、ソフトウェア画像または構成ファイルをダウンロードできる有効なホストになりすまして、無効なファイルをインフラストラクチャデバイスにダウンロードできます。これは、信頼できるホストを妥協していない可能性のある信頼できるベンダーの場合にもなります。無効なソフトウェアイメージまたは構成ファイルにより、デバイスがハングして動作不能になる可能性があります。特に追加のコマンドが、特定のホストアクセスを許可し、そのデバイスへの認証用のローカルユーザー名/パスワードデータベースエントリを構成することにより、そのデバイスへの不正なアクセスを許可することのみが追加されたコマンドである場合、スプーフィングされた構成ファイルを検出するのが難しい場合があります。
A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent between the infrastructure device and the host used to upload/download the system image or configuration file. He/she can then act on behalf of one or both of these systems.
中間の攻撃は、データストリーム自体ではなく、通信ピアのアイデンティティを攻撃します。攻撃者は、インフラストラクチャデバイスとシステムイメージまたは構成ファイルのアップロード/ダウンロードに使用されるホストとの間に送信されるトラフィックを傍受します。彼/彼女は、これらのシステムの一方または両方に代わって行動できます。
If an attacker obtained a copy of the software image being deployed, he could potentially exploit a known vulnerability and gain access to the system. From a captured configuration file, he could obtain confidential network topology information, or even more damaging information, if any of the passwords in the configuration file were not encrypted.
攻撃者が展開されているソフトウェア画像のコピーを取得した場合、既知の脆弱性を悪用し、システムにアクセスできる可能性があります。キャプチャされた構成ファイルから、構成ファイルのパスワードのいずれかが暗号化されていない場合、機密ネットワークトポロジ情報、またはさらに損害を与える情報を取得できます。
Images and configurations are stored on specific hosts that have limited access. All access and activity relating to these hosts are authenticated and logged via AAA services. When uploaded/downloading any system software or configuration files, either TFTP, FTP, or SCP can be used. Where possible, SCP is used to secure the data transfer and FTP is generally never used. All SCP access is username/password authenticated but since this requires an interactive shell, most ISPs will use shared key authentication to avoid the interactive shell. While TFTP access does not have any security measures, it is still widely used, especially in OOB management scenarios. Some ISPs implement IP-based restriction on the TFTP server, while some custom written TFTP servers will support MAC-based authentication. The MAC-based authentication is more common when using TFTP to bootstrap routers remotely.
画像と構成は、アクセスが制限されている特定のホストに保存されます。これらのホストに関連するすべてのアクセスとアクティビティは、AAAサービスを介して認証および記録されます。システムソフトウェアまたは構成ファイルをアップロード/ダウンロードすると、TFTP、FTP、またはSCPのいずれかを使用できます。可能であれば、SCPはデータ転送を保護するために使用され、FTPは通常使用されません。すべてのSCPアクセスはユーザー名/パスワードが認証されていますが、これにはインタラクティブなシェルが必要なため、ほとんどのISPは共有キー認証を使用してインタラクティブシェルを回避します。TFTPアクセスにはセキュリティ対策はありませんが、特にOOB管理シナリオでは、依然として広く使用されています。一部のISPは、TFTPサーバーにIPベースの制限を実装していますが、一部のカスタム作成されたTFTPサーバーはMacベースの認証をサポートします。TFTPを使用してルーターをリモートでブートストラップする場合、Macベースの認証はより一般的です。
In most environments, scripts are used for maintaining the images and configurations of a large number of routers. To ensure the integrity of the configurations, every hour the configuration files are polled and compared to the previously polled version to find discrepancies. In at least one environment these, tools are Kerberized to take advantage of automated authentication (not confidentiality). 'Rancid' is one popular publicly available tool for detecting configuration and system changes.
ほとんどの環境では、スクリプトは、多数のルーターの画像と構成を維持するために使用されます。構成の整合性を確保するために、1時間ごとに構成ファイルがポーリングされ、以前にポーリングされたバージョンと比較して不一致を見つける。少なくとも1つの環境では、これらのツールは自動認証（機密性ではなく）を活用するためにKerberizedです。「Rancid」は、構成とシステムの変更を検出するための一般的に利用可能な一般的なツールの1つです。
Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses and protocols.
フィルターは、構成ファイルとシステムイメージのアップロード/ダウンロードへのアクセスを特定のIPアドレスとプロトコルに制限するために使用されます。
The software images perform Cyclic Redundancy Checks (CRC) and the system binaries use the MD5 algorithm to validate integrity. Many ISPs expressed interest in having software image integrity validation based on the MD5 algorithm for enhanced security.
ソフトウェア画像は、環状冗長チェック（CRC）を実行し、システムバイナリはMD5アルゴリズムを使用して整合性を検証します。多くのISPは、セキュリティを強化するためのMD5アルゴリズムに基づいてソフトウェアイメージの整合性検証を持つことに関心を示しました。
In all configuration files, most passwords are stored in an encrypted format. Note that the encryption techniques used in varying products can vary and that some weaker encryption schemes may be subject to off-line dictionary attacks. This includes passwords for user authentication, MD5-authentication shared secrets, AAA server shared secrets, NTP shared secrets, etc. For older software that may not support this functionality, configuration files may contain some passwords in readable format. Most ISPs mitigate any risk of password compromise by either storing these configuration files without the password lines or by requiring authenticated and authorized access to the configuration files that are stored on protected OOB management devices.
すべての構成ファイルで、ほとんどのパスワードは暗号化された形式で保存されます。さまざまな製品で使用される暗号化手法はさまざまであり、いくつかの弱い暗号化スキームはオフラインの辞書攻撃の対象となる可能性があることに注意してください。これには、ユーザー認証のパスワード、MD5-Authentication Shared Secrets、AAA Server Shared Secrets、NTP共有シークレットなどが含まれます。ほとんどのISPは、パスワード行なしでこれらの構成ファイルを保存するか、保護されているOOB管理デバイスに保存されている構成ファイルへの認証された承認されたアクセスを要求することにより、パスワードの妥協のリスクを軽減します。
Automated security validation is performed on infrastructure devices using Network Mapping (Nmap) and Nessus to ensure valid configuration against many of the well-known attacks.
自動セキュリティ検証は、ネットワークマッピング（NMAP）とnessusを使用してインフラストラクチャデバイスで実行され、多くの既知の攻撃に対する有効な構成を確保します。
o User Authentication - All users are authenticated before being able to download/upload any system images or configuration files.
o ユーザー認証 - すべてのユーザーは、システム画像または構成ファイルをダウンロード/アップロードする前に認証されます。
o User Authorization - All authenticated users are granted specific privileges to download or upload system images and/or configuration files.
o ユーザー承認 - すべての認証されたユーザーには、システムイメージおよび/または構成ファイルをダウンロードまたはアップロードするための特定の特権が付与されます。
o Data Origin Authentication - Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses.
o Data Origin Authentication -Filtersは、構成ファイルとシステム画像のアップロード/ダウンロードへのアクセスを特定のIPアドレスに制限するために使用されます。
o Access Control - Filters are used to limit access to uploading/ downloading configuration files and system images to specific IP addresses and protocols.
o アクセス制御 - フィルターは、構成ファイルとシステムイメージのアップロード/ダウンロードへのアクセスを特定のIPアドレスとプロトコルに制限するために使用されます。
o Data Integrity - All systems use either a CRC-check or MD5 authentication to ensure data integrity. Also, tools such as rancid are used to automatically detect configuration changes.
o データの整合性 - すべてのシステムは、CRCチェックまたはMD5認証を使用して、データの整合性を確保します。また、RANCIDなどのツールを使用して、構成の変更を自動的に検出します。
o Data Confidentiality - If the SCP protocol is used then there is confidentiality of the downloaded/uploaded configuration files and system images.
o データの機密性 - SCPプロトコルを使用する場合、ダウンロード/アップロードされた構成ファイルとシステム画像の機密性があります。
o Auditing/Logging - All access and activity relating to downloading/uploading system images and configuration files are logged via AAA services and filter exception rules.
o 監査/ロギング - システム画像と構成ファイルのダウンロード/アップロードに関連するすべてのアクセスとアクティビティは、AAAサービスとフィルター例外ルールを介して記録されます。
o DoS Mitigation - A combination of filtering and CRC-check/ MD5-based integrity checks are used to mitigate the risks of DoS attacks. If the software updates and configuration changes are performed via an OOB management system, this is also added protection.
o DOS緩和 - フィルタリングとCRC-Check/ MD5ベースの完全性チェックの組み合わせを使用して、DOS攻撃のリスクを軽減します。ソフトウェアの更新と構成の変更がOOB管理システムを介して実行される場合、これも追加されます。
Where the MD5 algorithm is not used to perform data-integrity checking of software images and configuration files, ISPs have expressed an interest in having this functionality. IPsec is considered too cumbersome and operationally difficult to use for data integrity and confidentiality.
MD5アルゴリズムがソフトウェア画像と構成ファイルのデータ積分チェックを実行するために使用されない場合、ISPはこの機能を持つことに関心を表明しています。IPSECは、データの整合性と機密性に使用するのが面倒で、運用上困難であると考えられています。
Although logging is part of all the previous sections, it is important enough to be covered as a separate item. The main issues revolve around what gets logged, how long are logs kept, and what mechanisms are used to secure the logged information while it is in transit and while it is stored.
ロギングは以前のすべてのセクションの一部ですが、別のアイテムとしてカバーするのに十分重要です。主な問題は、ログに記録されるもの、ログが維持されている期間、および輸送中および保存中にログされた情報を保護するために使用されるメカニズムを中心に展開します。
Attacks on the logged data can be both from passive or active sources. Passive attacks are possible if someone has the capability to intercept data between the recipient logging server and the device from which the logged data originated. This can be accomplished if a single infrastructure device is somehow compromised and can act as a network sniffer, or if it is possible to insert a new device that acts as a network sniffer.
記録されたデータに対する攻撃は、パッシブソースまたはアクティブなソースの両方からのものです。受信攻撃は、受信者ロギングサーバーとログに記録されたデータが発信されたデバイスとの間にデータを傍受する機能がある場合、可能です。これは、単一のインフラストラクチャデバイスが何らかの形で侵害され、ネットワークスニファーとして機能する可能性がある場合、またはネットワークスニファーとして機能する新しいデバイスを挿入できる場合に実現できます。
Active attacks are possible for both on-path and off-path scenarios. For on-path active attacks, the situation is the same as for a passive attack, where either a device has to already be compromised, or a device can be inserted into the path. For off-path active attacks, the attacks are generally limited to message insertion or modification that can alter the logged data to keep any compromise from being detected, or to destroy any evidence that could be used for criminal prosecution.
オンパスとオフパスの両方のシナリオでは、アクティブな攻撃が可能です。パスでアクティブな攻撃の場合、状況はパッシブ攻撃の場合と同じです。この攻撃では、デバイスを既に妥協する必要があるか、デバイスをパスに挿入できます。オフパスのアクティブな攻撃の場合、攻撃は一般に、ログデータを変更して妥協が検出されないようにしたり、刑事訴追に使用できる証拠を破壊したりすることができるメッセージ挿入または変更に限定されます。
Confidentiality violations can occur when a miscreant intercepts any of the logging data that is in transit on the network. This could lead to privacy violations if some of the logged data has not been sanitized to disallow any data that could be a violation of privacy to be included in the logged data.
機密性違反は、悪党がネットワーク上で輸送中のログデータを傍受すると発生する可能性があります。ログに含まれるデータに含まれるプライバシーの違反になる可能性のあるデータを禁止するように記録されたデータの一部が消毒されていない場合、これはプライバシー違反につながる可能性があります。
If any cryptographic mechanism was used to provide for data integrity and confidentiality, an offline cryptographic attack could potentially compromise the data. The traffic would need to be captured either by eavesdropping on the network or by being able to divert traffic to a malicious user.
データの整合性と機密性を提供するために暗号化メカニズムが使用された場合、オフラインの暗号攻撃がデータを損なう可能性があります。トラフィックは、ネットワーク上で盗聴するか、悪意のあるユーザーにトラフィックを迂回させることができることによってキャプチャする必要があります。
For a replay attack to be successful, the logging data would need to first be captured either on-path or diverted to an attacker and later replayed to the recipient.
リプレイ攻撃を成功させるには、ロギングデータを最初にパスでキャプチャするか、攻撃者に転用し、後で受信者に再生される必要があります。
Logging data could be injected, deleted, or modified by someone in control of intermediate hosts. Logging data can also be injected by forging packets from either legitimate or illegitimate IP addresses.
ロギングデータは、中間ホストを制御している人が注入、削除、または変更できます。ロギングデータは、正当なIPアドレスまたは違法なIPアドレスのいずれかからパケットを偽造することで注入することもできます。
A man-in-the-middle attack attacks the identity of a communicating peer rather than the data stream itself. The attacker intercepts traffic that is sent between the infrastructure device and the logging server or traffic sent between the logging server and the database that is used to archive the logged data. Any unauthorized access to logging information could lead to the knowledge of private and proprietary network topology information, which could be used to compromise portions of the network. An additional concern is having access to logging information, which could be deleted or modified so as to cover any traces of a security breach.
中間の攻撃は、データストリーム自体ではなく、通信ピアのアイデンティティを攻撃します。攻撃者は、インフラストラクチャデバイスとロギングサーバーの間に送信されるトラフィックまたはロギングサーバーと、ログされたデータのアーカイブに使用されるデータベース間で送信されるトラフィックをインターセプトします。ロギング情報への不正アクセスは、ネットワークの一部を妥協するために使用できるプライベートおよび独自のネットワークトポロジ情報の知識につながる可能性があります。追加の懸念は、ロギング情報にアクセスできることです。これは、セキュリティ侵害の痕跡をカバーするために削除または変更できます。
When it comes to filtering, logging is mostly performed on an exception auditing basis (i.e., traffic that is NOT allowed is logged). This is to assure that the logging servers are not overwhelmed with data, which would render most logs unusable. Typically the data logged will contain the source and destination IP addresses and layer 4 port numbers as well as a timestamp. The syslog protocol is used to transfer the logged data between the infrastructure device to the syslog server. Many ISPs use the OOB management network to transfer syslog data since there is virtually no security performed between the syslog server and the device. All ISPs have multiple syslog servers - some ISPs choose to use separate syslog servers for varying infrastructure devices (i.e., one syslog server for backbone routers, one syslog server for customer edge routers, etc.)
フィルタリングに関しては、ロギングはほとんど例外監査ベースで実行されます（つまり、許可されていないトラフィックが記録されます）。これは、ロギングサーバーがデータに圧倒されないことを保証するためです。これにより、ほとんどのログが使用できなくなります。通常、ログに記録されたデータには、ソースと宛先のIPアドレスとレイヤー4ポート番号、およびタイムスタンプが含まれます。Syslogプロトコルは、インフラストラクチャデバイス間でログデータをSyslogサーバーに転送するために使用されます。Syslogサーバーとデバイスの間にセキュリティが実質的に実行されていないため、多くのISPはOOB管理ネットワークを使用してSyslogデータを転送します。すべてのISPには複数のSyslogサーバーがあります - 一部のISPは、さまざまなインフラストラクチャデバイスに個別のSyslogサーバーを使用することを選択します（つまり、バックボーンルーター用の1つのSyslogサーバー、顧客エッジルーター用の1つのSyslogサーバーなど）
The timestamp is derived from NTP, which is generally configured as a flat hierarchy at stratum1 and stratum2 to have less configuration and less maintenance. Consistency of configuration and redundancy is the primary goal. Each router is configured with several stratum1 server sources, which are chosen to ensure that proper NTP time is available, even in the event of varying network outages.
タイムスタンプはNTPから派生しています。NTPは、通常、Stratum1とStratum2のフラット階層として構成され、構成が少なくメンテナンスが少なくなります。構成と冗長性の一貫性が主な目標です。各ルーターは、ネットワークの停止が異なる場合でも、適切なNTP時間が利用可能であることを確認するために選択されたいくつかのStratum1サーバーソースで構成されています。
In addition to logging filtering exceptions, the following is typically logged: routing protocol state changes, all device access (regardless of authentication success or failure), all commands issued to a device, all configuration changes, and all router events (boot-up/flaps).
フィルタリングの例外のログに加えて、通常、以下はログに記録されます：ルーティングプロトコル状態の変更、すべてのデバイスアクセス（認証の成功または障害に関係なく）、デバイスに発行されたすべてのコマンド、すべての構成の変更、およびすべてのルーターイベント（ブートアップ/フラップ）。
The main function of any of these log messages is to see what the device is doing as well as to try and ascertain what certain malicious attackers are trying to do. Since syslog is an unreliable protocol, when routers boot or lose adjacencies, not all messages will get delivered to the remote syslog server. Some vendors may implement syslog buffering (e.g., buffer the messages until you have a route to the syslog destination), but this is not standard. Therefore, operators often have to look at local syslog information on a device (which typically has very little memory allocated to it) to make up for the fact that the server-based syslog files can be incomplete. Some ISPs also put in passive devices to see routing updates and withdrawals and do not rely solely on the device for log files. This provides a backup mechanism to see what is going on in the network in the event that a device may 'forget' to do syslog if the CPU is busy.
これらのログメッセージのいずれかの主な機能は、デバイスが何をしているかを確認し、特定の悪意のある攻撃者が何をしようとしているかを確認しようとすることです。Syslogは信頼性の低いプロトコルであるため、ルーターが隣接を起動または失うと、すべてのメッセージがリモートSyslogサーバーに配信されるわけではありません。一部のベンダーは、Syslogバッファリングを実装する場合があります（たとえば、Syslogの宛先へのルートがあるまでメッセージをバッファリングします）が、これは標準ではありません。したがって、オペレーターは多くの場合、サーバーベースのSyslogファイルが不完全である可能性があるという事実を補うために、デバイス上のローカルSyslog情報（通常はメモリがほとんど割り当てられていません）を調べる必要があります。一部のISPは、ルーティングの更新と引き出しを確認するためにパッシブデバイスを入れており、ログファイルのためにデバイスのみに依存していません。これにより、CPUがビジーである場合、デバイスがSyslogを実行することを「忘れている」可能性がある場合、ネットワークで何が起こっているかを確認するためのバックアップメカニズムが提供されます。
The logs from the various syslog server devices are generally transferred into databases at a set interval that can be anywhere from every 10 minutes to every hour. One ISP uses Rsync to push the data into a database, and then the information is sorted manually by someone SSH'ing to that database.
さまざまなSyslogサーバーデバイスからのログは、通常、10分ごとに1時間ごとにどこにでもある設定された間隔でデータベースに転送されます。1つのISPはRSYNCを使用してデータをデータベースに押し込み、そのデータはそのデータベースにsshしている人によって手動でソートされます。
o User Authentication - Not applicable.
o ユーザー認証 - 該当なし。
o User Authorization - Not applicable.
o ユーザー承認 - 該当なし。
o Data Origin Authentication - Not implemented.
o Data Origin Authentication-実装されていません。
o Access Control - Filtering on logging host and server IP address to ensure that syslog information only goes to specific syslog hosts.
o アクセス制御 - ロギングホストとサーバーIPアドレスのフィルタリングは、Syslog情報が特定のSyslogホストにのみ届くようにします。
o Data Integrity - Not implemented.
o データの整合性 - 実装されていません。
o Data Confidentiality - Not implemented.
o データの機密性 - 実装されていません。
o Auditing/Logging - This entire section deals with logging.
o 監査/ロギング - このセクション全体でロギングを扱います。
o DoS Mitigation - An OOB management system is used and sometimes different syslog servers are used for logging information from varying equipment. Exception logging tries to keep information to a minimum.
o DOS緩和 - OOB管理システムが使用され、さまざまな機器からの情報のログに異なるSyslogサーバーが使用される場合があります。例外ロギングは、情報を最小限に抑えようとします。
There is no security with syslog and ISPs are fully cognizant of this. IPsec is considered too operationally expensive and cumbersome to deploy. Syslog-ng and stunnel are being looked at for providing better authenticated and integrity-protected solutions. Mechanisms to prevent unauthorized personnel from tampering with logs is constrained to auditing who has access to the logging servers and files.
Syslogにはセキュリティはなく、ISPはこれを完全に認識しています。IPSECは、運用上高価すぎて展開するには面倒であると考えられています。Syslog-ngとStunnelは、より適切に認証された整合性保護されたソリューションを提供するために検討されています。許可されていない人員がログを改ざんするのを防ぐためのメカニズムは、ロギングサーバーやファイルにアクセスできる監査に制約されます。
ISPs expressed requirements for more than just UDP syslog. Additionally, they would like more granular and flexible facilities and priorities, i.e., specific logs to specific servers. Also, a common format for reporting standard events so that modifying parsers after each upgrade of a vendor device or software is not necessary.
ISPは、UDP Syslog以上の要件を表明しました。さらに、より詳細で柔軟な施設と優先順位、つまり特定のサーバーへの特定のログが必要です。また、ベンダーデバイスまたはソフトウェアの各アップグレード後にパーサーを変更するための標準イベントを報告するための一般的な形式は必要ありません。
Although filtering has been covered under many of the previous sections, this section will provide some more insights to the filtering considerations that are currently being taken into account. Filtering is now being categorized into three specific areas: data plane, management plane, and routing control plane.
フィルタリングは以前のセクションの多くでカバーされていますが、このセクションでは、現在考慮されているフィルタリングの考慮事項に対するいくつかの洞察を提供します。フィルタリングは現在、データプレーン、管理プレーン、およびルーティング制御プレーンの3つの特定の領域に分類されています。
Data plane filters control the traffic that traverses through a device and affects transit traffic. Most ISPs deploy these kinds of filters at customer facing edge devices to mitigate spoofing attacks using BCP38 and BCP84 guidelines.
データプレーンフィルターは、デバイスを通過して輸送トラフィックに影響を与えるトラフィックを制御します。ほとんどのISPは、BCP38およびBCP84ガイドラインを使用してスプーフィング攻撃を緩和するために、顧客向けのエッジデバイスにこれらの種類のフィルターを展開します。
Management filters control the traffic to and from a device. All of the protocols that are used for device management fall under this category and include: SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP, SCP, and Syslog. This type of traffic is often filtered per interface and is based on any combination of protocol, source and destination IP address, and source and destination port number. Some devices support functionality to apply management filters to the device rather than to the specific interfaces (e.g., receive ACL or loopback interface ACL), which is gaining wider acceptance. Note that logging the filtering rules can today place a burden on many systems and more granularity is often required to more specifically log the required exceptions.
管理フィルターは、デバイスとの間のトラフィックを制御します。デバイス管理に使用されるすべてのプロトコルは、このカテゴリに分類され、SSH、Telnet、SNMP、NTP、HTTP、DNS、TFTP、FTP、SCP、およびSyslogが含まれます。このタイプのトラフィックは、多くの場合、インターフェイスごとにフィルタリングされ、プロトコル、ソースおよび宛先IPアドレス、およびソースおよび宛先ポート番号の任意の組み合わせに基づいています。一部のデバイスは、特定のインターフェイス（たとえば、ACLまたはループバックインターフェイスACLを受信するなど）ではなく、デバイスに管理フィルターを適用する機能をサポートしています。フィルタリングルールをログすると、今日多くのシステムに負担がかかる可能性があり、必要な例外をより具体的に記録するために、より多くの粒度性が必要になることがよくあります。
Any services that are not specifically used are turned off.
特別に使用されていないサービスはオフになります。
IPv6 networks require the use of specific ICMP messages for proper protocol operation. Therefore, ICMP cannot be completely filtered to and from a device. Instead, granular ICMPv6 filtering is always deployed to allow for specific ICMPv6 types to be sourced or destined to a network device. A good guideline for IPv6 filtering is in the Recommendations for Filtering ICMPv6 Messages in Firewalls [ICMPv6].
IPv6ネットワークでは、適切なプロトコル操作のために特定のICMPメッセージを使用する必要があります。したがって、ICMPをデバイスとの間で完全にフィルタリングすることはできません。代わりに、粒状ICMPV6フィルタリングは常に展開されて、特定のICMPV6タイプをネットワークデバイスに供給または運命づけることができます。IPv6フィルタリングの適切なガイドラインは、ファイアウォール[ICMPv6]でICMPV6メッセージをフィルタリングするための推奨事項にあります。
Routing filters are used to control the flow of routing information. In IPv6 networks, some providers are liberal in accepting /48s due to the still unresolved multihoming issues, while others filter at allocation boundaries, which are typically at /32. Any announcement received that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing is filtered out of eBGP. Note that this is for non-customer traffic. Most ISPs will accept any agreed upon prefix length from its customer(s).
ルーティングフィルターは、ルーティング情報のフローを制御するために使用されます。IPv6ネットワークでは、一部のプロバイダーは、まだ解決されていないマルチホームの問題のために /48sを受け入れるのにリベラルであり、他のプロバイダーは通常 /32にある配分境界でフィルターします。IPv6ルーティングの場合はA /48よりも長く、IPv4ルーティングの場合はA /24よりも長い発表がEBGPからフィルタリングされます。これは非カスタマートラフィック用であることに注意してください。ほとんどのISPは、顧客から合意されたプレフィックスの長さを受け入れます。
Denial-of-Service attacks are an ever-increasing problem and require vast amounts of resources to combat effectively. Some large ISPs do not concern themselves with attack streams that are less than 1G in bandwidth - this is on the larger pipes where 1G is essentially less than 5% of an offered load. This is largely due to the large amounts of DoS traffic, which continually requires investigation and mitigation. At last count, the number of hosts making up large distributed DoS botnets exceeded 1 million hosts.
サービス拒否攻撃は増え続ける問題であり、効果的に戦うために膨大な量のリソースが必要です。いくつかの大きなISPは、帯域幅が1g未満の攻撃ストリームには関係ありません - これは、1Gが提供された負荷の5％未満である大きなパイプ上にあります。これは、主に大量のDOSトラフィックが原因で、調査と緩和が継続的に必要です。最後に、大規模な分散DOSボットネットを構成するホストの数は100万人のホストを超えました。
New techniques are continually evolving to automate the process of detecting DoS sources and mitigating any adverse effects as quickly as possible. At this time, ISPs are using a variety of mitigation techniques including: sinkhole routing, black hole triggered routing, uRPF, rate limiting, and specific control plane traffic enhancements. Each of these techniques will be detailed below.
DOSソースを検出し、可能な限り迅速に副作用を軽減するプロセスを自動化するために、新しい技術が継続的に進化しています。現時点では、ISPは、陥没穴ルーティング、ブラックホールトリガールーティング、URPF、レート制限、特定のコントロールプレーントラフィックの強化など、さまざまな緩和手法を使用しています。これらの各手法については、以下に詳しく説明します。
Sinkhole routing refers to injecting a more specific route for any known attack traffic, which will ensure that the malicious traffic is redirected to a valid device or specific system where it can be analyzed.
陥没穴ルーティングとは、既知の攻撃トラフィックに対してより具体的なルートを注入することを指します。これにより、悪意のあるトラフィックが有効なデバイスまたは分析できる特定のシステムにリダイレクトされることが保証されます。
Black hole triggered routing (also referred to as Remote Triggered Black Hole Filtering) is a technique where the BGP routing protocol is used to propagate routes which in turn redirects attack traffic to the null interface where it is effectively dropped. This technique is often used in large routing infrastructures since BGP can propagate the information in a fast, effective manner, as opposed to using any packet-based filtering techniques on hundreds or thousands of routers (refer to the following NANOG presentation for a more complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf).
ブラックホールトリガールーティング（リモートトリガートリガーブラックホールフィルタリングとも呼ばれる）は、BGPルーティングプロトコルを使用してルートを伝播するために使用され、それが効果的にドロップされているNULLインターフェイスにトラフィックをリダイレクトする手法です。この手法は、数百または数千のルーターでパケットベースのフィルタリング技術を使用するのではなく、BGPが高速で効果的な方法で情報を伝播することができるため、大規模なルーティングインフラストラクチャでよく使用されます（以下のNANOGプレゼンテーションを参照して、より完全な説明を参照してください。http://www.nanog.org/mtg-0402/pdf/morrow.pdf）。
Note that this black-holing technique may actually fulfill the goal of the attacker if the goal was to instigate black-holing traffic that appeared to come from a certain site. On the other hand, this black hole technique can decrease the collateral damage caused by an overly large attack aimed at something other than critical services.
目標が特定のサイトから来たと思われるブラックホーリングトラフィックを扇動することであった場合、このブラックホーリング技術は実際に攻撃者の目標を達成する可能性があることに注意してください。一方、このブラックホールのテクニックは、重要なサービス以外の何かを目的とした非常に大きな攻撃によって引き起こされる付随的損害を減らすことができます。
Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating whether or not an incoming packet has a legitimate source address. It has two modes: strict mode and loose mode. In strict mode, uRPF checks whether the incoming packet has a source address that matches a prefix in the routing table, and whether the interface expects to receive a packet with this source address prefix. If the incoming packet fails the unicast RPF check, the packet is not accepted on the incoming interface. Loose mode uRPF is not as specific and the incoming packet is accepted if there is any route in the routing table for the source address.
ユニキャストリバースパス転送（URPF）は、着信パケットが正当なソースアドレスを持っているかどうかを検証するメカニズムです。Strict Modeとルーズモードの2つのモードがあります。厳密なモードでは、URPFは、着信パケットにルーティングテーブルのプレフィックスと一致するソースアドレスがあるかどうか、およびインターフェイスがこのソースアドレスのプレフィックスでパケットを受信することを期待しているかどうかをチェックします。着信パケットがUnicast RPFチェックに障害に失敗した場合、着信インターフェイスでパケットは受け入れられません。ルーズモードURPFはそれほど具体的ではなく、ソースアドレスのルーティングテーブルにルートがある場合、着信パケットは受け入れられます。
While BCP84 [RFC3704] and a study on uRPF experiences [BCP84-URPF] detail how asymmetry, i.e., multiple routes to the source of a packet, does not preclude applying feasible paths strict uRPF, it is generally not used on interfaces that are likely to have routing asymmetry. Usually for the larger ISPs, uRPF is placed at the customer edge of a network.
BCP84 [RFC3704]およびURPF経験に関する研究[BCP84-URPF]は、非対称性、つまりパケットのソースへの複数のルートが実行可能なパスの厳格なURPFを適用することを排除しないことを詳述していますが、一般的には一般的には、一般的には使用されない可能性があります。ルーティングの非対称性を持つこと。通常、より大きなISPの場合、URPFはネットワークの顧客エッジに配置されます。
Rate limiting refers to allocating a specific amount of bandwidth or packets per second to specific traffic types. This technique is widely used to mitigate well-known protocol attacks such as the TCP-SYN attack, where a large number of resources get allocated for spoofed TCP traffic. Although this technique does not stop an attack, it can sometimes lessen the damage and impact on a specific service. However, it can also make the impact of a DoS attack much worse if the rate limiting is impacting (i.e., discarding) more legitimate traffic.
レート制限とは、特定のトラフィックタイプに特定の量の帯域幅またはパケットを割り当てることを指します。この手法は、TCP-Syn攻撃などのよく知られたプロトコル攻撃を緩和するために広く使用されており、TCPトラフィックに多数のリソースが割り当てられます。この手法は攻撃を止めませんが、特定のサービスへの損傷と影響を軽減することがあります。ただし、レートの制限がより合法的なトラフィックに影響を与えている（つまり、破棄する）場合、DOS攻撃の影響をはるかに悪化させる可能性もあります。
Some ISPs are starting to use capabilities that are available from some vendors to simplify the filtering and rate limiting of control traffic. Control traffic here refers to the routing control plane and management plane traffic that requires CPU cycles. A DoS attack against any control plane traffic can therefore be much more damaging to a critical device than other types of traffic. No consistent deployment of this capability was found at the time of this writing.
一部のISPは、一部のベンダーから利用可能な機能を使用して、制御トラフィックのフィルタリングとレートの制限を簡素化しています。ここでの制御トラフィックとは、CPUサイクルを必要とするルーティング制御プレーンと管理プレーンのトラフィックを指します。したがって、コントロールプレーンのトラフィックに対するDOS攻撃は、他のタイプのトラフィックよりも重要なデバイスにとってはるかに損害を与える可能性があります。この執筆時点では、この機能の一貫した展開は見つかりませんでした。
This entire document deals with current security practices in large ISP environments. It lists specific practices used in today's environments and as such, does not in itself pose any security risk.
このドキュメント全体は、大規模なISP環境での現在のセキュリティ慣行を扱っています。今日の環境で使用されている特定のプラクティスをリストしているため、セキュリティリスクをもたらすことはありません。
The editor gratefully acknowledges the contributions of: George Jones, who has been instrumental in providing guidance and direction for this document, and the insightful comments from Ross Callon, Ron Bonica, Ryan Mcdowell, Gaurab Upadhaya, Warren Kumari, Pekka Savola, Fernando Gont, Chris Morrow, Ted Seely, Donald Smith, and the numerous ISP operators who supplied the information that is depicted in this document.
編集者は、このドキュメントのガイダンスと方向性を提供するのに役立ったジョージ・ジョーンズ、ロス・カロン、ロン・ボニカ、ロン・マクダウェル、ガウラブ・ウパダヤ、ウォーレン・クマリ、ペッカ・サヴォラ、フェルナンド・ゴント、フェルナンド・ゴントの洞察に満ちたコメントの貢献を感謝して認めています。クリス・モロー、テッド・シーリー、ドナルド・スミス、およびこの文書に描かれている情報を提供した多数のISPオペレーター。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[RFC2828] Shirey、R。、「インターネットセキュリティ用語集」、RFC 2828、2000年5月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[RFC3882] Turk、D。、「サービス拒否攻撃をブロックするためにBGPの構成」、RFC 3882、2004年9月。
[BCP84-URPF] Savola, P., "Experiences from Using Unicast RPF", Work in Progress, November 2006.
[BCP84-URPF] Savola、P。、「Unicast RPFの使用経験」、2006年11月、作業中。
[ICMPv6] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", Work in Progress, July 2006.
[ICMPV6] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPV6メッセージのフィルタリングに関する推奨事項」、2006年7月、進行中の作業。
[RTGWG] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, July 2006.
[RTGWG] Savola、P。、「バックボーンインフラストラクチャの攻撃と保護」、2006年7月、進行中の作業。
This section will list many of the traditional protocol-based attacks that have been observed over the years to cause malformed packets and/or exploit protocol deficiencies. Note that they all exploit vulnerabilities in the actual protocol itself and often, additional authentication and auditing mechanisms are now used to detect and mitigate the impact of these attacks. The list is not exhaustive, but is a fraction of the representation of what types of attacks are possible for varying protocols.
このセクションでは、奇形のパケットやエクスプロイトプロトコルの欠陥を引き起こすために長年にわたって観察されてきた従来のプロトコルベースの攻撃の多くをリストします。これらはすべて、実際のプロトコル自体の脆弱性を活用しており、多くの場合、これらの攻撃の影響を検出および軽減するために、追加の認証と監査メカニズムが使用されることに注意してください。このリストは網羅的ではありませんが、さまざまなプロトコルで可能な攻撃の種類の表現のほんの一部です。
o ARP Flooding
o ARP洪水
o IP Addresses, either source or destination, can be spoofed which in turn can circumvent established filtering rules.
o ソースまたは宛先のいずれかのIPアドレスをスプーフィングできます。これにより、確立されたフィルタリングルールを回避できます。
o IP Source Route Option can allows attackers to establish stealth TCP connections.
o IPソースルートオプションにより、攻撃者はステルスTCP接続を確立できます。
o IP Record Route Option can disclose information about the topology of the network.
o IPレコードルートオプションは、ネットワークのトポロジに関する情報を開示できます。
o IP header that is too long or too short can cause DoS attacks to devices.
o 長すぎるまたは短すぎるIPヘッダーは、デバイスに対してDOS攻撃を引き起こす可能性があります。
o IP Timestamp Option can leak information that can be used to discern network behavior.
o IPタイムスタンプオプションは、ネットワークの動作を識別するために使用できる情報をリークできます。
o Fragmentation attacks which can vary widely - more detailed information can be found at http://www-src.lip6.fr/homepages/ Fabrice.Legond-Aubry/www.ouah.org/fragma.html.
o 広く異なる可能性のある断片化攻撃 - より詳細な情報は、http：//www-src.lip6.fr/homepages/ fabrice.legond-aubry/www.ouah.org/fragma.htmlにあります。
o IP ToS field (or the Differentiated Services (DSCP) field) can be used to reroute or reclassify traffic based on specified precedence.
o IP TOSフィールド（または差別化されたサービス（DSCP）フィールド）を使用して、指定された優先順位に基づいてトラフィックを再表示または再分類できます。
o IP checksum field has been used for scanning purposes, for example when some firewalls did not check the checksum and allowed an attacker to differentiate when the response came from an end-system, and when from a firewall.
o IPチェックサムフィールドは、たとえば、一部のファイアウォールがチェックサムをチェックせず、応答が最終システムから来たとき、およびファイアウォールから攻撃者に区別できるようにした場合、スキャン目的で使用されています。
o IP TTL field can be used to bypass certain network-based intrusion detection systems and to map network behavior.
o IP TTLフィールドを使用して、特定のネットワークベースの侵入検知システムをバイパスし、ネットワークの動作をマッピングできます。
The following lists additional attacks, but does not explicitly numerate them in detail. It is for informational purposes only.
以下には追加の攻撃が記載されていますが、それらを明示的に詳細に数値にしていません。それは情報提供のみを目的としています。
o IGMP oversized packet
o IGMP特大のパケット
o ICMP Source Quench
o ICMPソースクエンチ
o ICMP Mask Request
o ICMPマスクリクエスト
o ICMP Large Packet (> 1472)
o ICMPラージパケット（> 1472）
o ICMP Oversized packet (>65536)
o ICMP特大パケット（> 65536）
o ICMP Flood
o ICMP洪水
o ICMP Broadcast w/ Spoofed Source (Smurf Attack)
o スプーフィングされたソース付きICMPブロードキャスト（スマーフ攻撃）
o ICMP Error Packet Flood
o ICMPエラーパケットフラッド
o ICMP Spoofed Unreachable
o ICMPスプーフィングされていない
o TCP Packet without Flag
o フラグのないTCPパケット
o TCP Oversized Packet
o TCP特大のパケット
o TCP FIN bit with no ACK bit
o ACKビットがないTCPフィンビット
o TCP Packet with URG/OOB flag (Nuke Attack)
o urg/oobフラグを備えたTCPパケット（Nuke Attack）
o SYN Fragments
o synフラグメント
o SYN Flood
o syn洪水
o SYN with IP Spoofing (Land Attack)
o IPスプーフィング（土地攻撃）とのSyn
o SYN and FIN bits set
o
o TCP port scan attack
o TCPポートスキャン攻撃
o UDP spoofed broadcast echo (Fraggle Attack)
o UDPスプーフィングされたブロードキャストエコー（フラググル攻撃）
o UDP attack on diagnostic ports (Pepsi Attack)
o 診断ポートに対するUDP攻撃（ペプシ攻撃）
Any of the above-mentioned IPv4 attacks could be used in IPv6 networks with the exception of any fragmentation and broadcast traffic, which operate differently in IPv6. Note that all of these attacks are based on either spoofing or misusing any part of the protocol field(s).
上記のIPv4攻撃のいずれかは、IPv6では断片化と放送トラフィックを除き、IPv6ネットワークで使用できます。これらの攻撃はすべて、プロトコルフィールドの任意の部分のスプーフィングまたは誤用に基づいていることに注意してください。
Today, IPv6-enabled hosts are starting to be used to create IPv6 tunnels, which can effectively hide botnet and other malicious traffic if firewalls and network flow collection tools are not capable of detecting this traffic. The security measures used for protecting IPv6 infrastructures should be the same as in IPv4 networks, but with additional considerations for IPv6 network operations, which may be different from IPv4.
今日、IPv6対応のホストを使用してIPv6トンネルの作成を開始しています。これは、ファイアウォールやネットワークフローコレクションツールがこのトラフィックを検出できない場合、ボットネットやその他の悪意のあるトラフィックを効果的に非表示にすることができます。IPv6インフラストラクチャの保護に使用されるセキュリティ対策は、IPv4ネットワークと同じである必要がありますが、IPv4ネットワーク操作については追加の考慮事項があります。これはIPv4とは異なる場合があります。
Author's Address
著者の連絡先
Merike Kaeo Double Shot Security, Inc. 3518 Fremont Avenue North #363 Seattle, WA 98103 U.S.A.
Merige Kaeo Double Shot Security、Inc。3518 Fremont Avenue North＃363 Seattle、WA 98103 U.S.A.
Phone: +1 310 866 0165
EMail: merike@doubleshotsecurity.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。