PAN-OS: Creating Custom Applications and Threat Signatures

Introduction: Extending Firewall Capabilities

While Palo Alto Networks provides extensive, regularly updated libraries for application identification (App-ID) and threat signatures, there are situations where organizations need to define their own custom classifications. PAN-OS allows administrators to create Custom Application Signatures (often called "Custom Apps") and Custom Threat Signatures .

• Custom Applications: Used to identify applications (typically internal or obscure) that are not covered by the standard App-ID database, enabling Layer 7 visibility and policy control for that traffic.
• Custom Threat Signatures: Used to detect specific patterns in network traffic that indicate a threat unique to the organization, a zero-day exploit not yet covered by vendor signatures, or sometimes for policy enforcement based on content patterns.

Understanding how to create and apply these custom objects is crucial for tailoring the firewall's capabilities to specific organizational needs and threat landscapes.

Purpose and Use Cases

Create a Custom Application when:

• You have an in-house, proprietary application that needs specific policy control (Allow, Deny, QoS, Threat Prevention).
• A standard App-ID is too broad, and you need to identify a specific subset or behavior of that application based on traffic characteristics for distinct policy treatment.
• An application uses a non-standard protocol or encoding that the standard App-ID engine cannot fully classify, but you know its unique traffic patterns.
• You need to classify traffic based on specific Layer 7 data (e.g., HTTP headers, URL patterns, specific payload data) that isn't captured by existing App-IDs.

Important Distinction: Unlike Application Override (which bypasses App-ID), Custom Applications *integrate* with the App-ID engine. The firewall uses the custom signature definition within the App-ID framework to classify the traffic.

Configuration Location and Key Parameters

• GUI Path: Objects > Applications , then click 'Add'.
• Key Parameters:
  • Name: Unique, descriptive name.
  • Category/Subcategory/Technology: Classify your custom app for organization and potential use in Application Filters.
  • Risk: Assign a risk level (1-5).
  • Ports: Define standard TCP/UDP ports (used for `application-default`).
  • Characteristics: Select relevant attributes (e.g., `capable-of-file-transfer`, `used-by-malware`).
  • Signature Tab (Crucial): This is where you define *how* to identify the application. You create one or more signatures using:
    • Port/Protocol Specification: Basic Layer 4 matching (TCP/UDP port). Often used as a starting point or in combination with L7.
    • Layer 7 Signatures: Define patterns based on:
      • HTTP Header Fields: Match Host, User-Agent, Referer, Method, URL patterns.
      • Payload Content: Match specific strings or patterns within the data payload using Contexts and Patterns (PCRE regular expressions can be used).
  • Parent App: Optionally link to a standard App-ID if this custom app is a variant.

How Custom Apps are Used

1. Create the Custom Application object with its signature(s).
2. Commit the configuration.
3. Use the Custom Application name just like any standard App-ID in Security Policy rules, QoS rules, etc.
4. Set the Service in Security rules preferably to application-default if you defined standard ports, or specify the custom port if necessary.

Purpose and Use Cases

Create Custom Threat Signatures when:

• You need to detect a specific threat targeting your organization that isn't covered by standard Palo Alto Networks signatures (e.g., unique malware C2 traffic, internal policy violations).
• You want to create a signature for a zero-day vulnerability before an official vendor signature is released (requires deep protocol/exploit knowledge).
• You need to block or alert on specific data patterns for compliance or internal policy (e.g., detecting specific keywords or file types not covered by Data Filtering).
• You need signatures for non-standard protocols or specific variants used internally.

Types and Configuration Location

• GUI Path: Objects > Custom Objects > [Threat Type]
• Primary Types for Custom Signatures:
  • Spyware (Phone-Home): Detects Command & Control (C2) traffic, botnet activity, or specific outbound connections based on patterns. Often looks for specific hostnames, URLs, or patterns in client->server traffic.
  • Vulnerability Protection: Detects exploit attempts or malicious patterns targeting specific vulnerabilities. Often looks for patterns in server->client or client->server traffic related to known exploit vectors.
  • Custom Vulnerability Signature (Advanced): Allows creating signatures with more complex stateful logic and protocol decoding context, similar to vendor-provided signatures. Requires deeper expertise.
  • (Note: Custom URL Categories and Data Patterns are related but configured differently).

Key Configuration Parameters (Spyware/Vulnerability)

• Name: Unique, descriptive name.
• Threat ID: Assign a unique ID within the custom range (typically high numbers).
• Severity: Critical, High, Medium, Low, Informational.
• Direction: Client-to-Server, Server-to-Client, or Both.
• Default Action: Alert, Allow, Drop, Reset (can be overridden in the profile).
• Signature Tab (Crucial): Defines the pattern(s) to match.
  • Standard Signatures (Simpler):
    • Add one or more conditions.
    • Context: Where in the protocol/payload to look (e.g., `http-req-host-header`, `tcp-payload`, `dns-query`).
    • Pattern: The specific string or regex pattern to match within the context.
    • Qualifiers: Additional options like `case-insensitive`.
  • Combination Signatures (AND/OR Logic): Group multiple standard signatures with AND or OR logic for more complex matching.

How Custom Threat Signatures are Applied

Creating a custom threat signature does **NOT** automatically enable detection. You must actively apply it:

1. Create the Custom Threat Signature object (e.g., a custom spyware signature).
2. Navigate to the relevant Security Profile:
   • For custom Spyware signatures: Objects > Security Profiles > Anti-Spyware . Edit or create a profile.
   • For custom Vulnerability signatures: Objects > Security Profiles > Vulnerability Protection . Edit or create a profile.
3. In the profile, go to the Exceptions or Rules tab (depending on profile type/version).
4. Explicitly enable detection for your custom signature Threat ID (or use the 'Show all signatures' option and find it by name). Set the desired Action (Alert, Block, etc.) which overrides the signature's default action if needed.
5. Attach the modified Security Profile (Anti-Spyware or Vulnerability Protection) to the Security Policy rule(s) governing the traffic you want to inspect.
6. Commit the changes.

graph TD
    A["Create Custom Threat Signature - Objects to Custom Objects"] --> B{"Edit Security Profile - Anti-Spyware or Vulnerability Protection"};
    B -- "Enable Threat ID & Set Action" --> C["Security Profile Includes Custom Threat"];
    C --> D{"Attach Profile to Security Policy Rule - Policies to Security"};
    D -- "Inspects Allowed Traffic" --> E["Firewall Engine Detects Custom Threat"];

    style A fill:#fdebd0,stroke:#f5b041,stroke-width:2px
    style C fill:#d5f5e3,stroke:#58d68d,stroke-width:2px

     

Common Gotchas and Caveats

• Custom Apps:
  • Use specific Layer 7 signature details (HTTP fields, payload) whenever possible, rather than just port/protocol.
  • Test thoroughly using packet captures (PCAPs) of the target application traffic.
  • Document the purpose, traffic characteristics, and expected behavior clearly.
  • Prefer Custom Apps over Application Override for better security integration.
• Custom Threats:
  • Make patterns as unique and specific as possible to minimize false positives and performance impact.
  • Test rigorously against known-good traffic and known-bad traffic (if possible).
  • Start with 'Alert' action during testing before moving to 'Block' or 'Drop'.
  • Document the threat being targeted and the pattern's logic.
  • Regularly review if the custom threat is still relevant or if vendor signatures now cover it.
  • Be mindful of the performance implications of complex regex patterns.

For the PCNSE exam, understand:

• The purpose and use cases for both Custom Applications and Custom Threat Signatures.
• Where each type of object is configured in the GUI (Objects > Applications vs. Objects > Custom Objects).
• The basic components of a custom signature (e.g., name, ports/signatures for apps; name, severity, patterns/context for threats).
• The key difference: Custom Apps integrate with App-ID for policy matching; Custom Threats are detected via Security Profiles attached to policies.
• The crucial step of enabling Custom Threat signatures within Security Profiles.
• The importance of specificity to avoid false positives and performance issues.
• The difference between Custom Apps and Application Override.

References

• PAN-OS Admin Guide: Create a Custom Application
• PAN-OS Admin Guide: Create Custom Threat Signatures
• PAN-OS Admin Guide: Best Practices for Custom Signatures
• PAN-OS Admin Guide: Application Override (Contrast)
• Knowledge Base: Getting Started: Custom Application Signatures
• Knowledge Base: Getting Started: Custom Threat Signatures
• Palo Alto Networks Certified Network Security Engineer (PCNSE) Exam Blueprint