Config Audit

[MarkDufault]

Hi Everyone - I wanted to pose this question to the folks out there that may be feeling the same as I do about the way the config audit feature works. It is supposed to be a simple way to do a diff on config changes/deletes. I have found that palo seems to insert simicolons and braces throwing off the reporting and making it less than optimal for a tool that should be more simple. I am on v 8.1.6 and use panorama also, just fyi. I have heard some of the explanations as to why but it doesn't change the end game of the tool be less useful.

I have a case opened Case#: 01355897.

The programming team that created and maintains the PAN-OS normally does not give information about its internal design in the interest of platform security.
The programming team does not share their software designs with the members of the technical support staff.

I believe that the main reason for these changes is to consolidate disk space.
For example, a PA-200 can only have a maximum of 2500 address objects.
Firewall administrators can add and delete address objects over a period of time which can cause gaps in the address objects database.
In order to keep the database as small as possible,
the firewall might perform cleanup procedures which might include moving addresses that are high in the list into sections of the database where other addresses were deleted previously.

[kiwi]

Hi @MarkDufault ,

What is your question exactly ?

Cheers,

-Kiwi.

[MarkDufault]

I'm trying to rally the users for support so that palo will address the issue of the config auditor and make the tool work better to find changes. What is your experience with the tool? DO you see the same thing I am seeing. Would you like it to work better and more easily to find actual changes in the config and not one induced by the programmers.

[kiwi]

Hi @MarkDufault ,

Honestly, I don't see this issue of added brackets or semicolons.   Blank lines I see yes ... when configuration is removed.

For me the Config Audit reflects the changes perfectly.

Green = Added new configuration

Red = Removed configuration

Yellow = Changed configuration

Nowhere do I see added semicolons or brackets in the Config Audit, unless of course it is required by the XML formatting by adding new config.

The blank lines I do see in the config audit when configuration is removed.  But if you look at the numbering going from 948 to 949 in the  screeshot below... you'll know that there are no actual lines there... it's just to visualize the changes made.  Exporting the config should have no empty lines there.

removed config

Or are you seeing this behaviour only when performing certain changes on the config (removing and adding address objects for example ... I haven't tested that) ?

Maybe more people can share their experience.

Cheers !

-Kiwi.

[MarkDufault]

Here would be my example:

These are riddled all over the place making it difficult to find the REAL changes.

Also, I would add that my version of code is not changing, so it is the same version on left and right panes.

[MarkDufault]

Sorry, I should have included more lines for context:

[BPry]

@MarkDufault,

This is due to mixing configuration methods (IE: Using the CLI and the GUI, mixing CLI with XML/API). If you want this to remain static, pick a configuration method and dedicate changes to only utilize that method. 

[MarkDufault]

We don't do changes very often via CLI. And these diffs are not related to that since we have not done any recently.

We do changes via panorama. We have dynamic EDL's, Minemeld, etc...

I don't know the inner working of how the above work, and they may cause some issue.

We also apply updates via panorama by schedule.

It is a real pain in the neck to try to find where the changes are when the config is riddled with yellow like the previous snippet.

There are too many for me to include them all in this forum but they are all similar to what I pasted in.

If others have similar experiences, please chime in, I would really like palo to take note and see if they can come up with a fix.

[BPry]

@MarkDufault,

The difference that you are seeing has to do with how the underlying XML configuration is actually specified; if you would export the configuration versions you could visually see what the difference is in the XML. Usually, this is caused by changing how you are making changes, but even the order of operations of how you modify some of these settings in the GUI can cause minor differences like this.