topic Re: Pingdom & Management Profiles in General Topics

Pingdom & Management Profiles

Brett.Hoshaw — Wed, 03 Apr 2019 20:42:20 GMT

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.

Re: Pingdom & Management Profiles

Raido_Rattameister — Wed, 03 Apr 2019 21:46:58 GMT

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

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 14:01:06 GMT

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.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 14:35:51 GMT

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

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 14:40:00 GMT

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.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 14:42:48 GMT

It does not pass security policy.

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

If no rule mathes then they will.

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 15:10:41 GMT

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.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 15:38:09 GMT

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.

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 16:14:22 GMT

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.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 16:14:05 GMT

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.

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 16:15:16 GMT

That's correct - it is populating correctly.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 16:16:55 GMT

Did you enable loggign on intrazone-default rule?

Do you see incoming pings now?

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 16:17:56 GMT

Intra and Inter zone logging are both enabled. There are no ~~logs~~ pings.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 16:21:51 GMT

Go to Monitor > Session Browser

Use filter:

(application eq 'ping')

Do you see active sessions?

What rule do they match against?

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 17:31:49 GMT

Negative. No ping sessions.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 17:39:05 GMT

If it is not constant ping thenyou might miss it because ping sessions are cleared after 6 seconds.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRiCAK

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 17:43:44 GMT

Fair enough. This would be one ping every minute - I can't specify the exact second between each minute. I did refresh the sessions page every few seconds for a couple of minutes and still didn't see any pings.

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 18:55:36 GMT

Alright, I figured it out. Feeling a little foolish here but essentially 3 of my 4 tabs were on the correct device in Panorama, the one that was not on the correct device had the IP I was setting up for rules, probes, etc.

~~Issue resolved, there was no foul play, just user error.~~

Still running into the same issue - why traffic is not hitting the security policy rule but instead hitting the inter/intra zone rules. I now see the traffic in the monitor, the dynamic list is populating the correct addresses, the destination address is correct but traffic flows are still aging out.

Re: Pingdom & Management Profiles

Brett.Hoshaw — Thu, 04 Apr 2019 19:23:29 GMT

Fixed the rules, needed to set the security policy type to 'intrazone' and changed the application from 'icmp' to 'ping'.

Now traffic logs are hitting the rule, however still timing-out. I'm wondering if this is due to the management profile now allowing the IPs for ping.

Re: Pingdom & Management Profiles

Raido_Rattameister — Thu, 04 Apr 2019 19:43:14 GMT

By timing out you mean session end reason?

Well this is normal for udp and icmp protocols.

In case of TCP there is session setup and teardown procedure.