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).
Excellent