Logging for a Next Generation policy in AWS Network Firewall

A firewall that uses a Next Generation policy logs events the same way as a firewall that uses a Classic Network Firewall policy. You configure logging in the same way, and there's no new log type and no new logging configuration to set up. For information about Next Generation policies, see Next Generation policies. For information about configuring logging, see Logging network traffic from AWS Network Firewall.

Even though a Next Generation policy uses two inspection engines, both engines report through the same alert EVE event type, into the same log destination you already configure. There's no separate log stream for each engine.

Telling firewall engine events from IPS engine events

To tell which engine produced a log record, use the engine field inside the alert object. It has one of the following values:

In the following example alert log entry, "engine": "fw" shows that the event came from the firewall engine. The firewall object reports the hook that the packet was evaluated at and the policy that was applied, and the verdict object reports the action that Network Firewall took. In this example, the firewall engine's default action dropped the packet.

{
    "firewall_name": "example-fw",
    "availability_zone": "us-east-1d",
    "event_timestamp": "1600000000",
    "event": {
        "app_proto": "ntp",
        "ip_v": 4,
        "src_ip": "10.0.2.53",
        "src_port": 49152,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2201000,
            "rev": 1,
            "engine": "fw",
            "signature": "SURICATA FW default packet policy",
            "action": "blocked",
            "category": ""
        },
        "firewall": {
            "hook": "packet:filter",
            "policy": "drop:flow,alert"
        },
        "flow_id": 1111111111111111,
        "dest_ip": "10.0.2.100",
        "proto": "UDP",
        "verdict": {
            "action": "drop"
        },
        "dest_port": 123,
        "timestamp": "2020-09-13T12:26:40.000000+0000",
        "direction": "to_server"
    }
}

The following example shows a firewall engine alert under an Alert default action, or under any default action while the policy is in monitor mode. The policy is accept:hook,alert and the verdict action is accept, so the packet was allowed and recorded in the alert log.

{
    "firewall_name": "example-fw",
    "availability_zone": "us-east-1d",
    "event_timestamp": "1600000000",
    "event": {
        "app_proto": "tls",
        "ip_v": 4,
        "src_ip": "10.0.2.53",
        "src_port": 47610,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2201000,
            "rev": 1,
            "engine": "fw",
            "signature": "SURICATA FW default packet policy",
            "action": "allowed",
            "category": ""
        },
        "firewall": {
            "hook": "packet:filter",
            "policy": "accept:hook,alert"
        },
        "flow_id": 1111111111111111,
        "dest_ip": "10.0.2.100",
        "proto": "TCP",
        "verdict": {
            "action": "accept"
        },
        "dest_port": 443,
        "timestamp": "2020-09-13T12:26:40.000000+0000",
        "direction": "to_server"
    }
}

You can also use the resource_arn field to identify the source of an event. The resource type in the ARN distinguishes a firewall rule group (firewall-rulegroup/), an IPS rule group (ips-rulegroup/), and a Next Generation policy (firewall-policy-v2/). The policy ARN (firewall-policy-v2/) is carried when the event isn't attributable to one of your own rule groups—for example, when the firewall engine's default action is applied. An alert from a managed rule carries the managed rule group's ARN (an ips-rulegroup/ ARN under your account), not the policy ARN. Use the engine field or the resource_arn resource type as a stable key for filtering your logs—for example, to separate access-control events (the firewall engine) from threat-detection events (the IPS engine).

Logging in monitor mode

When a Next Generation policy is in monitor mode, both engines still generate the same alert event records, but no traffic is dropped or rejected. If you use monitor mode to validate rules before enforcing them, your logs continue to show the actions the engines would have applied. For more information about monitor mode, see Policy mode: enforce and monitor.