セキュリティ・ルール

ネットワーキング・サービスには、パケット・レベルでトラフィックを制御するためにセキュリティ・ルールを使用する2つの仮想ファイアウォール機能が用意されています。2つの機能は:

  • セキュリティ・リスト: ネットワーキング・サービスによる元の仮想ファイアウォール機能。
  • ネットワーク・セキュリティ・グループ(NSG): 異なるセキュリティ体制を持つアプリケーション・コンポーネント用に設計された後続の機能。NSGは特定のサービスに対してのみサポートされます。

これらの2つの機能は、仮想クラウド・ネットワーク(VCN)内の仮想ネットワーク・インタフェース・カード(VNIC)のセットにセキュリティ・ルールを適用する様々な方法を提供します。

このトピックでは、2つの機能の基本的な相違点について説明します。また、理解しておく必要のある、重要なセキュリティ・ルールの概念についても説明します。セキュリティ・ルールの作成、管理および適用方法は、セキュリティ・リストとネットワーク・セキュリティ・グループでは異なります。実装の詳細は、次の関連トピックを参照してください:

セキュリティ・リストとネットワーク・セキュリティ・グループの比較

セキュリティ・リストを使用すると、サブネット全体のすべてのVNICに適用されるセキュリティ・ルールのセットを定義できます。特定のサブネットで指定のセキュリティ・リストを使用するには、サブネットの作成中または作成後に、そのサブネットにセキュリティ・リストを関連付けます。サブネットは、最大5つのセキュリティ・リストに関連付けることができます。そのサブネットに作成されるVNICはすべて、そのサブネットに関連付けられているセキュリティ・リストの対象となります。

ネットワーク・セキュリティ・グループ(NSG)を使用すると、選択したVNICのグループ(またはVNICのロード・バランサやDBシステムなどの親リソース)に適用されるセキュリティ・ルールのセットを定義できます。たとえば、すべて同じセキュリティ体制を持つコンピュート・インスタンスのセットに属するVNICです。指定したNSGを使用するには、目的のVNICをグループに追加します。そのグループに追加されたVNICは、すべてそのグループのセキュリティ・ルールの対象となります。VNICは、最大5つのNSGに追加できます。

次の図は、この概念を示しています。

ネットワーク・セキュリティ・グループとセキュリティ・リストの比較。

NSGでは、VCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストのかわりにNSGを使用することをお薦めします。

ただし、必要であれば、セキュリティ・リストとNSGを両方とも使用できます。詳細は、セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合を参照してください。

VNICと親リソースについて

VNICは、ネットワーキング・サービス・コンポーネントであり、コンピュート・インスタンスなどのネットワーク・リソースが仮想クラウド・ネットワーク(VCN)に接続できるようにします。VNICは、インスタンスがVCNの内外のエンドポイントと接続する方法を決定します。各VNICは、VCN内のサブネットに存在します。

コンピュート・インスタンスを作成すると、そのインスタンスのサブネット内のインスタンスにVNICが自動的に作成されます。インスタンスは、VNICの親リソースとみなされます。コンピュート・インスタンスに別の(セカンダリ) VNICを追加できます。このため、インスタンスのVNICは、コンピュート・インスタンスの関連リソースの一部として、コンソールに目立つように表示されます。

他にも、VNICが自動的に作成される、ユーザーが作成可能な親リソースのタイプがあります。たとえば、ロード・バランサを作成すると、ロード・バランシング・サービスによって、バックエンド・セット間のトラフィックを分散するためにVNICが自動的に作成されます。また、DBシステムを作成すると、データベース・サービスによって、DBシステム・ノードとしてVNICが自動的に作成されます。これらのサービスにより、VNICが作成および管理されます。そのため、これらのVNICは、コンピュート・インスタンスのVNICと同じようにわかりやすくコンソール内に表示されません。

NSGを使用するには、選択したVNICをグループに配置します。ただし、VNIC自体ではなく、グループにVNICを追加する場合、通常は親リソースを使用します。たとえば、コンピュート・インスタンスを作成するときに、オプションでそのインスタンスにNSGを指定できます。概念的にはインスタンスをグループに配置しますが、実際にはインスタンスのプライマリVNICをネットワーク・セキュリティ・グループに配置します。グループのセキュリティ・ルールは、インスタンスではなくVNICに適用されます。また、セカンダリVNICをインスタンスに追加する場合、オプションでそのVNICにNSGを指定でき、ルールはインスタンスではなくそのVNICに適用されます。指定されたNSG内のすべてのVNICが、そのNSGが属するVCN内にある必要があります。

同様に、ネットワーク・セキュリティ・グループにロード・バランサを配置する場合、概念的にはロード・バランサをグループに配置します。ただし、実際にはロード・バランシング・サービスによって管理されるVNICを、ネットワーク・セキュリティ・グループに配置することになります。

NSGのVNICメンバーシップは親リソースで管理し、NSG自体では管理しません。つまり、親リソースをNSGに追加するには、(親リソースを追加するNSGを指定することで)親リソースに対してアクションを実行します。(NSGに追加するVNICまたは親リソースを指定することで) NSGに対してアクションを実行しません。同様に、VNICをNSGから削除するには、NSGではなく親リソースを更新してそのアクションを実行します。たとえば、既存のコンピュート・インスタンスのVNICをNSGに追加するには、VNICのプロパティを更新してNSGを指定します。たとえば、REST APIを使用して、UpdateVnicをコールします。コンソールで、インスタンスおよび目的のVNICを表示し、そこでVNICのプロパティを編集します。

NSGの使用をサポートする親リソースのリストについては、ネットワーク・セキュリティ・グループのサポートを参照してください。

ルールのソースまたは宛先としてのネットワーク・セキュリティ・グループ

セキュリティ・リストと比較して、NSGのセキュリティ・ルールを記述する方法には、重要な違いがあります。

NSGのルールを記述する場合、トラフィックのソース(イングレス・ルールの場合)またはトラフィックの宛先(エグレス・ルールの場合)としてNSGを指定できます。これとは対照的に、セキュリティ・リスト・ルールでは、ソースまたは宛先としてCIDRを指定します。

NSGを指定できるため、2つの異なるNSG間のトラフィックを制御するルールを容易に記述できます。各NSGは同じVCN内にある必要があります。

また、特定のNSGにあるVNIC間のトラフィックを制御する場合は、ルール独自のNSGをソース(イングレス・ルールの場合)または宛先(エグレス・ルールの場合)として指定するルールを記述できます。

詳細は、ネットワーク・セキュリティ・グループの概要を参照してください。

REST APIの相違点

セキュリティ・リストと比較して、NSGのREST APIモデルにはいくつかの基本的な違いがあります。詳細は、APIの使用を参照してください。

デフォルト・ルール

VCNには、ネットワーキング・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。サブネットを作成するとき、VCNですでに作成したカスタム・セキュリティ・リストを指定しないかぎり、デフォルト・セキュリティ・リストがサブネットに関連付けられます。比較すると、VCNにはデフォルトのネットワーク・セキュリティ・グループはありません。

制限

2つの機能の制限は異なります。

セキュリティ・リストの制限

リソース

スコープ

月次ユニバーサル・クレジット

Pay-as-You-Goまたはプロモーション

セキュリティ・リスト VCN 300 300
セキュリティ・リスト サブネット 5* 5*
セキュリティ・ルール セキュリティ・リスト

200イングレス・ルール*

および

200エグレス・ルール*

200イングレス・ルール*

および

200エグレス・ルール*

* このリソースの制限を増やすことはできません
ネットワーク・セキュリティ・グループの制限

リソース

スコープ

月次ユニバーサル・クレジット

Pay-as-You-Goまたはプロモーション

ネットワーク・セキュリティ・グループ VCN 1000 1000
VNIC ネットワーク・セキュリティ・グループ

特定のネットワーク・セキュリティ・グループには、VCN内と同じ数のVNICを含めることができます。

特定のVNICは、最大5つのネットワーク・セキュリティ・グループに属することができます。*

特定のネットワーク・セキュリティ・グループには、VCN内と同じ数のVNICを含めることができます。

特定のVNICは、最大5つのネットワーク・セキュリティ・グループに属することができます。*

セキュリティ・ルール ネットワーク・セキュリティ・グループ

500 (イングレスとエグレスの合計)*

500 (イングレスとエグレスの合計)*

* このリソースの制限を増やすことはできません

セキュリティ・ルールのベスト・プラクティス

ネットワーク・セキュリティ・グループを使用します

すべて同じセキュリティ体制を持つコンポーネントにはNSGを使用することをお薦めします。たとえば、複数層アーキテクチャでは、各層に対して個別のNSGを使用します。指定された層のVNICは、すべてその層のNSGに属します。特定の層内に、追加の特別なセキュリティ要件を持つ層のVNICの特定のサブセットが存在する可能性があります。そのため、これらの追加ルールに対して別のNSGを作成し、VNICのサブセットを層のNSGと追加のNSGの両方に配置します。

Oracleでは、将来の拡張機能を実装するときに、セキュリティ・リストよりもNSGを優先する予定のため、NSGの使用が推奨されます。

デフォルト・セキュリティ・リストのルールを理解します

VCNには、ネットワーキング・サービスの使用を開始する際に役立つデフォルトのセキュリティ・ルールがいくつか含まれているデフォルト・セキュリティ・リストが自動的に付属しています。これらのルールは、基本的な接続を可能にするために存在します。セキュリティ・リストやデフォルト・セキュリティ・リストを使用しない場合でも、ネットワーク接続されたクラウド・リソースが必要とするトラフィックのタイプをよく理解できるように、ルールに精通してください。このようなルールは、NSGで、または設定したカスタム・セキュリティ・リストで使用できます。

デフォルト・セキュリティ・リストには、pingを有効にするルールは含まれていません。pingを使用する必要がある場合は、Pingを有効化するルールを参照してください。

デフォルト・セキュリティ・ルールを無計画に削除しないでください

VCNに、デフォルト・セキュリティ・リストをデフォルトで使用するサブネットがある場合があります。最初にVCNのリソースでそれらが必要でないことを確認した場合を除き、リストのデフォルト・セキュリティ・ルールは削除しないでください。そうしないと、VCNの接続が中断されることがあります。

OSファイアウォール・ルールがセキュリティ・ルールと一致することを確認します

Oracle提供のLinuxイメージまたはWindowsイメージを実行しているインスタンスには、そのインスタンスへのアクセスを制御するOSファイアウォール・ルールもあります。インスタンスへのアクセスのトラブルシューティングを行う場合は、次の項目がすべて正しく設定されていることを確認してください:

  • インスタンスが存在するネットワーク・セキュリティ・グループ内のルール
  • インスタンスのサブネットに関連付けられているセキュリティ・リスト内のルール
  • インスタンスのOSファイアウォール・ルール

詳細は、Oracle提供のイメージを参照してください。

インスタンスでOracle Autonomous Linux 7、Oracle Linux 8またはOracle Linux 7を実行している場合は、iptablesルールと相互作用するにはfirewalldを使用する必要があります。参照用に、ポート(この例では1521)をオープンするためのコマンドを次に示します:

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

ISCSIブート・ボリュームを持つインスタンスでは、前述の--reloadコマンドで問題が発生することがあります。詳細および回避策については、firewall-cmd --reloadの実行後にインスタンスでシステム・ハングが発生しますを参照してください。

セキュリティ・ルールのためにドロップされたパケットのトラブルシューティングにはVNICメトリックを使用します

ネットワーキング・サービスはVNICのメトリックを提供し、それがVNICトラフィックのレベル(パケットおよびバイト)を示します。2つのメトリックは、セキュリティ・ルールに違反してドロップされるイングレス・パケットおよびエグレス・パケット用です。これらのメトリックを使用すると、セキュリティ・ルールに関連する問題をトラブルシューティングしたり、VNICが目的のトラフィックを受信するかどうかをトラブルシューティングするのに役立ちます。

セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合

セキュリティ・リストのみ、ネットワーク・セキュリティ・グループのみ、またはその両方を使用できます。これは、特定のセキュリティ・ニーズに依存します。

VCN内のすべてのVNICに適用するセキュリティ・ルールがある場合: 最も簡単な解決策は、ルールを1つのセキュリティ・リストに配置し、そのセキュリティ・リストをVCN内のすべてのサブネットに関連付けることです。これにより、組織内の誰がVCNでVNICを作成するかに関係なく、ルールを確実に適用できます。必要に応じて、VCNのデフォルト・セキュリティ・リストを使用できます。このリストは、VCNに自動的に付属しており、デフォルトで一連の必須ルールが含まれています。

セキュリティ・リストとネットワーク・セキュリティ・グループの両方を使用する場合、特定のVNICに適用される一連のルールは次のアイテムを結合したものになります:

  • VNICのサブネットに関連付けられているセキュリティ・リスト内のセキュリティ・ルール
  • VNICが存在するすべてのNSGのセキュリティ・ルール

次の図は、この概念を簡単に説明したものです。

VNICは、それが存在するすべてのネットワーク・セキュリティ・グループ内およびサブネットに関連付けられているすべてのセキュリティ・リスト内のルールの対象となります。

関連するいずれかのリストおよびグループのルールでトラフィックを許可する場合(またはトラフィックが既存のトラッキング対象の接続の一部である場合)、目的のパケットは許可されます。同じトラフィックをカバーするステートフル・ルールとステートレス・ルールの両方がリストに含まれる場合は注意が必要です。詳細は、ステートフル・ルールとステートレス・ルールを参照してください。

セキュリティ・ルールの構成要素

セキュリティ・ルールにより、VNIC内外の特定タイプのトラフィックを許可できます。たとえば、一般的に使用されるセキュリティ・ルールでは、インスタンス(具体的にはインスタンスのVNIC)へのSSH接続を確立するためにTCPポート22のイングレス・トラフィックを許可します。セキュリティ・ルールを使用しない場合、VCNのVNIC内外のトラフィックは許可されません。

ノート

169.254.0.0/16 CIDRブロックを含むトラフィックに対しては、セキュリティ・ルールは適用されません。これには、iSCSIやインスタンス・メタデータなどのサービスが含まれます。

各セキュリティ・ルールは次の項目を指定します:

  • 方向(イングレスまたはエグレス): イングレスはVNICへのインバウンド・トラフィックで、エグレスはVNICからのアウトバウンド・トラフィックです。セキュリティ・リスト用のREST APIモデルは、ネットワーク・セキュリティ・グループとは異なります。セキュリティ・リストには、IngressSecurityRuleオブジェクトと個別のEgressSecurityRuleオブジェクトがあります。ネットワーク・セキュリティ・グループには、SecurityRuleオブジェクトのみが存在し、オブジェクトのdirection属性によって、ルールがイングレス・トラフィック用かエグレス・トラフィック用かが決定されます。
  • ステートフルまたはステートレス: ステートフルの場合は、ルールに一致するトラフィックに接続トラッキングが使用されます。ステートレスの場合、接続トラッキングは使用されません。ステートフル・ルールとステートレス・ルールを参照してください。
  • ソース・タイプおよびソース(イングレス・ルールのみ): イングレス・ルールに対して指定するソースは、選択したソース・タイプによって異なります。

    許可されるソース・タイプ
    ソース・タイプ 許可されるソース
    CIDR トラフィックの発生元のCIDRブロック。0.0.0.0/0を使用して、すべてのIPアドレスを指定します。接頭辞が必要です(たとえば、個々のIPアドレスを指定する場合は/32を含めます)。
    ネットワーク・セキュリティ・グループ

    このルールのNSGと同じVCN内にあるNSG。

    このソース・タイプは、ルールがNSGに属し、セキュリティ・リストには属していない場合にのみ使用できます。

    サービス

    サービス・ゲートウェイを介してOracleサービスから受信するパケットのみ。

    ソース・サービスは、目的のサービスCIDRラベルです。

  • 宛先タイプおよび宛先(エグレス・ルールのみ): エグレス・ルールに対して指定する宛先は、選択した宛先タイプによって異なります。

    許可される宛先タイプ
    宛先タイプ 許可される宛先
    CIDR トラフィックの宛先になるCIDRブロック。0.0.0.0/0を使用して、すべてのIPアドレスを指定します。接頭辞が必要です(たとえば、個々のIPアドレスを指定する場合は/32を含めます)。
    ネットワーク・セキュリティ・グループ

    このルールのNSGと同じVCN内にあるNSG。

    この宛先タイプは、ルールがNSGに属し、セキュリティ・リストには属していない場合にのみ使用できます。

    サービス

    サービス・ゲートウェイを介してOracleサービスに送信するパケットのみ。

    宛先サービスは、目的のサービスCIDRラベルです。

  • IPプロトコル: 単一のIPv4プロトコル、またはすべてのプロトコルをカバーする場合は「all」。
  • ソース・ポート: トラフィックの発生元のポート。TCPまたはUDPの場合、すべてのソース・ポートを指定するか、オプションで単一のソース・ポート番号または範囲を指定できます。
  • 宛先ポート: トラフィックの宛先のポート。TCPまたはUDPの場合、すべての宛先ポートを指定するか、オプションで単一の宛先ポート番号または範囲を指定できます。
  • ICMPタイプおよびコード: ICMPの場合、すべてのタイプおよびコードを指定することも、オプションで単一のタイプとオプション・コードを指定することもできます。タイプに複数のコードがある場合は、許可するコードごとに別々のルールを作成します。
  • 説明(NSGルールのみ): NSGセキュリティ・ルールには、ルールのわかりやすい説明を指定できるオプションの属性が含まれます。これは現在、セキュリティ・リスト・ルールではサポートされていません。

セキュリティ・ルールの例については、ネットワーキング・シナリオを参照してください。

使用できるルールの数の制限については、セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。

ノート

NSGを使用していて、同じVCN内の2つのVNICがパブリックIPアドレスを使用して通信する必要がある場合、VNICのパブリックIPアドレスを使用する必要があります。関連するセキュリティ・ルールのソース(イングレスの場合)または宛先(エグレスの場合)として、VNICのNSGを使用しないでください。パケットはVCNのインターネット・ゲートウェイにルーティングされ、その時点ではVNICのNSG情報は使用できません。そのため、ソースまたは宛先としてNSGを指定するセキュリティ・ルールは、特定タイプのトラフィックを許可する場合に無効になります。

ステートフル・ルールとステートレス・ルール

セキュリティ・ルールを作成する際には、ステートフルステートレスのどちらにするかを選択します。その違いについては、次の項で説明します。デフォルトはステートフルです。インターネットに接続するWebサイト(HTTP/HTTPSトラフィック用)が大量に存在する場合は、ステートレス・ルールをお薦めします。

この項では、特にコンピュート・インスタンスとそのトラフィックについて説明します。ただし、その説明はVNICを含むすべてのタイプのリソースに適用されます。セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。

ステートフル・ルール

セキュリティ・ルールをステートフルとしてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用することを示します。これは、インスタンスがステートフル・イングレス・ルールに一致するトラフィックを受け取ると、インスタンスに適用されるエグレス・ルールに関係なく、レスポンスがトラッキングされ、元のホストに自動的に戻されることを意味します。また、インスタンスがステートフル・エグレス・ルールに一致するトラフィックを送信すると、イングレス・ルールに関係なく、受信レスポンスが自動的に許可されます。詳細は、ステートフル・ルールとステートレス・ルールを参照してください。

次の図に、HTTPトラフィックを受信して応答する必要があるインスタンスに対するステートフル・イングレス・ルールを示します。インスタンスAとホストBが通信しています(ホストBは、インスタンスかどうかにかかわらず、任意のホストです)。ステートフル・イングレス・ルールでは、任意のソースIPアドレス(0.0.0.0/0)から宛先ポート80のみ(TCPプロトコル)へのトラフィックが許可されます。レスポンス・トラフィックを許可するエグレス・ルールは必要ありません。

受信HTTPトラフィックおよびレスポンスを許可するステートフル・イングレス・ルール

ステートレス・ルール

セキュリティ・ルールをステートレスとしてマークすることは、そのルールに一致するトラフィックに対して接続トラッキングを使用しないことを示します。これは、レスポンス・トラフィックが自動的に許可されないことを意味します。ステートレス・イングレス・ルールでレスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールを作成する必要があります。

次の図は、インスタンスAとホストBを前のように示していますが、ステートレス・セキュリティ・ルールが使用されています。前の項のステートフル・ルールと同様に、ステートレス・イングレス・ルールでは、宛先ポート80のみで、すべてのIPアドレスおよび任意のポートからの(TCPプロトコルを使用した)トラフィックが許可されます。レスポンス・トラフィックを許可するには、対応するステートレス・エグレス・ルールが必要です。このルールでは、ソース・ポート80のみから任意の宛先IPアドレス(0.0.0.0/0)および任意のポートへの(TCPプロトコルを使用した)トラフィックを許可します。

受信HTTPトラフィックおよびレスポンスを許可するステートレス・イングレスおよびエグレス・ルール

インスタンスAがHTTPトラフィックを開始してレスポンスを取得する必要がある場合は、別のステートレス・ルールのセットが必要です。次の図に示すように、エグレス・ルールには、ソース・ポート = allおよび宛先ポート = 80 (HTTP)が含まれます。イングレス・ルールには、ソース・ポート80および宛先ポート = allが含まれます。

インスタンスによるHTTPトラフィックの開始とレスポンスの取得を許可するステートレス・イングレスおよびエグレス・ルール

インスタンスAでポート・バインディングを使用してHTTPトラフィックの発生元のポートを正確に指定する場合は、エグレス・ルールのソース・ポートおよびイングレス・ルールの宛先ポートとしてそれを指定できます。

ノート

なんらかの理由でステートフル・ルールとステートレス・ルールの両方を使用し、特定の方向(イングレスなど)でステートフル・ルールとステートレス・ルールの両方に一致するトラフィックがある場合は、ステートレス・ルールが優先され、接続はトラッキングされません。レスポンス・トラフィックを許可するには、他の方向(たとえば、ステートレスまたはステートフルのエグレス)に対応するルールが必要です。

ステートフル・ルールの接続トラッキングの詳細

Oracleは接続トラッキングを使用して、ステートフル・ルールと一致するトラフィックに対するレスポンスを許可します(ステートフル・ルールとステートレス・ルールを参照)。各インスタンスには、インスタンスのシェイプに基づいてトラッキングできる同時接続の最大数があります。

TCP、UDPおよびICMPのレスポンス・トラフィックを特定するために、Oracleはパケットについて次の項目の接続トラッキングを実行します:

  • プロトコル
  • ソースおよび宛先のIPアドレス
  • ソースおよび宛先のポート(TCPおよびUDPの場合のみ)
ノート

その他のプロトコルについては、OracleはプロトコルとIPアドレスのみをトラッキングし、ポートはトラッキングしません。つまり、インスタンスが別のホストへのトラフィックを開始し、そのトラフィックがエグレス・セキュリティ・ルールによって許可される場合、その後インスタンスがそのホストから受信する一定期間のトラフィックは、レスポンス・トラフィックとみなされ、許可されます。

ステートレス・ルールでのPath MTU Discoveryメッセージの有効化

ステートレス・セキュリティ・ルールを使用してVCN外部のエンドポイント間のトラフィックを許可する場合、ソース0.0.0.0/0および任意のソース・ポートからのイングレスICMPトラフィック・タイプ3のコード4を許可するセキュリティ・ルールを追加することが重要です。このルールを使用すると、インスタンスでPath MTU Discoveryのフラグメンテーション・メッセージを受信できます。このルールは、インスタンスとの接続を確立するために重要です。これがない場合、接続性の問題が発生する可能性があります。詳細は、接続のハングを参照してください。

Pingを有効化するルール

VCNのデフォルト・セキュリティ・リストには、いくつかのデフォルトのルールが含まれていますが、pingリクエストを許可するルールは含まれていません。インスタンスをpingする場合は、インスタンスの適用可能なセキュリティ・リストまたはNSGに追加のステートフル・イングレス・ルールが含まれていることを確認して、ping元となる予定のソース・ネットワークからのICMPトラフィック・タイプ8を明確に許可してください。インターネットからのpingアクセスを許可するには、ソースとして0.0.0.0/0を使用します。pingのこのルールは、デフォルト・セキュリティ・リストにあるデフォルトのICMP関連ルールとは別です。これらのルールは削除しないでください。

断片化されたUDPパケットを処理するルール

インスタンスはUDPトラフィックを送受信できます。接続のUDPパケットが大きすぎる場合は、断片化されます。ただし、パケットの最初のフラグメントにのみ、プロトコルとポートの情報が含まれます。このイングレス・トラフィックまたはエグレス・トラフィックを許可するセキュリティ・ルールで特定のポート番号(ソースまたは宛先)を指定すると、最初のもの以降のフラグメントが削除されます。インスタンスで大規模なUDPパケットを送受信する場合は、適用可能なセキュリティ・ルールのソース・ポートと宛先ポートの両方をALLに設定します(特定のポート番号は使用しません)。