facebook logolinkedin logoyoutube logo

Introducing Cloud Defense Free Enterprise Scale CSPM. No Cost. No Strings. No Kidding

Learn More

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 SiCL. 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 SiCL query that is applicable to all devices. In this case, the SiCL 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.

Get 9x
BETTER

Book your demo now

Sign Up Now