Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

例:ジュニパーネットワークデバイス上の管理アクセスの制御

注:

この例は、当社のコンテンツテストチームが検証し、更新しました。

この例では、許可された特定のIPアドレスセットに基づいて、ジュニパーネットワーキングデバイスへの管理アクセスを制限する方法を示しています。このタイプの機能は、しばしばACL(アクセス制御リスト)と呼ばれ、Junos OSにステートレスファイアウォールフィルターとして実装されています。

要件

管理ネットワークに接続されたジュニパーネットワークデバイス。設定を検証するには、DUT(被試験デバイス)へのSSHまたはTelnet接続を開始できる管理ネットワークへのアクセスを持つデバイスが少なくとも1つ必要です。この例を設定する前に、デバイスの基本的な初期化(管理インターフェイスおよび関連するスタティックルート、システムサービス、ユーザーログインアカウントなど)以外の特別な設定は必要ありません。

概要

ファイアウォールフィルターを設定して、デバイスを管理できるIPアドレスを制限できます。このファイアウォールフィルターには、デバイスの管理が許可されているIPアドレスを除くすべてのトラフィックを拒否する条件を含める必要があります。ファイアウォールフィルターをループバックインターフェイス(lo0)に適用して、管理トラフィック、つまりデバイス自体に送信されたトラフィックのみがフィルタリングされるようにする必要があります。

トポロジーの例

図1 は、この例のトポロジーを示しています。R1デバイスは、172.16.0.0/24サブネットが割り当てられた管理ネットワークのデフォルトゲートウェイとして機能します。この例では、R2デバイスへの管理アクセスを制限するフィルターを適用して、それをDUTにします。リモートワークステーションにはDUTを管理する権限があり、10.0.0.1/32アドレスが割り当てられています。

この例では、以下を行います。

  • manager-ipというプレフィックスリストを設定します。このリストは、デバイスの管理に許可されるIPアドレスのセットを定義します。この例では、リストには管理サブネット自体(172.16.0.0/24)と、許可されたリモートユーザーのIPアドレス(10.0.0.1/32)が含まれています。

  • manager-ipプレフィックスリストで定義された特定のアドレスセットを除くすべての送信元アドレス拒否するファイアウォールフィルターlimit-mgmt-accessを設定します。これにより、プレフィックスリストに記載されているIPアドレスのみがデバイスを管理できるようになります。

  • ループバックインターフェイスに limit-mgmt-access フィルターを適用します。ローカルデバイス宛てのパケットがインターフェイスに到着するたびに、ループバックインターフェイスはフィルター limit-mgmt-access を適用して、許可されたアドレスのみに管理アクセスを制限します。

図1:ネットワークトポロジーのNetwork diagram showing an Authorized Remote Management Station at 10.0.0.1 connecting to Gateway R1 at 10.0.0.254 and DUT R2 at 172.16.0.253.

デバイスへの管理アクセスを制限するためのIPアドレスリストの設定

手順

CLIクイックコンフィグレーション

この例をすばやく設定するには、必要に応じて以下のコマンドを編集し、 [edit] 階層レベルでR2デバイスのCLIに貼り付けます。念のために言えるように、この設定には、SSH(非ユーザー向け)と Telnet システム サービスを設定するコマンドが含まれています。また、管理インターフェイスおよび関連する静的ルートの設定も提供します。デバイスにこの機能がすでに設定されている場合は、これらのコマンドは必要ありません。

注:

Telnetは、ジュニパーネットワークスデバイスでのrootログインをサポートしていません。この例では、rootユーザーのSSHログインは設定されていません。デバイスには、リモートログインを許可するようにルート以外のユーザーが設定されている必要があります。または、system services sshステートメントにroot-login allow引数を追加して、SSHを使用したrootユーザーのログインを許可することもできます。

変更を有効にするには、必ず設定モードから commit を発行してください。

ヒント:

デバイスへのアクセスを制限するフィルターを適用する場合は、 commit confirmedの使用を検討してください。このオプションは、指定された時間内に別のコミットを発行できない場合に、設定を自動的にロールバックします。

ステップバイステップの手順

以下の手順では、設定階層のさまざまなレベルに移動する必要があります。その方法の詳細については、『CLIユーザーガイド』の「構成モードでのCLIエディターの使用」を参照してください。

  1. 管理インターフェイスとループバック インターフェイスを設定し、Telnet および SSH システム サービスが有効であることを確認します。

  2. プレフィックスリストで許可されるホストアドレスのセットを定義します。このリストには、管理サブネットと単一の承認済みリモート管理ステーションのプレフィックスが含まれています。

    プレフィックスリストは、ファイアウォールフィルターで参照されます。プレフィックスリストを使用すると、デバイスへのアクセスを許可されているアドレスを簡単に更新できます。これは、プレフィックスリストのみを更新する必要があるためです。許可されたプレフィックスを追加または削除する際に、ファイアウォールフィルター自体を編集する必要はありません。

  3. ファイアウォールフィルターを設定して、プレフィックスリストで定義されているIPアドレス を除く すべてのIPアドレスからのTelnetおよびSSHトラフィックを拒否します。

    exceptアクション修飾子の使用に注意してください。最初の用語は、可能なすべての送信元アドレスで一致します。次の条件は、指定されたプレフィックスリスト内の送信元アドレスの一致を反転します。その結果、指定されたプロトコルとポート宛ての管理トラフィックは、トラフィックがリスト内のアドレスから来ている場合にのみ受け入れられます。他のすべての送信元プレフィックスから、同じプロトコルとポートの組み合わせへのトラフィックは破棄されます。この例では、フィルターのデバッグと検証を支援するログアクションが追加されています。

  4. 他のすべてのトラフィックを受け入れるようにデフォルト条件を設定します。これにより、ping、BGP、OSPFなどの他のサービスやプロトコルがフィルターの影響を受けないようにすることができます。

    ヒント:

    この例のフィルターは、設計上寛容です。以前のフィルター条件によって拒否または破棄されていないすべてのトラフィックを明示的に受け入れる場合、セキュリティ上の脅威を表す可能性があります。より強力なセキュリティ フィルターを構成するには、受け入れるべきすべてのプロトコルとサービスを明示的にリストし、暗黙的または明示的に、すべて拒否条件でフィルターを終了し、他のすべてのトラフィックをフィルタリングします。制限フィルターの欠点は、サポートされているサービスが追加または削除されるたびに編集する必要があることです。

  5. ステートレスファイアウォールフィルターを入力フィルターとしてループバックインターフェイスに適用します。この例では、ローカルデバイスから送信されたトラフィックはフィルタリングされません。

結果

設定モードから以下の show configuration コマンドを入力して作業を確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

作業に満足したら、設定モードから commit に入ります。

ヒント:

デバイスへのアクセスを制限するフィルターを適用する場合は、 commit confirmedの使用を検討してください。このオプションは、指定された時間内に別のコミットを発行できない場合に、設定を自動的にロールバックします。

ステートレスファイアウォールフィルターの確認

管理アクセスを制限するファイアウォールフィルターが正常に動作していることを確認します。

受け入れられたパケットの確認

目的

トラフィックが 172.16.0.0/24 サブネットまたはリモート管理ステーションに関連付けられた 10.0.0.1 ホストプレフィックスから送信されている場合、ファイアウォールフィルターが SSH と Telnet を正しく許可していることを確認します。

アクション

  1. ルーターまたはスイッチのファイアウォールログを消去します。

  2. R1デバイスなど、172.16.0.0/24サブネットに接続されたホストから、ssh 172.16.0.253コマンドを使用してDUTへの接続を開始します。デフォルトでは、R1デバイスは、宛先に到達するために使用されるegressインターフェイスからのトラフィックを送信します。その結果、テストトラフィックはR1の172.16.0.254アドレスから送信されます。このトラフィックは、参照されているプレフィックスリストに一致するアドレスのexceptアクション修飾子のため、block_non_managerフィルター条件に一致しません。このトラフィックは、accept_everything_elseフィルター条件に一致し、受け入れられます

    注:

    これらのデバイス間の user として最初のSSHログインである場合は、SSHホストキーを保存するように求められます。

  3. R2デバイスのCLIからログアウトして、SSHセッションを閉じます。

    注:

    telnetコマンドを使用して、この手順を繰り返します。Telnet 接続に成功するはずです。

  4. R2デバイスで show firewall log コマンドを使用して、R2デバイスのファイアウォールログバッファに、172.16.0.0/24サブネット内の送信元アドレスを持つエントリが含まれ ていない ことを確認します。これは、このトラフィックのパケットヘッダー情報がファイアウォールフィルターログに 記録されない ことを意味します。この例では、 block_non_manager 条件に一致するトラフィックのみがログに記録されます。

意味

出力では、SSH(およびTelnet)接続が管理ネットワークからの発信元の場合に受け入れられていることを確認します。また、 block_non_manager 条件に一致しないパケットはログに記録されないことも示します。SSHまたはTelnetトラフィックが、10.0.0.1アドレスが割り当てられたリモート管理ステーションによって生成された場合も、同じ結果が予想されます。

ログされたパケットと拒否されたパケットの確認

目的

ファイアウォールフィルターが、manager-ipプレフィックスリストのいずれかのプレフィックスから発信されていないSSHおよびTelnetトラフィックを正しく破棄していることを確認します。

アクション

  1. manager-ipプレフィックスリストで指定されていないアドレスから発信されたSSHトラフィックを生成します。R1デバイスのループバックアドレスからセッションをソースして、非承認IPをシミュレートできます。または、管理サブネットに接続されておらず、IPアドレス10.0.0.1が割り当てられていない任意のリモートデバイスから接続を開始します。このSSHセッションのパケットは破棄し、パケットヘッダー情報はファイアウォールフィルターログバッファに記録する必要があります。

    注:

    エラーメッセージや返信を期待しないでください。接続試行がタイムアウトします。これは、サンプルフィルターがrejectアクションではなくdiscardを使用するためです。

    出力は、SSH接続が成功しないことを示しています。これにより、許可されていない送信元アドレスから送信された SSH トラフィックをフィルターが正しくブロックしていることを確認します。許可されていないIP送信元アドレスによって開始されたTelnetセッションについても、同じ結果が予想されます。

  2. show firewall log コマンドを使用して、R2 デバイスのファイアウォール ログ バッファーに、許可されていない送信元アドレスを持つパケットのエントリーが含まれていることを確認します。

意味

この出力から、送信元アドレス10.0.0.119からのトラフィックが limit-mgmt-access フィルターのログ条件と一致したことがわかります。この例では、 block_non_manager 項のみにログアクションがあることを思い出してください。 Action 列には、パケットが破棄されたことを示す D が表示されます。フィルタリングされたトラフィックのイングレスインターフェイスが、デバイス上の管理ポート fxp0.0 であることが確認されます。フィルタリングされたパケットのトランスポートプロトコル TCP とIPアドレスも表示されます。このトラフィックの送信元アドレス 10.0.0.119 は、 manager-ip プレフィックスリストに記載されていないことに注意してください。

これらの結果から、この例ではファイアウォールフィルターが正しく動作していることが確認できます。