View a markdown version of this page

Policy mode: enforce and monitor - Amazon Network Firewall
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Policy mode: enforce and monitor

The policy mode setting controls whether the policy's engines apply their actions or only report them in your logs. In both modes, both engines evaluate traffic against your rules. In monitor mode, Network Firewall also turns on alert logging for your rules and for the firewall default action, so monitor mode produces alert log entries that enforce mode doesn't.

  • Enforce (default) – The engines apply their actions. The firewall engine drops or rejects traffic that isn't accepted, and the IPS engine drops or rejects traffic that matches a drop or reject rule.

  • Monitor – The engines evaluate traffic and generate log records, but no traffic is dropped or rejected. In monitor mode, your rules also act as alerting rules, so a rule match generates an alert log entry. This gives you visibility into which rules match your traffic without affecting the traffic itself. Use monitor mode to see how your rules would affect traffic before you enforce them. This is useful for a staged rollout: you can validate a new policy or a change to an existing policy against real traffic, review the alerts in your logs, and then switch the policy to enforce mode. To validate, review your alert logs and the FirewallDefaultActionApplied metric in Amazon CloudWatch, confirm that the traffic you intend to allow isn't being matched by the default drop action, and only then switch the policy mode to Enforce.

To keep monitored traffic flowing while still reflecting what enforce mode would do, monitor mode handles a firewall rule that blocks traffic (a drop or reject rule) by accepting the traffic in the firewall engine but bypassing the IPS engine for it. This approximates enforce mode, where traffic that the firewall engine blocks never reaches the IPS engine: in both modes the blocked traffic receives no IPS inspection, but in monitor mode it continues to its destination instead of being dropped. In monitor mode, every firewall rule that would drop or reject traffic records an alert log entry when it matches, whether or not the rule has alert logging turned on. In enforce mode, a drop or reject rule records an alert log entry only if it has alert logging turned on—either the alert keyword chained to the action (drop:flow,alert) or added as a rule option.

Note

Monitor mode approximates enforce mode but doesn't reproduce it exactly, so monitor logs don't match enforce-mode logs flow for flow:

  • In monitor mode, every blocking firewall rule becomes an accept of the whole flow—its scope is discarded—so the flow skips the firewall engine's later hooks and the IPS engine. The later rule matches and IPS alerts that enforce mode would produce for that flow don't appear in the monitor logs.

  • In the IPS engine, every action—including pass—is recorded as an alert. As a result, monitor logs can show IPS drop alerts that a pass rule would have shadowed in enforce mode.

Note

In monitor mode, Network Firewall doesn't add alerting to accept:hook rules, because they only advance a connection to the next hook. This applies both to the carrier rules that a domain list (FQDN) firewall rule group generates automatically and to any accept:hook rules that you author yourself. All other accept rules, every drop and reject rule, and the firewall default action generate an alert log entry when they're applied. So a connection that matches none of your allowed domains is still visible in your logs through the default action.

Note

In monitor mode, your firewall doesn't block any traffic, regardless of your rules and your firewall default action. Logs record the actions the engines apply in monitor mode, which approximate what enforce mode would apply (see the note earlier in this section about how monitor logs differ from enforce-mode logs). If you expect traffic to be blocked and it isn't, confirm whether the policy is in monitor mode. This includes the stream exception policy, which uses Continue in monitor mode (your configured value applies again in enforce mode). The following are exceptions that still block in monitor mode:

  • Certificate revocation checking still blocks revoked or unknown-status certificates in monitor mode when its action is Drop or Reject.

  • Route 53 Resolved IP validation still applies its configured Action and DNS expiry exception policy in monitor mode—it isn't neutralized. Because the console defaults the Action to Reject, if you validate a policy in monitor mode you can still see flows to untrusted destinations reset. While you validate in monitor mode, consider setting the Route 53 Resolved IP validation Action to Alert (or disabling it).

  • TLS connections in scope of a TLS inspection configuration whose Server Name Indication (SNI) is missing or invalid are still blocked in monitor mode. Network Firewall resets these connections before the TLS handshake, regardless of your rules, and records the error in the TLS log.

  • TLS connections where the server's certificate doesn't match the SNI that the client sent are still blocked in monitor mode. Network Firewall validates the server's certificate before it decrypts the connection, and the TLS handshake with the client fails when the certificate doesn't match.