Академический Документы
Профессиональный Документы
Культура Документы
Tech Note
PAN-OS 5.0
When deciding you want to create a custom signature, you’ll almost always start out with just a packet-capture. For that
reason, screenshots of Wireshark captures were used when possible to help provide a simple reference when trying to
understand what each context provides.
Qualifiers: This context can use FTP command (Table 1) and FTP vendor ID (Table 2) qualifiers to limit signatures to
specific FTP commands and known FTP clients.
http-req-content-length
Description: Content length of a HTTP request
Example: This context provides the length of the text highlighted in yellow.
Qualifiers: This context can use HTTP header field (Table 3) and HTTP method (Table 4) qualifiers to limit signatures to
HTTP headers with specific values for select header fields and for specific HTTP methods.
http-req-param-length
Description: Length of the URL query string
Example: This context provides the length of the text highlighted in yellow (everything after the ‘?’).
Example: This context provides the length of the text highlighted in yellow.
Qualifiers: This context can use the HTTP method (Table 4) qualifier to limit signatures to HTTP headers with specific
HTTP methods.
http-req-uri-tilde-count-num
Description: Number of “~” characters in the path (same path that http-req-uri-path provides). The following encoded
characters are included in this context:
• %3A
• %u003A
• %u0589
• %u2236
• %u007E
• %u0303
• %u223C
• %uFF5E
Qualifiers: This context can use the HTTP method (Table 4) qualifier to limit signatures to HTTP headers with specific
HTTP methods.
http-rsp-code
Description: The number corresponding to the HTTP response code
http-rsp-total-headers-len
Description: Length of the HTTP response headers, not including the HTTP status banner
Example: This context provides the length of the text highlighted in yellow.
imap-req-cmd-param-len
Description: Total length of all parameters of an IMAP command
Example: This context provides the length of the text highlighted in yellow.
Qualifiers: This context can use the IMAP command (Table 5) qualifier to limit signatures to specific IMAP commands.
Example: This context provides the length of the text highlighted in yellow.
Qualifiers: This context can use the IMAP command (Table 5) qualifier to limit signatures to specific IMAP commands.
imap-req-param-len-from-second
Description: Total length of all parameters of an IMAP command, not including the first
Example: This context provides the length of the text highlighted in yellow.
Qualifiers: This context can use the IMAP command (Table 5) qualifier to limit signatures to specific IMAP commands.
smtp-req-helo-argument-length
Description: Length of the argument to the SMTP “HELO” command
Example: This context provides the length of the text highlighted in yellow.
Example: This context provides the length of the text highlighted in yellow.
smtp-req-rcpt-argument-length
Description: Length of the argument to the SMTP “RCPT TO” command
Example: This context provides the length of the text highlighted in yellow.
dns-req-authority-section
Description: Authority section if found in a DNS request (normal DNS requests should not have an authority section).
dns-req-section
Description: This context matches against the DNS questions of a DNS query, so that patterns can be written against
one or more domains in a given DNS query. It is a direct pattern match against the format of a DNS query, so patterns
must adhere to the DNS question structure. A recommended approach to create a DNS pattern is to capture the DNS
request with Wireshark and copy the DNS Request field (make sure to remove the ending period in the request).
Example 1: The following example illustrates how to build a signature for a DNS query for the domain
www.bayareagamers.com.
Pattern Description
\x Indicates this pattern is a hex pattern match
03 Indicates that the next 3 bytes are to be matched
77 77 77 "www"
[The period in the domain name is omitted.]
10 Indicates that the next 16 bytes (10 hex) are to be
matched
74 68 65 62 61 79 61 72 65 61 67 61 6d 65 72 73 "thebayareagamers"
03 Indicates that the next 3 bytes are to be matched
63 6f 6d "com"
\x Ends hex pattern match
dns-rsp-addition-section
Description: Additional records sections of a DNS response
dns-rsp-authority-section
Description: The complete authority section of a DNS response
dns-rsp-ptr-answer-data
Description: FQDN for a type PTR DNS response
email-headers
Description: All email headers and the plain text email body. Attachments are not included in this context as they are
provided elsewhere.
Hey,
Kelly
R0lGODlhFAAWAKEAAP///8z//wCZMwAAACH+TlRoaXMgYXJ0IGlzIGluIHRoZSBwdWJsaWMgZG9t
YWluLiBLZXZpbiBIdWdoZXMsIGtldmluaEBlaXQuY29tLCBTZXB0ZW1iZXIgMTk5NQAh+QQBAAAB
ACwAAAAAFAAWAAACY4yPqTrtm5qYtMEGBNiaWzRMHEVlwgBm5lieR7hqsiqjQSjG3I7C9LgznXw5
nUwjAaqEIiSs2Vl2nKWglIfbsHJTV3bJJNkGLG10arspwZ20mlYVum++8PBCBn8gBseDD7hQAAA7
Example: Using a cli hex-editor named xxd, we can view the header of the flash file.
th
Every byte after the 9 is provided by this context. Only the first 50 bytes were printed here as an example.
file-html-body
Description: Full body of a HTML file, minus the first 8 bytes as they’re reserved for the header
th
Example: xxd is a cli-based hex editor; every byte after the 8 is provided by this context. Only the first 50 bytes were
printed here as an example.
Example: Using a cli based hex editor named xxd, we can view the first 4 bytes of the java file:
th
Every byte after the 4 is provided by this context. Only the first 25 bytes were printed here as an example.
file-mov-body
Description: Full body of a MOV file, minus the first 8 bytes as they’re reserved for the header
th
Example: xxd is a cli-based hex editor; every byte after the 8 is provided by this context. Only the first 50 bytes were
printed here as an example.
file-office-content
Description: Full body of a Microsoft Office Document file, minus the first 8 bytes as they’re reserved for the header
th
Example: xxd is a cli-based hex editor, every byte after the 8 is provided by this context. Only the first 50 bytes were
printed here as an example.
file-riff-body
Description: Full body of a RIFF file, minus the first 8 bytes as they’re reserved for the header
th
Example: xxd is a cli-based hex editor; every byte after the 8 is provided by this context. Only the first 50 bytes were
printed here as an example.
file-swf-body
Description: Full body of a SWF file, minus the first 8 bytes as they’re reserved for the header
th
Example: xxd is a cli-based hex editor; every byte after the 8 is provided by this context. Only the first 50 bytes were
printed here as an example.
ftp-req-params
Description: Parameters following an FTP command
Qualifiers: This context can use FTP command (Table 1) and FTP vendor ID (Table 2) qualifiers to limit signatures to
specific FTP commands and known FTP clients.
ftp-rsp-banner
Description: FTP welcome banner shown before authentication
gdbremote-req-context
Description: GDB is a process debugger that has the ability to debug across the network. This context provides the
request data.
Example: 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.
Example: 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
Description: Everything in the GIOP request
http-req-headers
Description: HTTP request header, not including the method, path, HTTP version, or host as those are provided
elsewhere.
Qualifiers: This context can use HTTP header field (Table 3) and HTTP method (Table 4) qualifiers to limit signatures to
HTTP headers with specific values for select header fields and for specific HTTP methods.
http-req-host-header
Description: Host field in a HTTP request header
Qualifiers: This context can use HTTP header field (Table 3) and HTTP method (Table 4) qualifiers to limit signatures to
HTTP headers with specific values for select header fields and for specific HTTP methods.
Example: This context provides the full body. I followed the TCP stream in Wireshark and only chose a portion of the
body for the signature to match.
Qualifiers: This context can use the HTTP method (Table 4) qualifier to limit signatures to HTTP headers with specific
HTTP methods.
http-req-mime-form-data
Description: MIME header data in the body of an HTTP request, not including embedded file contents
Qualifiers: This context can use the HTTP method (Table 4) qualifier to limit signatures to HTTP headers with specific
HTTP methods.
http-req-uri-path
Description: Path in a HTTP request header (up to and including the ‘?’).
Qualifiers: This context can use the HTTP method (Table 4) qualifier to limit signatures to HTTP headers with specific
HTTP methods.
imap-req-cmd-line
Description: IMAP command used.
imap-req-first-param
Description: First parameter to an IMAP command
Qualifiers: This context can use the IMAP command (Table 5) qualifier to limit signatures to specific IMAP commands.
irc-req-params
Description: Argument after the actual IRC command and space
irc-req-prefix
Description: Data before an IRC command, typically used to indicate the true origin of a message
Example: You can see by following the TCP stream in Wireshark that there is data in between the IRC commands. It
appears this message was Proxied.
jpeg-file-scan-data
Description: This context provides all of the scan data within a jpeg file.
jpeg-file-segment-data
Description: This context provides all of the segment data within a jpeg file.
ms-ds-smb-req-share-name
Description: Full path to a file that is read or written using SMB
msrpc-req-bind-data
Description: Data payload of a MS RPC Bind request
Example: 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 below.
pe-dos-headers
Description: This context provides the DOS MZ header and the DOS stub. These are located in the first 64 bytes of the
PE file.
PE File Structure
DOS MZ Header + DOS Stub – first 64 bytes
PE File Header – next 20 bytes
PE Optional Header – next 224 bytes
PE Section Header – next 40 bytes each
PE Body Data – Rest of the file
pe-file-header
th
Description: This context provides the PE file header. This is 20 bytes long and starts at the 65 byte of the PE file.
PE File Structure
DOS MZ Header + DOS Stub – first 64 bytes
PE File Header – next 20 bytes
PE Optional Header – next 224 bytes
PE Section Header – next 40 bytes each
PE Body Data – Rest of the file
PE File Structure
DOS MZ Header + DOS Stub – first 64 bytes
PE File Header – next 20 bytes
PE Optional Header – next 224 bytes
PE Section Header – next 40 bytes each
PE Body Data – Rest of the file
pe-section-header
Description: This context provides the section headers for a PE file. These are 40 bytes each. Some typical sections with
headers are “idata”, “rsrc”, “data”, “text”, and “src”. However, each PE file may not include each section and they’re not
guaranteed to be in any specific order.
PE File Structure
DOS MZ Header + DOS Stub – first 64 bytes
PE File Header – next 20 bytes
PE Optional Header – next 224 bytes
PE Section Header – next 40 bytes each
PE Body Data – Rest of the file
pe-body-data
Description: This context provides the body data of a PE file. This includes everything inside the file sections themselves.
The body data is located after the headers mentioned above.
PE File Structure
DOS MZ Header + DOS Stub – first 64 bytes
PE File Header – next 20 bytes
PE Optional Header – next 224 bytes
PE Section Header – next 40 bytes each
PE Body Data – Rest of the file
rtsp-req-headers
Description: Full RTSP request headers, not including the command line
Qualifiers: This context can use the RTSP method (Table 6) qualifier to limit signatures to specific RTSP methods.
Qualifiers: This context can use the RTSP method (Table 6) qualifier to limit signatures to specific RTSP methods.
smtp-req-argument
Description: Argument of a SMTP command
Qualifiers: This context can use the SMTP method (Table 7) qualifier to limit signatures to specific SMTP methods.
smtp-rsp-content
Description: SMTP server response content
ssh-rsp-banner
Description: SSH banner of the server, not including comments
ssl-req-certificate
Description: Certificate request message of a SSL negotiation when initiated from the client
ssl-req-random-bytes
Description: Random bytes field in the SSL client hello
Example: This value is already hexadecimal; you’ll need to write the pattern in your signature as such (enclosed in \x).
ssl-rsp-certificate
Description: Certificate response message of a SSL negotiation from the server
telnet-req-client-data
Description: All telnet data for traffic originating from the client
telnet-rsp-server-data
Description: All telnet data for traffic originating from the server
unknown-rsp-tcp-payload
Description: Full TCP payload for unknown TCP traffic originating from the server
unknown-req-udp-payload
Description: Full UDP payload for unknown UDP traffic originating from the “client”, which is the initiator of UDP
communications
unknown-rsp-udp-payload
Description: Full UDP payload for unknown UDP traffic originating from the “server”, which is opposite the “client”
Syntax Description
. Match any single character
? Match the preceding character or expression 0 or 1 time; the general expression MUST be inside a pair of parentheses, e.g. (abc)?
* Match the preceding character or expression 0 or more times; the general expression MUST be inside a pair of parentheses, e.g. (abc)*
Match the preceding character or regular expression 1 or more times; the general expression MUST be inside a pair of parentheses, e.g.
+ (abc)+
Equivalent to "or" as in this example: ((bif)|(scr)|(exe)): match “bif”, “scr” or “exe”. Note that the alternative substrings MUST be in
| parentheses
- Used to create range expressions as in this example: [c-z]: match any character between c and z INCLUSIVE
^ Match any except, as in this example: [^abz]: match any character but a, b, or z
Min/Max number of bytes, as in this example: .{10,20}: match any string that is between 10 and 20 bytes. Note: Must be directly in front of
{} fixed string of at least 7 bytes, and only supports “.”.
\ To perform a literal match on any one of the special characters above, it MUST be escaped by preceding them with a ‘\’ (backslash)
& & is a special character, so to look for the "&" in a string you must use "&" instead
3. The “Pattern” field in the condition window has a limit of 127 characters, but what if your pattern is
longer?
o The solution is to ‘AND’ them together as figure 5 shows. You can even leave “Ordered Condition Match”
selected so it must see them in order so you’re closer to matching the full string.
Figure 4 – Too many characters in the “Pattern” field Figure 5 – String split in half with ‘AND’
o Another work-around that is possible in some patterns is to just write out the ‘.’ (dot) characters instead of
using the repetition. ‘{4}’ would become ‘….’ and there is no repetition requirement.
Figure 4.1 – Invalid because only 4 bytes, ‘BBBB’ follow the repetition ‘.{4}’
o To fix this, you need to increase the size of at least one of the strings to 7 bytes or more. Figure 5.2
shows a fixed signature by changing “net” to “networks” which is at least 7 bytes.
Figure 5.1 – Invalid because there are two strings less than 7 bytes separated by a DFA
Figure 5.2 –Valid because there is only 1 string less than 7 bytes now surround the repetition element
Qualifier - Qualifiers can be used to further refine and limit the scope of a custom signature, and are context-dependent.
They often limit the scope to an individual command or header type.
Aggregation Criteria – This is a setting found in combination signatures used to granularly aggregate the number of hits
per second. If for example you wanted to alert only after 25 POSTs have been seen in 60 seconds and only when going to
a certain destination IP, you would set the aggregation criteria to “destination”. Only a POST to that destination would
count towards your limit of 25 POSTs. You can also choose “source” or “source-and-destination” to aggregate the number
of hits differently.
Context – After the decoder decodes the protocol or file, it separates each portion into a context. Each context provides
certain portions of that file or protocol. We then specify the context where we expect our pattern to be.
Ordered Condition Match – If your signature has multiple conditions and the order of which the conditions are seen is
important, you can enable this setting. (The list of conditions uses the top-down approach, meaning it matches in order
from top to bottom.)
And / Or Conditions – Just like any other Boolean conditions, “And” matches the first condition and the second condition
and so on. “Or” matches the first condition or the second condition. “Or” conditions broaden the search, while “and”
conditions narrow the search.
Direction – Found in the configuration tab of a custom signature. This indicates whether the threat is assessed from the
client to server, server to client, or both.
Affected System – Found in the configuration tab of a custom signature. Indicates whether the threat involves the client,
server, either, or both. This applies to vulnerability signatures, but not spyware signatures.
1. First, you’ll need to go to the Objects tab -> click Vulnerability under the Custom Signatures section -> and click
“Add”.
2. The only required fields are Threat ID, Name, Severity, and Direction. Ensure the Threat ID is between 41000-
45000.
3. Next, you’ll need to click the “Signatures” tab. We will cover combination signatures in a later example. For now,
leave it at standard. Click “Add” at the bottom of the window to bring up the “Standard” window.
4. We start by giving this signature a name. This example will only have one condition; therefore we can ignore the
Ordered Condition Match setting. Also, we only want to alert on a single transaction and not the full session, so
we will leave the scope at “Transaction”. Finally, click “Add And Condition”.
5. Since we’re looking for the exact value of “404”, choose “Equal To” from the “Operator” drop-down menu. You’ll
notice that the entries in the “Context” drop-down depend on your “Operator” selection. If for example you were to
choose the operator “Pattern Match”, it would contain contexts based on a pattern, not an integer. Knowing this,
select the “http-rsp-code” context from the “Context” drop-down menu. Next, enter “404” in the “Value” field.
6. The completed condition should look like “figure 6”. Click “OK” on each of the signature windows, commit, and
test your new signature.
You can use any hex-editor to view the hex contents of the file. I chose to go with xxd, a cli-based editor. By reading the
“file-flv-body” context example in the contexts section above, we know that this context provides every byte after the
header. Everything in bold is within the context, so we can write a pattern using those bytes.
We pick ‘0a6f 6e4d 6574 61’ as our value to match on. Keep in mind that every two alphanumeric values represent one
byte, so this pattern just meets our 7-byte requirement. Let’s pretend we’ve identified these bytes as malicious shell-code
that we don’t want passing through our firewall. Let’s now walk through the process of creating the signature from start to
finish:
1. Add a new custom vulnerability signature and fill out the mandatory fields.
2. Click the signatures tab and click “Add” to bring up the “Standard” window.
3. Fill in the “Signature Name” field and leave the scope as transaction. We only have one condition, so we can
leave “Ordered Condition Match” alone. Click “Add And Condition”.
4. Choose “Pattern Match” as the operator, then find “file-flv-body” from the “Context” drop-down, and enter the
pattern we found earlier with ‘\x’ before and after the pattern to indicate we’re matching hexadecimal. (See Figure 4
below)
5. Click “OK” on each of the signature windows, commit, and test your new signature.
1. Create a new Custom Vulnerability Signature and fill out the needed fields in the “Configuration” tab.
2. Go to the “Signatures” tab, leave “Standard” selected and click “Add” to bring up the “Standard” window.
3. Enter a signature name, leave the scope as “Transaction”; again we only have one condition so the “Ordered
Match Setting” can be ignored.
4. Click “Add And Condition” for the condition window to open. Here, choose “Pattern Match” from the “Operator”
drop-down menu since we’re matching on a string. Select “http-req-uri-path” from the “Context” drop-down menu
and enter the pattern “wp\-login\.php” (without the quotes as seen in figure 4). We escape the ‘–‘ and ‘.’ characters
with backslashes since they’re part of the regex library and we want a literal match on those characters.
5. Last, we’re going to click “Add” on the condition window from step 4 to add a qualifier to the signature. Choose
“http-method” as the qualifier and set the value to “POST”. This way, our pattern only matches if it’s found inside
of a HTTP POST message.
6. Click “OK” on each signature window, commit, and test the signature.
1. Create a new custom signature and fill out the needed fields in the “Configuration” tab.
2. Click the signature tab, choose “Combination” and click “Add And Condition”.
3. In the condition window, you first name the condition. Then choose the threat ID that will be used. Here we chose
Threat ID “42100” which is the WordPress login signature we created in the last example.
4. Click the “Time Attribute” tab. These settings are what make this a combination signature. We can monitor the
matches on this signature and only alert or drop if the number of hits reaches our maximum value within our
defined amount of seconds. You’ll also want to choose your “Aggregation Criteria”.
5. Click “OK” on each of the signature windows, commit, and test the signature.
Revision History
Date Revision Comment
July 26, 2013 A First release of this document.