Firewall Policy Basics – How to Verify Stealth Rules

Updated – January 2017


The firewall stealth rule is the explicit rule near the top of the policy denying access to the firewall beyond what is required to manage the device. It should be defined like:

Source = ANY

Destination = [self]

Service / Application = ANY

Action = DROP

Logging = Enabled

This is not exactly applicable to certain firewalls like Juniper Netscreen that define administrative access via interface-level settings instead of via the firewall policy. However, even in these cases, auditors may require a stealth rule as a matter of practice.

Why define a Stealth Rule?

The Stealth Rule insures that rules later defined in the policy do not inadvertently permit access to the firewall. For example, the firewall may have an interface in the Web-DMZ zone. A request from the web development team may ask for SSH access to all systems in the Web-DMZ. Without thinking too hard about the request, it seems reasonable that they may require SSH access to all those servers if they are the sole owner of the systems defined in the Web-DMZ. However, without a Stealth Rule properly defined, SSH access would not only be allowed to the servers in the Web-DMZ, but also to the firewall itself. Clearly this is not appropriate, but could go undetected by a firewall administrator for years.

To avoid this simple, but significant mistake, a Stealth Rule should be defined in the firewall policy.

How to verify there is a Stealth Rule?

This process is very straight forward. Review every policy and verify that a rule near the top of the policy after necessary administrative rules denies all traffic to the firewall (Any, Self, Any, Drop, Log).

How can FireMon help?

FireMon provides pre-defined controls to verify the existence of the Stealth Rule in each policy. This control is part of pre-defined assessments and can be added to any user-defined assessment as well.

Another powerful option is to search for rules yourself using FMQL. In this case, the search is pretty straight forward. You want to verify that near the top of the policy an explicit rule exists dropping all traffic to the firewall. Using the pre-defined variable of self you can create an FMQL query that is applicable to all devices. In this case, the FMQL syntax for this search is:

rule{ POSITION < 5 and source.any=true and destination is superset of self and SERVICE.any=true and action=’DROP’}

In the example above, I specified that the rule needed to be one of the first 4 rules in the policy and that the destination needs to fully contain the firewall address space (destination is superset of self). Superset includes equals and bigger. Self is the firewall object itself.


You May Also Like

Ransomware Attacks – The new normal?

Once again, the world is hit with another ransomware attack. Similar to the WannaCry Ransomware cyberattack last month, Petya is causing major pain among thousands of users, this time crippling banks and infrastructure in what cybersecurity experts called one of the most-devastating digital intrusions of its type. In fact, not

Read More >

Looking Forward to Seeing You at RSA 2022

RSA 2022 is almost here! I’m excited to see many of you face-to-face in just a few weeks in San Francisco. So much has changed at FireMon since RSAC in 2020, yet our core mission of protecting our customers is still true north. If you are attending RSA, I’d love

Read More >

Pragmatic Steps Toward Zero Trust

If you ask most security professionals to define zero trust, you’ll get an eye roll and an exasperated sigh. To many, it’s been little more than a marketing exercise—and let’s be honest: a lot of what we’re seen and heard about zero trust over the past decade has been more

Read More >