SNMP（簡易ネットワーク管理プロトコル）入門

紹介

システム管理者としての大きな役割の一つは、サーバーやインフラストラクチャに関する正確な情報を収集することです。この種の情報を収集し処理するためのさまざまなツールやオプションがあります。それらの多くはSNMPという技術に基づいています。

SNMPはSimple Network Management Protocolの略です。これは、サーバーが現在の状態に関する情報を共有する方法であり、管理者が事前に定義された値を変更できるチャネルでもあります。このプロトコル自体は非常にシンプルですが、SNMPを実装するプログラムの構造は非常に複雑になることがあります。

このガイドでは、SNMPプロトコルの基本について紹介します。その利用方法、ネットワーク内でのプロトコルの一般的な使用方法、プロトコルバージョン間の違いなどを説明します。

基本概念

SNMPはネットワークスタックのアプリケーション層に実装されているプロトコルです（ネットワークリソースの層について学ぶにはここをクリックしてください）。このプロトコルは、非常に異なるシステムから一貫した方法で情報を収集する手段として作成されました。さまざまなシステムと接続する際にも使用できるものの、情報の照会方法や関連情報へのパスは標準化されています。

SNMPプロトコルには複数のバージョンがあり、多くのネットワーク接続デバイスが何らかの形でSNMPアクセスを実装しています。最も広く使用されているバージョンはSNMPv1ですが、多くの点で安全ではありません。その人気は主にその普及と長い使用期間に起因しています。特に理由がない限り、より高度なセキュリティ機能を提供するSNMPv3の使用を推奨します。

一般的に、SNMPによってプロファイルされるネットワークは、主にSNMPエージェントを含むデバイスで構成されています。エージェントは、ハードウェアに関する情報を収集し、それを事前に定義されたエントリに整理し、SNMPプロトコルを使用してクエリに応答するプログラムです。

このモデルの情報を代理人に問い合わせるコンポーネントは、SNMP マネージャーと呼ばれます。これらのマシンは、通常、ネットワーク内のすべてのSNMP対応デバイスに関するデータを持ち、情報を収集し、特定のプロパティを設定するためのリクエストを発行することができます。

SNMPマネージャー

SNMPマネージャーは、情報を得るためにSNMPエージェントをポーリングするように設定されたコンピューターです。管理コンポーネントは、そのコア機能についてのみ議論する場合、実際にはクライアント設定よりもはるかに複雑ではありません。なぜなら、管理コンポーネントは単にデータを要求するだけだからです。

マネージャーは、正しい認証情報を持ってSNMPエージェントにクエリリクエストを送信できる任意の機械であることができます。時には、これが監視スイートの一部として実装されることもありますし、別の時には管理者が簡単なユーティリティを使用して迅速なリクエストを作成することもあります。

SNMPプロトコルで定義されたコマンドのほとんどは（これらについては後で詳しく説明します）、マネージャーコンポーネントによって送信されるように設計されています。これには、GetRequest、GetNextRequest、GetBulkRequest、SetRequest、InformRequest、およびResponseが含まれます。これに加えて、マネージャーは応答することもできるように設計されており、TrapおよびResponseメッセージに対して応答します。

SNMPエージェント

SNMPエージェントは大部分の作業を行います。彼らはローカルシステムに関する情報を収集し、それを照会可能な形式で保存する責任があります。「管理情報ベース」と呼ばれるデータベース、つまりMIBを更新します。

MIBは、情報をクエリまたは設定できるように格納する階層的で事前定義された構造です。これは、正しい資格情報で認証されたホスト（SNMPマネージャー）から発信された適切なSNMP要求に対して利用可能です。

エージェントコンピュータは、どのマネージャーが情報にアクセスできるかを構成します。また、SNMPトラフィックに設定されていない接続可能なデバイスに関する情報を報告する仲介者としても機能できます。これにより、コンポーネントをオンラインにし、SNMPにアクセスできるようにする際の柔軟性が大幅に向上します。

SNMPエージェントは、プロトコルによって定義されたほとんどのコマンドに応答します。これには、GetRequest、GetNextRequest、GetBulkRequest、SetRequest、およびInformRequestが含まれます。さらに、エージェントはTrapメッセージを送信するように設計されています。

管理情報ベースの理解

SNMPシステムで理解するのが最も難しい部分は、おそらくMIB（管理情報ベース）です。MIBは、マネージャーとエージェントが遵守する標準に従ったデータベースです。それは階層構造であり、多くの分野ではグローバルに標準化されていますが、ベンダー固有の追加を許可するほど柔軟性もあります。

MIB構造は、上から下への階層的なツリーとして最もよく理解されます。分岐する各ブランチには、その階層のレベルでユニークな識別番号（1から始まる）と識別文字列がラベル付けされています。文字列と番号は互換的に使用できます。

木の特定のノードを参照するには、名前のない木のルートから対象のノードまでの経路をたどる必要があります。その親ID（番号または文字列）の系譜が最も一般的なものから始まり、連結されてアドレスを形成します。階層内の各接続点は、この表記法でドットで表されるため、アドレスはドットで区切られた一連のID文字列または番号となります。このアドレス全体はオブジェクト識別子、またはOIDとして知られています。

デバイスにSNMPエージェントを埋め込むハードウェアベンダーは、独自のフィールドやデータポイントを持つカスタムブランチを実装することがあります。しかし、どのデバイスでも使用できる標準MIBブランチも明確に定義されています。

私たちが議論する標準ブランチはすべて同じ親ブランチ構造の下にあります。このブランチは、準拠したデバイスのための改訂標準であるMIB-2仕様に準拠する情報を定義します。

このブランチへのベースパスは:

1.3.6.1.2.1

これは、次のような文字列で表すこともできます:

iso.org.dod.internet.mgmt.mib-2

1.3.6.1またはiso.org.dod.internetのセクションは、インターネットリソースを定義するOIDです。その後の2またはmgmtは、管理のサブカテゴリのためのものです。その下の1またはmib-2は、MIB-2仕様を定義しています。

これはMIBツリーに慣れるための素晴らしいリソースです。この特定のページは、私たちが話していた接続ノードを表しています。ツリーの上位および下位を確認するには、それぞれ「上位」および「下位」の参照をチェックしてください。

もう一つの類似のツールは、Ciscoが提供するSNMPオブジェクトナビゲーターです。これを使用すると、階層を掘り下げて必要な情報を見つけることができます。同様のツリーはSolarWindsによって提供されています。

基本的に、デバイスから情報を取得したい場合、ほとんどのパスは1.3.6.1.2.1から始まります。利用可能な情報を照会および設定できる種類について学ぶために、ツリーインターフェースをブラウズできます。

SNMPプロトコルコマンド

SNMPがこれほど広く採用されている理由の一つは、利用可能なコマンドのシンプルさです。実装するか覚えておくべき操作はほとんどありませんが、プロトコルのユーティリティ要件に対応するのに十分な柔軟性があります。

次のPDU、つまりプロトコルデータユニットは、プロトコルによって許可される正確なメッセージタイプを説明します:

取得: 取得メッセージは、マネージャーがエージェントに特定のOIDの値を要求するために送信されます。この要求は、データを持ってマネージャーに返送される応答メッセージによって回答されます。
GetNext: GetNextメッセージは、マネージャーがMIB内の次のシーケンシャルオブジェクトを要求することを可能にします。これは、どのOIDをクエリするかを気にすることなく、MIBの構造を横断する方法の一つです。
設定: セットメッセージは、マネージャーからエージェントに送信され、エージェントの変数が保持する値を変更するために使用されます。これは、構成情報を制御したり、リモートホストの状態を変更したりするために使用できます。これは、プロトコルで定義された唯一の書き込み操作です。
GetBulk: このマネージャーからエージェントへのリクエストは、複数のGetNextリクエストが行われたかのように機能します。マネージャーへの返信には、リクエストによって設定された制約内で、パケットが許す限りできるだけ多くのデータが含まれます。
レスポンス: このメッセージは、エージェントによって送信され、マネージャーに要求された情報を送信するために使用されます。このメッセージは、要求されたデータの輸送として機能するだけでなく、要求の受領の確認としても機能します。要求されたデータが返せない場合、レスポンスには追加情報を設定できるエラーフィールドが含まれます。上記のリクエストに対しては、レスポンスメッセージを返す必要があり、インフォメッセージにも該当します。
トラップ: トラップメッセージは一般的にエージェントからマネージャーに送信されます。トラップは非同期通知であり、それを受信するマネージャーから要求されるものではありません。主にエージェントが管理するデバイスで発生しているイベントをマネージャーに通知するために使用されます。
通知: トラップの受信を確認するために、マネージャはエージェントに通知メッセージを返送します。このメッセージをエージェントが受信しない場合、トラップメッセージを再送し続ける可能性があります。

これらの7つのデータユニットタイプを使って、SNMPはネットワークデバイスに関する情報を問い合わせたり送信したりすることができます。

プロトコルバージョン

SNMPプロトコルは、最初に導入されて以来、多くの変更を経てきました。最初の仕様は1988年にRFC 1065、1066、1067に基づいて策定されました。それが長い間存在しているという単純な事実により、このバージョンは依然として広くサポートされています。しかし、平文での認証を含む多くのセキュリティ問題があるため、その使用は強く推奨されていません。特に保護されていないネットワークでの使用は避けるべきです。

プロトコルのバージョン2の作業は1993年に開始され、以前の標準に対していくつかの重要な改善が提供されました。このバージョンには、以前の改訂に固有のセキュリティ問題に対処するために設計された新しい「パーティーベース」のセキュリティモデルが含まれていました。しかし、新しいモデルは理解しにくく、実装も難しかったため、あまり人気がありませんでした。

これにより、バージョン2のいくつかの「スピンオフ」が作成され、それぞれがバージョン2の改善の大部分を保持しながら、セキュリティモデルを変更しました。SNMPv2cでは、コミュニティベースの認証が再導入され、これはv1で使用されたのと同じモデルです。これはv2プロトコルの中で最も人気のあるバージョンでした。別の実装であるSNMPv2uは、ユーザーベースのセキュリティを使用していますが、これはあまり人気がありませんでした。これにより、ユーザーごとの認証設定が可能になりました。

1998年に、SNMPプロトコルの第3（現行）のバージョンが仕様提案として登場しました。ユーザーの視点から見ると、最も関連性の高い変更はユーザーベースのセキュリティシステムの導入でした。これにより、ユーザーの認証要件を以下のモデルの1つとして設定できるようになります。

NoAuthNoPriv: このレベルで接続しているユーザーは、認証がなく、送受信するメッセージにプライバシーがありません。
AuthNoPriv: このモデルを使用する接続は認証が必要ですが、メッセージは暗号化されずに送信されます。
AuthPriv: 認証が必要で、メッセージは暗号化されています。

認証に加えて、ユーザーがアクセスできるブランチに対して詳細な制御を提供するためのアクセス制御メカニズムが実装されました。バージョン3は、SSHやTLSなどのトランスポートプロトコルによって提供されるセキュリティを活用する能力も備えています。

結論

プロトコルの動作について良い理解を得たので、自分のインフラストラクチャにSNMPを実装するために必要な基盤が整いました。

次のガイドでは、システムでSNMPを活用するために必要なコンポーネントのインストールと設定方法について説明します。