Introduction to Logging, Monitoring & Reporting

Welcome to Chapter 12! So far, we’ve built a solid foundation, understanding how Palo Alto Networks Next-Generation Firewalls (NGFWs) classify traffic, enforce policies, and secure our networks. But what happens after a policy permits or denies traffic? How do we know if our security policies are effective, if threats are being blocked, or if users are accessing appropriate applications? This is where logging, monitoring, and reporting become absolutely essential.

In this chapter, we’ll dive deep into the “eyes and ears” of your Palo Alto firewall. You’ll learn how to configure the firewall to record vital information, effectively monitor real-time and historical data, and generate meaningful reports that provide insights into network activity and security posture. This knowledge isn’t just about troubleshooting; it’s about proactive security, compliance, and continuous improvement of your network defenses.

By the end of this chapter, you’ll be able to confidently navigate the firewall’s logging infrastructure, configure external log forwarding, and leverage the built-in monitoring and reporting tools to keep a vigilant watch over your network. Get ready to transform raw data into actionable intelligence!

Core Concepts: The Pillars of Visibility

Visibility is paramount in network security. Without understanding what’s happening on your network, you’re essentially flying blind. Palo Alto Networks firewalls excel at providing deep visibility, and it all starts with robust logging.

Understanding PAN-OS Log Types

Palo Alto Networks firewalls generate various types of logs, each providing specific insights into different aspects of network activity and firewall operations. It’s crucial to understand what each log type captures:

  1. Traffic Logs: These are the most common logs, detailing every session that traverses the firewall. They record source/destination IP, port, application, user, ingress/egress zone, policy name, action (allow/deny), and bytes transferred.
    • Why it matters: Essential for understanding network flow, user behavior, and policy enforcement.
  2. Threat Logs: Whenever the firewall detects and blocks a threat (e.g., virus, spyware, vulnerability exploit, DoS attack), a threat log is generated.
    • Why it matters: Direct evidence of the firewall’s security efficacy and identification of active threats.
  3. URL Filtering Logs: Records when users attempt to access URLs categorized by the firewall’s URL filtering profiles, along with the action taken (allow, block, alert, override).
    • Why it matters: Provides insights into web browsing habits, policy compliance, and potential risky website access.
  4. Data Filtering Logs: Generated when sensitive data (as defined by Data Filtering profiles) attempts to traverse the firewall.
    • Why it matters: Critical for Data Loss Prevention (DLP) and compliance.
  5. WildFire Submissions Logs: Records files submitted to the WildFire cloud for analysis and the verdict received (benign, malware, grayware).
    • Why it matters: Shows the firewall’s advanced threat prevention in action and helps identify zero-day threats.
  6. System Logs: Capture events related to the firewall’s own operation, such as interface status changes, daemon restarts, high resource utilization, and HA (High Availability) events.
    • Why it matters: Vital for monitoring firewall health, performance, and troubleshooting operational issues.
  7. Configuration Logs: Records every configuration change made on the firewall, including who made it, when, and from where.
    • Why it matters: Essential for auditing, compliance, and quickly identifying recent changes that might have introduced issues.
  8. User-ID Logs: Tracks user login and logout events, mapping IP addresses to specific usernames.
    • Why it matters: Enables user-based policy enforcement and provides user context in all other log types.
  9. HIP Match Logs: Generated when a Host Information Profile (HIP) check is performed, indicating whether an endpoint meets specific security posture requirements.
    • Why it matters: Used in GlobalProtect VPN deployments to enforce access based on endpoint health.
  10. Decryption Logs: Records events related to SSL/SSH decryption, such as successful decryption, decryption failures, or traffic not decrypted due to policy or errors.
    • Why it matters: Helps monitor the effectiveness and troubleshoot issues with decryption policies.

Centralized Logging: The Power of Panorama

While each firewall stores its own logs locally, for larger deployments with multiple firewalls, managing logs individually becomes impractical. This is where Panorama comes in. Panorama is Palo Alto Networks’ centralized management platform, and one of its most powerful features is centralized log collection.

When firewalls forward logs to Panorama, you gain a single pane of glass to:

  • View logs from all managed firewalls.
  • Run reports across your entire security estate.
  • Perform correlated analysis for faster threat detection.
  • Ensure consistent log retention.

Per official Palo Alto Networks best practices, for any deployment with more than a handful of firewalls, Panorama is highly recommended for centralized logging and management.

Log Forwarding Destinations

Beyond local storage and Panorama, you can configure your firewall to forward logs to external systems for long-term storage, analysis, and Security Information and Event Management (SIEM) integration. Common destinations include:

  • Syslog Servers: The most common method for forwarding logs to SIEMs (e.g., Splunk, QRadar, ELK Stack). Logs are sent in a standardized format (UDP 514 or TCP 6514 for secure syslog).
  • SNMP Traps: Used primarily for system alerts and status changes, often integrated with network monitoring tools.
  • Email: Can be configured to send specific alerts (e.g., critical threat detections) to security teams.
  • HTTP: Less common for general log forwarding, but can be used for specific integrations.

Monitoring Tools on PAN-OS

Palo Alto Networks firewalls offer powerful built-in tools for monitoring and analyzing logs directly from the device GUI.

Application Command Center (ACC)

The ACC provides a high-level, interactive dashboard of network activity. It uses the collected log data to present graphical summaries of applications, users, threats, URL categories, and network activity. It’s excellent for quickly identifying trends, top talkers, and potential anomalies.

Monitor Tab

This is your primary hub for detailed log analysis. The Monitor tab provides granular views of all log types, allowing you to filter, search, and export log entries. You can drill down into individual sessions, view threat details, and understand the context of security events.

Reporting for Insight and Compliance

Reports transform raw log data into digestible, actionable intelligence. They are crucial for:

  • Security Posture Assessment: Understanding what threats are most prevalent, which applications are being used, and where vulnerabilities might exist.
  • Compliance: Generating reports for regulatory audits (e.g., PCI DSS, HIPAA) to demonstrate adherence to security policies.
  • Trend Analysis: Identifying long-term patterns in network traffic, application usage, and threat landscape.
  • Capacity Planning: Understanding bandwidth usage and resource consumption.

PAN-OS allows you to generate pre-defined reports, customize reports based on specific criteria, and schedule them for regular delivery.

Step-by-Step Implementation: Getting Hands-On

Let’s configure some basic logging and monitoring features on our Palo Alto firewall. For these steps, we’ll assume you’re running PAN-OS 11.1.x, the latest stable release as of December 2025.

Step 1: Configuring a Syslog Server Profile

First, we need to tell the firewall where to send logs if we want to forward them externally. We’ll create a Syslog Server Profile.

  1. Navigate to Device > Server Profiles > Syslog.
  2. Click Add to create a new profile.
  3. Profile Name: Enter MySyslogServer (or a descriptive name for your SIEM).
  4. Syslog Server: Click Add in the “Servers” section.
    • Name: SIEM-Primary
    • IP Address: Enter the IP address of your Syslog server (e.g., 192.168.1.100).
    • Port: 514 (standard UDP) or 6514 (standard TCP for secure syslog).
    • Protocol: Select UDP (most common) or SSL/TLS if your SIEM supports secure syslog.
    • Format: BSD (standard) or IETF (RFC 5424). Most SIEMs support BSD.
    • Facility: LOG_USER (default is usually fine, but check your SIEM’s requirements).
  5. Click OK twice to save the profile.
# CLI equivalent (for reference, not for direct execution unless you prefer CLI)
# Configure the Syslog server profile
configure
set device-group shared profiles syslog MySyslogServer servers SIEM-Primary ip-address 192.168.1.100 protocol udp port 514 format bsd facility LOG_USER
commit

Explanation: This configuration creates a named profile (MySyslogServer) that defines the connection details to our external Syslog server. We specify its IP, the protocol (UDP is often used for simplicity, but TCP/SSL is more reliable and secure), port, and the log format.

Step 2: Creating a Custom Log Forwarding Profile

Now that we have a destination, we need to define which logs go there and under what conditions. This is done with a Log Forwarding Profile.

  1. Navigate to Objects > Log Forwarding.
  2. Click Add to create a new profile.
  3. Name: Enter CriticalThreatsToSIEM.
  4. For each log type you want to forward, click Add in the relevant section (e.g., “Threat”).
    • Name: CriticalThreatsRule
    • Log Type: threat (already selected if you clicked Add in the Threat section)
    • Filter: This is powerful! Let’s say we only want critical/high threats.
      • Click Add in the “Filter” section.
      • Field: severity
      • Operator: is one of
      • Value: Select critical, high.
      • Click OK.
    • Syslog: Select MySyslogServer (the profile we created).
    • Panorama: (Optional) Select default if you have Panorama and want to send these logs there too.
    • SNMP Trap: (Optional) If you have an SNMP server configured.
    • Email: (Optional) If you want email alerts for these specific logs.
  5. Click OK to save the rule, then OK again to save the Log Forwarding Profile.
# CLI equivalent (for reference)
# Create a log forwarding profile for critical threats
configure
set shared log-settings log-forwarding-profile CriticalThreatsToSIEM match-list CriticalThreatsRule log-type threat filter '(severity eq critical) or (severity eq high)' syslog MySyslogServer
commit

Explanation: This profile (CriticalThreatsToSIEM) contains rules for forwarding specific log types. We created a rule specifically for threat logs, applying a filter to only include those with critical or high severity. Finally, we direct these filtered logs to our MySyslogServer profile. This allows for very granular control over what logs are sent where.

Step 3: Applying the Log Forwarding Profile to a Security Policy

A Log Forwarding Profile is useless until it’s applied to something. Typically, you apply it to Security Policy rules.

  1. Navigate to Policies > Security.
  2. Select the security policy rule you want to associate with this logging behavior (e.g., a rule that permits outbound internet access).
  3. Click the Actions tab at the bottom of the rule editor.
  4. In the Log Forwarding dropdown, select CriticalThreatsToSIEM.
  5. Ensure Log at Session End is checked (this is the default and generally recommended for most traffic logs).
  6. Click OK to save the policy rule.
  7. Commit your changes to the firewall.
# CLI equivalent (for reference)
# Apply the log forwarding profile to a security policy rule named "Outbound-Internet"
configure
set rulebase security rules Outbound-Internet action allow log-end yes log-forwarding CriticalThreatsToSIEM
commit

Explanation: By applying CriticalThreatsToSIEM to a security policy, any session processed by that policy that also generates a threat log meeting our filter criteria will have that log forwarded to the configured Syslog server. This links our security enforcement directly to our visibility strategy.

Step 4: Monitoring Logs in the GUI

After configuring, it’s time to verify! The Monitor tab is your go-to.

  1. Navigate to Monitor > Logs.
  2. You’ll see different sub-tabs for each log type (Traffic, Threat, URL Filtering, etc.). Click on Threat.
  3. Observe the logs. You can use the filter bar at the top to search for specific criteria, like (severity eq critical) or (severity eq high) to match your log forwarding profile.
  4. Practice: Try filtering by Source IP, Destination IP, or Application. Click on an individual log entry to open a detailed view with all its attributes.

Explanation: The Monitor tab provides a powerful, interactive way to view logs. You can apply complex filters, sort columns, and drill down into individual log entries to understand the full context of an event. This is invaluable for real-time monitoring and historical analysis.

Step 5: Generating a Basic Custom Report

Let’s create a simple report to summarize threat activity.

  1. Navigate to Monitor > Reports.
  2. Click on the Custom Reports tab.
  3. Click Add.
  4. Report Name: Monthly Critical Threats
  5. Database: Select Threat (as we’re reporting on threat logs).
  6. Time Frame: Last Calendar Month
  7. Query: Enter (severity eq critical) or (severity eq high) (This matches our log forwarding filter).
  8. Report Type: Summary
  9. Summary Fields:
    • Click Add.
    • Field: threatid (to see which threats are most common)
    • Operation: count
    • Add another field: src (source IP)
    • Operation: unique-count
    • Add another field: dst (destination IP)
    • Operation: unique-count
  10. Click OK to save the report.
  11. To run it immediately, select the report and click Run Now.
  12. Once generated, click the PDF or CSV icon to view the report.

Explanation: Custom reports allow you to aggregate log data into meaningful summaries. By selecting the database, time frame, and specific query, you can focus on the most relevant data. Summary fields with operations like count or unique-count help you quickly identify trends and top contributors to specific events, which is crucial for high-level security assessments.

Mini-Challenge: Refined Log Forwarding

You’ve got the basics down! Now, let’s refine your logging skills.

Challenge: Configure a new log forwarding profile named AppVisibilityLogs that specifically forwards Traffic logs to your MySyslogServer profile. However, this profile should only forward logs for the web-browsing and ssl applications, and only if the action was allow. Apply this new profile to a security policy that permits internal users to access the internet.

Hint:

  • Remember to use the “Filter” option within the log forwarding profile rule. You can combine multiple conditions using and and or operators.
  • The filter for applications would look something like (application eq web-browsing) or (application eq ssl).
  • Don’t forget to commit your changes after applying the profile to the security policy.

What to observe/learn:

  • How to create highly specific log forwarding rules.
  • The power of combining multiple filter conditions.
  • Verifying that only the desired logs (web-browsing/ssl, allowed) are being forwarded to your Syslog server (or visible in the firewall’s Traffic logs with the same filter). This demonstrates granular control for application visibility.

Common Pitfalls & Troubleshooting

Even with careful configuration, logging and monitoring can sometimes present challenges.

  1. Logs Not Forwarding to SIEM:

    • Problem: You’ve configured Syslog forwarding, but logs aren’t appearing in your SIEM.
    • Troubleshooting Steps:
      • Check connectivity: Can the firewall ping the Syslog server? (ping host <SIEM_IP> from CLI).
      • Firewall on SIEM: Is the SIEM server’s host-based firewall blocking traffic on port 514/6514?
      • Syslog service: Is the Syslog daemon running on the SIEM server?
      • Log forwarding profile: Is the profile correctly applied to the security policy? Are the filters in the profile too restrictive?
      • Interface management profile: Does the interface connected to the SIEM have a management profile allowing Syslog traffic? (Device > Setup > Interfaces > Management Profile).
      • Packet Capture: Run a packet capture on the firewall’s egress interface to see if Syslog packets are leaving the firewall. (monitor packet-capture from CLI).

  2. Overwhelming Log Volume:

    • Problem: Your SIEM is getting flooded with too many logs, making it hard to find important events or costing too much in storage.
    • Troubleshooting Steps:
      • Refine Log Forwarding Profiles: Use granular filters to send only relevant logs (e.g., only threat logs, or traffic logs for specific zones/applications).
      • Review Security Policies: Do all “allow” rules need to log at session end? Consider only logging critical allow rules or rules that might require auditing.
      • Severity Filtering: For threat and system logs, often only critical, high, or medium severity logs are needed for external forwarding.

  3. Inaccurate or Missing Reports:

    • Problem: Reports aren’t showing the expected data or seem incomplete.
    • Troubleshooting Steps:
      • Time Frame: Double-check the report’s time frame. Is it covering the period you expect?
      • Query Filters: Are the query filters correctly defined? Simple typos or incorrect logic (and vs. or) can drastically alter results. Test your query in the Monitor tab first, as it uses the same syntax.
      • Database Selection: Ensure you’re pulling from the correct log database (e.g., Threat logs for threat reports).
      • Log Retention: Is the firewall or Panorama retaining logs for the duration required by your report’s time frame?

Summary

Congratulations! You’ve completed a crucial chapter on the visibility aspects of Palo Alto Networks firewalls. Let’s recap the key takeaways:

  • Diverse Log Types: Palo Alto firewalls generate a rich array of logs (Traffic, Threat, URL, System, etc.) each providing unique insights.
  • Centralized Logging is Key: For enterprise environments, Panorama is the recommended solution for centralized log collection, management, and reporting.
  • Granular Log Forwarding: You can create custom Log Forwarding Profiles to send specific logs (filtered by type, severity, application, etc.) to external systems like SIEMs via Syslog.
  • Powerful Monitoring Tools: The ACC provides high-level dashboards, while the Monitor tab offers detailed, searchable views of all log types.
  • Actionable Reporting: Built-in and custom reports transform raw log data into intelligence for security posture assessment, compliance, and trend analysis.
  • Best Practices: Always consider centralized logging, granular filtering, appropriate log retention, and regular review of logs and reports.

Understanding logging, monitoring, and reporting isn’t just a technical skill; it’s a fundamental security practice that empowers you to detect, respond, and proactively defend your network.

In our next chapter, Chapter 13, we’ll shift our focus to Performance Tuning and High Availability. We’ll explore how to optimize your firewall’s performance and ensure your security infrastructure remains resilient and available even in the face of hardware failures.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.