About nembery

Validation Skillets can be extremely powerful tools to ensure configuration compliance of all your next-generation firewalls. They can especially be useful in situations where Panorama is not an option. In this post, we'll walk through how to build a simple validation skillet.   Just like building a configuration skillet, we will use the Skillet Builder tools to help us build our validation skillet. If you aren't familiar with the Skillet Builder tools, Get Started Building your first Skillet.   Validation skillets work by comparing the raw configuration objects against a set of rules. If you aren't deeply familiar with the XML structure of the next-generation firewall configuration, I recommend using the web interface debug window. This essentially works by showing you what XPaths and XML fragments are being modified as you make changes in the web interface. To get to the TLDR; version, open a browser tab to your next-generation firewall and log in. Then open another tab and navigate to https://$NGFW_IP/debug, hit the clear debug button to get a fresh start, and click the debug checkbox.   With the debug window now open and cleared, you can find the XPath setting we want to validate. Navigate to the setting you would like to validate in the web interface and make a change. You don't need to commit this change, just change some small value. For example, click a checkbox or change a name.    In this example, I am going to create a validation to ensure telnet and HTTP are disabled on the management interface. I will navigate to settings in the web interface and toggle the values there.   Browse to Device > Interfaces > Management Management Interface Settings   I checked the Telnet and HTTP options and clicked OK.   Back in the debug tab, once you hit Refresh, you should see a ton of debugging output. Inside, you will see the specific XPath and XML fragments that were modified by changing these values in the web interface.   In this case, the output was in part:   [2020/02/28 15:04:08] user=6556896827576927 <request cmd="get" obj="/config/devices/entry[@name='localhost.localdomain']/deviceconfig/system" cookie="6556896827576927"/> [2020/02/28 15:04:08] user=6556896827576927 Response took 0.038s <response status="success" code="19"><result total-count="1" count="1"> <system admin="admin" dirtyId="17" time="2020/02/28 15:00:44"> <dns-setting> <servers> <primary>1.1.1.1</primary> <secondary>1.0.0.1</secondary> </servers> </dns-setting> <hostname>panos-06</hostname> <type> <static/> </type> <ip-address>192.168.128.4</ip-address> <netmask>255.255.255.0</netmask> <default-gateway>192.168.128.1</default-gateway> <update-schedule> <statistics-service> <application-reports>yes</application-reports> <threat-prevention-reports>yes</threat-prevention-reports> <threat-prevention-pcap>yes</threat-prevention-pcap> <threat-prevention-information>yes</threat-prevention-information> <passive-dns-monitoring>yes</passive-dns-monitoring> <url-reports>yes</url-reports> <health-performance-reports>yes</health-performance-reports> <file-identification-reports>yes</file-identification-reports> </statistics-service> <threats> <recurring> <every-30-mins> <at>2</at> <action>download-and-install</action> </every-30-mins> <threshold>48</threshold> </recurring> </threats> <anti-virus> <recurring> <hourly> <at>4</at> <action>download-and-install</action> </hourly> </recurring> </anti-virus> <wildfire> <recurring> <every-min> <action>download-and-install</action> </every-min> </recurring> </wildfire> <global-protect-datafile> <recurring> <hourly> <at>40</at> <action>download-and-install</action> </hourly> </recurring> </global-protect-datafile> <global-protect-clientless-vpn> <recurring> <hourly> <at>50</at> <action>download-and-install</action> </hourly> </recurring> </global-protect-clientless-vpn> </update-schedule> <snmp-setting> <access-setting> <version> <v3/> </version> </access-setting> </snmp-setting> <ntp-servers> <primary-ntp-server> <ntp-server-address>0.pool.ntp.org</ntp-server-address> </primary-ntp-server> <secondary-ntp-server> <ntp-server-address>1.pool.ntp.org</ntp-server-address> </secondary-ntp-server> </ntp-servers> <login-banner>You have accessed a protected system. Log off immediately if you are not an authorized user.</login-banner> <timezone>UTC</timezone> <service admin="admin" dirtyId="17" time="2020/02/28 15:00:44"> <disable-telnet admin="admin" dirtyId="17" time="2020/02/28 15:00:44">no</disable-telnet> <disable-http admin="admin" dirtyId="17" time="2020/02/28 15:00:44">no</disable-http> </service> </system> </result></response>   If there is a lot of output, you can quickly find what was changed by searching for 'dirtyId'. This will indicate items in the config that are "dirty," which just means uncommitted values.   From this, I can see the modified XPath is: /config/devices/entry[@name='localhost.localdomain']/deviceconfig/system   Now, copy and paste an example validation Skillet to a new file and modify it to suite your needs. I copied one from the Example Skillets Repository.   name: ensure_telnet_and_http_disabled label: Ensure Telnet and HTTP is disabled per compliance policy description: | Checks the configuration to ensure telnet and HTTP are disabled type: pan_validation labels: collection: - Example Skillets - Validation variables: snippets:   So far, I've left variables and snippets both blank. I know from the debug tool which XPath I need for the setting we are interested in. The first step is to parse the configuration for that specific XPath, so I can perform some logic against it. Let's add the first snippet to do just that:   - name: parse config variable and capture xpath as an object cmd: parse variable: config outputs: - name: system_object capture_object: /config/devices/entry[@name='localhost.localdomain']/deviceconfig/system   The key to validation skillets is parsing the config into objects that can then be evaluated using logic. There are a couple of options for how to do this. The most important are 'capture_list' and 'capture_object'. In this case, you want to capture a single object from the XML fragment found at that XPath.   This snippet will place an object in the context with the name 'system_object', which reflects the XML structure found at the given XPath converted to JSON.   The exact structure of the JSON object is what you will test to determine if this config is in compliance or not. To explore the structure in more detail, you can use the Configuration Explorer Tool in the Skillet Builder Tools collection.   Configuration Explorer Tool Preview   This tool is very similar to the API Explorer tool in the PAN-OS next-generation firewall web interface. However, it allows you to experiment with advanced XPath queries.    Once you run this tool, the output will show the exact structure of the configuration for that XPath in both XML and JSON formats.   { "system": { "dns-setting": { "servers": { "primary": "1.1.1.1", "secondary": "1.0.0.1" } }, "hostname": "panos-06", "type": { "static": null }, "ip-address": "192.168.128.4", "netmask": "255.255.255.0", "default-gateway": "192.168.128.1", "update-schedule": { "statistics-service": { "application-reports": "yes", "threat-prevention-reports": "yes", "threat-prevention-pcap": "yes", "threat-prevention-information": "yes", "passive-dns-monitoring": "yes", "url-reports": "yes", "health-performance-reports": "yes", "file-identification-reports": "yes" }, "threats": { "recurring": { "every-30-mins": { "at": "2", "action": "download-and-install" }, "threshold": "48" } }, "anti-virus": { "recurring": { "hourly": { "at": "4", "action": "download-and-install" } } }, "wildfire": { "recurring": { "every-min": { "action": "download-and-install" } } }, "global-protect-datafile": { "recurring": { "hourly": { "at": "40", "action": "download-and-install" } } }, "global-protect-clientless-vpn": { "recurring": { "hourly": { "at": "50", "action": "download-and-install" } } } }, "snmp-setting": { "access-setting": { "version": { "v3": null } } }, "ntp-servers": { "primary-ntp-server": { "ntp-server-address": "0.pool.ntp.org" }, "secondary-ntp-server": { "ntp-server-address": "1.pool.ntp.org" } }, "login-banner": "You have accessed a protected system.\nLog off immediately if you are not an authorized user.", "timezone": "UTC", "service": { "disable-telnet": "no", "disable-http": "no" } } }   Now you can see the XPath you want to check, and you can see the structure of the XML. You are now ready to create our first test. You captured the XPath into an object with the name 'system_object' in the parse step. Now, you can check that object to ensure the value of the disable_telnet element is equal to 'yes'.   - name: test_telnet_disabled label: Ensure Telnet is disabled on this device fail_message: Telnet should not be enabled on this device! test: system_object | element_value('system.service.disable-telnet') == 'yes' documentation_link: https://live.paloaltonetworks.com/t5/Skillet-District/ct-p/Skillets   The 'test' attribute uses the Jinja expression language to evaluate the expression as a Boolean. Jinja is useful here as it is a well understood, fairly simple expression language. It also offers a lot of built in operators and filters. Skilletlib also has a set of built in filters to optimize the task of working with a PAN-OS configurations.   This test uses the 'element_value' filter to find the value of the element at the path: system > service > disable_telnet. This syntax is very similar to the normal Jinja variable lookup syntax. However, the PAN-OS configuration causes a few wrinkles that necessitates a slightly more complex syntax. Namely, the use of '@attributes' names and names containing '-'. Because of this, we had to build our own variable lookup syntax. For the most part, you can treat this exactly like the normal Jinja variable look up syntax.   While we are here, let's go ahead and add another test as well. This time, we will ensure the HTTP service is also disabled.   - name: test_http_disabled label: Ensure HTTP is disabled on this device fail_message: HTTP should not be enabled on this device! test: system_object | element_value('system.service.disable-http') == 'yes' documentation_link: https://live.paloaltonetworks.com/t5/Skillet-District/ct-p/Skillets   Now, you are ready to test your skillet. In the Skillet Builder Tools collection, there is a Skillet Test Tool that is useful for this task.   Skillet Test Tool Preview   After pasting in the skillet and entering credentials for a running firewall, you will see the validation results.   Next, just to verify, change the next-generation firewall configuration back to have these values disabled and run the validation again.   Just for fun, I only disabled 'HTTP' and left 'Telnet' enabled.     After running the Skillet Test Tool again, I can see the Telnet check still failed while the HTTP check now passes. Great!   In summary, Validation Skillets can be used to verify configuration from very simple to very complex all using a simplified Jinja expression language and a few custom filters. Be sure to check out all the examples to get more ideas about how you can build your own validations for any use case! ... View more

Brief Description This skillet will automate the process of creating an SLR from a NGFW.   Target Audience This quickplay solution is designed for use by SEs, partners, customers, CEs and anyone who needs to perform a Security Lifecycle Review   Solution Details Authoring Group: This Skillet was designed by the Technical Marketing Engineering Group Documentation: https://github.com/ipzero209/SLR_Bot/blob/master/README.md Github Location: https://github.com/nembery/SLR_Bot.git Github Branches: master PAN-OS Supported: PAN-OS 7.1 – PANOS 9.1. Cloud Provider(s) Supported: Any and all providers are supported by this skillet Type of Skillet: Python3 Script Collections: Example Skillets Purpose: Any type of IPSec Tunnel Configuration   Detail Description This skillet will collect information from a NGFW then post that information to the SLR API. A report will then be generated and emailed to the supplied list of email recipients.   User Entered Variables The skillet supports use of the following variables:   firewall: IP Address or host name of the firewall from which to collect data username: NGFW authentication username password: NGFW authentication password support_api_key : API Key to access the Support Site email: List of email addresses where the report should be sent requestor_email: Email address of the person who is requesting the SLR report prepared_by : Name of the person who is requesting the SLR report   Additional SLR Information   Security Lifecycle Review ... View more

Skillets make it possible to share best practice and use-case specific configuration sets across PAN-OS and Panorama devices. However, getting started working with XML configuration can be tricky. Fortunately, there are a whole set of tools available designed to make this as painless as possible.   Using Panhandler, you can import the Skillet Builders repository from GitHub and get started right away.   First, import the Skillet Builders repository into Panhandler. Use the 'clone' link from Github as the URL to import the repository     Once imported, you will find a new Collection called "Skillet Builder." Click into that collection to see the available tools: Panhandler - Collections > Skillet Builder     Now that we have our tools installed, we can move on to the fun part—Configuring a NGFW! For best results, we recommend you start with a fresh NGFW with as few configuration options present as possible. If you only have access to a firewall that is already configured, that will work too, but may require a bit more work.     For this example, I'm going to configure a couple of address objects, but any configuration of arbitrary complexity will work just as well. Web Interface View of popup to enter Addresses     Here are a couple of address objects I've added: Web Interface View of popup with different Address     Note, that I have not yet committed these changes! Once i"m happy with my configuration, we can use a Skillet Generator tool to give us a starter Skillet.   In Panhandler, select the "Skillet Builder" Collection and choose the Generate a Skillet workflow: Skillet Builder - Generate a Skillet   The first question, is whether you want to generate a skillet from an uploaded config, or from a running NGFW. Choose the "From Running NGFW" option and click Submit. Skillet Builder Workflow Generate a Skillet Submit   Enter the authentication information for the NGFW what you just configured. We also have the option to choose the Configuration Source. Since all our changes are still in the Candidate Configuration, we will choose that option. If you were to choose the "From Running Configuration" option, the tool would generate a skillet comprised of all changes ever made to this device! Step 1: Generate a Skillet   Click Next to continue. Execute Skillet   In this step, we will customize the actual Skillet template. These are things like the name and description of what your Skillet does and why someone would want to use it. Step 2: Generate a Skillet - Customize Template   Click Next and you will receive the complete Skillet!   Generated Skillet # skillet preamble information used by panhandler # --------------------------------------------------------------------- # unique snippet name name: example_skillet_id # label used for menu selection label: Address Object Skillet description: This skillet creates two address objects in the NGFW # type of device configuration # common types are panorama, panos, and template # https://github.com/PaloAltoNetworks/panhandler/blob/develop/docs/metadata_configuration.rst type: panos # preload static or default-based templates extends: # grouping of like snippets for dynamic menu creation in panhandler labels: collection: - Example Skillets # --------------------------------------------------------------------- # end of preamble section # variables section # --------------------------------------------------------------------- # variables used in the configuration templates # type_hint defines the form field used by panhandler # type_hints can be text, ip_address, or dropdown variables: - name: hostname description: Firewall hostname default: myFirewall type_hint: text - name: choices description: sample dropdown list default: choices type_hint: dropdown dd_list: - key: option1 value: option1 - key: option2 value: option2 # --------------------------------------------------------------------- # end of variables section # snippets section # --------------------------------------------------------------------- # snippets used for api configuration including xpath and element as file name # files will load in the order listed # There is a variable called snippets that we can use to auto-generate this section for us snippets: - name: address-860650 xpath: ./devices/entry[@name="localhost.localdomain"]/vsys/entry[@name="vsys1"] element: |- <address> <entry name="some_address"> <ip-netmask>10.10.10.0/24</ip-netmask> <description>This is my address object </description> </entry> <entry name="another_address"> <ip-netmask>172.16.99.0/24</ip-netmask> <description>This is another address that I've decided to add as well</description> </entry> </address> # --------------------------------------------------------------------- # end of snippets section   This skillet now holds all the configuration options we configured in our firewall in a shareable format. This can be posted to Github, LIVEcommunity, or anywhere else for others to use.   Next Steps This generated output needs a bit of customization before you can publish. It includes a few variables as an example, but you'll note that those variables do not actually appear in the "element" sections of the snippets.To make this example a bit better, let's customize the value of the addresses being added.   First, we'll find the portions of the configuration on which we will allow customization. <entry name="some_address"> <ip-netmask>10.10.10.0/24</ip-netmask> <description>This is my address object </description> </entry>   We can make this more useful by allowing the user to enter their own values. <entry name="{{ address_name }}"> <ip-netmask>{{ address_cidr }}</ip-netmask> <description>{{ address_description }}</description> </entry>   I've added three variables 'address_name', 'address_cidr' and 'address_description'. Let's add these to the "variables" section of the Skillet as well. I'll use the 'text_hint' to give a hint to the tooling as to what type of data is allowed from the user. A complete list of type_hints can be found here. variables: - name: address_name description: Address Name default: some_address type_hint: text - name: address_cidr description: Address CIDR default: 10.10.10.0/24 type_hint: cidr - name: address_description description: Address Description default: Description of this Address Objet type_hint: text_area   Now the user can enter their own information, or choose the defaults and create their own customized address objects.   Sharing your new Skillet Now that you have a skillet in hand, let's upload to Github so everyone else can benefit from your expertise and hard work.   Log in to your GitHub account and Create a new Repository. Ensure you make this repository public and check the "Initialize this repository with a README" option. GitHub New Repository   Once created, click Create new file to add our Skillet. Create new file     Currently, all Skillets are required to be named '.meta-cnc.yaml'. So enter the name, then paste in your completed skillet.   nembery / simple skillet     Once completed, your Skillet can be used by everyone. Congrats! ... View more