序章

システム管理者であることの大部分は、サーバーとインフラストラクチャに関する正確な情報を収集することです。 このタイプの情報を収集および処理するためのツールとオプションは多数あります。 それらの多くは、SNMPと呼ばれるテクノロジーに基づいて構築されています。

SNMPは、簡易ネットワーク管理プロトコルの略です。 これは、サーバーが現在の状態に関する情報を共有できる方法であり、管理者が事前定義された値を変更できるチャネルでもあります。 プロトコル自体は非常に単純ですが、SNMPを実装するプログラムの構造は非常に複雑になる可能性があります。

このガイドでは、SNMPプロトコルの基本を紹介します。 その使用法、プロトコルがネットワークで通常使用される方法、プロトコルバージョンの違いなどについて説明します。

基本概念

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

SNMPプロトコルには複数のバージョンがあり、多くのネットワークハードウェアデバイスは何らかの形式のSNMPアクセスを実装しています。 最も広く使用されているバージョンはSNMPv1ですが、多くの点で安全ではありません。 その人気は主に、その遍在性と野生での長い時間に由来しています。 強い理由がない限り、より高度なセキュリティ機能を提供するSNMPv3を使用することをお勧めします。

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

エージェントに情報を照会するこのモデルのコンポーネントは、SNMP managerと呼ばれます。 これらのマシンは通常、ネットワーク内のすべての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, SetRequestInformRequest. さらに、エージェントは送信するように設計されています 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です。 The 2 また mgmt基本パスに続くのは、管理サブカテゴリ用です。 The 1 また mib-2 その下でMIB-2仕様を定義します。

これは、MIBツリーに慣れるための優れたリソースです。 この特定のページは、私たちが話しているジャンクションの接続ノードを表しています。 「上位」と「補助」の参照をそれぞれチェックすることで、ツリーのさらに上と下を確認できます。

もう1つの同様のツールは、シスコが提供する SNMP ObjectNavigatorです。 これを使用して、階層にドリルダウンし、必要な情報を見つけることができます。 同様のツリーはSolarWindsによって提供されます。

基本的に、デバイスに情報を照会する場合、ほとんどのパスは次のように始まります。 1.3.6.1.2.1. ツリーインターフェイスを参照して、クエリと設定に使用できる情報の種類を確認できます。

SNMPプロトコルコマンド

SNMPがこのように多く採用されている理由の1つは、使用可能なコマンドの単純さです。 実装または記憶する操作はほとんどありませんが、プロトコルのユーティリティ要件に対応するのに十分な柔軟性があります。

次のPDU、またはプロトコルデータユニットは、プロトコルで許可されている正確なメッセージングタイプを示しています。

  • Get :Getメッセージは、特定のOIDの値を要求するためにマネージャーからエージェントに送信されます。 この要求は、データとともにマネージャーに返送される応答メッセージで応答されます。
  • GetNext :GetNextメッセージにより、マネージャーはMIB内の次の順次オブジェクトを要求できます。 これは、クエリするOIDを気にせずにMIBの構造をトラバースできる方法です。
  • Set :エージェントの変数が保持する値を変更するために、マネージャーからエージェントにSetメッセージが送信されます。 これを使用して、構成情報を制御したり、リモートホストの状態を変更したりできます。 これは、プロトコルによって定義された唯一の書き込み操作です。
  • GetBulk :このマネージャーからエージェントへのリクエストは、複数のGetNextリクエストが行われたかのように機能します。 マネージャーへの返信には、パケットが許す限り(要求によって設定された制約内で)可能な限り多くのデータが含まれます。
  • Response :エージェントによって送信されるこのメッセージは、要求された情報をマネージャーに送り返すために使用されます。 これは、要求されたデータの転送と、要求の受信の確認の両方として機能します。 要求されたデータを返すことができない場合、応答には、詳細情報で設定できるエラーフィールドが含まれます。 上記の要求のいずれかに対して応答メッセージを返す必要があります。また、通知メッセージも返す必要があります。
  • Trap :トラップメッセージは通常、エージェントからマネージャーに送信されます。 トラップは、トラップを受信するマネージャーによって要求されないという点で非同期通知です。 これらは主に、管理対象デバイスで発生しているイベントをマネージャーに通知するためにエージェントによって使用されます。
  • Inform :トラップの受信を確認するために、マネージャーはInformメッセージをエージェントに送り返します。 エージェントがこのメッセージを受信しない場合、エージェントはトラップメッセージを再送信し続ける可能性があります。

これらの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を活用するために必要なコンポーネントをインストールおよび構成する方法について説明します。