MineMeld to Implement NAC Application (DAGPusher)

[xhoms]

Introduction

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.

• UPDATE messages will be converted into "register" API calls
• WITHDRAW messages will be converted into "unregister" API calls

This article explores all the rich features of the DAGPusher MineMeld node in the contexts of a NAC application.

Overview of the DAGPusher node

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:

• username: the basis of the PANOS User-ID technology. IP addresses are mapped with a user-name ID and policies can be constructed based on this extended information instead of based on the value of the IP's themselves.
• tags: multiple tags can be attached to an IP. Then groups of IP's can be created by collecting all IP addresses having a common set of tags. These groups can be used in the policies. This is, for example, the basis for the VM Information Sources PANOS feature.

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:

• non-IPv4 indicators (that includes IPv6, URL, Domain, etc.)
• IPv4 indicators with the format <ip-address>/<masklen> where masklen is not 32
• IPv4 indicators with the format <ip-address-begin>-<ip-address-end> (ranges) where begin and end are not equal.

The configuration attributes for the DAGPusher node are:

• tag_prefix (string): a char sequence that will be used as prefix for any tag value pushed to the devices (defaults to 'mmld_')
• tag_watermark (string): the value of a tag that will be attached to any indicator pushed by the DAGPusher node. This way, a NGFW administrator can backtrace any given tagged IP back to MineMeld as responsible for it (defaults to 'pushed')
• persistent_registered_ips (boolean): true if the tags pushed by the node should survive a device reboot (defaults to 'true')
  
• tag_attributes (list of strings): The collection of indicator attributes that should be extracted and converted into tags. The resulting tag value will be calculated as <tag_prefix>+"_"+<indicator attribute name>+"_"+<indicator attribute value> (defaults to ['confidence', 'direction'])

Creating a poor man's NAC application

Next sections of this article will provide a step by step guide to create a datacenter NAC application with the following specifications:

• The enforcer of the policy should be a NGFW placed at the Internet Gateway
• Only traffic sourced by windows servers should be able to consume the application "ms-update"
• Only traffic sourced by linux servers should be able to consume the applications "yum" and "apt-get"
• A procedure must be provided to allow temporary (4 hours) full access to Internet to a third party device identified by its IP.

Step 1: Creating a new DAGPusher prototype

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:

• Attaches an operating system TAG to the registered IP address (that will be used to discriminate between Windows and Linux)
• Attaches an "temporary authorization" TAG to these IP addresses that should be allowed to traverse the NGFW

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.

Step 2: Setting up the graph

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:

• A DAGPusher node based on the prototype we just created and
• A LocalDB miner that we'll use to host the indicators (our NAC database)

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.

Step 3: Adding our PAN-OS device as a "handled device" to the DAGPusher node

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.

Operating the poor man's NAC application

We're going to perform the following three tasks:

• Add a windows server in the NAC's database
• Add a linux server in the NAC's database
• Add a temporary entry (4 hours) in the NAC database corresponding to a visitor's device.

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.

Configuring the PAN-OS device to use the pushed objects

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:

• Windows Servers (contain the tag "mm_os_windows")
• Linux Servers (contain the tag "mm_os_linux") and
• Guest Servers (contain the tag "mm_authorized_yes")

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.

Annex 1: Using PAN-OS API Key instead of user and password

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:

• assign null to both the api_username and api_password attributes
• attach a new attribute called api_key with the corresponding value for our device

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.

Annex 2: Bulk upload of indicators

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)

[ksteves1]

Update: DagPusher node now handles IPv6 indicators.