Pingdom & Management Profiles

Reply
Highlighted
L2 Linker

Pingdom & Management Profiles

Quick write here.  We currently use Pingdom to monitor external reachability to services and our remote office edge devices.  In some scenarios such as new office deployments, we may need to utilize the WAN interface to setup the device.  The problem here is the All-or-None approach of management profiles.  We want only ping from pingdom's probes and http from our specified management nodes.

 

Since pings to any interface are considered 'management' there's no way to setup a security policy to allow the probes, so my next question is now whether or not this is even possible?

 

Thanks in advance.


Accepted Solutions
Highlighted
L2 Linker

That's true!

 

I did get this working, now it's just a matter of locking it down.  I was able to allow ping outside via and intrazone rule, allowing ping in the management profile for the external interface, and removing the addresses in the management profile.

 

Here's a link to how it was solved, not exactly what I was trying to do but same solution.

View solution in original post


All Replies
Highlighted
L7 Applicator

Can you configure GlobalProtect to connect to remote offices?

If not then you can create loopback interface and permit management on it (or DNAT to mgmt interface directly).

Set up DNAT to this loopback for mgmt traffic.

In security policy specify what source IPs are permitted to connect to manage firewall.

On external interface permit ping-only mgmt profile.

 

Be careful to limit this traffic as every now and then there are issues with security on mgmt traffic ( https://securityadvisories.paloaltonetworks.com/ ).

 

 

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Highlighted
L2 Linker

Thanks for the link.  Question - it seems like those vulnerabilities are all towards the 'management interface'.  In my case, the management interface would not be accessible externally only internally.

 

I need a management profile on an external interface to allow pingdom probes to ping it, however I also need a management profile on the same interface to allow remote access in case of setup failures or VPN outages.

 

The loopback is a good idea but I question the security policy aspect since it seems like ping traffic with a destination of an interface on the palo does not show up in the traffic monitor which makes me wonder if this specific type of traffic is going to a different process - as if it classifies it as management traffic and compares it against the management profile.

Highlighted
L7 Applicator

Security policies are evaluated top to down. 

First one that matches will take effect (either permit or deny).

If you don't have custom rule like this:

from zone - wan

from address - any

to zone - wan

to address - fw public ip

application - ping (or more relaxed like any)

 

Then at the bottom intrazone-default rule will match.

This is not configured to write log by default.

 

Click on intrazone-default rule.

Click override at the bottom.

Open rule.

Actions tab.

Check "log at session end"

 

Do the same with interzone-default

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Highlighted
L2 Linker

I'm familiar with the evaluation, what I'm not familiar with is how Palo treats specific traffic.

 

I had a specific security policy yesterday setup to allow pingdom probes to ping the external interface.  The pings still failed and the traffic monitor never showed any indicatation this traffic was attempted.

 

This is why I'm assuming that if traffic matches ping and the destination is the physical interface, it bypasses the security policy and utilizes the management profile instead.

Highlighted
L7 Applicator

It does not pass security policy.

Enable loggign on intrazone-default and interzone-default rules.

If no rule mathes then they will.

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Highlighted
L2 Linker

Alright, I think we are going in circles here.

 

Security policies are evaluated top to down. 
First one that matches will take effect (either permit or deny).

If you don't have custom rule like this:
from zone - wan
from address - any
to zone - wan
to address - fw public ip
application - ping (or more relaxed like any)

Then at the bottom intrazone-default rule will match.

This is not configured to write log by default.
 
Click on intrazone-default rule.
Click override at the bottom.
Open rule.
Actions tab.
Check "log at session end"

Do the same with interzone-default

The specific rule did exist in the security policy yesterday so the intrazone-default rule should not be catching this - therefor there should be a log and it should show in the traffic monitor tab, correct?

 

It does not pass security policy.
Enable loggign on intrazone-default and interzone-default rules.
If no rule mathes then they will.

Now you've got me confused.  You said if there is a specific rule it should match and log there correct?  Otherwise it goes to intrazone-default or interzone-default.  So, even if there is a rule in the security policy for this traffic, it is still no matter what, considered intrazone-default or interzone-default? I have to turn on the logging for those to see the traffic logs, but this does not help reach the end goal of specifying what can and cannot ping an interface and what can browse (https) to the external interface.

Highlighted
L7 Applicator

Well if the rule would have matched it would be in the log.

For example if you have following Security policy then you should see log:

From zone - wan

To zone - wan

From address - any

To address - fw public IP

Application - ping

 

As soon as you add DNAT rule like the one below your security policy does not match any more because destination zone of the session is now LAN (not WAN):

From zone - wan

To zone - wan

Service - any

To address - fw public IP

Destination NAT to - some internal ip

 

In this case the rule does not match any more because <some internal ip> is in LAN zone and destination zone is switched in session header before security policy is checked so without knowing exactly how your security and nat policy were set up we don't know if the rule supposed to match.

 

For this reason i suggested to enable logging on default rules.

 

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Highlighted
L2 Linker

I see now, I never setup the DNAT because I didn't want to expose the management interface externally.  So the rule in place is

 

From - External

Source - Probes

To - External

Destination - External Interface

 

I'm also questioning whether the external dynamic list is correctly populated.  I assume it does an initial pull before it re-checks on the schedule specified in creation?  Is there a way to see the current value of an external dynamic list?

 

The external dynamic list is populating correctly, verified through CLI.

 

After 30 minutes we should have seen 30 logs, yet there's nothing there, even with the intra/inter logs enabled and filtering explicitly on the external interface address as the destination.

 

At this point I'm convinced that the management profile set on the external interface is the reason why it's failing and again the fact that you're pinging a physical interface proves that they somehow handle this management traffic differently than normal intra/inter zone traffic.

Highlighted
L7 Applicator

Are you using External Dynamic List?

In this case you can see entries if you go to Objects > External Dynamic Lists

Open the one you are using as source address.

List Entries And Exeptions tab.

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!