JumpServer Access Control Guide: Block High-Risk Commands with Regex

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 perfectly legitimate in the right hands, but catastrophic when run by mistake or by a compromised account. If you want the background on why each of these commands is dangerous, start with High-Risk Linux Server Commands: A Comprehensive Security Guide. This article picks up where that one stops: how to actually stop the command from executing.

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 five layers:

Command filtering is the core mechanism for blocking high-risk commands and is available in both the Community and Enterprise editions. It works the same way for Linux, Windows, database, and network device assets, because the filter matches the text of the command that flows through the session.

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.

Command Regex Syntax That Actually Works

A command group can use two matching types. Use Command when you need an exact string match, and Regex when you need to cover argument variants. Regex matching is a search against the command line rather than a strict full-line match, so where you place the anchor determines how tightly the rule binds. Everything in the reference tables below uses the building blocks in this section.

Three rules of thumb before you enable anything:

1. Test on a small scope first. Apply the new filter to a test asset, then run both the destructive command and a harmless lookalike such as rm -rf /tmp/build. Confirm that what you want blocked is blocked and what you want allowed still runs.
2. Separate deny from review. Dual-use commands such as dd, curl, wget, scp, and rsync are frequently needed for legitimate operations. Route them to Review or to an explicit allow rule instead of a hard deny, or you will block real maintenance work.
3. Anchor tightly when you want precision. ^\s*rm -rf /.* matches any path under root, while ^\s*rm -rf /(?:\s.*)?$ matches only the root directory itself, so rm -rf /tmp/cache is still permitted.

The High-Risk Command Reference

The tables below are the patterns we recommend as a starting point. They cover 226 commands grouped by risk scenario across Linux, Windows, database, and network device assets.

Not every entry should be denied. Use the tables as an inventory of what to review, then choose the action (Deny, Review, or Alert) based on your own risk tolerance and operational needs. Patterns that we do not recommend enabling without a review are called out in the description column.

Linux and Unix Commands (100)

Data Destruction and Irreversible Deletion (16)

Business Availability (27)

Privilege and Escalation (21)

Security Control Bypass (10)

Network and Configuration (5)

Data Exfiltration and Lateral Movement (9)

Anti-Forensics (3)

Package Removal (9)

Windows Commands (49)

Database Commands (55)

Network Device Commands (22)

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, so grouping patterns by risk scenario keeps the rules readable.

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

Example: irreversible file and disk operations

Create a command group with type Regex and this content, one pattern per line:

^\s*rm -rf /.*
^\s*mkfs.*
^\s*wipefs.*
^\s*shred.*
^\s*dd\s+if=/dev/zero.*
^\s*dd\s+if=/dev/urandom.*

Example: cross-database destructive statements

Database commands are a good fit for Regex with Case Insensitive enabled, because drop database, DROP DATABASE, and Drop Database all reach the server the same way and should all be caught by the same rule:

(?i)^\s*drop\s+database.*
(?i)^\s*drop\s+table.*
(?i)^\s*truncate.*
(?i)^\s*flushall.*

Note that a bare (?i)^\s*truncate.* pattern is intentionally broad. It also matches TRUNCATE TABLE, which is why the reference tables do not list both variants in the same group.

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.

A practical pattern is to keep one group per risk scenario and then compose filters from them, for example a “DBA change window” filter that binds the database groups only to the DBA user group and the production database assets.

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, for example mkfs on production servers or DROP DATABASE for read-only accounts.
• Use Review for commands that are occasionally necessary but require a second pair of eyes, for example userdel, chmod 777, or GRANT.
• Use Alert for commands you want visibility into but do not want to interrupt, for example history, export, or reboot during business hours.
• Use Accept for narrow exceptions that must be evaluated before a broader deny rule, for example ^\s*rm -rf /tmp/.* for a build agent account.

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.

The most common mistake is to place an exception rule at a high priority number and then wonder why it never takes effect. An exception must be evaluated before the rule it is an exception to, so it needs a lower priority number than the deny rule.

A Complete Three-Tier Policy Example

The table below shows a working policy for a mixed production environment. The exception rule runs first, then the hard blocks, then the review and visibility layers.

With this setup, rm -rf /tmp/build is allowed at priority 5, rm -rf / is blocked at priority 10, DROP TABLE goes to an approver at priority 30, and scp runs but generates a notification at priority 70.

Rollout Checklist

• Inventory first. Export your current command groups and filters before you change anything, so you have a rollback path.
• Stage the rollout. Apply new filters to a small set of non-production assets and a pilot user group before the broad rollout.
• Pilot for 24 to 48 hours. Review the command execution logs to see what the new rules actually catch. Expect at least one legitimate command to surface.
• Tune the false positives. Split the rule rather than deleting it. Keep the deny for the dangerous form and add a narrowly scoped Accept rule with a lower priority number for the safe form.
• Prefer review over removal. When a dual-use tool is genuinely required, move the rule from Deny to Review instead of disabling it.
• Verify coverage. Test alternative paths that users could take, including shell wrappers, editors, and script files, and confirm the result is what you expect.
• Review quarterly. New tooling introduces new commands. Re-check the reference tables against your asset estate and adjust.

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. This is a useful complement to command filtering, because it limits what a privileged user can read even when the query itself is allowed.

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 of All Five ACL Types

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

Start Controlling Privileged Commands With JumpServer

The commands in this guide represent the highest-risk operations across Linux, Windows, database, and network device estates. 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.

• Compare the editions and capability boundaries on the features page
• Start a 30-day Enterprise test drive through the free trial
• New to privileged access management? Read What Is PAM and RBAC in PAM first
• Related reading: JumpServer Audit Recordings Management

Get JumpServer Free