アクセス ルールについて
アクセス ルール ポリシーでは、インターフェイスを通過するトラフィックを許可または拒否するルールを定義します。通常は、インターフェイスに入るトラフィックのアクセス ルールを作成します。これは、特定タイプのパケットを拒否する場合、デバイスがパケットの処理に多くの時間を費やす前にパケットを拒否する方が有効なためです。
アクセス ルールは、デバイスに展開されると、インターフェイスに接続されているアクセス コントロール リスト(ACL)の 1 つ以上のエントリ(ACE)となります。通常、これらのアクセス ルールが、パケットに最初に適用されるセキュリティ ポリシーとなります。つまり、防御の最前線となります。アクセス ルールを使用して、サービス(プロトコルとポート番号)、送信元アドレス、および宛先アドレスに基づいて、トラフィックを許可または拒否(ドロップ)することにより、望ましくないトラフィックをフィルタリングして除外します。インターフェイスに到着したパケットごとに、指定した基準に基づいてパケットを転送するかドロップするかが決定されます。Out 方向のアクセス ルールを定義した場合、パケットは、インターフェイスを出ていくときにも分析されます。
ヒント |
ASA 8.3+ デバイスの場合は、グローバルなアクセス ルールを使用して、インターフェイス固有のアクセス ルールを増強できます。詳細については、グローバル アクセス ルールについてを参照してください。 |
アクセス ルールでトラフィックを許可しても、後続のポリシーによってそのトラフィックが最終的にドロップされることがあります。たとえば、インスペクションルール、Web フィルタルール、およびゾーンベースのファイアウォールルールは、パケットがインターフェイスのアクセスルールに合格したあとに適用されます。この場合、これらの後続のルールによって、さらに深いトラフィック分析に基づいてトラフィックがドロップされることがあります。たとえば、パケット ヘッダーが検査要件を満たしていない場合や、Web 要求の URL が望ましくない Web サイトに対応している場合などです。
このため、アクセス ルールを定義する際は、作成する他のタイプのファイアウォール ルールについて慎重に検討する必要があります。検査する必要があるトラフィックに対しては、アクセス ルールで全面的な拒否ルールを作成しないでください。一方、特定のホストやネットワークを起点または宛先とするサービスをどのような場合にも許可しないことがわかっている場合は、アクセス ルールを使用してトラフィックを拒否してください。
アクセス ルールの順序に留意してください。つまり、デバイスは、ルールに基づいてパケットを比較するとき、上から下に検索を行い、一致した最初のルールに対するポリシーを適用します。それ以降のルールは、(最初のルールより一致率が高くても)すべて無視されます。したがって、特定のルールが無視されないようにするには、そのルールを汎用性の高いルールよりも上に配置する必要があります。IPv4 ルールがまったく一致しないケースを特定する場合、および冗長なルールを特定する場合は、自動競合検出ツールやポリシークエリツールを使用すると便利です。詳細については、自動競合検出の使用およびポリシー クエリー レポートの生成を参照してください。
次の方法でも、アクセス ルールを評価できます。
-
ルールを結合する:IPv4 ルールを評価するためのツールを使用し、各ルールを結合することによって、より少ない数のルールで同じ機能を実行できます。これにより、ルールのリストが縮小され、管理が簡単になります。詳細については、ルールの結合を参照してください。
-
ヒット カウントを生成する:IPv4 および IPv6 ACL のデバイスで管理されるヒット カウント統計を表示するためのツールを使用できます。これにより、ルールでトラフィックが許可または拒否された頻度がわかります。詳細については、ヒットカウントの詳細の表示を参照してください。
-
CS-MARS により収集されたイベントを表示する:デバイスをモニタするように Cisco Security Monitoring, Analysis and Response System アプリケーションを設定した場合、および syslog メッセージを生成するようにルールを設定した場合は、このアプリケーションを使用して、IPv4 ルールに関連するリアルタイムのイベントと過去のイベントを分析できます。詳細については、IPS シグニチャの CS-MARS イベントの表示を参照してください。
アクセス ルールの概念的な詳細については、次の項を参照してください。
関連項目
グローバル アクセス ルールについて
アクセル ルール(ACL)は、どのトラフィックがデバイスを通過できるかを制御するものであり、従来からデバイス インターフェイスに適用されています。ただし、ソフトウェア リリース 8.3+ が動作している ASA デバイスを使用している場合は、IPv4 および IPv6 に対してグローバル アクセス ルールを作成することもできます。
グローバル アクセス ルールは、デバイス上のインターフェイスごとに、インターフェイスに入るトラフィックに対して処理される特殊な ACL として定義します。このため、ACL はデバイスで 1 回だけ設定されますが、In 方向に対して定義されたインターフェイス固有のセカンダリ ACL のように機能します(グローバル ルールは常に、Out 方向ではなく In 方向に適用されます)。
ASA 8.3+ デバイス上のインターフェイスにトラフィックが入ると、デバイスは、ACL を適用する際に、まずインターフェイス固有のアクセス ルールをトラフィックに適用します。次に、グローバル ルールを適用します(全体的な処理については、ファイアウォール ルールの処理順序についてを参照してください)。
着信インターフェイスに関係なくデバイスに入ってくるすべてのトラフィックに適用するルールには、グローバル ルールを使用すると最適です。たとえば、常に拒否または常に許可する特定のホストまたはサブネットがあるとします。これらをグローバル ルールとして作成すると、デバイス上で 1 回だけ設定すれば、各インターフェイスに対して繰り返し設定する必要がありません(機能的には、[All-Interfaces] ロールに対してインターフェイス固有のルールを設定した場合と同じですが、[All-Interfaces] ルールはデバイス上で 1 回だけ設定するのではなく、各インターフェイスに対して繰り返して設定します)。
ヒント |
複数のデバイスに対して同じグローバル ルール セットを設定する場合は、共有ポリシーを作成して、デバイスごとに IPv4 または IPv6 アクセス ルール ポリシー内に継承します。すべてのグローバル ルールを共有ポリシーの [Default] セクション内に配置する必要があります。いずれかのグローバル ルールを [Mandatory] セクションに配置した場合は、ローカルなインターフェイス固有のアクセス ルールが定義されているデバイス上でそのルールを継承できなくなります。共有ポリシーおよび継承ポリシーの詳細については、ローカルポリシーと共有ポリシーおよびルールの継承についてを参照してください。 |
Security Manager で ASA 8.3+ デバイスに対してアクセス ルールを設定する場合、インターフェイス固有のルールとグローバル ルールは同じポリシー内に設定されます。ただし、デバイスでは常にインターフェイス固有のルールが最初に処理されるため、Security Manager ではこれらの異なるタイプのルールを混在させることはできません。そのため、1 つのデバイス上でインターフェイス固有のルールとグローバルルールの両方を設定する場合は、次の点に注意してください。
-
アクセス ルール ポリシー内では、常にグローバル ルールが最後に処理されます。インターフェイス固有のルールはいずれも、グローバル ルールよりも先に処理されます。
-
決められた順序に違反するようなルールの移動はできません。たとえば、インターフェイス固有のルールをグローバル ルールの下に移動したり、グローバル ルールをインターフェイス固有のルールの上に移動したりすることはできません。
-
決められた順序に違反する場所にルールを作成することはできません。たとえば、インターフェイス固有のルールを選択し、インターフェイス固有の別のルールをテーブル内でその次に配置した場合、グローバル ルールを作成することはできません。間違った種類のルールを作成しようとすると、ルールを保存するときに、Security Manager によって、ルールを最も近い有効な場所に作成できるかどうか尋ねられます。この提案を受け入れないと、ルールはテーブルに追加されません。提案された場所が不適切な場合は、ルールの作成後にいつでもルールを移動できます(ただし、ルールの順序に違反しない場合にかぎります)。
-
決められた順序に継承ポリシー内のルールが違反する場合、そのポリシーは継承できません。たとえば、デバイス ポリシー内にグローバル ルールを作成し、[Default] セクション内でインターフェイス固有のルールを含む共有ポリシーを継承しようとすると、Security Manager でそのポリシーが継承できなくなります。
-
共有ポリシーの割り当て後または継承後は、そのポリシーを使用するデバイス上のルール順序に違反するようなポリシーの編集はできません。
-
グローバル ルールをサポートしていないデバイス上で、グローバル ルールを含むポリシーを割り当てまたは継承した場合、そのデバイスではすべてのグローバル ルールが無視され、設定はされません。たとえば、共有ポリシー内のグローバル ルールでホスト 10.100.10.10 からのすべてのトラフィックを許可し、そのポリシーを IOS デバイスに割り当てた場合、10.100.10.10 アクセスを許可するルールは IOS デバイス上では設定されません。そのホストからのトラフィックは、別のインターフェイス固有ポリシーか、またはデフォルトの deny all ポリシーによって処理されます。グローバル ルールをサポートしないデバイスには、グローバル ルールを含む共有ポリシーを割り当てないようにすることを推奨します。そうすれば、グローバル ルールで定義されているポリシーが、サポートされていないデバイスで設定されていると誤解することがありません。
また、特定のツールでグローバル ルールが処理される方法に関して、いくつかの変更点があります。
-
Find/Replace:グローバル ルールは、Global というインターフェイス名を使用して検索できます。ただし、グローバル ルールとインターフェイス固有のルールを変換する方法はありません。グローバルルールはグローバルインターフェイス名を使用して検索できますが、インターフェイス名を「Global」という名前で置換しようとすると、実際には Global という名前のポリシーオブジェクトを使用する、インターフェイス固有のアクセスルールが作成されます。
-
Rule Combiner:インターフェイス固有のルールとグローバル ルールが結合されることはありません。
関連項目
デバイス固有のアクセス ルールの動作について
次に、アクセス ルール ポリシーを作成しない場合のデフォルトの動作をデバイス タイプに基づいて示し、アクセス ルールを作成したときに行われる処理を示します。
-
IOS デバイス:インターフェイスを通過するすべてのトラフィックを許可します。
送信元 A から宛先 B へのトラフィックを許可しているものの、インスペクション ルール テーブルに TCP/UDP インスペクションを設定していないか、ルールに [established] 拡張オプションを設定していない場合、デバイスは A から B へのパケットをすべて許可します。ただし、B から A に戻るパケットについては、そのパケットを許可するためのアクセスルールがないかぎり、パケットは許可されません。トラフィックのインスペクション ルール テーブルに TCP/UDP インスペクションを設定した場合、B から A に戻るパケットはいずれも自動的にデバイスを通過するため、アクセス ルール内に B から A を許可するルールは必要ありません。
-
ASA および PIX デバイス:高いセキュリティのインターフェイスから低いセキュリティのインターフェイスへのトラフィックを許可します。それ以外のトラフィックはすべて拒否されます。
アクセス ルールで単方向の TCP/UDP トラフィックが許可されている場合、アプライアンスによりリターン トラフィックが自動的に許可されます(リターン トラフィックのためのルールを設定する必要はありません)。ただし、ICMP トラフィックの場合は例外で、リターン ルールが必要となります(逆方向の送信元および宛先を許可します)。あるいは、ICMP のインスペクション ルールを作成する必要があります。
-
FWSM デバイス:インターフェイスに入るすべてのトラフィックを拒否し、インターフェイスを出るすべてのトラフィックを許可します。
デバイスに入るすべてのトラフィックを許可するためのアクセス ルールを設定する必要があります。
任意のタイプのデバイスに対してインターフェイスのルールを作成すると、デバイスによってポリシーの最後に暗黙的な [deny any] ルールが追加されます。このルールは、場所を忘れないように自分で追加することを推奨します。また、ルールを追加すると、ルールのヒット カウント情報を取得できます。詳細については、ヒットカウントの詳細の表示を参照してください。
ヒント |
アクセス ルール ポリシーを作成する場合、Security Manager サーバからデバイスへのアクセスを許可するルールを含める必要があります。そうしない場合、この製品を使用してデバイスを管理できなくなります。 |
関連項目
アクセス ルールのアドレス要件およびルールの展開方法について
コマンドライン インターフェイス(CLI)でオペレーティング システム コマンドを使用してアクセス制御リストを作成する場合の複雑な点の 1 つは、送信元アドレスと宛先アドレスの IP アドレス形式がオペレーティングシステムで異なっていることです。
たとえば、Cisco IOS Software では、サブネット マスクではなくワイルドカード マスクを使用してアドレスを入力する必要があります。10.100.10.0/24 ネットワーク(サブネット マスク 255.255.255.0)のルールを作成するには、アドレスを 10.100.10.0 0.0.0.255 として入力する必要があります。ワイルドカード マスクとサブネット マスクでは、0 と 1 の意味が逆になります。ただし、ASA、PIX、および FWSM ソフトウェアでは、サブネットマスクを使用するため、10.100.10.0 255.255.255.251 と入力します。
Security Manager では、アクセス ルールのアドレッシング要件が単純化されており、常にサブネット マスクを使用します。ワイルドカード マスクは入力できません。アクセス ルールをデバイスに展開すると、Security Manager によって、デバイスのオペレーティング システムが考慮され、必要に応じてサブネット マスクがワイルドカード マスクに自動変換されます。
このため、論理ポリシーに基づいて共有ルールを作成して、すべてのデバイスに適用することが可能になります。たとえば、すべてのデバイスで使用するアクセス ルール セットがある場合は、共有ポリシーを作成して、それをすべてのデバイスの継承ポリシーとして割り当てます。デバイスタイプごとに「適切な」構文を使用してルールを定義する必要はありません。他のポリシー タイプで使用する同じネットワーク/ホスト オブジェクトを使用して、対象のホストおよびネットワークを識別できます。
展開された設定内に生成される特定の CLI コマンドも、デバイス タイプに基づきます。IOS デバイスの場合、ip access-list コマンドを使用します。ASA、PIX、FWSM デバイスの場合、access-list または ipv6 access-list コマンドを使用し、access-group コマンドを使用してインターフェイスにバインドします。ASA、PIX、FWSM、および IOS 12.4(20)T 以降のデバイスでは、ネットワーク/ホストオブジェクトを使用してルールの送信元アドレスまたは宛先アドレスを識別する場合、それらのネットワーク/ホストオブジェクトに対してオブジェクトグループを作成するために、object-group コマンドを使用します。また、サービス オブジェクトに対してもオブジェクト グループが作成されます。
ヒント
-
ネットワーク/ホスト オブジェクトを使用してルールの送信元アドレスや宛先アドレスを識別でき、またルールに対して展開の最適化を設定できるため、アクセス ルールと ACL の CLI 定義内の ACE が必ずしも 1 対 1 の関係になるとはかぎりません。
-
ファイアウォール ルールから作成されるアクセス リストはすべて、(標準アクセス リストではなく)拡張アクセス リストです。[Access Control Settings] ページで ACL の名前を指定していない場合、Security Manager によってシステム生成名が ACL に適用されます。この名前は、名前が定義されているインターフェイスおよび方向に関連するすべてのルールが含まれる ACL に適用されます。
-
オブジェクト グループの展開方法を制御する展開オプションがいくつかあります。この項では、デフォルトの動作について説明します。[Deployment] ページ( を選択)で、ネットワーク/ホストオブジェクトからオブジェクトグループを作成するためのオプションの選択を解除できます。また、展開中にオブジェクト グループを最適化したり(ファイアウォール ルールの展開時のネットワーク オブジェクト グループの最適化を参照)、複数のサービスまたは送信元アドレスや宛先アドレスを持つルールから新しいオブジェクト グループを作成したり、使用していないオブジェクト グループを削除したりできます。
-
展開オプションには、アクセス ルールから生成される ACL の名前および作成される ACL の数を制御する設定も含まれます。デフォルトでは、Security Manager により、インターフェイスごとに一意の ACL が作成されます。このため、複数の重複する ACL が作成されることがあります。
[ファイアウォールルールに対するACL共有の有効化(Enable ACL Sharing for Firewall Rules)] を選択した場合、Cisco Security Manager は単一の ACL を作成して複数のインターフェイスに適用できるため、重複する不要な ACL は作成されません。ただし、ACL の共有が行われるのは、ACL 命名要件が保たれている間に実行できる場合にかぎります。
-
インターフェイスおよび方向に対して ACL 名を指定した場合は、その名前が常に使用されます。このため、重複する ACL が作成されることがあります。詳細については、アクセス コントロール ポリシー設定の指定を参照してください。
-
[ファイアウォールアクセルリスト名(Firewall Access-List Names)] プロパティの [既存の名前を再利用(Reuse Existing Names)] を選択すると、既存の名前は保存されます(アクセス制御設定ポリシーで名前をオーバーライドした場合を除く)。つまり、重複する ACL がデバイスにすでに存在する場合は、異なる名前で ACL が重複して作成されます。
ヒント:ACL 共有を最大限に利用するには、[ファイアウォールアクセスリスト名(Firewall Access-List Names)] プロパティに [CS-Managerの生成名にリセット(Reset to CS-Manager Generated Names)] を選択し、[アクセスルールの展開の最適化対象(Optimize the Deployment of Access Rules For)] プロパティに [速度(Speed)] を選択する必要があります。アクセス制御設定ポリシー内に ACL 名は設定しないでください。
[ファイアウォールルールに対するACL共有の有効化(Enable ACL Sharing for Firewall Rules)] プロパティの詳細については、[Deployment] ページを参照してください。
-
IPv4 および IPv6 ACL は同じ名前を持てません。