Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

注:

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

この例では、許可された特定のIPアドレスのセットに基づいて、Juniper Networkingデバイスへの管理アクセスを制限する方法を示しています。このタイプの機能は、しばしば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: ネットワーク トポロジーの例ネットワーク トポロジーの例

IP アドレスリストを構成して、デバイスへの管理アクセスを制限する

手順

CLIクイック構成

この例を簡単に設定するには、以下のコマンドを適宜編集して、 [edit] 階層レベルでR2デバイスのCLIに貼り付けます。簡潔にするために、設定にはSSH(非ユーザー向け)とTelnetシステムサービスを設定するコマンドが含まれています。また、管理インターフェイスと関連するスタティックルートの設定も提供します。デバイスでこの機能がすでに設定されている場合、これらのコマンドは必要ありません。

注:

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

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

ヒント:

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

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

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

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

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

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

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

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

  4. 他のすべてのトラフィックを受け入れるようにデフォルトの条件を設定します。これにより、pings、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 デバイスは、宛先に到達するために使用するエグレス インターフェイスからトラフィックを送信します。その結果、テストトラフィックは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 プレフィックスリストに記載されていないことに注意してください。

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