The most common way to share indicators with a PAN-OS device is by using its External Dynamic List feature. MineMeld hosts a WEB server that can be used to generate feeds for URL, Domain and IP indicators to be consumed by a NGFW. One of the drawbacks of this approach is it being synchronous. The PANOS device polls at regular intervals the feed. This means that a recently received indicator might not be available for enforcement in the NGFW until the next poll is executed (typically 60 minutes)
For host-based (/32) IPv4 indicators, MineMeld features an async node that leverages the Dynamic Address Group PANOS feature. This node will "push" indicator changes to the device as soon as they reach the output.
This article explores all the rich features of the DAGPusher MineMeld node in the contexts of a NAC application.
The DAGPusher node is, basically, a multi-instance API Client to the User-ID API entry point provided by any PANOS or PANORAMA device. The User-ID API entry point allows an external party (in this case MineMeld) map IP addresses with abstract data, for example:
Each indicator reaching the DAGPusher node is processed, attributes extracted, and a call to the User-ID API is made to "register" or "unregister" these IP's with a collection of tags related to the indicator's attributes.
The DAGPusher node instantiates a new User-ID client for each managed device. This way the indicators can be pushed to many devices at once. The DAGPusher node also supports using PANORAMA as proxy to the devices.
The current version of the DAGPusher node only supports host-based IPv4 indicators. Take in mind that all the following indicators types will be discarded by the node and not pushed down to the PANOS devices:
The configuration attributes for the DAGPusher node are:
Next sections of this article will provide a step by step guide to create a datacenter NAC application with the following specifications:
First step is to create a MineMeld node prototype based on the DAGPusher class that suits our needs. Basically we need to configure the DAGPusger class in such a way that it:
To achieve this we will create a new prototype using the standard lib DAGPusher one as base and defining the tag_attributes configuration element.
In the new node prototype window we specify values for tag_prefix, tag_watermark and tag_attributes to look like in the following screenshot.
With this prototype in the library we're ready to setup a couple of nodes we'll use to achieve our poor man's NAC application:
Let's start by cloning the existing stdlib.localDB prototype into a miner node.
Now, let's clone the poor-man-dagpusher prototype we created before as an output node and connect it directly to the poor-man-store miner node.
At this point we shoud have a basic graph connecting a miner with an outputter. Let's commit this graph.
The DAGPusher works on a database of "handled devices". In other words: the set of PANOS devices that should be notified each time a new IPv4 reaches the node (either for registering-update or unregistering-whitdraw)
The MineMeld WEBUI provides a tab in the DAGPusher node to allow the administrator maintain the list of handled devices. Let's navigate to the node's WEBUI component and add a PANOS device.
This change does not requiere any configuration commit. The DAGPusher node will, automatically, instantiate a new API Client object with the provided credentials and network information. We're ready to operate our brand new poor man's NAC application.
We're going to perform the following three tasks:
To perform all these tasks we'll use the indicator tab provided by the WEBUI to the nodes based on the localDB class. Just navigate to the node and open the indicators tab.
The first entry we'll add is the one corresponding to the windows server. As it is a "permanent" entry, we'll chose the "Disable Expiration" option in the TTL field. Attach an "os" attribute to the indicator defining this entry as a windows server (remember that we created a DAGPusher prototype that will extract the "os" and "authorized" attributes from the indicators).
Addig an indicator to a node based on the localDB class does not requiere a commit. That means that, if everything is OK in our setup, we should be able to see the registered IP in out PANOS device.
Let's repeat the task but with a Linux server this time.
Our last step is to create a timed entry (4 hours) for a visitor. This time, instead of chosing the "Disable expiration" option, we'll define a TTL of 14400 (4 hours = 14400 seconds). And we'll attach an "authorized" attribute this time.
The localDB miner will take care of the expiration. After 14400 seconds, the visitor's entry will be aged out, a WHITDRAW message generated down the graph and an "unregister" message will be send by the DAGPusher node to the handled device.
For the pushed objects to be usable into policies, a Dynamic Address Group (DAG) must be created. For this excercise we'll create three DAG's:
The Dynamic Address Groups are created the same way Regular Address Groups are created. Just that they're of type "dynamic" and based on a tag query ("and", "or" accepted).
Repeat for Linux_Servers and Guest_Servers.
Now let's use these DAGs into our poor man's NAC security policies.
After committing the configuration changes you'll be able to confirm the DAG membership using the NGFW's WEBUI.
If you followed the steps then you'll remember that, for the Guest Server entry in the LocalDB miner, we attached the attribute "os" with a value "windows" alongside the attribute "authorized". This means that the Guest Server is also registered as a Windows Server so it will be able to receive updates during the 4 hours it was granted access to the network.
The DAGPusher node supports using the PANOS API Key. But, unfortunatelly, the current WEB UI component does not expose it. This means we need to hack the configuration file of the DAGPusher node.
First of all let's create a handled device in our DAGPusher node with a fake username and password.
The device list for the node is maintained in a YAML file inside the MineMeld's configuration folder (defaults to /opt/minemeld/local/config). The filename should have the value <nodename>_device_list.yml. In this example it will be "dagPusherWithAPIKey_device_list.yml".
We just have to edit the file to:
The node should detect the file modification and reload the device list. But, if you want to be sure it is readed, just restart the engine.
You may need to upload a bulk list of entries to the LocalDB miner (the NAC database in our example). The LocalDB miner features an API that is explained in the annex 2 of the article Using MineMeld as an Incident Response Platform.
You can leverage the API or use the script created by @lmori that implements the client side of the LocalDB API and that can use text formated input file as source.
(Script available at https://gist.github.com/jtschichold/95f3906566b18b50cf2e3e1a44f1e785)
