stackstorm-exchange / stackstorm-paloalto Goto Github PK

License: Apache License 2.0

Python 100.00%

stackstorm-paloalto's Introduction

Palo Alto Networks Pack

This pack uses the Palo Alto Network developed library pandevice to implement a number of functions for interaction with Palo Alto Networks devices.

The actions in this pack are Panorama aware when appropiate. In most cases, you will reference the Panorama as the firewall and a desired device group via device_group.

Block threats on Palo Alto Networks (PAN) firewalls. This uses PAN HTTP server profiles (webhooks) which are available in PAN-OS version 8+.

Configuration

Copy the example configuration in paloalto.yaml.example to /opt/stackstorm/configs/paloalto.yaml and edit as required. After making changes, tell ST2 to load them with sudo st2ctl reload --register-configs.

Example configuration:

---
firewall:
  default:
    host: prodfirewall.corp.lan
    api_username: admin
    api_password: admin

You can configure serveral devices (both Firewalls and Panoramas) all under the firewall config section. The default device will be used whenever the firewall parameter is not passed in various actions. You may also use an api key instead of username/password for device authentication using the api_key parameter in the config of each device.

In order to obtain Palo Alto API key, run the command below. Replace firewall with the IP address of firewall, and provide the appropriate username and password:

curl -kgX GET 'https://firewall/api/?type=keygen&user=admin&password=password'

Actions

Currently, the following actions listed below are supported:

Config objects

Add or update an each of these object types on a Firewall/Panorama (or device group):

address object - apply_address_object
address group - apply_address_group
service object - apply_service_object
service group - apply_service_group
security rule - apply_security_rule

The above objects may also be added and updated in bulk:

bulk_apply_address_object
bulk_apply_address_group
bulk_apply_service_object
bulk_apply_service_group
bulk_apply_security_rule

You may also retrieve these objects in a json serialized string (or as a raw python pandevice object)

get_address_obejcts
get_address_groups
get_service_objects
get_service_groups
get_security_rules

IP/Tag registration

You can dynamically register IP Addresses/tags to the device using the User-ID API.

register_ip and bulk_register_ip
unregister_ip and bulk_unregister_ip

Commits

Issue commits to Firewalls and Panorama (including device groups)

commit

Example Rule

The pack also includes an example rule which can be used to receive webhooks from a Palo Alto Networks Device that contain bad actors and use the pack actions to block those actors.

The rule name is block_bad_actors located in the rules/ directory. The rule receives webhooks from the firewall and registers the IP in the payload with a defined tag to the firewall for inclusion in a Dynamic Address Group to block traffic from the IP.

Configure a http webhook (http server profile) on the firewall/Panorama following the PAN-OS 8.0 documentation

Name of the StackStorm server has to match the certificate imported into the firewall/Panorama for connection. The firewall/Panorama will also need a StackStorm API key. To generate a new key run this command:

st2 apikey create -k -m '{"used_by": "PAN"}'

For more information, see this blog post.

stackstorm-paloalto's People

Contributors

Stargazers

Watchers

Forkers

lampwins cognifloyd namachieli rliessum

stackstorm-paloalto's Issues

Merging of parallel Palo Alto pack based on pan-python

Summary

Due to limitations with pandevice (the underlying package for the current pack) my team and I created a pack that uses pan-python (what pandevice is built on top of) for interaction with the PAN XApi, and other related APIs supported, as well as NetMiko for actions explicitly not supported by the XApi (Request and Debug commands that are reasonably safe for automation)

Our intent is to share this pack with the community because it opens up a huge range of capabilities not present in the pandevice library that we believe could help many organizations.

https://github.com/namachieli/exchange-incubator/tree/master/paloalto

Design Summary

The design of the pack is pretty strait forward:

YAML only action files that reference a shared set of python logic (4 API specific .py, a Netmiko .py, and a lib/base.py)
- XAPI
- LicAPI
- WFAPI
- AFAPI
- NetMiko for raw CLI commands
Use existing methods in pan-python where feasible
Leverage Immutable fields and Jinja Templating to simplify a complex usage of a method (creating an object in panorama, for example)
A Pack config structure that supports the usage of a customized list of 'connections' that can be referenced by name, in whole or partially, for connections to any Firewall devices or panoramas. (Similar to the existing pack's config logic)

A large majority of the POST/PUT actions around the XAPI involve very customized configurations (Object Names, Templates, Groups, etc). There are basically two types of actions; Native method based actions (xapi.op, xapi.set, etc) and something we coined as 'Shortcut Actions'. Shortcut actions leverage the same underlying python actions files, with immutable primary inputs, and secondary inputs prefixed with a single underscore, that are used in a Jinja template fashion for the immutable inputs, to simplify common tasks that require a well known structure with "name of your thing here" type replacements. Example. This means that adding a "shortcut action" is as easy as providing the relevant structure, and replacement inputs. The pack logic does all the rest.

We chose to have separate actions for each API type (and Netmiko) because each one leverages shared logic in potentially slightly different ways. We felt keeping them separate at this layer simplified future changes to existing API endpoints, methods, or in the event of an addition/removal by Palo Alto of an API/Method.

Approach for moving forward

A while back I requested some feedback in the #community channel on stackstorm_community in slack, and presented a few options of how to move forward:

Leave the existing pack as is, and maintain the new pack in parallel for a time, and later deprecate the old one
Do a hard 'replace' of the current pack with the new one, tag as a larger version change, Big warnings about no backwards compatibility.
Merge the logic of the packs into one pack with parallel actions (some overlaps), maintain both for a while, add warnings to older actions of future removal, etc

Possibly others?

The loose consensus was split between 'hard replace' and 'graceful merge'.

I would love to hear thoughts an opinions on this. I assume this is a 'how' question, not an 'if' question.

My team and I are willing to do the work to get us to the end state, and would only request oversight, peer review, and minor assistance as needed.

Extend and cleanup pack

I think this is great! I would like to extend this pack a bit in a couple of ways. I would like to support registering multiple IPs/Tags at once using bulk operations. I would like to use the pandevice library to make the actions a little easier to build out and maintain as apposed to dealing with xapi directly. I would like to restructure the pack config for firewall authentication based on the vSphere pack config model. Finally I noticed the rules in this pack have some hard coded addresses that we should take a look at.

Do you have any thoughts on this @irom77 and @LindsayHill