Session Command Filters: Configuration
Command Filters must be properly configured and assigned to access profiles in order to be effective during remote sessions. This section describes how administrators can define, manage, and apply Command Filter policies using the PAM platform’s management interface. By setting up filters with Allow, Deny, and Paths rules, and associating them with the right users or assets, organizations can enforce granular control over command execution.
Command Filter Options
Command Filters operate using one of two list types; Allow or Deny; along with an Paths setting for trusted binary enforcement. Only one of Allow or Deny can be active in a single policy.
Allow List
- Specifies exact commands that are permitted, using regular expressions.
- All commands not explicitly matched are denied.
- Common use: Whitelisting a limited set of administrative tasks.
Example:
^exit$
^sudo /etc/init.d/mysql restart$
^sudo /etc/init.d/mysql status$
Deny List
- Specifies commands that are explicitly prohibited, using regular expressions.
- All other commands are allowed.
- Common use: Blocking high-risk or destructive commands.
Example:
^kill .*$
^sudo shutdown .*$
Paths Enforcement
- Defines a list of absolute binary paths considered trusted.
- Commands entered without full paths are automatically rewritten by the Access Broker to use these trusted paths before execution.
- Helps prevent execution of malicious scripts or binaries from untrusted directories.
Example:
/bin/ls
/bin/awk
/bin/grep
Creating a Command Filter Policy
To create a Command Filter policy:
- Navigate to Management > Command Filters and click the Add button.
- Enter a unique and recognizable Name for the policy.
- Decide on the Filter mode:
- Populate the Allow to permit only matching commands.
- Populate the Deny field to block only matching commands.
- Enter one regular expression per line in the appropriate list.
- (Optional) In the Paths section, specify a list of full binary paths to enforce trusted command execution.
- Toggle On the Enabled switch.
- Click Save to create the filter.
Note: Be sure to test regular expressions for accuracy. Improper syntax or overly broad patterns may lead to unintended access or false denials.
Assigning Command Filters to Access Profiles
Once a Command Filter is created, it must be assigned to the relevant access profile to take effect:
- Navigate to Management > Access Profiles.
- Create or Edit the access profile to which the filter should apply.
- For the Command Filter parameter, choose the desired filter from the dropdown list.
- Click Save to apply the configuration.
The selected Command Filter will now be enforced for all users and their sessions governed by this access profile.
Example: Command Filter Policy Configuration
Here is a full example of a Command Filter policy used to secure access to a MySQL database server, allowing only safe operations and enforcing trusted binaries.
- Login with a Site Administrator account.
- Navigate to Management > Command Filters and click Add.
- Enter a unique, but recognizable Name like
MySQL Safe Operations
. - In the Allow field, enter:
^sudo /etc/init.d/mysql restart$ ^sudo /etc/init.d/mysql status$ ^exit$
- Leave the Deny field empty.
- In the Paths field, enter:
/bin/ls /bin/awk /bin/grep
- Click Save.
Use Case:
- Allows only restart/status checks of the MySQL service and clean session exits.
- Prevents all other commands, including dangerous ones like
shutdown
,kill
, or shell navigation. - Enforces execution of utilities like
ls
,awk
, andgrep
from secure locations.
This configuration would typically be assigned to an access profile for database administrators, ensuring strict command control and mitigating the risk of misuse or lateral movement.
To assign the Command Filter policy to a user(s) and asset:
- Locate an existing Access Profile or Create a new Access Profile
- In the Add or Edit Access Profile page, select the enabled Command Filter policy from the Command Filter dropdown selector.
- Click Save.
Testing and User Experience
After assigning a Command Filter to an Access Profile, it is important to test the policy to validate that the rules function as intended and to understand the resulting user experience during remote sessions.
User Experience
When Command Filters are active in a session, the user interface is modified to enforce secure command input:
- Keyboard and mouse input to the remote session is completely blocked.
- A Command Input Field appears as an overlay along the bottom of the session screen.
- Users must enter all commands through this input field.
- Direct interaction with the remote session window (typing or clicking) is not permitted.
Command Execution Flow:
- The user types a command into the Command Input Field.
- The Access Broker evaluates the command against the assigned Command Filter:
- If Allowed, the command is forwarded to the remote host for execution.
- If Denied, the command is blocked and the user is shown a message stating the command is not permitted due to policy.
This controlled experience ensures that all command activity is validated before reaching the endpoint, significantly reducing the risk of unauthorized or harmful operations.
How to Test a Command Filter Policy
- Launch a Remote Session to a target system using a user account governed by an Access Profile that has an active Command Filter.
- When the session starts, confirm the appearance of the Command Input Overlay at the bottom of the session window. Mouse and native keyboard inputs are blocked entirely.
- Attempt to enter a command that is allowed by the policy:
- The command will be validated.
- If permitted, it will be sent to the endpoint and executed as expected.
- If Paths were defined, the command will be executed from a trusted location.
- Attempt to enter a disallowed command (either not on the Allow list or matched in the Deny list):
- The system will block the command.
- A notification prompt will appear, indicating that the command is not permitted due to an active policy.
Example: The command `ls -alp` was executed when in the user's home directory, but Command Filter automatically executed it from the defined Paths directory of `/bin/ls -alp`
This process can be repeated to verify that all relevant policies are working as expected.
Events Report Logging
Commands blocked due to an active Command Filters Policy will generate an entry in the Events Report.
Level: Information
Category: Operation
Event: Command Filter
Message: user=<loginName (DisplayName) / userDirectory>, command=<blockedCommand>