Filter rules with no log forwarding profile configured

[Anon1]

Anybody knows a trick how to filter for rules with no log forwarding profile configured?

(log-setting eq 'Profile-Name') => all rules with Profile-Name

!(log-setting eq 'Profile-Name') => does not work, shows all rules

(log-setting neq 'Profile-Name') => does not work, shows no rules

(log-setting eq none) => does not work, shows no rules

[Brandon_Wertz]

(log-setting eq 'Panorama')  = Gives me panorama

(log-setting eq '') = Gives me empty values

'' is also useful in user-id searches as it gives you "empty" user-id log matches

[reaper]

this may be useful : Tips & Tricks: Filtering the security policy

log filters look for a positive match in the config file (or a negate of a positive match). values that have not been set can't be searched (in essence, any policy that does not have log forwarding set will not have the attribute in the XML of the config file)

one exception is when a policy used to have it set, and later was removed, the attribute will remain

unfortunately this makes it a little more difficult if you need to look for 'something thats NOT there'

[Anon1]

Hello, thanks for all your replies.

Unfortunately (log-setting eq '')  does not work for me either. It finds nothing, but there are definitely rules with Log Forwarding = None. Probably due to the behavior reaper mentioned.

[Remo]

Hi @Anon1

Depending on the amount of rules you have it might be worth to spend some time with learning - learning about the XML API and XPATH. If you're alrrady familiar with these topics: Great, then this should be easy for you.

Some basics you can find here: https://live.paloaltonetworks.com/t5/Community-Blog/Export-the-security-rulebase-using-XML-API/ba-p/...

The most important API request in this case for you is:

https://{FIREWALL-IP}/api/?type=config&action=show&key={APIKEY}&xpath={XPATH}

With XPATH you should be able to get only the rules without a log forwarding profile configured.

This XPATH will show you all the existing rules:

/config/devices/entry/vsys/entry/rulebase/security

If you now add a NOT statement to this XPATH to exclude all the rule with a log forwarding profile:

[not(rules/entry/log-setting)]

Combined this will give you this API request:

https://{FIREWALL-IP}/api/?type=config&action=show&key={APIKEY}&xpath=/config/devices/entry/vsys/entry/rulebase/security[not(rules/entry/log-setting)]

With this final request, I am actually not 100% sure if this really works but you can test this easily (copy&paste - done). @reaper: Do you know if the XML API has FULL support for XPATH queries?

If this does not work, you need to do it in two steps with the help of a scripting language, where you first do the rulebase query and then to the additional XPATH query to reduce the output to the rules without log-forwarding profile. (If it does not work and you're interested in this solution I can post a short example with powershell).

Regards,

Remo

[Anon1]

Hello Remo,

thank you very much for the detailed information. It is very helpful.

[reaper]

hi @Remo

Sorry for the late reply

the xpath should fully work, but i dont think you can use 'not' operators (i can't get those to work anyway)

I'm not the penultimate expert either so I may be wrong 😉

[JoeAndreini]

@Remo and @reaper

I tested this on panorama (7.1.10) and the 'not' operator worked as expected.

This is briliant, I was unaware of the ability to use filters in xpaths like this - I pull the entire config branch, and use a foreach loop and "if" statements to find the applicable entries for this and other instances.  Thank you for saving me a lot of future time.

[reaper]

Interesting! Would you mind sharing your full command (minus IP and Key) so I can document this properly?

[JoeAndreini]

In today's example, I needed to add log-forwarding profiles and threat profile groups to rules that had been imported from the migration tool:

Powershell:

I declare a few variables

$panoramaIP =

$apiKey =

$deviceGroup =

I run two "get" calls to obtain the rules that are missing one or both items:

$noLog = invoke-restmethod -URI "https://$panoramaIP/api/?key=$apiKey&type=config&action=get&xpath=/config/devices/entry/device-group/entry[@name='$deviceGroup']/pre-rulebase/security/rules/entry[not(log-setting)]"

$noProfile = invoke-restmethod -URI "https://$panoramaIP/api/?key=$apiKey&type=config&action=get&xpath=/config/devices/entry/device-group/entry[@name='$deviceGroup']/pre-rulebase/security/rules/entry[not(profile-setting/group)]"

I dig a little deeper in my x-path to make future commands shorter

Then for each policy in the lists, i use set calls

for log forwarding:

invoke-restmethod -URI "https://$panoramaIP/api/?key=$apiKey&type=config&action=get&xpath=/config/devices/entry/device-group/entry[@name='$deviceGroup']/pre-rulebase/security/rules/entry[@name='$($policy.name)']&element=<log-setting>Log-Forwarding-Profile</log-setting>"

for profile group:

invoke-restmethod -URI "https://$panoramaIP/api/?key=$apiKey&type=config&action=get&xpath=/config/devices/entry/device-group/entry[@name='$deviceGroup']/pre-rulebase/security/rules/entry[@name='$($policy.name)']&element=<profile-setting><group><member>Profile_Group</member></group></profile-setting>"

obviously these are only snippits of a longer script.  I imagine with the approriate tweaks these xpaths and commands would work for a firewall.