Rule base documentation

[jdprovine]

PA Best practice says you should have your rules documented on the rules and some where other than your rule base. Anyone doing that? and if so how

[Remo]

Hi @jdprovine

We do this in our Changemanagement. Every Rule (Name,srczone,srcaddress,srcuser,dstzone,dstaddress,ports,apps,URL category,Log forwarding, security profiles) and specially every rulechange is documented there and depending on the actual Firewall the change also needs so be approved by different Security officers.

Regards,

Remo

[jdprovine]

@Remo

Yeah that would be great to do change management LOL, unfortunately we do not. 

[OtakarKlier]

Hello,

What we did was go through the entire firewall settings and approved the base. Then any firewall change requires approved chagne management. At the end of each month I have to review the changes with our security officer and justify them. This is how we get around certification and changes that are forced onto us by the customers. 

For security reasons we do not keep like an excel spreadsheet of all the rules. That said, you can export the rules into a CSV.

https://indeni.com/how-to-export-palo-alto-networks-firewalls/

Just a thought.

[jdprovine]

@OtakarKlier

I actually exported the configuration change logs to a csv and we backup the running config dail

[BPry]

@jdprovine,

So what I would recommend doing is having a bash or PowerShell script that pulls the running-config.xml from the firewall on a nightly basis, and saves it to a backed-up location. In this instance you would have a backup of your entire configuration and if need be, you can easily get replacement equipment up and running quickly. 

If need be I can share an example PowerShell script. 

[jdprovine]

@BPry

I would a appreciate you sharing some script 

[BPry]

$netAssembly = [Reflection.Assembly]::GetAssembly([System.Net.Configuration.SettingsSection])

if($netAssembly)
{
    $bindingFlags = [Reflection.BindingFlags] "Static,GetProperty,NonPublic"
    $settingsType = $netAssembly.GetType("System.Net.Configuration.SettingsSectionInternal")

    $instance = $settingsType.InvokeMember("Section", $bindingFlags, $null, $null, @())

    if($instance)
    {
        $bindingFlags = "NonPublic","Instance"
        $useUnsafeHeaderParsingField = $settingsType.GetField("useUnsafeHeaderParsing", $bindingFlags)

        if($useUnsafeHeaderParsingField)
        {
          $useUnsafeHeaderParsingField.SetValue($instance, $true)
        }
    }
}
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
$ConfigTime = Get-Date -Format "MM-dd-yyyy"
# Config File Logation
$ConfigFile = '\\fs1\Enterprise\Documentation\Network\Palo Alto\PA-3020 Backups\'+"running-config-"+$ConfigTime+".xml"
$wc = New-Object System.Net.WebClient
# Takes the running-config and saves it to the S drive.
$src=$wc.DownloadString("https://10.191.136.7/api/?type=export&category=configuration&key=*key*") | Out-File $ConfigFile
# Attempts to remove the commit lock if one is held by bpry.
$src=$wc.DownloadString("https://10.191.136.7/api/?type=op&cmd=<request><commit-lock><remove><admin>bpry</admin></remove></commit-lock></request>&key=*key*")
# Commits the current canidate-config.
$src=$wc.DownloadString("https://10.191.136.7/api/?type=commit&cmd=<commit></commit>&key=*key*")

Obviously you would replace 10.191.136.7 with whatever IP your firewall is on, and replace the destination of $ConfigFile with whatever location you are going to save to. The *key* is going to simply be your API key which you'll need to generate if you haven't done so already. 

What this script will do is take a backup of the running-config with the first API call; then it removed a commit lock that I would potentially have in place (I have three lines for removing possible commit locks) and then it simply commits the current canidate-config. 

You can simply issue the first line if you simply want a backup to be taken; however I use the entire script as a sort of 'scheduled commit' so that all of the changes that I've made throughout the day simply take effect at 10pm; you simply need to ensure that your team knows about this so that they don't leave something half-finished. If the config isn't valid obviously this will fail automatically during the commit process, but I wouldn't chance that. 

[Remo]

What is the goal now? Documentation or backup 😛

[jdprovine]

@Remo

For me it is to keep track of who made changes to the firewall and when.  We have a user or two who do not communicate when they make changes and why they are doing it.  We also do not have a change management process,not good. So I guess I am doing a little of both backing them up so I can review what has been done.  Sometimes the logs roll over and I loose the history.

[OtakarKlier]

Hello,

I can see how that can be a real pain. For the time being, unless you have a lot of changes, you can refer to the Configuration logs? 

Monitor tab -> Logs-> Configuration

That should let you know who made what changes. However a good change management policy should help out as well, expecially since there are many admins working in the systems.

You can setup alerts to email you when changes are made. 

Device tab -> Log Settings -> Configuration area.

Cheers!

[jdprovine]

@OtakarKlier

Yep I have started to export the config logs from monitor/configuration to maintain history. Though i also check those logs daily.

[Remo]

@jdprovine

This is bad when there is a security admin (you) needed to controll other admins. Do they know what what they have to do or is there maybe a conversation with the supervisor needed?

As mentionned by @OtakarKlier you can configure alert emails when someone changes the configuration or limit these alert emails to the commit-log-events. This way you know at least when someone changed something. And as you then directly have the timestamp you can probably check the config logs more easily and find out what they changed.

You may be also want to try a script that automatically pulls the config logs hourly/daily so this saves your time with the manual config-log-export-task.

[jdprovine]

@Remo

Well we have not change management in place so you can't hold people accountable for what you do not have rules concerning. I have heard for that last year that they want to put change management in place, I do think that would help

[Remo]

Hi @jdprovine

Ok, thats true. But you could also have some teaminternal guidelines that make it easier for all when they know what's been done and noone needs to waist time searching for a change which may resultet in something not working anymore.

@kiwi probably also read this topic 😉 ... and if not it's luck that he posted a blog post exactly about this config log topic and the basics on how to automate this here: https://live.paloaltonetworks.com/t5/Community-Blog/The-Power-of-XML-API/ba-p/202789