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