About Custom Application Signatures

Custom application signatures reduce unknown traffic, provide application visibility, and give you more granular control over applications on your network. For example, you may believe office productivity has decreased since the FIFA Women’s World Cup began. You can create custom signatures for the FIFA landing and live streaming pages and view FIFA activity in the ACC and Traffic logs ( as long as current security policies allow the traffic). From there, you can create a report, configure a QoS policy, or block the application by adding it to security policy.

An application signature identifies a pattern located within packets from an application or application function. This pattern uniquely identifies the application or function of interest. The App-ID ^™ traffic classification system relies on application signatures to accurately identify applications in your network. Palo Alto Networks has developed App-ID signatures for many wellknown applications. (See Applipedia for a complete list). However, the volume of commercial applications and the nature of internal applications means that some applications do not have a signature. Such traffic receives “unknown” classification in the ACC and Traffic logs alongside potential threats. To properly classify this traffic and enforce security policy rules, you can create a custom application signature .

Custom application signatures enable you to:

• Minimize “unknown” traffic on your network

• Identify internal applications or special interest applications, such as a custom payroll application or sports live streaming

• Monitor application usage in the ACC and Traffic logs

• Explicitly define allowed applications and application functions (for example, allowing Slack for instant messaging, but blocking file transfer)

• Perform QoS for a specific application

• Identify nested applications, such as Words with Friends in Facebook

Custom applications take precedence over predefined applications when traffic matches both a custom-defined signature and a Palo Alto Networks signature. Accordingly, Traffic logs reflect the custom application name once the new application has been configured.

About Custom Threat Signatures

Our next-generation firewalls allow you to create custom threat signatures to monitor malicious activity or integrate third-party signatures. As with Palo Alto Networks threat signatures, you can detect, monitor, and prevent network-based attacks with custom threat signatures. Build your signature by examining packet captures for regular expression patterns that uniquely identify spyware activity and vulnerability exploits. The firewall will scan network traffic for these patterns and act based on the action specified during configuration upon threat detection. Be sure to use custom threat signatures as part of anti-spyware and vulnerability protection profiles to detect and handle command-and-control (C2) activity and system flaws that an attacker might attempt to exploit.

You can also define a combination signature for brute force attacks —a custom threat signature that triggers when traffic matches a specified pattern a certain number of times in a given time interval.

• Create a Custom Threat Signature

• Create a Combination Signature

Combination Signatures for Brute Force Attacks

Combination signatures detect and prevent brute force attacks. A combination signature assigns a time attribute to an existing threat signature—the child signature—to form a distinct parent signature. The time attribute specifies the number of pattern matches or “hits” to the child signature and the time frame (in seconds) the hits must occur within for the parent signature to trigger. If a pattern matches the child signature alone, the default action for that signature occurs.

You can narrow the trigger conditions by including aggregation criteria, which define what the parent signature counts as a hit. You can select from “source,” “destination,” and “source-and destination.” If you wanted to count the number of hits to a particular destination IP address, you would set the aggregation criteria to “destination.” To count all hits from a particular source, select “source.” “Source-and-destination” instantiates multiple time-windows that count the n-number of instances when a single source goes to a specific destination.

• About Custom Threat Signatures

• Create a Combination Signature

Create a Custom Application Signature

To create a custom application signature, you must do the following:

Research the application using packet capture and analyzer tools

Identify patterns in the packet captures

Build your signature

Validate your signature

Custom application signatures require you to specify the Scope —how your signature is applied to the traffic, Context —the portion of the file or protocol where you expect to find your pattern, the Pattern , and the Operator ( Pattern Match for string contexts and Greater Than , Less Than , or Equal To for integer-based contexts).

Refer to the Custom Signature Contexts , Defining Applications and Syntax for Regular Expression Data Patterns while building your signature.

Tutorial: How to Configure a Custom App-ID

STEP 1 | Research the application using packet capture and/or analyzer tools.

• You should understand how you’d like to control the application before all else. Do you want to limit application functionality? Create a usage report? You’ll want to examine the contents of packet captures to gather context and identify unique characteristics of the application.

Consider using a tool such as Wireshark or perform a packet capture on the firewall itself Take a Packet Capture for Unknown Applications .

1. Perform multiple packet captures between the client system and web server.

Generate traffic for various application scenarios once you have launched the capture tool. For example, if you wanted to create a signature for ‘uploading’ on uploading.com, you would upload a file on that site.

Multiple sessions might be created for the different actions performed in the application. You will need to locate and inspect each type of session in the resulting packet captures.

2. Inspect packet captures for values or patterns that uniquely identify the application or application function.

For example, after you uploaded a file to uploading.com, you would look for HTTP POST request packets in the sessions captured by your packet analyzer tool. Then, you would examine the packet contents for patterns.

STEP 2 | Create the custom application.

1. Select Objects > Applications and click Add .

2. Under Configuration , enter a name and optional description for the application. Specify the application’s Properties and Characteristics.

• If your custom application has no Parent App that can be identified by regular App-ID or is used in an application override, the application cannot be scanned for threats.

• If the custom application has scanning options unchecked, the threat engine will stop inspecting the traffic as soon as the custom application is identified.

3. Under Advanced , define settings that will allow the firewall to identify the application protocol:

• Specify the default ports or protocol that the application uses. To specify signatures independent of protocol, select None.

• Specify the session timeout values. If you don’t specify timeout values, the default timeout values will be used.

• Indicate any type of additional scanning you plan to perform on the application traffic.

STEP 3 | Define your signature.

Multiple signatures may be necessary to account for all traffic specific to the application.

1. Under Signatures , click Add and enter a Signature Name and optional description.

2. Specify the Scope —Select between Transaction (e.g. HTTP request and response) or Session (e.g. a single POST request).

3. Specify the matching conditions by clicking Add And Condition or Add Or Condition .

4. Select an Operator to define the conditions that must be true for a signature to match traffic.

• If you select Pattern Match , select a Context and then use a regular expression to specify the Pattern . Optionally, Add a qualifier/value pair.

• Qualifiers are context-dependent and limit the match condition for the given context. For example, you might use the http-method qualifier to specify that a http-req- uri -path only matters if it is found inside an HTTP GET method.

• If you select Equal To , Less Than , or Greater Than , select an integer Context , and enter a Value .

5. Repeat sub-steps 3 and 4 for each matching condition.

If you leave Ordered Condition Match selected, make sure the condition or group of conditions is in the desired order. The most specific conditions should come first. To order the conditions: Select a condition or a group and click Move Up or Move Down .

You cannot move conditions from one group to another.

STEP 4 | Save the custom signature.

1. Click OK to save your signature definition.

2. Commit your signature.

STEP 5 | Test your custom signature .

Create a Custom Threat Signature

To create a custom threat signature, you must do the following:

Research the application using packet capture and analyzer tools

Identify patterns in the packet captures

Build your signature

Validate your signature

Be sure to Set Up Antivirus, Anti-Spyware, and Vulnerability Protection to specify how the firewall responds when it detects a threat.

Refer to the list of Custom Signature Contexts , Threat Details and Syntax for Regular Expression Data Patterns while building your signature.

Tutorial: Custom Vulnerability

To create a threat signature with time attributes, see create a combination signature .

STEP 1 | Add a custom threat.

1. Click Objects > Custom Objects > Spyware/Vulnerability and then click Add .

2. Under Configuration , fill out the following required fields in the General and Properties sections.

• Threat ID

• For a vulnerability signature, enter a numeric ID between 41000 and 45000. If the firewall runs PAN-OS 10.0 or later, the ID can also be between 6800001 and 6900000.

• For a spyware signature, the ID should be between 15000 and 18000. If the firewall runs PAN-OS 10.0 or later, the ID can also be between 6900001 and 7000000.

• Name —Specify the threat name.

• Severity —Select the severity of the threat.

STEP 2 | Define your signature.

1. Under Signatures , leave Standard selected unless you wish to Create a Combination Signature . Add a new signature.

2. Specify the following information:

• Standard —Enter a name to identify the signature.

• Comment —Enter an optional description.

• Ordered Condition Match —If the order in which the firewall attempts to match the signature definitions is important, make sure the check box is selected.

• Scope —Indicate whether this signature applies to a full Session or a single Transaction .

3. Specify the matching conditions by clicking Add And Condition or Add Or Condition .

4. Select an Operator to define the conditions that must be true for a signature to match traffic.

• If you select Pattern Match , specify the following:

• Context —Select from available custom signature contexts .

• Pattern —Use a regular expression to define this attribute.

• Optionally, Add a qualifier/value pair.

Qualifiers are context-dependent and limit the match condition for the given context.

• Select Negate to signal a condition under which the custom signature does not trigger. The custom signature matches to traffic only when this condition is false.

• A custom signature cannot be created with only Negate conditions. You must include at least one positive condition in your definition.

• If the signature’s scope is set to Session, a negative condition cannot be configured as the last condition to match to traffic.

You can define exceptions for custom vulnerability or spyware signatures using the new option to negate signature generation when traffic matches both a signature and the exception to the signature. Use this option to allow certain traffic in your network that might otherwise be classified as spyware or a vulnerability exploit. In this case, the signature is generated for traffic that matches the pattern; traffic that matches the pattern but also matches the exception to the pattern is excluded from signature generation and any associated policy action (such as being blocked or dropped). For example, you can define a signature to be generated for redirected URLs; however, you can now also create an exception where the signature is not generated for URLs that redirect to a trusted domain.

• If you select an Equal To , Less Than , or Greater Than operator, specify a Context and a Value .

5. Repeat sub-steps 3 and 4 for each matching condition.

You cannot move conditions from one group to another.

STEP 3 \|	Save the custom threat. 1. Click OK to save the custom threat.
STEP 4 \|	Enable your custom signature. 1. Go to Security Profiles > Anti-Spyware/Vulnerability Protection and select an existing profile. 2. Under Exceptions , Show All Signatures , enter the Threat ID you created, and Enable it. 3. Click OK .
STEP 5 \|	Commit your changes.
STEP 6 \|	Test your custom signature .

Create a Combination Signature

You can create a combination signature to monitor the frequency and rate of matches to a signature on your network. You’ll need to know the Threat ID of an existing threat signature or create a custom threat signature that detects a particular event such as a Wordpress login attempt. When you configure your combination signature, you’ll have to specify the time conditions for matches to the threat—x number of hits in y number of seconds. You can adjust the time attribute according to needs and experience.

STEP 1 | Add a custom threat.

1. Click Objects > Custom Objects > Spyware/Vulnerability and then click Add .

2. Under Configuration , fill out the following required fields in the General and Properties sections.

• Threat ID

• For a vulnerability signature, enter a numeric ID between 41000 and 45000. If the firewall runs PAN-OS 10.0 or later, the ID can also be between 6800001 and 6900000.

• For a spyware signature, the ID should be between 15000 and 18000. If the firewall runs PAN-OS 10.0 or later, the ID can also be between 6900001 and 7000000.

• Name —Specify the threat name.

• Severity —Select the severity of the threat.

STEP 2 | Define your signature.

1. Click Signatures and select Combination .

2. Under Combination Signatures , click Add And Condition or Add Or Condition .

• To add a condition within a group, select the group and click Add Condition .

• To move a condition within a group, select the condition and click Move Up or Move Down .

You cannot move conditions from one group to another.

• To move a group, select the group and click Move Up or Move Down .

3. Choose the Threat ID for the signature you’d like to use. You may also edit the condition name.

4. Under Time Attribute specify the following:

• Number of Hits —Specify the threshold that will trigger any policy-based action as a number of hits (1-1000) in a specified number of seconds (1-3600).

• Aggregation Criteria —Specify whether the hits are tracked by source IP address, destination IP address, or a combination of source and destination IP addresses.

• To move a condition within a group, select the condition and click Move Up or Move Down .

You cannot move conditions from one group to another.

• To move a group, select the group and click Move Up or Move Down .

5. Repeat sub-steps 2 , 3 , and 4 for each matching condition.

You cannot move conditions from one group to another.

STEP 3 |

Save the custom threat.

1. Click OK to save the custom threat.

2. Commit your signature(s).

STEP 4 |

Test your custom signature .

Create a Custom Threat Signature from a Snort Signature

The following steps illustrate the process for converting a Snort signature into a custom spyware signature compatible with Palo Alto Networks firewalls. The use case below uses a Snort rule for a North Korean Trojan malware variant as identified by the Department of Homeland Security, the Federal Bureau of Investigation, and other US government partners.

With Panorama version 10.0 or later, you can use the IPS Signature Converter plugin to automatically convert Snort and Suricata rules into custom Palo Networks threat signatures instead of manually performing the following procedure.

Snort rule:

alert tcp any any -> any any (msg:" Malformed_UA "; content:" UserAgent : Mozillar /"; depth:500; sid:99999999;)

Reference: https://www.us-cert.gov/ncas/alerts/TA17-318B

IOC List: https://www.us-cert.gov/sites/default/files/publications/TA-17-318B-IOCs.csv In this example you can:

• Use the IP addresses provided as part of the IOC List to detect if a possible infection already exists by searching the firewall logs.

• The IP addresses provided can be part of an EDL or Address group and added to a Policy to block traffic to and from the suspicious list.

• Use the provided Snort signature and convert it to a custom spyware signature. This signature will become part of the spyware profile added to the appropriate policy.

For other use cases, see our companion article .

STEP 1 | Create a Custom Spyware Object.

1. Navigate to Objects > Custom Objects > Spyware/Vulnerability .

2. Click Add and provide a Threat ID , an optional comment, and fill out the Properties section.

3. Under Signatures , press Add .

4. Specify the following information:

• Standard —Enter a name to identify the signature in the field.

• Comment —Enter an optional description.

• If the order in which the firewall attempts to match the signature definitions is important, keep Ordered Condition Match selected.

• Scope —Indicate whether this signature applies to a full Session or a single Transaction .

5. Add a condition by clicking Add And Condition or Add Or Condition .

6. Select an Operator from the drop-down menu to define the conditions that must be true for the signature to match traffic.

• If you select Pattern Match , identify a Context in the Snort pattern that matches our available contexts , provide a regular expression Pattern , and optionally, Add a qualifier/value pair. Select Negate to specify conditions under which the custom signature does not trigger.

• If you select Equal To , Less Than , or Greater Than , select a Context and enter a Value .

7. Click OK to finish creating the Spyware object.

STEP 2 \|	Verify that the custom Spyware object is part of your Anti-Spyware Profile. 1. Go to Security Profiles > Anti-Spyware . Click an existing profile, then under Exceptions , search for your signature’s Threat ID and Enable it.
STEP 3 \|	Create an EDL object. 1. Navigate to Objects > External Dynamic Lists . Click Add . 2. Add the suspicious IP address provided from the IOC list to a previously created EDL or a new EDL as shown below.
STEP 4 \|	Add the EDL and Anti-Spyware profiles to appropriate Policy Objects.
STEP 5 \|	Test policy is working as expected by looking at Threat logs.
STEP 6 \|	Change the action for the spyware object from alert to drop/reset after verification. Also, change the severity of the object created as needed.
STEP 7 \|	Commit your signature(s).
STEP 8 \|	Test your custom signature .

Create a Custom L3 & L4 Vulnerability Signature

You can create custom threat signatures (vulnerability) based on Layer3 and Layer4 header fields (such as IP flags, acknowledgment numbers, etc ). This enables you to provide user-created vulnerability signature coverage for old and deprecated TCP/IP stacks used in embedded / IoT devices that normally would not have any existing threat signature coverage.

Custom L3 & L4 vulnerability signatures are expressed through your Zone and Zone Protection profile configuration. You must specify how the firewall responds when it detects a threat.

STEP 1 | Log in to the PAN-OS web interface.

STEP 2 | Select Device > Setup > Session and enable L3 & L4 Header Inspection globally on the firewall.

STEP 3 | Create a Zone Protection profile and configure your L3 & L4 header inspection settings.

1. Select Network > Network Profiles > Zone Protection and either select an existing profile or Add a new profile.

2. If you are creating a new zone protection profile, enter a Name for the profile and an optional Description .

3. Select L3 & L4 Header Inspection to define your custom vulnerability signatures.

4. Add new custom rules by defining the configuration and signature details for each entry, which are performed in their respective tabs: Configuration and Signature .

5. Under Configuration , fill out the following required fields in the General, Properties, and Reference section.

• Rule —Specify the custom rule name.

• Threat ID —Enter a numeric ID between 41000 and 45000 or 6800001 and 6900000.

• Comment —Optionally, add a description of the custom rule.

• Packet Capture —Select a packet capture setting.

Optionally, select send icmp unreachable packets if packet is dropped to send an ICMP unreachable response to the client upon packet loss.

• Exempt IP —Enter the IP address(es) for which you do not want the custom rule to apply to.

• Log Severity —Select the severity of the threat.

• Log Interval —Indicates how frequently an event is logged.

• Action —Choose the action to take when there is a custom signatures match. Options include alert, drop, reset-client, reset-server, and reset-both. Refer to Security Policy Actions for more information about these action settings.

• Reference —Add references to provide context or related information about the custom threat signature. You can add CVEs, Bugtraq citations, 3rd party vendor IDs, or reference links to additional analysis or background information.

6. From the Signature tab, provide a name or description of the custom vulnerability under Comment . After specifying a name, select Add to provide the custom signature details.

• Specify a matching Or Condition. When finished, select Add to configure an And Condition and the associated values in a new window.

• If you select a Less Than or Greater Than operator, specify a Context and a Value . The Equal To operator additionally has Mask and Negate options. Click OK when you have finished configuring the new and condition.

7. Repeat for each matching condition that you want to add.

8. Click OK and review your signatures. Click OK again to return to the zone protection profile.

9. From the L3 & L4 Header Inspection tab, you can reorder, disable, and clone the custom rule entries as necessary. Click OK to exit the zone protection profile.

STEP 4 | Apply the Zone Protection profile to a security zone that is assigned to interfaces you want to protect.

1. Select Network > Zones and select the zone where you want to assign the Zone Protection profile.

2. Add the Interfaces belonging to the zone.

3. For Zone Protection Profile , select the profile you just created.

4. Select Enable Net Inspection to enable the L3 & L4 header inspection configuration settings.

	5. Click OK .
STEP 5 \|	Commit your changes.
STEP 6 \|	Test your custom signature .

Test a Custom Signature

Custom signatures are particularly at risk for false positives and false negatives— the incorrect identification of traffic or failed detection of applications or threats. You should always test a custom signature after committing its configuration to verify that it functions as expected. Poorly written or outdated custom signatures may only be detected (and improved) through testing. If left unexamined, your signatures can reduce the efficacy of the firewall.

For custom App-ID signatures, generate traffic matching the application or application functions on a client system with a firewall between it and the application. Then, check the Traffic logs to verify that the generated sessions match the signatures you wrote. Your signature is incomplete if any traffic from your session does not match. Look at streams of sessions that do not match your signature with a packet capture tool like Wireshark. Identify unique patterns from those streams and add them to your signature to improve the accuracy of your signature.

For custom threat signatures, run penetration tests to detect system vulnerabilities. Then, view the Threat logs to see threat activity and the actions taken. Investigate any false positives or negatives. You may need to modify your signature, change its default action, or examine security profiles and policies.

Validate that traffic matches your signature as expected.

1. Run application traffic/penetration testing.

2. Navigate to Monitor > Logs > Traffic/Threat . Verify that you see traffic matching the custom application/threat (and that it is being handled per your policy rule).

For example, if you wrote an application signature for uploading on example.com, you would visit example.com and upload a file. In the Traffic logs, you would verify that the session updated from “web-browsing” to “uploading-example” after the file upload.

3. Fine-tune your signature by adding additional patterns or conditions to the signature, if necessary.

4. Repeat.

Custom Signature Pattern Requirements

The pattern requirements and available syntax for custom signatures depends on your firewall version. Firewalls running PAN-OS 10.0 (or a later version) have more flexible pattern requirements and a wider selection of regular expression (regex) syntax.

Refer to Syntax for Regular Expression Data Patterns for more details about the differences in syntax and pattern requirements between pre-PAN-OS 10.0 releases and PAN-OS 10.0 (and later) releases. You can switch between documentation releases by using the version switcher located in the left navigation bar.

If you encounter any errors using your custom signatures, verify that they conform to the following requirements.

Custom Signature

Pattern Requirements

All versions

•

You can enter hex-based patterns by surrounding the bytes with ‘ \ x ’.

•

Most signature patterns can contain a maximum of 127 characters.

• If you need to use a pattern longer than 127 characters, create two separate conditions—one beginning where the other left off —and join them with ‘ AND ’. You can still use Ordered Condition Match to require the firewall to consider one condition before the other to ensure a closer match to the full string.

• PA-220 and PA-800 appliances running PAN-OS 10.2 and later support a maximum pattern length of 64 characters for the following contexts: tcp -context-free and udp -context-free .

Signature compilation processes can cause other signatures to support a maximum pattern length of 64 characters, however, this is a rare occurrence.

As noted above, you can also create a pattern that is longer that the maximum size of 64

		characters by creating two separate conditions.
	•	Some application decoders may be case-sensitive for a given field, depending on the decoder the firewall uses. For this reason, you should define variations of the pattern. For example, \.CNN\.com and \. cnn \.com will ensure your signature functions properly regardless of case.
PAN-OS 9.1 and earlier versions	•	Every pattern you create must contain at least one 7-byte string with fixed values. • The 7 bytes cannot include a period ( . ), an asterisk ( * ), a plus sign ( + ), or [a-z] (ranges). • The 7-byte string can be anywhere in your pattern.
	•	The curly braces (repetition operator) has some limitations. • Curly braces must be preceded by a ‘ .’ (period). • You must have 7 static bytes after the braces.
	•	If you have two strings that are both less than 7 bytes and that are separated by a regular expression wildcard element, you must increase the size of at least one of the strings to 7 or more bytes.

Testing Pattern Performance Impact

Firewalls running PAN-OS 10.0 or later have an enhanced pattern-matching engine that loosens pattern requirements and offers a richer selection of syntax. Used incorrectly, these features can have consequences that range from higher latency to dropped packets. To help you avoid performance degradation, the firewall enables you to check the performance impact of your signatures before you commit them.

The firewall scores the performance impact of a signature on a scale of 0 to 100%. A score of 0% means the signature severely affects firewall performance and a score of 100% means it minimally affects performance.

Use either of the following two commands to check the performance impact of a signature:

Command

Description

test custom-signature-type pattern <pattern>

Calculates the performance impact of a signature without a context and determines whether the pattern is not valid, is valid but in only the new engine ( lscan ), or is valid in both the old and new engine ( pscan /AHO).

Example:

admin@VM-FW-75-252> test custom-signa ture -type pattern aaaa .

*The pattern is lscan pattern

Performance score: 68%

test custom-signature-perf context <context> pattern <pattern>

Calculates the performance impact of a signature with a context and displays a warning if the performance score is below 55%.

Example:

admin@VM-FW-75-252> test custom-signa ture -perf context http- rsp -headers pa

ttern aaaa.*

Performance score: 42%

This signature will have performance

impact

When you test a custom signature without a context , the score is a function of the literal parts of the pattern. The literal parts are the characters in the string with fixed values, such as “pan” and “net” in pan.{4}net . The greater the number and length of the literal parts, the higher the score of the pattern.

When you test a pattern with a context, the firewall performs the above calculation and adjusts it based on the typical length and frequency of the context. The firewall then divides the typical context length by the shortest literal part of the pattern and multiplies the base score of the pattern by this value. Finally, the firewall lowers the score if the context appears frequently and raises the score if the context appears infrequently.

Custom Signature Contexts

Custom signature contexts are available for both string and integer context types.

• String Contexts

• Integer Contexts

• Context Qualifiers

String Contexts

String Contexts are a type of custom signature context . They are used for Pattern Match operators.

• dhcp -req- chaddr

• dhcp -req- ciaddr

• dhcp-rsp-chaddr

• dhcp-rsp-ciaddr

• dns -req-addition-section

• dns -req-answer-section

• dns -req-authority-section

• dns -req-header

• dns -req-protocol-payload

• dns -req-section

• dns - rsp -addition-section

• dns - rsp -answer-section

• dns - rsp -authority-section

• dns - rsp -header

• dns - rsp -protocol-payload

• dns - rsp - ptr -answer-data

• dns - rsp -queries-section

• email-headers

• file-data

• file-elf-body

• file- flv -body

• file-html-body file-java-body file-mov-body file-office-content file-pdf-body file-riff-body file- swf -body file-tiff-body file-unknown-body ftp-req-params

• ftp-req-protocol-payload

• ftp- rsp -protocol-payload

• ftp- rsp -banner

• ftp- rsp -message

• gdbremote -req-context

• gdbremote - rsp -context

• giop -req-message-body

• giop - rsp -message-body

• h225-payload

• http-req-cookie

• http-req-headers

• http-req-host-header

• http-req-host-ipv4-address-found

• http-req-host-ipv6-address-found

• http-req-message-body

• http-req-mime-form-data

• http-req- ms -subdomain

• http-req-origin-headers

• http-req-params

• http-req- uri

• http-req- uri -path

• http-req-user-agent-header

• http- rsp -headers

• http-rsp-non-2xx-response-body

• http-rsp-reason

• icmp-req-code

• icmp-req-data icmp-req-type icmp-req-protocol-payload icmp-rsp-data icmp-rsp-protocol-payload icmp-req-possible-custom-payload ike-req-headers ike-rsp-headers ike-req-payload-text ike-rsp-payload-text

• imap -req- cmd -line

• imap -req-first-param

• imap -req-params-after-first-param

• imap -req-protocol-payload

• imap - rsp -protocol-payload

• irc -req-params

• irc -req-prefix

• jpeg-file-scan-data

• jpeg-file-segment-data

• jpeg-file-segment-header

• ldap -req- searchrequest - baseobject

• ldap-rsp-searchresentry-objectname

• ms -ds- smb -req-share-name

• ms-ds-smb-req-v1-create-filename

• ms-ds-smb-req-v2-create-filename

• msrpc -req-bind-data

• mssql - db -req-body

• netbios -dg-req-protocol-payload

• netbios -dg- rsp -protocol-payload

• netbios -ns-req-protocol-payload

• netbios -ns- rsp -protocol-payload

• nettcp -req-context

• oracle-req-data-text

• pe-dos-headers

• pe-file-header

• pe-optional-header

• pe-section-header pe-body-data pop3-req-protocol-payload pop3-rsp-protocol-payload pre-app-req-data

pre-app- rsp -data rtmp -req-message-body rtsp -req-headers rtsp -req- uri -path sip-req-headers

• snmp -req-community-text

• smtp-req-argument

• smtp-req-protocol-payload

• smtp- rsp -protocol-payload

• smtp- rsp -content

• ssh-req-banner

• ssh- rsp -banner

• ssl -req-certificate

• ssl -req- chello - sni

• ssl -req-client-hello

• ssl -req-protocol-payload

• ssl -req-random-bytes

• ssl - rsp -cert- subjectpublickey

• ssl - rsp -certificate

• ssl - rsp -protocol-payload

• ssl - rsp -server-hello

• tcp -context-free

• telnet-req-client-data

• telnet- rsp -server-data

• udp -context-free

• unknown-req- tcp -payload

• unknown- rsp - tcp -payload

• unknown-req- udp -payload

• unknown- rsp - udp -payload dhcp -req- chaddr

The payload of a DNS request.

Context Capture

dns -req-section

This context matches the DNS questions of a DNS query so that patterns can be written against one or more domains in a given DNS query.

Additional Details

All email headers and the plain text email body. Attachments are not included in this context as they are provided elsewhere.

Additional Details

None

Context Capture

This context provides the text in bold.

file-data

Covers the data of transferred files.

Additional Details

This context supports the following file types:

ABR ACE

ANI

ARJ header

• ASF

• BAT

• BMP

• CAB

• CAFF

• CHM

• Cineon

• CorelDRAW

• CRX

• CSV

• DER

• DEX

• DMG

• DOC

• DWF

• DWG

• EICAR

• ELF

• Email headers

• EMF

• EPS

• FFmpeg

• FLAC

• FLV

• Font

• GDS

• GIF

• GZip

• HDF

• HLP

• ICO

IFF

IVR

JarPack

Java

JPEG

• JS

• PL

• HTA

• LNK

• LZH

• M3U

• Mach

• MAKI

• MDB

• MDI

• MFT

• MIDI

• MOV

• MP2T

• MP3

• MPEG

• MVG

• MSOFFICE

• OGG

• OOXML

• Pcap

• PDF

• PE

• PGP

• PICT

• PKG

• PLS

• PNG

• Powershell

• PSD

• QVF

RAR

RIFF

RLA

RTF

• RWS

• SAMI

• SGI

• SH

• Shockwavelte ⇐

• Shockwavebte ⇐

• Softimage ⇐ PIC

• Soundbank

• SVG

• SWC

• SWF

• SWZ

• TIFF

• TNEF

• VBS

• WebM

• WebP

• WMF

• WOFF

• WPC

• WRI

• ZIP

Context Capture

This context captures the following information for a given file type (here GIF87a).

file-elf-body

Identifies an executable and linkable formatted (ELF) file type contained in a protocol or application response and checks the ELF file body.

Additional Details

None

Context Capture

file- flv -body

Full body of a flash video file minus the first 9 bytes, which are reserved for the header.

Additional Details

Here is a screenshot from Wikipedia detailing the 9-byte header:

Context Capture

Using a cli hex-editor named xxd , we can view the header of the flash file.

Every byte after the 9th is provided by this context. Only the first 50 bytes were printed here as an example.

file-html-body

Full body of a HTML file, minus the first 8 bytes as they’re reserved for the header.

Additional Details

None

Context Capture

xxd is a cli-based hex editor; every byte after the 8th byte is provided by this context. Only the first 50 bytes were printed here as an example.

file-java-body

Full body of a Java file, minus the first 4 bytes, which is always 0xCAFEBABE (“ cafebabe ”).

Additional Details

None

Context Capture

The first 4 bytes of the Java file printed by the cli-based hex editor, xxd . Every byte after the 4th is provided by this context. Only the first 25 bytes were printed in the above example.

When the firewall detects a tagged image file format (TIFF) file, this context returns data contained within the body of the file.

Additional Details

None

file-unknown-body

This context provides data after the first 8 bytes and up to 7 packets of an unknown file we couldn’t otherwise identify.

Additional Details

None

Context Capture

xxd is a cli-based hex editor; every byte after the 8th is provided up until 7 bytes is seen. In this example the first 8 bytes are numbered to easily show what wouldn’t be matched. Next are “A’s” followed by “shellcode” in hex. You could block this file by adding ‘\x7368656c6c636f6465\x’ in the “Pattern” field of the custom signature.

ftp-req-params

Parameters following an FTP command.

Additional Details

None

Context Capture

The context provides the text highlighted in yellow. Qualifiers: This context can use FTP command and FTP vendor ID qualifiers to limit signatures to specific FTP commands and known FTP clients.

ftp-req-protocol-payload

The payload of an FTP request.

Context Capture

ftp- rsp -protocol-payload

The payload of an FTP response.

Context Capture

ftp- rsp -banner

FTP welcome banner shown before authentication.

Additional Details

None

ftp- rsp -message

FTP server response code and the code itself. Note, that the code and the space can be used as part of the required 7-byte anchor.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

gdbremote -req-context

GDB is a process debugger that has the ability to debug across the network. This context provides the request data.

Additional Details

None

Context Capture

After capturing the GDB network data, follow the TCP stream to view the data. In this instance, everything in red is the request data, and that is what this context provides.

gdbremote - rsp -context

GDB is a process debugger that has the ability to debug across the network. This context provides the response data.

Additional Details

None

Context Capture

After capturing the GDB network data, I followed the TCP stream to view the data. In this instance, everything in blue is what this context provides

giop -req-message-body

Everything in the GIOP request.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

giop - rsp -message-body

Data after the GIOP header in a GIOP response.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

h225-payload

Extracts any data contained in an H.225.0 (App-ID: h.225) request.

Additional Details

None

Context Capture

http-req-cookie

Returns the Cookie header value contained in an HTTP request header.

Additional Details

None

Context Capture

http-req-headers

HTTP request header, not including the method, path, HTTP version, or host as those are provided elsewhere.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow. This context can use HTTP header field and HTTP method qualifiers to limit signatures to HTTP headers with specific values for select header fields and for specific HTTP methods.

http-req-host-header

Host field in a HTTP request header.

Additional Details

The pattern match searches for a pattern only within the highlighted field. By default it does not apply line start and line end anchors; as a result, the pattern ‘example.com’ will match with < anytext >example.com< anytext >. To initiate an exact match search, you must add a <space> before the pattern and ‘\r\n’ after the pattern on PAN-OS 9.1 and earlier. Starting with PAN-OS 10.0 you can use the following anchor characters: ^ and $ to specify a string start and end.

Context Capture

http-req-host-ipv4-address-found

When an HTTP request host header contains an IPv4 address, the value is set to 1.

Additional Details

None

Context Capture

Path in a HTTP request header (up to and including the ‘?’).

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

Qualifiers: This context can use the HTTP method qualifier to limit signatures to HTTP headers with specific HTTP methods.

Context Capture

icmp -req-code

Identifies the ICMP request message code number.

Additional Details

None

Context Capture

This context provides the highlighted text.

icmp -req-data

Identifies the ICMP payload request message.

Additional Details

None

Context Capture

This context provides the highlighted text.

icmp -req-type

Identifies the ICMP request message type number.

Additional Details

None

Context Capture

This context provides the highlighted text.

icmp -req-protocol-payload

The payload of an ICMP request.

Context Capture

icmp - rsp -data

Identifies the ICMP payload response message.

Additional Details

None

Context Capture

This context provides the highlighted text.

icmp - rsp -protocol-payload

The payload of an ICMP response.

Context Capture

icmp -req-possible-custom-payload

This context provides the text highlighted in yellow. This context can use the IMAP command qualifier to limit signatures to specific IMAP commands.

imap -req-params-after-first-param

Every parameter to an IMAP command, not including the first parameter.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

imap -req-protocol-payload

The payload of an IMAP request.

Context Capture

None jpeg-file-segment-data

This context provides all of the segment data within a JPEG file.

Additional Details

None jpeg-file-segment-header

This context provides the text highlighted in yellow. The easiest way to find a pattern to match is to look at the hex representation of the payload and pick at least 7 bytes to match on as seen above.

mssql - db -req-body

Request to a Microsoft SQL server, excluding the request header.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

netbios -dg-req-protocol-payload

The payload of a NetBIOS Datagram Service request.

Context Capture

netbios -dg- rsp -protocol-payload

The payload of a NetBIOS Datagram Service response.

Context Capture

netbios -ns-req-protocol-payload

The payload of a NetBIOS Name Service request.

Context Capture

netbios -ns- rsp -protocol-payload

The payload of a NetBIOS Name Service response.

Context Capture

nettcp -req-context

Checks the RequestContext field in Net.TCP (App-ID: net.tcp ) requests.

Additional Details

The payload of a POP3 request.

Context Capture

pop3-rsp-protocol-payload

The payload of a POP3 response.

Context Capture

pre-app-req-data

This field provides the request data before the firewall App-ID has identified the traffic.

Additional Details

Firewall traffic that cannot be identified by App-ID due to inadequate data for signature matching is designated as insufficient data in the application field of the traffic logs.

Context Capture

This context tracks the value of the variable field, “community” in the SNMP request header.

Additional Details

None

Context Capture

smtp-req-argument

Argument of a SMTP command.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow. This context can use the SMTP method qualifier to limit signatures to specific SMTP methods.

smtp- rsp -content

SMTP server response content.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

smtp-req-protocol-payload

The payload of an SMTP request.

Context Capture

ssl -req-random-bytes

Random bytes field in the SSL client hello.

Additional Details

None

Context Capture

This value is already hexadecimal; you’ll need to write the pattern in your signature as such (enclosed in \x).

ssl - rsp -cert- subjectpublickey

Certificate subject public key that’s part of an SSL server hello handshake.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

ssl - rsp -certificate

Certificate response message of a SSL negotiation from the server.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

ssl - rsp -protocol-payload

The payload of an SSL response.

Context Capture

ssl - rsp -server-hello

Server hello message of a SSL negotiation.

Additional Details

None

Context Capture

This context provides the text highlighted in yellow.

tcp -context-free

The entire payload of a TCP packet.

Additional Details

Available only on PAN-OS 10.0 or later.

• Using this context is not recommended and results in severe performance degradation.

• Upon upgrade to PAN-OS 10.2 and later, PA-220 and PA-800 appliances support a maximum pattern length of 64 characters.

Context Capture

telnet-req-client-data

All telnet data for traffic originating from the client.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

telnet- rsp -server-data

All telnet data for traffic originating from the server.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

udp -context-free

The entire payload of a UDP packet.

Additional Details

Available only on PAN-OS 10.0 or later.

• Using this context is not recommended and results in severe performance degradation.

• Upon upgrade to PAN-OS 10.2 and later, PA-220 and PA-800 appliances support a maximum pattern length of 64 characters.

Context Capture

unknown-req- tcp -payload

Full TCP payload for unknown TCP traffic originating from the client.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

unknown- rsp - tcp -payload

Full TCP payload for unknown TCP traffic originating from the server.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

unknown-req- udp -payload

Full UDP payload for unknown UDP traffic originating from the “client”, which is the initiator of UDP communications.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

unknown- rsp - udp -payload

Full UDP payload for unknown UDP traffic originating from the “server”, which is opposite the “client”.

Additional Details

None

Context Capture

This context matches the text highlighted in yellow.

Integer Contexts

Integer Contexts are a type of custom signature context . They are used for equality operators: less than, greater than, and equal to. They are available for custom IPS signatures, but not custom application signatures.

• dnp3-req-func-code

• dnp3-req-object-type

• dns - rsp - tcp -over- dns

• dns - rsp -txt-found

• ftp-req-params- len

• http-req-connect-method

• http-req-content-length

• http-req-cookie-length

• http-req-header-length

• http-req-host-ipv4-address-found

• http-req-host-ipv6-address-found

• http-req- dst -port

• http-req-param-length

• http-req-no-host-header

• http-req-no-version-string-small-pkt

• http-req-simple-request

• http-req- uri -path-length

• http-req- uri -tilde-count-num

• http- rsp -code

• http- rsp -content-length

• http-rsp-total-headers-len

• iccp-req-func-code

• ike -req-payload-type

• ike - rsp -payload-type

• ike -req-payload-length

• ike - rsp -payload-length

• ike -version

• imap -req- cmd -param- len

• imap -req-first-param- len

• imap -req-param- len -from-second

• irc -req-protocol-payload

• irc - rsp -protocol-payload

• ntlm-req-auth-v1

• ntlm-req-auth-v2

• open- vpn -req-protocol-payload

• pfcp -req-msg-type

• pfcp - rsp -msg-type

• smtp-req- helo -argument-length

• smtp-req-mail-argument-length

• smtp-req- rcpt -argument-length

• sctp -req- ppid

• ssl -req-client-hello- ext -type

• ssl -req-client-hello-missing- sni

• ssl-rsp-version

• stun-req-attr-type

• panav-rsp-zip-compression-ratio dnp3-req-func-code

DNP3 Application Layer request and response headers contain function codes. The function codes include read, write, select, operate, and direct_operate . The dnp3-req-func-code context identifies these function codes which are 1 byte in length.

Additional Details

None

Context Capture

In this example, the function code ‘Select’ has hex value 0x03. In the custom application, a decimal equivalent of 3 will have to be defined.

dnp3-req-object-type

This context can be used to identify group and variation objects in the DNP3 library.

Additional Details

The dnp3-req-object-type context is a 2-byte hex value.

Context Capture

In this case, the hex is 0x0c01 and the custom application will take a decimal value of 3073.

Additional Details

None

Context Capture

The encoded characters below are included in this context.

Qualifiers: This context can use the HTTP method qualifier to limit signatures to HTTP headers with specific HTTP methods.

http- rsp -code

The number corresponding to the HTTP response code.

Additional Details

None

Context Capture

This context provides the integer highlighted in yellow.

http- rsp -content-length

Content length of a HTTP response.

Additional Details

None

Context Capture

This context provides the integer highlighted in yellow.

http- rsp -total-headers- len

Length of the HTTP response headers, not including the HTTP status banner.

Additional Details

None

Context Capture

This context provides the content-length of the text highlighted in yellow.

Total length of all parameters of an IMAP command.

Additional Details

None

Context Capture

This context provides the length of the text highlighted in yellow.

Qualifiers: This context can use the IMAP command qualifier to limit signatures to specific IMAP commands.

imap -req-first-param- len

Length of the first parameter of an IMAP command.

Additional Details

None

Context Capture

This context provides the length of the text highlighted in yellow.

Qualifiers: This context can use the IMAP command qualifier to limit signatures to specific IMAP commands.

imap -req-param- len -from-second

Total length of all parameters of an IMAP command, not including the first.

Additional Details

None

Context Capture

This context provides the length of the text highlighted in yellow

This context can use the IMAP command qualifier to limit signatures to specific IMAP commands.

irc -req-protocol-payload

The payloads of the prefix, commands, and parameters of an IRC request. Does not cover the entire payload.

Context Capture

This context covers the sections called out in red.

irc - rsp -protocol-payload

The payloads of the prefix, commands, and parameters of an IRC response. Does not cover the entire payload.

Context Capture

This context covers the sections called out in red.

ntlm-req-auth-v1

Detects and identifies the NTLM version contained in the NTLM response. If this field is set to 1, the protocol has been detected; if set to 0, the protocol has not been detected. Does not cover the entire payload.

Context Capture

This context covers the sections called out in blue.

ntlm-req-auth-v2

Detects and identifies the NTLMv2 version contained in the NTLM response. If this field is set to 1, the protocol has been detected; if set to 0, the protocol has not been detected. Does not cover the entire payload.

Context Capture

This context covers the sections called out in blue.

A PPID is a 32-bit unsigned integer value that represents an application (upper layer) specified protocol identifier. It identifies the type of information being carried in a SCTP DATA chunk.

Context Capture

ssl -req-client-hello- ext -type

Detects the extension type listed in the TLS client hello message.

Additional Details

None

Context Capture

This context provides the highlighted text, in this case, the encrypted Server Name extension present in the TLS Client Hello message. To detect this extension, specify ssl -req-client-hello- exttype equals 65486.

ssl -req-client-hello-missing- sni

When this field is set to 1, an SSL client hello without the presence of an SNI (Server Name Indication) entry during the SSL negotiation process, is detected.

Additional Details

None

Context Capture

The following SSL client hello examples show requests with and without an SNI, respectively.

With SNI Entry:

Without SNI Entry:

ssl - rsp -version

Detects the SSL version listed in the SSL server hello handshake.

Additional Details

None

Context Capture

stun-req- attr -type

This context identifies the 2-byte attribute type value in STUN server requests and responses.

Additional Details

In this case, the hex is 0x0003 and the custom application will take a decimal equivalent value of 3.

Context Capture

panav - rsp -zip-compression-ratio

This context detects the zip compression ratio of files downloaded over HTTP.

Additional Details

The data compression ratio compares the uncompressed size and the compressed size of a file.

This context can be used to identify a zip bomb or files with large data compression ratios.

Context Capture

Context Qualifiers

Qualifiers lessen the chance of false positives by restricting the locations where the firewall can find a given pattern. In other words, a signature matches only when the firewall detects the pattern inside a specific qualifier, which corresponds to a specific context. For example, you might use the http-method qualifier to specify that a http-req- uri -path pattern matters when found inside a HTTP GET method.

FTP Command Qualifiers

FTP Vendor ID Qualifiers

HTTP Header Field Qualifiers

HTTP Method Qualifiers

IMAP Command Qualifiers

RTSP Method Qualifiers

SMTP Method Qualifiers

FTP Command Qualifiers

FTP command qualifiers can be added to custom signatures that use FTP-related contexts to limit a match condition to specific FTP commands.

ABOR	ACCT	ALLO	APPE	AUTH	CDUP	CWD
DELE	EHLO	ERPT	HELO	LIST	MDTM	MKD
MODE	NLIST	OPTS	PASS	PASV	PBSZ	PORT
PWD	QUIT	REIN	REST	RETR	RMD	RNFR
RNTO	SITE	SIZE	SMNT	STAT	STOR	STOU
STRU	SYST	TEST	TYPE	UNKNOWNCOMMAND	UNLOCK	USER
XCRC	XMD5	XSHA1

FTP Vendor ID Qualifiers

FTP vendor ID qualifiers can be added to custom signatures that use FTP-related contexts to limit a match condition to specific FTP clients.

CEASERFTP	EASY_FILE_SH	ARING_FTPFILE_COPA_FTP	FREEFTPD	MICROSOFTFT	PNETTERM
PROFTPD	SERV_U	UNKNOWN_F	TP_SERVERVSFTPD	WARFTPD	WS_FTP
WUFTP

HTTP Header Field Qualifiers

HTTP header field qualifiers can be added to custom signatures that use HTTP-related contexts to limit a match condition to HTTP headers that have specific values for select header fields.

ACCEPT_LANG	UAUTHORIZATIGE	ONCONTENT_EN	CODICONTENT_LENG	GTHCONTENT_TYP	EHOST
IF_MOD_SINCE	SUBSCRIBE_H	DRTRANSFER_EN	CODINGUNKNOWN_H	DRX_FORWARD_	FOR

HTTP Method Qualifiers

HTTP method qualifiers can be added to custom signatures that use HTTP-related contexts to limit a match condition to HTTP headers that use specific HTTP methods.

BCOPY	BDELETE	BITS_POST	BMOVE	BPROPFIND	BROPPATCH	CCM_POST
CONNECT	COPY	DELETE	GET	HEAD	LINK	LOCK
MCKCOL	MOVE	NOTIFY	OPTIONS	POLL	POST	PROPFIND
PROPPATCH	PROXY_SUC	CESSPUT	RPC_CONNE	CTSEARCH	SMS_POST	SOURCE

SUBSCRIBE TRACE TRACK UNKNOWN_METHODUNLINK UNLOCK UNSUBSCRIBE

IMAP Command Qualifiers

IMAP command qualifiers can be added to custom signatures that use IMAP-related contexts to limit a match condition to specific IMAP commands.

APPEND	AUTHENTIC	ATECAPABILITY	CHECK	CLOSE	COPY	CREATE
DELETE	EXAMINE	EXPUNGE	FETCH	FIND	IDLE	LIST
LOGIN	LSUB	NOOP	RENAME	SEARCH	SELECT	STARTTLS
STATUS	SUBSCRIBE	UNKNOWN	_COMMANDUNSUBSCRI	BE

RTSP Method Qualifiers

RTSP method qualifiers can be added to custom signatures that use RTSP-related contexts to limit a match condition to specific RTSP methods.

ANNOUNCES	DESCRIBE	GET_PARAMETER	OPTIONS	PAUSE
PLAY	RECORD	REDIRECT	SET_PARAMETER	SETUP
SETUP_PARAMET	ERTEAR_DOWN	UNKNOWN_MET	HOD

SMTP Method Qualifiers

SMTP method qualifiers can be added to custom signatures that use SMTP-related contexts to limit a match condition to specific SMTP methods.

AUTH	BDAT	DATA	EHLO	HELO	MAIL	QUIT
RCPT	RSET	SAML	SEND	SOML	STARTTLS
USER	VRFY	XEXCH50	XEXPS	XLINK2STAT	EXTELLMAIL

UNKNOWN_CMD

IPS Signature Converter Plugin for Panorama

Snort and Suricata are open-source intrusion prevention system (IPS) tools that use uniquely formatted rules to detect threats. The IPS Signature Converter enables you to leverage these rules for immediate threat protection by translating the IPS signatures into custom Palo Alto Networks threat signatures . You can then register the signatures on Palo Alto Networks firewalls in specified device groups and enforce policy using Vulnerability Protection and Anti-Spyware Security Profiles .

Additionally, you can export rules that list IP address indicators of compromise (IOC) and use the resultant text file as an external dynamic list to enforce policy on the entries contained in the list.

• About the IPS Signature Converter Plugin

• Convert Rules Using the Panorama Web Interface

• Convert Rules Using the Panorama CLI

• Convert Rules Using the Panorama XML API

• Install the IPS Signature Converter Plugin

• CLI Quick Start

• Troubleshooting the IPS Signature Converter

About the IPS Signature Converter Plugin

The IPS Signature Converter plugin for Panorama provides an automated solution for converting rules from a third-party intrusion prevention system (IPS)—Snort or Suricata—into custom Palo Alto Networks threat signatures . You can then register these custom signatures on firewalls that belong to device groups you specify and use the signatures to enforce policy in Vulnerability Protection and Anti-Spyware Security Profiles .

Snort and Suricata are open-source IPS tools that use uniquely formatted rules to detect threats. Organizations that share threat intelligence often distribute security advisories with these rules to help you implement the appropriate protections on your firewall. The IPS Signature Converter plugin enables you to immediately act upon these advisories and protect your network against any threats you receive in Snort or Suricata format.

After you install the IPS Signature Converter plugin on Panorama, you can upload rules for conversion and import them to your device groups. You can also export rules containing indicators of compromise (IOC) to a text file that you can use as an external dynamic list to enforce policy on the entries contained in the list.

Convert Rules Using the Panorama Web Interface

After you install the intrusion prevention system (IPS) signature converter plugin, you can use it to translate Snort and Suricata rules into custom Palo Alto Networks threat signatures . You can then register the custom signatures on Palo Alto Networks firewalls that belong to device groups that you specify and use these customer signatures in your Vulnerability Protection and Anti-Spyware Security Profiles .

The following example uses this Snort rule:

alert tcp any any -> any any (msg:" Malformed_UA "; content:" UserAgent : Mozillar /"; depth:500; sid:99999999;)

STEP 1 | Select Panorama > IPS Signature Converter > Manage .

STEP 2 | Upload Signatures .

STEP 3 | Select one of two methods for uploading your rules:

• Browse to and select a text file.

You cannot convert binary file types, such as .pdf or .docx.

• Paste the rules directly into the text box.

You can upload only 300 rules at a time for conversion.

STEP 4 | Click OK .

Your signatures will populate at least one of the following tabs: Succeeded , Succeeded with Warnings , Failed , Duplicates , or Existing Coverage .

STEP 5 | ( Optional ) Export rules to an indicator of compromise (IOC) list.

Panorama converts a rule that does not contain the keywords content or PCRE into an IOC List . Export IOC List to group these rules into a text file that you can use as an external dynamic list for your Security policy rules.

1. Select Export IOC List .

A dialog displays any rules that converted as IOC List .

2. Select the rules that you want to export.

3. Enter the name of the file to which you want to export your rules.

4. Click OK .

The exported text file will appear in your downloads folder.

STEP 6 | Commit converted signatures to Panorama.

1. Select the signatures you want to upload.

2. Import Custom Signatures .

3. Select a Device Group from the drop-down.

Select Shared to make the signatures available to all device groups.

4. Under the Destination column, select whether to commit the signatures as Vulnerability or Spyware .

5. Click OK .

6. In the top right of the screen, select and Commit to Panorama .

7. Verify that you successfully committed your signatures.

1. Select Objects > Custom Objects .

2. Select either Spyware or Vulnerability , depending on how you categorized your signatures in the previous step .

STEP 7 | Push the signatures to managed firewalls.

The firewalls must be running PAN-OS 10.0 or a later release with an active Threat Prevention license.

STEP 8 | Test your signatures on a firewall in the device group to which you pushed the signatures.

Convert Rules Using the Panorama CLI

In addition to the web interface, you can use the command-line interface (CLI) to convert Snort

® and Suricata rules into custom PAN-OS threat signatures. This example uses the following Snort rule:

alert tcp $HOME_NET 2589 -> $EXTERNAL_NET any ( msg :"MALWARE-BACKDOOR

- Dagger_1.4.0"; flow:to_ client,established ; content:"2|00 00 00 06 00 00 00|Drives|24 00| ",depth 16; metadata:ruleset community;

classtype:misc -activity ; sid:105; rev:14 ; )

You can not convert rule files through the CLI. If you want to convert a file with multiple rules in it, use the Panorama web interface .

The CLI Quick Start contains additional CLI commands.

STEP 1 | Encode the rule in Base64 format.

You can do this using a free, browser-based tool ( example ).

Before encoding the rule, ensure there are no line breaks. Otherwise, the line breaks are encoded and cause the rule conversion in the subsequent step to fail.

STEP 2 | Convert the encoded rule:

admin@demo-panorama-vm> request plugins ips-signature-converter convert b64-encode <base64_encoded_rule>

LINE# TITLE RESULT TYPE CONVERTER_MSG

1 Converted_MALWARE - Succeed Plain None

BACKDOOR -

Dagger_1.4.0_105

Summary: Total:1, Succeed:1, Warnings:0, Existing Coverage:0,

Duplicated:0, Failed:0

STEP 3 | ( Optional ) Change the signature type.

If your signature is for protection against spyware, you can set the type as spyware so that Panorama imports it as an Anti-Spyware signature. Otherwise, rules convert as vulnerability by default.

admin@demo-panorama-vm> request plugins ips-signature-converter

set-properties signature-type <vulnerability/spyware > lines < line_number >

LINE# TITLE SIG_TYPE ACTION

SEVERITY

1 Converted_MALWARE -BACKDOOR - spyware alert

low

Dagger_1.4.0_105

STEP 4 | Import the signature to Panorama:

admin@demo-panorama-vm > request plugins ips-signatureconverter import-custom-signatures device-group < device_group > lines < line_number >

LINE# TITLE THREAT_ID STATUS DETAIL

1 Converted_MALWARE -BACKDOOR - 16002 Success Import

Succeeded

Dagger_1.4.0_105

If you do not specify a device-group , Panorama imports the signature to the Shared location.

STEP 5 | Commit your changes to Panorama:

admin@demo-panorama-vm # commit

Commit job 707 is in progress. Use Ctrl+C to return to command

prompt

...23%.59%80%.......90% ..... 100%

Configuration committed successfully

STEP 6 | Push the signatures to a device group:

@demo -panorama-vm> commit-all shared-policy devicegroup < device_group >

Job enqueued with jobid 709

709

STEP 7 | Log in to a firewall in the device group that you specified in the previous step to verify that the push succeeded:

admin@PA-3220# show threats <vulnerability/spyware> < threat_id >

~ spyware { 16002 { signature { standard {

ips_converted_pattern { and-condition {

"And Condition 1" { or-condition {

"Or Condition 1" { operator { pattern-match {

pattern "2\x00 00 00 06 00 00 00\ xDrives \x24

00\x ";

context tcp -context- free;

negate no;

}

order-free no; scope session;

Convert Rules Using the Panorama XML API

The Panorama XML API enables you to convert Snort and Suricata, open-source intrusion prevention system (IPS) rules to custom Palo Alto Networks threat signatures. You can then use the XML API to import the custom rules as Vulnerability Protection and Anti-Spyware Security profiles.

Because the PAN-OS XML API uses a tree of XML nodes, you must specify the correct type and action in your API request along with the XPath Node Selection . See Explore the API to learn how to construct XML requests.

You can not convert rule files through the CLI. If you want to convert a file with multiple rules in it, use the Panorama web interface .

STEP 1 | Convert Snort or Suricata policy rules to Base64 URL encoded format.

You can use a free, browser-based tool ( example .

This example uses the following Snort rule:

alert tcp $HOME_NET any -> $EXTERNAL_NET any ( msg:"ET CHAT Yahoo IM conference message"; flow: to_server,established ; content:"YMSG "; nocase ; depth: 4; content:"|00 1D|"; offset: 10; depth: 2; reference:url,doc.emergingthreats.net/2001258; classtype:policyviolation ; sid:2001258; rev:7; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

STEP 2 | Make a request to convert the rule to a custom PAN-OS threat signature.

curl -X POST ’https:// <firewall> / api /?key=

key &type=op&cmd=<request><plugins><ips-signatureconverter><convert><b64-encode> YWxlcnQgdGNwICRIT01FX05FVCBhbnkgLT4gJEVYVEVSTkF MX05FVCBhbnkgKG1zZzoiRVQgQ0hBVCBZYWh vbyBJTSBjb25mZXJlbmNlIG1lc3NhZ2UiOyBmbG93OiB0b19zZXJ2ZXIs ZXN0YWJsaXNoZWQ7IGNvbnRlbnQ6IllNU0ciOyBub2Nhc2U7IGRlcHRoO iA0OyBjb250ZW50OiJ8MDAgMUR8Ijsgb2Zmc2V0OiAxMDsgZGVwdGg

6IDI7IHJlZmVyZW5jZTp1cmwsZG9jLmVtZXJnaW5ndGhyZWF0cy5uZXQvMjAwM TI1ODsgY2xhc3N0eXBlOnBvbGljeS12aW9sYXRpb247IHNpZDoyMDAx

MjU4OyByZXY6NzsgbWV0YWRhdGE6Y3JlYXRlZF9hdCAyMDEwXzA3XzMwLCB1cGRh

dGVkX2F0IDIwMTBfMDdfMzA7KQ== </b64-encode></convert></ipssignature-converter></plugins></request>’

The response contains details about the rules (see previous details for more information):

<msg>

<convert-result>

<extra-msg></extra-msg> <failed-count>0/1</failed-count>

<duplicated-count>0/1</duplicatedcount> <duplicated></duplicated> <skipped-count>0/1</skipped-count>

<type>plain</type>

< sig_type >vulnerability</ sig_type > <line>1</line>

<title> Converted_ET CHAT Yahoo

IM conference message_2001258</title>

<action>alert</action> <severity>low</severity>

<msg>[ performance_impact ] use of tcp -context-free (YMSG)</msg>

< start_offset >127</ start_offset >

< end_offset >131</ end_offset > </entry>

</info>

</entry>

</warned> <succeed-count>0/1</succeed-count>

</msg>

</result>

</result> </response>

STEP 3 | Set the properties for rules that you converted.

Use the line number of a converted rule and set the properties. For example:

• Type set to spyware .

• Action when detected set to alert .

• Severity set to low .

curl -X POST 'https://

<firewall> / api /? type=op&key=LUFRPT0&cmd=<request><plugins><ips-signatureconverter><set-properties><default-action>alert</defaultaction><lines>1</lines><severity>low</severity><signaturetype>spyware</signature-type></set-properties></ips-signatureconverter></plugins></request>'

The resulting success message:

<msg>

<set-properties-result>

< sig_type >spyware</ sig_type >

<action>alert</action>

<severity>low</severity> <status>success</status>

</entry> </set-properties-result>

</msg>

</result>

</result> </response>

STEP 4 | ( Optional ) View the results of the converted rules.

The following request results in output that displays all successfully converted rules and the properties associated with each.

curl-X GET ‘https://

<firewall> /api/?type=op&key= apikey &cmd=<show><plugins><ipssignature-converter><results></results></ips-signature-converter></ plugins></show>

The resulting success message:

<msg>

<status>warned</status>

<rule>alert tcp $HOME_ NET any -

> $EXTERNAL_NET any ( msg:"ET CHAT Yahoo IM conference message"; flow: to_server,established ; content:"YMSG "; nocase ; depth: 4; content:"|00 1D|"; offset: 10; depth: 2; reference:url,doc.emergingthreats.net/2001258; classtype:policyviolation ; sid:2001258; rev:7; metadata:created_at 2010_07_30, updated_at 2010_07_30;)</rule> <type>plain</type>

< sig_type >spyware</ sig_type >

<title> Converted_ET CHAT Yahoo IM conference message _2001258</title> <action>alert</action>

< perf_score >10</ perf_score > < perf_level >high</ perf_level >

<info>

<msg>[ performance_impact ] use of tcp -context-free (YMSG)</msg> < start_offset >127</ start_offset > < end_offset >131</ end_offset >

</entry>

</info>

[CDATA[<entry><signature><standard><entry

name=" ips_converted_pattern "><and-condition><entry name="And

Condition 1"><or-condition><entry name="Or Condition

1"><operator><pattern-match><pattern>YMSG</pattern><context>tcpcontext-free</context><negate>no</negate></pattern-match> </operator>

</entry>

</or-condition>

</entry><entry name="And Condition 2">< orcondition ><entry name="Or Condition 1"><operator>< patternmatch ><pattern>\x00 1D\x</pattern><context> tcp -context-free</ context><negate>no</negate></pattern-match> </operator>

</entry>

</or-condition>

</entry>

</and-condition><order-free>no</orderfree><scope>session</scope></entry>

</standard>

</signature><default-action><alert/></defaultaction><reference><member>doc.emergingthreats.net/2001258</ member><member>Score: 10</member><member>Impact: high</member><member>Reason: use of tcp -context-free</ member></reference>< threatname > Converted_ET CHAT Yahoo IM conference message_2001258</ threatname ><severity>low</ severity><direction>client2server</direction><affectedhost><server>yes</server></affected-host>

STEP 5 | Import the Spyware or Vulnerability rule to your device groups to use in a custom object.

Using the line number of a successfully converted rule, send a request that imports the rule to the shared device group.

curl-X GET ‘https:// <firewall> / api /?key=

key &type=op&cmd=<request><plugins><ips-signatureconverter><import-custom-sig><lines>

1 </lines></import-custom-sig></ ips -signature-converter></ plugins></request>

The resulting success message using line one provides an ID number you can use to find the profile in the web interface.

<msg>

<import-result>

< sid >42556</ sid >

<status>success</status>

<msg>command succeeded</msg>

</entry> </import-result>

</msg>

</result>

</result> </response>

Install the IPS Signature Converter Plugin

To convert intrusion prevention system (IPS) rules to custom PAN-OS threat signatures, download and install the IPS Signature Converter on Panorama ™ .

If you have a Panorama high availability (HA) configuration, repeat the installation process on each Panorama peer. When you install the plugin on Panorama peers in an HA pair, install the plugin on the passive peer first and then on the active peer. After you install the plugin on the passive peer, that peer will transition to a non-functional state. When you install the plugin on the active peer, the passive peer will return to a functional state.

Before you install the plugin, ensure that you have the correct version requirements and the latest Applications and Threats content updates .

STEP 1 \|	Select Panorama > Plugins .
STEP 2 \|	Enter ips_signature_converter in the search bar.
STEP 3 \|	Refresh ( ) to retrieve the latest updates.
STEP 4 \|	Download (ACTIONS column) the plugin.
STEP 5 \|	Select the version of the plugin that you want to install.
STEP 6 \|	Install the plugin (ACTIONS column).

CLI Quick Start

See the list of basic commands below for the intrusion prevention system (IPS) Signature Converter plugin on Panorama ™ . For more information about how to use the command line interface (CLI), see how to Get Started with the CLI .

To do this...

Start here...

Convert, import, check performance impact, and configure the properties of signatures

request plugins ips-signature-converter

Set the type, default action, or severity of a signature

request plugins ips -signature-converter set-

properties <line numbers>

View information about your converted signatures

show plugins ips -signature-converter

Delete all signatures (does not delete signatures that you imported to Panorama)

clear plugins ips -signature-converter all

Troubleshooting the IPS Signature Converter

If your rules fail to convert, use the following command in the Panorama command-line interface (CLI) to see a detailed summary of the failure:

admin@M-200-49> tail follow yes lines 1 plugins- log plugin_ips_signature_converter.log

The output consists of a list of the logs for each rule and a final summary of the status of their conversion.

Rule Logs

The output first lists the logs for each rule that you submitted for conversion. Each log contains the following fields.

Field	Values
Line	The line number of the rule.
result	• True —The rule converted successfully. • False —The rule failed to convert.
type	• normal —The rule contains a pattern to search packet payloads. • edl —The rule is a list of suspect URLs, IP addresses, or domains.
hash	A unique identifier for each rule that successfully converted. This output is None if conversion failed.
msg	Details about a signature with a result of failed or warned .

Summary

After listing the logs for each rule, the output displays a summary of the conversion results.

Field	The number of rules that...
Total	Were submitted for conversion.
Succeed	Converted successfully.

Field	The number of rules that...
Warned	Converted successfully but contain minor syntax errors or that pose a risk, such as high performance impact or false-positive rate.
Skipped	Converted successfully and share a common vulnerabilities and exposures (CVE) identifier with a signature that already exists in the Palo Alto Networks Threat Vault .
Duplicated	Were repeated in the submission.
Failed	Failed to convert.