RFC4778 日本語訳
4778 Operational Security Current Practices in Internet ServiceProvider Environments. M. Kaeo. January 2007. (Format: TXT=88344 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Kaeo Request for Comments: 4778 Double Shot Security, Inc. Category: Informational January 2007
Kaeoがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4778年の二重ショットセキュリティInc.カテゴリ: 情報の2007年1月
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).
IETFが信じる著作権(C)(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操作上のネットワークに使用される現在の実務の調査です。 ここにリストアップされた情報は直接インターネットサービスプロバイダ環境における安全なインフラストラクチャを定義して、実装するのに責任がある人々から集められた情報の結果です。
Kaeo Informational [Page 1] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[1ページ]のRFC4778OPSECは2007年1月に練習します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2。 脅威モデル. . . . . . . . . . . . . . . . . . . . . . . 3 1.3。 ソース. . . . . . . . . . . . . . . . . . . . . . 4 1.4を攻撃してください。 操作上のセキュリティに脅威. . . . . . . . . 5 1.5から影響を与えます。 レイアウト. . . . . . . . . . . . . . . . . . . . . 7 2を記録してください。 操作上の機能. . . . . . . . . . . . . . . 8 2.1を保護しました。 デバイスの物理的なアクセス. . . . . . . . . . . . . . . . . . 8 2.2。 バンドにおけるデバイス管理とバンドで出かけている(OOB。). . . . 10 2.3 データ経路. . . . . . . . . . . . . . . . . . . . . . . . 16 2.4。 制御飛行機. . . . . . . . . . . . . . . . . . 18 2.5を発送します。 ソフトウェアの更新と構成保全/合法化. . . . . . . . . . . . . . . . . . . 22 2.6。 問題. . . . . . . . . . . . . . . . . . 26 2.7を登録します。 問題. . . . . . . . . . . . . . . . . 29 2.8をフィルターにかけます。 サービス妨害の追跡/たど. . . . . . . . . . . . 30 3ること。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 32 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 32 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1。 引用規格. . . . . . . . . . . . . . . . . . . 33 5.2。 情報の参照. . . . . . . . . . . . . . . . . 33付録A.は特定の攻撃. . . . . . . . . . . . . . 34について議定書の中で述べます。A.1。 層2は.34A.2を攻撃します。 IPv4のプロトコルベースの攻撃. . . . . . . . . . . . . . . 34A.3。 IPv6攻撃. . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
1. 序論
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はあるセキュリティ実践がそれらのネットワークが彼らの顧客に操作上利用可能であることを保証するために続かれているのを保証しなければなりません。 このドキュメントはどんな現在のセキュリティ実践がネットワークインフラを保証するために配布されているかを見つけるために指導された調査の結果です。
1.1. Scope
1.1. 範囲
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
この調査のための範囲はネットワークの有用性と信頼性に逆に影響を与える可能性で暴露をリスクに緩和するセキュリティ実践に制限されます。 行われた調査の範囲の外に実際のデータがトラフィックであると機密保護するのがあります。 このドキュメント
Kaeo Informational [Page 2] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[2ページ]のRFC4778OPSECは2007年1月に練習します。
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ネットワークに(and should)は適用できますか? IPv4とIPv6ネットワークインフラの両方がこの調査で考慮に入れられます。
1.2. Threat Model
1.2. 脅威モデル
A threat is a potential for a security violation, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm [RFC2828]. Every operational network is subject to a multitude of threat actions, or attacks, i.e., an assault on system security that derives from an intelligent act that is a deliberate attempt to evade security services, and violate the security policy of a system [RFC2828]. Many of the threats to a network infrastructure occur from an instantiation (or combination) of the following:
脅威は安全の侵害の可能性です。(セキュリティと原因害[RFC2828]を破ることができた状況、能力、動作、またはイベントがあるとき、それは、存在します)。 脅威動作、または攻撃の多数において、あらゆる操作上のネットワークが受けることがある、すなわち、知的な行為からそれを引き出すシステムセキュリティに対する襲撃はセキュリティー・サービスを回避して、システムの安全保障政策に違反する慎重な試みです[RFC2828]。 ネットワークインフラへの脅威の多くが以下の具体化(または、組み合わせ)から起こります:
Reconnaissance: An attack whereby information is gathered to ascertain the network topology or specific device information, which can be further used to exploit known vulnerabilities
偵察: 情報がネットワーク形態を確かめるために集められる攻撃か特定のデバイス情報。(さらに、知られている脆弱性を利用するのにその情報を使用できます)。
Man-In-The-Middle: An attack where a malicious user impersonates either the sender or recipient of a communication stream while inserting, modifying, or dropping certain traffic. This type of attack also covers phishing and session hijacks.
マン・イン・ザ・ミドル: 悪意あるユーザーが、あるトラフィックを挿入するか、変更するか、または下げている間にコミュニケーションストリームの送付者か受取人をまねる攻撃。 また、このタイプの攻撃はフィッシング詐欺とセッションハイジャックを含んでいます。
Protocol Vulnerability Exploitation: An attack that takes advantage of known protocol vulnerabilities due to design or implementation flaws to cause inappropriate behavior.
脆弱性攻略について議定書の中で述べてください: デザインか実装のため知られているプロトコル脆弱性を利用する攻撃は不適当な振舞いを原因に失敗させます。
Message Insertion: This can be a valid message (it could be a reply attack, which is a scenario where a message is captured and resent at a later time). A message can also be inserted with any of the fields in the message being spoofed, such as IP addresses, port numbers, header fields, or even packet content. Flooding is also part of this threat instantiation.
メッセージ挿入: これは有効なメッセージであるかもしれません(それは回答攻撃であるかもしれません)。(攻撃はメッセージが後でキャプチャされて、再送されるシナリオです)。 また、メッセージの分野のどれかが偽造されている状態で、メッセージを挿入できます、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.
メッセージ変更: これは再送される前に、前のメッセージが得られて、変更されたメッセージ挿入攻撃の部分集合です。 介入者攻撃を使用するか、メッセージ転換であることをメッセージを得ることができます。
Kaeo Informational [Page 3] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[3ページ]のRFC4778OPSECは2007年1月に練習します。
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.
時々、サービス不能攻撃が別々のカテゴリとして記載されていることに注意してください。 サービスの否定は、攻撃の結果であり、あまりに多くのトラフィック(すなわち、氾濫)の結果であるかもしれません、メッセージをプロトコル攻略を利用するか、挿入するか、削除する、紛らす、または変更して。
1.3. Attack Sources
1.3. 攻撃ソース
These attacks can be sourced in a variety of ways:
さまざまな方法でこれらの攻撃の出典を明示されることができます:
Active vs Passive Attacks
受け身の攻撃に対してアクティブです。
An active attack involves writing data to the network. It is
common practice in active attacks to disguise one's address and
conceal the identity of the traffic sender. A passive attack
involves only reading information off the network. This is
possible if the attacker has control of a host in the
communications path between two victim machines, or has
compromised the routing infrastructure to specifically arrange
that traffic pass through a compromised machine. There are also
situations where mirrored traffic (often used for debugging,
performance monitoring, or accounting purposes) is diverted to a
compromised machine, which would not necessarily subvert any
existing topology, and could be harder to detect. In general, the
goal of a passive attack is to obtain information that the sender
and receiver would prefer to remain private [RFC3552].
活発な攻撃は、ネットワークにデータを書くことを伴います。 活発な攻撃では、人のアドレスを変装して、トラフィック送付者のアイデンティティを隠すのは、一般的な習慣です。 受け身の攻撃は、ネットワークから情報を読むだけであることを伴います。 攻撃者が2つの犠牲マシンの間のコミュニケーション経路でホストを管理するか、または明確にアレンジするトラフィックが感染しているマシンで通過するルーティングインフラストラクチャに感染したなら、これは可能です。 状況も映されたトラフィック(デバッグ、性能モニター、または会計にしばしば目的を使用する)が必ず少しの既存のトポロジーも打倒するというわけではないだろう感染しているマシンに紛らされて、検出するのが、より困難であるかもしれないところにあります。 一般に、受け身の攻撃の目標は送付者と受信機が、個人的に残っているのを好むだろうという情報[RFC3552]を得ることです。
On-path vs Off-path Attacks
オフ経路に対する経路の攻撃
In order for a datagram to be transmitted from one host to
another, it generally must traverse some set of intermediate links
and routers. Such routers are naturally able to read, modify, or
remove any datagram transmitted along that path. This makes it
much easier to mount a wide variety of attacks if you are on-path.
Off-path hosts can transmit arbitrary datagrams that appear to
come from any host but cannot necessarily receive datagrams
intended for other hosts. Thus, if an attack depends on being
able to receive data, off-path hosts must first subvert the
topology in order to place themselves on-path. This is by no
means impossible, but is not necessarily trivial [RFC3552]. A
more subtle attack is one where the traffic-mirroring capability
of a device is hijacked and the traffic is diverted to a
compromised host since the network topology may not need to be
subverted.
一般に、データグラムが1人のホストから別のホストまで送られるために、それは何らかのセットの中間的リンクとルータを横断しなければなりません。 そのようなルータは、その経路に沿って送られたどんなデータグラムも、読むか、変更するか、または自然に取り外すことができます。 これで、あなたが経路であるなら、さまざまな攻撃を仕掛けるのははるかに簡単になります。 オフ経路ホストは、どんなホストからも来るように見える任意のデータグラムを送ることができますが、必ず他のホストのために意図するデータグラムを受け取ることができるというわけではありません。 したがって、攻撃がデータを受け取ることができるのによるなら、オフ経路ホストは、最初に、自分たちでオン経路を置くためにトポロジーを打倒しなければなりません。 これは、決して不可能ではありませんが、必ず些細でないというわけではありません[RFC3552]。 より微妙な攻撃はデバイスのトラフィックを反映する能力がハイジャックされて、ネットワーク形態が打倒される必要はないかもしれないのでトラフィックが感染されたホストに紛らされるものです。
Kaeo Informational [Page 4] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[4ページ]のRFC4778OPSECは2007年1月に練習します。
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.
攻撃ソースは上記のどれかの組み合わせであるかもしれません。そのすべてがどんな攻撃もネットワークの有用性と信頼性に持つことができる影響力を確かめようとするとき、考えられる必要があります。 インサイダー攻撃か意図的でないイベントを止めるのはほとんど不可能です。 しかしながら、適切な監視メカニズムが適所にあるなら、また、いかなる他の攻撃ソースならもこれらの攻撃を検出して、緩和できます。 攻撃を特定して、たどるのに要する取り組みの量はもちろん攻撃者の工夫に富むことに依存しています。 さらに議論した特定の攻撃のどれかは本書では悪意のある態度について詳しく説明して、どれが「部外者」によって出典を明示されて、慎重であるかは攻撃されます。 あるセキュリティが特徴であると配布する後ろに動機を示しているために受動態対アクティブでオフ経路に対して経路の攻撃に関する実現の可能性に一層のいくらかの労作を与えるでしょう。
1.4. Operational Security Impact from Threats
1.4. 操作上のセキュリティに脅威から影響を与えます。
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.
実体が実体が認可されていないデータへのアクセスを得る状況かイベント。
Kaeo Informational [Page 5] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[5ページ]のRFC4778OPSECは2007年1月に練習します。
Deception
詐欺
A circumstance or event that may result in an authorized entity
receiving false data and believing it to be true.
誤ったデータを受け取って、それが本当であると信じている権限のある機関をもたらすかもしれない状況かイベント。
Disruption
分裂
A circumstance or event that interrupts or prevents the correct
operation of system services and functions. A broad variety of
attacks, collectively called denial of service attacks, threaten
the availability of systems and bandwidth to legitimate users.
Many such attacks are designed to consume machine resources,
making it difficult or impossible to serve legitimate users.
Other attacks cause the target machine to crash, completely
denying service to users.
システムサービスと機能の正しい操作を中断するか、または防ぐ状況かイベント。 広いバラエティーのまとめてサービス不能攻撃と呼ばれた攻撃は正統のユーザへのシステムと帯域幅の有用性を脅かします。 正統のユーザに役立つのを難しいか不可能にして、そのような多くの攻撃が、マシンリソースを消費するように設計されています。 他の攻撃で、ユーザに対するサービスを完全に否定して、ターゲットマシンはダウンします。
Usurpation
強奪
A circumstance or event that results in control of system services
or functions by an unauthorized entity. Most network
infrastructure systems are only intended to be completely
accessible to certain authorized individuals. Should an
unauthorized person gain access to critical layer 2/layer 3
infrastructure devices or services, they could cause great harm to
the reliability and availability of the network.
システムのコントロールをもたらす状況かイベントが、権限のない実体で修理するか、または機能します。 ほとんどのネットワークインフラシステムが確信している認可された個人には完全にアクセスしやすいことを意図するだけです。 権限のない人が限界層2/層3つのインフラストラクチャデバイスかサービスへのアクセスを得るなら、それらはネットワークの信頼性と有用性に重大な害を引き起こす場合がありました。
A complete description of threat actions that can cause these threat consequences can be found in [RFC2828]. Typically, a number of different network attacks are used in combination to cause one or more of the above-mentioned threat consequences. An example would be a malicious user who has the capability to eavesdrop on traffic. First, he may listen in on traffic for a while, doing reconnaissance work and ascertaining which IP addresses belong to specific devices, such as routers. Were this miscreant to obtain information, such as a router password sent in cleartext, he can then proceed to compromise the actual router. From there, the miscreant can launch various active attacks, such as sending bogus routing updates to redirect traffic or capture additional traffic to compromise other network devices. While this document enumerates which countermeasures ISPs are deploying today, a useful generic analysis of actual backbone infrastructure attacks and the appropriate countermeasures can be found in [RTGWG].
[RFC2828]でこれらの脅威結果を引き起こす場合がある脅威動作の完全な記述を見つけることができます。 通常、多くの異なったネットワーク攻撃が、上記の脅威結果の1つ以上を引き起こすのに組み合わせに使用されます。 例はトラフィックを立ち聞きする能力を持っている悪意あるユーザーでしょう。 まず最初に、彼はしばらく、トラフィックで聴くかもしれません、偵察仕事をして、どのIPアドレスが特定のデバイスに属すかを確かめて、ルータなどのように。 この悪党はcleartextで送られたルータパスワードの情報を得ることになっていて、次に、彼は実際のルータに感染しかけることができます。 そこから、悪党は様々な活発な攻撃に着手できます、他のネットワークがデバイスであると感染するためにトラフィックを向け直すか、または追加トラフィックを得るためににせのルーティングアップデートを送るのなどように。 このドキュメントがISPが今日配布しているどの対策を列挙しているか間、[RTGWG]で実際のバックボーンインフラストラクチャ攻撃と適切な対策の役に立つジェネリック分析を見つけることができます。
Kaeo Informational [Page 6] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[6ページ]のRFC4778OPSECは2007年1月に練習します。
1.5. Document Layout
1.5. ドキュメントレイアウト
This document is a survey of current operational practices that mitigate the risk of being susceptible to any threat actions. As such, the main focus is on the currently deployed security practices used to detect and/or mitigate attacks. The top-level categories in this document are based on operational functions for ISPs and generally relate to what is to be protected. This is followed by a description of which attacks are possible and the security practices currently deployed. This will provide the necessary security services to help mitigate these attacks. These security services are classified as follows:
このドキュメントはどんな脅威動作にも影響されやすいことの危険を緩和する現在の操作上の習慣の調査です。 そういうものとして、主な焦点が攻撃を検出する、そして/または、緩和するのに使用される現在配布しているセキュリティ実践にあります。 トップレベルカテゴリは、本書ではISPのための操作上の機能に基づいていて、一般に、保護されることになっているべきことに関連します。 攻撃が可能である記述と現在配布されているセキュリティ実践はこれのあとに続いています。 これは、これらの攻撃を緩和するのを助けるために必要なセキュリティー・サービスを提供するでしょう。 これらのセキュリティー・サービスは以下の通り分類されます:
o User Authentication
o ユーザー認証
o User Authorization
o ユーザ承認
o Data Origin Authentication
o データ発生源認証
o Access Control
o アクセス制御
o Data Integrity
o データの保全
o Data Confidentiality
o データの機密性
o Auditing/Logging
o 監査/伐採
o DoS Mitigation
o DoS緩和
In many instances, a specific protocol currently deployed will offer a combination of these services. For example, Authentication, Authorization, and Accounting (AAA) can offer user authentication, user authorization, and audit/logging services, while the Secure SHell (SSH) Protocol can provide data origin authentication, data integrity, and data confidentiality. The services offered are more important than the actual protocol used. Note that access control will refer basically to logical access control, i.e., filtering. Each section ends with an additional considerations section that explains why specific protocols may or may not be used, and also gives some information regarding capabilities, which are not possible today due to bugs or lack of usability.
多くのインスタンスでは、現在配布されている特定のプロトコルはこれらのサービスの組み合わせを提供するでしょう。 例えば、Authentication、Authorization、およびAccounting(AAA)はユーザー認証、ユーザ承認、および監査/伐採サービスを提供できます、Secure SHell(SSH)プロトコルはデータ発生源認証、データ保全、およびデータの機密性を提供できますが。 提供されたサービスは実際のプロトコルが使用したより重要です。 アクセスコントロールが基本的に論理的なアクセスコントロール、すなわち、フィルタリングについて言及することに注意してください。 各セクションは特定のプロトコルがなぜ使用されるかもしれないかを説明して、また今日ユーザビリティのバグか不足のために可能でない能力のいくつかの情報を提供する追加問題部で終わります。
Kaeo Informational [Page 7] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[7ページ]のRFC4778OPSECは2007年1月に練習します。
2. Protected Operational Functions
2. 保護された操作上の機能
2.1. Device Physical Access
2.1. デバイスの物理的なアクセス
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のネットワークインフラデバイスの物理的な位置を保護して、アクセスに関係します。 物理的なセキュリティはそういうものの研究/習慣の大きい分野です、論証上最も大きいです、最も古いです、そして、大部分がセキュリティの領域をよく理解していました。 天災のための緊急時対策を持っているのは重要ですが、このドキュメントの範囲の外に地震や洪水などのようなこれはあります。(洪水はネットワークデバイスへの損傷をもたらすことができます)。 ここで、私たちは、物理的な位置とすなわち、物理的な位置がコンソールアクセサリーを保護しながら感染されたなら不正アクセスからデバイスをどうさらに保護できるかへのアクセスを保護するのに携わります。 物理的なアクセスの侵入者がデバイスの運用統制を獲得するのを主に止めるのをこれは目的とされます。 何も、物理的なアクセスの攻撃者がサービス不能攻撃に作用するか、またはただいくつかのケーブルのプラグを抜くのを止めないことに注意してください。容易に、デバイスで動かすことによって、サービス不能攻撃を実行できます。
2.1.1. Threats/Attacks
2.1.1. 脅威/攻撃
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デバイスを層に手に入れるなら、全体のネットワークインフラが侵入者のコントロールの下にあることができます。 最小限では、侵入者は使われなくなっていた状態で感染しているデバイスを取ることができます、ネットワーク分裂(それの範囲をネットワーク形態に依存する)を引き起こして。 より悪いシナリオは侵入者がコンソールパスワードを解読するのにこのデバイスを使用するところです、デバイス(だれも恐らくそのようなaを検出しないで、妥協してくださいか、別のネットワークデバイスをaに取り付けるために、侵入者がネットワーク形態を確かめることができるデータを移植して、吸収する)の完全なコントロールと全体のネットワークを獲得して。
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.
さまざまな方法で物理的なアクセスを得る脅威を実現できます、重要なデバイスが高いセキュリティの下にあっても。 ケースは攻撃者が主要な供給停止とプライバシー感染を引き起こした重要なデバイスへの物理的なアクセスを得るために保安要員をまねたところにまだ現れています。 任命された者からのインサイダー攻撃をも本当の脅威を引き起こして、適切に認識されて、扱わなければなりません。
2.1.2. Security Practices
2.1.2. セキュリティ実践
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
フィジカル・デバイスセキュリティのために、設備は非常に制限している環境で保たれます。 カード主要なバッジをもっている認定ユーザだけが重要なネットワークインフラデバイスを含む物理的な位置のいずれにも近づく手段を持っています。 これらのカード主要なシステムはだれに関する道を保つか。
Kaeo Informational [Page 8] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[8ページ]のRFC4778OPSECは2007年1月に練習します。
accessed which location and at what time. Most cardkey systems have a fail-back "master key" in case the card system is down. This "master key" usually has limited access and its use is also carefully logged (which should only happen if the card-key system is NOT online/functional).
どの位置で何時にアクセスされているか。 カードシステムがダウンしているといけないので、ほとんどのcardkeyシステムには、フェールバック「マスターキー」があります。 通常、この「マスターキー」はアクセスを制限しました、そして、また、使用は慎重に登録されます(カード主要なシステムがオンライン的でもなくて、また機能的でもない場合にだけ、起こるべきです)。
All console access is always password protected and the login time is set to time out after a specified amount of inactivity - typically between 3-10 minutes. The type of privileges that you obtain from a console login varies between separate vendor devices. In some cases you get initial basic access and need to perform a second authentication step to get more privileged access (i.e., enable or root). In other vendors, you get the more privileged access when you log into the console as root, without requiring a second authentication step.
ログイン時間は不活発の一定金額の後にタイムアウトに設定されます--いつもすべてのコンソールアクセスが保護されたパスワードです、そして、通常3-10分の間で。 あなたがコンソールログインから得る特権のタイプは別々のベンダーデバイスの間で異なります。 すなわち、いくつかの場合、あなたが、より特権があるアクセスを得るのに初期の基本的なアクセスを得て、第2の認証ステップを実行する必要がある、(可能にするか、根づく、) 根としてコンソールにログインするとき、他のベンダーでは、あなたは、より特権があるアクセスを得ます、第2の認証ステップを必要としないで。
How ISPs manage these logins vary greatly, although many of the larger ISPs employ some sort of AAA mechanism to help automate privilege-level authorization and utilize the automation to bypass the need for a second authentication step. Also, many ISPs define separate classes of users to have different privileges while logged onto the console. Typically, all console access is provided via an out-of-band (OOB) management infrastructure, which is discussed in Section 2.2 of this document.
ISPがどうこれらのログインを管理するかは大いに異なります、より大きいISPの多くが特権レベル承認を自動化して、第2の認証ステップの必要性を迂回させるのにオートメーションを利用するのを助けるのにある種のAAAメカニズムを使いますが。 また、多くのISPが、コンソールに登録されている間、異なった特権を持つために別々のクラスのユーザを定義します。 通常、バンドで出ている(OOB)管理インフラストラクチャですべてのコンソールアクセスを提供します。(このドキュメントのセクション2.2でそれについて、議論します)。
2.1.3. Security Services
2.1.3. セキュリティー・サービス
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 ユーザAuthentication--物理的な施設に近づく手段を持っているすべての個人が認証されます。 コンソールアクセスは認証されます。
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 ユーザAuthorization--認証された個人はデバイスで実行コマンドに暗黙の承認を持っています。 いくつかの場合、複数の認証が、基本的でより特権があるアクセスを区別するのに必要です。
o Data Origin Authentication - Not applicable.
o データOrigin Authentication--適切ではありません。
o Access Control - Not applicable.
o Controlにアクセスしてください--適切ではありません。
o Data Integrity - Not applicable.
o データの保全--適切ではありません。
o Data Confidentiality - Not applicable.
o データConfidentiality--適切ではありません。
Kaeo Informational [Page 9] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[9ページ]のRFC4778OPSECは2007年1月に練習します。
o Auditing/Logging - All access to the physical locations of the
infrastructure equipment is logged via electronic card-key
systems. All console access is logged (refer to Section 2.2 of
this document for more details).
o インフラストラクチャ設備の物理的な位置へのすべてのアクセスが電子カード主要なシステムで登録されます。監査/伐採--すべてのコンソールアクセスが登録されます(その他の詳細のためのこのドキュメントのセクション2.2について言及します)。
o DoS Mitigation - Not applicable.
o DoS Mitigation--適切ではありません。
2.1.4. Additional Considerations
2.1.4. 追加問題
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がOOB管理インフラストラクチャでコンソールアクセスを提供します。(このドキュメントのセクション2.2でそれについて、議論します)。
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が、適切に認証されないか、または権限を与えられない人々への物理的なアクセスが重要インフラデバイスに物理的なアクセスを持っていることを否定するために会社の人員を教育するために実務講習と啓発プログラムを設立しました。
2.2. Device Management - In-Band and Out-of-Band (OOB)
2.2. デバイス管理--バンドとバンドの外(OOB)
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管理とバンドで同じ管理ですが、それに注意してください、とデバイスへのアクセス以来この経営者側がネットワークでつなぐ化粧はOOBマネージメントシステムですが、保護されて、それほど悪意がある活動に影響されやすくないと考えられて、ほとんどのISPがより用心深く好みます。
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
コンソールアクセスはOOBネットワークを通していつもarchitectedされます。 現在、バンドにおける管理かOOBのどちらかに使用されるメカニズムが仮想端末アクセス(すなわち、TelnetかSSH)、Simple Network Managementプロトコル(SNMP)、またはHTTPであります。 インタビューされたすべての大きいISPでは、HTTP管理は、決して使用されないで、明らかに使用されました。
Kaeo Informational [Page 10] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[10ページ]のRFC4778OPSECは2007年1月に練習します。
disabled. Note that file transfer protocols (TFTP, FTP, and SCP) will be covered in Section 2.5 of this document.
障害がある。 ファイル転送プロトコル(TFTP、FTP、およびSCP)がこのドキュメントのセクション2.5でカバーされていることに注意してください。
2.2.1. Threats/Attacks
2.2.1. 脅威/攻撃
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.
両方のオン経路とオフ経路シナリオに、活発な攻撃は可能です。 経路に対する活発な攻撃に、状況は受け身の攻撃のように同じです、デバイスが既に感染されなければならない、さもなければ、デバイスを経路に挿入できるところで。 能動態がトポロジー転覆が交通ルートを変更するのに必要であるところで攻撃して、本質的にはもたらすオフ経路、攻撃者、オン経路、一般に、攻撃はメッセージ挿入か変更に制限されます。
2.2.1.1. Confidentiality Violations
2.2.1.1. 秘密性違反
Confidentiality violations can occur when a miscreant intercepts any management data that has been sent in cleartext or with weak encryption. This includes interception of usernames and passwords with which an intruder can obtain unauthorized access to network devices. It can also include other information, such as logging or configuration information, if an administrator is remotely viewing local logfiles or configuration information.
悪党がcleartextか弱い暗号化と共に送られたどんな管理データも傍受するとき、秘密性違反は起こることができます。 これは侵入者がデバイスをネットワークでつなぐために不正アクセスを得ることができるユーザ名とパスワードの妨害を含んでいます。 また、それは他の情報を含むことができます、伐採や設定情報のように、管理者が地方のログファイルか設定情報を離れて見ているなら。
2.2.1.2. Offline Cryptographic Attacks
2.2.1.2. オフライン暗号の攻撃
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.
ユーザ名/パスワード情報が暗号化されたか、しかし、使用される暗号のメカニズムでデータを得て、暗号化キーを壊すのは簡単になって、デバイス管理トラフィックに感染することができました。 トラフィックは、ネットワークを立ち聞きするか、またはトラフィックを悪意あるユーザーに紛らすことができることに捕らわれる必要があるでしょう。
2.2.1.3. Replay Attacks
2.2.1.3. 反射攻撃
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.
反射攻撃がうまくいっているために、管理トラフィックは、最初に後で意図している受取人に再演されるためにどちらのオンまた経路でもあるとキャプチャされるか、または攻撃者に紛らされる必要があるでしょう。
Kaeo Informational [Page 11] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[11ページ]のRFC4778OPSECは2007年1月に練習します。
2.2.1.4. Message Insertion/Deletion/Modification
2.2.1.4. メッセージ挿入/削除/変更
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スプーフィングで可能です、とホストは信じました。(そこでは、リモートホストが別のものから来るように見えるパケットを出します)。
2.2.1.5. Man-In-The-Middle
2.2.1.5. マン・イン・ザ・ミドル
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.
介入者攻撃はデータ・ストリーム自体よりむしろ交信している同輩のアイデンティティを攻撃します。 攻撃者はマネージメントシステムからネットワークインフラストラクチャデバイスに送られるトラフィックとネットワークインフラデバイスからマネージメントシステムに送られるトラフィックを妨害します。
2.2.2. Security Practices
2.2.2. セキュリティ実践
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.
バンドにおける経営者側とOOB経営者側が2を層にして、3台のデバイスを層にするためにアクセスするすべてが認証されます。 AAAサーバ(すなわち、中のRemote Authentication Dial User Service(RADIUS)、そして/または、Terminal Access Controller Access-コントロールSystem(TACACS+))によってユーザー認証と承認は通常制御されます。 ユーザのアイデンティティを決定するのに使用される資格証明書は静的なユーザ名/パスワードとSecure-IDなどの1回のユーザ名/パスワード体系に異なります。 静的なユーザ名/パスワードは指定された期間、通常30日後に吐き出されます。 AAAを通したあらゆる認証された実体がコントロールの、よりすばらしい粒状のための個々のユーザです。 しばしば、OOB管理認証に使用されるAAAサーバがバンドにおける管理ユーザー認証に使用されるAAAサーバからの別々のフィジカル・デバイスであることに注意してください。 いくつかの展開、デバイス管理認証/承認/会計に使用されるAAAサーバは、いかなる他の認証機能にも画定を供給するために別々のネットワークで中です。
For backup purposes, there is often a single local database entry for authentication that is known to a very limited set of key personnel. It is usually the highest privilege-level username/password combination, which in most cases is the same across all devices. This local device password is routinely regenerated once every 2-3 months, and is also regenerated immediately after an employee who had access to that password leaves the company or is no longer authorized to have knowledge of that password.
バックアップ目的のために、非常に限られたセットの主要人員にとって知られている認証のための単一の地方のデータベースエントリーがしばしばあります。 通常、それは最も高い特権レベルユーザーネーム/パスワード組み合わせです。(多くの場合、そのユーザーネーム/パスワード組み合わせはすべてのデバイスの向こう側に同じです)。 このローカル装置パスワードが一度きまりきって作り直される、あらゆる、2-3カ月、また、そのパスワードに近づく手段を持っていた従業員が退職する直後作り直されるか、またはもうそのパスワードに関する知識を持っているのは認可されません。
Kaeo Informational [Page 12] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[12ページ]のRFC4778OPSECは2007年1月に練習します。
Each individual user in the AAA database is configured with specific authorization capability. Specific commands are either individually denied or permitted, depending on the capability of the device to be accessed. Multiple privilege levels are deployed. Most individuals are authorized with basic authorization to perform a minimal set of commands, while a subset of individuals are authorized to perform more privileged commands. Securing the AAA server is imperative and access to the AAA server itself is strictly controlled. When an individual leaves the company, his/her AAA account is immediately deleted and the TACACS/RADIUS shared secret is reset for all devices.
AAAデータベースのそれぞれの個々のユーザは特定の承認能力によって構成されます。 デバイスがアクセスされる能力によって、特定のコマンドは、個別に否定されるか、または受入れられます。 複数の特権レベルが配布されます。 ほとんどの個人が1人の極小集合のコマンドを実行する基本認可で権限を与えられます、個人の部分集合が、より特権があるコマンドを実行するのが認可されますが。 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日間の間でこれらの共同体ストリングを変えるために、手順が適所にあります。 システムが、2SNMP共同体がストリングであるとサポートするなら、古いストリングを現在中古のストリングから新しいものまでの最初に1秒を構成する、より新しい共同体ストリング、次に、および移行するのに取り替えます。 複数のSNMPシステムがほとんどの大きいISPからそれらのルータにアクセスするので、正しいすべてのシステムですべてのストリングを修理させているには次にあるメインテナンスの期間が以上にかかります。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
すべてのデバイス管理アクセスが監査されます、そして、どんな違反も自動化されたメール、ポケットベル、そして/または、電話通知を開始するアラームの引き金となります。 AAAサーバは特定のデバイスで実行されたすべてのコマンドと同様に認証された実体の動向をおさえます。 さらに、デバイス自体がどんなアクセス制御違反も登録する、(すなわち、SSH要求はそうしないIPアドレスから入ります。
Kaeo Informational [Page 13] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[13ページ]のRFC4778OPSECは2007年1月に練習します。
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)
明らかに、受入れられます、そのイベントが怒っているIPアドレスを追跡できる登録されたそうとそれが特定のインフラストラクチャデバイスにアクセスしようとしていた理由に関してされた調査である、)
2.2.3. Security Services
2.2.3. セキュリティー・サービス
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 ユーザAuthentication--すべての個人がAAAサービスで認証されます。
o User Authorization - All individuals are authorized via AAA
services to perform specific operations once successfully
authenticated.
o ユーザAuthorization--首尾よく一度認証された特定の操作を実行するAAAサービスですべての個人が権限を与えられます。
o Data Origin Authentication - Management traffic is strictly
filtered to allow only specific IP addresses to have access to the
infrastructure devices. This does not alleviate risk the from
spoofed traffic, although when combined with edge filtering using
BCP38 [RFC2827] and BCP84 [RFC3704] guidelines (discussed in
Section 2.5), then the risk of spoofing is mitigated, barring a
compromised internal system. Also, using SSH for device access
ensures that no one can spoof the traffic during the SSH session.
o データOrigin Authentication--管理トラフィックは、特定のIPアドレスだけがインフラストラクチャデバイスに近づく手段を持っているのを許容するために厳密にフィルターにかけられます。 これが危険を軽減しない、次に、BCP38[RFC2827]を使用して、BCP84[RFC3704]ガイドラインをフィルターにかける(セクション2.5では、議論します)縁に結合されると、スプーフィングの危険が緩和されますが、感染している内部のシステムを禁じる偽造しているトラフィックから。 また、デバイスアクセスにSSHを使用するのは、だれもSSHセッションの間トラフィックを偽造することができないのを確実にします。
o Access Control - Management traffic is filtered to allow only
specific IP addresses to have access to the infrastructure
devices.
o アクセスControl--管理トラフィックは、特定のIPアドレスだけがインフラストラクチャデバイスに近づく手段を持っているのを許容するためにフィルターにかけられます。
o Data Integrity - Using SSH provides data integrity and ensures
that no one has altered the management data in transit.
o データの保全--SSHを使用するのは、データ保全を前提として、だれもトランジットにおける管理データを変更していないのを確実にします。
o Data Confidentiality - Using SSH provides data confidentiality.
o データ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.
o DoS Mitigation--特定のIPアドレスだけがインフラストラクチャデバイスに近づく手段を持っているのを許容するのにパケットフィルタを使用します。 制限しますが、これは偽造しているインフラストラクチャデバイスが向けられたDoS攻撃を防ぎません。 しかしながら、リスクが、管理目的に別々の物理ネットワークを使用することによって、低くなります。
Kaeo Informational [Page 14] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[14ページ]のRFC4778OPSECは2007年1月に練習します。
2.2.4. Additional Considerations
2.2.4. 追加問題
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 rekeyイベントを必要とします。 また、SSHキーがルートプロセッサカードに保存される場合では、ルートプロセッサカードが、交換される必要があるときはいつも、SSHを再の合わせることが必要でしょう。 いくつかのプロバイダーが、この操作上の影響が必要な状態でセキュリティを超えているのを感じて、それらのデバイスを管理するのに代わりに信じられた内面のホスト('jumphosts'か'要塞ホスト'と呼ばれます)からTelnetを使用します。 個人はjumphostから実際のどんなパスワードもjumphostとデバイスの間それが接続している明確で送られるのを完全に理解しているインフラストラクチャデバイスまでのjumphostと次に、Telnetへの最初のSSHがそうするでしょう。 すべての認証と承認が、AAAサーバを使用することでまだ行われています。
In instances where Telnet access is used, the logs on the AAA servers are more verbose and more attention is paid to them to detect any abnormal behavior. The jumphosts themselves are carefully controlled machines and usually have limited access. Note that Telnet is NEVER allowed to an infrastructure device except from specific jumphosts; i.e., packet filters are used at the console server and/or infrastructure device to ensure that Telnet is only allowed from specific IP addresses.
インスタンスでは、Telnetアクセスが使用されているところでは、AAAサーバに関するログは、より冗長です、そして、どんな異常行動も検出するのにより多くの注意をそれらに向けます。 jumphosts自身は慎重に制御されたマシンであり、通常、アクセサリーを制限しました。 特定のjumphosts以外に、Telnetがインフラストラクチャデバイスに決して許容されていないことに注意してください。 すなわち、パケットフィルタは、Telnetが特定のIPアドレスから許容されているだけであるのを保証するのにコンソールサーバ、そして/または、インフラストラクチャデバイスで使用されます。
With thousands of devices to manage, some ISPs have created automated mechanisms to authenticate to devices. As an example, Kerberos has been used to automate the authentication process for devices that have support for Kerberos. An individual would first log in to a Kerberized UNIX server using SSH and generate a Kerberos 'ticket'. This 'ticket' is generally set to have a lifespan of 10 hours and is used to automatically authenticate the individual to the infrastructure devices.
管理する何千台ものデバイスで、いくつかのISPがデバイスに認証する自動化されたメカニズムを作成しました。 例として、ケルベロスは、ケルベロスのサポートを持っているデバイスのために認証過程を自動化するのに使用されました。 個人は、最初に、SSHを使用することでKerberized Unixサーバーにログインして、ケルベロス'チケット'を生成するでしょう。 この'チケット'は、一般に、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をサポートするだけです。(次に、SNMPv1は、操作上の簡単さのためにすべてのインフラストラクチャデバイスの向こう側に使用を強制するためにプロバイダーを必要とします)。 セットアップするのがv3より簡単であるので、SNMPv2は主として配布されます。
Kaeo Informational [Page 15] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[15ページ]のRFC4778OPSECは2007年1月に練習します。
2.3. Data Path
2.3. データ経路
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に攻撃を引き起こして、ネットワークを入手できなく表すことができる多量の悪意があるトラフィックのため、具体策は、正統の顧客トラフィックを進めるために有用性を確実にするために時々配布されます。
2.3.1. Threats/Attacks
2.3.1. 脅威/攻撃
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オプションを作成するか、またはパケット断片化などの)を引き起こすためにヘッダーフィールドのどんな部分も台無しにする偽造しているソース、そして/または、送付先アドレスかいかなる他の誤った形式のパケットでもパケットから成ることができます。
2.3.2. Security Practices
2.3.2. セキュリティ実践
Filtering and rate limiting are the primary mechanism to provide risk mitigation of malicious traffic rendering the ISP services unavailable. However, filtering and rate limiting of data path traffic is deployed in a variety of ways, depending on how automated the process is and what the capabilities and performance limitations of the existing deployed hardware are.
フィルタリングとレート制限はISPサービスを入手できなくする悪意があるトラフィックのリスク緩和を提供する一次機構です。 しかしながら、データ経路トラフィックのフィルタリングとレート制限はさまざまな方法で配布されます、プロセスがどれくらい自動化されているか、そして、ハードウェアであると配布された存在の能力と性能限界が何であるかによって。
The ISPs that do not have performance issues with their equipment follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress filtering. BCP38 recommends filtering ingress packets with obviously spoofed and/or 'reserved' source addresses to limit the effects of denial-of-service attacks, while BCP84 extends the recommendation for multi-homed environments. Filters are also used to help alleviate issues between service providers. Without any filtering, an inter-exchange peer could steal transit just by using static routes, and essentially redirect data traffic. Therefore, some ISPs have implemented ingress/egress filters that block unexpected source and destination addresses not defined in the above-mentioned documents. Null routes and black-hole triggered routing [RFC3882] are used to deter any detected malicious traffic streams. These two techniques are described in more detail in Section 2.8 below.
それらの設備の性能問題を持っていないISPはイングレスフィルタリングのためのBCP38[RFC2827]とBCP84[RFC3704]ガイドラインに従います。 BCP38が、BCP84が推薦を広げている間のサービス不能攻撃の効果を制限する明らかに偽造しているそして/または、'予約された'ソースアドレスでイングレスパケットをフィルターにかけることを勧める、マルチ、家へ帰り、環境。 また、フィルタは、サービスプロバイダーの間の問題を軽減するのを助けるのに使用されます。 少しもフィルタリングがなければ、相互交換同輩は、スタティックルートを使用するだけでトランジットを横取りして、データ通信量を本質的には向け直すことができました。 したがって、いくつかのISPが、イングレス/出口フィルタが予期していなかった情報筋と送付先アドレスが上記のドキュメントで定義しなかったそのブロックであると実装しました。 ヌルルートとブラックホールの引き起こされたルーティング[RFC3882]は、どんな検出された悪意があるトラフィックストリームも思いとどまらせるのに使用されます。これらの2つのテクニックがさらに詳細に以下のセクション2.8で説明されます。
Most ISPs consider layer 4 filtering useful, but it is only implemented if performance limitations allow for it. Since it poses a large administrative overhead and ISPs are very much opposed to acting as the Internet firewall, Layer 4 filtering is typically
ほとんどのISPが、層4のフィルタリングが役に立つと考えますが、性能制限がそれを考慮する場合にだけ、それは実装されます。 大きい管理オーバーヘッドを引き起こして、ISPがインターネットファイアウォールとして機能するのにたいへん反対されるので、Layer4フィルタリングは通常、反対されます。
Kaeo Informational [Page 16] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[16ページ]のRFC4778OPSECは2007年1月に練習します。
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.
最後のオプションとして、実装されます。 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.
ユニキャストReverse Path Forwarding(RPF)は一貫して実装されません。 そうすることの途中にいくつかのISPがあって、他のISPは、トラフィックであると偽造されたそれを知る知覚された利益が正統であるのから来ると思いますが、アドレスは操作上の複雑さの価値がありません。 いくつかのプロバイダーには、ネットワークにおけるすべてのハードウェアがDS3速度のためにuRPFをサポートしたという事実のためであったDigitalよりSignal3(DS3)のリンク速度における以下のuRPFを実装する方針があります。 より高い速度リンクでは、uRPFサポートは無節操でした、そして、操作上の人々が一貫したソリューションを実現するのは、より簡単でした。
2.3.3. Security Services
2.3.3. セキュリティー・サービス
o User Authentication - Not applicable.
o ユーザAuthentication--適切ではありません。
o User Authorization - Not applicable.
o ユーザAuthorization--適切ではありません。
o Data Origin Authentication - When IP address filtering per BCP38,
BCP84, and uRPF are deployed at network edges it can ensure that
any spoofed traffic comes from at least a legitimate IP address
and can be tracked.
o データOrigin Authentication--1BCP38あたりのIPアドレスフィルタリング、BCP84、およびuRPFがそうときに、ネットワーク縁で配布されて、それは、どんな偽造しているトラフィックも少なくとも正統の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 アクセスControl--IPアドレスフィルタリングと層4のフィルタリングは、禁制のプロトコルと限界トラフィックがインフラストラクチャデバイス自体のために運命づけられたことを否定するのに使用されます。 また、フィルタは、予期していなかったソース/送付先アドレスを妨げるのに使用されます。
o Data Integrity - Not applicable.
o データの保全--適切ではありません。
o Data Confidentiality - Not applicable.
o データConfidentiality--適切ではありません。
o Auditing/Logging - Filtering exceptions are logged for potential
attack traffic.
o 監査/伐採--フィルタリング例外は起こり得るかもしれない攻撃トラフィックのために登録されます。
o DoS Mitigation - Black-hole triggered filtering and rate-limiting
are used to limit the risk of DoS attacks.
o DoS Mitigation--ブラックホールの引き起こされたフィルタリングとレート制限は、DoS攻撃の危険を制限するのに使用されます。
2.3.4. Additional Considerations
2.3.4. 追加問題
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アドレスフィルタリングと認証は大規模な展開に使用されません。 これは問題をネットワークでつなぐことにおける障害調査するときそれが引き起こす場合がある問題のためです。 ポートセキュリティは何千個ものスイッチが配布される大規模で「非-処理しやす」になります。
Kaeo Informational [Page 17] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[17ページ]のRFC4778OPSECは2007年1月に練習します。
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を引き起こす能力に関する一貫性の欠如。 その一例が縁の箱にあります、OC-12(光学Carrier)アップリンクでルータに接続する1000T1sまで。 或るものは、フィルタリングでデバイス経験が大きい性能影響であると配布しました、(uRPF)をフィルターにかけるイングレスはこれらの集合ルータを接続しているデバイスで適切であるかもしれませんが。(フィルタリングは一時的な顧客トラフィックにおいて突き抜けた状態で容認できません)。 性能が問題でないところでは、ISPは管理の間でリスクに対して見返りをします。
2.4. Routing Control Plane
2.4. ルート設定制御飛行機
The routing control plane deals with all the traffic that is part of establishing and maintaining routing protocol information.
ルーティング制御飛行機はルーティングプロトコル情報を確立して、維持する一部であるすべてのトラフィックに対処します。
2.4.1. Threats/Attacks
2.4.1. 脅威/攻撃
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.
オフ経路の活発な攻撃において、一般に、攻撃はメッセージ挿入か変更に制限されます、トラフィックが意図している目的地に決して達しないことを引き起こして。(変更は違法な目的地にトラフィックを逸らすことができます)。
Kaeo Informational [Page 18] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[18ページ]のRFC4778OPSECは2007年1月に練習します。
2.4.1.1. Confidentiality Violations
2.4.1.1. 秘密性違反
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が個人的で独占である情報としてアドレシング体系とネットワークtopologiesを分類しているので、これは一層の関心になっています。 また、ルーティング・プロトコルパケットがルーティングセッションを偽造したか、またはハイジャックできた方法を示しているかもしれない情報を含んでいるので、それは関心です。 これは順番に介入者攻撃に導くことができました、悪党がトラフィック経路に自分たちを挿入するか、トラフィック経路を紛らして、または利用者データの秘密性に違反できるところで。
2.4.1.2. Offline Cryptographic Attacks
2.4.1.2. オフライン暗号の攻撃
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.
何か暗号のメカニズムがデータ保全と秘密性に備えるのに使用されるなら、オフライン暗号の攻撃は潜在的にデータに感染するかもしれないでしょうに。 トラフィックは、ネットワークを立ち聞きするか、またはトラフィックを悪意あるユーザーに紛らすことができることに捕らわれる必要があるでしょう。 デバイスが、暗号で保護されたルーティングが情報であると盗み聞いて、単にキャプチャすることができたならこの攻撃が可能であるように暗号で保護されたルーティング情報を使用することによって、後者が、暗号化キーが既にとにかく感染されるのを必要とすることに注意してください。
2.4.1.3. Replay Attacks
2.4.1.3. 反射攻撃
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.
反射攻撃がうまくいっているために、ルーティングコントロール飛行機通行は、最初に後で意図している受取人に再演されるためにどちらのオンまた経路でもあるとキャプチャされるか、または攻撃者に紛らされる必要があるでしょう。 さらに、また、これらのプロトコルの多くが反復操作による保護メカニズムを含むので、これらは、打倒されていて、適切である必要があるでしょう。
2.4.1.4. Message Insertion/Deletion/Modification
2.4.1.4. メッセージ挿入/削除/変更
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攻撃を引き起こす場合があります。
2.4.1.5. Man-In-The-Middle
2.4.1.5. マン・イン・ザ・ミドル
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
介入者攻撃はデータ・ストリーム自体よりむしろ交信している同輩のアイデンティティを攻撃します。 攻撃者は1人のルーティング同輩からもう片方に送られて、同輩のひとりを代表して交信するトラフィックを妨害します。 これは権限のない受信をどちらかへのユーザトラフィックの転換に導くことができます。
Kaeo Informational [Page 19] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[19ページ]のRFC4778OPSECは2007年1月に練習します。
party or cause legitimate traffic to never reach its intended destination.
パーティーへ行くか、または正統のトラフィックが意図している目的地に決して達しないことを引き起こしてください。
2.4.2. Security Practices
2.4.2. セキュリティ実践
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.
ルーティング制御飛行機を固定すると、多くの特徴が取ります。(一般に、特徴はシステムとして配布されます)。 メッセージDigest5(MD5)認証はいくつかのISPによって使用されて、送付同輩を有効にして、トランジットにおけるデータが変更されていないのを保証します。 いくつかのISPが、顧客の要求によってMD5が認証であると配布するだけです。 容認されたルーティングアップデートが有効なルーティング同輩によって溯源されたという妥当な確実性で確実にする追加健全度チェックはルートフィルタとGeneralized TTL Security Mechanism(GTSM)の特徴[RFC3682](また、時々TTL-ハッキングと呼ばれる)を含んでいます。 GTSMの特徴は、ボーダ・ゲイトウェイ・プロトコル(BGP)などのプロトコルに使用されて、同輩を伝えながら保護するのに、パケットのTime To Live(TTL)分野(IPv4)かHop Limit(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顧客のための送受信の接頭語フィルタ、同輩のための送受信の接頭語フィルタ、および上流の隣人、入って来るAS-PATHはBGPのために顧客をフィルターにかけます、と同輩と、上流の隣人と、ルートの湿りと選択された属性と共同体を拒絶することに向かって出発しているAS-PATHはフィルターにかけます。 これらの方針の間一貫性が大いに異なって、もう一方の端が端サイトでありか否かに関係なく内部の同輩対別の大きいISPか顧客に対して明確な区別があります。 ほとんどISPは彼らの端サイト顧客を接頭語でフィルターにかけますが、大きい接頭語フィルタリストを維持する操作上の規制のため、多くのISPが彼らの同輩と上流の隣人からの/へのBGP AS-PATHフィルタにより始めています。
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
接頭語リストが使用されていない場合では、オペレータは、misconfiguration(例えば、意図的でない反-集合か隣人ルーティング方針誤構成)を防ぐか、または攻撃を積みすぎるために1同輩あたり1つの最大の接頭語限界をしばしば定義します。 ISPは、互いと共に予想された接頭語交換がものであるのに調整して、この数をいくらかの気が確かな量で増強する必要があります。 ISPが最大接頭語番号をルーティング発表における有効なスイングを考慮できるくらい水増しするのは、重要です、BGPセッションの意図的でない閉鎖を防いで。 ISPの中の個々の実装は、ユニークであり、設備供給者、異なった実装オプションによっています。
Kaeo Informational [Page 20] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[20ページ]のRFC4778OPSECは2007年1月に練習します。
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.
利用可能。 ほとんどの設備ベンダーがただ受け取られる過度の接頭語を登録するのから自動的にセッションを止めるまで及ぶ実装オプションを提供します。 何らかのあらかじめ設定されたアイドルタイムアウトに達した後にセッションを回復させるオプションが利用可能であるなら、セッションを自動的に回復させると隣接している隣人で誤構成している方針が状態を引き起こすことであるなら不安定性が潜在的に絶え間なく総合的な経路指定テーブルに導入されるかもしれないのが理解されるべきです。 じっと見ている隣人での重大な誤構成が起こったなら、自動的にセッションを止めて、それを残すのは、必要に応じて手動でクリアされるまで停止して、時々最も良く、修正するオペレータ介入を考慮します。
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が、ルートがインターネットルート設定Registry(IRR)に登録されるのを必要とします--フィルタリストを生成するのに使用できるインターネットのネットワークのためのルーティング情報の公共の登録。そして、Registryはルート設定Assets Database(RADb)の一部であるかもしれません。 特にヨーロッパでは、いくつかのISPがだれかと共にeBGP同輩になるのに同意する前に、登録されたルートを必要とします。
Many ISPs also do not propagate interface IP addresses to further reduce attack vectors on routers and connected customers.
多くのISPも、ルータと接続顧客で攻撃ベクトルをさらに減少させるためにインタフェースIPアドレスを伝播しません。
2.4.3. Security Services
2.4.3. セキュリティー・サービス
o User Authentication - Not applicable.
o ユーザAuthentication--適切ではありません。
o User Authorization - Not applicable.
o ユーザAuthorization--適切ではありません。
o Data Origin Authentication - By using MD5 authentication and/or
the TTL-hack, a routing peer can be reasonably certain that
traffic originated from a valid peer.
o MD5認証を使用するのによるデータOrigin Authentication、そして/または、TTL-ハッキング、ルーティング同輩はトラフィックが有効な同輩から発したのを合理的に確信している場合があります。
o Access Control - Route filters, AS-PATH filters, and prefix limits
are used to control access to specific parts of the network.
o アクセスControl--ルートフィルタ、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 データConfidentiality--実装されません。
o Auditing / Logging - Filter exceptions are logged.
o 監査/伐採--フィルタ例外は登録されます。
Kaeo Informational [Page 21] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[21ページ]のRFC4778OPSECは2007年1月に練習します。
o DoS Mitigation - Many DoS attacks are mitigated using a
combination of techniques including: MD5 authentication, the GTSM
feature, filtering routing advertisements to bogons, and filtering
routing advertisements to one's own network.
o DoS Mitigation--緩和されて、:多くのDoS攻撃が、テクニックの組み合わせを使用することで緩和されます。 MD5認証と、GTSMの特徴と、bogonsへのフィルタリングルーティング広告と、自分自身のネットワークにルーティング広告をフィルターにかけること。
2.4.4. Additional Considerations
2.4.4. 追加問題
So far the primary concern to secure the routing control plane has been to validate the sending peer and to ensure that the data in transit has not been altered. Although MD5 routing protocol extensions have been implemented, which can provide both services, they are not consistently deployed amongst ISPs. Two major deployment concerns have been implementation issues, where both software bugs and the lack of graceful re-keying options have caused significant network down times. Also, some ISPs express concern that deploying MD5 authentication will itself be a worse DoS attack victim and prefer to use a combination of other risk mitigation mechanisms such as GTSM (for BGP) and route filters. An issue with GTSM is that it is not supported on all devices across different vendors' products.
今までのところ、ルーティング制御飛行機を固定するプライマリ関心は、送付同輩を有効にして、トランジットにおけるデータが変更されていないのを保証することです。 MD5ルーティング・プロトコル拡張子(両方のサービスを提供できる)は実装されましたが、それらはISPの中で一貫して配布されません。 2の主要な展開、関心は導入問題です。(そこでは、ソフトウェアのバグと優雅な再の合わせるオプションの不足の両方が回の下側に重要なネットワークを引き起こしました)。 ISPは、また、或るものが、より悪いDoSが攻撃犠牲者であったならMD5認証がそうするのがそれ自体でその展開に関係があって、GTSMなどの他のリスク軽減メカニズム(BGPのための)とルートフィルタの組み合わせを使用するのを好むと言い表します。 GTSMの問題はそれが異なったベンダーの製品の向こう側にすべてのデバイスでサポートされないということです。
IPsec is not deployed since the operational management aspects of ensuring interoperability and reliable configurations is too complex and time consuming to be operationally viable. There is also limited concern to the confidentiality of the routing information. The integrity and validity of the updates are of much greater concern.
相互運用性と信頼できる構成を確実にする運営管理局面が複雑であって、操作上実行可能であるように思えないほど時間がかかっているので、IPsecは配布されません。 ルーティング情報の秘密性へのまた、限られた関心があります。 アップデートの保全と正当性ははるかにすごい関心のものです。
There is concern for manual or automated actions, which introduce new routes and can affect the entire routing domain.
関心が手動の、または、自動化された動きのためにあります、そして、全体の経路ドメインに影響できます。(動きは新しいルートを導入します)。
2.5. Software Upgrades and Configuration Integrity/Validation
2.5. ソフトウェアの更新と構成保全/合法化
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管理の一部が機能するとき、通常、ソフトウェアの更新と構成変更は実行されます。 しかしながら、考慮に入れられるべき追加問題があります。(問題はこのセクションで列挙されます)。
2.5.1. Threats/Attacks
2.5.1. 脅威/攻撃
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.
システムソフトと構成に実行された攻撃がともに受け身の、または、活発なソースからあることができます。 だれかがネットワークインフラデバイスとダウンロードされているシステムの間にデータを傍受する能力を持っているなら、受け身の攻撃が可能であるか、またはアップロードはソフトウェアか設定情報が可能です。 単一のインフラストラクチャデバイスがどうにか感染されて、ネットワーク障害解析ソフトウェアとして作動できるか、またはネットワーク障害解析ソフトウェアとして作動する新しいデバイスを挿入するのが可能であるなら、これを達成できます。
Kaeo Informational [Page 22] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[22ページ]のRFC4778OPSECは2007年1月に練習します。
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ネットワーク管理システムまでソフトウェアアップデートをダウンロードするとき、同様の問題が関連していることに注意してください。
2.5.1.1. Confidentiality Violations
2.5.1.1. 秘密性違反
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アドレスとパスワードを特定するようにうっかり導くことができる間、ソフトウェアイメージはデバイスが被害を受け易い功績のしるしを与えるかもしれません。
2.5.1.2. Offline Cryptographic Attacks
2.5.1.2. オフライン暗号の攻撃
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.
何か暗号のメカニズムがデータ保全と秘密性に備えるのに使用されるなら、オフライン暗号の攻撃は潜在的にデータに感染するかもしれないでしょうに。 トラフィックは、通信路を立ち聞きするか、またはトラフィックを悪意あるユーザーに紛らすことができることに捕らわれる必要があるでしょう。
2.5.1.3. Replay Attacks
2.5.1.3. 反射攻撃
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.
反射攻撃がうまくいっているために、ソフトウェアイメージか構成ファイルが、最初に後で意図している受取人に再演されるためにどちらのオンまた経路でもあるとキャプチャされるか、または攻撃者に紛らされる必要があるでしょう。 多くのプロトコルには反復操作による保護能力があるので、さらに、また、これらは適切な状況で打倒されなければならないでしょう。
2.5.1.4. Message Insertion/Deletion/Modification
2.5.1.4. メッセージ挿入/削除/変更
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
だれかが中間的ホストのコントロールでソフトウェアイメージと構成ファイルを操ることができます。 IPアドレスを偽造して、有効なそうすることができるホストをまねることによって、ソフトウェアのダウンロードイメージか構成ファイル、無効のファイルをインフラストラクチャデバイスにダウンロードできます。 また、これによるそれらに知られずにそうするかもしれない信じられたベンダーからのこの件が信じられたホストに感染したということであることができます。 イメージか構成ファイルがデバイスを引き起こす場合がある無効のソフトウェア
Kaeo Informational [Page 23] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[23ページ]のRFC4778OPSECは2007年1月に練習します。
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.
掛かってください、そして、手術不能になってください。 偽造している構成ファイルは検出するのが困難である場合があります、唯一の加えられたコマンドが特にそのデバイスに特定のホストアクセスを許して、認証のためのローカルのユーザ名/パスワードデータベースエントリーを構成するフィルタを入れることによってそのデバイスへの悪党のアクセスを許すことであるときに。
2.5.1.5. Man-In-The-Middle
2.5.1.5. マン・イン・ザ・ミドル
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.
介入者攻撃はデータ・ストリーム自体よりむしろ交信している同輩のアイデンティティを攻撃します。 攻撃者はシステムイメージか構成ファイルをアップロードするか、またはダウンロードするのに使用されるインフラストラクチャデバイスとホストの間に送られるトラフィックを妨害します。 そして、その人はこれらのシステムの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.
攻撃者が配布されるソフトウェアイメージのコピーを入手するなら、彼は、潜在的に知られている脆弱性を利用して、システムへのアクセスを得ることができるでしょうに。 捕らわれている構成ファイルから、彼は秘密のネットワーク形態情報、またはさらにダメージが大きい情報を得ることができました、構成ファイルのパスワードのいずれも暗号化されなかったなら。
2.5.2. Security Practices
2.5.2. セキュリティ実践
Images and configurations are stored on specific hosts that have limited access. All access and activity relating to these hosts are authenticated and logged via AAA services. When uploaded/downloading any system software or configuration files, either TFTP, FTP, or SCP can be used. Where possible, SCP is used to secure the data transfer and FTP is generally never used. All SCP access is username/password authenticated but since this requires an interactive shell, most ISPs will use shared key authentication to avoid the interactive shell. While TFTP access does not have any security measures, it is still widely used, especially in OOB management scenarios. Some ISPs implement IP-based restriction on the TFTP server, while some custom written TFTP servers will support MAC-based authentication. The MAC-based authentication is more common when using TFTP to bootstrap routers remotely.
イメージズと構成はアクセサリーを制限した特定のホストの上に保存されます。 これらのホストに関連するすべてのアクセスと活動が、AAAサービスで認証されて、登録されます。 どんなシステムソフトや構成ファイルもアップロードされるか、またはダウンロードするとき、TFTP、FTP、またはSCPを使用できます。 可能であるところでは、SCPがデータ転送を保証するのに使用されます、そして、一般に、FTPは決して使用されません。 すべてのSCPアクセスが認証されたユーザ名/パスワードですが、これが対話的なシェルを必要とするので、ほとんどのISPが対話的なシェルを避けるのに共有された主要な認証を使用するでしょう。 TFTPアクセスにはどんな安全策もない間、それは特にOOB管理シナリオでまだ広く使用されています。 いくつかのISPがTFTPサーバでIPベースの制限を実装しますが、TFTPサーバに書かれたいくらかの習慣がMACベースの認証をサポートするでしょう。 ルータを離れて独力で進むのにTFTPを使用するとき、MACベースの認証は、より一般的です。
In most environments, scripts are used for maintaining the images and configurations of a large number of routers. To ensure the integrity of the configurations, every hour the configuration files are polled and compared to the previously polled version to find discrepancies. In at least one environment these, tools are Kerberized to take advantage of automated authentication (not confidentiality). 'Rancid' is one popular publicly available tool for detecting configuration and system changes.
ほとんどの環境で、スクリプトは、多くのルータのイメージと構成を維持するのに使用されます。 構成の保全を確実にするなら、構成ファイルは、毎時間、食い違いを見つけるために以前に投票されたバージョンに、投票されて、たとえられます。 これらであり少なくとも1つの環境で、ツールはそうです。自動化された認証(秘密性でない)を利用するKerberized。 'いやなにおいのする'であることは、構成とシステム変更を検出するための1つのポピュラーな公的に利用可能なツールです。
Kaeo Informational [Page 24] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[24ページ]のRFC4778OPSECは2007年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.
ソフトウェアイメージはCyclic Redundancy Checks(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.
自動化されたセキュリティ合法化は、よく知られる攻撃の多くから有効な構成を守るのにNetwork Mapping(Nmap)とネッソスを使用することでインフラストラクチャデバイスに実行されます。
2.5.3. Security Services
2.5.3. セキュリティー・サービス
o User Authentication - All users are authenticated before being
able to download/upload any system images or configuration files.
o ユーザAuthentication--どんなシステムイメージや構成ファイルもダウンロードするか、またはアップロードできる前に、すべてのユーザが認証されます。
o User Authorization - All authenticated users are granted specific
privileges to download or upload system images and/or
configuration files.
o ユーザAuthorization--システムイメージ、そして/または、構成ファイルをダウンロードするか、またはアップロードするためにすべての認証されたユーザに特定の特権を与えます。
o Data Origin Authentication - Filters are used to limit access to
uploading/downloading configuration files and system images to
specific IP addresses.
o データOrigin Authentication--フィルタは、アップロード/ダウンロード構成ファイルへのアクセスとシステムイメージを特定の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 アクセスControl--フィルタは、アップロード/ダウンロード構成ファイルへのアクセスとシステムイメージを特定のIPアドレスとプロトコルに制限するのに使用されます。
o Data Integrity - All systems use either a CRC-check or MD5
authentication to ensure data integrity. Also, tools such as
rancid are used to automatically detect configuration changes.
o データの保全--すべてのシステムが、データ保全を確実にするのにCRC-チェックかMD5認証のどちらかを使用します。 また、ツールは、自動的に構成変更を検出するのにいやなにおいのするように使用されます。
Kaeo Informational [Page 25] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[25ページ]のRFC4778OPSECは2007年1月に練習します。
o Data Confidentiality - If the SCP protocol is used then there is
confidentiality of the downloaded/uploaded configuration files and
system images.
o データConfidentiality--SCPプロトコルが使用されているなら、ダウンロードされたかアップロードされた構成ファイルとシステムイメージの秘密性があります。
o Auditing/Logging - All access and activity relating to
downloading/uploading system images and configuration files are
logged via AAA services and filter exception rules.
o 監査/伐採--ダウンロード/アップロードシステムイメージと構成ファイルに関連するすべてのアクセスと活動がAAAサービスとフィルタ例外の原則で登録されます。
o DoS Mitigation - A combination of filtering and CRC-check/
MD5-based integrity checks are used to mitigate the risks of DoS
attacks. If the software updates and configuration changes are
performed via an OOB management system, this is also added
protection.
o DoS Mitigation--MD5フィルタリングとCRC-チェック/ベースの保全チェックの組み合わせは、DoS攻撃の危険を緩和するのに使用されます。 ソフトウェアアップデートと構成変更がOOBマネージメントシステムで実行されるなら、これはまた、加えられた保護です。
2.5.4. Additional Considerations
2.5.4. 追加問題
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は厄介過ぎて、データ保全と秘密性に使用するのが操作上難しいと考えられます。
2.6. Logging Considerations
2.6. 伐採問題
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.
伐採はすべての前項の一部ですが、それは別々の項目としてカバーできるくらい重要です。 本題は登録されるものを中心題目とします、そして、ログはどれくらい長い間、保たれるか、そして、どんなメカニズムが、それがトランジット中であり、保存されている間、登録された情報を保証するのに使用されますか?
2.6.1. Threats/Attacks
2.6.1. 脅威/攻撃
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.
両方のオン経路とオフ経路シナリオに、活発な攻撃は可能です。 経路に対する活発な攻撃に、状況は受け身の攻撃のように同じです、デバイスが既に感染されなければならない、さもなければ、デバイスを経路に挿入できるところで。 一般に、オフ経路の活発な攻撃において、攻撃はどんな感染も検出されるのを妨げるか、または刑事訴追に使用できたどんな証拠も無効にするために登録されたデータを変更できるメッセージ挿入か変更に制限されます。
Kaeo Informational [Page 26] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[26ページ]のRFC4778OPSECは2007年1月に練習します。
2.6.1.1. Confidentiality Violations
2.6.1.1. 秘密性違反
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.
悪党がネットワークでトランジット中であることの伐採データのどれかを妨害するとき、秘密性違反は起こることができます。 いくつかの登録されたデータが登録されたデータに含まれるためにはプライバシーの違反であるかもしれないどんなデータも禁じるために殺菌されていないなら、これはプライバシー違反に通じるかもしれません。
2.6.1.2. Offline Cryptographic Attacks
2.6.1.2. オフライン暗号の攻撃
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.
何か暗号のメカニズムがデータ保全と秘密性に備えるのに使用されるなら、オフライン暗号の攻撃は潜在的にデータに感染するかもしれないでしょうに。 トラフィックは、ネットワークを立ち聞きするか、またはトラフィックを悪意あるユーザーに紛らすことができることに捕らわれる必要があるでしょう。
2.6.1.3. Replay Attacks
2.6.1.3. 反射攻撃
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.
反射攻撃がうまくいっているために、伐採データは、最初にどちらのオンまた経路でもあるとキャプチャされるか、攻撃者に紛らされて、または後で受取人に再演される必要があるでしょう。
2.6.1.4. Message Insertion/Deletion/Modification
2.6.1.4. メッセージ挿入/削除/変更
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アドレスから伐採データを注入できます。
2.6.1.5. Man-In-The-Middle
2.6.1.5. マン・イン・ザ・ミドル
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.
介入者攻撃はデータ・ストリーム自体よりむしろ交信している同輩のアイデンティティを攻撃します。 攻撃者はインフラストラクチャデバイスと伐採サーバの間に送られるトラフィックか伐採サーバと登録されたデータを格納するのに使用されるデータベースの間に送られたトラフィックを妨害します。 伐採情報へのどんな不正アクセスも個人的で独占であるネットワーク形態情報に関する知識につながるかもしれません。(ネットワークの一部に感染するのに情報を使用できました)。 追加関心は伐採情報に近づく手段を持っています。(機密保護違反のどんな跡もカバーするようにそれを削除したか、または変更できました)。
2.6.2. Security Practices
2.6.2. セキュリティ実践
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
フィルターにかけることとなると、伐採は例外の監査ベースにほとんど実行されます(すなわち、許容されていないトラフィックは登録されます)。 これは、伐採サーバがデータで圧倒されないことを保証するためのものです。(データはほとんどのログを使用不可能に表すでしょう)。 通常、登録されたデータはソースと目的地IPを含むでしょう。
Kaeo Informational [Page 27] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[27ページ]のRFC4778OPSECは2007年1月に練習します。
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.)
アドレスと層4はタイムスタンプと同様に数を移植します。 syslogプロトコルは、syslogサーバへのインフラストラクチャデバイスの間に登録されたデータを移すのに使用されます。多くのISPが、syslogサーバとデバイスの間で実行されたセキュリティが全く実際にはないので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.
NTPからタイムスタンプを得ます。(一般に、NTPは、より少ない構成と、より少ないメインテナンスを持つために平坦な階層構造としてstratum1とstratum2で構成されます)。 構成と冗長の一貫性はプライマリ目標です。 各ルータはいくつかのstratum1サーバソースによって構成されます、異なったネットワーク供給停止の場合さえ。(ソースは、適切な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.
一般に、どこでも10分毎から毎時間まであることができるセット間隔で、データベースに様々なsyslogサーバデバイスからのログを移します。 1つのISPがデータベースにデータを押し込むのにRsyncを使用します、そして、次に、情報はSSH'ingのだれかによって手動でそのデータベースに分類されます。
Kaeo Informational [Page 28] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[28ページ]のRFC4778OPSECは2007年1月に練習します。
2.6.3. Security Services
2.6.3. セキュリティー・サービス
o User Authentication - Not applicable.
o ユーザAuthentication--適切ではありません。
o User Authorization - Not applicable.
o ユーザAuthorization--適切ではありません。
o Data Origin Authentication - Not implemented.
o データOrigin Authentication--実装されません。
o Access Control - Filtering on logging host and server IP address
to ensure that syslog information only goes to specific syslog
hosts.
o アクセスControl--ホストと確実にするサーバIPアドレスを登録するときそのsyslog情報をフィルターにかけるだけが特定のsyslogホストのものになります。
o Data Integrity - Not implemented.
o データの保全--実装されません。
o Data Confidentiality - Not implemented.
o データConfidentiality--実装されません。
o Auditing/Logging - This entire section deals with logging.
o 監査/伐採--この全体のセクションは伐採に対処します。
o DoS Mitigation - An OOB management system is used and sometimes
different syslog servers are used for logging information from
varying equipment. Exception logging tries to keep information to
a minimum.
o DoS Mitigation--OOBマネージメントシステムは使用されていて、時々異なったsyslogサーバは異なった設備からの伐採情報に使用されます。 例外伐採は情報を最小に抑えようとします。
2.6.4. Additional Considerations
2.6.4. 追加問題
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以上のための要件を言い表しました。 さらに、彼らは、より粒状の、そして、フレキシブルな施設とプライオリティ、すなわち、特定のログが特定のサーバに欲しいです。 また、したがって、標準のイベントがそんなに変更していると報告して、それぞれ後のパーサがベンダーデバイスかソフトウェアをアップグレードさせるので、一般的な形式も必要ではありません。
2.7. Filtering Considerations
2.7. 問題をフィルターにかけます。
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つの特定の領域に分類されています: データ飛行機、管理飛行機、およびルーティングは飛行機を制御します。
Kaeo Informational [Page 29] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[29ページ]のRFC4778OPSECは2007年1月に練習します。
2.7.1. Data Plane Filtering
2.7.1. データ飛行機フィルタリング
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ガイドラインであると偽造する緩和する顧客の面しているエッジデバイスでこれらの種類のフィルタを配布します。
2.7.2. Management Plane Filtering
2.7.2. 管理飛行機フィルタリング
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フィルタリングのための良いガイドラインはFiltering ICMPv6 MessagesのためにFirewalls[ICMPv6]にRecommendationsにあります。
2.7.3. Routing Control Plane Filtering
2.7.3. ルート設定コントロール飛行機フィルタリング
Routing filters are used to control the flow of routing information. In IPv6 networks, some providers are liberal in accepting /48s due to the still unresolved multihoming issues, while others filter at allocation boundaries, which are typically at /32. Any announcement received that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing is filtered out of eBGP. Note that this is for non-customer traffic. Most ISPs will accept any agreed upon prefix length from its customer(s).
ルート設定フィルタは、ルーティング情報の流れを制御するのに使用されます。 IPv6ネットワークでは、いくつかのプロバイダーがまだ未定のマルチホーミング問題のために48受諾/年代で寛容です、配分境界(通常/32にある)の他のものフィルタである間。 受けられたIPv6ルーティングのための/48と/24より長い間IPv4ルーティングのためのものであるどんな発表もeBGPからフィルターにかけられます。 これが非顧客トラフィックのためのものであることに注意してください。 ほとんどのISPが、いずれも接頭語の長さで顧客から同意されていると受け入れるでしょう。
2.8. Denial-of-Service Tracking/Tracing
2.8. サービス妨害の追跡/たどること
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
サービス不能攻撃は、絶えず増加する問題であり、有効に戦うために広大な量のリソースを必要とします。 いくつかの大きいISPは帯域幅で1G以下である攻撃ストリームに携わりません--1Gが本質的には少ないより大きいパイプの上にこれはあります。
Kaeo Informational [Page 30] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[30ページ]のRFC4778OPSECは2007年1月に練習します。
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.
提供された負荷の5%より。 これは主に多量のDoSトラフィックのためです。(それは、絶えず調査と緩和を必要とします)。 最後のカウントでは、大きい分配されたDoS botnetsを作るホストの数は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、レート制限、および特定のコントロール空輸増進の引き金となりました。 それぞれのこれらのテクニックは以下で詳細になるでしょう。
2.8.1. Sinkhole Routing
2.8.1. 下水落し口ルート設定
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.
下水落し口ルーティングはどんな知られている攻撃トラフィックのためにもより特定のルートを注入するのを示します。(トラフィックは、悪意があるトラフィックがそれを分析できる有効なデバイスか特定のシステムに向け直されるのを確実にするでしょう)。
2.8.2. Black Hole Triggered Routing
2.8.2. ブラックホールの引き起こされたルート設定
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).
ブラックホールの引き起こされたルーティング(また、Remote Triggered Black Hole Filteringと呼ばれる)はBGPルーティング・プロトコルがルートを伝播するのに使用されるテクニックです(順番に事実上、それが下げられるヌルインタフェースに攻撃トラフィックを向け直します)。 BGPが速くて、効果的な方法による情報を伝播できるので、このテクニックは大きいルーティングインフラストラクチャにしばしば使用されます、数百か何千ものルータに関するどんなパケットベースのフィルター技術も使用することと対照的に(より完全な記述 http://www.nanog.org/mtg-0402/pdf/morrow.pdf について以下のNANOGプレゼンテーションを参照してください)。
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.
この黒を掘るテクニックが目標が現れた黒を掘るトラフィックが、ある一定のサイトから来るのを唆すことであったなら実際に攻撃者の目標を実現させるかもしれないことに注意してください。 他方では、このブラックホールのテクニックは重要なサービス以外の何かが目的とされたひどく大きい攻撃で引き起こされた巻き添え被害を下げることができます。
2.8.3. Unicast Reverse Path Forwarding
2.8.3. ユニキャスト逆経路推進
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
入って来るパケットに正統のソースアドレスがあるか否かに関係なく、ユニキャストReverse Path Forwarding(uRPF)は有効にするメカニズムです。 それには、2つのモードがあります: 厳しいモードとゆるいモード。 厳しいモードで、uRPFは、入って来るパケットが経路指定テーブルに接頭語に合っているソースアドレスを持つかどうかと、インタフェースが、このソースアドレス接頭語でパケットを受けると予想するかどうかチェックします。 入って来るパケットがユニキャストRPFチェックに失敗するなら、パケットはオンであると受け入れられません。
Kaeo Informational [Page 31] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[31ページ]のRFC4778OPSECは2007年1月に練習します。
incoming interface. Loose mode uRPF is not as specific and the incoming packet is accepted if there is any route in the routing table for the source address.
入って来るインタフェース。 ゆるいモードuRPFは特定ではありません、そして、何かルートがソースアドレスのための経路指定テーブルにあれば、入って来るパケットを受け入れます。
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.
すなわち、非対称、パケットの源への複数のルートが、実行可能経路の厳しいuRPFを適用するのをどう排除しないかをBCP84[RFC3704]とuRPF経験に関する研究[BCP84-URPF]が詳しく述べている間、一般に、それはルーティング非対称を持ちそうなインタフェースで使用されません。 通常、より大きいISPにおいて、uRPFはネットワークの顧客縁に置かれます。
2.8.4. Rate Limiting
2.8.4. レート制限
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.
レート制限は特定のトラフィックタイプへの特定の量の1秒あたりの帯域幅かパケットを割り当てるのを示します。 このテクニックはTCP-SYN攻撃などのよく知られるプロトコル攻撃を緩和するのに広く使用されます、偽造しているTCPトラフィックのために多くのリソースを割り当てるところで。 このテクニックは攻撃を止めませんが、それは特定のサービスのときに時々損害と影響を少なくすることができます。 しかしながら、それで、また、DoS攻撃の影響はレート制限が影響を与えること(すなわち、捨てる)の、より正統のトラフィックであるならはるかに悪くなる場合があります。
2.8.5. Specific Control Plane Traffic Enhancements
2.8.5. 特定のコントロール空輸増進
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攻撃は他のタイプのトラフィックより重要なデバイスにはるかにダメージが大きい場合があります。 この能力のどんな一貫した展開もこの書くこと時点で、見つけられませんでした。
3. Security Considerations
3. セキュリティ問題
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環境における現在のセキュリティ実践に対処します。 それは今日の環境にそういうものとして使用される特定の習慣を記載して、少しのセキュリティリスクも本来引き起こされません。
4. Acknowledgments
4. 承認
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、ライアンMcdowell、Gaurab Upadhaya、ウォレンKumari、ペッカSavola、フェルナンドGont、クリス・モロー、テッド・シーリ、ドナルド・スミス、および本書では表現される情報を提供した多数のISPオペレータからの洞察に満ちたコメント。(ジョーンズは、このドキュメントのための指導を提供して、方向で手段になっています)。
Kaeo Informational [Page 32] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[32ページ]のRFC4778OPSECは2007年1月に練習します。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[RFC2828]Shirey(R.、「インターネットセキュリティ用語集」、RFC2828)は2000がそうするかもしれません。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[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)」、RFC3682 2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004.
[RFC3882] トルコ人、D.、「サービス不能攻撃を妨げるためにBGPを構成します」、RFC3882、2004年9月。
5.2. Informational References
5.2. 情報の参照
[BCP84-URPF] Savola, P., "Experiences from Using Unicast RPF", Work
in Progress, November 2006.
P.、「ユニキャストRPFを使用するのからの経験」という[BCP84-URPF]Savolaは進歩、2006年11月に働いています。
[ICMPv6] Davies, E. and J. Mohacsi, "Recommendations for
Filtering ICMPv6 Messages in Firewalls", Work
in Progress, July 2006.
[ICMPv6] 「ファイアウォールでICMPv6メッセージをフィルターにかけるための推薦」というデイヴィース、E.、およびJ.Mohacsiは進歩、2006年7月に働いています。
[RTGWG] Savola, P., "Backbone Infrastructure Attacks and
Protections", Work in Progress, July 2006.
P.と、「バックボーンインフラストラクチャ攻撃と保護」という[RTGWG]Savolaは進歩、2006年7月に働いています。
Kaeo Informational [Page 33] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[33ページ]のRFC4778OPSECは2007年1月に練習します。
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
o ARP氾濫
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 Addresses(ソースか目的地のどちらか)を偽造することができます(順番に確立したフィルタリング規則を回避できます)。
o IP Source Route Option can allows attackers to establish stealth
TCP connections.
o IP Source Route Option缶で、攻撃者はこっそりTCP接続を確立できます。
o IP Record Route Option can disclose information about the topology
of the network.
o IP Record Route Optionはネットワークのトポロジーに関して情報を開示できます。
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 Timestamp Optionはネットワークの振舞いについて明察するのに使用できる情報を漏らすことができます。
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分野(または、Differentiated Services(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分野を使用できます。
Kaeo Informational [Page 34] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[34ページ]のRFC4778OPSECは2007年1月に練習します。
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
o IGMPの特大のパケット
o ICMP Source Quench
o ICMPソース焼き入れ
o ICMP Mask Request
o ICMPマスク要求
o ICMP Large Packet (> 1472)
o ICMPの大きいパケット(>1472)
o ICMP Oversized packet (>65536)
o ICMP Oversizedパケット(>65536)
o ICMP Flood
o ICMP洪水
o ICMP Broadcast w/ Spoofed Source (Smurf Attack)
o 偽造しているソースと共に放送されたICMP(スマーフ攻撃)
o ICMP Error Packet Flood
o ICMP誤りパケット洪水
o ICMP Spoofed Unreachable
o ICMPがだました、手の届かなさ
o TCP Packet without Flag
o 旗のないTCPパケット
o TCP Oversized Packet
o TCPの特大のパケット
o TCP FIN bit with no ACK bit
o ACKなしで噛み付かれたTCP FINは噛み付きました。
o TCP Packet with URG/OOB flag (Nuke Attack)
o URG/OOBとTCP Packetは弛みます。(核兵器攻撃)
o SYN Fragments
o SYN断片
o SYN Flood
o SYN洪水
o SYN with IP Spoofing (Land Attack)
o IPがだまされているSYN(陸の攻撃)
o SYN and FIN bits set
o 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攻撃(ペプシの攻撃)
Kaeo Informational [Page 35] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[35ページ]のRFC4778OPSECは2007年1月に練習します。
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).
どんな断片化と放送トラフィックを除いても、IPv6ネットワークに上記のIPv4攻撃のどれかを使用できました。(それは、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によって可能にされたホストは使用され始めています。(事実上、ファイアウォールとネットワーク流れ収集ツールがこのトラフィックを検出できないなら、トンネルはbotnetと他の悪意があるトラフィックを隠すことができます)。 IPv6インフラストラクチャを保護するのに使用される安全策はIPv4ネットワークにもかかわらず、IPv6ネットワーク操作のための追加問題で同じであるべきです。(操作はIPv4と異なっているかもしれません)。
Author's Address
作者のアドレス
Merike Kaeo Double Shot Security, Inc. 3518 Fremont Avenue North #363 Seattle, WA 98103 U.S.A.
Merike Kaeoの二重ショットセキュリティInc.3518フレモントAvenue北部#363ワシントン98103シアトル(米国)
Phone: +1 310 866 0165 EMail: merike@doubleshotsecurity.com
以下に電話をしてください。 +1 0165年の310 866メール: merike@doubleshotsecurity.com
Kaeo Informational [Page 36] RFC 4778 OPSEC Practices January 2007
Kaeoの情報[36ページ]のRFC4778OPSECは2007年1月に練習します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Kaeo Informational [Page 37]
Kaeo情報です。[37ページ]
一覧
スポンサーリンク
