[Solved] Palo Alto Diff since 2.3

[fti-msmith]

Is there any way to edit the commands that are run for a specific vendor backup? Specifically Palo Alto.

Since 2.3, we get extensive diff alerts based on the way backups are generated by 'show running security policy' and external dynamic lists.

Currently, the backup looks like this

Code: Select all

# command: "show running security-policy"

"Palo_Alto_AttackerDB_Inbound; index: 1" {

        from any;

        source [ 10.99.85.0-10.99.85.255 172.23.205.0-172.23.205.255 ... ];

but previously unimus was not running the command 'show running security-policy'. Because the security policy uses external dynamic lists (which change quite frequently) - we are alterted to these changes when we really don't care since these are managed by 3rd party blacklist providers.

Any suggestions are greatly appreciated.

[Tomas]

Hi,

We added the output of "show running security-policy'" to backups due to Panorama-managed PAs not outputting any policies at all in their config - even tho they are configured. Other users were complaining that this caused changes in PA config (even when introduced from Panorama) to not be visible in Unimus, therefore breaking change management.

Sadly, PAs indeed output addresses in random order in "show running security-policy'", and this causes issues like you are seeing. We will deal with this on our end (introduce sorting of the addresses by Unimus), but in the meantime, you can create an ignore filter for PA with this regex:

Code: Select all

(?m)^\h*(?:source|destination)(?:-region)?\h\[(.+?)\](\h\(.+?\))?;$

In "Backups > Configuration", create an "Ignored data filter", and this should suppress any changes to address lists in policies.

[fti-msmith]

Thank you. I will test this out.

I would suggest the option for both options. I personally don't need policy config of my PA managed firewalls in a backup diff - since the configuration of those polices live on Panorama which we also backup.

[dominik.c]

Greetings,

We have a new Unimus version 2.4.2 live now, where we fix an issue with randomly order of IP addresses. Here's the https://unimus.net/download.html and changelog viewtopic.php?f=3&t=1748.

If you get a chance, give it a try and let us know if it works as expected.

Thank you and have a nice day.

[fti-msmith]

Greetings,

We have a new Unimus version 2.4.2 live now, where we fix an issue with randomly order of IP addresses. Here's the https://unimus.net/download.html and changelog viewtopic.php?f=3&t=1748.

If you get a chance, give it a try and let us know if it works as expected.

Thank you and have a nice day.

Thanks. We have updated and will update if we continue to see issues.

[fti-msmith]

We are still noticing an issue that I believe is a sorting issue.

Example sample below

Code: Select all

source [ 10.1.200.2 10.1.200.251 10.1.200.48 10.1.200.49 172.25.200.109 172.25.79.20 172.27.240.0/20 172.30.12.45 172.30.16.45 172.30.20.45 172.30.255.21 172.30.255.24 172.30.28.44 172.30.4.45 172.30.64.42 172.30.68.45 172.30.72.45 172.30.8.45 172.30.98.44 172.30.99.24 ];

Change detected was as follows

Code: Select all

source [ 10.1.200.2 10.1.200.251 10.1.200.48 10.1.200.49 17 172.25.79.20 172.27.240.0/20 172.30.12.45 172.30.16.45 172.30.20.45 172.30.255.21 172.30.255.24 172.30.28.44 172.30.4.45 172.30.64.42 172.30.68.45 172.30.72.45 172.30.8.45 172.30.98.44 172.30.99.24 2.25.200.109 ];

Looks like the the 5th object - 172.25.200.109 address was split with 17 separated but the remainder shows as 2.25.200.109?

[fti-msmith]

Is there any update on when this will be fixed? We run a network of primary PA firewalls and the constant detected changes due to lack of proper IP address sorting means we get dozens of daily emails with little or no actual changes which means output from Unimus is just noise. I would much prefer the ability to turn off the retrieval of Panorama puhsed objects and policies from the backups at this point.

[Tomas]

Is there any update on when this will be fixed?

Apologies on the long resolution time on this. The team is looking at this now, we hope to have this completely fixed in 2.5.0.

[Tomas]

Update: we have just released 2.5.0, which contains an additional fix for these Palo issues. This combined with the previous fix should hopefully eliminate all erroneous diffs on Palo. More info: viewtopic.php?f=3&t=1819