From ab0e00ecd3230b4b7ca8dd7eb1e2014972348c64 Mon Sep 17 00:00:00 2001 From: awstools Date: Thu, 25 Jul 2024 19:38:56 +0000 Subject: [PATCH] feat(client-network-firewall): You can now log events that are related to TLS inspection, in addition to the existing alert and flow logging. --- ...CreateTLSInspectionConfigurationCommand.ts | 3 +- .../DescribeLoggingConfigurationCommand.ts | 2 +- .../UpdateLoggingConfigurationCommand.ts | 4 +- .../src/models/models_0.ts | 47 +++++++++++++------ .../aws-models/network-firewall.json | 22 +++++---- 5 files changed, 50 insertions(+), 28 deletions(-) diff --git a/clients/client-network-firewall/src/commands/CreateTLSInspectionConfigurationCommand.ts b/clients/client-network-firewall/src/commands/CreateTLSInspectionConfigurationCommand.ts index a22391b20348..ad064b57ca48 100644 --- a/clients/client-network-firewall/src/commands/CreateTLSInspectionConfigurationCommand.ts +++ b/clients/client-network-firewall/src/commands/CreateTLSInspectionConfigurationCommand.ts @@ -33,8 +33,7 @@ export interface CreateTLSInspectionConfigurationCommandOutput __MetadataBearer {} /** - *

Creates an Network Firewall TLS inspection configuration. A TLS inspection configuration contains Certificate Manager certificate associations between and the scope configurations that Network Firewall uses to decrypt and re-encrypt traffic traveling through your firewall.

- *

After you create a TLS inspection configuration, you can associate it with a new firewall policy.

+ *

Creates an Network Firewall TLS inspection configuration. Network Firewall uses TLS inspection configurations to decrypt your firewall's inbound and outbound SSL/TLS traffic. After decryption, Network Firewall inspects the traffic according to your firewall policy's stateful rules, and then re-encrypts it before sending it to its destination. You can enable inspection of your firewall's inbound traffic, outbound traffic, or both. To use TLS inspection with your firewall, you must first import or provision certificates using ACM, create a TLS inspection configuration, add that configuration to a new firewall policy, and then associate that policy with your firewall.

*

To update the settings for a TLS inspection configuration, use UpdateTLSInspectionConfiguration.

*

To manage a TLS inspection configuration's tags, use the standard Amazon Web Services resource tagging operations, ListTagsForResource, TagResource, and UntagResource.

*

To retrieve information about TLS inspection configurations, use ListTLSInspectionConfigurations and DescribeTLSInspectionConfiguration.

diff --git a/clients/client-network-firewall/src/commands/DescribeLoggingConfigurationCommand.ts b/clients/client-network-firewall/src/commands/DescribeLoggingConfigurationCommand.ts index 22f48a1871f4..88c1785f2abe 100644 --- a/clients/client-network-firewall/src/commands/DescribeLoggingConfigurationCommand.ts +++ b/clients/client-network-firewall/src/commands/DescribeLoggingConfigurationCommand.ts @@ -51,7 +51,7 @@ export interface DescribeLoggingConfigurationCommandOutput * // LoggingConfiguration: { // LoggingConfiguration * // LogDestinationConfigs: [ // LogDestinationConfigs // required * // { // LogDestinationConfig - * // LogType: "ALERT" || "FLOW", // required + * // LogType: "ALERT" || "FLOW" || "TLS", // required * // LogDestinationType: "S3" || "CloudWatchLogs" || "KinesisDataFirehose", // required * // LogDestination: { // LogDestinationMap // required * // "": "STRING_VALUE", diff --git a/clients/client-network-firewall/src/commands/UpdateLoggingConfigurationCommand.ts b/clients/client-network-firewall/src/commands/UpdateLoggingConfigurationCommand.ts index 3a1f0d565c03..375045170da0 100644 --- a/clients/client-network-firewall/src/commands/UpdateLoggingConfigurationCommand.ts +++ b/clients/client-network-firewall/src/commands/UpdateLoggingConfigurationCommand.ts @@ -66,7 +66,7 @@ export interface UpdateLoggingConfigurationCommandOutput extends UpdateLoggingCo * LoggingConfiguration: { // LoggingConfiguration * LogDestinationConfigs: [ // LogDestinationConfigs // required * { // LogDestinationConfig - * LogType: "ALERT" || "FLOW", // required + * LogType: "ALERT" || "FLOW" || "TLS", // required * LogDestinationType: "S3" || "CloudWatchLogs" || "KinesisDataFirehose", // required * LogDestination: { // LogDestinationMap // required * "": "STRING_VALUE", @@ -83,7 +83,7 @@ export interface UpdateLoggingConfigurationCommandOutput extends UpdateLoggingCo * // LoggingConfiguration: { // LoggingConfiguration * // LogDestinationConfigs: [ // LogDestinationConfigs // required * // { // LogDestinationConfig - * // LogType: "ALERT" || "FLOW", // required + * // LogType: "ALERT" || "FLOW" || "TLS", // required * // LogDestinationType: "S3" || "CloudWatchLogs" || "KinesisDataFirehose", // required * // LogDestination: { // LogDestinationMap // required * // "": "STRING_VALUE", diff --git a/clients/client-network-firewall/src/models/models_0.ts b/clients/client-network-firewall/src/models/models_0.ts index e36d882eed56..851f413d95ad 100644 --- a/clients/client-network-firewall/src/models/models_0.ts +++ b/clients/client-network-firewall/src/models/models_0.ts @@ -1618,7 +1618,8 @@ export type TargetType = (typeof TargetType)[keyof typeof TargetType]; /** *

Stateful inspection criteria for a domain list rule group.

*

For HTTPS traffic, domain filtering is SNI-based. It uses the server name indicator extension of the TLS handshake.

- *

By default, Network Firewall domain list inspection only includes traffic coming from the VPC where you deploy the firewall. To inspect traffic from IP addresses outside of the deployment VPC, you set the HOME_NET rule variable to include the CIDR range of the deployment VPC plus the other CIDR ranges. For more information, see RuleVariables in this guide and Stateful domain list rule groups in Network Firewall in the Network Firewall Developer Guide.

+ *

By default, Network Firewall domain list inspection only includes traffic coming from the VPC where you deploy the firewall. To inspect traffic from IP addresses outside of the deployment VPC, you set the HOME_NET rule variable to include the CIDR range of the deployment VPC plus the other CIDR ranges. For more information, see RuleVariables in this guide and + * Stateful domain list rule groups in Network Firewall in the Network Firewall Developer Guide.

* @public */ export interface RulesSourceList { @@ -1852,6 +1853,10 @@ export interface StatefulRule { * can enable the rule with ALERT action, verify in the logs that the rule * is filtering as you want, then change the action to DROP.

* + *
  • + *

    + * REJECT - Drops traffic that matches the conditions of the stateful rule, and sends a TCP reset packet back to sender of the packet. A TCP reset packet is a packet with no payload and an RST bit contained in the TCP header flags. REJECT is available only for TCP traffic. This option doesn't support FTP or IMAP protocols.

    + *
    • * * @public */ @@ -2343,8 +2348,7 @@ export interface CreateRuleGroupRequest { *

    * Capacity for a stateful rule group *

    - *

    For - * a stateful rule group, the minimum capacity required is the number of individual rules that + *

    For a stateful rule group, the minimum capacity required is the number of individual rules that * you expect to have in the rule group.

    * @public */ @@ -3081,6 +3085,7 @@ export type LogDestinationType = (typeof LogDestinationType)[keyof typeof LogDes export const LogType = { ALERT: "ALERT", FLOW: "FLOW", + TLS: "TLS", } as const; /** @@ -3090,24 +3095,37 @@ export type LogType = (typeof LogType)[keyof typeof LogType]; /** *

    Defines where Network Firewall sends logs for the firewall for one log type. This is used - * in LoggingConfiguration. You can send each type of log to an Amazon S3 bucket, a CloudWatch log group, or a Kinesis Data Firehose delivery stream.

    - *

    Network Firewall generates logs for stateful rule groups. You can save alert and flow log - * types. The stateful rules engine records flow logs for all network traffic that it receives. - * It records alert logs for traffic that matches stateful rules that have the rule - * action set to DROP or ALERT.

    + * in LoggingConfiguration. You can send each type of log to an Amazon S3 bucket, a CloudWatch log group, or a Firehose delivery stream.

    + *

    Network Firewall generates logs for stateful rule groups. You can save alert, flow, and TLS log + * types.

    * @public */ export interface LogDestinationConfig { /** - *

    The type of log to send. Alert logs report traffic that matches a StatefulRule with an action setting that sends an alert log message. Flow logs are - * standard network traffic flow logs.

    + *

    The type of log to record. You can record the following types of logs from your Network Firewall stateful engine.

    + *
      + *
    • + *

      + * ALERT - Logs for traffic that matches your stateful rules and that have an action that sends an alert. A stateful rule sends alerts for the rule actions DROP, ALERT, and REJECT. For more information, see StatefulRule.

      + *
      • + *
    • + *

      + * FLOW - Standard network traffic flow logs. The stateful rules engine records flow logs for all network traffic that it receives. Each flow log record captures the network flow for a specific standard stateless rule group.

      + *
      • + *
    • + *

      + * TLS - Logs for events that are related to TLS inspection. For more information, see + * Inspecting SSL/TLS traffic with TLS inspection configurations + * in the Network Firewall Developer Guide.

      + *
      • + *
    * @public */ LogType: LogType | undefined; /** *

    The type of storage destination to send these logs to. You can send logs to an Amazon S3 bucket, - * a CloudWatch log group, or a Kinesis Data Firehose delivery stream.

    + * a CloudWatch log group, or a Firehose delivery stream.

    * @public */ LogDestinationType: LogDestinationType | undefined; @@ -3118,9 +3136,8 @@ export interface LogDestinationConfig { *
      *
    • *

      For an Amazon S3 bucket, provide the name of the bucket, with key bucketName, - * and optionally provide a prefix, with key prefix. The following example - * specifies an Amazon S3 bucket named - * DOC-EXAMPLE-BUCKET and the prefix alerts:

      + * and optionally provide a prefix, with key prefix.

      + *

      The following example specifies an Amazon S3 bucket named DOC-EXAMPLE-BUCKET and the prefix alerts:

      *

      * "LogDestination": \{ "bucketName": "DOC-EXAMPLE-BUCKET", "prefix": "alerts" * \} @@ -3135,7 +3152,7 @@ export interface LogDestinationConfig { *

      *
      • *
    • - *

      For a Kinesis Data Firehose delivery stream, provide the name of the delivery stream, with key + *

      For a Firehose delivery stream, provide the name of the delivery stream, with key * deliveryStream. The following example specifies a delivery stream * named alert-delivery-stream:

      *

      diff --git a/codegen/sdk-codegen/aws-models/network-firewall.json b/codegen/sdk-codegen/aws-models/network-firewall.json index 0bcf6825a7f1..2343b42bc6de 100644 --- a/codegen/sdk-codegen/aws-models/network-firewall.json +++ b/codegen/sdk-codegen/aws-models/network-firewall.json @@ -804,7 +804,7 @@ "Capacity": { "target": "com.amazonaws.networkfirewall#RuleCapacity", "traits": { - "smithy.api#documentation": "

      The maximum operating resources that this rule group can use. Rule group capacity is fixed at creation.\n When you update a rule group, you are limited to this capacity. When you reference a rule group\n from a firewall policy, Network Firewall reserves this capacity for the rule group.

      \n

      You can retrieve the capacity that would be required for a rule group before you create the rule group by calling\n CreateRuleGroup with DryRun set to TRUE.

      \n \n

      You can't change or exceed this capacity when you update the rule group, so leave\n room for your rule group to grow.

      \n       \n

      \n Capacity for a stateless rule group\n

      \n

      For a stateless rule group, the capacity required is the sum of the capacity\n requirements of the individual rules that you expect to have in the rule group.

      \n

      To calculate the capacity requirement of a single rule, multiply the capacity\n requirement values of each of the rule's match settings:

      \n
        \n
      • \n

        A match setting with no criteria specified has a value of 1.

        \n
        • \n
      • \n

        A match setting with Any specified has a value of 1.

        \n
        • \n
      • \n

        All other match settings have a value equal to the number of elements provided in\n the setting. For example, a protocol setting [\"UDP\"] and a source setting\n [\"10.0.0.0/24\"] each have a value of 1. A protocol setting [\"UDP\",\"TCP\"] has a value\n of 2. A source setting [\"10.0.0.0/24\",\"10.0.0.1/24\",\"10.0.0.2/24\"] has a value of 3.\n

        \n
        • \n
      \n

      A rule with no criteria specified in any of its match settings has a capacity\n requirement of 1. A rule with protocol setting [\"UDP\",\"TCP\"], source setting\n [\"10.0.0.0/24\",\"10.0.0.1/24\",\"10.0.0.2/24\"], and a single specification or no specification\n for each of the other match settings has a capacity requirement of 6.

      \n

      \n Capacity for a stateful rule group\n

      \n

      For\n a stateful rule group, the minimum capacity required is the number of individual rules that\n you expect to have in the rule group.

      ", + "smithy.api#documentation": "

      The maximum operating resources that this rule group can use. Rule group capacity is fixed at creation.\n When you update a rule group, you are limited to this capacity. When you reference a rule group\n from a firewall policy, Network Firewall reserves this capacity for the rule group.

      \n

      You can retrieve the capacity that would be required for a rule group before you create the rule group by calling\n CreateRuleGroup with DryRun set to TRUE.

      \n \n

      You can't change or exceed this capacity when you update the rule group, so leave\n room for your rule group to grow.

      \n       \n

      \n Capacity for a stateless rule group\n

      \n

      For a stateless rule group, the capacity required is the sum of the capacity\n requirements of the individual rules that you expect to have in the rule group.

      \n

      To calculate the capacity requirement of a single rule, multiply the capacity\n requirement values of each of the rule's match settings:

      \n
        \n
      • \n

        A match setting with no criteria specified has a value of 1.

        \n
        • \n
      • \n

        A match setting with Any specified has a value of 1.

        \n
        • \n
      • \n

        All other match settings have a value equal to the number of elements provided in\n the setting. For example, a protocol setting [\"UDP\"] and a source setting\n [\"10.0.0.0/24\"] each have a value of 1. A protocol setting [\"UDP\",\"TCP\"] has a value\n of 2. A source setting [\"10.0.0.0/24\",\"10.0.0.1/24\",\"10.0.0.2/24\"] has a value of 3.\n

        \n
        • \n
      \n

      A rule with no criteria specified in any of its match settings has a capacity\n requirement of 1. A rule with protocol setting [\"UDP\",\"TCP\"], source setting\n [\"10.0.0.0/24\",\"10.0.0.1/24\",\"10.0.0.2/24\"], and a single specification or no specification\n for each of the other match settings has a capacity requirement of 6.

      \n

      \n Capacity for a stateful rule group\n

      \n

      For a stateful rule group, the minimum capacity required is the number of individual rules that\n you expect to have in the rule group.

      ", "smithy.api#required": {} } }, @@ -893,7 +893,7 @@ } ], "traits": { - "smithy.api#documentation": "

      Creates an Network Firewall TLS inspection configuration. A TLS inspection configuration contains Certificate Manager certificate associations between and the scope configurations that Network Firewall uses to decrypt and re-encrypt traffic traveling through your firewall.

      \n

      After you create a TLS inspection configuration, you can associate it with a new firewall policy.

      \n

      To update the settings for a TLS inspection configuration, use UpdateTLSInspectionConfiguration.

      \n

      To manage a TLS inspection configuration's tags, use the standard Amazon Web Services resource tagging operations, ListTagsForResource, TagResource, and UntagResource.

      \n

      To retrieve information about TLS inspection configurations, use ListTLSInspectionConfigurations and DescribeTLSInspectionConfiguration.

      \n

      \n For more information about TLS inspection configurations, see Inspecting SSL/TLS traffic with TLS\ninspection configurations in the Network Firewall Developer Guide.\n

      " + "smithy.api#documentation": "

      Creates an Network Firewall TLS inspection configuration. Network Firewall uses TLS inspection configurations to decrypt your firewall's inbound and outbound SSL/TLS traffic. After decryption, Network Firewall inspects the traffic according to your firewall policy's stateful rules, and then re-encrypts it before sending it to its destination. You can enable inspection of your firewall's inbound traffic, outbound traffic, or both. To use TLS inspection with your firewall, you must first import or provision certificates using ACM, create a TLS inspection configuration, add that configuration to a new firewall policy, and then associate that policy with your firewall.

      \n

      To update the settings for a TLS inspection configuration, use UpdateTLSInspectionConfiguration.

      \n

      To manage a TLS inspection configuration's tags, use the standard Amazon Web Services resource tagging operations, ListTagsForResource, TagResource, and UntagResource.

      \n

      To retrieve information about TLS inspection configurations, use ListTLSInspectionConfigurations and DescribeTLSInspectionConfiguration.

      \n

      \n For more information about TLS inspection configurations, see Inspecting SSL/TLS traffic with TLS\ninspection configurations in the Network Firewall Developer Guide.\n

      " } }, "com.amazonaws.networkfirewall#CreateTLSInspectionConfigurationRequest": { @@ -3073,27 +3073,27 @@ "LogType": { "target": "com.amazonaws.networkfirewall#LogType", "traits": { - "smithy.api#documentation": "

      The type of log to send. Alert logs report traffic that matches a StatefulRule with an action setting that sends an alert log message. Flow logs are\n standard network traffic flow logs.

      ", + "smithy.api#documentation": "

      The type of log to record. You can record the following types of logs from your Network Firewall stateful engine.

      \n
        \n
      • \n

        \n ALERT - Logs for traffic that matches your stateful rules and that have an action that sends an alert. A stateful rule sends alerts for the rule actions DROP, ALERT, and REJECT. For more information, see StatefulRule.

        \n
        • \n
      • \n

        \n FLOW - Standard network traffic flow logs. The stateful rules engine records flow logs for all network traffic that it receives. Each flow log record captures the network flow for a specific standard stateless rule group.

        \n
        • \n
      • \n

        \n TLS - Logs for events that are related to TLS inspection. For more information, see \n Inspecting SSL/TLS traffic with TLS inspection configurations \n in the Network Firewall Developer Guide.

        \n
        • \n
      ", "smithy.api#required": {} } }, "LogDestinationType": { "target": "com.amazonaws.networkfirewall#LogDestinationType", "traits": { - "smithy.api#documentation": "

      The type of storage destination to send these logs to. You can send logs to an Amazon S3 bucket,\n a CloudWatch log group, or a Kinesis Data Firehose delivery stream.

      ", + "smithy.api#documentation": "

      The type of storage destination to send these logs to. You can send logs to an Amazon S3 bucket,\n a CloudWatch log group, or a Firehose delivery stream.

      ", "smithy.api#required": {} } }, "LogDestination": { "target": "com.amazonaws.networkfirewall#LogDestinationMap", "traits": { - "smithy.api#documentation": "

      The named location for the logs, provided in a key:value mapping that is specific to the\n chosen destination type.

      \n
        \n
      • \n

        For an Amazon S3 bucket, provide the name of the bucket, with key bucketName,\n and optionally provide a prefix, with key prefix. The following example\n specifies an Amazon S3 bucket named\n DOC-EXAMPLE-BUCKET and the prefix alerts:

        \n

        \n \"LogDestination\": { \"bucketName\": \"DOC-EXAMPLE-BUCKET\", \"prefix\": \"alerts\"\n }\n

        \n
        • \n
      • \n

        For a CloudWatch log group, provide the name of the CloudWatch log group, with key\n logGroup. The following example specifies a log group named\n alert-log-group:

        \n

        \n \"LogDestination\": { \"logGroup\": \"alert-log-group\" }\n

        \n
        • \n
      • \n

        For a Kinesis Data Firehose delivery stream, provide the name of the delivery stream, with key\n deliveryStream. The following example specifies a delivery stream\n named alert-delivery-stream:

        \n

        \n \"LogDestination\": { \"deliveryStream\": \"alert-delivery-stream\"\n }\n

        \n
        • \n
      ", + "smithy.api#documentation": "

      The named location for the logs, provided in a key:value mapping that is specific to the\n chosen destination type.

      \n
        \n
      • \n

        For an Amazon S3 bucket, provide the name of the bucket, with key bucketName,\n and optionally provide a prefix, with key prefix.

        \n

        The following example specifies an Amazon S3 bucket named DOC-EXAMPLE-BUCKET and the prefix alerts:

        \n

        \n \"LogDestination\": { \"bucketName\": \"DOC-EXAMPLE-BUCKET\", \"prefix\": \"alerts\"\n }\n

        \n
        • \n
      • \n

        For a CloudWatch log group, provide the name of the CloudWatch log group, with key\n logGroup. The following example specifies a log group named\n alert-log-group:

        \n

        \n \"LogDestination\": { \"logGroup\": \"alert-log-group\" }\n

        \n
        • \n
      • \n

        For a Firehose delivery stream, provide the name of the delivery stream, with key\n deliveryStream. The following example specifies a delivery stream\n named alert-delivery-stream:

        \n

        \n \"LogDestination\": { \"deliveryStream\": \"alert-delivery-stream\"\n }\n

        \n
        • \n
      ", "smithy.api#required": {} } } }, "traits": { - "smithy.api#documentation": "

      Defines where Network Firewall sends logs for the firewall for one log type. This is used\n in LoggingConfiguration. You can send each type of log to an Amazon S3 bucket, a CloudWatch log group, or a Kinesis Data Firehose delivery stream.

      \n

      Network Firewall generates logs for stateful rule groups. You can save alert and flow log\n types. The stateful rules engine records flow logs for all network traffic that it receives.\n It records alert logs for traffic that matches stateful rules that have the rule\n action set to DROP or ALERT.

      " + "smithy.api#documentation": "

      Defines where Network Firewall sends logs for the firewall for one log type. This is used\n in LoggingConfiguration. You can send each type of log to an Amazon S3 bucket, a CloudWatch log group, or a Firehose delivery stream.

      \n

      Network Firewall generates logs for stateful rule groups. You can save alert, flow, and TLS log\n types.

      " } }, "com.amazonaws.networkfirewall#LogDestinationConfigs": { @@ -3167,6 +3167,12 @@ "traits": { "smithy.api#enumValue": "FLOW" } + }, + "TLS": { + "target": "smithy.api#Unit", + "traits": { + "smithy.api#enumValue": "TLS" + } } } }, @@ -5089,7 +5095,7 @@ } }, "traits": { - "smithy.api#documentation": "

      Stateful inspection criteria for a domain list rule group.

      \n

      For HTTPS traffic, domain filtering is SNI-based. It uses the server name indicator extension of the TLS handshake.

      \n

      By default, Network Firewall domain list inspection only includes traffic coming from the VPC where you deploy the firewall. To inspect traffic from IP addresses outside of the deployment VPC, you set the HOME_NET rule variable to include the CIDR range of the deployment VPC plus the other CIDR ranges. For more information, see RuleVariables in this guide and Stateful domain list rule groups in Network Firewall in the Network Firewall Developer Guide.

      " + "smithy.api#documentation": "

      Stateful inspection criteria for a domain list rule group.

      \n

      For HTTPS traffic, domain filtering is SNI-based. It uses the server name indicator extension of the TLS handshake.

      \n

      By default, Network Firewall domain list inspection only includes traffic coming from the VPC where you deploy the firewall. To inspect traffic from IP addresses outside of the deployment VPC, you set the HOME_NET rule variable to include the CIDR range of the deployment VPC plus the other CIDR ranges. For more information, see RuleVariables in this guide and \n Stateful domain list rule groups in Network Firewall in the Network Firewall Developer Guide.

      " } }, "com.amazonaws.networkfirewall#RulesString": { @@ -5310,7 +5316,7 @@ "Action": { "target": "com.amazonaws.networkfirewall#StatefulAction", "traits": { - "smithy.api#documentation": "

      Defines what Network Firewall should do with the packets in a traffic flow when the flow\n matches the stateful rule criteria. For all actions, Network Firewall performs the specified\n action and discontinues stateful inspection of the traffic flow.

      \n

      The actions for a stateful rule are defined as follows:

      \n
        \n
      • \n

        \n PASS - Permits the packets to go to the\n intended destination.

        \n
        • \n
      • \n

        \n DROP - Blocks the packets from going to\n the intended destination and sends an alert log message, if alert logging is configured in the Firewall\n LoggingConfiguration.

        \n
        • \n
      • \n

        \n ALERT - Sends an alert log message, if alert logging is configured in the Firewall\n LoggingConfiguration.

        \n

        You can use this action to test a rule that you intend to use to drop traffic. You\n can enable the rule with ALERT action, verify in the logs that the rule\n is filtering as you want, then change the action to DROP.

        \n
        • \n
      ", + "smithy.api#documentation": "

      Defines what Network Firewall should do with the packets in a traffic flow when the flow\n matches the stateful rule criteria. For all actions, Network Firewall performs the specified\n action and discontinues stateful inspection of the traffic flow.

      \n

      The actions for a stateful rule are defined as follows:

      \n
        \n
      • \n

        \n PASS - Permits the packets to go to the\n intended destination.

        \n
        • \n
      • \n

        \n DROP - Blocks the packets from going to\n the intended destination and sends an alert log message, if alert logging is configured in the Firewall\n LoggingConfiguration.

        \n
        • \n
      • \n

        \n ALERT - Sends an alert log message, if alert logging is configured in the Firewall\n LoggingConfiguration.

        \n

        You can use this action to test a rule that you intend to use to drop traffic. You\n can enable the rule with ALERT action, verify in the logs that the rule\n is filtering as you want, then change the action to DROP.

        \n
        • \n
      • \n

        \n REJECT - Drops traffic that matches the conditions of the stateful rule, and sends a TCP reset packet back to sender of the packet. A TCP reset packet is a packet with no payload and an RST bit contained in the TCP header flags. REJECT is available only for TCP traffic. This option doesn't support FTP or IMAP protocols.

        \n
        • \n
      ", "smithy.api#required": {} } },