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）IETFトラスト（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.
man-in-the-middle：挿入、変更、または特定のトラフィックをドロップしながら、悪意のあるユーザが通信ストリームの送信者または受信者のいずれかを偽装攻撃。この種の攻撃はまた、フィッシングやセッションハイジャックをカバーしています。
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.
メッセージ挿入：これは、有効なメッセージであることができる（それがメッセージを捕捉し、後で再送されるシナリオであるリプライ攻撃することができます）。メッセージはまた、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.
メッセージ変更：これは、前のメッセージが再送信される前にキャプチャされ、変更されたメッセージ挿入攻撃のサブセットです。メッセージは、man-in-the-middle攻撃またはメッセージの宛先を使用して捕捉することができます。
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].
積極的な攻撃は、ネットワークへのデータの書き込みを必要とします。これは、1つのアドレスを偽装して、トラフィックの送信者の身元を隠すために積極的な攻撃で一般的に行われています。受動的攻撃のみをネットワークから情報を読み取る必要とします。攻撃者は、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.
別のホストから送信されるデータグラムのためには、一般に中間リンクとルータのいくつかのセットを横断しなければなりません。そのようなルータは、当然、その経路に沿って送信されたデータグラムを読み取り、変更、または削除することができます。これは、あなたが上でパスされている場合、それははるかに簡単に攻撃の多種多様をマウントすることができます。オフパスホストは、任意のホストから来るように見えるが、必ずしも他のホストのために意図されたデータグラムを受信することができない任意のデータグラムを送信することができます。攻撃は、データを受信することができることに依存している場合このように、オフパスホストは最初にパス自身を配置するためにトポロジを破壊しなければなりません。このことは、不可能でないことは、必ずしも自明で[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.
攻撃元は、任意の攻撃は、ネットワークの可用性と信頼性に持つことができる影響を把握しようとするときに考慮する必要があるすべては、上記のいずれかの組み合わせとすることができます。インサイダー攻撃や意図的でないイベントを停止することはほぼ不可能です。適切な監視機構が整備されている場合は、これらの攻撃も検出され、他の攻撃元と同じように緩和することができます。それは攻撃を識別し、追跡するのにかかる労力の量は、当然のことながら、攻撃者の機知に依存しています。本書で詳しく説明特定の攻撃のいずれかが「部外者」によってソースと意図的な攻撃されている、悪意のある動作について詳しく説明します。いくつかのさらなる詳細は、特定のセキュリティ機能を展開背後にある動機を表示するには、アクティブ対とのパスオフパス攻撃VSパッシブの実現可能性について説明します。
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]で見つけることができます。一般的に、異なるネットワーク攻撃の数は、上述した脅威の結果の一つ以上を引き起こすために組み合わせて使用されています。例では、トラフィックを盗聴する能力を持っている悪意のあるユーザーになります。まず、彼はIPアドレスが、ルータなどの特定のデバイスに属し偵察仕事と把握をして、しばらくの間、交通上で聴取することができます。そのようなクリアテキストで送信されたルーターのパスワードなどの情報を入手するには、この悪党だった、彼はその後、実際のルータを妥協に進むことができます。そこから、悪党は、このようなトラフィックをリダイレクトまたは他のネットワークデバイスを妥協する追加のトラフィックをキャプチャするために偽のルーティングアップデートの送信など、さまざまな能動的な攻撃を起動することができます。この文書は、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 Access Control
Oアクセス制御
o Data Integrity
データのインテグリティ
o Data Confidentiality
Oデータの機密性
o Auditing/Logging
監査/記録
o DoS Mitigation
Oドスmitigatin
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.
多くの場合、現在展開特定のプロトコルは、これらのサービスの組み合わせを提供します。セキュアシェル（SSH）プロトコルは、データ発信元認証、データの整合性、およびデータの機密性を提供することが可能である。例えば、認証、認可、アカウンティング（AAA）は、ユーザー認証、ユーザー認証、および監査/ロギングサービスを提供することができます提供されるサービスは、使用される実際のプロトコルよりも重要です。アクセス制御は、論理アクセス制御、すなわち、フィルタリングに基本的に参照することに留意されたいです。各セクションには、特定のプロトコルを用いても用いなくてもよい理由を説明する追加の考慮事項のセクションを終了し、また、原因のバグや使いやすさの不足のために、今日は不可能ないくつかの情報に関する機能を、提供します。
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).
物理デバイスのセキュリティを確保するために、設備は非常に制限された環境に保たれています。カードキーバッジで許可されたユーザーのみが重要なネットワークインフラストラクチャデバイスが含まれている物理的な場所のいずれかへのアクセス権を持っています。これらのカードキーシステムでは、どの場所、どのような時にアクセス者を追跡します。カードシステムがダウンしている場合にはほとんどのカードキーシステムはフェイルバックを「マスターキー」を持っています。 （カードキーシステムが機能/オンラインでない場合にのみ起こるべきである）この「マスターキー」は、通常アクセスが制限されており、その使用にも慎重に記録されます。
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の認証ステップを実行する必要があります。他のベンダーでは、あなたが第二認証ステップを必要とせずに、rootとしてコンソールにログインし、より特権アクセスを取得します。
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の多くは、特権レベルの認可を自動化し、第二認証ステップの必要性を回避するために自動化を利用する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 Data Origin Authentication - Not applicable.
データ発信元認証 - 適用されません。
o Access Control - Not applicable.
Oアクセス制御 - 適用されません。
o Data Integrity - Not applicable.
データのインテグリティ - 適用されません。
o Data Confidentiality - Not applicable.
データの秘匿性 - 適用されません。
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).
監査/記録 - インフラ機器の物理的な位置へのすべてのアクセスは、電子カードキーシステムを経由して記録されます。すべてのコンソールアクセスは（詳細については、このドキュメントのセクション2.2を参照してください）記録されます。
o DoS Mitigation - Not applicable.
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.
悪人が平文でまたは弱い暗号化で送信されたすべての管理データを傍受する際に守秘義務違反が発生する可能性があります。これは、侵入者がネットワークデバイスへの不正アクセスを得ることが可能なユーザ名とパスワードの傍受が含まれています。管理者がリモートからローカルのログファイルや設定情報を閲覧している場合にも、そのようなログや設定情報などの情報を含めることができます。
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.
リプレイ攻撃を成功させるために、管理トラフィックは、1枚目の撮影のいずれかにパス以降の目的の受信者に再生されるように、攻撃者に流用される必要があろう。
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.
man-in-the-middle攻撃は、通信相手の身元ではなく、データストリーム自体を攻撃します。攻撃者が管理システムにネットワークインフラストラクチャデバイスから送信されたネットワークインフラストラクチャデバイスとトラフィックを管理システムから送信されたトラフィックをインターセプト。
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アクセスは、デバイスとのセッションが開始されているところから、ターミナルサーバに到達するために使用されます。ネットワークが利用できない場合、ダイヤルインアクセスは、バックアップとして展開されています。しかし、それはモデムを暗号化、ダイヤルバックを使用するのが一般的である、および/またはワンタイムパスワード（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などのワンタイムユーザ名/パスワードのスキームに静的なユーザー名/パスワードによって異なります。静的なユーザー名/パスワードは、特定の期間、通常は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.
バックアップの目的のために、キーパーソンの非常に限られたセットにはよく知られている認証のための単一のローカルデータベースエントリがあることが多いです。これは通常、ほとんどの場合、すべてのデバイスで同じである最高の特権レベルのユーザ名/パスワードの組み合わせ、です。このローカルデバイスのパスワードを定期的に一度2〜3ヶ月ごとに再生成され、また、そのパスワードへのアクセスを持っていた従業員が会社を辞めていないか、もはやそのパスワードの知識を持っていることを許可された直後に再生されます。
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スクリプトを実行するスクリプトでのアイデンティティのために使用されています。認証されると、コマンドはこれらのスクリプト制御は、認証された個々の許可権限に応じて、合法的です。
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コミュニティ文字列をサポートしている場合、古い文字列が第一、第二、新しいコミュニティストリングを設定して、新規の方に現在使用された文字列からオーバー移行によって置き換えられます。ほとんどの大規模ISPは、それはすべての権利のシステムで修正されたすべての文字列を取得するには1つのメンテナンス期間、より多くかかりますので、そのルータにアクセスする複数のSNMPシステムを持っています。 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サーバは、認証されたエンティティのトラックだけでなく、特定のデバイス上で行われたすべてのコマンドをキープ。また、デバイス自体は、SSH要求が明示的に許可されていないIPアドレスから来る場合、すなわち、そのイベントは、問題のある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.
ユーザ認可 - すべての個人は、一度認証に成功特定の操作を実行するために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.
データ発信元認証 - 管理トラフィックは、厳密に、インフラストラクチャデバイスへのアクセスを持っている特定のIPアドレスのみを許可するようにフィルタリングされます。これは、スプーフィングされたトラフィックのリスク、（セクション2.5で論じ）BCP38 [RFC2827]とBCP84 [RFC3704]のガイドラインを使用して、エッジ・フィルタリングと組み合わされた場合も、その後、なりすましの危険性が損なわ内部システムがなければ、緩和さを軽減しません。また、デバイスアクセスのための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.
データの秘匿性は - 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.
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リキーイベントを必要とします。ルートプロセッサカードが交換される必要があるときはいつでも、また、SSHキーがルートプロセッサカードに格納されている場合には、SSHの再入力が必要とされるであろう。一部のプロバイダは、この操作の影響は、必要なセキュリティを超えていることを感じて、代わりにそれらのデバイスを管理するために（「jumphosts」または「要塞ホスト」と呼ばれる）のホスト内で、信頼できるからTelnetを使用します。個体は、任意のパスワードがjumphostとそれが接続されたデバイスとの間で平文で送信されることを十分に理解実際のインフラストラクチャデバイスへjumphostから最初jumphostにSSHおよびTelnet、あろう。すべての認証および承認はまだ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サーバ上のログはより冗長であり、より多くの注意が異常動作を検出するためにそれらに支払われます。 jumphosts自体は慎重にマシンを制御され、通常のアクセスが制限されています。 Telnetが特定jumphostsから除き、インフラストラクチャデバイスに許可されないことに注意してください。すなわち、パケットフィルタは、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を使用してKerberos対応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をサポートしています。 V3よりセットアップが容易であるため、SNMPv2のは、主に展開されています。
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]のガイドラインに従ってください。 BCP84がマルチホーム環境のための推薦を延びているBCP38は、サービス拒否攻撃の影響を制限するために明らかに偽装および/または「予約済み」の送信元アドレスを持つフィルタリング入力パケットをお勧めします。フィルタはまた、サービスプロバイダ間の問題を軽減するために使用されています。任意のフィルタリングなしで、相互交換ピアは単に静的ルートを使用して輸送を盗み、本質的にデータトラフィックをリダイレクトすることができました。そのため、一部のISPは、上記の文書で定義されていない、予期せぬ送信元と送信先アドレスをブロック入力/出力フィルタを実装しています。ヌル経路とブラックホールは、任意の検出された悪意のあるトラフィックストリームを阻止するために使用されるルーティング[RFC3882]をトリガー。これら二つの技術は、以下の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（RPF）は一貫して実装されていません。他のISPは偽装されたトラフィックが正当なアドレスから来ていることを知っているの知覚利益は、操作の複雑さの価値はないと思いながら、いくつかのISPは、そうすることの過程にあります。一部のプロバイダは、ネットワーク内のすべてのハードウェアは、以下のDS3速度とのためのuRPFをサポートするという事実によるものだった以下のデジタル信号3（DS3）と、のリンク速度でのuRPFを実装する方針を持っています。高速リンクでは、uRPFのサポートは、矛盾していましたし、運用人々が一貫したソリューションを実装するのは簡単でした。
o User Authentication - Not applicable.
Oユーザ認証 - 適用されません。
o User Authorization - Not applicable.
ユーザ認可 - 適用されません。
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.
データ発信元認証 - 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 Data Confidentiality - Not applicable.
データの秘匿性 - 適用されません。
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.
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.
特にパフォーマンスの問題に関して、フィルタリングする機能について、一貫性の欠如は、イングレスフィルタリングのためのBCP38とBCP84ガイドラインを実装することなく、いくつかのISPを引き起こします。その一例は、1000までのT1は、OC-12（光キャリア）アップリンクでルータに接続するエッジボックス、です。いくつかの展開デバイスは、イングレスフィルタリング（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.
オフパスアクティブな攻撃に関しては、攻撃は一般的にその目的の宛先に到達しないようにトラフィックを引き起こし、違法な目的地へのトラフィックをそらすことができ、メッセージの挿入または変更、に限定されています。
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がプライベートと独自の情報としてアドレス指定方式とネットワークトポロジを分類しているので、これは懸念のよりになってきています。ルーティングプロトコルパケットをルーティングセッションが偽装されたりハイジャックすることできる方法を示してもよい情報が含まれているので、それも懸念されます。これは、順番に悪党は、トラフィックパスに自分自身を挿入したり、トラフィックパスをそらすと、ユーザデータの機密性に違反する可能性がman-in-the-middle攻撃、につながる可能性があります。
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.
man-in-the-middle攻撃は、通信相手の身元ではなく、データストリーム自体を攻撃します。攻撃者は、他の1つのルーティング・ピアから送信され、ピアの1つに代わって通信されるトラフィックを傍受します。これは、どちらかの不正な受信者へのユーザートラフィックの転換につながるか、その意図した目的地に到達することはありませんする正当なトラフィックを引き起こす可能性があります。
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機能は、そのようなボーダーゲートウェイプロトコル（BGP）などのプロトコルを使用し、通信を行うピアを保護するために、ライブへのパケットのTimeの使用（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は、へ/仲間と上流ネイバーからAS-PATHフィルタを自分のエンドサイト顧客をフィルタリングプレフィックスが、大きいため、プレフィックスフィルタリストを維持するための運用制約のために、多くの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の中の個々の実装では、ユニークであり、機器供給（S）に応じて、さまざまな実装オプションが用意されています。ほとんどの機器ベンダーは、単に、セッションを自動的にシャットダウンするために受信されている過度のプレフィックスをログに至るまで実装オプションを提供します。いくつかの事前に設定アイドルタイムアウトに達した後、セッションを再確立するのオプションが利用可能である場合、隣接する隣接のポリシー設定ミスがある場合、自動的にセッションを再確立することは、潜在的に全体ルーティングテーブルに連続的不安定性を導入してもよいことが理解されるべきです条件を引き起こして。ピアリング隣人に深刻な設定ミスが発生した場合は、自動的にセッションをシャットダウンし、それが手動でクリアされるまでシャットダウンしたまま、時には最高で、必要に応じて修正するために、オペレータの介入が可能になります。
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は、ルートが次にルーティング資産データベース（RADB）の一部とすることができるインターネットルーティングレジストリ（IRR）に登録されることを必要と。特にヨーロッパでは一部の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 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.
データ発信元認証 - 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 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.
MD5認証、GTSMの機能、bogonsへのルーティング広告をフィルタリングし、フィルタリングを自分のネットワークに広告をルーティング： - DoS軽減多くのDoS攻撃を含めた技術の組み合わせを使用して軽減されています。
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の間で展開されていません。二つの主要な展開の懸念は、両方のソフトウェアのバグと優雅な再入力オプションの欠如は時間を大幅にネットワークをダウン引き起こしている実装上の問題、となっています。また、いくつかのISPは、MD5認証を展開すること自体は悪いことDoS攻撃の被害者になることを懸念を表明し、他の、そのような（BGP用）GTSMとしてリスク軽減メカニズムとルートフィルタの組み合わせを使用することを好みます。 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.
ソフトウェアアップデートは、ソフトウェアアップデートおよび/またはコンフィギュレーション情報を担当してISPのネットワーク管理システムにベンダーのサイトからダウンロードされた場合、同様の問題が関連していることに注意してください。
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.
リプレイ攻撃を成功させるために、ソフトウェアイメージまたはコンフィギュレーションファイルは、1枚目の撮影のいずれかにパス以降の目的の受信者に再生されるように、攻撃者に流用される必要があろう。多くのプロトコルは、リプレイ保護機能を持っているので、さらに、これらは該当する状況でも同様に覆さなければならないであろう。
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.
man-in-the-middle攻撃は、通信相手の身元ではなく、データストリーム自体を攻撃します。インフラストラクチャデバイスとホスト間で送信される攻撃をインターセプト・トラフィックは、システムイメージまたはコンフィギュレーションファイルをダウンロード/アップロードするために使用されます。彼/彼女は、1つまたはこれらのシステムの両方を代表して行動することができます。
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管理シナリオでは、使用されています。いくつかのカスタム書かれたTFTPサーバがMACベースの認証をサポートする一方、一部のISPは、TFTPサーバにIPベースの制限を実装します。リモートからルータをブートストラップするために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.
ほとんどの環境では、スクリプトは、ルータの多数のイメージや設定を維持するために使用されています。構成の整合性を確保するために、時間ごとの設定ファイルは、ポーリングや矛盾を見つけるために、以前にポーリングされたバージョンと比較されます。少なくとも一つの環境これらでは、ツールは、自動化された認証（ない機密性）を活用するためにKerberos対応されています。 「ランシド」は設定とシステムの変更を検出するための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認証の共有秘密、AAAサーバの共有秘密のパスワードが含まれ、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 Data Origin Authentication - Filters are used to limit access to uploading/downloading configuration files and system images to specific IP addresses.
データ発信元認証 - フィルタは、特定の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.
データのインテグリティ - すべてのシステムは、データの整合性を確保するために、CRCチェックやMD5認証のいずれかを使用します。また、このような悪臭などのツールが自動的に構成変更を検出するために使用されています。
o Data Confidentiality - If the SCP protocol is used then there is confidentiality of the downloaded/uploaded configuration files and system images.
データの秘匿性 - 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.
監査/記録 - ダウンロード/アップロードシステムイメージおよびコンフィギュレーションファイルに関連するすべてのアクセス及び活動は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.
DoS軽減 - フィルタリングとCRCチェックの組み合わせが/ 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.
リプレイ攻撃を成功させるために、ログデータは、1枚目の撮影のいずれかに、パスまたは攻撃者に転用し、後で受信者に再生される必要があろう。
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アドレスのいずれかからのパケットを鍛造により注入することができます。
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.
man-in-the-middle攻撃は、通信相手の身元ではなく、データストリーム自体を攻撃します。攻撃者は、インフラストラクチャデバイスとロギングサーバと記録されたデータをアーカイブするために使用されているデータベースとの間で送信されるロギングサーバやトラフィックの間で送信されるトラフィックを傍受します。ログ情報への不正アクセスは、ネットワークの部分を妥協するために使用することができ、プライベートと独自のネットワークトポロジ情報の知識、につながる可能性があります。追加の懸念はセキュリティ侵害の痕跡を覆うように、削除または変更することができ、ログ情報へのアクセスを持っています。
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サーバとデバイス間で実行はセキュリティが事実上存在しないので、多くのISPは、syslogデータを転送するためにOOB管理ネットワークを使用します。すべての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.
タイムスタンプは、一般的に以下の構成と少ないメンテナンスを持つ階層とstratum2におけるフラット階層として構成されているNTP、から誘導されます。構成や冗長性の一貫性が第一の目標です。各ルータであってもネットワークの停止を変化させた場合には、適切なNTP時間が利用可能であることを確実にするために選択されているいくつかの階層サーバー源、で構成されています。
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分ごとから毎時間にすることができ、設定された間隔でデータベースに転送されます。一つのISPは、データベースにデータをプッシュするのRsyncを使用し、その情報をそのデータベースにSSH'ing誰かによって手動でソートされます。
o User Authentication - Not applicable.
Oユーザ認証 - 適用されません。
o User Authorization - Not applicable.
ユーザ認可 - 適用されません。
o Data Origin Authentication - Not implemented.
データ発信元認証 - 実装されていません。
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 Data Confidentiality - Not implemented.
データの秘匿性 - 実装されていません。
o Auditing/Logging - This entire section deals with logging.
監査/記録 - ログとこのセクション全体を扱います。
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.
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).
ルーティングフィルタは、ルーティング情報の流れを制御するために使用されています。他の人が/ 32で典型的に割り当て境界におけるフィルタながらIPv6ネットワークでは、いくつかのプロバイダは、依然として未解決のマルチホーミングの問題に起因/ 48Sを受け付けるにリベラルです。任意の発表は、長いIPv6ルーティング/ 48以上であり、IPv4ルーティングのために/ 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ルーティングプロトコルが順番にそれが効果的にドロップされヌルインタフェースに攻撃トラフィックをリダイレクトルートを伝播するために使用される技術です。 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.
ユニキャストRPF（uRPFの）は、着信パケットが正当なソースアドレスを有するか否かを検証するための機構です。 strictモードとlooseモード：これは、2つのモードがあります。厳密モードでは、uRPFの着信パケットは、ルーティングテーブル内のプレフィクスと一致するソースアドレスを有するかどうかをチェックし、インターフェイスは、この送信元アドレスのプレフィックスを持つパケットを受信することを期待するかどうか。着信パケットがユニキャスト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トラフィックに割り当てられますTCP-SYN攻撃、などのよく知られたプロトコルの攻撃を軽減するために使用されます。この技術は攻撃を停止しませんが、それは時々、特定のサービスへの被害や影響を軽減することができます。しかし、それはまた、速度制限が影響を与えている場合（すなわち、廃棄）はるかに悪い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.
このドキュメントのためのガイダンスと方向性を提供してきましたジョージ・ジョーンズ、とロスCallon、ロンBonica、ライアン・マクダウェル、Gaurab Upadhaya、ウォーレン・クマリ、ペッカSavola、フェルナンドGontからの洞察に満ちたコメント：エディタは感謝の貢献を認めてクリス・モロー、テッド・シーリー、ドナルド・スミス、そして本書に描かれている情報を提供し、多くの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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 3682、2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
、RFC 3882、2004年9月 "ブロックサービス拒否攻撃へのBGPの設定" [RFC3882]トルコ人、D.、。
[BCP84-URPF] Savola, P., "Experiences from Using Unicast RPF", Work in Progress, November 2006.
[BCP84-URPF] Savola、P.、 "ユニキャストRPFを使用してからの経験"、進歩、2006年11月に作業。
[ICMPv6] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", Work in Progress, July 2006.
[ICMPv6の]デイヴィス、E.およびJ. Mohacsi、 "ファイアウォールでのフィルタリングICMPv6メッセージへの提言"、進歩、2006年7月での作業。
[RTGWG] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, July 2006.
[RTGWG] Savola、P.、 "バックボーンインフラストラクチャ攻撃と保護"、進歩、2006年7月での作業。
Appendix A. Protocol Specific Attacks
付録A.プロトコル特定の攻撃
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.
このセクションでは、不正なパケットを引き起こし、および/またはプロトコルの欠陥を悪用するために長年にわたって観察されている伝統的なプロトコルベースの攻撃の多くが一覧表示されます。それらはすべて、実際のプロトコル自体の脆弱性を悪用すると、多くの場合、追加の認証および監査メカニズムは今やこれらの攻撃の影響を検出し軽減するために使用されることに留意されたいです。リストは網羅的ではなく、プロトコルを変化させることも可能です攻撃の種類の表現の一部です。
A.1. Layer 2 Attacks
A.1。レイヤ2回の攻撃
o ARP Flooding
ARPフラッディングO
A.2. IPv4 Protocol-Based Attacks
A.2。 IPv4のプロトコルベースの攻撃
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-オーブリー/ 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フィールドは、特定のネットワークベースの侵入検知システムを迂回して、ネットワークの動作をマッピングするために使用することができます。
A.2.1. Higher Layer Protocol Attacks
A.2.1。上位層プロトコル攻撃
The following lists additional attacks, but does not explicitly numerate them in detail. It is for informational purposes only.
次のリストの追加攻撃が、明示的にそれらを詳細に数に入れることはありません。これは、情報提供のみを目的としています。
o IGMP oversized packet
IGMPパケット特大O
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
ICMPフラッドO
o ICMP Broadcast w/ Spoofed Source (Smurf Attack)
O ICMPブロードキャストワット/スプーフィングされたソース（スマーフ攻撃）
o ICMP Error Packet Flood
ICMPエラーパケット洪水O
o ICMP Spoofed Unreachable
ICMP到達不能なりすましO
o TCP Packet without Flag
旗のないTCPパケットO
o TCP Oversized Packet
TCP特大パケットO
o TCP FIN bit with no ACK bit
無ACKビットとO TCP FINビット
o TCP Packet with URG/OOB flag (Nuke Attack)
URG / OOBフラグをTCPパケット（ヌケアタック）O
o SYN Fragments
O SYNフラグメント
o SYN Flood
O SYNフラッド
o SYN with IP Spoofing (Land Attack)
IPスプーフィングとSYN（土地・アタック）O
o SYN and FIN bits set
O SYNとFINビットが設定します
o TCP port scan attack
O TCPポートスキャン攻撃
o UDP spoofed broadcast echo (Fraggle Attack)
O UDPは、偽装されたブロードキャストエコー（Fraggleアタック）
o UDP attack on diagnostic ports (Pepsi Attack)
O診断ポート上のUDP攻撃（ペプシ・アタック）
A.3. IPv6 Attacks
A.3。 IPv6の攻撃
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から異なっていてもよく、IPv6ネットワークの運用のための追加の考慮事項を有するべきです。
Author's Address
著者のアドレス
Merike Kaeo Double Shot Security, Inc. 3518 Fremont Avenue North #363 Seattle, WA 98103 U.S.A.
Merike Kaeoのダブルショット・セキュリティ株式会社3518フリーモントアベニューノース第363位シアトル、WA 98103 U.S.A.
Phone: +1 310 866 0165 EMail: merike@doubleshotsecurity.com
電話：+1 310 866 0165 Eメール：merike@doubleshotsecurity.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。