シンプルネットワーク管理プロトコル

SNMPv3 STD0062
通信プロトコル
OSI層応用
ポート161、162（トラップ）
RFC(s)3411–3418
セキュアSNMP
通信プロトコル
OSI層応用
ポート10161、10162（トラップ）
RFC(s)6353

簡易ネットワーク管理プロトコル（SNMP）は、IPネットワーク上の管理対象デバイスに関する情報を収集・整理し、その情報を変更してデバイスの動作を変更するためのインターネット標準プロトコルです。SNMPをサポートするデバイスには、ケーブルモデム、ルーター、ネットワークスイッチ、サーバー、ワークステーション、プリンターなどがあります。[ 1 ]

SNMPは、ネットワーク管理におけるネットワーク監視に広く利用されています。SNMPは、管理対象システム上の管理データを変数の形で公開します。これらの変数は、システムの状態と構成を記述する管理情報ベース（MIB）に編成されています。これらの変数は、管理アプリケーションによってリモートから照会（場合によっては操作）できます。

SNMPには3つの主要なバージョンが開発・導入されています。SNMPv1はプロトコルのオリジナルバージョンです。より新しいバージョンであるSNMPv2cとSNMPv3では、パフォーマンス、柔軟性、セキュリティが向上しています。

SNMPは、インターネット技術特別調査委員会（IETF）によって定義されたインターネットプロトコルスイートの構成要素です。SNMPは、アプリケーション層プロトコル、データベーススキーマ、およびデータオブジェクトセットを含む、ネットワーク管理のための一連の標準規格で構成されています。[ 2 ]

概要と基本概念

SNMP通信の原理

SNMPの典型的な用途では、マネージャと呼ばれる1台以上の管理コンピュータが、コンピュータネットワーク上のホストまたはデバイスのグループを監視または管理する役割を担います。管理対象システムごとに、エージェントと呼ばれるソフトウェアコンポーネントが実行され、SNMPを介してマネージャに情報が報告されます。

SNMP 管理ネットワークは、次の 3 つの主要コンポーネントで構成されます。

管理対象デバイスとは、ノード固有の情報への単方向（読み取り専用）または双方向（読み取りと書き込み）アクセスを可能にするSNMPインターフェースを実装したネットワークノードです。管理対象デバイスは、NMSとノード固有の情報を交換します。管理対象デバイスはネットワーク要素と呼ばれることもあり、ルーター、アクセスサーバー、スイッチ、ケーブルモデム、ブリッジ、ハブ、IP電話、IPビデオカメラ、コンピュータホスト、プリンターなど、あらゆる種類のデバイスが対象となります。

エージェントは、管理対象デバイスに常駐するネットワーク管理ソフトウェアモジュールです。エージェントは管理情報に関するローカルな知識を持ち、その情報をSNMP固有の形式に変換したり、SNMP固有の形式からSNMP固有の形式に変換したりします。

ネットワーク管理ステーションは、管理対象デバイスを監視および制御するアプリケーションを実行します。NMSは、ネットワーク管理に必要な処理およびメモリリソースの大部分を提供します。管理対象ネットワークには、1つまたは複数のNMSが存在する場合があります。

管理情報ベース

SNMP エージェントは、管理対象システムの管理データを変数として公開します。このプロトコルでは、これらの変数をリモートで変更することで、構成の変更などのアクティブな管理タスクも許可します。SNMP 経由でアクセスできる変数は、階層構造になっています。SNMP 自体は、管理対象システムが提供すべき変数を定義しません。その代わりに、SNMP は、アプリケーションが独自の階層を定義できる拡張可能な設計を採用しています。これらの階層は、管理情報ベース(MIB) として記述されます。MIB は、デバイス サブシステムの管理データの構造を記述し、オブジェクト識別子(OID)を含む階層型の名前空間を使用します。各 OID は、SNMP 経由で読み取りまたは設定できる変数を識別します。MIB は、 ASN.1のサブセットであるStructure of Management Information Version 2.0 (SMIv2、RFC 2578 )で定義された表記法を使用します。  

プロトコルの詳細

SNMPはインターネットプロトコルスイートのアプリケーション層で動作します。すべてのSNMPメッセージはユーザーデータグラムプロトコル（UDP）を介して転送されます。SNMPエージェントはUDPポート161でリクエストを受信します。マネージャは、利用可能な任意の送信元ポートからエージェントのポート161にリクエストを送信できます。エージェントの応答はマネージャの送信元ポートに返されます。マネージャはポート162で通知（トラップとインフォームリクエスト）を受信します。エージェントは利用可能な任意のポートから通知を生成できます。トランスポート層セキュリティまたはデータグラムトランスポート層セキュリティと併用する場合、リクエストはポート10161で受信され、通知はポート10162に送信されます。[ 3 ]

SNMPv1では、5つのコアプロトコルデータユニット（PDU）が規定されています。SNMPv2ではGetBulkRequestとInformRequestという2つのPDUが追加され、 SNMPv3ではReport PDUが追加されました。すべてのSNMP PDUは以下のように構成されます。

IPヘッダー UDPヘッダー バージョン コミュニティ PDUタイプ リクエストID エラーステータス エラーインデックス 変数バインディング

PDU タイプフィールドによって識別される 7 つの SNMP PDU タイプは次のとおりです。

リクエストの取得
マネージャーからエージェントへの、変数または変数リストの値を取得するためのリクエストです。取得する変数は変数バインディングで指定します（値フィールドは使用されません）。指定された変数値の取得は、エージェントによってアトミック操作として実行されます。現在の値を含むレスポンスが返されます。
リクエストの設定
変数または変数リストの値を変更するための、マネージャーからエージェントへのリクエスト。変数バインディングはリクエスト本体で指定されます。指定されたすべての変数への変更は、エージェントによってアトミック操作として実行されます。[ 4 ]変数の（現在の）新しい値を含むレスポンスが返されます。
次リクエストを取得
利用可能な変数とその値を検出するための、マネージャーからエージェントへのリクエストです。MIB内で辞書式順序で次の変数への変数バインディングを含むレスポンスを返します。エージェントのMIB全体は、 OID 0からGetNextRequestを繰り返し適用することで参照できます。リクエストの変数バインディングで列OIDを指定することにより、テーブルの行を読み取ることができます。
一括リクエストの取得
GetNextRequestの複数回の反復を要求するマネージャーからエージェントへのリクエスト。GetNextRequest の最適化バージョンです。リクエスト内の変数バインディングから複数の変数バインディングを抽出し、レスポンスを返します。PDU固有の非リピーターおよび最大反復フィールドは、レスポンスの動作を制御するために使用されます。GetBulkRequestはSNMPv2で導入されました。
応答
GetRequest、SetRequest、GetNextRequest、GetBulkRequest、InformRequestに対する変数バインディングとエージェントからマネージャへの確認応答を返します。エラー報告はerror-status フィールドとerror-indexフィールドによって提供されます。このPDUはgetとsetの両方への応答として使用されていましたが、SNMPv1ではGetResponseと呼ばれていました。
トラップ
エージェントからマネージャへの非同期通知。他のSNMP通信ではマネージャがエージェントに情報を要求しますが、これらのPDUは明示的に要求されることなくエージェントからマネージャに送信されます。SNMPトラップを使用すると、エージェントは非請求SNMPメッセージを介して管理ステーションに重要なイベントを通知できます。トラップPDUには、現在のsysUpTime値、トラップの種類を識別するOID、およびオプションの変数バインディングが含まれます。トラップの宛先アドレスは、通常、MIB内のトラップ設定変数を通じて、アプリケーション固有の方法で決定されます。SNMPv2ではトラップメッセージの形式が変更され、PDUの名前がSNMPv2-Trapに変更されました。
通知リクエスト
確認応答付き非同期通知。このPDUはSNMPv2で導入され、当初はマネージャ間通信として定義されていました。[ 5 ]その後の実装では、エージェントとマネージャ間の通信も可能になるように元の定義が緩和されました。 [ 6 ] [ 7 ] [ 8 ]マネージャ間通知はSNMPv1でもトラップを用いて可能でしたが、SNMPはUDP上で実行されることが多く、UDPでは配信が保証されず、パケットのドロップも報告されないため、トラップの配信は保証されませんでした。InformRequestは、受信時に確認応答を返すことでこの問題を解決しました。[ 7 ]

RFC  1157では、SNMP実装は少なくとも484バイトの長さのメッセージを受け入れなければならないと規定されています。実際には、SNMP実装はそれよりも長いメッセージを受け入れます。[ 9 ]：1870 正しく実装されていれば、メッセージのデコードに失敗した場合、SNMPメッセージは破棄され、不正なSNMP要求は無視されます。デコードに成功したSNMP要求は、コミュニティ文字列を用いて認証されます。認証に失敗した場合、認証失敗を示すトラップが生成され、メッセージは破棄されます。[ 9 ]：1871

SNMPv1およびSNMPv2cは、マネージャとエージェント間の信頼関係を確立するためにコミュニティを使用します。ほとんどのエージェントは、読み取り専用、読み取り書き込み、トラップのそれぞれに対応する3つのコミュニティ名をサポートしています。これらの3つのコミュニティ文字列は、異なる種類のアクティビティを制御します。読み取り専用コミュニティはGETリクエストに適用されます。読み取り書き込みコミュニティ文字列はSETリクエストに適用されます。トラップコミュニティ文字列はトラップの受信に適用されます。SNMPv3もコミュニティ文字列を使用しますが、SNMPマネージャとエージェント間の安全な認証と通信を可能にします。[ 10 ]

プロトコルバージョン

実際には、SNMPの実装では複数のバージョンがサポートされていることが多く、通常はSNMPv1、SNMPv2c、SNMPv3です。[ 11 ] [ 12 ]

バージョン1

SNMPバージョン1（SNMPv1）は、SNMPプロトコルの初期実装です。SNMPv1の設計は1980年代に、OSI/IETF/NSF（全米科学財団）が公式に支援していたHEMS/CMIS/CMIP（HEMS/CMIS/CMIP）の取り組みが、当時のコンピュータプラットフォームでは実装不可能であり、また潜在的に機能しないと判断した協力者グループによって行われました。SNMPは、インターネットの大規模展開と商用化に向けたステップを踏むために必要な暫定的なプロトコルであるという信念に基づいて承認されました。

現在 SNMPv1 として知られている SNMP の 最初のRequest for Comments (RFC) は 1988 年に登場しました。

  • RFC  1065  — TCP/IPベースのインターネットにおける管理情報の構造と識別
  • RFC  1066  — TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース
  • RFC  1067  — シンプルなネットワーク管理プロトコル

1990 年に、これらの文書は次の文書に置き換えられました。

  • RFC  1155  — TCP/IPベースのインターネットにおける管理情報の構造と識別
  • RFC  1156  — TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース
  • RFC  1157  — シンプルなネットワーク管理プロトコル

1991 年に、RFC 1156 (MIB-1) は、より頻繁に使用される次のものに置き換えられました。  

  • RFC  1213  — TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース（MIB-2）のバージョン2

SNMPv1は広く使用されており、インターネットコミュニティにおける事実上のネットワーク管理プロトコルとなっている。 [ 13 ]

SNMPv1 は、ユーザー データグラム プロトコル (UDP)、OSIコネクションレス モード ネットワーク サービス(CLNS)、AppleTalkデータグラム配信プロトコル(DDP)、Novellインターネットワーク パケット交換(IPX) などのトランスポート層プロトコルによって伝送される場合があります。

バージョン1は、セキュリティの低さが批判されてきた。[ 14 ]仕様では、実際にはカスタム認証を使用する余地が認められているが、広く使用されている実装では、「すべてのSNMPメッセージを本物のSNMPメッセージとして識別する単純な認証サービスしかサポートされていない」。[ 15 ]そのため、メッセージのセキュリティは、メッセージが送信されるチャネルのセキュリティに依存することになる。例えば、ある組織では、内部ネットワークは十分に安全であるため、SNMPメッセージには暗号化は不要であると考えている場合がある。このような場合、元の仕様に反して、平文で送信されるコミュニティ名は、事実上のパスワードと見なされる傾向がある。

バージョン2

RFC 1441およびRFC 1452で定義されているSNMPv2は、バージョン1を改訂したもので、パフォーマンス、セキュリティ、およびマネージャ間通信の分野で改善が図られています。大量の管理データを単一のリクエストで取得するための反復的なGetNextRequestsの代替として、 GetBulkRequestが導入されました。SNMPv2で導入された新しいパーティベースのセキュリティシステムは、多くの人から複雑すぎると思われ、広く採用されませんでした。[ 14 ] このバージョンのSNMPはProposed Standardレベルの成熟度に達しましたが、後のバージョンでは廃止されたとみなされました。[ 16 ]  

コミュニティベースの簡易ネットワーク管理プロトコルバージョン2（SNMPv2c ）は、 RFC 1901 – RFC 1908で定義されています。SNMPv2cは、議論の的となった新しいSNMP v2セキュリティモデルを除いたSNMPv2をベースとし、代わりにSNMPv1のシンプルなコミュニティベースのセキュリティスキームを採用しています。このバージョンは、IETFのドラフト標準の成熟度レベルを満たした比較的数少ない標準の1つであり、事実上のSNMPv2標準と広く考えられていました。[ 16 ] 後にSNMPv3の一部として再定義されました。[ 17 ]  

ユーザーベースの簡易ネットワーク管理プロトコルバージョン2（SNMPv2u ）は、 RFC 1909 – RFC 1910で定義されています。これは、SNMPv1よりも高いセキュリティを提供しながら、SNMPv2のような高度な複雑さを回避しようとする妥協案です。この派生版はSNMP v2*として商用化され、最終的にSNMP v3の2つのセキュリティフレームワークの1つとして採用されました。[ 18 ]  

64ビットカウンター

SNMPバージョン2では、64ビットデータカウンタのオプションが導入されました。バージョン1は、0から42億9千万（正確には4 294 967 295）。32ビットバージョン1のカウンタは、10ギガビット以上のインターフェースの最大速度（ビット/秒単位）を保存できません。同様に、10ギガビット以上のインターフェースの統計情報を追跡する32ビットカウンタは、1分未満で再びゼロに戻る可能性があります。これは、カウンタが現在の状態を読み取るためにポーリングされる時間間隔よりも短い場合があります。その結果、検出されない値のロールオーバーやトレンド追跡データの破損により、データが失われたり無効になったりする可能性があります。

64ビットバージョン2のカウンタは、0から18.4京（正確には18,446,744,073,709,551,615）までの値を格納できるため、現時点ではポーリングイベント間でカウンタのロールオーバーが発生する可能性は低いと考えられます。例えば、1.6テラビットのイーサネットは2025年までに利用可能になると予測されています。1.6兆ビット/秒の速度でインクリメントする64ビットカウンタであれば、このようなインターフェースの情報を133日間ロールオーバーすることなく保持できます。

SNMPv1とSNMPv2cの相互運用性

SNMPv2cは、メッセージ形式とプロトコル操作という2つの主要な領域においてSNMPv1と互換性がありません。SNMPv2cメッセージは、SNMPv1メッセージとは異なるヘッダーとプロトコルデータユニット（PDU）形式を使用します。また、SNMPv2cはSNMPv1では規定されていない2つのプロトコル操作を使用します。この非互換性を克服するために、RFC 3584では、プロキシエージェントとバイリンガルネットワーク管理システムという2つのSNMPv1/v2c共存戦略が定義されています。  

プロキシエージェント

SNMPv2エージェントは、SNMPv1管理対象デバイスの代わりにプロキシエージェントとして動作できます。SNMPv2 NMSがSNMPv1エージェント宛てのコマンドを発行すると、そのコマンドはSNMPv2プロキシエージェントに送信されます。プロキシエージェントはGet、、、GetNextおよびSetメッセージをそのままSNMPv1エージェントに転送します。GetBulkメッセージはプロキシエージェントによってGetNextメッセージに変換され、SNMPv1エージェントに転送されます。さらに、プロキシエージェントはSNMPv1トラップメッセージを受信して​​SNMPv2トラップメッセージにマッピングし、NMSに転送します。

バイリンガルネットワーク管理システム

バイリンガルSNMPv2ネットワーク管理システムは、SNMPv1とSNMPv2の両方をサポートします。このデュアル管理環境をサポートするために、管理アプリケーションはローカルデータベースに保存されている情報を調べ、エージェントがSNMPv1とSNMPv2のどちらをサポートしているかを判断します。NMSはデータベースの情報に基づいて、適切なバージョンのSNMPを使用してエージェントと通信します。

バージョン3

SNMPv3は暗号化セキュリティの追加以外にプロトコル自体には変更を加えていないものの、新しいテキスト表記、概念、用語が導入されているため、見た目は大きく異なっています。[ 1 ]最も目立った変更点は、SNMPにセキュリティとリモート設定の拡張機能を追加することで、SNMPのセキュアバージョンを定義したことです。[ 19 ]セキュリティ面では、強力な認証とプライバシー保護のためのデータ暗号化の両方を提供することで対応しています。管理面では、SNMPv3は通知発信元とプロキシ転送という2つの部分に重点を置いています。これらの変更により、SNMPエンティティのリモート設定と管理が容易になり、大規模導入、アカウンティング、障害管理に関する問題にも対処しています。

含まれる機能と拡張機能:

  • 既知のSNMPエンティティ間の通信を容易にするためのSNMPエンティティの識別 – 各SNMPエンティティにはSNMPEngineIDと呼ばれる識別子があり、SNMPエンティティがピアのIDを認識している場合にのみSNMP通信が可能になります。トラップと通知はこのルールの例外です。
  • セキュリティモデルのサポート - セキュリティモデルは、管理ドメインまたはイントラネット内のセキュリティポリシーを定義できます。SNMPv3には、ユーザーベースセキュリティモデル（USM）の仕様が含まれています。
  • メッセージ認証サービスの目標に以下のものに対する保護が含まれるセキュリティ目標の定義:
    • 情報の変更 – 許可されていない SNMP エンティティが、許可されたプリンシパルによって生成された転送中のメッセージを変更することから保護します。
    • マスカレード – 適切な承認を持つ別のプリンシパルの ID を装うことで、一部のプリンシパルに対して承認されていない管理操作の試行に対する保護。
    • メッセージ ストリームの変更 - メッセージが悪意を持って並べ替えられたり、遅延されたり、再生されたりして、不正な管理操作に影響を及ぼすことを防ぎます。
    • 開示 – SNMP エンジン間のやり取りの盗聴に対する保護。
  • USM の仕様 – USM は、利用可能な次の通信メカニズムの一般的な定義で構成されます。
    • 認証とプライバシーのない通信 (NoAuthNoPriv)。
    • 認証あり、プライバシーなしの通信 (AuthNoPriv)。
    • 認証とプライバシーを備えた通信 (AuthPriv)。
  • さまざまな認証およびプライバシープロトコルの定義 - MD5、SHA、HMAC-SHA-2 [ 20 ]認証プロトコルとCBC_DESおよびCFB_AES_128プライバシープロトコルがUSMでサポートされています。
  • 検出手順の定義 - 指定されたトランスポート アドレスとトランスポート エンドポイント アドレスの SNMP エンティティの SNMPEngineID を見つけます。
  • 時間同期手順の定義 - SNMP エンティティ間の認証された通信を容易にします。
  • SNMP フレームワーク MIB の定義 - SNMP エンティティのリモート構成と管理を容易にします。
  • USM MIB の定義 – セキュリティ モジュールのリモート構成と管理を容易にします。
  • ビューベース アクセス制御モデル (VACM) MIB の定義 - アクセス制御モジュールのリモート構成と管理を容易にします。

セキュリティはSNMP v3まで最大の弱点の一つでした。SNMP v1およびv2における認証は、マネージャとエージェント間で平文で送信されるパスワード（コミュニティ文字列）に過ぎませんでした。[ 1 ]各SNMP v3メッセージには、オクテット文字列としてエンコードされたセキュリティパラメータが含まれています。これらのセキュリティパラメータの意味は、使用されているセキュリティモデルによって異なります。[ 21 ] v3におけるセキュリティアプローチの目標は以下のとおりです。[ 22 ]

  • 機密性 -不正なソースによるスヌーピングを防止するためのパケットの暗号化。
  • 整合性 -オプションのパケット再生保護メカニズムを含む、転送中にパケットが改ざんされていないことを確認するメッセージ整合性。
  • 認証– メッセージが有効なソースからのものであることを確認します。

v3 では USM と VACM も定義されており、その後に SSH 経由の SNMPv3 と TLS および DTLS 経由の SNMPv3 のサポートを提供するトランスポート セキュリティ モデル (TSM) が続きました。

  • USM (ユーザーベースのセキュリティ モデル) は、認証およびプライバシー (暗号化) 機能を提供し、メッセージ レベルで動作します。
  • VACM (ビューベースのアクセス制御モデル) は、特定のプリンシパルが特定の MIB オブジェクトにアクセスして特定の機能を実行できるかどうかを決定し、PDU レベルで動作します。
  • TSM（トランスポート・セキュリティ・モデル）は、外部セキュリティチャネルを介したメッセージの認証と暗号化を行うための手法を提供します。TSM仕様を利用する2つのトランスポート、SSHとTLS/DTLSが定義されています。

2004年現在、IETFはRFC 3411 – RFC 3418 [ 23 ]（STD0062とも呼ばれる）で定義されている簡易ネットワーク管理プロトコルバージョン3をSNMPの現在の標準バージョンとして認定しています。IETFはSNMPv3を完全なインターネット標準と指定しており、[ 24 ] RFCとしては最も成熟度の高いレベルです。IETFはそれ以前のバージョンを廃止（HistoricまたはObsolete）と見なしています。[ 16 ]  

実装上の問題

ネットワーク デバイスの構成を可能にする SNMP の強力な書き込み機能は、多くのベンダーによって十分に活用されていません。その理由としては、SNMPv3 より前のバージョンの SNMP にセキュリティが欠けていること、また多くのデバイスが個々の MIB オブジェクトの変更によって構成できないことが挙げられます。

一部のSNMP値（特に表形式の値）は、テーブルインデックススキームに関する特定の知識を必要とし、これらのインデックス値はプラットフォーム間で必ずしも一貫しているとは限りません。そのため、同じテーブルインデックススキームを採用していない可能性のある複数のデバイスから情報を取得する際に、相関関係の問題が発生する可能性があります（例えば、特定のディスク識別子がプラットフォーム間で異なるディスク使用率メト​​リックを取得する場合など）。[ 25 ]

一部の大手機器ベンダーは、独自のコマンドラインインターフェース（CLI）中心の構成および制御システムを過度に拡張する傾向があります。 [ 26 ]

2002年2月、カーネギーメロン大学ソフトウェア工学研究所（CM-SEI）のコンピュータ緊急対応チームコーディネーションセンター（CERT-CC）は、オウル大学セキュアプログラミンググループがSNMPメッセージ処理の徹底的な分析を実施した後、SNMPv1に関するアドバイザリ[ 27 ]を発行しました。ほとんどのSNMP実装は、サポートするプロトコルのバージョンに関係なく、プロトコルデータユニット（PDU）のデコードに同じプログラムコードを使用しており、このコードに問題が見つかりました。また、SNMP管理ステーションが受信したSNMPトラップメッセージや、ネットワークデバイス上のSNMPエージェントが受信したリクエストのデコードにも問題が見つかりました。多くのベンダーがSNMP実装用のパッチを発行する必要がありました[ 9 ]。

セキュリティへの影響

SNMPを使用してネットワークを攻撃する

SNMPは管理者がネットワークデバイスをリモートで監視・設定できるように設計されているため、ネットワークへの侵入にも利用される可能性があります。多くのソフトウェアツールはSNMPを使用してネットワーク全体をスキャンできるため、読み取り/書き込みモードの設定ミスはネットワークを攻撃に対して脆弱にする可能性があります。[ 28 ] : 52

2001年、シスコは、読み取り専用モードであっても、Cisco IOSのSNMP実装が特定のサービス拒否攻撃に対して脆弱であることを示す情報を公開しました。これらのセキュリティ問題は、IOSのアップグレードによって修正できます。[ 29 ]

ネットワークでSNMPを使用しない場合は、ネットワークデバイスでSNMPを無効にする必要があります。SNMPの読み取り専用モードを設定する際には、アクセス制御の設定と、SNMPメッセージがどのIPアドレスから受信されるかに細心の注意を払う必要があります。SNMPサーバーがIPアドレスで識別されている場合、SNMPはこれらのIPアドレスにのみ応答し、他のIPアドレスからのSNMPメッセージは拒否されます。ただし、IPアドレスのスプーフィングは依然としてセキュリティ上の懸念事項です。[ 28 ] : 54

認証

SNMP には複数のバージョンがあり、各バージョンには独自のセキュリティ問題があります。SNMP v1 では、ネットワーク上でパスワードがプレーンテキストで送信されます。そのため、パケット スニッフィングによってパスワードが読み取られる可能性があります。SNMP v2 ではMD5によるパスワード ハッシュが可能ですが、設定が必要です。事実上すべてのネットワーク管理ソフトウェアはSNMP v1 をサポートしていますが、SNMP v2 または v3 は必ずしもサポートしていません。SNMP v2 は、認証、プライバシー、認可など、データ セキュリティを提供するために特別に開発されましたが、SNMP バージョン 2c のみがインターネット技術特別調査委員会(IETF)の承認を受け、バージョン 2u と 2* はセキュリティ上の問題により IETF の承認を受けられませんでした。SNMP v3 は、MD5、セキュア ハッシュ アルゴリズム(SHA)、およびキー アルゴリズムを使用して、不正なデータ変更やスプーフィング攻撃に対する保護を提供します。より高いレベルのセキュリティが必要な場合は、オプションで暗号ブロック チェーンモードでデータ暗号化規格(DES) を使用できます。SNMP v3 は、リリース 12.0(3)T 以降の Cisco IOS に実装されています。[ 28 ] : 52

SNMPv3は、認証鍵または暗号化鍵が短い（弱い）パスワードまたは辞書に載っているパスワードから生成された場合、ブルートフォース攻撃や辞書攻撃によって推測される可能性があります。SNMPv3では、ランダムに均一に分散された暗号鍵を提供することと、ユーザーが入力したパスワードから暗号鍵を生成することの両方が可能です。ネットワーク経由で送信されるハッシュ値から認証文字列を推測されるリスクは、使用される暗号ハッシュ関数とハッシュ値の長さによって異なります。SNMPv3は、ユーザーベースセキュリティモデル（USM）にHMAC - SHA-2認証プロトコルを使用します。 [ 30 ] SNMPは、より安全なチャレンジハンドシェイク認証プロトコルを使用しません。SNMPv3は（他のSNMPプロトコルバージョンと同様に）ステートレスプロトコルであり、エージェントとマネージャー間のやり取りが最小限に抑えられるように設計されています。したがって、コマンドごとにチャレンジレスポンスハンドシェイクを導入すると、プロトコル設計者が過度で許容できないと判断するエージェント（および場合によってはネットワーク自体）に負担がかかります。

すべてのSNMPバージョンにおけるセキュリティ上の欠陥は、 IPsec認証と機密保持メカニズムによって軽減できます。SNMPは、データグラムトランスポート層セキュリティ（DTLS）を介して安全に伝送することもできます。[ 11 ]

多くのSNMP実装には、スイッチやルータなどの新しいネットワークコンポーネントが自動的に検出され、ポーリングされる自動検出機能が含まれています。SNMPv1およびSNMPv2cでは、これはコミュニティ文字列を介して行われ、コミュニティ文字列はクリアテキストで他のデバイスに送信されます。[ 11 ]クリアテキストパスワードは重大なセキュリティリスクです。コミュニティ文字列が組織外に知られると、攻撃の標的になる可能性があります。コミュニティ文字列を収集しようとする他の試みを管理者に警告するために、SNMPはコミュニティ名認証失敗トラップを渡すように設定できます。[ 28 ] : 54 SNMPv2を使用する場合、ネットワークデバイスのSNMPエージェントでパスワード暗号化を有効にすることでこの問題を回避できます。

コミュニティ文字列の一般的なデフォルト設定は、読み取り専用アクセスの場合は「public」、読み取り/書き込みアクセスの場合は「private」です。[ 9 ]：1874 これらのよく知られたデフォルト設定のため、SNMPはSANS Instituteの一般的なデフォルト設定の問題のリストでトップとなり、2000年のSANSトップ10の最も重要なインターネットセキュリティの脅威の10位にランクされました。 [ 31 ]システム管理者やネットワーク管理者は、これらの設定を変更することはあまりありません。[ 9 ]：1874

TCPまたはUDPのどちらで実行されても、SNMPv1およびv2はIPスプーフィング攻撃に対して脆弱です。スプーフィングにより、攻撃者はSNMPアクセスを制限するために実装されたエージェントのデバイスアクセスリストをバイパスできます。USMやTSMなどのSNMPv3セキュリティメカニズムは、スプーフィング攻撃を防ぐことができます。

参照

参考文献

  1. ^ a b c Douglas R. Mauro & Kevin J. Schmidt. (2001). Essential SNMP (第1版). セバストポル, カリフォルニア州: O'Reilly & Associates.
  2. ^シンプルネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ。doi ：10.17487/ RFC3411。RFC 3411。
  3. ^ RFC 6353セクション10 
  4. ^ Mark Fedor、Martin Schoffstall、James R. Davin、Dr. Jeff D. Case (1990年5月).簡易ネットワーク管理プロトコル (SNMP) . ネットワークワーキンググループ. doi : 10.17487/RFC1157 . RFC 1157 .歴史的。p . 26。RFC 1098は 廃止。SetRequest -PDUで指定された各変数の割り当ては、同じメッセージで指定された他のすべての割り当てに対して同時に設定されたかのように実行される必要があります。
  5. ^ J. Case; K. McCloghrie; M. Rose; S. Waldbusser (1993年4月). 「RFC 1448 – Simple Network Management Protocol バージョン2 (SNMPv2) のプロトコル操作」 . Internet Engineering Task Force. doi : 10.17487/RFC1448 . InformRequest-PDUは、マネージャロールで動作するSNMPv2エンティティ内のアプリケーションからの要求に応じて生成され、送信されます。このアプリケーションは、送信側アプリケーションにローカルなパーティのMIBビュー内の情報を、マネージャロールで動作するSNMPv2エンティティ内の別のアプリケーションに通知しようとします。
  6. ^ D. Levi; P. Meyer; B. Stewart (1999年4月). 「RFC 2573 – SNMPアプリケーション」 . インターネット技術タスクフォース. doi : 10.17487/RFC2573 .
  7. ^ a b「SNMP Inform Requests」 . Cisco . 2011年12月9日閲覧。
  8. ^ 「JUNOSソフトウェアにおけるSNMP実装の理解」 Juniper Networks . 2013年2月11日閲覧。
  9. ^ a b c d e Harold F. Tipton; Micki Krause (2007).情報セキュリティ管理ハンドブック 第6版. CRC Press. ISBN 9780849374951。
  10. ^ Douglas Mauro、Kevin Schmidt (2005). 『情報セキュリティ管理ハンドブック 第6版』Essential SNMP: システムおよびネットワーク管理者のためのヘルプO'Reilly Media, Inc. pp.  21– 22. ISBN 9780596552770。
  11. ^ a b cスチュアート・ジェイコブス (2015). 『エンジニアリング情報セキュリティ：情報保証を実現するためのシステムエンジニアリング概念の応用』 ジョン・ワイリー・アンド・サンズ. p. 367. ISBN 9781119104797。
  12. ^ RFC 3584「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、バージョン3の共存」 
  13. ^ Wiley, John (2015-12-01). 『エンジニアリング情報セキュリティ：情報保証を実現するためのシステムエンジニアリング概念の応用』 John Wiley & Sons. p. 366. ISBN 9781119104711. 2017年9月14日閲覧。
  14. ^ a b「SNMPv3とSNMPv1またはv2cのセキュリティの比較」(PDF) 。2013年4月29日時点のオリジナル(PDF)からアーカイブ。
  15. ^ RFC 1157 
  16. ^ a b c「RFC検索詳細: 標準化過程におけるSNMPv2 RFC」 RFCエディター2014年2月24日閲覧。
  17. ^ RFC 3416 
  18. ^ SNMPv3 - ユーザーセキュリティモデル、Dr. Dobbs 、 2019年3月9日取得
  19. ^この号の内容: SNMPバージョン3 2017年7月27日アーカイブThe Simple Times ISSN 1060-6084 
  20. ^ RFC 7860
  21. ^ David Zeltserman (1999). 『SNMPv3とネットワーク管理の実践ガイド』アッパーサドルリバー、ニュージャージー州: Prentice Hall PTR.
  22. ^ "SNMPv3" . Cisco Systems. 2011年7月19日時点のオリジナルよりアーカイブ。
  23. ^ 「SNMPバージョン3」 . Institute of Operating Systems and Computer Networks . 2010年5月7日閲覧。
  24. ^ RFC Editor Archived 2007-10-29 at the Wayback Machine現在のインターネット標準（STD）のリスト
  25. ^ 「SNMP のテーブル インデックス値について」。
  26. ^ 「SNMP Researchのプレゼンテーションでは、独自のCLIよりも標準ベースの管理が推奨されている」 SNMP Research . 2010年10月12日閲覧。
  27. ^ CERTアドバイザリ CA-2002-03 多くの実装における複数の脆弱性
  28. ^ a b c d Andrew G. Mason; Mark J. Newcomb (2001). Cisco Secure Internet Security Solutions . Cisco Press. ISBN 9781587050169。
  29. ^ Andrew G. Mason、Mark J. Newcomb (2001). Cisco Secure Internet Security Solutions . Cisco Press. pp.  52. ISBN 9781587050169。
  30. ^ SNMPv3のユーザーベースセキュリティモデル（USM）におけるHMAC-SHA-2認証プロトコル。RFC 7630。 
  31. ^ 「SANS Institute - CIS クリティカル セキュリティ コントロール」。

さらに読む

  • RFC  1155 (STD 16) — TCP/IPベースのインターネットにおける管理情報の構造と識別
  • RFC  1156 (Historic) — TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース
  • RFC  1157 (歴史的) —簡易ネットワーク管理プロトコル (SNMP)
  • RFC  1213 (STD 17) — TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース: MIB-II
  • RFC  1452 (情報) —インターネット標準ネットワーク管理フレームワークのバージョン 1 とバージョン 2 の共存( RFC 1908により廃止) 
  • RFC  1901 (実験的) —コミュニティベースSNMPv2の紹介
  • RFC  1902 (ドラフト標準) — SNMPv2 の管理情報の構造( RFC 2578により廃止) 
  • RFC  1908 (標準化過程) —インターネット標準ネットワーク管理フレームワークのバージョン 1 とバージョン 2 の共存
  • RFC  2570 (情報) —インターネット標準ネットワーク管理フレームワークのバージョン 3 の概要( RFC 3410により廃止) 
  • RFC  2578 (STD 58) —管理情報バージョン2 (SMIv2) の構造
  • RFC  3410 (情報) —インターネット標準管理フレームワークの概要と適用性に関する声明
  • STD 62には次の RFC が含まれています。
    • RFC  3411  —簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ
    • RFC  3412  —簡易ネットワーク管理プロトコル (SNMP) のメッセージ処理およびディスパッチ
    • RFC  3413  —簡易ネットワーク管理プロトコル (SNMP) アプリケーション
    • RFC  3414  —簡易ネットワーク管理プロトコルバージョン3（SNMPv3）のユーザーベースセキュリティモデル（USM）
    • RFC  3415  —簡易ネットワーク管理プロトコル (SNMP) のビューベース アクセス制御モデル (VACM)
    • RFC  3416  —簡易ネットワーク管理プロトコル (SNMP) のプロトコル操作バージョン 2
    • RFC  3417  —簡易ネットワーク管理プロトコル (SNMP) のトランスポートマッピング
    • RFC  3418  —簡易ネットワーク管理プロトコル (SNMP) の管理情報ベース (MIB)
  • RFC  3430 (実験的) —伝送制御プロトコル (TCP) トランスポート マッピング上の簡易ネットワーク管理プロトコル (SNMP)
  • RFC  3584 (BCP 74) —インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、バージョン3の共存
  • RFC  3826 (提案) — SNMP ユーザーベース セキュリティ モデルにおける Advanced Encryption Standard (AES) 暗号アルゴリズム
  • RFC  4789 (提案) — IEEE 802 ネットワーク上の簡易ネットワーク管理プロトコル (SNMP)
  • RFC  5343 (STD 78) —シンプルネットワーク管理プロトコル (SNMP) コンテキストエンジンID検出
  • RFC  5590 (STD 78) —簡易ネットワーク管理プロトコル (SNMP) のトランスポートサブシステム
  • RFC  5591 (STD 78) —簡易ネットワーク管理プロトコル (SNMP) のトランスポート セキュリティ モデル
  • RFC  5592 (提案) —シンプルネットワーク管理プロトコル (SNMP) のセキュアシェルトランスポートモデル
  • RFC  5608 (提案) —シンプル ネットワーク管理プロトコル (SNMP) トランスポート モデルでのリモート認証ダイヤルイン ユーザー サービス (RADIUS) の使用。
  • RFC  6353 (STD 78) —簡易ネットワーク管理プロトコル (SNMP) のトランスポート層セキュリティ (TLS) トランスポート モデル
  • RFC  7630 (提案|履歴) — SNMPv3 のユーザーベース セキュリティ モデル (USM) における HMAC-SHA-2 認証プロトコル
  • RFC  7860 (提案) — SNMPv3 のユーザーベース セキュリティ モデル (USM) における HMAC-SHA-2 認証プロトコル
ウィキバーシティには、シンプルネットワーク管理プロトコルに関する学習リソースがあります。
「 https://en.wikipedia.org/w/index.php?title=Simple_Network_Management_Protocol&oldid=1312421324#Version_2」から取得