Securing Remote Access in Palo Alto Networks E-Book

Tom Piens

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 251

Veröffentlichungsjahr: 2021

Beschreibung

This book builds on the content found in Mastering Palo Alto Networks, focusing on the different methods of establishing remote connectivity, automating log actions, and protecting against phishing attacks through user credential detection.
Complete with step-by-step instructions, practical examples, and troubleshooting tips, you will gain a solid understanding of how to configure and deploy Palo Alto Networks remote access products. As you advance, you will learn how to design, deploy, and troubleshoot large-scale end-to-end user VPNs. Later, you will explore new features and discover how to incorporate them into your environment.
By the end of this Palo Alto Networks book, you will have mastered the skills needed to design and configure SASE-compliant remote connectivity and prevent credential theft with credential detection.

Leseprobe

Securing Remote Access in Palo Alto Networks

Practical techniques to enable and protect remote users, improve your security posture, and troubleshoot next-generation firewalls

Tom Piens

BIRMINGHAM—MUMBAI

Securing Remote Access in Palo Alto Networks

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavoured to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Wilson D'souza

Publishing Product Manager: Vijin Boricha

Senior Editor: Shazeen Iqbal

Content Development Editor: Rafiaa Khan

Technical Editor: Shruthi Shetty

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Jyoti Chauhan

First published: June 2021

Production reference: 1030621

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-744-6

www.packt.com

I want to dedicate this book to my son, godson, and newborn nephew: life starts at 40, so don't grow up too fast.

Contributors

About the author

Tom Piens, PCNSE, CISSP, and founder of PANgurus, has over 10 years of experience working with Palo Alto Networks customers. Tom has been on the forefront of engaging with customers, responding to questions, and analysing unique needs to apply the best possible solutions or workarounds. He has authored a great many articles on the Palo Alto Networks knowledge base and discussion forum solutions, and a book, Mastering Palo Alto Networks. Also known as reaper on the PANgurus and LIVEcommunity forums, and PANWreaper on Twitter, Tom has been recognized by Palo Alto Networks user groups and community members, and by countless thankful customers.

I want to extend a special thanks to Nick "Ndx" for helping to review and fact-check this book, Aref Alsouqi for being a technical sounding board, and Rutger Truyers for his much-appreciated insights.

In these trying times I have very much enjoyed their friendship above all.

About the reviewer

Kris Znamierowski is an IT professional with over 18 years of experience in securing and supporting multiple operating systems, including PAN-OS, Microsoft, Linux, and BSD UNIX. An OpenBSD user since forever. He holds many credentials from industry leaders.

Table of Contents

Preface

Section 1: Leveraging the Cloud and Enabling Remote Access

Chapter 1: Centralizing Logs

Technical requirements

Understanding log forwarding profiles and best practices

Allocating log storage

Adding disk space to a VM firewall

Learning about Panorama and log collectors

Forwarding logs to syslog, SMTP, and other options

SNMP trap server profile

Syslog server profile

Email server profile

HTTP server profile

Netflow Profile

Configuring system log forwarding on the firewall

Exploring log forwarding profiles

Dynamic tagging

Assigning log forwarding actions

Troubleshooting logs and log forwarding

Debugging log-receiver

Reading system resources

Using tcpdump

Troubleshooting forwarding to a log collector

Summary

Chapter 2: Configuring Advanced GlobalProtect Features

Technical requirements

Learning about advanced configuration features

Integrating SAML into authentication methods

Setting up a VPN connection before the user has logged on

Leveraging quarantine to isolate agents

Practical troubleshooting for GlobalProtect issues

Summary

Chapter 3: Setting up Site-to-Site VPNs and Large-Scale VPNs

Technical requirements

Configuring a site-to-site VPN connection

Static site-to-site tunnels

Dynamic site-to-site tunnels

Setting up the LSVPN

Summary

Chapter 4: Configuring Prisma Access

Technical requirements

Configuring Prisma Access

Configuring the service infrastructure

Configuring the service connection

Configuring directory sync

Configuring mobile users

Configuring remote networks

Configuring the remote firewalls

Configuring Cortex Data Lake

Summary

Section 2: Tools, Troubleshooting, and Best Practices

Chapter 5: Enabling Features to Improve Your Security Posture

Technical requirements

Hardening the management interface

FIPS-CC mode

Replacing the default certificates

Setting minimum password complexity

Configuring administrator roles

Restricting access to the management interface

Setting the master key

EDLs

MineMeld

Summary

Chapter 6: Anti-Phishing with User Credential Detection

Technical requirements

Preparing the firewall for credential detection

Configuring SSL/TLS decryption

Enabling IP user mapping

Using IP user mapping for credential detection

Enabling group mapping

Troubleshooting user-ID

Using group mapping for credential detection

Using domain credential filter

Troubleshoot domain credential filter

Summary

Chapter 7: Practical Troubleshooting and Best Practices Tools

Technical requirements

Troubleshooting User-ID

Users are not being mapped

Users are mapped briefly

Inconsistent domain in username

Command-line interface (CLI) cheat sheet

Troubleshooting NAT

Loss of connectivity – proxy-ARP misconfiguration

Troubleshooting destination NAT issues

Troubleshooting source NAT

BPA tool

Summary

Why subscribe?

Other Books You May Enjoy

Preface

In this book, we will review remote connectivity in depth and learn about the different ways to deploy GlobalProtect and site-to-site VPN. Besides traditional methods, we will also learn about Large Scale VPN and Prisma Access SASE. Other topics that will be covered include anti-phishing and credential detection, hardening the management interface, and getting the most out of your logs.

Who this book is for

This book is for anyone who wants to learn more about remote access for users and remote locations leveraging GlobalProtect, Prisma Access, and Large Scale VPN. You will learn about the added value that log forwarding can bring and how to improve the security posture of your management interface. Anti-phishing and credential detection are covered in depth to help those who want to protect their organization from credential theft and data leaks.

What this book covers

Chapter 1, Centralizing logs, is all about how to get more out of logging.

Chapter 2, Configuring Advanced GlobalProtect Features, looks at best practices, troubleshooting, and advanced configuration.

Chapter 3, Setting up site-to-site VPNs and Large Scale VPNs, covers the ins and outs of traditional IPSec and GlobalProtect as a LargeScale VPN solution.

Chapter 4, Configuring Prisma Access, explores the complete configuration of a Prisma Access deployment.

Chapter 5, Enabling features to improve your security posture, talks about configuring advanced security measures to reach compliance.

Chapter 6, Anti Phishing with User Credential Detection, gets into how to prevent the leaking of user credentials due to phishing or misuse.

Chapter 7, Practical troubleshooting and Best Practice Tools, explains troubleshooting for User-ID and NAT and some best practices.

To get the most out of this book

To get the most out of this book, it is highly recommended that you have a small lab at your disposal with two firewalls, Windows 10, and Windows Server 2016. Access to a Panorama management server would be helpful to follow the covered material but not required. Familiarity with IPSec, syslog, and accessing systems through CLI is recommended, as well as working experience with PAN-OS. Basic knowledge of Palo Alto Networks, network protocols, and network design would be helpful, so reading Mastering Palo Alto Networks first is recommended.

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Code in Action

Code in Action videos for this book can be viewed at https://bit.ly/3votQBS.

Download the colour images

We also provide a PDF file that has colour images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/9781801077446_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system."

A block of code is set as follows:

html, body, #map {

height: 100%;

margin: 0;

padding: 0

}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

[default]

exten => s,1,Dial(Zap/1|30)

exten => s,2,Voicemail(u100)

exten => s,102,Voicemail(b100)

exten => i,1,Voicemail(s0)

Any command-line input or output is written as follows:

$ mkdir css

$ cd css

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Section 1: Leveraging the Cloud and Enabling Remote Access

In this section, we will configure and troubleshoot remote connectivity through direct access and the cloud. 

The following chapters will be covered in this section:

Chapter 1, Centralizing logsChapter 2, Configuring Advanced GlobalProtect FeaturesChapter 3, Setting up site-to-site VPNs and Large Scale VPNsChapter 4, Configuring Prisma Access

Chapter 1: Centralizing Logs

In this chapter, we will take a closer look at how to forward firewall logs to an external system and discuss some of the benefits. Logs can be forwarded to an external Security Incident and Event Management System (SIEM) and can be used to create a range of alerts whenever an interesting event occurs. You will learn how to set up the configuration and apply best practices when dealing with log forwarding. We will then review how logs can be forwarded to Panorama and log collectors, as well as how to leverage alternative log protocols such as syslog. We will also cover how to troubleshoot forwarding issues and how to apply filters to forwarding profiles to specify which log events are forwarded.

In this chapter, we are going to cover the following main topics:

Understanding log forwarding profiles and best practicesLearning about Panorama and log collectorsForwarding logs to syslog, SMTP, and other optionsExploring log forwarding profilesTroubleshooting logs and log forwarding

Technical requirements

For this chapter, you will need to have a Palo Alto Networks firewall set up and connected to a management network. It will be helpful if you are able to spin up a syslog server and email relay to reproduce the log forwarding settings we are about to configure. If you can set up or repurpose a Panorama instance, you will be able to follow along with some of the threat correlation examples.

Check out the following link to see the Code in Action video:https://bit.ly/3oTeYZW

Understanding log forwarding profiles and best practices

In this section, you will learn the steps required to ensure logs are forwarded to an external system. You will also learn how to apply filters so that only specific types of events are forwarded, as well as how to ensure Log forwarding configuration is applied automatically. First, we will look at where and how logs are stored.

Allocating log storage

All NGFW firewalls and Panorama Systems are built from a Linux operating system running proprietary PAN-OS on top. Log files for the system daemons reside in the root partition. They are only accessible via the command line and are included in a Tech Support file for troubleshooting. All logs related to PAN-OS live in the /opt/panlogs partition. Use the following command to review filesystem usage statistics:

reaper@PA-VM> show system disk-space

Filesystem      Size  Used Avail Use% Mounted on

/dev/root       7.0G  4.2G  2.5G  64% /

none            3.5G   92K  3.5G   1% /dev

/dev/sda5        16G  2.9G   13G  20% /opt/pancfg

/dev/sda6       8.0G  1.4G  6.3G  18% /opt/panrepo

tmpfs           2.8G  2.4G  420M  86% /dev/shm

cgroup_root     3.5G     0  3.5G   0% /cgroup

/dev/sda8        21G  598M   20G   3% /opt/panlogs

In this example, /dev/sda8 is a partition on the local disk that's used to store logs. Some of the larger hardware platforms may have a secondary hard disk for logging, and on VM firewalls, an additional disk can be installed post-deployment.

The available disk space needs to be shared by all the different log databases, so it is worth reviewing how much space is allocated to each database and tweaking the quotas and expiration periods to optimize them for retention. You can review the current quotas with the following command:

reaper@PA-VM> show system logdb-quota

Quotas:

      system: 4.00%,  0.629 GB Expiration-period: 0 days

      config: 4.00%,  0.629 GB Expiration-period: 0 days

       alarm: 3.00%,  0.472 GB Expiration-period: 0 days

     traffic: 29.00%, 4.559 GB Expiration-period: 0 days

      threat: 15.00%, 2.358 GB Expiration-period: 0 days

...snipped for brevity...

Disk usage:

traffic: Logs and Indexes: 211M Current Retention: 46 days

threat: Logs and Indexes: 24K Current Retention: 0 days

system: Logs and Indexes: 11M Current Retention: 46 days

config: Logs and Indexes: 21M Current Retention: 46 days

...snipped for brevity...

As you can see, the traffic logs are only assigned 29% of the totally available log space on this particular firewall.

These quotas can be adjusted via the web interface by going to Device > Setup > Management > Logging and Reporting Settings, as shown in the following screenshot. The log databases on the left represent logs that are the direct result of sessions or system events taking place; the column on the right contains the summary databases that are used to compile larger datasets containing statistical data that can be used in reporting:

Figure 1.1 – Logging and reporting settings

As hardware platforms are somewhat limited in terms of their capacity for storing logs, the need to export logs for a longer log retention period may arise quite quickly. A production firewall may see up to 40 GB or more of logs being created daily, thus decreasing log retention to less than a day on smaller platforms. Virtual machines, on the other hand, support having an additional disk added to them, which we will review in the next section.

Adding disk space to a VM firewall

Virtual appliances, both firewalls and Panorama, support local storage expansion by having additional virtual disks added to enlarge their log capacity.

Important note

The primary disk that's assigned to a virtual system cannot be enlarged to accommodate more logs. The partitions are predefined and additional disk space will be left unused.

As shown in the following screenshot, an additional disk can be added that's between 60 GB and 2 TB in size to a firewall VM. Panorama VM can support from 1 to 14 2-TB disks, or one single 24-TB disk in Panorama mode. Panorama systems that are deployed in Legacy mode, which means they were installed in an older version and have since been upgraded, can have a single disk added that's up to 8 TB in size:

Figure 1.2 – Adding disks to a VM

Disks need to be thick provisioned, and the controller must be set to SCSI. Make sure that you shut down the system before adding the new disk. During bootup, the disk will be discovered and mounted as the new /opt/panlogs partition.

The next stage is to enable log forwarding to an external system.

Learning about Panorama and log collectors

To enable log forwarding to Panorama, the firewall must be connected to a Panorama server. This can be achieved by adding the Panorama IP via Device > Setup > Panorama Settings, as shown in the following screenshot:

Figure 1.3 – Panorama settings on the firewall

Once the firewall has established a connection with Panorama, Panorama sets its external logging destinations to what you specify in the collector group configuration.

As shown in the following screenshot, enabling Enable log redundancy across collectors will ensure each log entry has a copy on a different log collector in the same group. Enabling Forward to all collectors in the preference list will let PA-5200 and PA-7000 devices forward to all collectors in a preference list, managed by Panorama in a round-robin fashion. Otherwise, the default behavior is to send logs to the first available collector in the list:

Figure 1.4 – Collector Group general settings

In the Device Log Forwarding tab, you can select firewall devices and assign a list of collectors that they may send logs to. The first member of a collector group is the primary collector; firewalls will send their logs to this collector for as long as it is available, using the next collector down the list as a fallback collector for redundancy. In the following screenshot, we have two firewalls that have different preferences assigned for the two available collectors. The firewall called PANgurus will send logs to Panorama itself, while the RemoteLAB firewall will send logs to Collector. If one of the log destinations becomes unavailable, the firewalls will fall back to the second collector in the list:

Figure 1.5 – Device log forwarding

In the next section, we will review other useful log forwarding options.

Forwarding logs to syslog, SMTP, and other options

In addition to forwarding logs to Panorama, other server profiles can be set up so that logs can be sent to a third-party log management or SIEM via Simple Network Management Protocol (SNMP). All profiles can be created in the Device > Server Profiles menu.

SNMP trap server profile

As shown in the following screenshot, there are two variations of the SNMP trap profile. SNMP protocol version V2c is very simple and requires only a server IP or FQDN, as well as a community string. This is insecure and should not be deployed in an untrusted network and should only be used if the receiving server is legacy. The V3 protocol version uses both an authentication password and a privacy password. SNMP traps and the privacy password are encrypted using AES 128; the authentication password is sent hashed with SHA1-160. Both passwords need to be between 8 and 256 characters in length. engineID is used as an identification number by the SNMP server and must consist of a hexadecimal format, prefixed by 0x and another 10 to 128 characters. If this is left empty, the firewall will use its serial number as the ID:

Figure 1.6 – SNMP trap profile

Syslog server profile

As you can see in the following screenshot, for syslog, you can select traditional UDP or TCP connections over port 514 or enable ssl encryption via port 6514. These ports can be changed if needed. The format can be changed to either BSD or RFC5424 IETF, and the facility field can be adjusted to accommodate how the receiving server manages incoming messages:

Figure 1.7 – Syslog server settings

An additional feature in the syslog profile is the ability to select the fields to include in forwarded logs for each log database. As shown in the following screenshot, this allows you to choose which fields and in which order they will appear in the forwarded log. This can come in handy if only a limited number of fields are supported, or to weed out unneeded log data. If the syslog server requires some characters to be escaped, you can list them here and define the escape character.

For example, a semicolon (;) may need to be escaped by encapsulating it with single quotes (') for compatibility reasons. Enable escaping and add the required characters, as shown here:

Figure 1.8 – Syslog custom log format

By default, the forwarded syslog message will include the source firewall's FQDN hostname. If the syslog server prefers an IP address or simple hostname, this default value can be changed in Device > Setup > Logging and Reporting Settings > Log Export and Reporting > Syslog HOSTNAME Format.

Email server profile

The Simple Mail Transfer Protocol (SMTP) profile can be configured with a friendly Email Display Name (this display name is injected in the From field in smtp DATA) so that the recipient can easily identify the firewall as the sender, the source email address (so that the relay will accept the sender), and the recipient. Only one email can be added in the To field, so an additional sender field is available to add a second email address. As shown in the following screenshot, since PAN-OS 10.0, the connection can be set to use SMTP over TLS 1.1 or 1.2 for added security. The authentication method can be set to Auto, Login, or Plain: Login with a base64 encoded username and password but send them separately or Plain with a Base64 encoded username and password but send them together. Auto will let the client and server sort out the preferred method of sending the username and password.

Logs can also be customized so that only the relevant fields are forwarded via email:

Figure 1.9 – SMTP profile

Important consideration

Emails can be a great notification method for critical events as most people will have immediate access to incoming emails, but over-abundant use of email notifications may lead to alert fatigue and important messages may go ignored or filtered. Use email notifications sparingly and only for the most critical notifications.

HTTP server profile

The HTTP profile can be used in two separate ways; first, you can add server details, choose a HTTP or HTTPS protocol, set the destination port and TLS version. Second, a certificate profile can be added, and a username and password can also be added.

This profile can be used to simply forward logs via HTTP or the payload can be edited to integrate with third-party API- or HTTP-based services. Several pre-defined payloads are available, so, as illustrated in the following screenshot, ServiceNow tickets can be created as the result of a log file being generated:

Figure 1.10 – Predefined formatting

As shown in the following screenshot, you can also enable Tag Registration. This changes the profile from regular log forwarding to a dynamic tagging role. This type of profile can be used to send dynamic tag registration or deregistration to a remote User-ID Agent (both a firewall and server installed agent) that has XML enabled. See the Log forwarding profile section later in this chapter for more details:

Figure 1.11 – HTTP server profile

For a regular HTTP Server Profile, the GET, PUT, POST, and DELETE methods are available, while for Tag Registration, only GET is supported as a HTTP method currently.

Netflow Profile

The Netflow Profile is the only profile that is assigned directly to an interface, as shown in the following screenshot. Unlike other log forwarding server profiles, no filter can be added to selectively forward certain logs; instead, all session information on an interface is directly streamed to the Netflow server:

Figure 1.12 – Adding a Netflow profile to an interface

Now that we have reviewed the available log forwarding profiles, we'll learn how to use them to forward logs.

Configuring system log forwarding on the firewall

Logs on the firewall fall roughly into two main categories: system logs and session-based logs. Each is made up of several more specific logs. Log forwarding must be configured for each log type individually. The system logs can be configured via Device > Log Settings. As shown in the following screenshot, the available logs are System, Configuration, User-ID, HIP Match, GlobalProtect, and IP Tag:

Figure 1.13 – System log forwarding configuration

Each log type can have multiple profiles associated with it, thus allowing filters and filter-specific actions to be applied. All the profiles are applied, so if a profile exists that sends all the logs of a certain type to Panorama, for example, a second profile for the same log type with a filter does not need to have Panorama checked.

In the preceding screenshot, you can see that we have already set up log forwarding for System log, Configuration logs, and User-ID logs to be sent to Panorama. Additional log forwarding Server Profiles can be added in the same profile, or in different profiles with different filters assigned. The following screenshot shows how to add an additional profile with a Filter set to critical events and one or more log forwarding profiles.

When this profile is added to the system logs, both profiles will be applied at the same time for each log. Log forwarding actions will be applied, depending on the filters that have been set in the profiles: the all system logs profile will always forward all logs to Panorama, while critical system events will match both profiles. The syslog server listed in the second profile will also receive the log:

Figure 1.14 – Adding additional server profiles to the System log forwarding profile

To determine a Filter, if any, you can click the little arrow to the right of the Filter field. Severity filters are preloaded and can simply be clicked. Alternatively, you can open the filter builder to review all the available attributes and values that can be added to the filter:

Figure 1.15 – Filter builder

Now that we've seen how to forward system logs, we will take a closer look at how to forward session-based logs.

Exploring log forwarding profiles

Security rules determine how the firewall processes sessions traversing its interfaces. Not only are ports and applications determined by the security rules, but also which security profiles and even which log forwarding profile is applied. This means that you need to attach a Log Forwarding profile to every security rule so that matching sessions are logged to an external system. First, you will need to create a Log Forwarding profile.

Important Note

Creating a Log Forwarding profile named default will automatically add it to every new security rule that is created afterward.

In Objects > Log Forwarding, create a new profile and name it default. This will ensure that this profile will be added to each new security policy moving forward. Additional profiles can be added as needed. Only one Log Forwarding profile can be added per security rule.

The default profile should look somewhat like the profile depicted in the following screenshot:

Figure 1.16 – Default log forwarding profile

A log forwarding profile consists of a set of match lists. Each match list contains the log type that needs to be forwarded, the destination server profiles the logs will be sent to, and optional filters to limit which logs will be forwarded. A typical log forwarding profile will contain all the common logs, such as traffic, threat, and url filtering logs. More specific Match lists can be added and tailored to take a specific action when an event is registered. For example, the following Match List will send out an email and forward the log to a syslog server when a critical threat is detected. This can be leveraged to alert the IT security team of an event and forward the information to an Security Operations Centre (SOC):

Figure 1.17 – Email and syslog log forwarding

Built-In Actions take log forwarding one step further by dynamically taking action on log events that can help protect critical systems from attacks, as we will see in the next section.

Dynamic tagging

The Built-In Actions section of Match List can be used to act dynamically when an event is seen that matches the filter.

The Quarantine checkbox can be used to add a source host to the device's quarantine list (the list can be found via Device > Device Quarantine). These devices can then be matched against the Quarantine attribute in a security policy, as shown in the following screenshot. The default behavior is to block the session that triggered a signature without interfering with other sessions initiated by a potentially malicious client. The advantage of adding this capability to Quarantine is that hosts are placed in a controlled group that can be cordoned off from sensitive resources, and even prevented from establishing a GlobalConnect VPN connection, until an unregister action is triggered or manually removed by an administrator:

Figure 1.18 – Quarantine match on a security policy rule

As shown in the following screenshot, additional actions can be taken that will add a tag (these can be created in Objects > Tags) to a Target:

Destination AddressSource AddressUser

X-Forwarded-For-Address: The address contained in the x-forwarded for header added by a proxy server, indicating the original client IP:

Figure 1.19 – Dynamic tag action

Tags can be added or removed by our Action. The tag can currently be registered to three different systems:

Local User-ID: This is the local firewall.Panorama User-ID: This is a Panorama management server that can redistribute the tags via User-ID redistribution.Remote User-ID: This is the User-ID agent that's been installed on a Windows server.

For Panorama and the Remote User-ID, an XML API needs to be enabled in the configuration of the User-ID agents. A timeout can be added so that a tag is removed after a certain amount of time.

As shown in the following screenshot, once tagging has been set up, a Dynamic User Group can be created for tagged users, or an Address Group can be used for tagged addresses. These groups can then be added to security rules so that they can be granted or blocked access to resources:

Figure 1.20 – Dynamic user group and address group

Once the dynamic tags are active and IPs start getting tagged, you can follow their progress in the Monitor > IP-Tag log, as you can see in the following screenshot:

Figure 1.21 – IP-Tag logs

The IP addresses or users that were tagged can be viewed by clicking the more…