Cisco ASA シリーズファイアウォール ASDM コンフィギュレーションガイドソフトウェアバージョン 7.3

ルールに関する一般情報

この項では、アクセス ルールと EtherType ルールの両方について説明します。次の項目を取り上げます。

• 「インターフェイス アクセス ルールとグローバル アクセス ルール」

• 「インバウンド ルールとアウトバウンド ルール」

• 「ルールの順序」

• 「暗黙的な許可」

• 「暗黙的な拒否」

• 「NAT とアクセス ルール」

インターフェイス アクセス ルールとグローバル アクセス ルール

アクセス ルールを特定のインターフェイスに適用するか、またはアクセス ルールをすべてのインターフェイスにグローバルに適用できます。インターフェイス アクセス ルールと一緒にグローバル アクセス ルールを設定できます。この場合、特定のインバウンド インターフェイス アクセス ルールが常に汎用のグローバル アクセス ルールよりも先に処理されます。グローバル アクセス ルールは、インバウンド トラフィックにだけ適用されます。

インバウンド ルールとアウトバウンド ルール

トラフィックの方向に基づいてアクセス ルールを設定できます。

• インバウンド：インバウンド アクセス ルールは、インターフェイスに入ってくるトラフィックに適用されます。グローバル アクセス ルールおよび管理アクセス ルールは常にインバウンド ルールになります。

• アウトバウンド：アウトバウンド ルールは、インターフェイスから送信されるトラフィックに適用されます。

（注） 「インバウンド」および「アウトバウンド」は、インターフェイスにおける ACL の適用対象を表したもので、前者は、インターフェイスにおいて ASA により受信されるトラフィックに ACL が適用されることを表し、後者はインターフェイスにおいて ASA から送信されるトラフィックに ACL が適用されることを表しています。これらの用語は、一般にインバウンドと呼ばれる、低セキュリティ インターフェイスから高セキュリティ インターフェイスへのトラフィックの移動や、一般にアウトバウンドと呼ばれる、高セキュリティ インターフェイスから低セキュリティ インターフェイスへのトラフィックの移動を意味しません。

たとえば、内部ネットワーク上の特定のホストに限って、外部ネットワーク上の Web サーバにアクセスできるようにする場合などには、アウトバウンド ACL が有用です。複数のインバウンド ACL を作成してアクセスを制限することもできますが、指定したホストだけアクセスを許可するアウトバウンド ACL を 1 つだけ作成する方が効率的です （次の図を参照）。このアウトバウンド ACL を使用すれば、その他のホストが外部ネットワークへアクセスすることもできなくなります。

図 3-1 アウトバウンド ACL

ルールの順序

ルールの順序が重要です。ASA において、パケットを転送するかドロップするかの判断が行われる場合、ASA では、パケットと各ルールとの照合が、適用される ACL におけるそれらのルールの並び順に従って行われます。いずれかのルールに合致した場合、それ以降のルールはチェックされません。たとえば、先頭に作成したアクセス ルールが、インターフェイスに対してすべてのトラフィックを明示的に許可するものであれば、それ以降のルールはチェックされません。

暗黙的な許可

ルーテッド モードの場合、デフォルトでは次のタイプのトラフィックが許可されます。

• 高セキュリティ インターフェイスから低セキュリティ インターフェイスへの IPv4 および IPv6 のユニキャスト トラフィック。

トランスペアレント モードの場合、デフォルトでは次のタイプのトラフィックが許可されます。

• 高セキュリティ インターフェイスから低セキュリティ インターフェイスへの IPv4 および IPv6 のユニキャスト トラフィック。

• 双方向の ARP。ARP トラフィックの制御には ARP インスペクションを使用します。アクセス ルールでは制御できません。

• 双方向の BPDU。

他のトラフィックには、拡張アクセス ルール（IPv4 および IPv6）、または EtherType ルール（非 IP）のいずれかを使用する必要があります。

暗黙的な拒否

ACL の最後で暗黙的な拒否が設定されるため、明示的に許可しない限り、トラフィックは通過できません。たとえば、特定のアドレスを除くすべてのユーザに、ASA を通過してネットワークにアクセスすることを許可する場合、特定のアドレスを拒否したうえで、他のすべてのユーザを許可します。

EtherType ACL の場合、ACL の末尾にある暗黙的な拒否は、IP トラフィックや ARP には影響しません。たとえば、EtherType 8037 を許可する場合、ACL の末尾にある暗黙的な拒否によって、拡張 ACL で以前許可（または高セキュリティ インターフェイスから低セキュリティ インターフェイスへ暗黙的に許可）した IP トラフィックがブロックされることはありません。ただし、EtherType ルールですべてのトラフィックを明示的に拒否した場合は、IP と ARP のトラフィックが拒否され、物理的なプロトコルのトラフィック（自動ネゴシエーションなど）だけが許可されます。

グローバル アクセス ルールを設定すると、暗黙的な拒否はグローバル ルールが処理された 後 になります。次の動作の順序を参照してください。

1. インターフェイス アクセス ルール。

2. グローバル アクセス ルール。

3. 暗黙的な拒否。

NAT とアクセス ルール

アクセス ルールは、NAT を設定している場合でも、アクセス ルールの一致を決定する際に常に実際の IP アドレスを使用します。たとえば、内部サーバ 10.1.1.5 用の NAT を設定して、パブリックにルーティング可能な外部の IP アドレス 209.165.201.5 をこのサーバに付与する場合は、この内部サーバへのアクセスを外部トラフィックに許可するアクセス ルールの中で、サーバのマッピング アドレス（209.165.201.5）ではなく実際のアドレス（10.1.1.5）を参照する必要があります。

拡張アクセス ルール

この項では、拡張アクセス ルールについて説明します。

• 「リターン トラフィックに対する拡張アクセス ルール」

• 「アクセス ルールを使用したトランスペアレント ファイアウォールを介したブロードキャストとマルチキャスト トラフィックの許可」

• 「管理アクセス ルール」

リターン トラフィックに対する拡張アクセス ルール

ルーテッド モードとトランスペアレント モードの両方に対する TCP 接続および UDP 接続については、リターン トラフィックを許可するためのアクセス ルールは必要ありません。ASA は、確立された双方向接続のリターン トラフィックをすべて許可します。

ただし、ICMP などのコネクションレス型プロトコルについては、ASA は単方向セッションを確立します。したがって、（ACL を送信元インターフェイスと宛先インターフェイスに適用することで）アクセス ルールで双方向の ICMP を許可するか、ICMP インスペクション エンジンをイネーブルにする必要があります。ICMP インスペクション エンジンは、ICMP セッションを双方向接続として扱います。

アクセス ルールを使用したトランスペアレント ファイアウォールを介したブロードキャストとマルチキャスト トラフィックの許可

ルーテッド ファイアウォール モードでは、ブロードキャストとマルチキャスト トラフィックは、アクセス ルールで許可されている場合でもブロックされます。これには、サポートされていないダイナミック ルーティング プロトコルおよび DHCP（DHCP リレーを設定している場合を除く）が含まれます。トランスペアレント ファイアウォール モードでは、すべての IP トラフィックの通過を許可できます。

（注） これらの特殊なタイプのトラフィックはコネクションレス型であるため、アクセス ルールを両方のインターフェイスに適用して、リターン トラフィックの通過を許可する必要があります。

次の表に、トランスペアレント ファイアウォールの通過を許可できる一般的なトラフィック タイプを示します。

管理アクセス ルール

ASA 宛ての管理トラフィックを制御するアクセス ルールを設定できます。to-the-box 管理トラフィック（インターフェイスへの HTTP、Telnet、SSH などによる接続）に対するアクセス コントロール ルールは、管理アクセス ルールよりも優先されます。したがって、このような許可された管理トラフィックは、to-the-box ACL で明示的に拒否されている場合でも着信が許可されます。

また、デバイスへの ICMP トラフィックは、ICMP ルールを使用して制御できます。デバイスを通過する ICMP トラフィックの制御には、通常の拡張アクセス ルールを使用します。

EtherType ルール

この項では、EtherType ルールについて説明します。

• 「サポートされている EtherType およびその他のトラフィック」

• 「リターン トラフィックに対する EtherType ルール」

• 「MPLS の許可」

サポートされている EtherType およびその他のトラフィック

EtherType ルールは次を制御します。

• 一般的なタイプの IPX および MPLS ユニキャストまたはマルチキャストを含む、16 ビットの 16 進数値で示された EtherType。

• イーサネット V2 フレーム。

• デフォルトで許可される BPDU。BPDU は、SNAP でカプセル化されており、ASA は特別に BPDU を処理するように設計されています。

• トランク ポート（シスコ専用）BPDU。トランク BPDU のペイロードには VLAN 情報が含まれるので、BPDU を許可すると、ASA により、発信 VLAN を使用してペイロードが修正されます。

• Intermediate System to Intermediate System（IS-IS）。

次のタイプのトラフィックはサポートされていません。

• 802.3 形式フレーム：type フィールドではなく length フィールドが使用されるため、ルールでは処理されません。

リターン トラフィックに対する EtherType ルール

EtherType はコネクションレス型であるため、トラフィックを両方向に通過させる必要がある場合は、両方のインターフェイスにルールを適用する必要があります。

MPLS の許可

MPLS を許可する場合は、ラベル配布プロトコルおよびタグ配布プロトコルの TCP 接続が ASA を経由して確立されるようにしてください。これには、ASA インターフェイス上の IP アドレスを LDP セッションまたは TDP セッションの router-id として使用するように、ASA に接続されている両方の MPLS ルータを設定します （LDP および TDP を使用することにより、MPLS ルータは、転送するパケットに使用するラベル（アドレス）をネゴシエートできるようになります）。

Cisco IOS ルータで、使用プロトコル（LDP または TDP）に適したコマンドを入力します。 interface は、ASA に接続されているインターフェイスです。

または

アクセス ルールの設定

アクセス ルールを適用するには、次の手順を実行します。

手順

ルールはインターフェイスおよび方向別に構成され、グローバル ルールはそれらとは別のグループにまとめられています。管理アクセス ルールを設定する場合は、このページで繰り返されます。これらのグループが、作成されてアクセス グループとしてインターフェイスまたはグローバルに割り当てられた拡張 ACL に相当します。それらの ACL も [ACL Manager] ページに表示されます。

ステップ 2 次のいずれかを実行します。

• 新しいルールを追加するには、[Add] > [Add Access Rule] の順に選択します。

• コンテナ内の特定の場所にルールを挿入するには、追加する場所の下にある既存のルールを選択して [Add] > [Insert] の順に選択するか、[Add] > [Insert After] の順に選択します。

• ルールを編集するには、ルールを選択し、[Edit] をクリックします。

ステップ 3 ルールのプロパティを入力します。選択する主なオプションを次に示します。

• [Interface]：ルールを適用するインターフェイスを指定します。 グローバル ルールを作成する場合は [Any] を選択します。

• [Action]：[Permit] または [Deny]：対象のトラフィックを許可するか拒否（破棄）するかを指定します。

• [Source Criteria]/[Destination Criteria]：送信元（送信元アドレス）と宛先（トラフィック フローの送信先アドレス）を定義します。通常は、ネットワーク オブジェクトまたはネットワーク オブジェクト グループを使用して、ホストまたはサブネットの IPv4 アドレスまたは IPv6 アドレスを設定します。送信元については、ユーザ名またはユーザ グループ名を指定することも可能です。また、[Service] フィールドでトラフィックの種類を指定すると、すべての IP トラフィックではなく、特定のトラフィックを対象とするルールを作成できます。Trustsec を実装している場合は、セキュリティ グループを使用して送信元と宛先を定義できます。

使用可能なすべてのオプションの詳細については、「アクセス ルールのプロパティ」を参照してください。

ルールの定義が完了したら、[OK] をクリックしてルール テーブルに追加します。

ステップ 4 [Apply] をクリックし、アクセス ルールを設定に保存します。

アクセス ルールのプロパティ

アクセス ルールを追加または編集するときに設定できるプロパティを次に示します。多くのフィールドでは、編集ボックスの右にある [...] ボタンをクリックして、そのフィールドに対応するオブジェクトを選択、作成、編集できます。

• [Interface]：ルールを適用するインターフェイスを指定します。 グローバル ルールを作成する場合は [Any] を選択します。

• [Action]：[Permit] または [Deny]：対象のトラフィックを許可するか拒否（破棄）するかを指定します。

• [Source Criteria]：照合するトラフィックの送信元の特性を定義します。[Source] は必須ですが、それ以外のプロパティは省略可能です。

– [Source]：送信元の IPv4 アドレスまたは IPv6 アドレスを指定します。デフォルトは any で、すべての IPv4 アドレスと IPv6 アドレスが対象になります。IPv4 だけを対象にするには any4 、IPv6 だけを対象にするには any6 を使用します。単一のホスト アドレス（10.100.10.5 や 2001:DB8::0DB8:800:200C:417A など）、サブネット（10.100.10.0/24 や 10.100.10.0/255.255.255.0 の形式、IPv6 の場合は 2001:DB8:0:CD30::/60）、ネットワーク オブジェクトまたはネットワーク オブジェクト グループの名前、インターフェイスの名前を指定できます。

– [User]：アイデンティティ ファイアウォールをイネーブルにしている場合に、トラフィックの送信元としてユーザまたはユーザ グループを指定できます。ユーザが現在使用している IP アドレスがルールに一致します。ユーザ名（DOMAIN\user）、ユーザ グループ（DOMAIN\\group、グループ名の前に \ を 2 つ入力）、またはユーザ オブジェクト グループを指定できます。このフィールドでは、[...] をクリックすると、AAA サーバ グループから名前を選択できます。直接入力するよりもはるかに簡単です。

– [Security Group]：Cisco TrustSec をイネーブルにしている場合に、セキュリティ グループの名前またはタグ（1 ～ 65533）、あるいはセキュリティ グループを指定できます。

– [More Options] > [Source Service]：宛先サービスとして TCP または UDP を指定した場合に、必要に応じて、TCP、UDP、または TCP-UDP の事前定義済みのサービス オブジェクトを指定できます（独自のオブジェクトを使用することもできます）。通常は、宛先サービスだけを定義し、送信元サービスは定義しません。送信元サービスを定義する場合は、宛先サービスのプロトコルと一致する必要があることに注意してください（たとえば、ポートの定義に関係なく、どちらも TCP にするなど）。

• [Destination Criteria]：照合するトラフィックの送信先の特性を定義します。[Destination] は必須ですが、それ以外のプロパティは省略可能です。

– [Destination]：送信先の IPv4 アドレスまたは IPv6 アドレスを指定します。デフォルトは any で、すべての IPv4 アドレスと IPv6 アドレスが対象になります。IPv4 だけを対象にするには any4 、IPv6 だけを対象にするには any6 を使用します。単一のホスト アドレス（10.100.10.5 や 2001:DB8::0DB8:800:200C:417A など）、サブネット（10.100.10.0/24 や 10.100.10.0/255.255.255.0 の形式、IPv6 の場合は 2001:DB8:0:CD30::/60）、ネットワーク オブジェクトまたはネットワーク オブジェクト グループの名前、インターフェイスの名前を指定できます。

– [Security Group]：Cisco TrustSec をイネーブルにしている場合に、セキュリティ グループの名前またはタグ（1 ～ 65533）、あるいはセキュリティ グループを指定できます。

– [Service]：トラフィックのプロトコル（IP、TCP、UDP など）を指定します。TCP および UDP の場合は、必要に応じてポートも指定します。デフォルトは IP ですが、特定のプロトコルを選択することで対象のトラフィックを絞り込むことができます。通常は、サービス オブジェクトのタイプを選択します。TCP および UDP の場合はポートも指定できます。たとえば、tcp/80、tcp/http、tcp/10-20（ポートの範囲）、tcp-udp/80（ポート 80 の TCP と UDP のすべてのトラフィック）のように指定できます。

• [Description] ：ルールの目的の説明を入力します。1 行の最大文字数は 100 文字までで、 複数行を入力できます。CLI では、各行がコメントとして追加され、ルールの前に配置されます。

（注） 1 つのプラットフォーム（Windows など）上で英語以外の文字でコメントを追加し、それらの文字を別のプラットフォーム（Linux など）から削除しようとした場合、元の文字が正しく認識されないため編集や削除を実行できない可能性があります。この制限は、各種言語の文字をさまざまな方法でエンコードするプラットフォームの依存性によるものです。

• [Enable Logging]、[Logging Level]、[More Options] > [Logging Interval]：ルールに対する syslog メッセージの生成方法を定義します。これらのロギング オプションは、次のように実装できます。

– [Enable Logging] を選択解除： ルールのロギングがディセーブルになります。このルールに一致するトラフィックに対して、どのタイプの syslog メッセージも発行されません。

– [Enable Logging] を選択、[Logging Level] が [Default]：ルールに対してデフォルトのロギングが行われます。パケットが拒否されるたびに、syslog メッセージ 106023 が発行されます。アプライアンスが攻撃を受けると、このメッセージが頻繁に発行され、サービスに影響を及ぼす可能性があります。

– [Enable Logging] を選択、[Logging Level] が [Default] 以外：syslog メッセージ 106023 の代わりに、まとめて 106100 が発行されます。メッセージ 106100 は、最初のヒットがあったときに発行され、それ以降は [More Options] > [Logging Interval] で設定された間隔（デフォルトは 300 秒、1 ～ 600 秒の範囲で指定可能）で発行されてその間のヒット数を示します。推奨されるロギング レベルは [Informational] です。

拒否メッセージをまとめることで、攻撃による影響を軽減し、メッセージを分析しやすくなります。サービス拒否攻撃を受けた場合、メッセージ 106100 のヒット数を特定するために使用される拒否フローのキャッシュ数が間隔あたりの最大数を超えたことを示すメッセージ 106101 が表示されることがあります。この場合、攻撃を軽減するために、次の間隔の開始時点まで統計情報の収集が停止されます。

• [More Options] > [Traffic Direction]：ルールの方向（[In] または [Out]）を指定します。デフォルトは [In] で、グローバル アクセス ルールと管理アクセス ルールではこのオプションしか選択できません。

• [More Options] > [Enable Rule]：ルールをデバイスでアクティブにするかどうかを指定します。ディセーブルにしたルールは、ルール テーブルに取り消し線付きで表示されます。ルールをディセーブルにすると、削除せずにトラフィックへの適用を停止できるので、後で必要になったときに再度イネーブルにすることができます。

• [More Options] > [Time Range]：ルールをアクティブにする時間帯や曜日を定義した時間範囲オブジェクトの名前を指定します。時間範囲を指定しない場合、ルールは常にアクティブになります。

アクセス ルールの詳細オプションの設定

アクセス ルールの詳細オプションを使用して、ルールの動作の一部をカスタマイズすることができます。ただし、これらのオプションは、ほとんどの場合に適切に動作するようにデフォルトで設定されています。

ステップ 2 ルール テーブルの下にある [Advanced] ボタンをクリックします。

ステップ 3 次のオプションを必要に応じて設定します。

• [Advanced Logging Settings]：デフォルト以外のロギングを設定すると、メッセージ 106100 の統計情報を得るために拒否フローがキャッシュされます（「アクセス ルールの syslog メッセージの評価」を参照）。メモリおよび CPU リソースが無制限に消費されないようにするために、ASA は同時拒否フロー数に制限を設定します。これは、拒否フローが攻撃を示している可能性があるためです。この制限に達すると、メッセージ 106101 が発行されます。106101 について以下を設定できます。

– [Maximum Deny-flows]：ASA によりフローのキャッシュが停止される前に許可される拒否フローの最大数を、1 ～ 4096 の範囲で指定します。デフォルトは 4096 です。

– [Alert Interval]：拒否フローが最大数に達したことを示すシステム ログ メッセージ 106101 が発行される時間間隔（1 ～ 3600 秒）を指定します。デフォルトは 300 秒です。

• [Per User Override] テーブル：ユーザの認証用に RADIUS サーバからダウンロードしたダイナミック ユーザ ACL をインターフェイスに割り当てられた ACL よりも優先するかどうかを指定します。たとえば、インターフェイス ACL が 10.0.0.0 からのトラフィックをすべて拒否し、ダイナミック ACL が 10.0.0.0 からのトラフィックをすべて許可する場合、そのユーザに関しては、ダイナミック ACL によってインターフェイス ACL が上書きされます。ユーザの上書きを許可する各インターフェイスについて、[Per User Override] チェックボックスをオンにします（インバウンド方向のみ）。ユーザごとの上書き機能がディセーブルになると、RADIUS サーバによって提供されるアクセス ルールは、そのインターフェイス上で設定されたアクセス ルールと結合されます。

デフォルトでは、VPN リモート アクセス トラフィックはインターフェイス ACL と照合されません。ただし、[Enable inbound VPN sessions to bypass interface access lists] 設定（[Configuration] > [Remote Access VPN] > [Network (Client) Access] > [AnyConnect Connection Profiles] ペイン）の選択を解除した場合は、グループ ポリシーで VPN フィルタが適用されているかどうか（[Configuration] > [Remote Access VPN] > [Network (Client) Access] > [Group Policies] > [Add/Edit] > [General] > [More Options] > [Filter] フィールド）、および [Per User Override] オプションを設定しているかどうかによって動作が異なります。

– [Per User Override] なし、VPN フィルタなし：トラフィックはインターフェイス ACL と照合されます。

– [Per User Override] なし、VPN フィルタ：トラフィックはまずインターフェイス ACL と照合され、次に VPN フィルタと照合されます。

– [Per User Override]、VPN フィルタ：トラフィックは VPN フィルタのみと照合されます。

• [Object Group Search Setting]：[Enable Object Group Search Algorithm] を選択すると、ルックアップのパフォーマンスは低下しますが、オブジェクト グループを使用するアクセス ルールの検索に必要なメモリを抑えることができます。オブジェクト グループ検索をイネーブルにした場合、ネットワーク オブジェクトは拡張されませんが、それらのグループの定義に基づいて一致するアクセス ルールが検索されます。

ステップ 4 [OK] をクリックします。

管理アクセス ルールの設定

特定のピア（または複数のピア）から ASA への to-the-box 管理トラフィックを制御するインターフェイス ACL を設定できます。このタイプの ACL は、IKE DoS（サービス拒絶）攻撃をブロックする場合などに有用です

to-the-box トラフィックのパケットを許可または拒否する拡張 ACL を設定するには、次の手順を実行します。

ステップ 1 [Configuration] > [Device Management] > [Management Access] > [Management Access Rules] を選択します。

ルールはインターフェイス別に構成されています。各グループが、作成されてコントロール プレーン ACL としてインターフェイスに割り当てられた拡張 ACL に相当します。それらの ACL も [Access Rules] ページおよび [ACL Manager] ページに表示されます。

ステップ 2 次のいずれかを実行します。

• 新しいルールを追加するには、[Add] > [Add Management Access Rule] の順に選択します。

• コンテナ内の特定の場所にルールを挿入するには、追加する場所の下にある既存のルールを選択して [Add] > [Insert] の順に選択するか、[Add] > [Insert After] の順に選択します。

• ルールを編集するには、ルールを選択し、[Edit] をクリックします。

ステップ 3 ルールのプロパティを入力します。選択する主なオプションを次に示します。

• [Interface]：ルールを適用するインターフェイスを指定します。

• [Action]：[Permit] または [Deny]：対象のトラフィックを許可するか拒否（破棄）するかを指定します。

• [Source Criteria]/[Destination Criteria]：送信元（送信元アドレス）と宛先（トラフィック フローの送信先アドレス）を定義します。通常は、ネットワーク オブジェクトまたはネットワーク オブジェクト グループを使用して、ホストまたはサブネットの IPv4 アドレスまたは IPv6 アドレスを設定します。送信元については、ユーザ名またはユーザ グループ名を指定することも可能です。また、[Service] フィールドでトラフィックの種類を指定すると、すべての IP トラフィックではなく、特定のトラフィックを対象とするルールを作成できます。Trustsec を実装している場合は、セキュリティ グループを使用して送信元と宛先を定義できます。

使用可能なすべてのオプションの詳細については、「アクセス ルールのプロパティ」を参照してください。

ルールの定義が完了したら、[OK] をクリックしてルール テーブルに追加します。

ステップ 4 [Apply] をクリックし、ルールを設定に保存します。

EtherType ルールの設定（トランスペアレント モードのみ）

EtherType ルールは、トランスペアレント ファイアウォール モードの IP 以外のレイヤ 2 トラフィックに適用されます。これらのルールを使用して、レイヤ 2 パケット内の EtherType 値に基づいてトラフィックを許可または破棄できます。EtherType ルールでは、ASA を経由する IP 以外のトラフィックのフローを制御できます。

トランスペアレント モードでは、拡張アクセス ルールと EtherType アクセス ルールの両方をインターフェイスに適用できます。EtherType ルールは、拡張アクセス ルールに優先されます。

EtherType ルールを追加するには、次の手順を実行します。

ルールはインターフェイスおよび方向別に構成されています。各グループが、作成されてインターフェイスに割り当てられた EtherType ACL に相当します。

ステップ 2 次のいずれかを実行します。

• 新しいルールを追加するには、[Add] > [Add EtherType Rule] の順に選択します。

• コンテナ内の特定の場所にルールを挿入するには、追加する場所の下にある既存のルールを選択して [Add] > [Insert] の順に選択するか、[Add] > [Insert After] の順に選択します。

• ルールを編集するには、ルールを選択し、[Edit] をクリックします。

ステップ 3 ルールのプロパティを入力します。選択する主なオプションを次に示します。

• [Interface]：ルールを適用するインターフェイスを指定します。

• [Action]：[Permit] または [Deny]：対象のトラフィックを許可するか拒否（破棄）するかを指定します。

• [EtherType]：次のオプションを使用してトラフィックを照合できます。

– ipx ：Internet Packet Exchange（IPX）。

– bpdu ：ブリッジ プロトコル データ ユニット。デフォルトで許可されます。

– mpls-multicast ：MPLS マルチキャスト。

– mpls-unicast ：MPLS ユニキャスト。

– isis ：Intermediate System to Intermediate System（IS-IS）。

– any ：すべてのトラフィック。

– hex_number ：16 ビットの 16 進数値（0x600 ～ 0xffff）で示された任意の EtherType。EtherType のリストについては、http://www.ietf.org/rfc/rfc1700.txt にアクセスして、RFC 1700「Assigned Numbers」を参照してください。

• [Description] ：ルールの目的の説明を入力します。1 行の最大文字数は 100 文字までで、 複数行を入力できます。CLI では、各行がコメントとして追加され、ルールの前に配置されます。

• [More Options] > [Direction]：ルールの方向（[In] または [Out]）を指定します。デフォルトは [In] です。

ルールの定義が完了したら、[OK] をクリックしてルール テーブルに追加します。

ステップ 4 [Apply] をクリックし、ルールを設定に保存します。

ICMP アクセス ルールの設定

デフォルトでは、IPv4 または IPv6 を使用して任意の ASA インターフェイスに ICMP パケットを送信できます。ただし、次の例外があります。

• ASA は、ブロードキャスト アドレス宛ての ICMP エコー要求に応答しません。

• ASAは、トラフィックが着信するインターフェイス宛ての ICMP トラフィックにのみ応答します。ICMP トラフィックは、インターフェイス経由で離れたインターフェイスに送信できません。

デバイスを攻撃から保護するために、ICMP ルールを使用して、ASA インターフェイスへの ICMP アクセスを特定のホスト、ネットワーク、または ICMP タイプに限定できます。ICMP ルールにはアクセス ルールと同様に順序があり、パケットに最初に一致したルールの処理が適用されます。

インターフェイスに対して any ICMP ルールを設定すると、ICMP ルールのリストの最後に暗黙の deny ICMP ルールが追加され、デフォルトの動作が変更されます。そのため、一部のメッセージ タイプだけを拒否する場合は、残りのメッセージ タイプを許可するように ICMP ルールのリストの最後に permit any ルールを含める必要があります。

ICMP 到達不能メッセージ タイプ（タイプ 3）の権限を常に付与することを推奨します。ICMP 到達不能メッセージを拒否すると、ICMP パス MTU ディスカバリがディセーブルになって、IPSec および PPTP トラフィックが停止することがあります。また、IPv6 の ICMP パケットは、IPv6 のネイバー探索プロセスに使用されます。パス MTU ディスカバリの詳細については、RFC 1195 および RFC 1435 を参照してください。

手順

ステップ 1 [Configuration] > [Device Management] > [Management Access] > [ICMP] を選択します。

ステップ 2 ICMP ルールを設定します。

a. ルールを追加する（[Add] > [Rule]、[Add] > [IPv6 Rule]、または [Add] > [Insert]）か、ルールを選択して編集します。

b. 制御する ICMP タイプを選択します。すべてのタイプに適用する場合は any を選択します。

c. ルールを適用するインターフェイスを選択します。各インターフェイスに対して個別にルールを作成する必要があります。

d. 一致したトラフィックに対してアクセスを許可するか拒否するかを選択します。

e. すべてのトラフィックにルールを適用する場合は、[Any Address] を選択します。特定のホストまたはネットワークを制御する場合は、アドレスとマスク（IPv4 の場合）またはアドレスとプレフィックス長（IPv6 の場合）を入力します。

f. [OK] をクリックします。

ステップ 3 （オプション）ICMP の到達不能メッセージに対する制限は、次の各オプションを使用して設定します。ASA をホップの 1 つとして表示するトレース ルートに対して ASA の通過を許可するためには、サービス ポリシーで [Decrement time to live for a connection] オプション（[Configuration] > [Firewall] > [Service Policy Rules] > [Rule Actions] > [Connection Settings] ダイアログボックス）をイネーブルにするほか、レート制限を大きくする必要があります。

• [Rate Limit]：到達不能メッセージのレート制限を、1 秒あたり 1 ～ 100 の範囲で設定します。デフォルトは、1 秒あたり 1 メッセージです。

• [Burst Size]：バースト レートを 1 ～ 10 の範囲で設定します。このキーワードは、現在システムで使用されていないため、任意の値を選択できます。

ステップ 4 [Apply] をクリックします。

アクセス ルールの syslog メッセージの評価

アクセス ルールに関するメッセージは、syslog イベントのビューア（ASDM のビューアなど）を使用して確認できます。

デフォルトのロギングを使用している場合、明示的に拒否されたフローに対する syslog メッセージ 106023 だけが表示されます。ルールのリストの最後にある「暗黙の deny」に一致するトラフィックは記録されません。

ASA が攻撃を受けた場合、拒否されたパケットを示す syslog メッセージの数が非常に大きくなることがあります。代わりに、syslog メッセージ 106100 を使用するロギングをイネーブルにすることをお勧めします。このメッセージは各ルール（許可ルールも含む）の統計情報を示すもので、これを使用することにより、生成される syslog メッセージの数を制限できます。また、特定のルールについて、すべてのロギングをディセーブルにする方法もあります。

メッセージ 106100 のロギングがイネーブルで、パケットが ACE と一致した場合、ASA はフロー エントリを作成して、指定された時間内で受信したパケットの数を追跡します。ASA は、最初のヒットがあったとき、および各間隔の終わりに syslog メッセージを生成し、その間隔におけるヒットの合計数と最後のヒットのタイムスタンプを示します。各間隔の終わりに、ASA はヒット数を 0 にリセットします。1 つの間隔内で ACE と一致するパケットがなかった場合、ASA はそのフロー エントリを削除します。ルールのロギングの設定では、それぞれのルールについて、ログ メッセージの間隔のほか、重大度も制御することができます。

フローは、送信元 IP アドレス、宛先 IP アドレス、プロトコル、およびポートで定義されます。同じ 2 つのホスト間の新しい接続では、送信元ポートが異なる場合があるため、接続のための新しいフローが作成されると、同じフローの増加は示されない場合があります。

確立された接続に属する、許可されたパケットを ACL でチェックする必要はありません。最初のパケットだけがロギングされ、ヒット数に含められます。ICMP などのコネクションレス型プロトコルの場合は、許可されているパケットもすべてロギングされ、拒否されたパケットはすべてロギングされます。

これらのメッセージの詳細については、 syslog メッセージ ガイド を参照してください。

ヒント メッセージ 106100 のロギングがイネーブルで、パケットが ACE と一致した場合、ASA はフロー エントリを作成して、指定された時間内で受信したパケットの数を追跡します。ASA では、ACE 用のロギング フローを最大 32 K 保持できます。どの時点でも大量のフローが同時に存在する可能性があります。メモリおよび CPU リソースが無制限に消費されないようにするために、ASA は同時拒否フロー数に制限を設定します。この制限は、拒否フローに対してだけ設定されます（許可フローには設定されません）。これは、拒否フローは攻撃を示している可能性があるためです。制限に達すると、ASA は既存の拒否フローが期限切れになるまでロギング用の新しい拒否フローを作成せず、メッセージ 106101 を発行します。このメッセージの頻度、および拒否フローのキャッシュの最大数は、詳細設定で制御できます。「アクセス ルールの詳細オプションの設定」を参照してください。