Stealth Rule Question

[ititsw]

Hi everyone,

Could someone please explain the correct way to create a Stealth rule in Palo Alto? My understanding is that it involves creating a rule that denies all traffic destined for the firewall’s public IP addresses.

I’m also unsure whether this will impact IPsec tunnels or GlobalProtect connections that terminate on those same IPs. Additionally, do I need to place a separate management‑allow rule above the Stealth rule to avoid blocking legitimate admin access?

Any guidance would be greatly appreciated.

[TomYoung]

Hi @ititsw ,

Traffic from the outside going to the outside interface of the NGFW is normally allowed by the intrazone-default rule.  You can create a "stealth rule" to block this traffic for an additional layer of security.  I do it for my NGFWs.

You WILL need to create rules to allow IPsec and GlobalProtect tunnels as you mentioned.  My S2S VPN rule allows the ipsec parent application only from known IPsec peers.  My GP rule allows ipsec-esp-udp, panos-global-protect, and ping (optional) only from an EDL or known source countries.

After your allow rules, you can create a universal (interzone and intrazone) drop rule for all other traffic coming from the outside zone.  If your NGFW uses BGP with your ISP, you will need to allow that also.  Make sure you place your stealth rule after all other existing inbound rules.  An "inbound" tag for the rules is always a good idea.  If you want to allow outbound pings from the outside interface (on the outside zone), you will need to allow that also.

Typically, management is not enabled on the outside interface.  If you created an Interface Management Profile and attached it to the outside interface, then you would also need to allow management traffic.  It is not recommended.  The preferred way to manage the NGFW would be onsite or over a VPN.

This rule is very effective and blocks a LOT of hacking attempts.

Thanks,

Tom

[reaper]

typically you should set up your 'ingress' rules so you allow only what you absolutely need and drop everything else

good practice is to put those rules at the very top of your rulebase so an accidental 'any any' further down doesn't let in any bad things from the internet

a typical layout would be something like this:

-block embargo countries and known malicious IP addresses (from palo EDL for example), set the service to 'any'

-allow inbound server connection (smtp,https,...). make sure you define app-id and ports (app-default is fine, just don't put 'any' in the service)

-allow in/outbound IPSec

-allow inbound GlobalProtect

-drop (this is silent making it 'stealth') all other packets from source untrust (destination ANY so it accounts for NAT rules etc), set the service to 'any'

As @Tom  mentioned, if you are hosting admin access on your untrust interface, migrate that access to GlobalProtect as soon as possible (#1 top priority) as this is extremely risky

[abayoumi21]

In my opinion, a Stealth rule is typically a “deny any any” rule designed to drop unwanted traffic to the firewall itself. The main benefit of this rule is that any traffic not explicitly allowed by other security rules will be dropped and appear in the traffic logs, giving you visibility into potentially malicious activity.

To implement this safely:

1. Allow management access first

   • Place explicit management-allow rules (for SSH, HTTPS, GlobalProtect, IPsec, etc.) above the Stealth rule to ensure legitimate administrative or VPN traffic is not blocked.

2. Use explicit controls in all security rules

   • Leverage App-ID, User-ID, and Security Profiles whenever possible.

   • Build a communication matrix to map which devices need access to which services and restrict rules accordingly to harden the environment.

3. Logging and monitoring

   • Enable logging on the default intrazone rule to capture unexpected traffic.

   • Log all traffic dropped by the Stealth rule for visibility and auditing.

4. Additional top-of-policy rules

   • Blacklist/EDL rules to block traffic from known malicious IPs.

   • URL category blocking rules to prevent access to malicious websites.

   • Sink-hole rule to redirect compromised devices to a sinkhole IP instead of allowing them to resolve malicious domains.

5. VPN-specific recommendations

   • Restrict VPN access to only the required countries.

   • Enforce MFA for all VPN users.

   • Utilize Host Profiling / Device-ID to ensure only compliant devices can access critical resources through security rules.

By following this approach, the Stealth rule acts as a safety net for all other traffic, while legitimate management, VPN, and application traffic remain functional. Combined with the communication matrix and layered controls (sink-hole, EDLs, profiling), this helps secure your environment comprehensively.