Skip to content

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:

  1. Navigate to Management > Command Filters and click the Add button.
  2. Enter a unique and recognizable Name for the policy.
  3. Decide on the Filter mode:
    1. Populate the Allow to permit only matching commands.
    2. Populate the Deny field to block only matching commands.
  4. Enter one regular expression per line in the appropriate list.
  5. (Optional) In the Paths section, specify a list of full binary paths to enforce trusted command execution.
  6. Toggle On the Enabled switch.
  7. 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:

  1. Navigate to Management > Access Profiles.
  2. Create or Edit the access profile to which the filter should apply.
  3. For the Command Filter parameter, choose the desired filter from the dropdown list.
  4. 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.

  1. Login with a Site Administrator account.
  2. Navigate to Management > Command Filters and click Add.
  3. Enter a unique, but recognizable Name like MySQL Safe Operations.
  4. In the Allow field, enter: 
    ^sudo /etc/init.d/mysql restart$
^sudo /etc/init.d/mysql status$
^exit$
  5. Leave the Deny field empty.
  6. In the Paths field, enter: 
    /bin/ls
/bin/awk
/bin/grep
  7. Click Save.

Create Command Filters Policy


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, and grep 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:

  1. Locate an existing Access Profile or Create a new Access Profile
  2. In the Add or Edit Access Profile page, select the enabled Command Filter policy from the Command Filter dropdown selector.
  3. Click Save.

Assigning Command Filters Policy

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 (Web SSH or RDP session)

When Command Filters are active in a web 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 Filter Session Input Field

Command Execution Flow:

  1. The user types a command into the Command Input Field.
  2. 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.

Command Filter Blocked Message

This controlled experience ensures that all command activity is validated before reaching the endpoint, significantly reducing the risk of unauthorized or harmful operations.


User Experience (SSH Proxy session)

When Command Filters are active during an SSH Proxy session, the user connects through a standard SSH client and is presented with a familiar shell prompt. Unlike Web SSH or RDP sessions, the interface is not visually modified; instead, command enforcement occurs transparently as commands are entered.

  • Users interact with the session using their native SSH client.
  • Commands are entered directly at the shell prompt as usual.
  • Each command is inspected in real time by the system before execution.
  • Commands may be normalized or expanded (for example, resolving aliases to full paths such as /bin/ls) prior to evaluation.

Command Execution Flow:

  1. The user types a command at the SSH prompt.
  2. The Access Broker evaluates the command against the assigned Command Filter:
    • If Allowed, the command is forwarded to the target host for execution.
    • If Denied, the command is blocked and the user receives an error indicating the command is not permitted by policy.

SSH Proxy Command Filter Block Messages

Example: SSH Proxy Command Filter Enforcement and Command Denied Messages.


While this approach preserves a native SSH experience, enforcement is dependent on the quality of the command filter policy. As with any deny-list–based model, insufficiently restrictive policies may allow users to bypass controls by launching interactive or graphical utilities (such as text editors) that provide access to secondary shells or similar methods.

To further strengthen enforcement in SSH Proxy sessions, an alternative execution model is available that more closely mirrors the controlled behavior of Web SSH sessions:

Command Filter Strategy Options

A custom Command Filter Strategy choice field can be created in an SSH based Asset Type and configured in the Asset using one of the following defined choices:

  • Native Shell
    Presents the standard system shell while monitoring and filtering commands as they are entered.

  • Application Shell
    Replaces the native shell with a 12Port proprietary, highly restricted shell that prevents access to secondary shells and interactive escape paths, providing stronger command control.

Custom Field Command Filter Strategy

Switching between these strategies allows administrators to balance usability and security based on the risk profile of the asset and the desired level of command enforcement.


How to Test a Command Filter Policy

  1. Launch a Remote Session to a target system using a user account governed by an Access Profile that has an active Command Filter.
  2. 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.
  3. 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.
  4. 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.

Command Filters Paths Example

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>

Command Filter Events Report Entry