Filesystem Read Write

The purpose of the Filesystem Read Write rule is to allow you to restrict a protected application from reading or writing to any file to which it should not have access.

Overview

This rule could prevent an application from reading a password file or writing to the shadow file on the system on which it resides.  This protection isn't specific to a CWE or other defined or limited attack.  The method of attack that causes the protected application to attempt to execute a specific command is irrelevant to this rule.  This rule only looks at and potentially protects against the end result of any such attack.

Rule Options

File Operation

The only options here are read or write. This tells the rule which action it is controlling, the reading of files or paths, or the writing to files or paths.

Restrict Rule to API Endpoints

You can limit the rule to respond to API requests only.

• No - Do not restrict the rule response
• All Endpoints - Restrict the rule response to API requests only
• Specific Endpoints - Restrict the rule response to API requests on the specified endpoints

You can change the default value No but you can select only one of these options.

Do Not Trust Inputs From

You can choose the sources that the rule will treat as untrusted. This section is optional, you do not have to select any or you can select all of the sources listed:

• HTTP - Data received by the application from HTTP requests (e.g. from a web browser).
• SQL Databases - Data received by the application from a SQL database.
• Deserialization APIs - Data received by the application via deserialization APIs (e.g. RMI, JMX, java.io.ObjectInputStream, etc.)

Files and Paths to Files

Here you can type in a path(s) or specific files that the rule will apply to.  Generally speaking this can be applied in 2 different ways:

1. You can list a number of paths and/or files that you wish to prevent from being read or written to via the protect action, or
2. You can create a pair of rules where the first Filesystem Read Write rule uses a path to Protect (e.g. /etc/*), and the second rule allows or whitelists specific files (via the Allow/Whitelist action) contained within that path, such as /etc/someTextFile.txt.

This way if there are 100 files in the target directory and you wish to protect 98 of them, you do not have to create 98 rules or an unwieldy rule listing 98 files. You can instead create 1 rule to protect against all of the files within the target directory, and create another rule to carve out the 2 that you want to allow to be read or written to.

In essence, the Allow/Whitelist option is allowing us to say “Protect all of these files” (protect rule with a path entered) followed by “Except these” (allow rule, explicitly listing files within that path). This is much more scalable than saying “Protect this file” (standard rule) 98 times.

You can type paths or files into the text field and upon typing a comma, or hitting the Return/Enter key the entries will be accepted and converted to a pill object which can then be removed from the list by clicking on the pill's cross symbol (x).

Valid File and Path Formats

Both Unix and Windows filesystem paths are valid. A wildcard (*) may be used in path entries, but only one wildcard can be used per entry.

On Windows systems, both backslashes (\) and forward slashes (/) are valid as path separators, as Windows supports both formats. However, for consistency and readability, using backslashes (\) is recommended.

Windows Short File Names (SFN / 8.3) are also valid (e.g. C:\PROGRA~1\). Although these are equivalent to long paths at the filesystem level, they must match exactly the paths expected by the application.

Action

• Detect - The Agent will detect the reading or writing of listed file (or files within a path) and always generate Security Event which will be viewable on the Security Events page in the Portal, but the Agent will take no further action.
• Protect - In addition to the Detect actions, and Security Event being optional, the Waratek Agent will also actively prevent the reading or writing of the files or anything within the protected paths, from succeeding.
• Allow - Acts as whitelist, will supersede the Protect action by whitelisting files and paths to be excluded from Protect actions. Generation of Security Event is optional.

Rule selection for overlapping file paths

Filesystem paths define a tree. Using wildcards, various complex policies can be implemented. When rules use different path patterns but both could match the same file, only a single rule will actually trigger. Action and severity are not compared across rules with different paths.

A rule with a complete and exact path takes precedence over a broader wildcard rule. Longer prefixes (e.g. /tmp/data/*) beat global filename or extension rules (e.g. file.txt, *.txt).

If one rule covers /tmp/* and another covers /tmp/example.txt, only the exact-path rule applies when that file is accessed. The wildcard rule is not combined with it and does not act as a fallback for that file.

A filename-only rule (e.g. file.txt) matches that base name in any directory.

• Wildcard Protect, exact-path Allow — Access to /tmp/example.txt is permitted. The exact Allow overrides the wildcard Protect for that file.
• Wildcard Detect, exact-path Allow — Access is permitted. The exact Allow applies; the wildcard Detect does not govern that file.
• Wildcard Detect, exact-path Protect — Access is denied. The exact Protect on the path wins over wildcard Detect.
• Wildcard Allow, exact-path Detect — Access is permitted. The exact Detect applies and will log; the wildcard Allow does not apply to that file.