JumpServer Access Control Guide: Block High-Risk Linux Commands Before They Execute

Table of Contents

• Why Command Filtering Matters
• How JumpServer Access Control Works
• The High-Risk Command Reference List
  • Basic System Commands
  • Disk and Filesystem Commands
  • User and Group Management
  • Network Interface Commands
  • File Permission Commands
  • Shell Built-ins and Process Control
  • Database Commands
• Step 1: Create a Command Group
• Step 2: Create a Command Filter
• Step 3: Choose the Right Action
• Understanding Priority (1–100)
• Additional Access Control Rules
  • User Login Rules
  • Asset Connection Rules (Enterprise)
  • Data Masking (Enterprise)
  • Connection Method Control (Enterprise)
• Quick Reference: All Four ACL Types

Why Command Filtering Matters

A single privileged session without guardrails can undo weeks of infrastructure work. Commands like rm -rf /, DROP DATABASE, or mkfs are entirely legitimate in the right hands — but catastrophic when run by mistake or by a compromised account.

Blanket blocking does not work in practice. A database administrator genuinely needs DROP TABLE in some contexts; a sysadmin may need reboot during a maintenance window. What you actually need is a policy layer that can:

• Block the most destructive commands outright
• Route borderline commands through a human approver before execution
• Alert a security team when a sensitive command is attempted
• Log every matched command for audit purposes

JumpServer's Access Control module provides exactly this — a flexible, priority-based rule engine that sits between the user and the asset, evaluating every command before it reaches the target server.

How JumpServer Access Control Works

JumpServer's Access Control operates at four layers:

Command filtering is the core mechanism for blocking high-risk commands and is available in both the Community and Enterprise editions.

How command matching works:

1. A user connects to an asset and executes a command.
2. JumpServer checks all command filters bound to that combination of user, asset, and account.
3. Filters are evaluated in priority order (lower number = evaluated first).
4. The first matching rule's action is executed: Deny, Accept, Review, or Alert.
5. If no rule matches, the command executes normally.

The High-Risk Command Reference List

The following commands are commonly flagged as high-risk in Linux environments managed by JumpServer. Use these as a starting point when building your command groups. Not all commands should be blocked — configure the action (Deny, Review, or Alert) based on your organization's risk tolerance and operational needs.

Basic System Commands

Disk and Filesystem Commands

User and Group Management

Network Interface Commands

File Permission Commands

Shell Built-ins and Process Control

Database Commands

Step 1: Create a Command Group

A command group is the list of commands (or patterns) that a filter will match against. One filter can reference multiple command groups.

Navigation: Access Control > Command Filter > Command Group tab > Create

Example: High-risk deletion group

To match rm and its variants, create a command group with type Regex and content:

\brm\b
\brmdir\b

To match exact SQL commands, use type Command and list each command on its own line:

DROP DATABASE
DROP TABLE
TRUNCATE TABLE

Tip: For database commands, enabling Case Insensitive ensures that drop database, DROP DATABASE, and Drop Database are all caught by the same rule.

Step 2: Create a Command Filter

A command filter binds one or more command groups to a specific combination of users, assets, and accounts.

Navigation: Access Control > Command Filter > Command Filter tab > Create

Binding logic: The filter applies when the specified user connects to the specified asset using the specified account. When a command is entered, it is evaluated against all matching filters in priority order. The first matching rule's action fires.

Step 3: Choose the Right Action

JumpServer supports four actions for matched commands — not just block or allow:

Practical configuration strategy:

• Use Deny for commands that have no legitimate use case in your environment (e.g., mkfs on production servers, DROP DATABASE for read-only accounts).
• Use Review for commands that are occasionally necessary but require a second pair of eyes (e.g., userdel, chmod 777, GRANT).
• Use Alert for commands you want visibility into but do not want to interrupt (e.g., history, export, reboot during business hours).

This layered approach avoids the "blanket ban" problem while still protecting critical systems.

Understanding Priority (1–100)

Every command filter and access control rule in JumpServer has a priority value between 1 and 100. Lower numbers are evaluated first.

When multiple filters match the same user-asset-account combination:

1. The filter with the lowest priority number is evaluated first.
2. If a command matches a rule in that filter, the action fires and evaluation stops.
3. If no rule matches, JumpServer moves to the next filter in priority order.
4. If no filter matches at all, the command executes normally.

Example setup:

With this setup, DROP DATABASE is blocked immediately (priority 10), DROP TABLE goes to an approver (priority 30), and chmod triggers a notification but still runs (priority 50).

Additional Access Control Rules

User Login Rules

User login rules control who can log in to JumpServer itself, from which IP addresses, and during which time windows.

Navigation: Access Control > User Login > Create

Note: The Review (approval workflow) action for user login is an Enterprise (X-Pack) feature.

Asset Connection Rules (Enterprise)

Asset connection rules add a second review layer specifically for connecting to assets — separate from the command filter that applies during a session.

Navigation: Access Control > Asset Connection > Create

Available actions:

Note: Password Rotation requires adding CHANGE_SECRET_AFTER_SESSION_END=true to the JumpServer configuration file and restarting the service.

Data Masking (Enterprise)

Data masking rules apply to database asset sessions. When a query returns results, specified columns are automatically obscured before they reach the user's screen.

Navigation: Access Control > Data Masking > Create

The masking rule uses column names with optional wildcard support:

• Single column: password — masks only the password column
• Multiple columns: password,secret — masks both columns
• Prefix wildcard: password* — masks all columns whose names start with password
• Suffix wildcard: .*password — masks all columns whose names end with password

Note: Data masking is not supported for database assets connected via the Magnus component (client mode), except for MySQL.

Connection Method Control (Enterprise)

Connection method rules let you restrict which protocols and interfaces users can use to reach an asset.

Navigation: Access Control > Connection Method > Create

Supported connection methods include Web CLI, Web SFTP, SSH, Web GUI, and database client. The only available action is Deny, which blocks the matched connection method for the specified users.

Quick Reference: All Four ACL Types

*Review action for User Login requires Enterprise (X-Pack).

Start Controlling Privileged Commands With JumpServer

The commands listed in this guide represent some of the highest-risk operations in any Linux environment. Without a policy layer between your operators and your assets, a single mistyped rm -rf or an unreviewed DROP DATABASE can cause damage that takes hours — or days — to recover from.

JumpServer Community Edition ships with full command filtering and user login access control at no cost. The Enterprise edition adds asset connection review, data masking, connection method control, and the full approval workflow across all ACL types.

Get JumpServer Free