Signature Format

Each signature has nine fields. Sometimes the last field can contain two extra fields making the total number of fields as large as eleven. Each field will be listed and all of their values discussed. Here is an example 'dragon.sigs' rule which searches for the CGI-BIN PHF attack:

T D A S 10 20 80 WEB:CGI-PHF get/20/2fcgi-bin/2fphf

| | | |  |  |  |      |                |
| | | |  |  |  |      |                |
| | | |  |  |  |      |                SEARCH STRING
| | | |  |  |  |      EVENT NAME
| | | |  |  |  PORT
| | | |  |  |
| | | |  |  COMPARE BYTES 
| | | |  |
| | | |  DYNAMIC LOG
| | | |
| | | BINARY OR STRING
| | |
| | PROTECTED NETWORKS
| |
| DIRECTION
|
PROTOCOL

FIELD 1: PROTOCOL

The first argument specifies the particular IP protocol to search through. Signatures can be applied against any IP protocol. The characters 'T', 'U' and 'I' have been reserved to specify TCP, UDP and ICMP traffic. To specify IP protocols other than these three, simply use the protocol number. IP Protocols other than UDP and TCP will be reconstructed if they are fragmented and the FRAG_REBUILD keyword is active, but streams of data will not be concatenated. At this time, there is no mechanism to search both UDP and TCP protocols with a single signature. Separate signatures must be used. The above PHF signature could have been rewritten with a '6' instead of a 'T' as the first character like this if desired:

6 D A S 10 20 80 WEB:CGI-PHF get/20/2fcgi-bin/2fphf

FIELD 2: DIRECTION

The second argument specifies to search for packets 'going to' or 'originating from' a network server. For example, email attacks on port 25 flow 'to' the server. Events such as telnet login failures happen on port 23, but come 'from' a server. Consider port 80. If we are looking for web server attacks, we probably wish to inspect port 80 packets going 'to' the server, i.e. with a destination port of 80. If we were interested in malicious JAVA downloads, we would search for packets with a source port of 80.

Use a 'D' character to define packets that are destined for a server and an 'S' character for packets that have a server source port. If the signature is ambiguous, use an 'A' for any direction. And finally, if the signature requires that both the source and destination port match, choose 'B' for both. The 'B' selection is useful for identifying DNS to DNS traffic and high port to high port complex rule traffic.

A 'ANY'         Either port must match
B 'BOTH'        Both ports must be equal to the matched port
D 'DESTINATION' The destination port must match
S 'SOURCE'      The source port must match

The PHF example above specifies 'D' for destination because we only want to search packets that are going to a web server.

FIELD 3: PROTECTED NETWORKS (and FOLLOW ON traffic)

Dragon Sensor can apply specific rules based on how each packet relates to the PROTECTED networks. For example, we may not care about SNMP traffic inside our networks, but would be very interested in anyone sending that kind of traffic from the Internet. There are six settings for this third argument:

A 'ALL'      All traffic
T 'TO'       Not from protected networks and going to them
F 'FROM'     Not to protected networks and leaving from them
I 'INSIDE'   From and to protected networks
X 'EXTERIOR' Not from and not to protected networks
D 'DYNAMIC'  Traffic occurring in 'follow-on' traffic from a previous event

The example above uses an 'A' to watch all traffic. This detects PHF attacks on any server regardless if it is on a protected network or not. To detect attacks only from sources outside the protected networks, a 'T' could have been specified.

The 'D' setting is the most complex type of signature. When an event such as a PHF attack occurs, it is followed by several packets that complete the sessions. Maybe the attack fails. Maybe the attack works. Regardless, this follow-on data is worth analyzing and a signature designed specifically to look at this data is very useful. Consider the following signature:

T S D B 0 0 80 FAIL:WEB-FORBIDDEN 403/20Forbidden

This signature looks for generic responses to web servers which have returned an error from a page which was attempted access. This type of traffic probably occurs a lot on any modern web server farm simply due to stale URLs and poorly managed web servers. However, consider the fact that previous to this event, the request may have been for a URL looking for the PHF attack. In this case, applying this 'FAIL:WEB-FORBIDDEN' rule to the follow on traffic from the web server and attacker is very interesting. Without these rules, the PHF attack may be logged an alerted, but it requires much more raw analysis to determine the success or failure of the attack. Consider the following log from a FTP server which has been logged into by a 'root' user:

02:57:54 [T] 95.23.135.1 25.25.79.151 [FTP:USER-ROOT](tcp,dp=21,sp=3106)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---A----)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---AP---)
02:57:54 [T] 95.23.135.1 25.25.79.151 [DYNAMIC-TCP] (tcp,sp=3106,dp=21,flags=---AP---)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---AP---)
02:57:55 [T] 95.23.135.1 25.25.79.151 [DYNAMIC-TCP] (tcp,sp=3106,dp=21,flags=---A----)

All of the follow-on packets marked with DYNAMIC-TCP listed, but in order to know what is happening with this session, we would have to use the mksession tool or inspect each packet manually. Consider if we had added the following signature to the dragon.sigs file:

T S D B 10 200 21 FTP:ROOT-LOGGED-IN 230/20User/20root/20logged/20in

This signature includes a 'D' for the third field which looks for port 21 DYNAMIC data. The search string is a positive login banner generated by 'wu-ftd 2.4.2' and is used as an example. With this signature running, we would get the following output logged:

02:57:54 [T] 95.23.135.1 25.25.79.151 [FTP:USER-ROOT](tcp,dp=21,sp=3106)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---A----)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---AP---)
02:57:54 [T] 95.23.135.1 25.25.79.151 [DYNAMIC-TCP] (tcp,sp=3106,dp=21,flags=---AP---)
02:57:54 [F] 25.25.79.151 95.23.135.1 [DYNAMIC-TCP] (tcp,sp=21,dp=3106,flags=---AP---)
[FTP:ROOT-LOGGED-IN]
02:57:55 [T] 95.23.135.1 25.25.79.151 [DYNAMIC-TCP] (tcp,sp=3106,dp=21,flags=---A----)

FIELD 4: BINARY OR CASE INSENSITIVE SEARCH

Search strings can be case insensitive for the printable character range. For example, most web servers will respond to 'GET' requests as well as 'get' requests. Dragon Sensor administrators could use two different rules to search for this, but there is a better way. By specifying an 'S' as the fourth argument, Dragon Sensor will search for all cases of the string regardless of upper or lower case characters.

It is important for these strings that all printable characters be in lower case. Dragon Sensor converts the data to be searched to lower case and then attempts to match it with the rule's search string. If the rule's search string has upper case letters, then the strings will never match. This string will never match because of the capital 'G'.:

6 D A S 10 20 80 WEB:CGI-PHF Get/20/2fcgi-bin/2fphf

WEBCONVERT and TELCONVERT processing only works on rules that are written to search for complex web ports with string ('S') searches. The PHF signature may be rewritten to make use of the complex web rules by substituting a 'W' for port 80. The character 'W' is defined in the COMPLEX web rules in the dragon.net file and usually is associated with ports 80, squid proxies and 8080. Here is the rewritten rule:

6 D A S 10 20 W WEB:CGI-PHF get/20/2fcgi-bin/2fphf

To use binary comparison, specify a 'B'. This will search for an exact match of the search string, including all unique uppercase and lowercase characters.

FIELD 5: DYNAMIC LOG

When a hit on a particular rule occurs, Dragon Sensor can be told to collect additional packets between the source and destination IP addresses of the event. For example, for a Telnet login failure, Dragon Sensor could be specified to grab the next 50 packets between the Telnet server and the IP address that had the login failure. This allows a greater level of analysis to be applied to a security event. It is recommended not to collect more than 100 packets per event for performance reasons. The amount of packets to collect is specified as an integer. The above example collects ten packets after each PHF attempt. It's important to note that the amount of DYNAMIC collection is a fixed resource and uses the 'least recently used' principal. That is, only the latest attacks have their additional traffic logged.

FIELD 6: BYTES TO COMPARE

As packets are collected by Dragon Sensor, it needs to know how far into each packet it should search for a match for this signature. This assumes that the interesting data is usually closest to the beginning of the packet. For example, URL web addresses are at the beginning of each packet. By telling Dragon Sensor to only look at the first 40 bytes, we avoid searching unnecessary portions of the packet. However, searching entire packets may be the right choice for certain types of attacks such as buffer overflows because their data signatures tend to be at the end of most packets. The number of bytes to compare is expressed as an integer. Use a zero to tell Dragon Sensor to search the entire packet.

In our example above, we tell Dragon Sensor to search the first twenty bytes of the packet for a match. It is not necessary to attempt to get this number exactly the same length as the search string. There seem to be 16 characters in the example search string. As long as the number of compare bytes is equal to or slightly greater than the length of the search string, Dragon Sensor performance has been optimized.

If an attempt to match a signature fails because the search signature is longer than the captured data, the collected data gets sent to a session reconstruction engine. As more data arrives, it to gets sent to the reconstruction engine until a complex set of rules determines that the collected data should be reevaluated for matches with the dragon.sigs rules.

FIELD 7: PORT

For UDP or TCP signatures, a port value is used to specify which particular protocol to apply the signature to. To specify a port value, use the numeric representation of the protocol. In other words, use 25 for SMTP, 80 for HTTP, 6000 for X Windows and so on. To specify more complex ranges of ports, please review the COMPLEX port format specified in the dragon.net file. These complex port rules are identified with capital letters such as 'X' and 'W'. Simply placing those letters in this part of a signature applies the complex rule to the signature. This field is ignored for protocols other than UDP and TCP.

FIELD 8: NAME

The name of the signature that Dragon Sensor is searching for is expressed as a string. There can be any combination of characters, but there can not be any spaces. The 'dragon.sigs' examples have a loose organization to naming attacks, but there is no reason that these can not be modified. There is no limit to the size of the names either, but smaller lengths take less memory and result in better performance. The above example uses a name of 'WEB:CGI-PHF'. We could have just as easily used 'STUPID-WEB-HACK-PHF' or 'PHF-SCRIPT-KIDDY'.

FIELD 9: SEARCH STRING

Dragon Sensor has several string definition features which allow for creation of powerful, yet efficient pattern searches. The most basic string definition is to simply type a string of letters and numbers without any spaces such as this:

This-is-a-test-string

That really isn't to useful though because we can't specify any non-printable characters like carriage returns or null bytes. To get around this, we can use the '/' character as an escape character to specify two alphanumeric values which represent a hex number. The hex ASCII code for '-' is 0x2d which means that the above example could be represented like:

This/2dis/2da/2dtest/2dstring

In order to search for a '/' character, simply use the hex value for '/' which is 0x2f. Here is a string that searches for "/cgi-bin/phf":

/2fcgi-bin/2fphf

To drive the point home, we can use the 0x20 character to represent a space. Here is "see spot run" followed by a newline.

see/20spot/20run/0a

WILD CARDS

Starting in Dragon Sensor 4.1, there are four available wildcard characters. These are the question mark, the pound sign, the dollar sign and the asterisk. All wildcards represent a single byte which may be used to represent the following ranges:

  ? - Any byte
  * - Any printable character (Alpha-numerics, /n, /r, etc..)
  $ - Any non printable character (negative of printable character set)
  # - Any number

Because of this protocol, attempting to search for these bytes (?,*,$,#) in normal traffic requires that the corresponding hex escape code be used. Here is a table for quick access:

  ? - 0x3f
  * - 0x2a
  $ - 0x24
  # - 0x23

For example, the question mark can be used as a single character wildcard. This wildcard will match anything regardless of what the value is. Something has to be there though. If the amount of captured data ends before a wildcard matches, then no match occurs. To search for a question mark, use the hex code of 0x3f. Here is the above example where we replace spot with any four-letter word.

see/20????/20run/0a

COMBO STRINGS

Searching for this string and any four letter word followed by "/20run/0a" may be useful, but combining two different strings is even more useful. Dragon Sensor's signatures can handle this by specifying an initial string and then a second string separated by a comma. If we want to search for the pattern "see/20" and then the pattern "/20run/0a" without any regard for the total number of bytes or content between the two strings, then the signature syntax would be as follows:

see/20 , run/0a

This is very useful as one could write a signature which looks for any "/cgi-bin/" query followed by interesting keywords such as "/etc/passwd", "/bin/mail" or "xterm -d ???". Here are these examples in Dragon Sensor signature format:

/2fcgi-bin/2f    ,   /2fetc/2fpasswd
/2fcgi-bin/2f    ,   /2fbin/2fmail
/2fcgi-bin/2f    ,   xterm/20-d???

BUFFER OVERFLOWS

Another Dragon Sensor signature format is designed to look for buffer overflows in ASCII style protocols. Protocols such as FTP and POP have an ASCII based communication such that users tend to log in with printable characters in response to prompts. This Dragon Sensor signature format can look for keywords that specify the beginning of a login string followed by an unusually large string of data. For example, in FTP a user specifies their username with a command of "USER", which is followed by a space, which is then followed by a username. Most usernames are eight bytes long so searching for of usernames larger than 256 bytes could show some denial of service attacks and possibly some buffer overflows. The signature format specifies the initial search string, followed by a greater than sign followed by a number of bytes. Here is an example:

USER/20 > 256

This searches for the string "USER/20" and then searches the remaining data for a newline. If more than 256 characters are found an event is recorded. Here is a complete Dragon Sensor signature which looks for extra long usernames during FTP command sessions:

T D A B 10 0 21 FTP:LONG-UNAME USER/20 > 256

NEGATIVE SIGNATURES

Dragon Sensor can be configured to search for signatures based on the absence of data. The original request for this feature originated from an electronic commerce web site. All of their URLs were simple requests for '/' , or a web resource which had their company name in the URL. A typical URL may have included something like 'www.company.com/companyname/index.html'. Any web queries which were not to '/' or did not contain '/companyname/' were suspect.

Starting in version Dragon Sensor 4.0i, the concept of the negative signature was introduced. This signature format simply looked for an initial string, and then if it was not immediately followed by one or more different strings, then an event was logged. In the company's example above, the resulting string would look like this:

T D A B 30 50 80 WEB:MISMATCH GET/20 ! ( /2f/20 , /2fcompanyname/2f )

This string basically alerts on any string going to a web server on port 80 which contains 'GET ' that is not immediately followed by a '/ ' (slash and space) or by a '/companyname/'. The initial 'GET ' is required to match before the subsequent negative matches are attempted. If we wanted to make searching faster, we could modify the first negative signature component from '/2f/20' to '/2f/20HTTP'. This is a much longer string which conforms to the HTTP standard.

The follow-on data is matched exactly on the first byte after the initial string. In the above example, if there was another character between the space of the 'GET ' and the first slash of the '/companyname/' string, then the event would not match. That is, the event would be logged because it was not an exact match.

Another use of this type of string is to look for strange FTP login names on anonymous FTP servers. Typically, the users 'ftp' and 'anonymous' are used to log into an FTP server set up for public usage. A signature which would log for users other than 'ftp' and 'anonymous' would look like:

T D A B 30 50 21 FTP:NOT-ANON USER/20 ! ( ftp , anonymous )

The possibilities with negative signatures are numerous. Another area of usage is for looking at various network services which have gone out of spec. For example, one could write a negative signature which looked for web servers that were Windows NT IIS, but only version 3 and version 4. Versions 2 and 5 would be alerted on in this case as being to old, or to new.