Rulelist

The rulelist is a semicolon separated file (the operator also may use the comma or pipe symbol "|" as legal separator symbols). We are planning a replacement of this field based text file by an XML rulelist file with more flexibility for the next version of OCFA.

You as operator can use the rulelist in order to program the evidence flow through the Computer Forensics Architecture. That is: to define the sequence of modules to process the evidence.

The idea behind the rulelist is roughly based on the iptables implementation. In the source distribution several example rulelists are included (an example tells more than a thousand words). After installation, the rulelists can be found in the ${OCFAROOT}/etc directory. The rulelist actually used during processing is defined in the ocfa configuration file.

Rule lines

The current version of the rulelist is a line based text file. Each line defines a rule. The maximum number of rulelines is defined in the ocfa configuration file . The rule line is mainly devided into three main parts:

  1. Table name (not currently used)
  2. Packet section
  3. Final action section
Table name
 Packet section
 Final action field

Example of three rulelines from an actual rulelist:

default;DNTCR;mimetype;image/jpeg;DNTCR;ACT_FORWARD;exif;
default;DNTCR;mimetype;application/msword;DNTCR;ACT_FORWARD;antiword;
default;DNTCR;mimetype;application/x-zip;DNTCR;ACT_FORWARD;zip;

In the following section the three fields are further explained.

Table name

The table name fields is not used for a routing decision at this moment. The value is set to "default". In this implementation only a single table is available and this puts some strain on how expressive the rulelist can be built. Future versions of the router will include support for jumping between multiple tables in order to allow routing on multiple metadata fields and in order to allow (per table) routing based on metadata added by modules before the previous module.

Packet section

The router uses the packet section to base the routing decision on. The packet section contains four restrictive selection fields:

  1. The namespace. An exact match on the namespace of the metadata.
  2. The type. An exact match on the type of the metadata.
  3. The value. A "part of" (substring) match of the actual value of the metadata.
  4. The module name of the module that added the metadata.

A match of the packet field will fire the final action defined in the same ruleline.

For each field in the packet section you may use the reserved "DNTCR" value. This means "don't care". In the example the value for the namespace does not influence the routing decision. All values from the metadata will match here. It is not a good practice to use "DNTCR" for all four fields. This rule will match for sure and the rulelist will exit at this point, never reaching the rulelines following (see matching strategies section below) . For this purpose a default routing is defined in the ocfa configuration file. Firing the default routing will cause a warning message in the logging. A properly constructed rulelist should prevent the firing of the default rule.

Final Action field

Future versions of the router shall have support for side-actions (logging, adding metadata etc) to make the router even more expressive. In the current version of the rulelist the operator can use the action field to define the final action on a evidence. The final action has three fields:

  1. Action type field. See defined actions below.
  2. Action target field. The target module to send the evidence to in the case of an ACT_FORWARD action type.
  3. Action argument field. Optional, not implemented yet.

In the ocfa configuration file, a rulelist section defines the default action in the case no ruleline matches.

Action type field

The following final action types are defined:

  1. ACT_FORWARD. This will send the evidence to the module type defined in the target field.
  2. ACT_COMMIT. This will store the evidence in the DSM. No further processing needed.
  3. ACT_SUSPEND. This will prevent the evidence from further processing, until a user action is given to continue.
  4. ACT_ERROR. Not implemented.
Planned extensions to this list are:
  1. ACT_JUMP. This will trigger a jump action to the table defined in the target field.
The complete ruleline looks like this:
table name
 namespace
 meta type
 meta value
 last module
 action type
 action target
 action argument

Matching strategy

Like the iptables implementation, the rulelist has a top down approach. The first best line matching the metadata coming with the evidence under consideration will fire the defined final action. Only all metadata of the last job will be evaluated against the defined packets.

This means that the most specific lines have to been put on top of the rulelist and the most general lines on the bottom of the rulelist. Don't use a general catch line with all DNTCR values as packet parameters. This is already implemented as an ocfa configuration item.

Back to router.