Keycyte PAM 3.2 · Administrator Guide
Command Filters
A command filter is a set of command patterns with an action. Keycyte PAM checks each command that a user runs against the filters that apply to the session, and the first matching filter decides what happens to the command.
Command filters apply to:
- SSH sessions through the Keycyte PAM SSH proxy;
- commands that network devices authorize through the Keycyte TACACS+ server.
Command filters are available only to MASTER users. To open the page, select Access Control > Command Filters.
Filter Actions
| Action | In an SSH session | Over TACACS+ |
|---|---|---|
accept | The command runs. Filters with a higher priority number are not checked for this command. | Permitted. |
warning | The command runs and is recorded with a warning level in the command history. | Permitted and recorded as warned. |
notify_and_warn | The user sees a warning before the command runs, and the command is recorded with a warning level. | Permitted and recorded as warned. |
reject | The command is blocked and does not reach the server. | Refused. |
Matched commands are recorded with the filter that matched them. See Sessions > Command History.
How Filters Are Evaluated
When a session starts, Keycyte PAM collects the enabled filters that apply to the user and the server, and orders them by Priority, lowest number first. For each command, the patterns of the filters are checked in this order, and the first pattern that matches decides the action. A command that matches no pattern runs normally.
A filter without patterns has no effect.
Creating a Command Filter
To create a command filter:
-
Select Access Control > Command Filters.
-
Click Create in the toolbar. The Create Command Filter dialog opens on the General tab.
-
On the General tab, fill in the fields:
Field Description Name Name of the filter, up to 128 characters. Required. Description Free-text note. Priority Evaluation order, from 0to9999. Lower numbers are checked first. Default:100.Action accept,warning,notify_and_warnorreject. Default:warning.Ignore case (default for items) Matches patterns without regard to upper and lower case. Each pattern can override this. Enabled Turns the filter on. Selected by default. -
On the Patterns tab, click Add Pattern and define one or more patterns. See Patterns.
-
Click Save.
The filter is saved and applies to all sessions until you add bindings. The Bindings and Test tabs become available when you open the saved filter with Edit.
Patterns
Each row on the Patterns tab is one pattern item:
| Column | Description |
|---|---|
| Type | command or regex. |
| Pattern (one per line) | The text to match. |
| Ignore case | Yes, No, or empty to use the filter’s Ignore case (default for items) setting. |
The two types match differently:
| Type | How it matches | Example |
|---|---|---|
command | Each line of the pattern is a literal text. The command matches if it contains any of the lines anywhere. | The lines rm -rf / and mkfs match sudo rm -rf /tmp/x and mkfs.ext4 /dev/sdb1. |
regex | The pattern is a regular expression (Go syntax). The command matches if the expression finds a non-empty match anywhere in it. | ^\s*(shutdown|reboot)\b matches commands that start with shutdown or reboot. |
Important
A command pattern matches substrings, so a short pattern can match more than intended. For example, rm also matches perform. Use a regex pattern with word boundaries when you need an exact command.
A regular expression that is not valid matches nothing. Test new patterns on the Test tab.
To remove a pattern, click the delete button in its row.
Bindings
Bindings decide which sessions a filter applies to. A filter without bindings applies to all sessions.
To add a binding:
- Open the filter with Edit and select the Bindings tab.
- Click Add Binding. The Add Binding dialog opens.
- In Scope Type, select Server Role, User Role, Server or User.
- In Target, select the role, server or user.
- Click Add.
Bindings work on two axes:
- the user axis: User and User Role bindings;
- the server axis: Server and Server Role bindings.
A filter applies to a session when both axes match. An axis without bindings matches everything. For example, a filter bound only to the server role Production Linux applies to every user on those servers; a filter bound to the user role Contractors and the server role Production Linux applies only to contractors on those servers.
To remove a binding, click the delete button in its row and confirm.
You can also attach filters from the role side: the edit panel of a server role or user role has a Linked Command Filters section with Attach Filter. See Server Roles and User Roles.
Testing a Command
The Test tab checks a command against the saved patterns of the filter with the same matching engine that sessions use.
To test a command:
- Open the filter with Edit and select the Test tab.
- Type a command, for example
rm -rf /, and click Run.
The result shows either No match — this command would pass through, or Match — action action would fire with the pattern item and the matched text. The test covers only this filter; it does not consider the priority of other filters.
Managing Filters
The filter list shows each filter’s Name, Action, Priority, Description, Updated time and Enabled switch.
- To turn a filter off or on, use its Enabled switch.
- To change a filter, click Edit. Changes on the General and Patterns tabs are saved with Save; bindings are saved immediately.
- To delete a filter with its patterns and bindings, click Delete and confirm.
- To filter the list, click Advanced Filter and set Name Contains, Action or Status (Enabled or Disabled).
Note
Sessions read their filters when they start. Changes apply to sessions that start afterwards.