- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
04-12-2018 09:45 AM
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
04-12-2018 11:42 AM - edited 04-12-2018 11:45 AM
(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
04-13-2018 02:28 AM
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'
04-13-2018 04:11 AM
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.
04-15-2018 12:55 PM
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
04-17-2018 02:04 AM
Hello Remo,
thank you very much for the detailed information. It is very helpful.
04-17-2018 02:03 PM
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 😉
04-18-2018 07:22 AM
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.
04-18-2018 08:47 AM
04-18-2018 10:31 AM
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.
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!