mozdev.org

Firekeeper

resources:

Firekeeper Rules

This documents describes Firekeeper rule format. There is also a rule writing tutorial available.

... Introduction ...

Firekeeper rules are based on Snort rules but are much simpler. Snort is a general purpose Intrusion Detection System that requires much more powerful rules description language than Firekeeper which purpose is only to detect browser based attacks attempts. Also some keywords supported by Snort that can be useful for Firekeeper are not yet implemented. Firekeeper rules have to be written in a single line. Each rule has two sections: Bellow is a sample Firekeeper rule. String 'alert' is a rule header, rule options are enclosed in parenthesis.
alert (msg:"Content-Disposition CLSID command attempt";
       headers_content:"Content-Disposition|3A|"; nocase;
       headers_re:"/^Content-Disposition\x3a[^\r\n]*\{[\da-fA-F]{8}
                   (-[\da-fA-F]{4}){3}-[\da-fA-F]{12}\}/smi";
       reference:bugtraq,9510; reference:cve,2004-0420;
       reference:url,www.microsoft.com/technet/security/bulletin/ms04-024.mspx;
       fid:2589; rev:3;)
Take a look at some other sample rules.

... Header ...

Rule header defines what action to take when rule matches. Currently three actions are supported:

... Options ...

Rule options allow flexible description of a HTTP(S) response that should trigger rule action. They also allow to add additional information to a rule useful for the user to learn more about attack described by a rule and to manage rules in a convenient way.

Payload detection options

url_content, headers_content, body_content

These are the most important Firekeeper rule options that allow search for a specified content in HTTP response URL, headers and body. They are similar to Snort content option. Content option description from the Snort manual:

"Whenever a content option pattern match is performed, the Aho & Corasick pattern match function is called and the (rather computationally expensive) test is performed against the packet contents. If data exactly matching the argument data string is contained anywhere within the packet's payload, the test is successful and the remainder of the rule option tests are performed. Be aware that this test is case sensitive.

The option data for the content keyword is somewhat complex; it can contain mixed text and binary data. The binary data is generally enclosed within the pipe (|) character and represented as bytecode. Bytecode represents binary data as hexadecimal numbers and is a good shorthand method for describing complex binary data.

Note that multiple content rules can be specified in one rule. This allows rules to be tailored for less false positives.

Also note that the following characters must be escaped inside a content rule:

: ; \ " 
"
Examples of *_content options:
body_content:"document.domain|28|";
body_content:"window.open|28 22|readme.eml|22|;
headers_content:"application/smi";
url_content:".emf";
Snort '!' flag that inverts match is not supported.

Note: To achieve the best performance each rule should have at least one content option which should be as long as possible.

nocace modifier
After each *_content option 'nocase' keyword can be placed to indicate that pattern defined by this option should be matched without case distinction.
For example:

headers_content:"image/"; nocase;
body_content:"document.domain|28|"; nocase;


url_re, headers_re, body_re

These options allow to specify Perl compatible regular expression which is matched against HTTP response URL, headers or body respectively. They are similar to pcre Snort option. *_re option format is described in the Snort manual (Snort R, U and B modifiers are not available). Note: It might be tempting to use only *_re options in rules as regular expressions have much more powerful syntax than *_content options provide. It is not a good idea because it has very negative impact on Firekeeper performance. *_content rules are matched using very effective Aho & Corasick multi-pattern search engine from Snort. This is fast algorithm which running time doesn't depend on a number of patterns that are used. In contrast every pattern defined by each *_re option has to be searched separately. To increase performance *_re options of a rule are only checked when all *_content options of this rule matched. It is recommended for every rule to have at least one *_content option (as long as possible) and to use regular expressions only to narrow the search.
Examples of *_re options:

url_re:"/\.ram$|\.rmp$|\.smi$|\.rt$|\.rp$/i";
body_re:"/^file\x3a\x2f\x2f[^\n]{400}/im";
headers_re:"/^Content-Disposition\x3a[^\r\n]*\{[\da-fA-F]{8}(-[\da-fA-F]{4}){3}-[\da-fA-F]{12}\}/smi";

Rule description options

msg

Specifies message displayed to the user when alert rule is triggered.
Examples:
msg:"object type overflow attempt";
msg:"Windows Media Player directory traversal via Content-Disposition attempt";

reference

Specifies sites where additional information about an attack described by a rule can be found. Links to these sites are displayed to the user in the alert window. Supported system are the same as in Snort (bugtraq, cve, nessus, mcafee, url). Multiple reference options are allowed.
Examples:
reference:bugtraq,9916; reference:cve,2004-0363;
reference:url,www.cert.org/advisories/CA-2001-26.html;
reference:url,www.ngssoftware.com/advisories/ms-winhlp.txt; reference:bugtraq,4857; reference:cve,2002-0823;
See also reference option description in the Snort manual.

fid

fid is a number that uniquely identifies Firekeeper rule. It is equivalent of Snort sid keyword.
Example:
fid:2435;

rev

rev is a number that identifies revision of a rule with a given fid. It allows identification of rules definition updates. Snort has the same keyword.
Example:
rev:10;

For questions or comments about firekeeper, please send a message to the firekeeper mailing list.
Copyright © 2006-2007 Jan Wrobel <wrr@mixedbit.org>. All rights reserved. Privacy Policy.