Administrator rules for your PANW firewalls (work in progress)

Will you let your kids play with your gun? I hope not.

With your firewall, I think you should do the same.

Letting the firewall managed by people who don't know exactly what they are doing, and the risks implied because of the applied configuration can be catastrophic in case of breach : it is like having a lock on your door, but leaving the door opened; do not get surprised if something bad happens then.

The purpose of this article is to provide a list of things to do or not to do on the firewall.

This list will always remain as a work in progress, as things change over time. But it will save you from some basic mistakes.

- Have a backup local account

What do you do if your main local admin account is not working? 

In case you have a strict account policy, set this account with just the CLI access so if the main account is locked, the TAC engineer can do something.
Note: unfortunately, the account need superuser right.

- Set an export of the configuration on a regular basis to an external location

How to recover a firewall due to a hardware issue (HDD dead)?

You can easily set up a regular export of the configuration via SCP

- For firewalls managed by Panorama, make sure that the local configuration has the minimal configuration to reach Panorama

In case you have a blank device (replacement device or factory reset), the Panorama will push the configuration, but the connectivity between the firewall and Panorama need to be set up first.

- Do not disable Template without importing the templates to the local configuration

Once you disable the templates, you will ne be able to commit any config until you recreate all the template configuration in the local policy or you disable the device groups pushed.

- Enable logs on the default interzone rule

It will save you time when you do not see your dropped traffic.

- Keep the software up to date

If your firewall is not regulary updated, and it misses security fixes, how can you be sure that your firewall is not compromised? We already cannot be sure that a firewall running on the latest release is not compromised (0-day), so do not expect it from a firewall running a software release 2 years ago.

Try to keep the firewall uptime below 90 days.

- x.16 is more stable than y.3

It is simple : when you reviewed a code for the 16th time, your code is more reliable than a code reviewed only 3 time.