The firewall cleanup rule is the explicit rule at the bottom of a firewall policy defined as:

Source = ANY
Destination = ANY
Service / Application = ANY
Action = DROP
Logging = Enabled

cleanup

Why define a Cleanup Rule?

Since the advent of the firewall (though not necessarily true with early access lists), the default behavior of a firewall is to drop all traffic that is not explicitly allowed. For this reason, an explicitly defined cleanup rule is effectively redundant to the default behavior of the firewall. So why is this such a basic requirement and recommendation? There are a few reasons:

  1. Logging Unauthorized Access – Significant security intelligence can be gained about threat activity by logging unauthorized access attempts. For most firewalls, the implicit drop behavior does not generate a log of failed access. To log these unauthorized access requests, you must create the explicit cleanup rule and choose to log it. These logs can then be fed into event analysis systems like a SIEM to improve your visibility into network activity.
  2. Explicit Understanding – While the default behavior may be to drop all other traffic, the lack of a rule visible in the policy may lead to confusion, particularly with inexperienced members of a firewall operations team. Explicitly defining the cleanup rule clarifies the intention for anyone reviewing the policy that all traffic not defined above this rule will be dropped.
  3. Compliance – Many compliance policies specify the need for the cleanup rule. While it is possible to argue with an auditor that it is not actually needed for your brand of firewall due to the implicit drop rule, there is very little gained in fighting this fight. Make life easy on yourself and help the auditor out.
  4. Logging for troubleshooting – New access requests and support tickets created by users often start with a claim that the firewall is denying access. There are multiple ways to evaluate this (using FireMon features like rule recommendation, policy test, FMQL rule search and Access Path Analysis all can assist with this), but a definitive log showing access is being denied is a very good way to not only see the drop, but also get additional data like what protocol/port/application is being used.
  5. NO ALLOW ALL – It is sad to say, but there are still many firewalls configured in this world with a final rule permitting all traffic. The net effect of this firewall policy is at best an event logging source and at worst and traffic bottleneck – but in no way should a policy like this be considered a “firewall policy”. Ensuring that there is a Cleanup Rule (as well and insuring there is NOT an Accept All Rule) is a good practice to verify that the firewall is acting as a positive security model device – only permitting what is explicitly allowed.

How to Verify there is a Cleanup Rule

This process is very straight forward. Review every policy and verify that the last rule is defined appropriately (Any, Any, Any, Drop, Log). And, also verify that there is not an Allow All Rule defined above it.

How FireMon Can Help

Using FireMon’s Assessment framework, it is possible to automate this for continuous assessment that not only does every policy have the Drop Rule defined, but that there is never a change that violates this configuraiton control.

Use the predefined control to verify that the last rule in the policy is defined appropriately. Assign that control to an assessment. Assign that Assessment to all devices under management. Now every device will be evaluated against this control and any failures will create an a control failure for immediate review.

Another cool option with FireMon is to use FMQL to create just about any rule search pattern you can think of. In this case, we want to verify that the last rule must be defined as ANY, ANY, ANY, DROP, LOG. We can do this by only evaluating the last rule in every policy and insuring that no column is improperly defined. In this case, the FMQL syntax for this search is:

rule{ POSITION = LAST and (source.any != true or destination.any != true or service.any!=true or  LOG != 'LOG' or action = 'DROP')}

And to verify there is not an Allow All rule:

rule{ source.any = true and destination.any = true and service.any = true and action = 'ACCEPT'}

This search can be used to create a custom Compliance Control or can be used ad-hoc as part of a rule search, integrated into an external application by making a REST call to FireMon or even to create a dashboard widget in Insight to identify all failing rules.